Flux de commandes via le gestionnaire de processus

Cette section décrit comment le gestionnaire de processus de commandes Southridge Video, l’orchestration OrderManager , traite les commandes. Cette section suit une nouvelle commande dans l'orchestration. La section explique également comment l'orchestration gère les mises à jour des commandes.

Notes

La solution de gestionnaire de processus d'entreprise inclut un seul gestionnaire de processus, bien qu'il soit écrit qu'il peut utiliser plusieurs types de gestionnaires.

L’orchestration OrderManager coordonne les orchestrations subordonnées qui implémentent le processus métier pour gérer la commande. OrderManager envoie la commande via deux étapes qui, combinées, valident la commande, envoient les informations au groupe d’installations, envoient la commande au système de commande par le biais des composants de communication à distance et mettent à jour l’historique des commandes. Vous pouvez ajouter, supprimer ou modifier ces phases sans avoir à modifier orderManager.

Notes

En raison de la taille et de l’étendue de l’orchestration OrderManager , vous pouvez lire cette section avec l’orchestration ouverte dans Microsoft Visual Studio.

Structure du gestionnaire de commandes

L’orchestration OrderManager commence par une forme de réception qui active l’orchestration. Le diagramme suivant montre la structure générale de l’orchestration OrderManager .

La première forme Réception donne deux branches principales. Une branche, à droite, traite les nouvelles commandes. La branche de gauche gère les annulations de commande. Étant donné qu’il accepte les entrées utilisateur, il est possible que OrderManager reçoive une annulation de commande une fois qu’une commande est déjà terminée. C'est le cas géré par la branche principale à gauche. La branche gère l'annulation isolée en définissant des indicateurs pour terminer le traitement et en ajoutant un avertissement au journal des événements. L'orchestration gère les annulations de commande qui arrivent tandis qu'une commande est en cours de traitement dans la branche de droite.

La branche de traitement de commande effectue une initialisation, puis entre dans deux boucles imbriquées. La boucle externe s'exécute une seule fois pour chaque étape du traitement de commande. La boucle interne s'exécute lors du traitement de l'étape. Le gestionnaire de commandes recherche également de possibles mises à jour de la commande à l'intérieur de la boucle interne. Une fois que les boucles s'arrêtent, le gestionnaire de commandes envoie un message d'achèvement.

Les étapes de traitement des commandes utilisent des ports dynamiques et auto-corrélats pour communiquer avec l’orchestration OrderManager . Cela simplifie la corrélation de OrderManager avec les instances de phase, car elle élimine la nécessité d’utiliser un jeu de corrélations. Pour plus d’informations sur la corrélation automatique des ports, consultez Liaisons de ports.

Réception de commandes

OrderManager reçoit les messages de commande de l’orchestration OrderBroker via le port FromBrokerPort. Ce port est lié directement à la base de données MessageBox. L’orchestration a deux formes De réception connectées au port : une pour les nouvelles commandes et une pour les commandes mises à jour.

OrderManger détermine les messages à traiter en fonction d’une expression de filtre. L’expression de filtre teste la valeur dans le champ de message status et le champ de type de gestionnaire de commandes OrderMgrType. Si le champ status est égal à ACCEPTED et orderMgrType est CABLEORDER, la commande est nouvelle et destinée à ce gestionnaire de processus.

La nouvelle commande active une nouvelle instance de l'orchestration. OrderManager vérifie ensuite le type de la demande dans une forme Décision. Si le type est Terminer, l'orchestration exécute la branche de gauche et met fin à la commande. Dans le cas contraire, l'orchestration procède au traitement de la commande. Notez que cela inclut la recherche de messages suivants liés à cette commande particulière.

Initialisation de nouvelles commandes

Une fois que l’orchestration OrderManager a reçu un message initial et a commencé la main branche de droite, elle obtient ses informations de configuration à partir de SSOConfigStore. Il effectue cette opération via un objet singleton défini dans l’assembly Utilities . Les valeurs de configuration sont les propriétés de l'objet. L'objet gère un cache local des valeurs de configuration, similaire à la solution d'architecture orientée services. Pour plus d’informations sur l’objet singleton, consultez Utilisation efficace de l’authentification unique dans la solution de gestion des processus métier.

