Introduction

Dans cet article, nous explorerons différentes approches permettant d'étendre et de personnaliser le comportement des routeurs de messages d'interopérabilité intégrés à InterSystems IRIS (et IRIS Health).

Les routeurs de messages remplissent l'une des fonctions essentielles de l'intégration d'applications d'entreprise (EAI) et font partie des processus métier les plus fréquemment utilisés dans les productions d'interopérabilité.

Après un bref aperçu des classes de routeurs de messages intégrés dans InterSystems IRIS et IRIS for Health, cet article expliquera comment améliorer leurs capacités afin d'obtenir des résultats spécifiques, sans avoir à développer un processus métier à partir de zéro.

Une mise en garde s'impose : la plupart de ces techniques impliquent de remplacer les méthodes de l'implémentation actuelle des classes de routeurs de messages dans IRIS Data Platform et IRIS for Health 2025.x. Elles peuvent ne pas s'appliquer à d'autres versions antérieures ou futures. 

Le référentiel GitHub qui accompagne cet article contient une collection d'exemples simples, minimalistes et volontairement abstraits illustrant les techniques abordées.

Nous vous invitons à nous faire part de vos avis, commentaires et retours constructifs!

Classes de routeurs

IRIS est fourni avec plusieurs classes de routeurs de messages de processus métier intégrées. La classe de base pour toutes ces classes est EnsLib.MsgRouter.RoutingEngine

Dans la plate-forme de données IRIS, plusieurs sous-classes spécialisées s’étendent à cette base:

• EnsLib.MsgRouter.RoutingEngineST: Améliore le routage en remplissant une table de recherche (consultez Ens.VDoc.SearchTable) pour chaque message entrant.
• EnsLib.MsgRouter.VDocRoutingEngine: gère le routage des messages, en implémentant Ens.VDoc.Interface.
• EnsLib.EDI.MsgRouter.SegmentedRoutingEngine: Routes segmented EDI messages.
• EnsLib.EDI.X12.MsgRouter.RoutingEngine: achemine les messages X12.

IRIS for Health dispose d'une sous-classe supplémentaire:

• EnsLib.HL7.MsgRouter.RoutingEngine qui est une extension de EnsLib.EDI.MsgRouter.SegmentedRoutingEngine pour prendre en charge le routage des messages HL7 v2.x, qui sont des instances de EnsLib.HL7.Message.

Toutes les classes de routeurs partagent le cycle de vie des processus métier hérité de Ens.BusinessProcess et ont un flux d'exécution commun implémenté par la méthode EnsLib.MsgRouter.RoutingEngine OnRequest(), qui exécute la séquence suivante: 

• Si la propriété Validation est définie, validez le message en appelant OnValidate().
• Si la validation échoue, traitez le message mal formé.
• Évaluez les règles et effectuez les actions résultantes en appelant doOneAction().

L'implémentation par défaut de OnValidate() ne fait rien. Des sous-classes spécialisées implémentent ce message pour valider les messages entrants. Par exemple, EnsLib.HL7.MsgRouter.RoutingEngine OnValidate() utilise EnsLib.HL7.Util.Validator pour vérifier le message HL7 entrant.

Si la validation échoue, les messages mal formés sont envoyés de manière asynchrone à la configuration cible BadMessageHandler, et OnError() est appelé, en passant le statut d'erreur et “0_!_Validation” comme clé d'achèvement.

L'évaluation des règles est implémentée de manière récursive par doOneAction().

Vous pouvez personnaliser le comportement de routage en remplaçant les méthodes clés suivantes dans votre classe de routage de messages personnalisée (qui étend une classe de routage intégrée):

• OnRequest() et autres méthodes de rappel du cycle de vie des processus métier: pour ajouter un prétraitement ou un post-traitement, ou définir des propriétés de routeur pouvant être utilisées lors de l'évaluation des règles.
• OnValidate(): pour personnaliser la validation des messages entrants.
• doOneAction(): pour modifier le comportement des actions.
• OnError(): pour implémenter une gestion personnalisée des erreurs.
• OnResponse(): pour implémenter une gestion personnalisée des réponses.
• OnTimeout(): pour implémenter une gestion personnalisée des délais d'expiration.

Implémentation du prétraitement ou du post-traitement

Comme le routeur est un processus métier, vous pouvez remplacer ses méthodes de rappel pour effectuer un prétraitement ou un post-traitement, ou une gestion personnalisée des erreurs:

