Dans un contexte de production, suivre ses flux peut s’avérer une tâche très complexe. Parmi les nombreux processus en exécution, difficile de trouver celui correspondant à une action effectuée sur un applicatif en amont. La complexité en est d’autant plus élevée si les flux traversent plusieurs plateformes Middlewares tel que l’OSB et la SOA Suite.

Cependant Oracle met à notre disposition une panoplie d’outils, de capteurs permettant de remonter les informations nécessaires dans les consoles de contrôle de ses différents applicatifs. Voici une proposition de méthodologie pour suivre vos flux de votre plateforme Middleware Oracle.

Il s’agit en priorité de déterminer les informations pertinentes vous permettant de retrouver efficacement le processus recherché. Il est de bon usage de concaténer à vos flux de données des méta-donnés techniques pour identifier sa provenance.

Voici un exemple d’un flux de données client:

 <CUSTOMER>
   <CUSTOMER_ID>0024735575</CUSTOMER_ID>
   <GENDER>male</GENDER>
   <COMPANY>Easyteam</COMPANY>
   <FIRST_NAME>Martin</FIRST_NAME>
   <LAST_NAME>Dupont</LAST_NAME>
   <STREET>12 rue Emile Zola</STREET>
   <ZIP_CODE>62220</ZIP_CODE>
   <CITY>Carvin</CITY>
   <COUNTRY>France</COUNTRY>
 </CUSTOMER>

A l’initialisation du flux dans l’OSB nous ajouterons les données techniques suivantes afin de retrouver le flux efficacement, en voici un exemple :

 <TECHNICAL_METADATA>
   <STREAM_ID>898AF39E-125E-88BC-BAF3-420EFA87</STREAM_ID>
   <STREAM_SOURCE_COMPONENT>crm</STREAM_SOURCE_COMPONENT>
   <STREAM_DATE>2009-09-07T00:00:00</STREAM_DATE>
   <STREAM_ACTION>create</STREAM_ACTION>
 </TECHNICAL_METADATA>

Dans ce flux nous distinguons 2 types de données:

• Métiers : le client (CUSTOMER)
• Techniques : les données d’informations (TECHNICAL_METADATA)

Pour surveiller ce flux et le retrouver au plus vite nous utiliserons un assortiment de données métiers et techniques. Dans ce cas nous exploiterons les données suivantes : CUSTOMER_ID, STREAM_ID, STREAM_SOURCE_COMPONENT, STREAM_ACTION

Notez le STREAM_ID qui identifie le flux de manière unique. Il peut être généré à l’initialisation du flux dans l’OSB grâce à la fonction XQuery fn-bea:uuid() ou dans le composite grâce à la fonction XPATH oraext:generate-guid().

Mise en place

Composite

Voici un composite d’exemple très simple :

Le suivi des flux s’effectue à 2 niveaux :

• Le nom du composite (identifiant unique)
• Les sensors de composite (informations techniques et métiers)

Nous placerons 3 sensors sur l’entrée du composite.

Création du sensor « ClientID ».

Puis la création des sensors « ComposantSource » et « Action »

Pour renseigner le nom du composite, nous utilisons l’action « assign » du mediator.

Puis utiliser la fonction XPATH setCompositeInstanceTitle pour affecter le nom du composite;

OSB

Voici un proxy service d’exemple :

Comme évoqué plus tôt, il est possible de générer l’indentifiant unique du flux.

Puis on utilise une activité « MessageReport » pour mettre à jour les index nécessaires à la surveillance du flux.

Nous avons repris ici, l’ensemble des informations des sensors Composite à savoir « ClientID », « ComposantSource » et « Action » ainsi que l’identifiant du composite ici représenté par la donnée « FluxID ».

Suivi des flux

OSB

Voici comment suivre votre processus grâce aux capteurs mis en place.

Nous invoquons notre processus via la console OSB avec les données clients évoquées au début de l’article.

La donnée « ClientID » est connue car elle provient du champs Customer_ID des données d’entrée, tandis que les 3 autres données sont affectées au début du proxy OSB. C’est donc sur le ClientID que portera la recherche (Interface ConsoleOSB -> Operations -> Reporting -> Message Reports).

Nous pouvons ensuite consulter les détails du flux en cliquant sur celui-ci et observer les 4 indicateurs de suivis mis à jour.

Et consulter le payload du message pour s’assurer de l’intégrité des données.

Détail du message Report :

<CUSTOMER_STREAM>
  <CUSTOMER>
    <CUSTOMER_ID>0024735575</CUSTOMER_ID>
    <GENDER>male</GENDER>
    <COMPANY>Easyteam</COMPANY>
    <FIRST_NAME>Martin</FIRST_NAME>
    <LAST_NAME>Dupont</LAST_NAME>
    <STREET>12 rue Emile Zola</STREET>
    <ZIP_CODE>62220</ZIP_CODE>
    <CITY>Carvin</CITY>
    <COUNTRY>France</COUNTRY>
  </CUSTOMER>
  <TECHNICAL_METADATA>
    <STREAM_ID>f532fb80-72cb-4588-b54b-0a8358fad78e</STREAM_ID>
    <STREAM_SOURCE_COMPONENT>crm</STREAM_SOURCE_COMPONENT>
    <STREAM_DATE>2009-11-25T08:30:17.479-08:00</STREAM_DATE>
    <STREAM_ACTION>create</STREAM_ACTION>
  </TECHNICAL_METADATA>
</CUSTOMER_STREAM>

Composite

A partir des informations recueillies dans l’OSB, nous avons plusieurs possibilités pour retrouver le flux concerné.

La première en recherchant dans la colonne « nom » l’identifiant unique du flux récupéré dans la donnée « FluxID » du message report OSB.

A l’identique de l’OSB, il est possible de rechercher via le ClientID. Pour cela, il est nécessaire d’ajouter le champs de recherche correspondant.

Puis de saisir le numéro de client dans le champs concerné.

La colonne « Détecteurs de composite » nous permet de consulter l’ensemble des données remontées par le composite sur lesquelles nous pourrions effectuer des recherches.

Cet article vous propose une méthodologie parmi d’autre pour le suivi de vos flux, libre à vous de l’adapter à vos besoin. Vous avez maintenant tous les clés en main pour rechercher et suivre vos processus et flux de données de plateforme en plateforme.

Si vous voulez le tester par vous-même, voici le projet OSB (OSBProxy.jar) et l’application composite (SoaComposite.zip) de cette démonstration.