Patrons

Les patrons d'échanges au niveau fonctionnel sont au nombre de 3.

1. Propagation de donnée (Data Exchange)

2. Envoi/Réception d'un événement (Event)

3. Appel d'une règle distante (Service).

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.

Vision simpliste

L’approche simpliste consiste à appréhender une propagation d’une données entre 2 systèmes.

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.

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.

Arbre de décision

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:

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.

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.

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.