Principes de conception de la solution de gestion des processus d'entreprise
Cette rubrique commence par des recommandations d'ordre général sur la manière de diviser les processus d'entreprise en étapes. Ensuite, elle prend en considération la structure de quelques orchestrations, assemblys et applications de la solution, en relation avec ces recommandations et les impératifs de l'entreprise. Pour plus d’informations sur les exigences métier, consultez « Exigences métier » dans Présentation de la solution de gestion des processus métier.
Division des processus d'entreprise
Souvent, le premier réflexe est de considérer un processus d'entreprise comme un processus unique et monolithique. Ce n'est pas toujours la meilleure conception. Pour Southridge Video, une commande est un processus d'entreprise à long terme, dont la réalisation peut prendre jusqu'à un an. Entre-temps, le processus d'entreprise lui-même peut changer. Pour permettre les mises à jour du processus d'entreprise sans interrompre les commandes en cours de traitement, le traitement de commande Southridge Video est divisé en étapes.
L'endroit où vous divisez le processus est important pour les parties du processus dont vous pouvez contrôler les versions et pour les types d'interruptions que vous autorisez pour les commandes en attente. La solution Southridge Video utilise quatre critères généraux pour déterminer les étapes :
Le regroupement logique des étapes dans le processus d'entreprise.
L'étendue des opérations au sein d'une orchestration.
Les éléments du processus dont il serait utile de contrôler les versions, étant donné le processus d'entreprise.
Une orchestration doit s'arrêter une fois une opération à long terme terminée.
Parmi ces quatre critères, le premier et le troisième sont les plus importants car, généralement, il y a plus d'étendues d'opérations que de regroupements logiques ou de versions d'éléments évidents à contrôler. Notez, cependant, que vous ne voulez pas terminer une orchestration au milieu d'une étendue.
Si vous examinez l’orchestration de la première étape, CableOrder1.odx, vous verrez qu’elle se termine efficacement par la séquence demande-réponse au système d’installations. Il s'agit d'un bon endroit pour une fin d'étape car cette partie du processus implique le travail physique réel pour terminer la commande. Avoir de longues étapes de traitement près de la fin de l'orchestration garantit qu'une fois réalimentée, l'orchestration se terminera rapidement. Cela accélère le mouvement de la solution dans son ensemble vers des versions plus récentes des orchestrations.
Notes
Bien que la solution fractionne le processus en étapes discontinues, la surveillance de la solution vous permet d'avoir une vue continue, grâce à l'utilisation de BAM.
Orchestrations d'action sur la commande, du courtier de commandes et du gestionnaire de commandes
Outre le fractionnement du traitement de commande en étapes, vous remarquez également que chaque action sur la commande, telle que son analyse, sa validation, son annulation, se trouve dans une orchestration distincte. Mettre chaque action dans une orchestration séparée dissocie les actions de la structure des étapes. Cela permet une plus grande souplesse dans la conception et le contrôle des versions des étapes de traitement de commande.
Le courtier de commandes et le gestionnaire de commandes se trouvent dans des orchestrations distinctes pour des raisons similaires. La conception de la solution permet l'utilisation de plusieurs gestionnaires de commandes pour gérer d'autres types de commandes. La dissociation du courtier et du gestionnaire leur permet également d'être dans des emplacements différents. Pour plus d’informations sur la conception du répartiteur de commandes, consultez « Pourquoi et Répartiteur de commandes ? » dans Traitement dans l’orchestration OrderBroker. Pour plus d’informations sur le gestionnaire de commandes, consultez Logique du gestionnaire de processus.
Assemblys
Les assemblys dans la solution sont organisés pour prendre en charge le contrôle des versions des composants et leur déplacement vers d'autres serveurs. Par exemple, les schémas sont dans des assemblys séparés. En particulier, les schémas du répartiteur de commandes se trouvent dans leur propre assembly. Cela permet un contrôle des versions sans modifier d'autres éléments de la solution. Cela simplifie le déplacement du courtier de commandes vers un groupe ou un serveur distinct. Pour plus d’informations sur le contrôle de version des assemblys d’application et de schéma, consultez Gestion des versions de la solution de gestion des processus métier.
Applications
Dans la console Administration de BizTalk, vous pouvez voir que la solution créée comprend trois applications distinctes :
BTSScn.BPM.OrderBrokerApp, l’application contenant le répartiteur de commandes
BTSScn.BPM.CableOrderApp, l’application contenant les composants de traitement des commandes
BTSScn.BPM.MessagingApp, une application qui collecte des artefacts partagés par les deux autres applications
La structure tripartite de la solution est possible du fait de la capacité des applications BizTalk à utiliser des artefacts dans d'autres applications du même groupe BizTalk. Pour utiliser les artefacts d'autres applications, vous ajoutez une référence à l'autre application à partir de l'application de référence. Pour plus d’informations sur le référencement d’autres applications, consultez Comment ajouter une référence à une autre application.
Mettre les artefacts communs dans une application distincte peut vous permettre de mettre à jour des composants dans un seul et unique endroit. Les composants partagés peuvent être de toute nature, y compris des ports. Par exemple, les orchestrations dans la solution envoient des erreurs à un port de création de rapports d'erreurs. Ce port est dans l'application de messagerie, BTSScn.BPM.MessagingApp, où l'ensemble de la solution peut l'utiliser.
Structurer la solution en trois applications facilite également le déplacement de parties de la solution sur d'autres serveurs. Vous pouvez convertir chaque application et ses applications référencées en un fichier MSI. Vous pouvez ensuite installer ce fichier MSI sur un autre ordinateur. Pour plus d’informations sur la conversion d’applications en fichiers MSI, consultez Guide pratique pour exporter une application BizTalk.
Solution test
Vous allez également tester trois applications dans la console d’administration BizTalk : BTSScn.BPM.OrderBrokerApp.Test, BTSScn.BPM.CableOrderApp.Test et BTSScn.BPM.MessagingApp.Test. Ces trois applications contiennent uniquement les ports pour l'application test et sont référencées par les applications principales. Cette structure permet aux ports test d'être utilisés par les applications principales pour créer une solution test tout en dissociant les ports test de la solution.
Voir aussi
Caractéristiques de l’implémentation de la solution de gestion des processus d’entreprise
Modèles dans la solution de gestion des processus d’entreprise