| Page Properties | ||||||
|---|---|---|---|---|---|---|
|
| Table of Contents |
|---|
Patrons
Les patrons d'échanges au niveau fonctionnel sont au nombre de 3.
Propagation de donnée (Data Exchange)
Envoi/Réception d'un événement (Event)
Appel d'une règle distante (Service).
| Info |
|---|
Ces patrons sont simples afin d'être facilement pris en main par les équipes métier. |
Pour faire le choix d'un bon patron, il faut dans un 1er temps se demander ce qui est transporté.
Par exemple:
la fiche client (une donnée),
la clôture de facture (un événement),
le taux de TVA (un résultat calculé).
Moyens d'échange
Les patrons définissent la typologie de l'échange. Il est ensuite nécessaire de préciser quel sera son moyen.
En fonction du pattern fonctionnel, le moyen est différent.
Propagation de donnée(s)
Ce patron est un échange d'une donnée entre plusieurs systèmes. Il n'y a pas de réponse ou d'accusé réception correspondant.
| Note |
|---|
La structure de la donnée peut être importante et comporter des données liées. Exemple: Pour une donnée Facture transportée, elle peut être accompagnée de Client + n Adresses + n Produits. |
Vision simpliste
L’approche simpliste consiste à appréhender une propagation d’une données entre 2 systèmes.
| Plantuml | ||||
|---|---|---|---|---|
| ||||
{"umlDefinition":"\"Système A\" --> \"Système B\": donnée"} |
Cas complexes
Toutefois, la production de la donnée cible peut-être la combinaison de n données provenant d’1 ou plusieurs systèmes.
| Plantuml | ||||
|---|---|---|---|---|
| ||||
{"umlDefinition":""} |
Moyens de l'échange
Les moyens d'échanges sont des patterns techniques:
Echange B2B
Echange Fichier
Echange Message (ie. Patterns applicatifs de Messages)
Echange Service = Pattern Service (ie. Patterns applicatifs de Services)
Echange API (ie Pattern Ressource API)
Pour déterminer ce moyen, il faut identifier comment le système cible manipule la donnée récupérée.
Unitairement. La donnée est utilisée pour permettre le déroulement lors d'une ou plusieurs activités métier.
Ensembliste. Toutes les données sont manipulées, analysées pour réaliser des opérations ensemblistes telles que des opérations statistiques, des agrégations, etc.
| Warning |
|---|
Une manipulation en série des données d'un ensemble correspond au cas n°1: Unitaire. |
Arbre de décision
| Power plant uml macro | ||||||
|---|---|---|---|---|---|---|
|
| Note |
|---|
Cet arbre cherche à minimiser les persistances inutiles d'information. Il favorise les demandes de données lors de leur utilisation. |
Bonne pratique
La préoccupation 1ère est l'usage faite de la donnée par le consommateur (celui qui reçoit et utilise la donnée). Le rythme du producteur cherche à s'y adapter.
Evénement
La propagation d'événements est similaire à la propagation de données mais avec une différence essentielle:
| Info |
|---|
un événement se rapporte à une donnée mais ne la porte pas. |
L'objectif 1er de l'échange d'événements est de pouvoir corréler des comportements au travers de plusieurs événements.
Par exemple:
déclencher une promotion lors de la sélection d'articles dans le panier.
lever une alerte si un colis n'a pas été livré 48h après sa commande.
envoyer un mail lorsque la boite aux lettres est pleine
.
L’événement est accompagnée de l’ID de la donnée de référence. S'il véhicule la donnée, celle-ci n’est pas une référence, seulement un état. La donnée a pu changer depuis.
Bonnes pratiques
Il faut privilégier l'envoi d'événement par l'ESB ou par le moteur de Workflow. Il s'agit souvent d'une responsabilité transverse ou à réception/émission d'un message ou un service. Toutefois, le système émetteur est toujours le déclencheur si des règles fonctionnelles rentrent en jeu.
Il n’est pas possible que la donnée véhiculée soit référente car non valorisable.
Si un Event et un Data-Exchange sont liés, vérifier qu'ils ne sont pas égal à un Service (ie. 1 Event IN + 1 DataExchange OUT = 1 Service).
Un moteur Complexe Event Processing (CEP) est l'architecture typique support aux traitements de ces événements.
Arbre de décision
L'arbre de décision concerne la localisation.
| Plantuml |
|---|
start if (Qui déclenche l'envoi ?) then (règle métier) :Emission depuis l'application; else (réception|l'émission d'un Service|Evenement) :Emission dans l'ESB; endif stop |
Déclinaison applicative
La déclinaison est conduite par le Patterns applicatifs d'Evenements.
Service
Le système cible (consommateur) a besoin d'une donnée calculée ou d'un résultat de plusieurs règles.
Classiquement, le système source (producteur) expose des règles sur les données qu'il possède. Les consommateurs demandent des opérations sur des données référencées (en indiquant juste l'ID de l'objet).
Si le producteur a besoin de données en dehors de son périmètre, le consommateur doit lui fournir ce périmètre supplémentaire.
| Warning |
|---|
Il est interdit de rapatrier des données unitaires pour réaliser un calcul sur le seul périmètre rapatriées. Ce service doit être proposé par le maître des données. |
Bonne pratique
Il peut être pertinent d'identifier le bon patterns technique de Service avec les référents fonctionnels. Ceci dans l'objectif de trouver au plus tôt d'autres services sous-jacents.
Déclinaison applicative
La déclinaison est conduite par les Patterns applicatifs de Services.