Comme la solution orientée services, la solution de gestion des processus d'entreprise utilise le magasin des secrets car il est présent lorsque BizTalk est installé, SSO met en cache les informations de configuration afin que les valeurs soient immédiatement disponibles et il peut protéger des informations, telles que des chaînes de connexion à la base de données et des mots de passe. Pour toutes ces raisons, le magasin des secrets est un bon endroit pour les informations de configuration, même si les authentifications uniques ne sont pas utilisées pour gérer les connexions aux applications principales.

Notes

L'orchestration extrait les informations de configuration avant de commencer le traitement. Cela garantit que l'orchestration utilise la même configuration si elle est en attente et, ultérieurement, réalimentée. Pour plus d’informations sur la déshydratation, consultez Déshydratation et réhydratation d’orchestration.

Le gestionnaire de commandes utilise une valeur des données de configuration : TotalStages, le nombre total d’étapes dans le processus de gestion des commandes. Le gestionnaire affecte cette valeur à une variable locale, numStages. Il définit également deux autres variables connectées à la boucle externe : l’étape et l’arrêt. La phase indique l’étape actuelle et est le compteur de la boucle externe ; arrêtez la valeur d’arrêt.

Enfin, le gestionnaire définit la variable orderStatus sur STARTED et entre dans la boucle de traitement externe.

Boucles de traitement de nouvelles commandes

La boucle externe s’exécute tant que la valeur de la variable d’étape est inférieure à la valeur de la variable numStages . La boucle externe dirige le traitement pour chaque étape. La boucle interne s'exécute tant qu'une étape est toujours en cours de traitement. Elle recherche également les modifications éventuellement apportées à la commande.

Boucle externe

L’orchestration commence la boucle externe en affectant le message reçu (NewOrderMgrMsg) à une variable, OrderMgrMsg. Elle copie ensuite l'étape et l'état dans la partie de routage du message. L’orchestration définit également l’adresse de retour dans le message sur l’adresse du StageCompletionPort :

OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =   
       StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);  

L’orchestration envoie ensuite la commande à StagePort, un port de sollicitation-réponse. Puis, l'orchestration attend un accusé de réception de l'étape, indiquant que le traitement de commande a démarré. La phase envoie un message OrderAck lorsqu’elle commence à traiter la commande.

Notes

Le message OrderAck est l’un des plusieurs dans la solution définie par les classes .NET plutôt qu’un schéma. Pour plus d’informations sur l’utilisation de classes .NET pour définir des messages, consultez Construction de messages dans le code utilisateur.

Lorsque l’orchestration reçoit l’accusé de réception, elle affecte la phase à la variable currentStage et entre dans la boucle interne.

Boucle interne

La boucle interne s’exécute tant que la variable currentStage est égale à la variable d’étape ; c’est-à-dire tant que l’étape actuelle est en cours de traitement. Le corps de la boucle est une forme Listen avec trois formes Receive . La forme la plus à gauche de l’orchestration, Order Request, fait partie du mécanisme de mise à jour de l’ordre, décrit dans la section suivante.

Lorsqu’une étape de traitement des commandes se termine, elle envoie un message au port StageCompletion de l’orchestration OrderManager . Si l’étape se termine brusquement en raison d’une erreur, elle envoie un TerminatedMessage. Dans ce cas, OrderManager lève une exception. Le gestionnaire d’exceptions le plus externe intercepte l’exception et envoie un message d’erreur à OperatorPort.

Si la phase envoie un OrderMgrMsg, orderManager incrémente la variable d’étape . S’il existe plus d’étapes (phase inférieure ou égale à numStages), les orchestrations définissent l’ordre status dans OrderMgrMsg sur STAGE_n_COMPLETED où n est le nombre de l’étape actuelle. S'il n'y a pas d'étape supplémentaire, elle définit l'état de la commande sur COMPLETED et quitte les boucles.

Mises à jour des commandes

L’orchestration OrderManager écoute les mises à jour de commande à l’intérieur de la boucle de traitement interne. Notez que la forme Receive qu’il utilise pour cela, OrderRequest, utilise également FromBrokerPort. L'utilisation d'une seconde forme Réception sur le même port dans une boucle, combinée à des ensembles de corrélations, crée un modèle BizTalk Server courant, le modèle de convoi. Vous utilisez le modèle de convoi pour garantir que la même instance d'une orchestration traite le premier message et les messages suivants connectés à une opération particulière.

