Catégorie : Blog

  • Socle V004 – KV-Bus

    Socle V004 – KV-Bus

    06 – KvBus (Key-Value Bus)

    Version : 4.0.0 Date : 2025-12-09

    1. Introduction

    KvBus est une abstraction de stockage clé-valeur avec deux implémentations :

    • in_memory : HashMap pour le développement local
    • redis : Redis pour la production multi-instances

    Caractéristiques

    • Interface unifiée
    • TTL (Time-To-Live) configurable
    • Opérations atomiques
    • Support JSON pour les objets complexes
    • Patterns pub/sub (Redis uniquement)

    2. Configuration

    2.1 application.yml

    socle:
      kvbus:
        mode: ${KVBUS_MODE:in_memory}
        redis:
          host: ${REDIS_HOST:localhost}
          port: ${REDIS_PORT:6379}
          password: ${REDIS_PASSWORD:}
          database: ${REDIS_DATABASE:0}
          prefix: ${REDIS_PREFIX:socle}
          connect-timeout-ms: ${REDIS_CONNECT_TIMEOUT:5000}
          read-timeout-ms: ${REDIS_READ_TIMEOUT:5000}
          pool:
            max-total: ${REDIS_POOL_MAX:16}
            max-idle: ${REDIS_POOL_MAX_IDLE:8}
            min-idle: ${REDIS_POOL_MIN_IDLE:2}
    

    2.2 Variables d’environnement

    Variable Description Défaut
    KVBUS_MODE Mode (in_memory/redis) in_memory
    REDIS_HOST Hôte Redis localhost
    REDIS_PORT Port Redis 6379
    REDIS_PASSWORD Mot de passe
    REDIS_DATABASE Database number 0
    REDIS_PREFIX Préfixe des clés socle

    3. Interface KvBus

    package eu.lmvi.socle.kv;
    
    public interface KvBus {
    
        // === CRUD basique ===
    
        /**
         * Stocke une valeur
         */
        void put(String key, String value);
    
        /**
         * Stocke une valeur avec TTL
         */
        void put(String key, String value, Duration ttl);
    
        /**
         * Récupère une valeur
         */
        Optional<String> get(String key);
    
        /**
         * Supprime une clé
         */
        void delete(String key);
    
        /**
         * Vérifie l'existence d'une clé
         */
        boolean exists(String key);
    
        // === TTL ===
    
        /**
         * Définit le TTL d'une clé existante
         */
        void setTtl(String key, Duration ttl);
    
        /**
         * Récupère le TTL restant
         */
        Optional<Duration> getTtl(String key);
    
        // === Opérations atomiques ===
    
        /**
         * Incrémente une valeur numérique
         */
        long increment(String key);
    
        /**
         * Incrémente avec delta
         */
        long increment(String key, long delta);
    
        /**
         * Set if not exists
         */
        boolean putIfAbsent(String key, String value);
    
        /**
         * Set if not exists avec TTL
         */
        boolean putIfAbsent(String key, String value, Duration ttl);
    
        // === Opérations en lot ===
    
        /**
         * Récupère plusieurs clés
         */
        Map<String, String> getAll(Collection<String> keys);
    
        /**
         * Stocke plusieurs valeurs
         */
        void putAll(Map<String, String> entries);
    
        /**
         * Supprime plusieurs clés
         */
        void deleteAll(Collection<String> keys);
    
        // === Pattern matching ===
    
        /**
         * Liste les clés correspondant à un pattern
         */
        Set<String> keys(String pattern);
    
        // === JSON helpers ===
    
        /**
         * Stocke un objet en JSON
         */
        <T> void putJson(String key, T object);
    
        /**
         * Récupère un objet depuis JSON
         */
        <T> Optional<T> getJson(String key, Class<T> type);
    
        // === Lifecycle ===
    
        /**
         * Vérifie la santé de la connexion
         */
        boolean isHealthy();
    
        /**
         * Ferme les connexions
         */
        void close();
    }
    

    4. Implémentation InMemoryKvBus

    package eu.lmvi.socle.kv;
    
    @Component
    @ConditionalOnProperty(name = "socle.kvbus.mode", havingValue = "in_memory", matchIfMissing = true)
    public class InMemoryKvBus implements KvBus {
    
        private final ConcurrentHashMap<String, Entry> store = new ConcurrentHashMap<>();
        private final ScheduledExecutorService cleaner;
    
        public InMemoryKvBus() {
            // Nettoyage des entrées expirées toutes les minutes
            cleaner = Executors.newSingleThreadScheduledExecutor();
            cleaner.scheduleAtFixedRate(this::cleanExpired, 1, 1, TimeUnit.MINUTES);
        }
    
        @Override
        public void put(String key, String value) {
            store.put(key, new Entry(value, null));
        }
    
        @Override
        public void put(String key, String value, Duration ttl) {
            Instant expiry = Instant.now().plus(ttl);
            store.put(key, new Entry(value, expiry));
        }
    
        @Override
        public Optional<String> get(String key) {
            Entry entry = store.get(key);
            if (entry == null) return Optional.empty();
            if (entry.isExpired()) {
                store.remove(key);
                return Optional.empty();
            }
            return Optional.of(entry.value);
        }
    
        @Override
        public void delete(String key) {
            store.remove(key);
        }
    
        @Override
        public boolean exists(String key) {
            return get(key).isPresent();
        }
    
        @Override
        public long increment(String key) {
            return increment(key, 1);
        }
    
        @Override
        public long increment(String key, long delta) {
            Entry entry = store.compute(key, (k, v) -> {
                long current = (v == null) ? 0 : Long.parseLong(v.value);
                return new Entry(String.valueOf(current + delta), v != null ? v.expiry : null);
            });
            return Long.parseLong(entry.value);
        }
    
        @Override
        public boolean putIfAbsent(String key, String value) {
            return store.putIfAbsent(key, new Entry(value, null)) == null;
        }
    
        @Override
        public Set<String> keys(String pattern) {
            String regex = pattern.replace("*", ".*");
            return store.keySet().stream()
                .filter(k -> k.matches(regex))
                .collect(Collectors.toSet());
        }
    
        @Override
        public boolean isHealthy() {
            return true;
        }
    
        @Override
        public void close() {
            cleaner.shutdown();
            store.clear();
        }
    
        private void cleanExpired() {
            store.entrySet().removeIf(e -> e.getValue().isExpired());
        }
    
        private record Entry(String value, Instant expiry) {
            boolean isExpired() {
                return expiry != null && Instant.now().isAfter(expiry);
            }
        }
    }
    

    5. Implémentation RedisKvBus

    package eu.lmvi.socle.kv;
    
    @Component
    @ConditionalOnProperty(name = "socle.kvbus.mode", havingValue = "redis")
    public class RedisKvBus implements KvBus {
    
        private static final Logger log = LoggerFactory.getLogger(RedisKvBus.class);
    
        private final JedisPool jedisPool;
        private final String prefix;
        private final ObjectMapper objectMapper;
    
        public RedisKvBus(SocleConfiguration config) {
            JedisPoolConfig poolConfig = new JedisPoolConfig();
            poolConfig.setMaxTotal(config.getKvbus().getRedis().getPool().getMaxTotal());
            poolConfig.setMaxIdle(config.getKvbus().getRedis().getPool().getMaxIdle());
            poolConfig.setMinIdle(config.getKvbus().getRedis().getPool().getMinIdle());
    
            this.jedisPool = new JedisPool(
                poolConfig,
                config.getKvbus().getRedis().getHost(),
                config.getKvbus().getRedis().getPort(),
                config.getKvbus().getRedis().getConnectTimeoutMs(),
                config.getKvbus().getRedis().getPassword(),
                config.getKvbus().getRedis().getDatabase()
            );
    
            this.prefix = config.getKvbus().getRedis().getPrefix() + ":";
            this.objectMapper = new ObjectMapper();
    
            log.info("RedisKvBus initialized: {}:{}",
                config.getKvbus().getRedis().getHost(),
                config.getKvbus().getRedis().getPort());
        }
    
        private String prefixedKey(String key) {
            return prefix + key;
        }
    
        @Override
        public void put(String key, String value) {
            try (Jedis jedis = jedisPool.getResource()) {
                jedis.set(prefixedKey(key), value);
            }
        }
    
        @Override
        public void put(String key, String value, Duration ttl) {
            try (Jedis jedis = jedisPool.getResource()) {
                jedis.setex(prefixedKey(key), ttl.toSeconds(), value);
            }
        }
    
        @Override
        public Optional<String> get(String key) {
            try (Jedis jedis = jedisPool.getResource()) {
                return Optional.ofNullable(jedis.get(prefixedKey(key)));
            }
        }
    
        @Override
        public void delete(String key) {
            try (Jedis jedis = jedisPool.getResource()) {
                jedis.del(prefixedKey(key));
            }
        }
    
        @Override
        public boolean exists(String key) {
            try (Jedis jedis = jedisPool.getResource()) {
                return jedis.exists(prefixedKey(key));
            }
        }
    
        @Override
        public long increment(String key) {
            try (Jedis jedis = jedisPool.getResource()) {
                return jedis.incr(prefixedKey(key));
            }
        }
    
        @Override
        public long increment(String key, long delta) {
            try (Jedis jedis = jedisPool.getResource()) {
                return jedis.incrBy(prefixedKey(key), delta);
            }
        }
    
        @Override
        public boolean putIfAbsent(String key, String value) {
            try (Jedis jedis = jedisPool.getResource()) {
                return jedis.setnx(prefixedKey(key), value) == 1;
            }
        }
    
        @Override
        public boolean putIfAbsent(String key, String value, Duration ttl) {
            try (Jedis jedis = jedisPool.getResource()) {
                String result = jedis.set(prefixedKey(key), value,
                    SetParams.setParams().nx().ex(ttl.toSeconds()));
                return "OK".equals(result);
            }
        }
    
        @Override
        public Set<String> keys(String pattern) {
            try (Jedis jedis = jedisPool.getResource()) {
                Set<String> rawKeys = jedis.keys(prefixedKey(pattern));
                return rawKeys.stream()
                    .map(k -> k.substring(prefix.length()))
                    .collect(Collectors.toSet());
            }
        }
    
        @Override
        public <T> void putJson(String key, T object) {
            try {
                String json = objectMapper.writeValueAsString(object);
                put(key, json);
            } catch (JsonProcessingException e) {
                throw new RuntimeException("Failed to serialize object", e);
            }
        }
    
        @Override
        public <T> Optional<T> getJson(String key, Class<T> type) {
            return get(key).map(json -> {
                try {
                    return objectMapper.readValue(json, type);
                } catch (JsonProcessingException e) {
                    throw new RuntimeException("Failed to deserialize object", e);
                }
            });
        }
    
        @Override
        public boolean isHealthy() {
            try (Jedis jedis = jedisPool.getResource()) {
                return "PONG".equals(jedis.ping());
            } catch (Exception e) {
                return false;
            }
        }
    
        @Override
        public void close() {
            jedisPool.close();
        }
    }
    

    6. Utilisation

    6.1 Injection

    @Service
    public class MonService {
    
        @Autowired
        private KvBus kvBus;
    
        public void process() {
            // Utiliser kvBus...
        }
    }
    

    6.2 CRUD basique

    // Stocker
    kvBus.put("user:123:name", "John");
    kvBus.put("session:abc", "data", Duration.ofHours(1));
    
    // Récupérer
    Optional<String> name = kvBus.get("user:123:name");
    name.ifPresent(n -> log.info("Name: {}", n));
    
    // Vérifier
    if (kvBus.exists("user:123:name")) {
        // ...
    }
    
    // Supprimer
    kvBus.delete("user:123:name");
    

    6.3 JSON

    // Stocker un objet
    Order order = new Order("123", "PENDING", List.of("item1", "item2"));
    kvBus.putJson("order:123", order);
    
    // Récupérer un objet
    Optional<Order> retrieved = kvBus.getJson("order:123", Order.class);
    

    6.4 Compteurs atomiques

    // Incrémenter
    long newValue = kvBus.increment("stats:requests:total");
    long newValue2 = kvBus.increment("stats:bytes:total", 1024);
    
    // Compteur avec reset quotidien
    String dailyKey = "stats:requests:" + LocalDate.now();
    kvBus.increment(dailyKey);
    kvBus.setTtl(dailyKey, Duration.ofDays(1));
    

    6.5 Lock distribué (Redis)

    public boolean tryLock(String resource, Duration timeout) {
        String lockKey = "lock:" + resource;
        return kvBus.putIfAbsent(lockKey, "locked", timeout);
    }
    
    public void unlock(String resource) {
        kvBus.delete("lock:" + resource);
    }
    
    // Utilisation
    if (tryLock("order-processing", Duration.ofMinutes(5))) {
        try {
            processOrders();
        } finally {
            unlock("order-processing");
        }
    }
    

    6.6 Cache avec TTL

    public Order getOrder(String orderId) {
        String cacheKey = "cache:order:" + orderId;
    
        // Check cache
        Optional<Order> cached = kvBus.getJson(cacheKey, Order.class);
        if (cached.isPresent()) {
            return cached.get();
        }
    
        // Load from DB
        Order order = orderRepository.findById(orderId);
    
        // Cache for 5 minutes
        kvBus.putJson(cacheKey, order);
        kvBus.setTtl(cacheKey, Duration.ofMinutes(5));
    
        return order;
    }
    

    7. Patterns avancés

    7.1 Rate limiting

    public boolean isRateLimited(String userId, int maxRequests, Duration window) {
        String key = "ratelimit:" + userId + ":" + Instant.now().truncatedTo(ChronoUnit.MINUTES);
    
        long count = kvBus.increment(key);
        if (count == 1) {
            kvBus.setTtl(key, window);
        }
    
        return count > maxRequests;
    }
    

    7.2 Session management

    public void createSession(String sessionId, User user) {
        kvBus.putJson("session:" + sessionId, user);
        kvBus.setTtl("session:" + sessionId, Duration.ofHours(24));
    }
    
    public Optional<User> getSession(String sessionId) {
        return kvBus.getJson("session:" + sessionId, User.class);
    }
    
    public void refreshSession(String sessionId) {
        kvBus.setTtl("session:" + sessionId, Duration.ofHours(24));
    }
    
    public void destroySession(String sessionId) {
        kvBus.delete("session:" + sessionId);
    }
    

    7.3 Feature flags

    public boolean isFeatureEnabled(String feature) {
        return kvBus.get("feature:" + feature)
            .map(Boolean::parseBoolean)
            .orElse(false);
    }
    
    public void setFeatureFlag(String feature, boolean enabled) {
        kvBus.put("feature:" + feature, String.valueOf(enabled));
    }
    

    8. KvBus vs TechDB (V4)

    Aspect KvBus TechDB (H2)
    Cas d’usage Cache, sessions, locks Offsets, état persistant
    Survie restart Non (in_memory) / Oui (Redis) Oui (fichier)
    Multi-instances Non (in_memory) / Oui (Redis) Non (par instance)
    Performance Ultra rapide Rapide
    Requêtes Clé simple SQL, JSON

    Règle de choix

    • KvBus : Données temporaires, cache, sessions, compteurs temps réel
    • TechDB : Offsets, checkpoints, état qui doit survivre au restart

    9. Monitoring

    9.1 Métriques

    socle_kvbus_operations_total{operation="get"}
    socle_kvbus_operations_total{operation="put"}
    socle_kvbus_operations_total{operation="delete"}
    socle_kvbus_latency_seconds{operation="get"}
    socle_kvbus_keys_count
    

    9.2 Health Check

    @Component
    public class KvBusHealthIndicator implements HealthIndicator {
    
        @Autowired
        private KvBus kvBus;
    
        @Override
        public Health health() {
            if (kvBus.isHealthy()) {
                return Health.up().build();
            }
            return Health.down().withDetail("error", "KvBus not responding").build();
        }
    }
    

    10. Bonnes pratiques

    DO

    • Utiliser des préfixes de clés cohérents (user:, session:, cache:)
    • Toujours définir un TTL pour les caches
    • Utiliser putIfAbsent pour les locks
    • Préférer Redis en production multi-instances

    DON’T

    • Ne pas stocker de données volumineuses (> 1MB)
    • Ne pas utiliser keys("*") en production (scan)
    • Ne pas oublier de fermer les connexions
    • Ne pas utiliser in_memory pour les données critiques en prod

    11. Références

  • Socle V004 – Workers

    Socle V004 – Workers

    05 – Workers

    Version : 4.0.1 Date : 2026-01-13

    1. Introduction

    Les Workers sont les composants de traitement du Socle V4. Chaque Worker implémente une tâche spécifique et son cycle de vie est géré par le MOP (Main Orchestrator Process).

    Caractéristiques

    • Interface unique : Tous les workers implémentent Worker
    • Cycle de vie géré : Le MOP orchestre start/stop/doWork
    • Priorités : Ordre de démarrage/arrêt configurable
    • Scheduling : Support cron et intervalle
    • Health check : Supervision intégrée

    2. Interface Worker

    package eu.lmvi.socle.worker;
    
    public interface Worker {
    
        /**
         * Nom unique du worker
         */
        String getName();
    
        /**
         * Initialisation (appelé une fois au démarrage)
         */
        void initialize();
    
        /**
         * Démarrage du worker
         */
        void start();
    
        /**
         * Traitement principal (appelé cycliquement)
         */
        void doWork();
    
        /**
         * Arrêt gracieux
         */
        void stop();
    
        /**
         * État de santé
         */
        boolean isHealthy();
    
        /**
         * Statistiques du worker
         */
        Map<String, Object> getStats();
    
        // === Priorités ===
    
        /**
         * Priorité au démarrage (plus petit = premier)
         */
        default int getStartPriority() {
            return 100;
        }
    
        /**
         * Priorité à l'arrêt (plus petit = premier)
         */
        default int getStopPriority() {
            return 100;
        }
    
        // === Scheduling ===
    
        /**
         * Expression cron (ou null si non schedulé)
         */
        default String getSchedule() {
            return null;
        }
    
        /**
         * Intervalle entre les cycles doWork() en ms
         * Valeurs recommandees : 5000 (5s), 10000 (10s), 30000 (30s)
         */
        default long getCycleIntervalMs() {
            return 5000; // 5 secondes par defaut
        }
    
        /**
         * Worker schedulé par cron ?
         */
        default boolean isScheduled() {
            return getSchedule() != null;
        }
    
        /**
         * Worker passif (ne fait rien dans doWork) ?
         */
        default boolean isPassive() {
            return false;
        }
    }
    

    3. Implémentation de base

    3.1 Worker simple

    package com.myapp.worker;
    
    import eu.lmvi.socle.worker.Worker;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import org.springframework.stereotype.Component;
    
    @Component
    public class SimpleWorker implements Worker {
    
        private static final Logger log = LoggerFactory.getLogger(SimpleWorker.class);
    
        private volatile boolean running = false;
        private long processedCount = 0;
    
        @Override
        public String getName() {
            return "simple-worker";
        }
    
        @Override
        public void initialize() {
            log.info("Initializing SimpleWorker");
            // Charger configuration, connexions, etc.
        }
    
        @Override
        public void start() {
            log.info("Starting SimpleWorker");
            running = true;
        }
    
        @Override
        public void doWork() {
            if (!running) return;
    
            try {
                // Traitement principal
                processedCount++;
                log.debug("Processing item #{}", processedCount);
            } catch (Exception e) {
                log.error("Error in doWork", e);
            }
        }
    
        @Override
        public void stop() {
            log.info("Stopping SimpleWorker");
            running = false;
        }
    
        @Override
        public boolean isHealthy() {
            return running;
        }
    
        @Override
        public Map<String, Object> getStats() {
            return Map.of(
                "running", running,
                "processedCount", processedCount
            );
        }
    }
    

    3.2 Worker avec priorité

    @Component
    public class DatabaseWorker implements Worker {
    
        @Override
        public String getName() {
            return "database-worker";
        }
    
        @Override
        public int getStartPriority() {
            return 10;  // Démarre en premier (connexion DB)
        }
    
        @Override
        public int getStopPriority() {
            return 90;  // S'arrête en dernier (flush des données)
        }
    
        // ... autres méthodes
    }
    

    3.3 Worker schedulé (cron)

    @Component
    public class ReportWorker implements Worker {
    
        @Override
        public String getName() {
            return "report-worker";
        }
    
        @Override
        public String getSchedule() {
            return "0 0 6 * * ?";  // Tous les jours à 6h
        }
    
        @Override
        public boolean isScheduled() {
            return true;
        }
    
        @Override
        public void doWork() {
            log.info("Generating daily report...");
            // Génération du rapport
        }
    
        // ... autres méthodes
    }
    

    3.4 Worker passif (HTTP)

    @Component
    public class ApiWorker implements Worker {
    
        @Override
        public String getName() {
            return "api-worker";
        }
    
        @Override
        public boolean isPassive() {
            return true;  // Pas de doWork() cyclique
        }
    
        @Override
        public void doWork() {
            // Ne fait rien - le traitement est déclenché par HTTP
        }
    
        // Les requêtes HTTP déclenchent le traitement via endpoints REST
    }
    

    4. AbstractWorker

    Le Socle fournit une classe de base qui simplifie l’implémentation :

    package eu.lmvi.socle.worker;
    
    public abstract class AbstractWorker implements Worker {
    
        protected final Logger log = LoggerFactory.getLogger(getClass());
        protected volatile boolean running = false;
        protected volatile boolean healthy = true;
        protected final AtomicLong processedCount = new AtomicLong(0);
        protected final AtomicLong errorCount = new AtomicLong(0);
        protected Instant lastActivity;
    
        @Override
        public void initialize() {
            log.info("[{}] Initializing", getName());
            doInitialize();
        }
    
        @Override
        public void start() {
            log.info("[{}] Starting", getName());
            running = true;
            doStart();
        }
    
        @Override
        public void stop() {
            log.info("[{}] Stopping", getName());
            running = false;
            doStop();
        }
    
        @Override
        public void doWork() {
            if (!running) return;
    
            try {
                doProcess();
                lastActivity = Instant.now();
            } catch (Exception e) {
                errorCount.incrementAndGet();
                handleError(e);
            }
        }
    
        @Override
        public boolean isHealthy() {
            return running && healthy;
        }
    
        @Override
        public Map<String, Object> getStats() {
            return Map.of(
                "running", running,
                "healthy", healthy,
                "processedCount", processedCount.get(),
                "errorCount", errorCount.get(),
                "lastActivity", lastActivity != null ? lastActivity.toString() : "never"
            );
        }
    
        // === Méthodes à implémenter ===
    
        protected void doInitialize() {}
        protected void doStart() {}
        protected abstract void doProcess();
        protected void doStop() {}
    
        protected void handleError(Exception e) {
            log.error("[{}] Error in doWork", getName(), e);
        }
    
        protected void incrementProcessed() {
            processedCount.incrementAndGet();
        }
    }
    

    Utilisation

    @Component
    public class OrderWorker extends AbstractWorker {
    
        @Override
        public String getName() {
            return "order-worker";
        }
    
        @Override
        protected void doInitialize() {
            // Initialisation spécifique
        }
    
        @Override
        protected void doProcess() {
            // Traitement principal
            processOrders();
            incrementProcessed();
        }
    
        private void processOrders() {
            // ...
        }
    }
    

    5. Cycle de vie

    5.1 Séquence de démarrage

    1. MOP.start()
    2. Pour chaque worker (trié par startPriority ASC) :
       a. worker.initialize()
       b. worker.start()
       c. Enregistrement dans Supervisor
    3. Boucle principale :
       - Pour chaque worker non-schedulé, non-passif :
         - worker.doWork()
         - Sleep(worker.getCycleIntervalMs())
    

    5.2 Séquence d’arrêt

    1. Signal SIGTERM reçu
    2. MOP.gracefulShutdown()
    3. Pour chaque worker (trié par stopPriority ASC) :
       a. worker.stop()
       b. Attendre terminaison
    4. Cleanup final
    

    5.3 Diagramme

                     ┌──────────────┐
                     │   CREATED    │
                     └──────┬───────┘
                            │ initialize()
                            ▼
                     ┌──────────────┐
                     │ INITIALIZED  │
                     └──────┬───────┘
                            │ start()
                            ▼
              ┌─────────────────────────────┐
              │          RUNNING            │
              │                             │
              │  ┌──────────────────────┐   │
              │  │   doWork() loop      │   │
              │  │   (si non-passif)    │   │
              │  └──────────────────────┘   │
              │                             │
              └─────────────┬───────────────┘
                            │ stop()
                            ▼
                     ┌──────────────┐
                     │   STOPPED    │
                     └──────────────┘
    

    6. Communication entre Workers

    6.1 Via SharedDataRegistry

    @Component
    public class ProducerWorker extends AbstractWorker {
    
        @Autowired
        private SharedDataRegistry registry;
    
        @Override
        protected void doProcess() {
            // Publier des données
            registry.put("orders.pending.count", pendingOrders.size());
            registry.incrementSequence("orders.total");
        }
    }
    
    @Component
    public class ConsumerWorker extends AbstractWorker {
    
        @Autowired
        private SharedDataRegistry registry;
    
        @Override
        protected void doProcess() {
            // Lire les données
            int pending = registry.getInt("orders.pending.count").orElse(0);
            if (pending > 0) {
                processOrders();
            }
        }
    }
    

    6.2 Via KvBus

    @Component
    public class OrderWorker extends AbstractWorker {
    
        @Autowired
        private KvBus kvBus;
    
        @Override
        protected void doProcess() {
            // Stocker l'état partagé (même entre instances)
            kvBus.put("order:" + orderId, orderJson);
        }
    }
    

    6.3 Via Events

    @Component
    public class EventProducerWorker extends AbstractWorker {
    
        @Autowired
        private ApplicationEventPublisher eventPublisher;
    
        @Override
        protected void doProcess() {
            // Publier un événement Spring
            eventPublisher.publishEvent(new OrderCreatedEvent(order));
        }
    }
    
    @Component
    public class EventConsumerWorker extends AbstractWorker {
    
        @EventListener
        public void onOrderCreated(OrderCreatedEvent event) {
            // Réagir à l'événement
            processOrder(event.getOrder());
        }
    }
    

    7. Workers et TechDB (V4)

    7.1 Persistance d’état

    @Component
    public class KafkaConsumerWorker extends AbstractWorker {
    
        @Autowired
        private TechDbManager techDb;
    
        private long currentOffset;
    
        @Override
        protected void doInitialize() {
            // Restaurer l'offset au démarrage
            currentOffset = techDb.getOffset("kafka", "my-topic-0")
                .orElse(0L);
            log.info("Starting from offset: {}", currentOffset);
        }
    
        @Override
        protected void doProcess() {
            // Traiter les messages
            List<Message> messages = consume(currentOffset);
            for (Message msg : messages) {
                process(msg);
                currentOffset = msg.getOffset();
            }
    
            // Persister périodiquement
            if (currentOffset % 1000 == 0) {
                techDb.saveOffset("kafka", "my-topic-0", currentOffset, null);
            }
        }
    
        @Override
        protected void doStop() {
            // Sauvegarder l'offset final
            techDb.saveOffset("kafka", "my-topic-0", currentOffset, null);
        }
    }
    

    7.2 État du worker

    @Component
    public class BatchWorker extends AbstractWorker {
    
        @Autowired
        private TechDbManager techDb;
    
        @Override
        protected void doProcess() {
            // Mettre à jour l'état
            techDb.saveWorkerState(getName(), "PROCESSING",
                Map.of(
                    "currentBatch", currentBatchId,
                    "progress", progress
                ));
    
            // Traitement...
    
            techDb.saveWorkerState(getName(), "IDLE", Map.of());
        }
    }
    

    8. Patterns courants

    8.1 Worker avec retry

    @Component
    public class RetryableWorker extends AbstractWorker {
    
        @Autowired
        private RetryTemplate retryTemplate;
    
        @Override
        protected void doProcess() {
            retryTemplate.execute(context -> {
                processWithRetry();
                return null;
            });
        }
    }
    

    8.2 Worker avec circuit breaker

    @Component
    public class ResilientWorker extends AbstractWorker {
    
        @Autowired
        private CircuitBreakerTemplate circuitBreaker;
    
        @Override
        protected void doProcess() {
            circuitBreaker.execute("external-api", () -> {
                callExternalApi();
            });
        }
    }
    

    8.3 Worker batch

    @Component
    public class BatchWorker extends AbstractWorker {
    
        private final int BATCH_SIZE = 100;
    
        @Override
        protected void doProcess() {
            List<Item> batch = fetchBatch(BATCH_SIZE);
            if (batch.isEmpty()) {
                return;
            }
    
            for (Item item : batch) {
                processItem(item);
                incrementProcessed();
            }
        }
    }
    

    9. Tests

    9.1 Test unitaire

    @ExtendWith(MockitoExtension.class)
    class SimpleWorkerTest {
    
        @InjectMocks
        private SimpleWorker worker;
    
        @Test
        void shouldInitialize() {
            worker.initialize();
            // Assertions...
        }
    
        @Test
        void shouldProcessItems() {
            worker.initialize();
            worker.start();
    
            worker.doWork();
    
            Map<String, Object> stats = worker.getStats();
            assertEquals(1L, stats.get("processedCount"));
        }
    
        @Test
        void shouldStopGracefully() {
            worker.initialize();
            worker.start();
            worker.stop();
    
            assertFalse(worker.isHealthy());
        }
    }
    

    9.2 Test d’intégration

    @SpringBootTest
    class WorkerIntegrationTest {
    
        @Autowired
        private List<Worker> workers;
    
        @Test
        void allWorkersShouldBeHealthyAfterStart() {
            workers.forEach(Worker::initialize);
            workers.forEach(Worker::start);
    
            workers.forEach(w -> assertTrue(w.isHealthy(),
                "Worker " + w.getName() + " should be healthy"));
        }
    }
    

    10. Auto-Restart des Workers

    Le MOP surveille automatiquement la sante des workers et peut les redemarrer en cas d’echec.

    Fonctionnement

    1. Detection : Le MOP verifie worker.isHealthy() a chaque cycle de la boucle principale
    2. Compteur : Un compteur d’echecs consecutifs est maintenu pour chaque worker
    3. Seuil : Apres 3 echecs consecutifs (configurable), le worker est redemarre
    4. Restart : Sequence stop()initialize()start() → replanification doWork()
    5. Reset : Le compteur est remis a zero si le worker redevient healthy

    Logs associes

    [step:worker_auto_restart] Worker 'xxx' unhealthy 3 fois, tentative de redemarrage
    [step:worker_restarted] Worker 'xxx' redemarre avec succes
    [step:worker_restart_failed] Echec du redemarrage de 'xxx': <error>
    

    Implementation dans le Worker

    Pour beneficier de l’auto-restart, le worker doit :

    1. Retourner false dans isHealthy() en cas de probleme
    2. Supporter un cycle stop()initialize()start()
    3. Reinitialiser son etat interne dans initialize()
    @Override
    public boolean isHealthy() {
        // Retourner false declenche le compteur d'echecs
        return lastApiCallSuccessful && !hasConsecutiveErrors;
    }
    

    Workers exclus

    Les workers built-in du socle (http_worker, control_worker, etc.) ne sont pas soumis a l’auto-restart car ils sont geres par le Supervisor.

    11. Workers Event-Driven

    Les Event-Driven Workers sont des workers passifs declenches par des evenements externes (Kafka, queues, CDC, etc.).

    Classe de base

    package eu.lmvi.socle.worker.event;
    
    public abstract class AbstractEventDrivenWorker<T> implements Worker {
    
        // Concurrence configurable
        protected AbstractEventDrivenWorker(int concurrency) { ... }
    
        // Mode PASSIVE automatique
        @Override
        public final boolean isPassive() { return true; }
    
        @Override
        public final String getSchedule() { return "PASSIVE"; }
    
        // Methodes abstraites a implementer
        protected abstract T pollEvent() throws InterruptedException;
        protected abstract void processEvent(T event);
    
        // Hooks optionnels
        protected void onInitialize() { }
        protected void onStarted() { }
        protected void onStopping() { }
        protected void onStopped() { }
        protected void handleError(T event, Exception e, int workerId) { }
        public long getBacklog() { return 0; }
    }
    

    Exemple d’implementation

    @Component
    public class KafkaEventWorker extends AbstractEventDrivenWorker<ConsumerRecord<String, String>> {
    
        private final BlockingQueue<ConsumerRecord<String, String>> eventQueue = new LinkedBlockingQueue<>();
    
        public KafkaEventWorker() {
            super(4); // 4 threads concurrents
        }
    
        @Override
        public String getName() {
            return "kafka_event_worker";
        }
    
        @Override
        protected ConsumerRecord<String, String> pollEvent() throws InterruptedException {
            return eventQueue.poll(100, TimeUnit.MILLISECONDS);
        }
    
        @Override
        protected void processEvent(ConsumerRecord<String, String> event) {
            // Traitement de l'evenement
            log.info("Processing: {}", event.value());
        }
    
        @Override
        public long getBacklog() {
            return eventQueue.size();
        }
    }
    

    Metriques standardisees

    Les Event-Driven Workers exposent des metriques compatibles avec le StatusDashboard :

    Cle Type Description
    state String "running" ou "stopped"
    execution_count long Nombre d’evenements traites
    errors_count long Nombre d’erreurs
    last_execution String ISO-8601 du dernier traitement
    schedule String Toujours "PASSIVE"
    messages_processed long Alias de execution_count
    throughput_per_sec double Debit calcule
    backlog long Evenements en attente

    12. Convention des Stats Workers

    Pour une integration correcte avec le StatusDashboard et le WorkerActivityTracker, tous les workers doivent exposer des cles standardisees dans getStats().

    Cles obligatoires

    Cle Type Description
    state String "running" ou "stopped"
    execution_count long Nombre total d’executions
    errors_count long Nombre d’erreurs
    last_execution String/long Timestamp ISO-8601 ou epoch ms
    schedule String Mode: "PASSIVE", "INTERVAL", "CRON", ou expression cron

    Cles optionnelles

    Cle Type Description
    total_duration_ms long Duree totale cumulee
    avg_duration_ms double Duree moyenne par execution
    throughput_per_sec double Debit (ops/sec)
    messages_processed long Pour Event-Driven (alias execution_count)
    backlog long File d’attente

    Exemple d’implementation

    @Override
    public Map<String, Object> getStats() {
        Map<String, Object> stats = new HashMap<>();
    
        // Cles standardisees (obligatoires)
        stats.put("state", running ? "running" : "stopped");
        stats.put("execution_count", executionCount.get());
        stats.put("errors_count", errorCount.get());
        stats.put("last_execution", lastExecution != null
            ? lastExecution.toString()  // ISO-8601
            : null);
        stats.put("schedule", getSchedule() != null ? getSchedule() : "INTERVAL");
    
        // Cles optionnelles
        stats.put("total_duration_ms", totalDurationMs.get());
        stats.put("avg_duration_ms", executionCount.get() > 0
            ? (double) totalDurationMs.get() / executionCount.get()
            : 0.0);
    
        return stats;
    }
    

    13. JaninoWorker (Scripts Java Compiles)

    Le JaninoWorker permet d’executer du code Java compile dynamiquement a la volee. Contrairement au ScriptEngine (interprete), Janino compile le code en bytecode JVM pour des performances natives.

    13.1 Activation

    socle:
      janino:
        enabled: true
        scripts-path: ./repository/scripts/java
        reload-interval-ms: 300000  # 5 minutes
    

    13.2 Interfaces disponibles

    Les scripts doivent implementer une des interfaces :

    Interface Usage Methode
    Calculator<T> Calculs (frais, taxes) T calculate(Map<String, Object> context)
    Executable Execution generique Object execute(Map<String, Object> context)
    Validator Validations ValidationResult validate(Object input)

    13.3 Exemple de script

    // Fichier: repository/scripts/java/KrakenFeeCalculator.java
    
    import eu.lmvi.socle.janino.interfaces.Calculator;
    import java.math.BigDecimal;
    import java.math.RoundingMode;
    import java.util.Map;
    
    public class KrakenFeeCalculator implements Calculator<BigDecimal> {
    
        private static final BigDecimal FEE_RATE = new BigDecimal("0.0026");
    
        @Override
        public BigDecimal calculate(Map<String, Object> context) {
            BigDecimal amount = (BigDecimal) context.get("amount");
            return amount.multiply(FEE_RATE).setScale(8, RoundingMode.HALF_UP);
        }
    }
    

    13.4 Utilisation dans un Worker

    @Component
    public class TradingWorker implements Worker {
    
        @Autowired
        private JaninoWorker janinoWorker;
    
        @Override
        public void doWork() {
            Map<String, Object> context = Map.of(
                "amount", new BigDecimal("1000.00")
            );
    
            BigDecimal fee = janinoWorker.execute(
                "KrakenFeeCalculator",
                context,
                BigDecimal.class
            );
    
            log.info("Fee calculated: {}", fee);
        }
    }
    

    13.5 Acces direct au moteur

    @Autowired
    private JaninoWorker janinoWorker;
    
    // Compiler un script a la volee
    janinoWorker.compileScript("MyScript", sourceCode);
    
    // Verifier si compile
    boolean ready = janinoWorker.isScriptCompiled("MyScript");
    
    // Forcer le rechargement
    janinoWorker.forceReload();
    
    // Acces au moteur
    JaninoEngine engine = janinoWorker.getEngine();
    

    13.6 Securite

    Janino bloque l’acces aux packages dangereux :

    • java.io – Acces fichiers
    • java.net – Acces reseau
    • java.lang.reflect – Reflection
    • sun.*, com.sun.* – Classes internes

    13.7 Comparaison avec ScriptEngine

    Critere ScriptEngine JaninoWorker
    Langages JavaScript, BeanShell Java pur
    Performance Interprete Compile (natif JVM)
    Typage Dynamique Statique
    Hot reload Non Oui (automatique)
    Use case Prototypage, scripts simples Calculs haute perf

    14. Bonnes pratiques

    DO

    • Implémenter stop() pour un arrêt gracieux
    • Utiliser isHealthy() pour signaler les problèmes
    • Logger les transitions d’état
    • Gérer les exceptions dans doWork()
    • Utiliser des priorités pour les dépendances

    DON’T

    • Ne pas bloquer indéfiniment dans doWork()
    • Ne pas ignorer les signaux d’arrêt
    • Ne pas oublier de décrémenter les ressources dans stop()
    • Ne pas utiliser de variables statiques pour l’état

    15. Références

  • Socle V004 – Status Dashboard

    Socle V004 – Status Dashboard

    27 – Status Dashboard

    Version : 4.0.0 Package : eu.lmvi.socle.worker.status

    Introduction

    Le StatusDashboardWorker est un Worker integre au Socle V004 qui expose un dashboard HTML de supervision sur un port dedie. Il permet de visualiser en temps reel l’etat de l’application et de tous les Workers.

    Caracteristiques

    • Automatique : Active par defaut, aucun code a ajouter
    • Port dedie : 9374 (configurable)
    • Dashboard HTML : Interface web avec rafraichissement AJAX partiel
    • API JSON : Endpoints REST pour integration
    • Metriques d’activite : Throughput, duree, charge relative
    • Animation visuelle : Mise en evidence des valeurs modifiees

    Acces au Dashboard

    Une fois l’application demarree, le dashboard est accessible sur :

    http://localhost:9374/
    

    Configuration

    application.yml

    socle:
      status_dashboard:
        # Activer/desactiver le dashboard (defaut: true)
        enabled: true
    
        # Port du serveur HTTP (defaut: 9374)
        port: 9374
    
        # Adresse de bind (vide = toutes les interfaces)
        bind_address: ""
    
        # Intervalle de rafraichissement HTML en secondes (defaut: 5)
        refresh_interval: 5
    
        # Fenetre de calcul des metriques en secondes (defaut: 60)
        metrics_window: 60
    
        # Limite de requetes par seconde (defaut: 10)
        max_requests_per_second: 10
    
        # Activer l'API JSON (defaut: true)
        api_enabled: true
    

    Variables d’environnement

    Variable Description Defaut
    STATUS_DASHBOARD_ENABLED Activer le dashboard true
    STATUS_DASHBOARD_PORT Port HTTP 9374
    STATUS_DASHBOARD_BIND Adresse de bind (vide)
    STATUS_DASHBOARD_REFRESH Refresh interval (sec) 5
    STATUS_DASHBOARD_METRICS_WINDOW Fenetre metriques (sec) 60
    STATUS_DASHBOARD_MAX_RPS Max requetes/sec 10
    STATUS_DASHBOARD_API_ENABLED Activer API JSON true

    Rafraichissement AJAX

    Le dashboard utilise JavaScript pour mettre a jour uniquement les valeurs qui changent, sans recharger la page entiere.

    Fonctionnement

    1. Chargement initial : La page HTML complete est servie
    2. Rafraichissement periodique : JavaScript appelle /api/status et /api/workers
    3. Mise a jour selective : Seuls les elements dont la valeur a change sont modifies
    4. Animation visuelle : Les valeurs modifiees sont brievement mises en surbrillance (effet cyan)

    Avantages

    • Pas de rechargement complet de la page
    • Experience utilisateur fluide
    • Reduction de la bande passante
    • Conservation de l’etat de scroll

    Configuration de l’intervalle

    L’intervalle de rafraichissement AJAX correspond a refresh_interval :

    socle:
      status_dashboard:
        refresh_interval: 3  # Rafraichissement toutes les 3 secondes
    

    Endpoints HTTP

    Dashboard HTML

    Endpoint Methode Description
    / GET Page HTML du dashboard
    /index.html GET Alias pour /

    Health Check

    Endpoint Methode Description
    /health GET Status UP/DOWN en JSON

    Exemple de reponse :

    {"status":"UP"}
    

    API JSON

    Endpoint Methode Description
    /api/status GET Status global de l’application
    /api/workers GET Liste de tous les workers avec metriques
    /api/workers/{name} GET Metriques d’un worker specifique

    Donnees affichees

    Section : Status Global

    Donnee Description
    MOP State Etat du MainOrchestratorProcess (RUNNING, DRAINING, etc.)
    Uptime Temps depuis le demarrage
    Workers Health Nombre de workers healthy / total
    Total Activity Throughput agrege (ops/sec)

    Section : Worker Activity

    Barres visuelles montrant la charge relative de chaque Worker :

    cdc_kafka_worker    ████████████████████░░░░  85%  [HOT]
    http_worker         ██████████████░░░░░░░░░░  58%
    rule_engine         ████████░░░░░░░░░░░░░░░░  32%
    control_worker      ███░░░░░░░░░░░░░░░░░░░░░  12%
    maintenance_worker  █░░░░░░░░░░░░░░░░░░░░░░░   2%  [IDLE]
    

    Tags :

    • [HOT] : Worker avec charge > 80%
    • [IDLE] : Worker inactif
    • [PASSIVE] : Worker event-driven sans activite

    Section : Workers Detail

    Tableau detaille avec :

    Colonne Description
    Name Nom du worker
    State Running / Stopped
    Health OK / FAIL
    Mode PASSIVE / CRON / INTERVAL
    Executions Nombre total d’executions doWork()
    Avg Duration Duree moyenne d’execution
    Throughput Operations par seconde
    Last Activity Temps depuis derniere activite
    Errors Nombre d’erreurs

    Exemples API JSON

    GET /api/status

    {
      "timestamp": "2026-01-12T17:34:56.789Z",
      "application": {
        "name": "my-app",
        "environment": "PROD",
        "version": "4.0.0"
      },
      "mop": {
        "state": "RUNNING",
        "uptime_ms": 9252000,
        "uptime_human": "2h 34m 12s"
      },
      "workers": {
        "total": 6,
        "healthy": 6,
        "running": 6
      },
      "activity": {
        "total_throughput": 847.3,
        "metrics_window_sec": 60
      }
    }
    

    GET /api/workers

    {
      "timestamp": "2026-01-12T17:34:56.789Z",
      "workers": [
        {
          "name": "cdc_kafka_worker",
          "state": "running",
          "healthy": true,
          "schedule": "PASSIVE",
          "metrics": {
            "execution_count": 12847,
            "total_duration_ms": 29548,
            "avg_duration_ms": 2.3,
            "last_execution": "2026-01-12T17:34:55.123Z",
            "throughput_per_sec": 721.4,
            "errors_count": 3,
            "messages_processed": 45230
          },
          "relative_load": 0.85
        }
      ]
    }
    

    Securite

    Bind localhost uniquement (production)

    Pour limiter l’acces au dashboard en production :

    socle:
      status_dashboard:
        bind_address: "127.0.0.1"
    

    Desactiver en production

    socle:
      status_dashboard:
        enabled: false
    

    Ou via variable d’environnement :

    export STATUS_DASHBOARD_ENABLED=false
    

    Architecture

    ┌─────────────────────────────────────────────────────────────┐
    │                  StatusDashboardWorker                      │
    │                                                             │
    │  ┌─────────────────────┐    ┌─────────────────────────┐    │
    │  │ WorkerActivityTracker│    │ DashboardHtmlRenderer   │    │
    │  │ (collecte metriques) │    │ (genere HTML)           │    │
    │  └──────────┬──────────┘    └────────────┬────────────┘    │
    │             │                            │                  │
    │             └──────────┬─────────────────┘                  │
    │                        │                                    │
    │              ┌─────────▼─────────┐                          │
    │              │   MiniHttpServer  │                          │
    │              │   (port 9374)     │                          │
    │              └─────────┬─────────┘                          │
    └────────────────────────┼────────────────────────────────────┘
                             │
                             ▼
                        Browser / curl
    

    Composants

    Composant Responsabilite
    StatusDashboardWorker Worker principal, orchestre le dashboard
    WorkerActivityTracker Collecte et agregation des metriques
    MiniHttpServer Serveur HTTP leger (ServerSocket)
    DashboardHtmlRenderer Generation du HTML avec CSS inline

    Integration avec Monitoring

    Le dashboard peut etre integre avec des outils de monitoring existants :

    Prometheus / Grafana

    Utilisez l’endpoint /api/status pour collecter les metriques :

    # prometheus.yml
    scrape_configs:
      - job_name: 'socle-status'
        metrics_path: /api/status
        static_configs:
          - targets: ['localhost:9374']
    

    Health Checks (Kubernetes)

    # deployment.yaml
    livenessProbe:
      httpGet:
        path: /health
        port: 9374
      initialDelaySeconds: 30
      periodSeconds: 10
    

    Convention des Stats Workers

    Pour que le dashboard affiche correctement les metriques, les workers doivent exposer des cles standardisees dans getStats().

    Cles requises par WorkerActivityTracker

    Cle Type Utilisation
    state String Affichage Running/Stopped
    execution_count long Colonne Executions
    errors_count long Colonne Errors
    last_execution String/long Colonne Last Activity
    schedule String Colonne Mode

    Cles optionnelles

    Cle Type Utilisation
    total_duration_ms long Calcul Avg Duration
    avg_duration_ms double Colonne Avg Duration (prioritaire)
    throughput_per_sec double Colonne Throughput
    messages_processed long Fallback pour execution_count

    Note : Les workers heritant de AbstractEventDrivenWorker exposent automatiquement ces cles depuis la version 4.0.1.

    Voir 05-WORKERS.md section 12 pour les details d’implementation.

    Troubleshooting

    Le dashboard ne demarre pas

    Cause possible : Port deja utilise

    Solution :

    socle:
      status_dashboard:
        port: 9375  # Changer le port
    

    Metriques a zero

    Cause possible : Les workers sont en mode PASSIVE et n’ont pas encore traite d’evenements

    Solution : Normal pour les workers event-driven. Les metriques apparaitront des que des evenements seront traites.

    Dashboard lent

    Cause possible : Trop de workers ou refresh trop frequent

    Solution :

    socle:
      status_dashboard:
        refresh_interval: 10  # Augmenter l'intervalle
    

    Voir aussi

    Socle V004 – Status Dashboard

  • Socle V004 – Workers

    Socle V004 – Workers

    05 – Workers

    Version : 4.0.1 Date : 2026-01-13

    1. Introduction

    Les Workers sont les composants de traitement du Socle V4. Chaque Worker implémente une tâche spécifique et son cycle de vie est géré par le MOP (Main Orchestrator Process).

    Caractéristiques

    • Interface unique : Tous les workers implémentent Worker
    • Cycle de vie géré : Le MOP orchestre start/stop/doWork
    • Priorités : Ordre de démarrage/arrêt configurable
    • Scheduling : Support cron et intervalle
    • Health check : Supervision intégrée

    2. Interface Worker

    package eu.lmvi.socle.worker;
    
    public interface Worker {
    
        /**
         * Nom unique du worker
         */
        String getName();
    
        /**
         * Initialisation (appelé une fois au démarrage)
         */
        void initialize();
    
        /**
         * Démarrage du worker
         */
        void start();
    
        /**
         * Traitement principal (appelé cycliquement)
         */
        void doWork();
    
        /**
         * Arrêt gracieux
         */
        void stop();
    
        /**
         * État de santé
         */
        boolean isHealthy();
    
        /**
         * Statistiques du worker
         */
        Map<String, Object> getStats();
    
        // === Priorités ===
    
        /**
         * Priorité au démarrage (plus petit = premier)
         */
        default int getStartPriority() {
            return 100;
        }
    
        /**
         * Priorité à l'arrêt (plus petit = premier)
         */
        default int getStopPriority() {
            return 100;
        }
    
        // === Scheduling ===
    
        /**
         * Expression cron (ou null si non schedulé)
         */
        default String getSchedule() {
            return null;
        }
    
        /**
         * Intervalle entre les cycles doWork() en ms
         * Valeurs recommandees : 5000 (5s), 10000 (10s), 30000 (30s)
         */
        default long getCycleIntervalMs() {
            return 5000; // 5 secondes par defaut
        }
    
        /**
         * Worker schedulé par cron ?
         */
        default boolean isScheduled() {
            return getSchedule() != null;
        }
    
        /**
         * Worker passif (ne fait rien dans doWork) ?
         */
        default boolean isPassive() {
            return false;
        }
    }
    

    3. Implémentation de base

    3.1 Worker simple

    package com.myapp.worker;
    
    import eu.lmvi.socle.worker.Worker;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import org.springframework.stereotype.Component;
    
    @Component
    public class SimpleWorker implements Worker {
    
        private static final Logger log = LoggerFactory.getLogger(SimpleWorker.class);
    
        private volatile boolean running = false;
        private long processedCount = 0;
    
        @Override
        public String getName() {
            return "simple-worker";
        }
    
        @Override
        public void initialize() {
            log.info("Initializing SimpleWorker");
            // Charger configuration, connexions, etc.
        }
    
        @Override
        public void start() {
            log.info("Starting SimpleWorker");
            running = true;
        }
    
        @Override
        public void doWork() {
            if (!running) return;
    
            try {
                // Traitement principal
                processedCount++;
                log.debug("Processing item #{}", processedCount);
            } catch (Exception e) {
                log.error("Error in doWork", e);
            }
        }
    
        @Override
        public void stop() {
            log.info("Stopping SimpleWorker");
            running = false;
        }
    
        @Override
        public boolean isHealthy() {
            return running;
        }
    
        @Override
        public Map<String, Object> getStats() {
            return Map.of(
                "running", running,
                "processedCount", processedCount
            );
        }
    }
    

    3.2 Worker avec priorité

    @Component
    public class DatabaseWorker implements Worker {
    
        @Override
        public String getName() {
            return "database-worker";
        }
    
        @Override
        public int getStartPriority() {
            return 10;  // Démarre en premier (connexion DB)
        }
    
        @Override
        public int getStopPriority() {
            return 90;  // S'arrête en dernier (flush des données)
        }
    
        // ... autres méthodes
    }
    

    3.3 Worker schedulé (cron)

    @Component
    public class ReportWorker implements Worker {
    
        @Override
        public String getName() {
            return "report-worker";
        }
    
        @Override
        public String getSchedule() {
            return "0 0 6 * * ?";  // Tous les jours à 6h
        }
    
        @Override
        public boolean isScheduled() {
            return true;
        }
    
        @Override
        public void doWork() {
            log.info("Generating daily report...");
            // Génération du rapport
        }
    
        // ... autres méthodes
    }
    

    3.4 Worker passif (HTTP)

    @Component
    public class ApiWorker implements Worker {
    
        @Override
        public String getName() {
            return "api-worker";
        }
    
        @Override
        public boolean isPassive() {
            return true;  // Pas de doWork() cyclique
        }
    
        @Override
        public void doWork() {
            // Ne fait rien - le traitement est déclenché par HTTP
        }
    
        // Les requêtes HTTP déclenchent le traitement via endpoints REST
    }
    

    4. AbstractWorker

    Le Socle fournit une classe de base qui simplifie l’implémentation :

    package eu.lmvi.socle.worker;
    
    public abstract class AbstractWorker implements Worker {
    
        protected final Logger log = LoggerFactory.getLogger(getClass());
        protected volatile boolean running = false;
        protected volatile boolean healthy = true;
        protected final AtomicLong processedCount = new AtomicLong(0);
        protected final AtomicLong errorCount = new AtomicLong(0);
        protected Instant lastActivity;
    
        @Override
        public void initialize() {
            log.info("[{}] Initializing", getName());
            doInitialize();
        }
    
        @Override
        public void start() {
            log.info("[{}] Starting", getName());
            running = true;
            doStart();
        }
    
        @Override
        public void stop() {
            log.info("[{}] Stopping", getName());
            running = false;
            doStop();
        }
    
        @Override
        public void doWork() {
            if (!running) return;
    
            try {
                doProcess();
                lastActivity = Instant.now();
            } catch (Exception e) {
                errorCount.incrementAndGet();
                handleError(e);
            }
        }
    
        @Override
        public boolean isHealthy() {
            return running && healthy;
        }
    
        @Override
        public Map<String, Object> getStats() {
            return Map.of(
                "running", running,
                "healthy", healthy,
                "processedCount", processedCount.get(),
                "errorCount", errorCount.get(),
                "lastActivity", lastActivity != null ? lastActivity.toString() : "never"
            );
        }
    
        // === Méthodes à implémenter ===
    
        protected void doInitialize() {}
        protected void doStart() {}
        protected abstract void doProcess();
        protected void doStop() {}
    
        protected void handleError(Exception e) {
            log.error("[{}] Error in doWork", getName(), e);
        }
    
        protected void incrementProcessed() {
            processedCount.incrementAndGet();
        }
    }
    

    Utilisation

    @Component
    public class OrderWorker extends AbstractWorker {
    
        @Override
        public String getName() {
            return "order-worker";
        }
    
        @Override
        protected void doInitialize() {
            // Initialisation spécifique
        }
    
        @Override
        protected void doProcess() {
            // Traitement principal
            processOrders();
            incrementProcessed();
        }
    
        private void processOrders() {
            // ...
        }
    }
    

    5. Cycle de vie

    5.1 Séquence de démarrage

    1. MOP.start()
    2. Pour chaque worker (trié par startPriority ASC) :
       a. worker.initialize()
       b. worker.start()
       c. Enregistrement dans Supervisor
    3. Boucle principale :
       - Pour chaque worker non-schedulé, non-passif :
         - worker.doWork()
         - Sleep(worker.getCycleIntervalMs())
    

    5.2 Séquence d’arrêt

    1. Signal SIGTERM reçu
    2. MOP.gracefulShutdown()
    3. Pour chaque worker (trié par stopPriority ASC) :
       a. worker.stop()
       b. Attendre terminaison
    4. Cleanup final
    

    5.3 Diagramme

                     ┌──────────────┐
                     │   CREATED    │
                     └──────┬───────┘
                            │ initialize()
                            ▼
                     ┌──────────────┐
                     │ INITIALIZED  │
                     └──────┬───────┘
                            │ start()
                            ▼
              ┌─────────────────────────────┐
              │          RUNNING            │
              │                             │
              │  ┌──────────────────────┐   │
              │  │   doWork() loop      │   │
              │  │   (si non-passif)    │   │
              │  └──────────────────────┘   │
              │                             │
              └─────────────┬───────────────┘
                            │ stop()
                            ▼
                     ┌──────────────┐
                     │   STOPPED    │
                     └──────────────┘
    

    6. Communication entre Workers

    6.1 Via SharedDataRegistry

    @Component
    public class ProducerWorker extends AbstractWorker {
    
        @Autowired
        private SharedDataRegistry registry;
    
        @Override
        protected void doProcess() {
            // Publier des données
            registry.put("orders.pending.count", pendingOrders.size());
            registry.incrementSequence("orders.total");
        }
    }
    
    @Component
    public class ConsumerWorker extends AbstractWorker {
    
        @Autowired
        private SharedDataRegistry registry;
    
        @Override
        protected void doProcess() {
            // Lire les données
            int pending = registry.getInt("orders.pending.count").orElse(0);
            if (pending > 0) {
                processOrders();
            }
        }
    }
    

    6.2 Via KvBus

    @Component
    public class OrderWorker extends AbstractWorker {
    
        @Autowired
        private KvBus kvBus;
    
        @Override
        protected void doProcess() {
            // Stocker l'état partagé (même entre instances)
            kvBus.put("order:" + orderId, orderJson);
        }
    }
    

    6.3 Via Events

    @Component
    public class EventProducerWorker extends AbstractWorker {
    
        @Autowired
        private ApplicationEventPublisher eventPublisher;
    
        @Override
        protected void doProcess() {
            // Publier un événement Spring
            eventPublisher.publishEvent(new OrderCreatedEvent(order));
        }
    }
    
    @Component
    public class EventConsumerWorker extends AbstractWorker {
    
        @EventListener
        public void onOrderCreated(OrderCreatedEvent event) {
            // Réagir à l'événement
            processOrder(event.getOrder());
        }
    }
    

    7. Workers et TechDB (V4)

    7.1 Persistance d’état

    @Component
    public class KafkaConsumerWorker extends AbstractWorker {
    
        @Autowired
        private TechDbManager techDb;
    
        private long currentOffset;
    
        @Override
        protected void doInitialize() {
            // Restaurer l'offset au démarrage
            currentOffset = techDb.getOffset("kafka", "my-topic-0")
                .orElse(0L);
            log.info("Starting from offset: {}", currentOffset);
        }
    
        @Override
        protected void doProcess() {
            // Traiter les messages
            List<Message> messages = consume(currentOffset);
            for (Message msg : messages) {
                process(msg);
                currentOffset = msg.getOffset();
            }
    
            // Persister périodiquement
            if (currentOffset % 1000 == 0) {
                techDb.saveOffset("kafka", "my-topic-0", currentOffset, null);
            }
        }
    
        @Override
        protected void doStop() {
            // Sauvegarder l'offset final
            techDb.saveOffset("kafka", "my-topic-0", currentOffset, null);
        }
    }
    

    7.2 État du worker

    @Component
    public class BatchWorker extends AbstractWorker {
    
        @Autowired
        private TechDbManager techDb;
    
        @Override
        protected void doProcess() {
            // Mettre à jour l'état
            techDb.saveWorkerState(getName(), "PROCESSING",
                Map.of(
                    "currentBatch", currentBatchId,
                    "progress", progress
                ));
    
            // Traitement...
    
            techDb.saveWorkerState(getName(), "IDLE", Map.of());
        }
    }
    

    8. Patterns courants

    8.1 Worker avec retry

    @Component
    public class RetryableWorker extends AbstractWorker {
    
        @Autowired
        private RetryTemplate retryTemplate;
    
        @Override
        protected void doProcess() {
            retryTemplate.execute(context -> {
                processWithRetry();
                return null;
            });
        }
    }
    

    8.2 Worker avec circuit breaker

    @Component
    public class ResilientWorker extends AbstractWorker {
    
        @Autowired
        private CircuitBreakerTemplate circuitBreaker;
    
        @Override
        protected void doProcess() {
            circuitBreaker.execute("external-api", () -> {
                callExternalApi();
            });
        }
    }
    

    8.3 Worker batch

    @Component
    public class BatchWorker extends AbstractWorker {
    
        private final int BATCH_SIZE = 100;
    
        @Override
        protected void doProcess() {
            List<Item> batch = fetchBatch(BATCH_SIZE);
            if (batch.isEmpty()) {
                return;
            }
    
            for (Item item : batch) {
                processItem(item);
                incrementProcessed();
            }
        }
    }
    

    9. Tests

    9.1 Test unitaire

    @ExtendWith(MockitoExtension.class)
    class SimpleWorkerTest {
    
        @InjectMocks
        private SimpleWorker worker;
    
        @Test
        void shouldInitialize() {
            worker.initialize();
            // Assertions...
        }
    
        @Test
        void shouldProcessItems() {
            worker.initialize();
            worker.start();
    
            worker.doWork();
    
            Map<String, Object> stats = worker.getStats();
            assertEquals(1L, stats.get("processedCount"));
        }
    
        @Test
        void shouldStopGracefully() {
            worker.initialize();
            worker.start();
            worker.stop();
    
            assertFalse(worker.isHealthy());
        }
    }
    

    9.2 Test d’intégration

    @SpringBootTest
    class WorkerIntegrationTest {
    
        @Autowired
        private List<Worker> workers;
    
        @Test
        void allWorkersShouldBeHealthyAfterStart() {
            workers.forEach(Worker::initialize);
            workers.forEach(Worker::start);
    
            workers.forEach(w -> assertTrue(w.isHealthy(),
                "Worker " + w.getName() + " should be healthy"));
        }
    }
    

    10. Auto-Restart des Workers

    Le MOP surveille automatiquement la sante des workers et peut les redemarrer en cas d’echec.

    Fonctionnement

    1. Detection : Le MOP verifie worker.isHealthy() a chaque cycle de la boucle principale
    2. Compteur : Un compteur d’echecs consecutifs est maintenu pour chaque worker
    3. Seuil : Apres 3 echecs consecutifs (configurable), le worker est redemarre
    4. Restart : Sequence stop()initialize()start() → replanification doWork()
    5. Reset : Le compteur est remis a zero si le worker redevient healthy

    Logs associes

    [step:worker_auto_restart] Worker 'xxx' unhealthy 3 fois, tentative de redemarrage
    [step:worker_restarted] Worker 'xxx' redemarre avec succes
    [step:worker_restart_failed] Echec du redemarrage de 'xxx': <error>
    

    Implementation dans le Worker

    Pour beneficier de l’auto-restart, le worker doit :

    1. Retourner false dans isHealthy() en cas de probleme
    2. Supporter un cycle stop()initialize()start()
    3. Reinitialiser son etat interne dans initialize()
    @Override
    public boolean isHealthy() {
        // Retourner false declenche le compteur d'echecs
        return lastApiCallSuccessful && !hasConsecutiveErrors;
    }
    

    Workers exclus

    Les workers built-in du socle (http_worker, control_worker, etc.) ne sont pas soumis a l’auto-restart car ils sont geres par le Supervisor.

    11. Workers Event-Driven

    Les Event-Driven Workers sont des workers passifs declenches par des evenements externes (Kafka, queues, CDC, etc.).

    Classe de base

    package eu.lmvi.socle.worker.event;
    
    public abstract class AbstractEventDrivenWorker<T> implements Worker {
    
        // Concurrence configurable
        protected AbstractEventDrivenWorker(int concurrency) { ... }
    
        // Mode PASSIVE automatique
        @Override
        public final boolean isPassive() { return true; }
    
        @Override
        public final String getSchedule() { return "PASSIVE"; }
    
        // Methodes abstraites a implementer
        protected abstract T pollEvent() throws InterruptedException;
        protected abstract void processEvent(T event);
    
        // Hooks optionnels
        protected void onInitialize() { }
        protected void onStarted() { }
        protected void onStopping() { }
        protected void onStopped() { }
        protected void handleError(T event, Exception e, int workerId) { }
        public long getBacklog() { return 0; }
    }
    

    Exemple d’implementation

    @Component
    public class KafkaEventWorker extends AbstractEventDrivenWorker<ConsumerRecord<String, String>> {
    
        private final BlockingQueue<ConsumerRecord<String, String>> eventQueue = new LinkedBlockingQueue<>();
    
        public KafkaEventWorker() {
            super(4); // 4 threads concurrents
        }
    
        @Override
        public String getName() {
            return "kafka_event_worker";
        }
    
        @Override
        protected ConsumerRecord<String, String> pollEvent() throws InterruptedException {
            return eventQueue.poll(100, TimeUnit.MILLISECONDS);
        }
    
        @Override
        protected void processEvent(ConsumerRecord<String, String> event) {
            // Traitement de l'evenement
            log.info("Processing: {}", event.value());
        }
    
        @Override
        public long getBacklog() {
            return eventQueue.size();
        }
    }
    

    Metriques standardisees

    Les Event-Driven Workers exposent des metriques compatibles avec le StatusDashboard :

    Cle Type Description
    state String "running" ou "stopped"
    execution_count long Nombre d’evenements traites
    errors_count long Nombre d’erreurs
    last_execution String ISO-8601 du dernier traitement
    schedule String Toujours "PASSIVE"
    messages_processed long Alias de execution_count
    throughput_per_sec double Debit calcule
    backlog long Evenements en attente

    12. Convention des Stats Workers

    Pour une integration correcte avec le StatusDashboard et le WorkerActivityTracker, tous les workers doivent exposer des cles standardisees dans getStats().

    Cles obligatoires

    Cle Type Description
    state String "running" ou "stopped"
    execution_count long Nombre total d’executions
    errors_count long Nombre d’erreurs
    last_execution String/long Timestamp ISO-8601 ou epoch ms
    schedule String Mode: "PASSIVE", "INTERVAL", "CRON", ou expression cron

    Cles optionnelles

    Cle Type Description
    total_duration_ms long Duree totale cumulee
    avg_duration_ms double Duree moyenne par execution
    throughput_per_sec double Debit (ops/sec)
    messages_processed long Pour Event-Driven (alias execution_count)
    backlog long File d’attente

    Exemple d’implementation

    @Override
    public Map<String, Object> getStats() {
        Map<String, Object> stats = new HashMap<>();
    
        // Cles standardisees (obligatoires)
        stats.put("state", running ? "running" : "stopped");
        stats.put("execution_count", executionCount.get());
        stats.put("errors_count", errorCount.get());
        stats.put("last_execution", lastExecution != null
            ? lastExecution.toString()  // ISO-8601
            : null);
        stats.put("schedule", getSchedule() != null ? getSchedule() : "INTERVAL");
    
        // Cles optionnelles
        stats.put("total_duration_ms", totalDurationMs.get());
        stats.put("avg_duration_ms", executionCount.get() > 0
            ? (double) totalDurationMs.get() / executionCount.get()
            : 0.0);
    
        return stats;
    }
    

    13. JaninoWorker (Scripts Java Compiles)

    Le JaninoWorker permet d’executer du code Java compile dynamiquement a la volee. Contrairement au ScriptEngine (interprete), Janino compile le code en bytecode JVM pour des performances natives.

    13.1 Activation

    socle:
      janino:
        enabled: true
        scripts-path: ./repository/scripts/java
        reload-interval-ms: 300000  # 5 minutes
    

    13.2 Interfaces disponibles

    Les scripts doivent implementer une des interfaces :

    Interface Usage Methode
    Calculator<T> Calculs (frais, taxes) T calculate(Map<String, Object> context)
    Executable Execution generique Object execute(Map<String, Object> context)
    Validator Validations ValidationResult validate(Object input)

    13.3 Exemple de script

    // Fichier: repository/scripts/java/KrakenFeeCalculator.java
    
    import eu.lmvi.socle.janino.interfaces.Calculator;
    import java.math.BigDecimal;
    import java.math.RoundingMode;
    import java.util.Map;
    
    public class KrakenFeeCalculator implements Calculator<BigDecimal> {
    
        private static final BigDecimal FEE_RATE = new BigDecimal("0.0026");
    
        @Override
        public BigDecimal calculate(Map<String, Object> context) {
            BigDecimal amount = (BigDecimal) context.get("amount");
            return amount.multiply(FEE_RATE).setScale(8, RoundingMode.HALF_UP);
        }
    }
    

    13.4 Utilisation dans un Worker

    @Component
    public class TradingWorker implements Worker {
    
        @Autowired
        private JaninoWorker janinoWorker;
    
        @Override
        public void doWork() {
            Map<String, Object> context = Map.of(
                "amount", new BigDecimal("1000.00")
            );
    
            BigDecimal fee = janinoWorker.execute(
                "KrakenFeeCalculator",
                context,
                BigDecimal.class
            );
    
            log.info("Fee calculated: {}", fee);
        }
    }
    

    13.5 Acces direct au moteur

    @Autowired
    private JaninoWorker janinoWorker;
    
    // Compiler un script a la volee
    janinoWorker.compileScript("MyScript", sourceCode);
    
    // Verifier si compile
    boolean ready = janinoWorker.isScriptCompiled("MyScript");
    
    // Forcer le rechargement
    janinoWorker.forceReload();
    
    // Acces au moteur
    JaninoEngine engine = janinoWorker.getEngine();
    

    13.6 Securite

    Janino bloque l’acces aux packages dangereux :

    • java.io – Acces fichiers
    • java.net – Acces reseau
    • java.lang.reflect – Reflection
    • sun.*, com.sun.* – Classes internes

    13.7 Comparaison avec ScriptEngine

    Critere ScriptEngine JaninoWorker
    Langages JavaScript, BeanShell Java pur
    Performance Interprete Compile (natif JVM)
    Typage Dynamique Statique
    Hot reload Non Oui (automatique)
    Use case Prototypage, scripts simples Calculs haute perf

    14. Bonnes pratiques

    DO

    • Implémenter stop() pour un arrêt gracieux
    • Utiliser isHealthy() pour signaler les problèmes
    • Logger les transitions d’état
    • Gérer les exceptions dans doWork()
    • Utiliser des priorités pour les dépendances

    DON’T

    • Ne pas bloquer indéfiniment dans doWork()
    • Ne pas ignorer les signaux d’arrêt
    • Ne pas oublier de décrémenter les ressources dans stop()
    • Ne pas utiliser de variables statiques pour l’état

    15. Références

  • Socle V004 – Status Dashboard

    Socle V004 – Status Dashboard

    27 – Status Dashboard

    Version : 4.0.0 Package : eu.lmvi.socle.worker.status

    Introduction

    Le StatusDashboardWorker est un Worker integre au Socle V004 qui expose un dashboard HTML de supervision sur un port dedie. Il permet de visualiser en temps reel l’etat de l’application et de tous les Workers.

    Caracteristiques

    • Automatique : Active par defaut, aucun code a ajouter
    • Port dedie : 9374 (configurable)
    • Dashboard HTML : Interface web avec rafraichissement AJAX partiel
    • API JSON : Endpoints REST pour integration
    • Metriques d’activite : Throughput, duree, charge relative
    • Animation visuelle : Mise en evidence des valeurs modifiees

    Acces au Dashboard

    Une fois l’application demarree, le dashboard est accessible sur :

    http://localhost:9374/
    

    Configuration

    application.yml

    socle:
      status_dashboard:
        # Activer/desactiver le dashboard (defaut: true)
        enabled: true
    
        # Port du serveur HTTP (defaut: 9374)
        port: 9374
    
        # Adresse de bind (vide = toutes les interfaces)
        bind_address: ""
    
        # Intervalle de rafraichissement HTML en secondes (defaut: 5)
        refresh_interval: 5
    
        # Fenetre de calcul des metriques en secondes (defaut: 60)
        metrics_window: 60
    
        # Limite de requetes par seconde (defaut: 10)
        max_requests_per_second: 10
    
        # Activer l'API JSON (defaut: true)
        api_enabled: true
    

    Variables d’environnement

    Variable Description Defaut
    STATUS_DASHBOARD_ENABLED Activer le dashboard true
    STATUS_DASHBOARD_PORT Port HTTP 9374
    STATUS_DASHBOARD_BIND Adresse de bind (vide)
    STATUS_DASHBOARD_REFRESH Refresh interval (sec) 5
    STATUS_DASHBOARD_METRICS_WINDOW Fenetre metriques (sec) 60
    STATUS_DASHBOARD_MAX_RPS Max requetes/sec 10
    STATUS_DASHBOARD_API_ENABLED Activer API JSON true

    Rafraichissement AJAX

    Le dashboard utilise JavaScript pour mettre a jour uniquement les valeurs qui changent, sans recharger la page entiere.

    Fonctionnement

    1. Chargement initial : La page HTML complete est servie
    2. Rafraichissement periodique : JavaScript appelle /api/status et /api/workers
    3. Mise a jour selective : Seuls les elements dont la valeur a change sont modifies
    4. Animation visuelle : Les valeurs modifiees sont brievement mises en surbrillance (effet cyan)

    Avantages

    • Pas de rechargement complet de la page
    • Experience utilisateur fluide
    • Reduction de la bande passante
    • Conservation de l’etat de scroll

    Configuration de l’intervalle

    L’intervalle de rafraichissement AJAX correspond a refresh_interval :

    socle:
      status_dashboard:
        refresh_interval: 3  # Rafraichissement toutes les 3 secondes
    

    Endpoints HTTP

    Dashboard HTML

    Endpoint Methode Description
    / GET Page HTML du dashboard
    /index.html GET Alias pour /

    Health Check

    Endpoint Methode Description
    /health GET Status UP/DOWN en JSON

    Exemple de reponse :

    {"status":"UP"}
    

    API JSON

    Endpoint Methode Description
    /api/status GET Status global de l’application
    /api/workers GET Liste de tous les workers avec metriques
    /api/workers/{name} GET Metriques d’un worker specifique

    Donnees affichees

    Section : Status Global

    Donnee Description
    MOP State Etat du MainOrchestratorProcess (RUNNING, DRAINING, etc.)
    Uptime Temps depuis le demarrage
    Workers Health Nombre de workers healthy / total
    Total Activity Throughput agrege (ops/sec)

    Section : Worker Activity

    Barres visuelles montrant la charge relative de chaque Worker :

    cdc_kafka_worker    ████████████████████░░░░  85%  [HOT]
    http_worker         ██████████████░░░░░░░░░░  58%
    rule_engine         ████████░░░░░░░░░░░░░░░░  32%
    control_worker      ███░░░░░░░░░░░░░░░░░░░░░  12%
    maintenance_worker  █░░░░░░░░░░░░░░░░░░░░░░░   2%  [IDLE]
    

    Tags :

    • [HOT] : Worker avec charge > 80%
    • [IDLE] : Worker inactif
    • [PASSIVE] : Worker event-driven sans activite

    Section : Workers Detail

    Tableau detaille avec :

    Colonne Description
    Name Nom du worker
    State Running / Stopped
    Health OK / FAIL
    Mode PASSIVE / CRON / INTERVAL
    Executions Nombre total d’executions doWork()
    Avg Duration Duree moyenne d’execution
    Throughput Operations par seconde
    Last Activity Temps depuis derniere activite
    Errors Nombre d’erreurs

    Exemples API JSON

    GET /api/status

    {
      "timestamp": "2026-01-12T17:34:56.789Z",
      "application": {
        "name": "my-app",
        "environment": "PROD",
        "version": "4.0.0"
      },
      "mop": {
        "state": "RUNNING",
        "uptime_ms": 9252000,
        "uptime_human": "2h 34m 12s"
      },
      "workers": {
        "total": 6,
        "healthy": 6,
        "running": 6
      },
      "activity": {
        "total_throughput": 847.3,
        "metrics_window_sec": 60
      }
    }
    

    GET /api/workers

    {
      "timestamp": "2026-01-12T17:34:56.789Z",
      "workers": [
        {
          "name": "cdc_kafka_worker",
          "state": "running",
          "healthy": true,
          "schedule": "PASSIVE",
          "metrics": {
            "execution_count": 12847,
            "total_duration_ms": 29548,
            "avg_duration_ms": 2.3,
            "last_execution": "2026-01-12T17:34:55.123Z",
            "throughput_per_sec": 721.4,
            "errors_count": 3,
            "messages_processed": 45230
          },
          "relative_load": 0.85
        }
      ]
    }
    

    Securite

    Bind localhost uniquement (production)

    Pour limiter l’acces au dashboard en production :

    socle:
      status_dashboard:
        bind_address: "127.0.0.1"
    

    Desactiver en production

    socle:
      status_dashboard:
        enabled: false
    

    Ou via variable d’environnement :

    export STATUS_DASHBOARD_ENABLED=false
    

    Architecture

    ┌─────────────────────────────────────────────────────────────┐
    │                  StatusDashboardWorker                      │
    │                                                             │
    │  ┌─────────────────────┐    ┌─────────────────────────┐    │
    │  │ WorkerActivityTracker│    │ DashboardHtmlRenderer   │    │
    │  │ (collecte metriques) │    │ (genere HTML)           │    │
    │  └──────────┬──────────┘    └────────────┬────────────┘    │
    │             │                            │                  │
    │             └──────────┬─────────────────┘                  │
    │                        │                                    │
    │              ┌─────────▼─────────┐                          │
    │              │   MiniHttpServer  │                          │
    │              │   (port 9374)     │                          │
    │              └─────────┬─────────┘                          │
    └────────────────────────┼────────────────────────────────────┘
                             │
                             ▼
                        Browser / curl
    

    Composants

    Composant Responsabilite
    StatusDashboardWorker Worker principal, orchestre le dashboard
    WorkerActivityTracker Collecte et agregation des metriques
    MiniHttpServer Serveur HTTP leger (ServerSocket)
    DashboardHtmlRenderer Generation du HTML avec CSS inline

    Integration avec Monitoring

    Le dashboard peut etre integre avec des outils de monitoring existants :

    Prometheus / Grafana

    Utilisez l’endpoint /api/status pour collecter les metriques :

    # prometheus.yml
    scrape_configs:
      - job_name: 'socle-status'
        metrics_path: /api/status
        static_configs:
          - targets: ['localhost:9374']
    

    Health Checks (Kubernetes)

    # deployment.yaml
    livenessProbe:
      httpGet:
        path: /health
        port: 9374
      initialDelaySeconds: 30
      periodSeconds: 10
    

    Convention des Stats Workers

    Pour que le dashboard affiche correctement les metriques, les workers doivent exposer des cles standardisees dans getStats().

    Cles requises par WorkerActivityTracker

    Cle Type Utilisation
    state String Affichage Running/Stopped
    execution_count long Colonne Executions
    errors_count long Colonne Errors
    last_execution String/long Colonne Last Activity
    schedule String Colonne Mode

    Cles optionnelles

    Cle Type Utilisation
    total_duration_ms long Calcul Avg Duration
    avg_duration_ms double Colonne Avg Duration (prioritaire)
    throughput_per_sec double Colonne Throughput
    messages_processed long Fallback pour execution_count

    Note : Les workers heritant de AbstractEventDrivenWorker exposent automatiquement ces cles depuis la version 4.0.1.

    Voir 05-WORKERS.md section 12 pour les details d’implementation.

    Troubleshooting

    Le dashboard ne demarre pas

    Cause possible : Port deja utilise

    Solution :

    socle:
      status_dashboard:
        port: 9375  # Changer le port
    

    Metriques a zero

    Cause possible : Les workers sont en mode PASSIVE et n’ont pas encore traite d’evenements

    Solution : Normal pour les workers event-driven. Les metriques apparaitront des que des evenements seront traites.

    Dashboard lent

    Cause possible : Trop de workers ou refresh trop frequent

    Solution :

    socle:
      status_dashboard:
        refresh_interval: 10  # Augmenter l'intervalle
    

    Voir aussi

    Socle V004 – Status Dashboard

  • Socle V004 – Workers

    Socle V004 – Workers

    05 – Workers

    Version : 4.0.1 Date : 2026-01-13

    1. Introduction

    Les Workers sont les composants de traitement du Socle V4. Chaque Worker implémente une tâche spécifique et son cycle de vie est géré par le MOP (Main Orchestrator Process).

    Caractéristiques

    • Interface unique : Tous les workers implémentent Worker
    • Cycle de vie géré : Le MOP orchestre start/stop/doWork
    • Priorités : Ordre de démarrage/arrêt configurable
    • Scheduling : Support cron et intervalle
    • Health check : Supervision intégrée

    2. Interface Worker

    package eu.lmvi.socle.worker;
    
    public interface Worker {
    
        /**
         * Nom unique du worker
         */
        String getName();
    
        /**
         * Initialisation (appelé une fois au démarrage)
         */
        void initialize();
    
        /**
         * Démarrage du worker
         */
        void start();
    
        /**
         * Traitement principal (appelé cycliquement)
         */
        void doWork();
    
        /**
         * Arrêt gracieux
         */
        void stop();
    
        /**
         * État de santé
         */
        boolean isHealthy();
    
        /**
         * Statistiques du worker
         */
        Map<String, Object> getStats();
    
        // === Priorités ===
    
        /**
         * Priorité au démarrage (plus petit = premier)
         */
        default int getStartPriority() {
            return 100;
        }
    
        /**
         * Priorité à l'arrêt (plus petit = premier)
         */
        default int getStopPriority() {
            return 100;
        }
    
        // === Scheduling ===
    
        /**
         * Expression cron (ou null si non schedulé)
         */
        default String getSchedule() {
            return null;
        }
    
        /**
         * Intervalle entre les cycles doWork() en ms
         * Valeurs recommandees : 5000 (5s), 10000 (10s), 30000 (30s)
         */
        default long getCycleIntervalMs() {
            return 5000; // 5 secondes par defaut
        }
    
        /**
         * Worker schedulé par cron ?
         */
        default boolean isScheduled() {
            return getSchedule() != null;
        }
    
        /**
         * Worker passif (ne fait rien dans doWork) ?
         */
        default boolean isPassive() {
            return false;
        }
    }
    

    3. Implémentation de base

    3.1 Worker simple

    package com.myapp.worker;
    
    import eu.lmvi.socle.worker.Worker;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import org.springframework.stereotype.Component;
    
    @Component
    public class SimpleWorker implements Worker {
    
        private static final Logger log = LoggerFactory.getLogger(SimpleWorker.class);
    
        private volatile boolean running = false;
        private long processedCount = 0;
    
        @Override
        public String getName() {
            return "simple-worker";
        }
    
        @Override
        public void initialize() {
            log.info("Initializing SimpleWorker");
            // Charger configuration, connexions, etc.
        }
    
        @Override
        public void start() {
            log.info("Starting SimpleWorker");
            running = true;
        }
    
        @Override
        public void doWork() {
            if (!running) return;
    
            try {
                // Traitement principal
                processedCount++;
                log.debug("Processing item #{}", processedCount);
            } catch (Exception e) {
                log.error("Error in doWork", e);
            }
        }
    
        @Override
        public void stop() {
            log.info("Stopping SimpleWorker");
            running = false;
        }
    
        @Override
        public boolean isHealthy() {
            return running;
        }
    
        @Override
        public Map<String, Object> getStats() {
            return Map.of(
                "running", running,
                "processedCount", processedCount
            );
        }
    }
    

    3.2 Worker avec priorité

    @Component
    public class DatabaseWorker implements Worker {
    
        @Override
        public String getName() {
            return "database-worker";
        }
    
        @Override
        public int getStartPriority() {
            return 10;  // Démarre en premier (connexion DB)
        }
    
        @Override
        public int getStopPriority() {
            return 90;  // S'arrête en dernier (flush des données)
        }
    
        // ... autres méthodes
    }
    

    3.3 Worker schedulé (cron)

    @Component
    public class ReportWorker implements Worker {
    
        @Override
        public String getName() {
            return "report-worker";
        }
    
        @Override
        public String getSchedule() {
            return "0 0 6 * * ?";  // Tous les jours à 6h
        }
    
        @Override
        public boolean isScheduled() {
            return true;
        }
    
        @Override
        public void doWork() {
            log.info("Generating daily report...");
            // Génération du rapport
        }
    
        // ... autres méthodes
    }
    

    3.4 Worker passif (HTTP)

    @Component
    public class ApiWorker implements Worker {
    
        @Override
        public String getName() {
            return "api-worker";
        }
    
        @Override
        public boolean isPassive() {
            return true;  // Pas de doWork() cyclique
        }
    
        @Override
        public void doWork() {
            // Ne fait rien - le traitement est déclenché par HTTP
        }
    
        // Les requêtes HTTP déclenchent le traitement via endpoints REST
    }
    

    4. AbstractWorker

    Le Socle fournit une classe de base qui simplifie l’implémentation :

    package eu.lmvi.socle.worker;
    
    public abstract class AbstractWorker implements Worker {
    
        protected final Logger log = LoggerFactory.getLogger(getClass());
        protected volatile boolean running = false;
        protected volatile boolean healthy = true;
        protected final AtomicLong processedCount = new AtomicLong(0);
        protected final AtomicLong errorCount = new AtomicLong(0);
        protected Instant lastActivity;
    
        @Override
        public void initialize() {
            log.info("[{}] Initializing", getName());
            doInitialize();
        }
    
        @Override
        public void start() {
            log.info("[{}] Starting", getName());
            running = true;
            doStart();
        }
    
        @Override
        public void stop() {
            log.info("[{}] Stopping", getName());
            running = false;
            doStop();
        }
    
        @Override
        public void doWork() {
            if (!running) return;
    
            try {
                doProcess();
                lastActivity = Instant.now();
            } catch (Exception e) {
                errorCount.incrementAndGet();
                handleError(e);
            }
        }
    
        @Override
        public boolean isHealthy() {
            return running && healthy;
        }
    
        @Override
        public Map<String, Object> getStats() {
            return Map.of(
                "running", running,
                "healthy", healthy,
                "processedCount", processedCount.get(),
                "errorCount", errorCount.get(),
                "lastActivity", lastActivity != null ? lastActivity.toString() : "never"
            );
        }
    
        // === Méthodes à implémenter ===
    
        protected void doInitialize() {}
        protected void doStart() {}
        protected abstract void doProcess();
        protected void doStop() {}
    
        protected void handleError(Exception e) {
            log.error("[{}] Error in doWork", getName(), e);
        }
    
        protected void incrementProcessed() {
            processedCount.incrementAndGet();
        }
    }
    

    Utilisation

    @Component
    public class OrderWorker extends AbstractWorker {
    
        @Override
        public String getName() {
            return "order-worker";
        }
    
        @Override
        protected void doInitialize() {
            // Initialisation spécifique
        }
    
        @Override
        protected void doProcess() {
            // Traitement principal
            processOrders();
            incrementProcessed();
        }
    
        private void processOrders() {
            // ...
        }
    }
    

    5. Cycle de vie

    5.1 Séquence de démarrage

    1. MOP.start()
    2. Pour chaque worker (trié par startPriority ASC) :
       a. worker.initialize()
       b. worker.start()
       c. Enregistrement dans Supervisor
    3. Boucle principale :
       - Pour chaque worker non-schedulé, non-passif :
         - worker.doWork()
         - Sleep(worker.getCycleIntervalMs())
    

    5.2 Séquence d’arrêt

    1. Signal SIGTERM reçu
    2. MOP.gracefulShutdown()
    3. Pour chaque worker (trié par stopPriority ASC) :
       a. worker.stop()
       b. Attendre terminaison
    4. Cleanup final
    

    5.3 Diagramme

                     ┌──────────────┐
                     │   CREATED    │
                     └──────┬───────┘
                            │ initialize()
                            ▼
                     ┌──────────────┐
                     │ INITIALIZED  │
                     └──────┬───────┘
                            │ start()
                            ▼
              ┌─────────────────────────────┐
              │          RUNNING            │
              │                             │
              │  ┌──────────────────────┐   │
              │  │   doWork() loop      │   │
              │  │   (si non-passif)    │   │
              │  └──────────────────────┘   │
              │                             │
              └─────────────┬───────────────┘
                            │ stop()
                            ▼
                     ┌──────────────┐
                     │   STOPPED    │
                     └──────────────┘
    

    6. Communication entre Workers

    6.1 Via SharedDataRegistry

    @Component
    public class ProducerWorker extends AbstractWorker {
    
        @Autowired
        private SharedDataRegistry registry;
    
        @Override
        protected void doProcess() {
            // Publier des données
            registry.put("orders.pending.count", pendingOrders.size());
            registry.incrementSequence("orders.total");
        }
    }
    
    @Component
    public class ConsumerWorker extends AbstractWorker {
    
        @Autowired
        private SharedDataRegistry registry;
    
        @Override
        protected void doProcess() {
            // Lire les données
            int pending = registry.getInt("orders.pending.count").orElse(0);
            if (pending > 0) {
                processOrders();
            }
        }
    }
    

    6.2 Via KvBus

    @Component
    public class OrderWorker extends AbstractWorker {
    
        @Autowired
        private KvBus kvBus;
    
        @Override
        protected void doProcess() {
            // Stocker l'état partagé (même entre instances)
            kvBus.put("order:" + orderId, orderJson);
        }
    }
    

    6.3 Via Events

    @Component
    public class EventProducerWorker extends AbstractWorker {
    
        @Autowired
        private ApplicationEventPublisher eventPublisher;
    
        @Override
        protected void doProcess() {
            // Publier un événement Spring
            eventPublisher.publishEvent(new OrderCreatedEvent(order));
        }
    }
    
    @Component
    public class EventConsumerWorker extends AbstractWorker {
    
        @EventListener
        public void onOrderCreated(OrderCreatedEvent event) {
            // Réagir à l'événement
            processOrder(event.getOrder());
        }
    }
    

    7. Workers et TechDB (V4)

    7.1 Persistance d’état

    @Component
    public class KafkaConsumerWorker extends AbstractWorker {
    
        @Autowired
        private TechDbManager techDb;
    
        private long currentOffset;
    
        @Override
        protected void doInitialize() {
            // Restaurer l'offset au démarrage
            currentOffset = techDb.getOffset("kafka", "my-topic-0")
                .orElse(0L);
            log.info("Starting from offset: {}", currentOffset);
        }
    
        @Override
        protected void doProcess() {
            // Traiter les messages
            List<Message> messages = consume(currentOffset);
            for (Message msg : messages) {
                process(msg);
                currentOffset = msg.getOffset();
            }
    
            // Persister périodiquement
            if (currentOffset % 1000 == 0) {
                techDb.saveOffset("kafka", "my-topic-0", currentOffset, null);
            }
        }
    
        @Override
        protected void doStop() {
            // Sauvegarder l'offset final
            techDb.saveOffset("kafka", "my-topic-0", currentOffset, null);
        }
    }
    

    7.2 État du worker

    @Component
    public class BatchWorker extends AbstractWorker {
    
        @Autowired
        private TechDbManager techDb;
    
        @Override
        protected void doProcess() {
            // Mettre à jour l'état
            techDb.saveWorkerState(getName(), "PROCESSING",
                Map.of(
                    "currentBatch", currentBatchId,
                    "progress", progress
                ));
    
            // Traitement...
    
            techDb.saveWorkerState(getName(), "IDLE", Map.of());
        }
    }
    

    8. Patterns courants

    8.1 Worker avec retry

    @Component
    public class RetryableWorker extends AbstractWorker {
    
        @Autowired
        private RetryTemplate retryTemplate;
    
        @Override
        protected void doProcess() {
            retryTemplate.execute(context -> {
                processWithRetry();
                return null;
            });
        }
    }
    

    8.2 Worker avec circuit breaker

    @Component
    public class ResilientWorker extends AbstractWorker {
    
        @Autowired
        private CircuitBreakerTemplate circuitBreaker;
    
        @Override
        protected void doProcess() {
            circuitBreaker.execute("external-api", () -> {
                callExternalApi();
            });
        }
    }
    

    8.3 Worker batch

    @Component
    public class BatchWorker extends AbstractWorker {
    
        private final int BATCH_SIZE = 100;
    
        @Override
        protected void doProcess() {
            List<Item> batch = fetchBatch(BATCH_SIZE);
            if (batch.isEmpty()) {
                return;
            }
    
            for (Item item : batch) {
                processItem(item);
                incrementProcessed();
            }
        }
    }
    

    9. Tests

    9.1 Test unitaire

    @ExtendWith(MockitoExtension.class)
    class SimpleWorkerTest {
    
        @InjectMocks
        private SimpleWorker worker;
    
        @Test
        void shouldInitialize() {
            worker.initialize();
            // Assertions...
        }
    
        @Test
        void shouldProcessItems() {
            worker.initialize();
            worker.start();
    
            worker.doWork();
    
            Map<String, Object> stats = worker.getStats();
            assertEquals(1L, stats.get("processedCount"));
        }
    
        @Test
        void shouldStopGracefully() {
            worker.initialize();
            worker.start();
            worker.stop();
    
            assertFalse(worker.isHealthy());
        }
    }
    

    9.2 Test d’intégration

    @SpringBootTest
    class WorkerIntegrationTest {
    
        @Autowired
        private List<Worker> workers;
    
        @Test
        void allWorkersShouldBeHealthyAfterStart() {
            workers.forEach(Worker::initialize);
            workers.forEach(Worker::start);
    
            workers.forEach(w -> assertTrue(w.isHealthy(),
                "Worker " + w.getName() + " should be healthy"));
        }
    }
    

    10. Auto-Restart des Workers

    Le MOP surveille automatiquement la sante des workers et peut les redemarrer en cas d’echec.

    Fonctionnement

    1. Detection : Le MOP verifie worker.isHealthy() a chaque cycle de la boucle principale
    2. Compteur : Un compteur d’echecs consecutifs est maintenu pour chaque worker
    3. Seuil : Apres 3 echecs consecutifs (configurable), le worker est redemarre
    4. Restart : Sequence stop()initialize()start() → replanification doWork()
    5. Reset : Le compteur est remis a zero si le worker redevient healthy

    Logs associes

    [step:worker_auto_restart] Worker 'xxx' unhealthy 3 fois, tentative de redemarrage
    [step:worker_restarted] Worker 'xxx' redemarre avec succes
    [step:worker_restart_failed] Echec du redemarrage de 'xxx': <error>
    

    Implementation dans le Worker

    Pour beneficier de l’auto-restart, le worker doit :

    1. Retourner false dans isHealthy() en cas de probleme
    2. Supporter un cycle stop()initialize()start()
    3. Reinitialiser son etat interne dans initialize()
    @Override
    public boolean isHealthy() {
        // Retourner false declenche le compteur d'echecs
        return lastApiCallSuccessful && !hasConsecutiveErrors;
    }
    

    Workers exclus

    Les workers built-in du socle (http_worker, control_worker, etc.) ne sont pas soumis a l’auto-restart car ils sont geres par le Supervisor.

    11. Workers Event-Driven

    Les Event-Driven Workers sont des workers passifs declenches par des evenements externes (Kafka, queues, CDC, etc.).

    Classe de base

    package eu.lmvi.socle.worker.event;
    
    public abstract class AbstractEventDrivenWorker<T> implements Worker {
    
        // Concurrence configurable
        protected AbstractEventDrivenWorker(int concurrency) { ... }
    
        // Mode PASSIVE automatique
        @Override
        public final boolean isPassive() { return true; }
    
        @Override
        public final String getSchedule() { return "PASSIVE"; }
    
        // Methodes abstraites a implementer
        protected abstract T pollEvent() throws InterruptedException;
        protected abstract void processEvent(T event);
    
        // Hooks optionnels
        protected void onInitialize() { }
        protected void onStarted() { }
        protected void onStopping() { }
        protected void onStopped() { }
        protected void handleError(T event, Exception e, int workerId) { }
        public long getBacklog() { return 0; }
    }
    

    Exemple d’implementation

    @Component
    public class KafkaEventWorker extends AbstractEventDrivenWorker<ConsumerRecord<String, String>> {
    
        private final BlockingQueue<ConsumerRecord<String, String>> eventQueue = new LinkedBlockingQueue<>();
    
        public KafkaEventWorker() {
            super(4); // 4 threads concurrents
        }
    
        @Override
        public String getName() {
            return "kafka_event_worker";
        }
    
        @Override
        protected ConsumerRecord<String, String> pollEvent() throws InterruptedException {
            return eventQueue.poll(100, TimeUnit.MILLISECONDS);
        }
    
        @Override
        protected void processEvent(ConsumerRecord<String, String> event) {
            // Traitement de l'evenement
            log.info("Processing: {}", event.value());
        }
    
        @Override
        public long getBacklog() {
            return eventQueue.size();
        }
    }
    

    Metriques standardisees

    Les Event-Driven Workers exposent des metriques compatibles avec le StatusDashboard :

    Cle Type Description
    state String "running" ou "stopped"
    execution_count long Nombre d’evenements traites
    errors_count long Nombre d’erreurs
    last_execution String ISO-8601 du dernier traitement
    schedule String Toujours "PASSIVE"
    messages_processed long Alias de execution_count
    throughput_per_sec double Debit calcule
    backlog long Evenements en attente

    12. Convention des Stats Workers

    Pour une integration correcte avec le StatusDashboard et le WorkerActivityTracker, tous les workers doivent exposer des cles standardisees dans getStats().

    Cles obligatoires

    Cle Type Description
    state String "running" ou "stopped"
    execution_count long Nombre total d’executions
    errors_count long Nombre d’erreurs
    last_execution String/long Timestamp ISO-8601 ou epoch ms
    schedule String Mode: "PASSIVE", "INTERVAL", "CRON", ou expression cron

    Cles optionnelles

    Cle Type Description
    total_duration_ms long Duree totale cumulee
    avg_duration_ms double Duree moyenne par execution
    throughput_per_sec double Debit (ops/sec)
    messages_processed long Pour Event-Driven (alias execution_count)
    backlog long File d’attente

    Exemple d’implementation

    @Override
    public Map<String, Object> getStats() {
        Map<String, Object> stats = new HashMap<>();
    
        // Cles standardisees (obligatoires)
        stats.put("state", running ? "running" : "stopped");
        stats.put("execution_count", executionCount.get());
        stats.put("errors_count", errorCount.get());
        stats.put("last_execution", lastExecution != null
            ? lastExecution.toString()  // ISO-8601
            : null);
        stats.put("schedule", getSchedule() != null ? getSchedule() : "INTERVAL");
    
        // Cles optionnelles
        stats.put("total_duration_ms", totalDurationMs.get());
        stats.put("avg_duration_ms", executionCount.get() > 0
            ? (double) totalDurationMs.get() / executionCount.get()
            : 0.0);
    
        return stats;
    }
    

    13. JaninoWorker (Scripts Java Compiles)

    Le JaninoWorker permet d’executer du code Java compile dynamiquement a la volee. Contrairement au ScriptEngine (interprete), Janino compile le code en bytecode JVM pour des performances natives.

    13.1 Activation

    socle:
      janino:
        enabled: true
        scripts-path: ./repository/scripts/java
        reload-interval-ms: 300000  # 5 minutes
    

    13.2 Interfaces disponibles

    Les scripts doivent implementer une des interfaces :

    Interface Usage Methode
    Calculator<T> Calculs (frais, taxes) T calculate(Map<String, Object> context)
    Executable Execution generique Object execute(Map<String, Object> context)
    Validator Validations ValidationResult validate(Object input)

    13.3 Exemple de script

    // Fichier: repository/scripts/java/KrakenFeeCalculator.java
    
    import eu.lmvi.socle.janino.interfaces.Calculator;
    import java.math.BigDecimal;
    import java.math.RoundingMode;
    import java.util.Map;
    
    public class KrakenFeeCalculator implements Calculator<BigDecimal> {
    
        private static final BigDecimal FEE_RATE = new BigDecimal("0.0026");
    
        @Override
        public BigDecimal calculate(Map<String, Object> context) {
            BigDecimal amount = (BigDecimal) context.get("amount");
            return amount.multiply(FEE_RATE).setScale(8, RoundingMode.HALF_UP);
        }
    }
    

    13.4 Utilisation dans un Worker

    @Component
    public class TradingWorker implements Worker {
    
        @Autowired
        private JaninoWorker janinoWorker;
    
        @Override
        public void doWork() {
            Map<String, Object> context = Map.of(
                "amount", new BigDecimal("1000.00")
            );
    
            BigDecimal fee = janinoWorker.execute(
                "KrakenFeeCalculator",
                context,
                BigDecimal.class
            );
    
            log.info("Fee calculated: {}", fee);
        }
    }
    

    13.5 Acces direct au moteur

    @Autowired
    private JaninoWorker janinoWorker;
    
    // Compiler un script a la volee
    janinoWorker.compileScript("MyScript", sourceCode);
    
    // Verifier si compile
    boolean ready = janinoWorker.isScriptCompiled("MyScript");
    
    // Forcer le rechargement
    janinoWorker.forceReload();
    
    // Acces au moteur
    JaninoEngine engine = janinoWorker.getEngine();
    

    13.6 Securite

    Janino bloque l’acces aux packages dangereux :

    • java.io – Acces fichiers
    • java.net – Acces reseau
    • java.lang.reflect – Reflection
    • sun.*, com.sun.* – Classes internes

    13.7 Comparaison avec ScriptEngine

    Critere ScriptEngine JaninoWorker
    Langages JavaScript, BeanShell Java pur
    Performance Interprete Compile (natif JVM)
    Typage Dynamique Statique
    Hot reload Non Oui (automatique)
    Use case Prototypage, scripts simples Calculs haute perf

    14. Bonnes pratiques

    DO

    • Implémenter stop() pour un arrêt gracieux
    • Utiliser isHealthy() pour signaler les problèmes
    • Logger les transitions d’état
    • Gérer les exceptions dans doWork()
    • Utiliser des priorités pour les dépendances

    DON’T

    • Ne pas bloquer indéfiniment dans doWork()
    • Ne pas ignorer les signaux d’arrêt
    • Ne pas oublier de décrémenter les ressources dans stop()
    • Ne pas utiliser de variables statiques pour l’état

    15. Références

  • Socle V004 – H2 et TechDB

    Socle V004 – H2 et TechDB

    21 – H2 TechDB (Nouveaute V4)

    Version : 4.0.2 Date : 2026-01-15

    1. Introduction

    La H2 TechDB est une base de donnees embarquee introduite dans le Socle V4 pour stocker l’etat technique de maniere persistante.

    Pourquoi H2 ?

    Critere H2 Nitrite (ancien)
    Embarque
    ARM/AMD64 ⚠️ Problemes
    UI debug ✅ H2 Console
    JSON SQL ✅ JSON_VALUE
    Stabilite ⚠️ v4 instable

    Nouveautes V4.0.1

    • Standard de tables x_ : Nouvelle structure avec champs techniques standardises
    • H2 Console sur port 9376 : Interface web dediee pour explorer la base
    • TechDbReaderWorker : Worker passif de lecture des donnees
    • TechDbPurgeWorker : Purge automatique des donnees obsoletes

    Nouveautes V4.0.2

    • API SQL REST : Nouveau endpoint /techdb/query pour requetes SQL via HTTP
    • Authentification Basic Auth : Securisation de l’acces API
    • Rate Limiting : Protection contre les abus (60 req/min/IP par defaut)
    • Mode Readonly : Protection contre les modifications accidentelles

    2. Cas d’usage

    La TechDB stocke :

    • Offsets/sequences : Position dans Kafka, NATS, DB2
    • Etat local des workers : Statut, derniere execution
    • Evenements techniques : Logs importants
    • Fallback logs : Logs non envoyes (LogForwarder)
    • Cle-valeur : Donnees generiques avec TTL

    3. Configuration

    3.1 application.yml

    socle:
      techdb:
        enabled: ${TECHDB_ENABLED:true}
        url: jdbc:h2:file:${TECHDB_PATH:./data/socle-techdb};MODE=PostgreSQL;DB_CLOSE_DELAY=-1;AUTO_SERVER=TRUE
        username: ${TECHDB_USERNAME:LMVI}
        password: ${TECHDB_PASSWORD:LMVI-SOCLEV004}
    
        # H2 Console Web (port 9376)
        console:
          enabled: ${TECHDB_CONSOLE_ENABLED:true}
          port: ${TECHDB_CONSOLE_PORT:9376}
          bind_address: ${TECHDB_CONSOLE_BIND:}
          allow_remote: ${TECHDB_CONSOLE_ALLOW_REMOTE:false}
    
        # Purge automatique des donnees anciennes
        purge:
          enabled: ${TECHDB_PURGE_ENABLED:true}
          schedule: ${TECHDB_PURGE_SCHEDULE:0 0 3 * * ?}  # 3h du matin
          events_retention_days: ${TECHDB_PURGE_EVENTS_DAYS:7}
          logs_retention_days: ${TECHDB_PURGE_LOGS_DAYS:3}
    

    3.2 Variables d’environnement

    Variable Description Defaut
    TECHDB_ENABLED Activer TechDB true
    TECHDB_PATH Chemin fichier H2 ./data/socle-techdb
    TECHDB_USERNAME Nom d’utilisateur LMVI
    TECHDB_PASSWORD Mot de passe LMVI-SOCLEV004
    TECHDB_CONSOLE_ENABLED Activer console web true
    TECHDB_CONSOLE_PORT Port console 9376
    TECHDB_CONSOLE_ALLOW_REMOTE Acces distant false
    TECHDB_PURGE_ENABLED Activer purge auto true
    TECHDB_PURGE_EVENTS_DAYS Retention events 7
    TECHDB_PURGE_LOGS_DAYS Retention logs 3

    3.3 Personnalisation des identifiants par environnement

    Les identifiants par defaut (LMVI / LMVI-SOCLEV004) conviennent pour le developpement et les tests. Pour la production, il est recommande de personnaliser via variables d’environnement.

    Docker Compose :

    services:
      mon-app:
        environment:
          - TECHDB_USERNAME=MonUserProd
          - TECHDB_PASSWORD=MonMotDePasseSecurise123!
    

    Java direct :

    export TECHDB_USERNAME=MonUserProd
    export TECHDB_PASSWORD=MonMotDePasseSecurise123!
    java -jar mon-application.jar
    

    Kubernetes :

    env:
      - name: TECHDB_USERNAME
        valueFrom:
          secretKeyRef:
            name: techdb-credentials
            key: username
      - name: TECHDB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: techdb-credentials
            key: password
    

    Note : Si vous changez les identifiants sur une base existante, vous devez supprimer le fichier socle-techdb.mv.db et laisser l’application recreer la base.

    4. Schéma de base

    Les tables sont créées automatiquement au démarrage :

    -- Offsets / séquences
    CREATE TABLE IF NOT EXISTS socle_offsets (
        id IDENTITY PRIMARY KEY,
        source_name VARCHAR(200) NOT NULL,
        partition_key VARCHAR(200) NOT NULL,
        last_sequence BIGINT NOT NULL,
        last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        extra JSON,
        UNIQUE(source_name, partition_key)
    );
    
    -- État local des workers
    CREATE TABLE IF NOT EXISTS socle_worker_state (
        id IDENTITY PRIMARY KEY,
        worker_id VARCHAR(200) NOT NULL UNIQUE,
        status VARCHAR(20) NOT NULL,
        last_heartbeat TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        metadata JSON
    );
    
    -- Événements techniques
    CREATE TABLE IF NOT EXISTS socle_events (
        id IDENTITY PRIMARY KEY,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        type VARCHAR(100) NOT NULL,
        payload JSON
    );
    
    -- Fallback logs (LogForwarder)
    CREATE TABLE IF NOT EXISTS socle_log_fallback (
        id IDENTITY PRIMARY KEY,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        log_entry JSON NOT NULL,
        retry_count INT DEFAULT 0
    );
    

    5. Interface TechDbManager

    package eu.lmvi.socle.techdb;
    
    @Component
    public class TechDbManager {
    
        // ===== Lifecycle =====
    
        /**
         * Initialise la base H2 et crée les tables
         */
        public void initialize();
    
        /**
         * Ferme proprement la connexion
         */
        public void close();
    
        /**
         * Vérifie la santé de la base
         */
        public boolean isHealthy();
    
        // ===== Offsets =====
    
        /**
         * Sauvegarde un offset
         */
        public void saveOffset(String sourceName, String partitionKey,
                               long sequence, Map<String, Object> extra);
    
        /**
         * Récupère un offset
         */
        public OptionalLong getOffset(String sourceName, String partitionKey);
    
        /**
         * Liste tous les offsets d'une source
         */
        public List<OffsetRecord> getOffsets(String sourceName);
    
        // ===== Worker State =====
    
        /**
         * Sauvegarde l'état d'un worker
         */
        public void saveWorkerState(String workerId, String status,
                                    Map<String, Object> metadata);
    
        /**
         * Récupère l'état d'un worker
         */
        public Optional<WorkerState> getWorkerState(String workerId);
    
        // ===== Events =====
    
        /**
         * Enregistre un événement technique
         */
        public void logEvent(String type, Map<String, Object> payload);
    
        /**
         * Récupère les événements
         */
        public List<TechEvent> getEvents(String type, Instant since, int limit);
    
        // ===== Generic KV =====
    
        public void put(String key, String value);
        public Optional<String> get(String key);
        public void delete(String key);
    }
    

    6. Utilisation

    6.1 Injection

    @Service
    public class MonWorker implements Worker {
    
        @Autowired
        private TechDbManager techDb;
    
        @Override
        public void doWork() {
            // Récupérer le dernier offset
            OptionalLong lastOffset = techDb.getOffset("kafka", "my-topic-0");
            long startFrom = lastOffset.orElse(0L);
    
            // Traiter les messages...
            long newOffset = processMessages(startFrom);
    
            // Sauvegarder le nouvel offset
            techDb.saveOffset("kafka", "my-topic-0", newOffset,
                Map.of("processed", true));
        }
    }
    

    6.2 Gestion des offsets

    // Sauvegarder
    techDb.saveOffset("nats", "events.orders", 123456789L,
        Map.of("consumer", "order-processor"));
    
    // Récupérer
    OptionalLong offset = techDb.getOffset("nats", "events.orders");
    if (offset.isPresent()) {
        log.info("Dernier offset: {}", offset.getAsLong());
    }
    
    // Lister tous les offsets NATS
    List<OffsetRecord> offsets = techDb.getOffsets("nats");
    offsets.forEach(o -> log.info("{}: {}", o.partitionKey(), o.lastSequence()));
    

    6.3 État des workers

    // Sauvegarder l'état
    techDb.saveWorkerState("kafka-consumer-001", "RUNNING",
        Map.of(
            "lastProcessed", Instant.now(),
            "messagesPerMinute", 523
        ));
    
    // Récupérer l'état
    Optional<WorkerState> state = techDb.getWorkerState("kafka-consumer-001");
    state.ifPresent(s -> {
        log.info("Worker {} - Status: {}", s.workerId(), s.status());
    });
    

    6.4 Événements techniques

    // Logger un événement
    techDb.logEvent("PIPELINE_ERROR", Map.of(
        "pipeline", "order-processing",
        "error", "Connection timeout",
        "messageId", "msg-123"
    ));
    
    // Récupérer les événements récents
    List<TechEvent> errors = techDb.getEvents(
        "PIPELINE_ERROR",
        Instant.now().minus(1, ChronoUnit.HOURS),
        100
    );
    

    7. H2 Console Web (Port 9376)

    Le Socle V4 expose une console H2 dediee sur le port 9376 via le TechDbConsoleWorker.

    Acces

    http://localhost:9376
    

    Informations de connexion

    Champ Valeur
    JDBC URL jdbc:h2:./data/socle-techdb (local) ou jdbc:h2:/app/data/socle-techdb (Docker)
    User LMVI (defaut, personnalisable via TECHDB_USERNAME)
    Password LMVI-SOCLEV004 (defaut, personnalisable via TECHDB_PASSWORD)
    Driver org.h2.Driver

    Configuration

    socle:
      techdb:
        console:
          enabled: true       # Activer/desactiver
          port: 9376          # Port dedie
          bind_address: ""    # Vide = toutes interfaces
          allow_remote: false # Securite: localhost only
    

    Requetes utiles

    -- Voir tous les offsets
    SELECT * FROM techdb_offsets ORDER BY x_dateCreated DESC;
    
    -- Offsets Kafka uniquement
    SELECT * FROM techdb_offsets WHERE topic LIKE 'kafka%';
    
    -- Etat des workers
    SELECT worker_name, state, last_run_at, error_count FROM techdb_worker_state;
    
    -- Evenements non traites
    SELECT * FROM techdb_events WHERE processed = FALSE ORDER BY x_dateCreated;
    
    -- Logs non envoyes
    SELECT COUNT(*) as pending FROM techdb_log_buffer WHERE forwarded = FALSE;
    
    -- Cles KV avec expiration
    SELECT kv_key, value_type, expires_at FROM techdb_kv WHERE expires_at IS NOT NULL;
    

    8. API SQL REST (Nouveaute V4.0.2)

    Le Socle V4 expose une API REST permettant d’executer des requetes SQL sur la TechDB. Cette API est distincte de la console H2 et offre un acces programmatique securise.

    8.1 Configuration

    socle:
      techdb:
        sql_api:
          enabled: ${TECHDB_SQL_API_ENABLED:false}
          auth:
            user: ${TECHDB_API_USER:admin}
            password: ${TECHDB_API_PASSWORD:}
          security:
            readonly: ${TECHDB_SQL_API_READONLY:true}
            blocked_tables: ${TECHDB_SQL_API_BLOCKED_TABLES:}
          limits:
            max_rows: ${TECHDB_SQL_API_MAX_ROWS:1000}
            timeout_seconds: ${TECHDB_SQL_API_TIMEOUT:30}
            rate_limit_per_minute: ${TECHDB_SQL_API_RATE_LIMIT:60}
          logging:
            log_queries: ${TECHDB_SQL_API_LOG_QUERIES:true}
    

    8.2 Variables d’environnement

    Variable Description Defaut
    TECHDB_SQL_API_ENABLED Activer l’API SQL false
    TECHDB_API_USER Utilisateur Basic Auth admin
    TECHDB_API_PASSWORD Mot de passe (vide = pas d’auth) « 
    TECHDB_SQL_API_READONLY Mode lecture seule true
    TECHDB_SQL_API_BLOCKED_TABLES Tables interdites (CSV) « 
    TECHDB_SQL_API_MAX_ROWS Limite de lignes 1000
    TECHDB_SQL_API_TIMEOUT Timeout requetes (sec) 30
    TECHDB_SQL_API_RATE_LIMIT Requetes/minute/IP 60

    8.3 Endpoints

    Methode Path Description
    POST /techdb/query Executer une requete SQL
    GET /techdb/tables Liste des tables
    GET /techdb/tables/{name} Details d’une table
    GET /techdb/stats Statistiques DB

    8.4 Authentification

    L’API utilise Basic Auth. Si un mot de passe est configure, toutes les requetes doivent inclure l’en-tete:

    Authorization: Basic base64(user:password)
    

    Exemple avec curl:

    # Sans authentification (si TECHDB_API_PASSWORD vide)
    curl http://localhost:8080/techdb/tables
    
    # Avec authentification
    curl -u admin:monmotdepasse http://localhost:8080/techdb/query \
      -H "Content-Type: application/json" \
      -d '{"sql": "SELECT * FROM techdb_kv LIMIT 10"}'
    

    8.5 Executer une requete SQL

    Requete:

    curl -X POST http://localhost:8080/techdb/query \
      -H "Content-Type: application/json" \
      -u admin:secret \
      -d '{
        "sql": "SELECT * FROM techdb_events WHERE event_type = ?",
        "params": ["WORKER_START"],
        "maxRows": 100
      }'
    

    Reponse succes:

    {
      "success": true,
      "timestamp": 1705312800000,
      "executionTimeMs": 12,
      "rowCount": 15,
      "columns": ["X_ID", "X_DATECREATED", "EVENT_TYPE", "SOURCE", "DATAS"],
      "rows": [
        {"X_ID": 1, "X_DATECREATED": "2025-01-15T10:00:00", "EVENT_TYPE": "WORKER_START", ...},
        ...
      ],
      "truncated": false
    }
    

    Reponse erreur:

    {
      "success": false,
      "timestamp": 1705312800000,
      "error": {
        "code": "SQL_SYNTAX_ERROR",
        "message": "Syntax error in SQL statement"
      }
    }
    

    8.6 Codes d’erreur

    Code HTTP Status Description
    SQL_SYNTAX_ERROR 400 Erreur de syntaxe SQL
    DDL_NOT_ALLOWED 403 Operation DDL interdite
    READONLY_VIOLATION 403 Non-SELECT en mode readonly
    TABLE_BLOCKED 403 Table bloquee par config
    QUERY_TIMEOUT 408 Timeout depasse
    UNAUTHORIZED 401 Authentification requise
    RATE_LIMITED 429 Limite requetes depassee
    TECHDB_DISABLED 503 TechDB non disponible

    8.7 Securite

    Operations toujours interdites:

    • DDL: DROP, ALTER, CREATE, TRUNCATE, GRANT, REVOKE
    • Commandes dangereuses: SHUTDOWN, SCRIPT, BACKUP, RESTORE

    Mode readonly (defaut):

    • Seuls les SELECT sont autorises
    • INSERT, UPDATE, DELETE interdits

    Tables bloquees:

    socle:
      techdb:
        sql_api:
          security:
            blocked_tables: techdb_log_buffer,techdb_kv  # CSV
    

    8.8 Rate Limiting

    L’API applique un rate limiting par IP (sliding window par minute).

    Par defaut: 60 requetes/minute/IP

    Depassement = HTTP 429 Too Many Requests

    8.9 Metriques Prometheus

    techdb_sql_api_queries_total{status="success|error|timeout"}
    techdb_sql_api_queries_duration_seconds
    techdb_sql_api_auth_failures_total
    techdb_sql_api_rate_limited_total
    

    8.10 Exemples pratiques

    Lister les tables:

    curl http://localhost:8080/techdb/tables
    

    Details d’une table:

    curl http://localhost:8080/techdb/tables/TECHDB_EVENTS
    

    Statistiques DB:

    curl http://localhost:8080/techdb/stats
    

    Requete avec parametres:

    curl -X POST http://localhost:8080/techdb/query \
      -H "Content-Type: application/json" \
      -d '{
        "sql": "SELECT worker_name, state, error_count FROM techdb_worker_state WHERE state = ?",
        "params": ["RUNNING"]
      }'
    

    9. Workers TechDB

    Le Socle V4 inclut 3 workers dedies a la gestion de TechDB:

    9.1 TechDbReaderWorker

    Worker PASSIVE exposant des methodes de lecture.

    @Autowired
    private TechDbReaderWorker reader;
    
    // Recuperer tous les offsets
    List<Map<String, Object>> offsets = reader.getAllOffsets();
    
    // Recuperer les evenements recents
    List<Map<String, Object>> events = reader.getRecentEvents(100);
    
    // Executer une requete personnalisee
    List<Map<String, Object>> results = reader.executeCustomQuery(
        "SELECT * FROM techdb_worker_state WHERE state = 'RUNNING'"
    );
    

    9.2 TechDbPurgeWorker

    Worker CRON qui purge automatiquement les donnees obsoletes.

    socle:
      techdb:
        purge:
          enabled: true
          schedule: "0 0 3 * * ?"  # 3h du matin
          events_retention_days: 7
          logs_retention_days: 3
    

    Donnees purgees :

    • Evenements traites > 7 jours
    • Logs forwardes > 3 jours
    • Cles KV expirees

    9.3 TechDbConsoleWorker

    Worker PASSIVE qui demarre la console H2 sur le port 9376.

    @Autowired
    private TechDbConsoleWorker console;
    
    // Verifier si la console est accessible
    boolean running = console.isConsoleRunning();
    
    // Obtenir les infos de connexion
    Map<String, String> info = console.getConnectionInfo();
    

    10. Fonctions JSON H2

    H2 2.x supporte les fonctions JSON SQL standard :

    -- Extraction de valeur
    SELECT JSON_VALUE('{"name":"John","age":30}', '$.name');
    -- Résultat: John
    
    -- Extraction d'objet
    SELECT JSON_QUERY('{"data":{"items":[1,2,3]}}', '$.data');
    -- Résultat: {"items":[1,2,3]}
    
    -- Test d'existence
    SELECT JSON_EXISTS('{"name":"John"}', '$.name');
    -- Résultat: TRUE
    
    -- Construction JSON
    SELECT JSON_OBJECT('name': 'John', 'age': 30);
    -- Résultat: {"name":"John","age":30}
    
    -- Filtrage sur JSON
    SELECT * FROM socle_events
    WHERE JSON_VALUE(payload, '$.severity') = 'ERROR';
    

    11. Integration avec SharedDataRegistry

    TechDB complète SharedDataRegistry :

    Aspect SharedDataRegistry TechDbManager
    Scope Runtime (mémoire) Persistant (fichier)
    Survie restart Non Oui
    Performance Ultra rapide Rapide
    Usage Métriques live Offsets, état

    Exemple de synergie

    @Service
    public class MonService {
    
        @Autowired
        private TechDbManager techDb;
    
        @Autowired
        private SharedDataRegistry sharedData;
    
        public void initialize() {
            // Restaurer l'offset depuis TechDB
            OptionalLong persisted = techDb.getOffset("kafka", "topic-0");
    
            // Créer le compteur en mémoire
            sharedData.createSequence("kafka.offset.topic-0",
                persisted.orElse(0L),
                HealthLevel.CRITICAL);
        }
    
        public void onMessage(long offset) {
            // Mettre à jour en mémoire (rapide)
            sharedData.setSequence("kafka.offset.topic-0", offset);
    
            // Persister périodiquement (moins fréquent)
            if (offset % 1000 == 0) {
                techDb.saveOffset("kafka", "topic-0", offset, null);
            }
        }
    }
    

    12. Bonnes pratiques

    DO

    • ✅ Utiliser TechDB pour les données qui doivent survivre au restart
    • ✅ Persister les offsets périodiquement (pas à chaque message)
    • ✅ Utiliser JSON pour les métadonnées flexibles
    • ✅ Activer H2 Console uniquement en dev

    DON’T

    • ❌ Stocker des données volumineuses (utiliser PostgreSQL)
    • ❌ Faire des requêtes complexes en boucle doWork()
    • ❌ Activer H2 Console en production
    • ❌ Utiliser pour du cache haute fréquence (utiliser KvBus)

    13. Troubleshooting

    Base corrompue

    # Supprimer et recréer
    rm -rf ./data/socle-techdb.*
    # Redémarrer l'application
    

    Fichier verrouillé

    Database may be already in use: "locked by another process"
    

    Solution : Arrêter l’autre instance ou utiliser AUTO_SERVER=TRUE dans l’URL.

    Console H2 inaccessible

    1. Vérifier socle.techdb.console.enabled: true
    2. Vérifier que l’application tourne
    3. Essayer avec le chemin complet du fichier

    14. References

    Socle V004 – TechDB H2

  • TEST






    Nouveau Test avec image V2



    Nouveau Test avec image V2

    Avec un fichier

    Slot_Car_Street.pdf

    Debut de Code en javascript

    Fichier Jar :

    registry-handler-1.0.0.jar.zip

    javascript
    import { Block } from '../../../../data/protocols/blocks';
    import { ToHtml } from '../../../../domain/use-cases/to-html';
    import { blockToInnerText } from '../../../helpers/block-to-inner-text';
    import hljs from '../../../../config/highlightConfig';
    import prettier from 'prettier';
    
    export class CodeBlockToHtml implements ToHtml {
      private readonly _block: Block;
    
      constructor(block: Block) {
        this._block = block;
      }
    
      async convert(): Promise<string> {
        const language = this._language ? this._language : 'plaintext';  // Fallback au texte brut si pas de langue spécifiée
        const languageClass = `language-${language}`;
    
        // Obtenir le texte du bloc et formater avec Prettier
        let code = blockToInnerText(this._block).replace(/(\s{4}|\t)/g, '  ');
        try {
          code = prettier.format(code, { semi: false, parser: "babel" }); // Assure-toi de choisir le bon parser selon le langage
        } catch (error) {
          console.error("Prettier formatting failed:", error);
        }
    
        // Appliquer la coloration syntaxique avec Highlight.js
        const highlightedCode = hljs.highlight(code, { language }).value;
    
        // Retourner le code HTML formaté
        return Promise.resolve(
            `<pre><code class="${languageClass}">${highlightedCode}</code></pre>`
        );
      }
    
      private get _language(): string {
        return this._block.properties?.language?.toLowerCase().replace(/ /g, '');
      }
    }

    Image

    Notion Image

    Autres images

    Notion Image

    Tableau

    Resolving The Problem

    The following table lists the ports that IBM i Access and related functions use for communication with the IBM i OS System:

    PC Function Server Name Port Non-SSL Port SSL
    • Server Mapper • as-svrmap • 449 • —
    • License Management • as-central • 8470 • 9470
    • Database Access • as-database • 8471 • 9471
    • Data Queues • as-dtaq • 8472 • 9472
    • IFS Access usingAccess/Navigator • as-file • 8473 • 9473
    • Network Printers • as-netprt • 8474 • 9474
    • Remote Command • as-rmtcmd • 8475 • 9475
    • Signon Verification • as-signon • 8476 • 9476
    • Telnet (5250 Emulation) • telnet • 23 • 992
    • Navigator for i (Heritage version) • as-nav • 2004 • 2005
    • New Navigator for i • as-new-nav • 2002 • 2003
    • Digital Certificate Manager • as-admin3-http • 2006 • 2007
    • HTTP Administration • as-admin • 2001 • 2010
    • DDM/DRDA • DDM/DRDA • 446 • 448
    • NetServer • netbios > • 137 • —
    • NetServer • netbios > • 139 • —
    • NetServer (CIFS) • CIFS • 445 • —
    • Service Tools Server • as-sts • 3000 • —

    If any of the above ports are restricted by using a firewall or any other mechanism, IBM i Access or related functions might fail to operate. For assistance with configuring ports or working with a firewall beyond the above information, contact the firewall provider or obtain a consulting agreement.

    Note:

    The following ports are common to most IBM i Access Client products such as ODBC, Telnet, and other specific functions:

    Port 449 is used to look up service by name and return the port number.

    Ports 8470 and 9470(TLS/SSL) are used for host code page translation tables and licensing functions.

    Ports 8475 and 9475(TLS/SSL) are used to check for application administration restrictions.

    Ports 8476 and 9476(TLS/SSL) are used for checking signon verification to authenticate.

    depending on your needs you may only need the above ports and the port(s) for your function/application.For the ports used by the Console, see document N1015344, IBM iSeries Port Assignments with Operations Console.

    For a list of currently listening IPv4 daemons on the IBM i, run the following SQL statement:

    sql
    SELECT LOCAL_PORT, LOCAL_PORT_NAME, BIND_USER, IDLE_TIME
    FROM QSYS2.NETSTAT_INFO
    where LOCAL_ADDRESS = '0.0.0.0';

    Other options are the CL command NETSTAT OPTION(*CNN) or to review the output from WRKSRVTBLE OUTPUT(*PRINT).

    Tache 1
    Tache 2
    Tache 3

    • Puce 1
    • Puce 2

    La maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombréeLa maison de la rue adjaçante est encombrée

    Test Unique

    ℹ️

    Avec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignesAvec un bel encadrement et avec plusieurs lignes

    Test de titre 1

    Test de titre 2

    Test de titre 3

    en gras, en italique, sous ligné, barré

    Champs de l’entité « Person »

    Voici les principaux champs disponibles pour l’entité « Person » selon Schema.org :

    1. additionalName: Un nom supplémentaire pour la personne, souvent un deuxième prénom.
    1. address: L’adresse postale de la personne.
    1. affiliation: Une organisation à laquelle la personne est affiliée, comme une entreprise ou une institution.
    1. alumniOf: Une organisation éducative ou une école dont la personne est un ancien élève.
    1. award: Une récompense ou un prix que la personne a reçu.
    1. birthDate: La date de naissance de la personne.
    1. birthPlace: Le lieu de naissance de la personne.
    1. brand: La marque associée à la personne, souvent utilisée pour des célébrités ou des entrepreneurs.
    1. children: Les enfants de la personne.
    1. colleague: Les collègues de la personne.
    1. contactPoint: Un point de contact pour la personne.
    1. deathDate: La date de décès de la personne.
    1. deathPlace: Le lieu de décès de la personne.
    1. duns: Le numéro DUNS de la personne.
    1. email: L’adresse email de la personne.
    1. familyName: Le nom de famille de la personne.
    1. faxNumber: Le numéro de fax de la personne.
    1. follows: Les personnes que cette personne suit (par exemple sur les réseaux sociaux).
    1. funder: Une entité qui finance cette personne.
    1. gender: Le genre de la personne (masculin, féminin, etc.).
    1. givenName: Le prénom de la personne.
    1. globalLocationNumber: Le numéro de localisation global pour la personne.
    1. hasCredential: Les informations d’identification de la personne.
    1. hasOccupation: La profession de la personne.
    1. hasOfferCatalog: Un catalogue d’offres que la personne possède.
    1. hasPOS: Un point de vente que la personne possède.
    1. height: La taille de la personne.
    1. homeLocation: L’emplacement de la résidence principale de la personne.
    1. honorificPrefix: Un préfixe honorifique pour la personne (par exemple, Dr., M., Mme).
    1. honorificSuffix: Un suffixe honorifique pour la personne (par exemple, Jr., Sr.).
    1. interactionStatistic: Les statistiques d’interaction pour la personne.
    1. isicV4: Le code ISIC pour la personne.
    1. jobTitle: Le titre du poste de la personne.
    1. knows: Les connaissances de la
    mermaid
    graph LR
    SymmetricDS_OVH[(« SymmetricDS-OVH »)]
    db-prod[(« PostgreSQL (db-reflet)
    Port: 5432″)]
    pgadmin[(« pgAdmin
    Port: 8888″)]
    redis[(« Redis (cache)
    Port: 6379″)]
    zookeeper[(« Zookeeper
    Port: 2181″)]
    kafka[(« Kafka
    Port: 9092″)]
    kafka_manager[(« Kafka Manager
    Port: 9000″)]
    directus[(« Directus
    Port: 8055″)]
    budibase[(« Budibase
    Port: 10000″)]
    n8n[(« n8n
    Port: 443″)]
    me[(« MONDE \n Extérieur
    Port: 443″)]
    cosmo[(« PostgreSQL (Cosmo)
    Port: 5432″)]
    directus-c[(« Directus
    4 Cosmo
    Port: 8055″)]

    db-prod –>|Cache| redis
    db-prod –>|Publie| kafka
    directus –>|Cache| redis
    pgadmin –>|Administre| db-prod
    budibase –>|CRUD| db-prod
    directus –>|Propose des APIS| db-prod
    kafka –>|Depends on| zookeeper
    kafka_manager –>|Depends on| zookeeper
    kafka_manager –>|Manage Topics| kafka

    SymmetricDS_OVH –>|Envoi| db-prod
    SymmetricDS_OVH –>|Envoi| kafka
    n8n –> |publie| kafka
    kafka –>|consomme| n8n
    db-prod –>|trigger| n8n
    n8n –> |publie| me
    directus-c –> |publie| cosmo
    cosmo –> |publie| directus-c
    n8n –> |GraphQL| directus-c

    python
    # flake8: noqa
    # This file is used for deploying replicate models
    # running: cog predict -i img=@inputs/whole_imgs/10045.png -i version='v1.4' -i scale=2
    # push: cog push r8.im/tencentarc/gfpgan
    # push (backup): cog push r8.im/xinntao/gfpgan
    
    import os
    
    os.system('python setup.py develop')
    os.system('pip install realesrgan')
    
    import cv2
    import shutil
    import tempfile
    import torch
    from basicsr.archs.srvgg_arch import SRVGGNetCompact
    
    from gfpgan import GFPGANer
    
    try:
        from cog import BasePredictor, Input, Path
        from realesrgan.utils import RealESRGANer
    except Exception:
        print('please install cog and realesrgan package')
    
    
    class Predictor(BasePredictor):
    
        def setup(self):
            os.makedirs('output', exist_ok=True)
            # download weights
            if not os.path.exists('gfpgan/weights/realesr-general-x4v3.pth'):
                os.system(
                    'wget https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/realesr-general-x4v3.pth -P ./gfpgan/weights'
                )
            if not os.path.exists('gfpgan/weights/GFPGANv1.2.pth'):
                os.system(
                    'wget https://github.com/TencentARC/GFPGAN/releases/download/v1.3.0/GFPGANv1.2.pth -P ./gfpgan/weights')
            if not os.path.exists('gfpgan/weights/GFPGANv1.3.pth'):
                os.system(
                    'wget https://github.com/TencentARC/GFPGAN/releases/download/v1.3.0/GFPGANv1.3.pth -P ./gfpgan/weights')
            if not os.path.exists('gfpgan/weights/GFPGANv1.4.pth'):
                os.system(
                    'wget https://github.com/TencentARC/GFPGAN/releases/download/v1.3.0/GFPGANv1.4.pth -P ./gfpgan/weights')
            if not os.path.exists('gfpgan/weights/RestoreFormer.pth'):
                os.system(
                    'wget https://github.com/TencentARC/GFPGAN/releases/download/v1.3.4/RestoreFormer.pth -P ./gfpgan/weights'
                )
    
            # background enhancer with RealESRGAN
            model = SRVGGNetCompact(num_in_ch=3, num_out_ch=3, num_feat=64, num_conv=32, upscale=4, act_type='prelu')
            model_path = 'gfpgan/weights/realesr-general-x4v3.pth'
            half = True if torch.cuda.is_available() else False
            self.upsampler = RealESRGANer(
                scale=4, model_path=model_path, model=model, tile=0, tile_pad=10, pre_pad=0, half=half)
    
            # Use GFPGAN for face enhancement
            self.face_enhancer = GFPGANer(
                model_path='gfpgan/weights/GFPGANv1.4.pth',
                upscale=2,
                arch='clean',
                channel_multiplier=2,
                bg_upsampler=self.upsampler)
            self.current_version = 'v1.4'
    
        def predict(
                self,
                img: Path = Input(description='Input'),
                version: str = Input(
                    description='GFPGAN version. v1.3: better quality. v1.4: more details and better identity.',
                    choices=['v1.2', 'v1.3', 'v1.4', 'RestoreFormer'],
                    default='v1.4'),
                scale: float = Input(description='Rescaling factor', default=2),
        ) -> Path:
            weight = 0.5
            print(img, version, scale, weight)
            try:
                extension = os.path.splitext(os.path.basename(str(img)))[1]
                img = cv2.imread(str(img), cv2.IMREAD_UNCHANGED)
                if len(img.shape) == 3 and img.shape[2] == 4:
                    img_mode = 'RGBA'
                elif len(img.shape) == 2:
                    img_mode = None
                    img = cv2.cvtColor(img, cv2.COLOR_GRAY2BGR)
                else:
                    img_mode = None
    
                h, w = img.shape[0:2]
                if h < 300:
                    img = cv2.resize(img, (w * 2, h * 2), interpolation=cv2.INTER_LANCZOS4)
    
                if self.current_version != version:
                    if version == 'v1.2':
                        self.face_enhancer = GFPGANer(
                            model_path='gfpgan/weights/GFPGANv1.2.pth',
                            upscale=2,
                            arch='clean',
                            channel_multiplier=2,
                            bg_upsampler=self.upsampler)
                        self.current_version = 'v1.2'
                    elif version == 'v1.3':
                        self.face_enhancer = GFPGANer(
                            model_path='gfpgan/weights/GFPGANv1.3.pth',
                            upscale=2,
                            arch='clean',
                            channel_multiplier=2,
                            bg_upsampler=self.upsampler)
                        self.current_version = 'v1.3'
                    elif version == 'v1.4':
                        self.face_enhancer = GFPGANer(
                            model_path='gfpgan/weights/GFPGANv1.4.pth',
                            upscale=2,
                            arch='clean',
                            channel_multiplier=2,
                            bg_upsampler=self.upsampler)
                        self.current_version = 'v1.4'
                    elif version == 'RestoreFormer':
                        self.face_enhancer = GFPGANer(
                            model_path='gfpgan/weights/RestoreFormer.pth',
                            upscale=2,
                            arch='RestoreFormer',
                            channel_multiplier=2,
                            bg_upsampler=self.upsampler)
    
                try:
                    _, _, output = self.face_enhancer.enhance(
                        img, has_aligned=False, only_center_face=False, paste_back=True, weight=weight)
                except RuntimeError as error:
                    print('Error', error)
    
                try:
                    if scale != 2:
                        interpolation = cv2.INTER_AREA if scale < 2 else cv2.INTER_LANCZOS4
                        h, w = img.shape[0:2]
                        output = cv2.resize(output, (int(w * scale / 2), int(h * scale / 2)), interpolation=interpolation)
                except Exception as error:
                    print('wrong scale input.', error)
    
                if img_mode == 'RGBA':  # RGBA images should be saved in png format
                    extension = 'png'
                # save_path = f'output/out.{extension}'
                # cv2.imwrite(save_path, output)
                out_path = Path(tempfile.mkdtemp()) / f'out.{extension}'
                cv2.imwrite(str(out_path), output)
            except Exception as error:
                print('global exception: ', error)
            finally:
                clean_folder('output')
            return out_path
    
    
    def clean_folder(folder):
        for filename in os.listdir(folder):
            file_path = os.path.join(folder, filename)
            try:
                if os.path.isfile(file_path) or os.path.islink(file_path):
                    os.unlink(file_path)
                elif os.path.isdir(file_path):
                    shutil.rmtree(file_path)
            except Exception as e:
                print(f'Failed to delete {file_path}. Reason: {e}')
    


  • Réinventer l’utilisation de l’ordinateur avec l’interpréteur ouvert

    Réinventer l’utilisation de l’ordinateur avec l’interpréteur ouvert

    L’évolution du traitement du langage naturel a donné naissance à l’interpréteur ouvert, une nouvelle manière d’interagir avec les ordinateurs. Cette interface en langage naturel ouvre des horizons inexplorés pour les tâches informatiques quotidiennes, allant de la création de contenus multimédias à l’analyse complexe de données.

    Les fondements de l’interprétation en langage naturel

    Le Traitement du Langage Naturel (TAL) figure au centre de l’innovation permettant aux ordinateurs de comprendre et d’agir sur les commandes humaines. Cette technologie a connu une évolution remarquable depuis ses origines, marquées par des programmes comme ELIZA, qui simulait une conversation sans réelle compréhension du langage. Aujourd’hui, grâce aux avancées considérables en intelligence artificielle et en apprentissage machine, les systèmes de traitement du langage naturel peuvent non seulement comprendre le sens littéral des mots mais aussi saisir les nuances et le contexte d’une demande.

    Au cœur de ces progrès, la capacité des algorithmes à analyser et interpréter les données linguistiques s’est nettement améliorée. Les techniques comme l’analyse syntaxique et sémantique permettent aux machines de décomposer les phrases en éléments compréhensibles et de les relier à des actions spécifiques. Cette compréhension est renforcée par l’apprentissage profond, qui dote les ordinateurs de la capacité à tirer des enseignements de vastes ensembles de données textuelles, leur permettant d’améliorer continuellement leur performance.

    Les applications actuelles du TAL s’étendent bien au-delà de la compréhension textuelle. Elles englobent la traduction automatique, la reconnaissance vocale, et même l’analyse de sentiments. L’interpréteur ouvert s’inscrit dans cette évolution comme un outil révolutionnaire, offrant aux utilisateurs la possibilité de commander et contrôler leurs ordinateurs en utilisant simplement le langage naturel. Cette innovation s’appuie sur les principes fondamentaux du TAL pour interpréter les commandes des utilisateurs, que ce soit pour créer un document, manipuler des fichiers multimédias, ou naviguer sur le web, rendant la technologie plus accessible et intuitive pour tous.

    Les progrès accomplis depuis ELIZA jusqu’aux systèmes sophistiqués d’aujourd’hui illustrent non seulement l’évolution du TAL, mais aussi la manière dont cette technologie continue de réinventer l’interaction entre l’homme et la machine. Avec l’avènement de l’interpréteur ouvert, l’informatique entre dans une nouvelle ère où les barrières linguistiques entre l’humain et l’ordinateur s’estompent, ouvrant la voie à une utilisation plus naturelle et efficace des technologies de l’information.

    La programmation accessible par le langage naturel

    La programmation a toujours été perçue comme un domaine réservé à une élite versée dans le maniement complexe des langages de programmation. Des premiers langages de haut niveau comme FORTRAN et COBOL, inventés dans les années 1950 et 1960, jusqu’aux paradigmes modernes tels que la programmation orientée objet, l’évolution a été constante. La création des premiers compilateurs a marqué une révolution, permettant la traduction du code source en langage machine, rendant l’exécution des programmes plus efficace. Cependant, malgré ces avancées, l’accès à la programmation est resté limité par la barrière du langage technique.

    L’avènement de l’interpréteur ouvert repousse aujourd’hui ces limites, inaugurant une ère où les commandes en langage naturel permettent d’exécuter des tâches de programmation complexes. Cet outil transforme fondamentalement l’approche de la programmation en la rendant accessible à tous, sans nécessité de maîtriser les syntaxes codifiées des langages traditionnels. L’utilisateur dialogue en langage naturel avec son ordinateur, qui interprète ces commandes et exécute les tâches demandées, allant de la gestion de bases de données à la manipulation de fichiers, en passant par la création et l’édition de contenus multimédias.

    Cette transformation marque un tournant dans la programmation du futur. L’interpréteur ouvert démocratise l’accès à la programmation, permettant à un public bien plus large de participer à la création et à l’innovation technologique. Il encourage également une nouvelle manière de penser la résolution de problèmes informatiques, où la compréhension et l’expression en langage naturel priment sur la connaissance de syntaxes complexes.

    L’impact de cette innovation se mesure également dans l’enseignement et l’apprentissage de la programmation. En simplifiant l’accès au codage, l’interpréteur ouvert constitue un outil pédagogique précieux, ouvrant les portes de l’informatique à des publics jusqu’ici éloignés de ce domaine. Cette accessibilité accrue pourrait même remodeler les professions futures, où la capacité à interagir avec les machines en langage naturel deviendra aussi fondamentale que l’est aujourd’hui la maîtrise de l’outil informatique.

    Ainsi, en offrant une interface intuitive de programmation en langage naturel, l’interpréteur ouvert ne se contente pas de simplifier l’accès à la programmation ; il redéfinit les contours mêmes de ce que signifie « programmer ». Cette mutation promet de révolutionner la manière dont nous interagissons avec les technologies, facilitant une intégration encore plus profonde et personnalisée de l’informatique dans notre quotidien.

    Interprétation avancée pour l’analyse de données

    Après avoir exploré la révolution de la programmation accessible via le langage naturel, où l’interpréteur ouvert simplifie les processus de codage, nous plongeons maintenant dans le monde de l’analyse de données. La capacité à interpréter, nettoyer, analyser et visualiser des données complexe est cruciale dans le paysage actuel de l’information. Historiquement, cette discipline exigeait une compréhension approfondie des statistiques et une maîtrise de logiciels spécialisés.

    L’extraction de données, ou data mining, a évolué depuis ses débuts, s’appuyant d’abord sur des statistiques simples pour évoluer vers des modèles prédictifs et des algorithmes complexes d’apprentissage automatique. La visualisation des données, quant à elle, a transformé la manière dont nous interprétons les ensembles de données, permettant de déceler des tendances et des anomalies auparavant invisibles.

    L’introduction de l’interpréteur ouvert dans ce paysage change radicalement la donne. En utilisant des commandes en langage naturel, même sans expertise en statistiques, les utilisateurs peuvent effectuer des analyses prédictives, nettoyer des ensembles de données de grande taille et intégrer différentes sources de données pour une analyse plus holistique. Ce processus d’intégration, essentiel pour comprendre les tendances à travers divers secteurs ou phénomènes, devient ainsi plus accessible.

    La visualisation des données, un autre aspect crucial de l’analyse, bénéficie également de cette avancée. En commandant à l’interpréteur de générer des graphiques ou des cartes à partir d’un ensemble de données spécifique, les utilisateurs peuvent créer des visualisations complexes sans connaissances préalables en bibliothèques de visualisation comme Matplotlib ou D3.js.

    Par exemple, un utilisateur souhaitant comprendre la répartition géographique de ses clients pourrait simplement demander à l’interpréteur de créer une carte de chaleur à partir de ses données de vente. Ce qui aurait autrefois exigé des heures de travail manuel – nettoyage des données, apprentissage d’une bibliothèque de visualisation, écriture du code – se résume maintenant à une simple instruction en langage naturel.

    L’impact de l’interpréteur ouvert sur l’analyse de données est donc profond, démocratisant l’accès à des insights complexes et facilitant une prise de décision basée sur des données pour un éventail beaucoup plus large d’individus et d’organisations. Il marque une étape significative vers la réinvention de l’utilisation de l’ordinateur, où la complexité technique cède la place à l’intuitivité et à l’accessibilité.

    Conclusions

    L’interpréteur ouvert transforme radicalement notre approche de l’utilisation de l’ordinateur. À travers une simple conversation, il réduit la barrière technique et démocratise l’accès à des opérations complexes pour tout utilisateur.

  • Neque porro quisquam est qui

    Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?

    Nullam ac erat. Donec a ipsum. Nullam tristique leo id lacus. Sed sed pede non arcu ornare interdum. Maecenas justo elit, rutrum in, adipiscing id, laoreet in, libero. Fusce quam. Donec a urna a enim gravida dictum. Nunc elementum, mauris sit amet imperdiet iaculis, dolor metus consectetuer mi, et tempor elit enim at massa. Duis ac nisl. Nullam pulvinar. Curabitur quam sapien, lobortis eu, luctus vitae, volutpat ac, metus. Nam elementum. Fusce fringilla. Praesent pulvinar turpis vitae justo cursus pulvinar. In hac habitasse platea dictumst. Nunc fermentum tellus interdum libero. Phasellus eros. Vestibulum euismod nunc at eros. Pellentesque nec ligula non tellus accumsan molestie. Pellentesque felis massa, tincidunt at, pulvinar id, placerat nec, velit.

    Cras rhoncus ipsum ac dolor. In hac habitasse platea dictumst. Nulla dapibus ultricies pede. Quisque augue risus, porttitor nec, suscipit ut, pellentesque quis, lacus. Duis adipiscing purus eu metus pharetra porttitor. Aenean sapien nisi, sodales non, facilisis nec, ultricies et, erat. Cras aliquam. Maecenas mi. Sed lacus arcu, malesuada id, ultricies et, ornare non, dolor. Maecenas turpis lacus, vehicula nec, blandit in, laoreet a, nibh. Donec aliquet. In et leo tincidunt tortor rhoncus convallis. Nulla facilisi. Praesent bibendum semper eros. Morbi risus. Nam tellus leo, ullamcorper egestas, venenatis quis, viverra ac, mauris. In hac habitasse platea dictumst. Curabitur at velit vel sem auctor hendrerit. Integer mauris orci, vehicula eu, feugiat ac, hendrerit ut, dolor. Fusce elit nulla, gravida quis, vulputate eu, rutrum vel, lectus. Integer cursus luctus nisl. Quisque quam. Aliquam lectus urna, porta in, viverra eu, pellentesque a, massa. Etiam eros sapien, porta et, aliquam et, bibendum sit amet, erat. Sed condimentum interdum lacus. In ut ante non felis tincidunt porta. Aenean aliquet ornare sem. Nunc dignissim, erat sit amet vulputate cursus, elit magna facilisis massa, quis hendrerit nunc odio id dui. Proin interdum dictum arcu. Pellentesque erat ante, ultricies ac, porttitor ac, dictum et, purus. Donec enim odio, gravida ut, imperdiet quis, rutrum ut, lacus.

    Etiam pharetra scelerisque diam. Maecenas varius augue vel urna. Vestibulum erat nisl, fringilla vel, mollis et, aliquam non, elit. Nulla malesuada turpis nec velit. Donec vitae sem a metus dictum molestie. Ut dignissim, odio non porttitor convallis, sapien leo viverra lorem, a consequat mauris erat sit amet dui. Nullam rutrum feugiat massa. Nullam lacinia purus vitae massa. Pellentesque vel tortor eget nulla ullamcorper vehicula. Cras egestas euismod magna. Praesent laoreet aliquet nulla. Aliquam arcu. Proin vel neque non ligula sodales sagittis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Sed magna. Pellentesque aliquet mollis arcu. Morbi at felis. Suspendisse ligula. Aliquam nisl arcu, vehicula vitae, hendrerit ut, sodales eu, augue. Sed tristique pretium risus. Ut luctus, dui quis commodo luctus, quam nulla ultricies lorem, eu ornare nulla metus at leo. Praesent rhoncus sapien sit amet mauris. Aenean commodo erat eu eros. Morbi tristique, risus sed consequat bibendum, enim augue tincidunt quam, ac semper libero velit vitae eros.