• OnRequest()
• OnResponse()
• OnComplete()
• OnTimeout()

Ajout de propriétés au routeur en remplaçant OnRequest()

Lors de l'évaluation des règles, les propriétés du routeur sont disponibles à la fois dans la logique des règles métier (par exemple, dans les expressions booléennes des conditions “when”) et lors de l'exécution de la transformation des données. Pour cela, le routeur transmet une référence à lui-même via l'argument auxiliaire aux. aux.

Les classes de routeurs intégrées n'exposent qu'un contexte limité : le message entrant et les propriétés liées à l'ensemble de règles, telles que RuleActionData ou les variables @ temporaires définies dans la règle (consultez Utilisation des règles).

Pour intégrer des données de contexte supplémentaires lors du routage des messages, vous pouvez créer une sous-classe d'un routeur intégré, ajouter des propriétés personnalisées et remplacer sa méthode 

 afin de définir ces propriétés avant l'exécution de la logique réelle du routeur. Cela vous permet d'enrichir la logique de routage en injectant des propriétés personnalisées ou des métadonnées dans le processus d'évaluation des règles et de transformation des données. 

Vous pouvez, par exemple, récupérer des données supplémentaires en interrogeant la base de données, ou envoyer une requête synchrone à un autre processus métier ou à une autre opération métier, en utilisant la réponse pour enrichir le contexte de routage.

Remplaçons OnRequest() pour montrer comment ajouter une propriété de contexte disponible pendant l'évaluation des règles:

