Traitement dans l’orchestration OrderBroker
Cette section décrit comment l’orchestration OrderBroker prend les commandes et les prépare pour un gestionnaire de processus. La section commence par le fonctionnement général de l'orchestration. Elle décrit ensuite la manière dont l'orchestration traite un message. Enfin, elle met en évidence la manière dont l'orchestration utilise une transaction atomique pour améliorer les performances.
Notes
En raison de la longueur du code OrderBroker , vous pouvez lire cette section avec l’orchestration ouverte dans Microsoft® Visual Studio.
Pourquoi un courtier de commandes ?
L’objectif de l’orchestration OrderBroker est de prétraiter une commande et de l’acheminer vers le gestionnaire de processus approprié. Le prétraitement consiste ici à produire des messages à titre indicatif pour la base de données de l'historique et pour le système de service, et à accuser réception de la commande. OrderBroker crée également un message de commande générique à partir de la demande de service client. Cette normalisation de la commande permet une utilisation générique de la commande par des éléments du processus d'entreprise.
Le message de commande est un message à parties multiples contenant des informations de routage séparées des informations de commande. Les informations de routage sont également génériques et conçues pour être utilisées par n'importe quel gestionnaire de commandes. Elles facilitent, à leur tour, le développement de la solution. Pour plus d’informations sur les messages en plusieurs parties, consultez Utilisation des types de messages en plusieurs parties.
L'isolation de la fonction de courtage vous permet aussi de la déplacer vers un autre groupe BizTalk. Étant donné que OrderBroker publie dans la base de données MessageBox (c’est-à-dire qu’il est lié directement), il est également plus facile de placer le répartiteur dans un autre groupe. Vous pouvez déplacer le répartiteur sans modifier l’orchestration. Pour plus d’informations sur le placement de OrderBroker dans un autre groupe, consultez Communication entre OrderBroker et OrderManager.
Notes
L’orchestration OrderBroker , car elle n’a qu’un seul OrderManager avec lequel communiquer, affecte simplement une chaîne constante au champ OrderMgrType dans le message du gestionnaire de commandes. Généralement, dans une application comptant plusieurs gestionnaires de commandes, l'application utilise le Moteur de règles d'entreprise pour déterminer la valeur appropriée de ce champ et le routage de la commande. Pour plus d’informations sur le moteur de règles d’entreprise, consultez Création et utilisation de règles d’entreprise.
Traitement des commandes
L’orchestration OrderBroker commence par deux formes Receive dans une forme Listen . Une forme Recevoir reçoit des messages du système de support client ; l’autre, les messages du système du fournisseur. Les messages à partir de ces deux sources ont le même schéma.
L’orchestration extrait l’adresse de retour du message et l’utilise pour définir l’adresse du port dynamique , CSRPort. L'orchestration utilise ce port pour envoyer des accusés de réception et des messages d'erreur.
Les étapes suivantes de l’orchestration OrderBroker créent le message d’historique, le message de service, le message de confirmation et le message de commande à envoyer à l’orchestration OrderManager . L’orchestration utilise la fonction utilitaire InsertOrderBody pour ajouter le message de commande au message d’historique.
Notes
Dans certains cas, la solution peut générer des messages qui sont livrés mais pas utilisés. L'orchestration OrderBroker utilise un port d'envoi pour insérer des informations dans la base de données de l'historique. Ce port d'envoi utilise l'accusé de réception. La configuration mappe le port d’envoi à un groupe de ports d’envoi contenant deux ports : un port pour la configuration de test (HistoryInsert-Test-SP), un port pour la configuration normale (HistoryInsert-SP). Si vous laissez les deux ports en cours d'exécution dans le groupe, la solution envoie des messages aux deux ports. Ainsi, elle demande deux accusés de réception mais n'en traite qu'un.
Pour éviter cette situation, désinscrivez le port de test (HistoryInsert-Test-SP) ou arrêtez la version de test de l’application, BTSScn.BPM.OrderBrokerApp.Test. Pour plus d’informations sur les notifications de remise, consultez Utilisation des accusés de réception.
Lors de la construction du message à envoyer à l’orchestration OrderManager , l’orchestration OrderBroker crée un message en plusieurs parties avec deux parties. L'une contient les informations de routage et l'autre, la commande proprement dite. La partie routage du message, OrderMgrMsg.Routing, utilise un schéma défini par une classe C# dans l’assembly SchemaClasses . Le répartiteur traite la partie ordre du message comme un document XML générique ou indépendant du type (System.Xml. XmlDocument) et l’affecte à OrderMgrMsg.Order.
Deux champs dans les informations de routage sont particulièrement importants pour le gestionnaire de commandes : OrderMgrMsg.Routing.OrderMgrType et OrderMgrMsg.Routing.Status. Le répartiteur définit OrderMgrType sur le type du gestionnaire de commandes qui doit gérer la commande. Dans la solution, il n'y a qu'un seul gestionnaire de commandes et le champ est défini sur CABLEORDER. Le répartiteur définit également le champ État sur ACCEPTÉ. Il s'agit de la valeur indiquant au gestionnaire de commandes que le message est une nouvelle commande. Le gestionnaire de commandes de la solution, orchestration OrderManager, utilise une forme Receive qui filtre pour le type de commande égal à CABLEORDER et status égal à ACCEPTED.
Les étapes restantes de l’orchestration OrderBroker envoient les différents messages aux ports appropriés.
Amélioration des performances avec des étendues imbriquées
L’une des choses notables de l’orchestration OrderBroker est son utilisation d’étendues imbriquées. Les étendues imbriquées sont là, notamment, pour améliorer les performances en limitant les points de persistance.
Le moteur d'orchestration enregistre régulièrement l'état de toute l'orchestration aux points d'exécution, nommés points de persistance. Le moteur d’orchestration traite automatiquement plusieurs formes d’orchestration, y compris les formes d’envoi , comme points de persistance. Pour obtenir la liste des points de persistance et plus d’informations sur ceux-ci, consultez Persistance et moteur d’orchestration.
Avec cinq formes d’envoi , l’orchestration OrderBroker doit avoir cinq points de persistance. Toutefois, lorsque vous regroupez envoyer des formes à l’intérieur d’une étendue de transaction atomique, le moteur reconnaît qu’il n’a besoin que d’un seul point de persistance pour l’étendue. Étant donné que quatre formes d’envoi dans l’orchestration OrderBroker ne font pas partie des gestionnaires d’exceptions et que rien n’est nécessaire après l’envoi, elles peuvent aller dans une étendue de transaction atomique. Cela réduit le nombre de points de persistance. Pour plus d’informations sur les transactions atomiques, consultez Transactions atomiques.
Par ailleurs, le moteur d'orchestration utilise un seul point de persistance pour les transactions imbriquées si les transactions finissent toutes au même moment. Ainsi, la façon dont l’orchestration OrderBroker imbrique les transactions réduit davantage les points de persistance : l’orchestration a un point de persistance unique en raison de l’utilisation des formes Étendue .
Conseil
Vous pouvez améliorer les performances en réduisant le nombre de points de persistance dans une orchestration. Vous pouvez regrouper des formes d’envoi dans une transaction atomique pour produire un point de persistance unique pour toutes les formes d’envoi . L'arrêt simultané des étendues de transactions imbriquées produit un seul point de persistance pour les transactions.
Une étendue de transaction atomique ne peut pas avoir de gestionnaire d'exceptions. Par conséquent, l'orchestration imbrique l'étendue atomique à l'intérieur d'une transaction longue. Cette transaction externe peut avoir un gestionnaire d’exceptions et c’est ce gestionnaire qui traite une exception à partir des formes d’envoi .
Conseil
L'imbrication d'une transaction atomique dans une transaction longue est une méthode courante de gestion des exceptions.
Voir aussi
Traitement dans la solution de gestion des processus métier
Logique du gestionnaire de processus
Gestion des interruptions dans la solution de gestion des processus d’entreprise
Orchestration ExceptionHandler