Lorsque le gestionnaire de commandes reçoit le premier message connecté à une commande, il initialise deux ensembles de corrélations. La première, OrderCorrelation, utilise l’ID client (CustID) et l’ID de commande (OrderID). Le gestionnaire de commandes partage cette corrélation avec les étapes de traitement de la commande. La deuxième corrélation est la corrélation de convoi, OrderConvoyCorrelation, qui utilise le status de commande (État) en plus de l’ID client et de la commande. La forme OrderRequestReceive utilise OrderConvoyCorrelation comme jeu de corrélations suivant. Cette définition de la configuration de la corrélation garantit que l'instance du gestionnaire de commandes travaillant sur une commande particulière reçoit les modifications éventuelles.

Notes

Rappelez-vous qu'un ensemble de corrélations est un regroupement de propriétés de message utilisées pour déterminer si un message appartient ou non à une instance donnée d'une orchestration. Pour plus d’informations, consultez Utilisation de corrélations dans les orchestrations.

Lorsque OrderManager reçoit un message suivant pour une commande, il teste d’abord le type de requête. Si le type de demande est TERMINATE, la forme Décision exécute la branche Terminer. Dans le cas contraire, l'orchestration teste le nouveau message pour voir s'il s'agit d'une mise à jour. Un message de mise à jour a un numéro de séquence (SeqNum) plus élevé que la requête d’origine. Si le numéro de séquence du nouveau message est supérieur, l'orchestration commence le traitement de la commande par ce nouveau message. Si le message d'origine et de mise à jour ont le même numéro de séquence ou un numéro inférieur, il s'agit d'une erreur de séquence. Si les numéros de séquence sont égaux, la commande est en double et indiquée comme une erreur de doublon.

Pour plus d’informations sur SeqNum, consultez Messages et champs clés.

Dernières étapes

Après avoir quitté les boucles, le gestionnaire de commandes affecte l’adresse de réponse au port dynamique CSRCompletionPort. Le gestionnaire crée alors le message d'état d'achèvement, l'envoie et teste pour détecter une erreur. Si une erreur s'est produite, l'orchestration exécute une forme Terminer, sinon elle prend simplement fin.

Coordination avec les étapes

L’orchestration OrderBroker et l’orchestration de la deuxième phase de traitement (CableOrder2) créent des entrées dans la base de données d’historique. L’orchestration CableOrder2 met à jour les informations d’historique entrées par l’orchestration OrderBroker . Pour s’assurer qu’il existe une entrée dans la base de données à mettre à jour, OrderBroker utilise la notification de remise sur le port qu’il utilise pour la base de données.

La configuration mappe le port d’envoi OrderBroker pour la base de données d’historique à un groupe de ports d’envoi contenant deux ports : un port pour la configuration de test (HistoryInsert-Test-SP), un port pour la configuration standard (HistoryInsert-SP). Si vous laissez les deux ports actifs 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, annulez la liste du port de test (HistoryInsert-Test-SP) ou arrêtez la version de test de l’application. Pour plus d’informations sur la notification de remise, consultez Utilisation des accusés de réception.

Erreurs et routage de messages réparés : choix de conception

L’orchestration et les orchestrations du gestionnaire d’exceptions utilisées par les étapes de traitement des commandes utilisent une orchestration de gestion des erreurs (ErrorHandlerOrch) pour acheminer les commandes incorrectes en vue d’une réparation. La conception suppose qu'il existe un service ou un groupe qui répare la commande dans la forme souhaitée. L’ordre réparé n’est pas soumis de nouveau via l’orchestration du répartiteur de commandes (OrderBroker). Au lieu de cela, la commande normalisée est réparée dans sa forme normalisée. Dans la conception actuelle de la solution, l'orchestration du gestionnaire route le message d'erreur vers la source de la commande d'origine. Les commandes réparées, cependant, doivent être routées vers un port MSMQ sur l'orchestration du gestionnaire des erreurs. (La version de test de la solution utilise un dossier de fichier.) Le gestionnaire d’erreurs retourne ensuite le message réparé à l’orchestration appelante.

Cette solution utilise cette conception car le courtier de commandes effectue une validation et une normalisation importantes du message de commande. À son tour, le message de commande nécessitant une réparation est également dans la forme normalisée. La maintenance de la forme normalisée du message évite de devoir contourner la différence entre les formes envoyée et normalisée des messages.

Voir aussi

Logique du gestionnaire de processus
Messages et champs clés