02 • 34 • 09 • 31 • 70
Dans un projet MDM, les "Golden Data" n'ont de valeur que si elle est partagée. Semarchy xDM propose un mécanisme pour propager ces données : les Data Notifications. Découvrez comment les implémenter.
Pourquoi utiliser les Data Notifications ?
Les notifications de données servent à exposer les données du référentiel vers l'extérieur dès qu'un changement survient. Elles agissent comme un "push" vers vos applications consommatrices.
Cas d'usages fréquents :
- Synchronisation temps réel : Alerter une application métier dès qu'un produit est enrichi
- Mise à jour via Middleware : Alimenter un système tiers qui doit réagir à des cycles de vie spécifiques (ex: dates de début/fin de validité)
- Pilotage par événements : Déclencher des processus en cascade après chaque certification de données
Structure d'une Data Notification
Une notification repose sur trois piliers indispensables :
1. Le Contenu (Named Query) : Une structure JSON définie dans le modèle qui sélectionne précisément les entités et attributs à exporter.
2. Le Déclencheur (Trigger) : L'événement qui lance l'envoi (fin de job de certification, modification d'une entité surveillée, ou planification horaire).
3. Le Destinataire (Target) : Le point de chute de la donnée (Serveur REST, file JMS, Kafka, etc.).
Guide d'implémantation pas à pas
Étape 1 : Créer la requête nommée (le"quoi")
Avant toute chose, définissez les données à envoyer.
- Le filtrage intelligent : Pour ne pas renvoyer tout le référentiel à chaque fois, utilisez les paramètres systèmes :QUERY_PARAM_PREVIOUS_BATCH et :QUERY_PARAM_CURRENT_BATCH.
- Conseil : Si votre requête cible des entités liées (ex: Tiers et ses Contacts), assurez-vous d'inclure le filtrage sur le BatchID pour l'entité parente ET les enfants afin de capturer toute les modifications.
Exemple : requête nommée sur tiers et ses contacts, contact étant enfant de tiers :
(
(BatchID > :QUERY_PARAM_PREVIOUS_BATCH AND BatchID <= :QUERY_PARAM_CURRENT_BATCH)
OR
(ANY Contacts HAS ( BatchID > :QUERY_PARAM_PREVIOUS_BATCH and BatchID <= :QUERY_PARAM_CURRENT_BATCH )
)
Étape 2 : Déploiement et test API
Une fois votre requête créée dans l'Application Builder, déployez votre modèle.
Validation Postman : Ne configurez pas la notification avant d'avoir testé votre endpoint REST via Postman. Vérifiez que le JSON retourné correspond exactement aux attentes de l'application cible.
Ajoutez ce Endpoint dans Postman et lancer la requête nommée
- Ajouter les paramètres CurrentBatch et PreviousBatch
- Ajouter dans Authorization un user (par défaut mettre en Basic Authentification : A renseigner)
- Ajouter dans Headers le paramètre Content-Type : application/json
Étape 3 : Configuration de la notification
Rendez-vous dans l'onglet Management de l'Application Builder.
1. Mapping des Batchs : Liez vos paramètres de requête aux variables HIGH_BATCH_ID et LOW_BATCH_ID. C'est ce qui garantit l'envoi incrémental.
2. Choix du Trigger : Pour une réactivité maximale, choisissez "Complétion du Batch" et ciblez les entités spécifiques à surveiller pour éviter des envois inutiles.
Pour tester, nous allons utiliser l’envoi de la notification à chaque complétion de batch couplé à une surveillance d’entités spécifiques : item & product. Si rien n’est précisé, elles sont toutes surveillées par défaut.
Test de bout en bout : du MDM au serveur Rest
Ajouter dans le paramétrage de votre data notification le serveur REST de destination à utiliser :
- Mettre l’URL REST à utiliser dans le champ URL de requête REST
- Activer la notification de données
- Réaliser une édition sur un Article :
Depuis le serveur REST on peut voir qu’une notification de données à bien été généré et déposé sur le serveur REST :
Conclusion
Les Data Notifications transforment Semarchy xDM d'un simple référentiel en un système dynamique et communicant avec le reste du système d’information.
Vous souhaitez bénéficier d'experts·es, de développeurs·euses, ou d'une formation sur Semarchy xDM ? Rendez-vous sur la page Contact !