Class dc.routing.examples.VariableTargetRouter Extends EnsLib.MsgRouter.RoutingEngine
{

Method doOneAction(pRequest As %Persistent, pOneAction As %String, Output pQuitProcessing As %Boolean, pLevel As %Integer = 1, Output pSyncResponse As %Persistent) As %Status
{
  #Dim sc as %Status
  #Dim ex as %Exception.AbstractException
  s sc = $$$OK
  try {
    if $piece(pOneAction,":",1)="send" {
      s $piece(pOneAction,":",2) = ##class(Ens.Rule.ExpressionParser).Evaluate($piece(pOneAction,":",2),$this,.errorMsg)
    }
    $$$TOE(sc,##super(pRequest,pOneAction,.pQuitProcessing,pLevel,.pSyncResponse))
  } catch (ex) {
    s sc = ex.AsStatus()
  }
  return sc
}

Storage Default
{
<Type>%Storage.Persistent</Type>
}

}

J'ai appliqué cette technique à plusieurs reprises dans des scénarios concrets. Un exemple concerne la récupération d'informations détaillées sur des produits médicaux à partir d'un système de gestion de pharmacie afin d'orienter les décisions de routage et de modifier les demandes sortantes. Le routeur remplace la méthode OnRequest() lançant un appel vers une opération qui s'interface avec l'API du système de pharmacie. L'opération renvoie des données enrichies sur les produits, qui sont ensuite soumises aux règles de routage et aux transformations de données en tant que propriété objet du routeur.

Exécution d'une validation de message personnalisée

Lors de l'exécution de la méthode OnRequest() pendant le traitement des messages entrants, le routeur appelle OnValidate(). Bien que l'implémentation par défaut n'effectue aucune action dans EnsLib.MsgRouter.RoutingEngine, les classes comme EnsLib.HL7.MsgRouter.RoutingEngine remplaçent OnValidate() pour permettre la vérification des messages HL7 v2.x.

Personnalisons la validation des messages HL7 en remplaçant OnValidate()et en utilisant différentes spécifications de vérification, en fonction de la source du message:

Class dc.routing.examples.CustomValidationRouter Extends EnsLib.HL7.MsgRouter.RoutingEngine
{

Parameter SETTINGS = "CustomValidation";
Property CustomValidation As %String(MAXLEN = 240);
Method OnValidate(pDoc As EnsLib.HL7.Message, pValSpec As %String, Output pStatus As %Status = {$$$OK}) As %Boolean
{
  #Dim ex as %Exception.AbstractException
  #Dim result as %Boolean
  s pStatus = $$$OK
  s result = 0
  try {    
   s result = ##super(pDoc,..GetCustomValidationSpec(pDoc,pValSpec),.pStatus)
  } catch (ex) {
    s pStatus = ex.AsStatus()
  }
  return result
}

Method GetCustomValidationSpec(request As EnsLib.HL7.Message, defaultSpec As %String) As %String
{
  s result = defaultSpec
  s specList = $listfromstring(..CustomValidation)
  s ptr = 0
  while $listnext(specList,ptr,spec) {
    if $piece(spec,"=",1)=..%PrimaryRequestHeader.SourceConfigName {
      s result = $piece(spec,"=",2)
      quit
    }
  }
  return result
}

}

En pratique, lorsque vous travaillez avec le routage HL7, le remplacement de la méthode OnValidate() existante et non vide vous permet, par exemple, d'accepter comme valides les messages comportant des segments personnalisés (Zxx) non finaux, sans avoir à recourir à un schéma HL7 personnalisé.

Modification du comportement de l'action

Pendant l'évaluation de la règle, le routeur appelle la méthode doOneAction() de manière récursive pour exécuter des actions telles que send, delete, delegate et rule, où l'action "rule" elle-même peut déclencher un autre appel récursif de doOneAction().

La signature de la méthode est la suivante:

Method doOneAction(pRequest As %Persistent, pOneAction As %String, Output pQuitProcessing As %Boolean, pLevel As %Integer = 1, Output pSyncResponse As %Persistent) As %Status

Les arguments sont transmis lors de l'exécution de OnRequest() et ont les valeurs suivantes:

• pRequest est un message entrant.
• pOneAction est une liste de jetons délimités par “:” décrivant l'action à entreprendre: 
  • $piece(pOneAction,”:”,1) est le type d'action (envoyer, supprimer, règler ou déléguer).
  • $piece(pOneAction,”:”,2) est l'argument de chaîne de l'action ‘send’ (envoyer).
  • $piece(pOneAction,”:”,3) est l'argument de transformation de l'action ‘send’ (envoyer).
  • $piece(pOneAction,”:”,4) est le texte expliquant la raison de l'action.

Pour personnaliser le comportement des actions, nous pouvons remplacer cette méthode. Par exemple, nous pouvons faire en sorte que l'action “send” évalue dynamiquement une expression et exploite toutes les propriétés disponibles pendant l'évaluation de la règle de routage:

Toute modification dans la façon dont le routeur interprète les actions doit, bien sûr, être prise en compte dans la règle de routage.

Dans cet exemple, les littéraux de chaîne doivent désormais être placés entre guillemets doubles, et comme l'argument entier est considéré comme une chaîne par le générateur de code de règle, les guillemets doivent être doublés pour éviter tout conflit.

Dans la règle de routage, l'argument send est une expression qui est évaluée comme la cible de l'action send.

Class dc.routing.examples.VariableTargetRouter Extends EnsLib.MsgRouter.RoutingEngine
{

Method doOneAction(pRequest As %Persistent, pOneAction As %String, Output pQuitProcessing As %Boolean, pLevel As %Integer = 1, Output pSyncResponse As %Persistent) As %Status
{
  #Dim sc as %Status
  #Dim ex as %Exception.AbstractException
  s sc = $$$OK
  try {
    if $piece(pOneAction,":",1)="send" {
      s $piece(pOneAction,":",2) = ##class(Ens.Rule.ExpressionParser).Evaluate($piece(pOneAction,":",2),$this,.errorMsg)
    }
    $$$TOE(sc,##super(pRequest,pOneAction,.pQuitProcessing,pLevel,.pSyncResponse))
  } catch (ex) {
    s sc = ex.AsStatus()
  }
  return sc
}

Storage Default
{
<Type>%Storage.Persistent</Type>
}

}

@Thomas Haig ,cette technique répond à votre question sur la possibilité d'avoir une règle de routage avec une cible variable.

Cette technique peut également être utilisée lorsque la décision de router le message résultant ne peut être prise qu'après la transformation des données. 

En pratique, j'ai appliqué cette technique aux messages entrants provenant d'un système de commande de médicaments qui comprenait un mélange de demandes de réapprovisionnement en produits médicaux.

Certaines demandes étaient destinées au système central de pharmacie, tandis que d'autres ciblaient le système autonome de gestion des armoires.

Plutôt que de déployer deux routeurs distincts avec des ensembles de règles distincts, j'ai utilisé une logique conditionnelle pour acheminer le message transformé sur la base d'une expression évaluée à partir du message résultant de la transformation des données.