Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’échange de messages entre différents systèmes est une partie nécessaire de la résolution des problèmes que BizTalk Server résout. Toutefois, l’objectif réel est de définir et d’exécuter des processus métier basés sur les applications. Le moteur BizTalk Server utilise des orchestrations pour définir la logique de ces processus métier. Pour créer et évaluer des groupes de règles métier, il utilise le moteur de règles d’entreprise. Cette section décrit à la fois les orchestrations et le moteur de règles métier.
Utilisation d’orchestrations
La logique d’un processus métier automatisé peut être implémentée directement dans un langage tel que Microsoft Visual Basic ou Microsoft Visual C#. Pourtant, la création, la maintenance et la gestion de processus métier complexes dans les langages de programmation classiques peuvent être difficiles. Contrairement à ses prédécesseurs, BizTalk Server adopte une approche différente. Il permet aux responsables d’entreprise ou aux développeurs de définir graphiquement un processus métier. Cela peut être plus rapide que de créer le processus directement dans un langage de programmation, et il facilite également la compréhension, l’explication et la modification du processus. Les processus métier créés de cette manière peuvent également être surveillés plus facilement, un fait exploité par la technologie BAM (Business Activity Monitoring).
Pour un développeur, la création d’une orchestration repose sur trois outils principaux : l’éditeur BizTalk pour la création de schémas XML, le mappeur BizTalk pour définir des traductions entre ces schémas et le Concepteur d’orchestration pour spécifier la logique des processus métier. Tous ces outils sont hébergés dans Visual Studio, fournissant un environnement cohérent pour les développeurs. Cette section décrit ce que chacun de ces outils fait et comment ils fonctionnent ensemble.
Création de schémas : Éditeur BizTalk
Les orchestrations fonctionnent avec des documents XML, chacun étant conforme à un schéma XML. L’éditeur BizTalk permet aux développeurs de définir ces schémas, qui définissent essentiellement la structure et les types d’informations d’un document à l’aide du langage XSD (XML Schema Definition).
La création de schémas XSD bruts sans assistance d’un outil n’est pas simple. Pour rendre cette étape nécessaire plus accessible, l’éditeur BizTalk permet aux utilisateurs, probablement aux développeurs, de créer un schéma en définissant ses éléments dans une hiérarchie graphique. Les schémas existants peuvent également être importés à partir de fichiers ou de services Web accessibles. Cependant qu'ils soient acquis, les schémas sont utilisés comme base pour les cartes BizTalk.
Mappage entre les schémas : Le mappeur BizTalk
Une orchestration implémentant un processus métier reçoit généralement certains documents et envoie d’autres. Souvent, une partie des informations contenues dans les documents reçus est transférée aux documents envoyés, peut-être transformée d’une certaine manière. Par exemple, un processus de traitement des commandes peut recevoir une commande pour un certain nombre d’éléments, puis renvoyer un message indiquant que la commande a été refusée pour une raison quelconque. Les informations de la commande, telles qu’un identificateur de demande et la quantité ordonnée, peuvent être copiées à partir de champs dans le message de commande reçu dans les champs du message de rejet. Le mappeur BizTalk peut être utilisé pour définir une transformation, appelée carte, d’un document à l’autre.
Comme le montre la figure ci-dessus, chaque carte est exprimée sous la forme d’une corrélation graphique entre deux schémas XML qui définit une relation entre les éléments de ces schémas. Le World Wide Web Consortium (W3C) a défini la transformation XSLT (Extensible Stylesheet Language Transformation) comme moyen standard d’exprimer ces types de transformations entre les schémas XML, et ainsi les mappages dans BizTalk Server sont implémentés en tant que transformations XSLT.
La transformation définie dans une carte peut être simple, par exemple la copie de valeurs inchangées d’un document à un autre. Les copies de données directes telles que celles-ci sont exprimées à l’aide d’un lien, qui s’affiche dans le mappeur BizTalk en tant que ligne connectant les éléments appropriés dans le schéma source avec leurs équivalents dans le schéma de destination. Des transformations plus complexes sont également possibles à l’aide de fonctoids. Un fonctoid est un segment de code exécutable qui peut définir des mappages arbitrairement complexes entre les schémas XML, et comme illustré ci-dessus, le mappeur BizTalk le représente comme une zone sur la ligne qui connecte les éléments en cours de transformation. Étant donné que certaines de ces transformations sont assez courantes, BizTalk Server inclut un certain nombre de fonctoids intégrés. Ces fonctoids intégrés sont regroupés en catégories, notamment les suivantes :
Fonctoids mathématiques qui effectuent des opérations telles que l’ajout, la multiplication et la division des valeurs de champs dans le document source et le stockage du résultat dans un champ du document cible.
Fonctoids de conversion qui convertissent une valeur numérique en son équivalent ASCII et inversement.
Fonctoids logiques qui peuvent être utilisés pour déterminer si un élément ou un attribut doit être créé dans le document cible en fonction d’une comparaison logique entre les valeurs spécifiées dans le document source. Ces valeurs peuvent être comparées pour l’égalité, supérieures/inférieures à, et d’autres façons.
Fonctoids cumulés qui calculent des moyennes, des sommes ou d’autres valeurs provenant de différents champs du document source, puis stockent le résultat dans un seul champ dans le document cible.
Fonctoids de base de données qui peuvent accéder aux informations stockées dans une base de données.
Il est également possible de créer des fonctoids personnalisés directement dans XSLT ou à l’aide de langages compatibles avec .NET tels que Visual C# et Visual Basic. Les fonctoids peuvent également être combinés dans des séquences, en faisant cascader la sortie d’un dans l’entrée d’un autre.
Il est essentiel que vous ayez un moyen de définir le schéma XML d’un document, ainsi qu’un mécanisme de mappage d’informations entre les documents avec différents schémas. L’éditeur BizTalk et le mappeur BizTalk résolvent ces deux problèmes. Pourtant, la définition de schémas et de mappages ne fait qu’une partie du processus. Vous devez également spécifier la logique métier qui utilisera les schémas et invoquera les mappages.
Définition de la logique métier : Concepteur d’orchestration
Un processus métier est un ensemble d’actions qui répondent ensemble à certains besoins métier utiles. Avec BizTalk Server, un développeur peut utiliser le Concepteur d’orchestration pour définir ces actions graphiquement. Au lieu d’exprimer les étapes dans un langage de programmation, un développeur peut créer une orchestration en connectant une série de formes de manière logique. Les formes disponibles dans le Concepteur d’orchestration sont les suivantes :
Forme de réception, qui permet à l’orchestration de recevoir des messages. Une forme de réception peut avoir un filtre qui définit les types de messages qui seront reçus, et il peut également être configuré pour démarrer une nouvelle instance d’une orchestration lorsqu’un nouveau message arrive.
Forme d’envoi, qui permet à l’orchestration d’envoyer des messages.
Forme de port, qui définit la façon dont les messages sont transmis. Chaque instance d’une forme port est connectée à une forme d’envoi ou de réception. Chaque port a également un type, qui définit des éléments tels que les types de messages que le port peut recevoir ; une direction, telle que l’envoi ou la réception ; et une liaison, qui détermine comment un message est envoyé ou reçu par, par exemple, en spécifiant une URL particulière et d’autres informations.
Forme Decide, qui représente une instruction if-then-else qui permet à une orchestration d’effectuer différentes tâches en fonction des conditions booléennes. Un éditeur d’expressions, qui fait partie du Concepteur d’orchestration, peut être utilisé pour spécifier cette instruction conditionnelle.
Forme de boucle, qui contrôle l’exécution répétée d’une action alors que certaines conditions sont vraies.
La fonction "Construire un message", qui permet de créer un message.
La forme de transformation permet de transférer des informations d'un document à un autre et de les transformer en utilisant des mappages définis avec le BizTalk Mapper.
Forme Actions parallèles, qui permet à un développeur de spécifier que plusieurs opérations doivent être effectuées en parallèle plutôt qu’en séquence. La forme qui suit celle-ci n’est pas exécutée tant que toutes les actions parallèles ne sont pas terminées.
L'élément Scope, qui permet de regrouper des opérations en transactions et de définir des gestionnaires d'exceptions pour le traitement des erreurs. Les transactions atomiques traditionnelles et les transactions de longue durée sont prises en charge. Contrairement aux transactions atomiques, les transactions longues s'appuient sur une logique de compensation plutôt que sur l'annulation pour gérer des situations imprévues.
Forme d’affectation de message, qui permet d’affecter des valeurs à des variables d’orchestration. Ces variables peuvent être utilisées pour stocker des informations d’état utilisées par l’orchestration, telles qu’un message en cours de création ou une chaîne de caractères.
La figure ci-dessous montre une orchestration créée dans le Concepteur d’orchestration à l’aide de quelques-unes de ces formes. Dans cet exemple simple, un message est reçu, une décision est prise en fonction du contenu de ce message et l’un des deux chemins est exécuté suite à cette décision. Les orchestrations qui résolvent des problèmes réels peuvent être beaucoup plus complexes que cela ; pour faciliter l’utilisation de ces diagrammes plus complexes, le Concepteur d’orchestration inclut la possibilité de zoom avant et arrière. Les développeurs ne peuvent afficher que les parties d’une orchestration qui leur intéressent actuellement.
Une fois qu’un développeur a défini une orchestration, le groupe de formes et de relations entre eux est converti en msIL (Microsoft Intermediate Language) utilisé par le Common Language Runtime (CLR) du .NET Framework. En fin de compte, le groupe de formes défini par un développeur BizTalk Server devient juste un assembly standard compatible .NET. Vous pouvez également ajouter du code explicite à une orchestration si nécessaire en appelant un objet COM ou .NET à partir d’une forme.
Rôle des services web
Les services web permettent aux applications d’échanger des documents XML à l’aide de SOAP et ont eu un impact significatif sur les plateformes d’intégration. Pour accéder à un service web externe, le créateur d’une orchestration peut utiliser l’option Ajouter une référence web dans Visual Studio, ainsi que l’adaptateur de services web pour appeler directement des opérations. De même, BizTalk Server fournit un assistant de publication de services Web qui peut générer un projet de service Web ASP.NET exposant une ou plusieurs opérations d'orchestration comme des services Web pouvant être appelés via SOAP. Ces deux options permettent aux développeurs d’accéder aux services Web existants à partir d’un processus métier et d’exposer les fonctionnalités d’une orchestration en tant que service Web à d’autres processus métier.
La montée en puissance des services Web a également un impact sur la façon dont les processus métier sont définis. Par exemple, réfléchissez au cas où deux organisations interagissent à l’aide de services Web. Pour interopérer efficacement, il peut être nécessaire que chaque partie à l’interaction sache quelque chose sur le processus métier que l’autre utilise. Si les deux organisations utilisent BizTalk Server, ce n’est pas un gros problème ; des outils tels que la technologie de gestion des partenaires commerciaux peuvent être utilisés pour distribuer ces connaissances. Mais que se passe-t-il s’ils utilisent différents produits ? Dans des cas comme celui-ci, il est utile d’avoir un moyen de décrire les aspects des processus métier de manière non spécifique à un fournisseur.
Pour permettre cela, Microsoft, IBM et d’autres ont créé le langage d’exécution de processus métier (BPEL). Un processus métier défini à l’aide du Concepteur d’orchestration peut être exporté vers BPEL, et BizTalk Server peut également importer des processus définis dans BPEL. Bien que le langage soit utile pour décrire et partager des parties visibles en externe d’un processus métier, BPEL se concentre davantage sur la résolution de ce problème que sur l’exécution multiplateforme de processus métier complets. Il est également important de comprendre que BPEL est entièrement basé sur les services Web, tandis que BizTalk Server et d’autres produits qui prennent en charge ce langage fournissent plus d’informations. Par exemple, BizTalk Server prend en charge le mappage entre différents schémas XML, appeler des méthodes dans des objets locaux et d’autres fonctionnalités qui ne sont pas disponibles dans BPEL. Pour ces raisons et pour d’autres raisons, BPEL n’est pas un langage complet pour définir des processus métier. Et étant donné que BPEL est toujours en cours de normalisation par l’Organisation pour l’avancement des normes d’information structurée (OASIS), il est difficile de la considérer aujourd’hui comme une technologie entièrement mature.
Les orchestrations sont le mécanisme fondamental de création de processus métier dans BizTalk Server. Toutefois, certains aspects d’une orchestration ont tendance à changer plus souvent que d’autres. En particulier, les décisions incorporées dans un processus métier ( les règles métier) sont généralement son aspect le plus volatile. La limite de dépense d’un responsable était de 100 000 $ la semaine dernière, mais sa promotion la porte à 500 000 $, tandis que la commande maximale d'un client à paiement lent diminue de 100 unités à seulement 10 unités. Vous pouvez spécifier et mettre à jour ces règles à l’aide du moteur de règles d’entreprise.
Utilisation du moteur de règles métier
Le Concepteur d’orchestration, ainsi que l’éditeur BizTalk et le mappeur BizTalk, offrent un moyen efficace de définir un processus métier et les règles qu’il utilise. Toutefois, il peut être utile d’avoir un moyen plus simple de définir et de modifier les règles d’entreprise. Pour ce faire, BizTalk Server fournit le moteur de règles d’entreprise (BRE). Les développeurs utiliseront le bre le plus souvent, mais les utilisateurs plus orientés métier peuvent créer et modifier des ensembles de règles métier à l’aide d’un outil appelé Compositeur de règles métiers.
Une situation dans laquelle le BRE est utile est lorsqu’un ensemble complexe de règles d’entreprise doit être évalué. Décider s’il faut accorder un prêt, par exemple, peut impliquer de travailler sur un large ensemble de règles basées sur l’historique de crédit, le revenu et d’autres facteurs du client. De même, déterminer s’il faut vendre une assurance vie à un demandeur dépend d’un certain nombre de choses, y compris l’âge, le sexe et la santé du demandeur. Exprimer toutes ces règles sous forme d’instructions conditionnelles utilisant, par exemple, la forme Décider d’une orchestration peut être possible, mais serait assez complexe à implémenter. Pour les processus gourmands en règles comme ceux-ci, le BRE peut simplifier la vie d’un développeur.
À l’aide du BRE, les développeurs peuvent rapidement et facilement modifier les règles en fonction des besoins. Pour savoir pourquoi, réfléchissez à ce qui est nécessaire pour modifier une règle métier implémentée dans une orchestration. Un développeur doit d’abord ouvrir l’orchestration dans Visual Studio, modifier les formes appropriées (et peut-être les objets .NET ou COM qu’ils appellent), puis générer et déployer l’assembly modifié. Cela nécessite également l’arrêt et le redémarrage de l’application BizTalk qui inclut cette orchestration. Si, au lieu de cela, cette règle métier est implémentée à l’aide du bre, elle peut être modifiée sans recompiler ou redémarrer quoi que ce soit. Tout ce qui est nécessaire consiste à utiliser le compositeur de règles métiers pour modifier la règle souhaitée, puis redéployer le nouvel ensemble de règles. La modification prend effet immédiatement. Et bien que les orchestrations soient généralement créées et gérées par les développeurs, les règles d’entreprise sont suffisamment lisibles que, dans certains cas, elles peuvent être modifiées par les analystes d’entreprise sans avoir à impliquer plus de personnes techniques.
Le créateur d’un ensemble de règles métier commence généralement par utiliser le compositeur de règles d’entreprise pour définir un vocabulaire à utiliser pour spécifier ces règles. Chaque terme du vocabulaire fournit un nom convivial pour certaines informations. Par exemple, un vocabulaire peut définir des termes tels que Nombre expédié ou Quantité maximale d’éléments ou limite d’approbation. Chacun de ces termes peut être défini sur une constante ou être mappé à un élément ou un attribut particulier dans un schéma XML (et ainsi dans un message entrant) ou au résultat d’une requête SQL sur une base de données ou même à une valeur dans un objet .NET.
Une fois qu’un vocabulaire a été défini, le compositeur de règles d’entreprise peut être utilisé pour créer des stratégies métier qui utilisent ce vocabulaire. Chaque stratégie peut contenir une ou plusieurs règles d’entreprise. Une règle utilise les termes définis dans un vocabulaire avec des opérateurs logiques tels que Supérieur à, Inférieur à, Est Égal à, et d’autres pour définir le fonctionnement d’un processus métier. Une règle métier peut définir la façon dont les valeurs contenues dans un document XML reçu doivent affecter les valeurs créées dans un document XML envoyé, ou comment ces valeurs reçues doivent affecter la valeur écrite dans une base de données ou d’autres éléments.
Pour exécuter une stratégie métier, une orchestration utilise une forme CallRules. Cette forme crée une instance du bre, spécifie la stratégie à exécuter, puis transmet les informations dont cette stratégie a besoin, comme un document XML reçu. Le BRE peut également être appelé de manière programmatique à l’aide d’un modèle objet basé sur .NET, ce qui permet de l’appeler à partir d’applications qui n’utilisent pas BizTalk Server. Cela signifie que les applications Windows Forms, les logiciels exposant des services Web et tout autre élément basé sur le .NET Framework peuvent potentiellement utiliser le bre chaque fois qu’il permet de résoudre le problème.
Les vocabulaires et les règles métier peuvent être beaucoup plus compliqués, et beaucoup plus puissants, que les exemples simples décrits ici. Mais l’idée fondamentale de définir un vocabulaire, puis de définir des ensembles de règles qui utilisent ce vocabulaire est le cœur du moteur de règles métier.