BizTalk – le BAM sans le BOUM

Comment mettre en place le suivi des flux Biztalk dans une table générique via Business Activity Manager ?

Lorsque l’on veut augmenter la visibilité d’une plate-forme de Mediation qui, de plus, possède un bagage fonctionnel complexe, il peut s’avérer très utile de tracer chaque message entrant et de connaître quels flux ce message a déclenché. Ce besoin est appelé le monitoring de l’usage. Comme démontré lors de la session sur le monitoring au BizTalk Summit 2015, plusieurs solutions peuvent être mises en place :

Dans cet article, nous allons illustrer le monitoring via le module natif de BizTalk : le BAM. L’objectif sera de pouvoir suivre et exploiter l’activité des demi-flux s’exécutant sur la plate-forme de médiation, tout en stockant les messages d’erreurs s’ils surviennent.

Dans le cas proposé, nous allons créer deux structures génériques (tables), une pour les demi-flux entrants, une pour les demi-flux sortants qui contiendront les informations fonctionnelles et techniques pertinentes présentes pour chaque flux.

Les informations  collectées pour chaque demi-flux entrant sont :

• Start_Date
• End_Date
• Object_Type
• InputHalfFlow
• Action
• Object_ TechnicalId
• Object_FunctionalId
• Error_Message

Dans notre exemple, elles sont identiques aux informations  collectées pour chaque demi-flux sortant :

• Start_Date
• End_Date
• Object_Type
• OutputHalfFlow
• Action
• Object_ TechnicalId
• Object_FunctionalId
• Error_Message

Ces deux structures seront valorisées pour chaque demi-flux exécuté. Nous aurons ainsi l’historique “utile” des exécutions et l’exploitation de la table via des requêtes ou un portail client serait aisé.

Installation du module et du portail BAM

La première étape est d’installer le module de BAM et portail associé. Cela est très intuitif, le seul point d’attention est de créer/définir le groupe AD dédié aux futurs utilisateurs du portail.

Le BAM fonctionne avec les “activités“, ce sont en fait nos futures tables. Nous allons en créer deux : une pour les demi-flux entrants “INPUT_HALF_FLOW”, une pour les demi-flux sortants “OUTPUT_HALF_FLOW”, en ajoutant à chaque activité les champs définis plus tôt.

Cela se fait via un fichier XML de définition des tâches, qui se crée avec l’add-in Excel pour BAM. Ici, nous avons une activité “demi flux entrant” et une activité “demi-flux sortant”.

Point d’attention : Cet add-in fonctionne uniquement avec Excel 64 bits !

Parallèlement aux activités, nous créons les vues « métier » associées. Dans notre cas, ce sera exactement les mêmes informations.

Autour du BAM, il est fréquent de lire les mots « dimensions », « mesures »,« fréquences ». Il n’est pas évident de s’y repérer ! Pour notre besoin, ces concepts ne sont pas utiles.

Une fois le fichier de définition créé (un XML généré automatiquement par add-in), il faut le déployer. Cela se fait via la commande :

​ "%BTSINSTALLPATH%Tracking\bm.exe" deploy-all -DefinitionFile:.\Mediation.xml

Ce déploiement va en fait créer les tables et vues à l’image du fichier XML dans la base de données BAMPrimaryImport. Ce sont ces tables et vues qui pourront précisément être exploitées par la suite.

Remarque : Il n’est pas possible de modifier les vues en déployant un nouveau fichier de définitions directement. Si un changement doit se faire, il faut désinstaller la vue avec l’ancien fichier, puis redéployer la nouvelle version du fichier de définitions. On peut déployer sans désinstallation préalable uniquement si le changement est un ajout.

Modification des orchestrations

Maintenant que notre structure/base de données est prête, nous allons la valoriser. Cela se fait via les méthodes BeginActivity, UpdateActivity et EndActivity de la classe Microsoft.BizTalk.Bam.EventObservation. Nous allons les ajouter dans chaque orchestration de demi-flux aux endroits stratégiques via les shapes d’expression :

Dans chaque shape, l’appel sera fait aux méthodes définies de la manière suivante :

​ public static void UpdateActivityOutputHalfFlow(String activityName, String activityID, String notifAction
            , String notifOutputHalfFlow
            , String notifObjectType, String notifObjectId, String notifId
            )
        {

            BamEventStream.UpdateActivity(activityName, activityID
               , "Notif_Action", notifAction
                , "Notif_OutputHalfFlow", notifOutputHalfFlow
                , "Object_Type", notifObjectType
                , "CurrentSystemObject_Id", notifObjectId
               );

            BamEventStream.AddRelatedActivity(activityName, activityID, "INPUT_HALF_FLOW", notifId);
        }

L’astuce est d’utiliser la méthode AddRelatedActivity pour le demi-flux sortant en lui passant la propriété BTS.InterchangeID. Ainsi, chaque demi-flux sortant est lié à son demi-flux entrant ! Il arrive que les méthodes de mise à jour des activités n’aient pas le même temps d’exécution, et afin d’éviter des activités « zombies », il est intéressant d’utiliser le mode asynchrone via la méthode BufferedEventStream () avec l’option flush activée.

Une fois nos orchestrations déployées, le tour est joué !

Astuce : Lors du développement avec BAM, la table TDD_Failed est d’une aide précieuse car elle stocke les erreurs à l’exécution.

Exploitation

Nous avons ainsi à notre disposition des vues qui ont pour chaque demi-flux entrant les identifiants fonctionnels, et dont nous sommes capables de tracer les demi-flux sortants déclenchés.

Pour exploiter ces vues, un portail BAM est installé par défaut. Cependant, on atteint vite ses limites. Une des solutions les plus efficaces est PowerBI dans Excel.

La dernière étape de mise en place est le paramétrage de l’archivage (et purge si nécessaire) de la base de données du BAM. Ceci n’est pas automatique, une commande créé un package SSIS pour l’archivage :

​"%BTSINSTALLPATH%Tracking\bm.exe" set-activitywindow -Activity:INPUT_HALF_FLOW -TimeLength:1 -TimeUnit:Day

Ensuite, il n’y a plus qu’à créer un job qui va exécuter cet SSIS :

Conclusion

Le BAM est efficace pour la trace précise de chaque message. Via le système des structures génériques, on a rapidement les informations voulues. La mise en place est aisée, une fois les astuces de ce post appliquées 🙂 Cependant, l’exploitation de ces données tant précieuses via le portail natif n’est pas confortable. Peu ou pas intuitif, ni « user-friendly », le portail n’a pas bénéficié du même refactoring que le reste du produit BizTalk et atteint rapidement ses limites :

Il est alors intéressant de se tourner vers Power BI pour rendre accessibles et valoriser les données collectées. Nous allons voir comment le faire dans la prochaine publication de la série. J’espère que cet article vous permettra de mettre en place le BAM sans le boom ;).