Traduction des modèles de la solution orientée service
Cette section décrit les modalités de conversion du diagramme modèle en artefacts BizTalk Server par la solution.
Connexions et conditions d'exhaustivité
Nous pouvons démarrer de n'importe où la conversion des modèles en composants BizTalk Server. Cependant, les connexions entre les composants sont, en effet, l'infrastructure des composants. Il s'agit donc d'un bon endroit pour commencer. En outre, dans le cas du modèle d'agrégation, nous devons penser à ce qui va indiquer l'exhaustivité des informations nécessaires. Cela affecte ses connexions aux autres composants ainsi que sa conception.
La solution doit fournir une méthode d'utilisation pratique et cohérente. L'interface de service spécifie comment d'autres applications peuvent l'utiliser. Comme la solution doit communiquer avec une application héritée à l'aide d'IBM WebSphere MQ, IBM WebSphere MQ doit faire partie de l'interface de service. Toutefois, pour les applications plus récentes, une interface de service Web semble être un choix évident. Une interface de service Web offre une souplesse maximale pour les autres applications utilisant le service. Ici, nous pouvons bénéficier de la souplesse de BizTalk Server pour avoir une interface de service double. Pour plus d’informations sur l’exposition d’orchestrations en tant que services web, consultez Comment mapper des orchestrations aux services web.
Les autres connexions sont celles entre l'interface de service et la liste de destinataires, entre la liste de destinataires et les applications principales, ainsi qu'entre les applications principales, l'agrégation et l'interface de service.
Si la connexion à la liste de destinataires est synchrone, la solution ne doit pas utiliser de corrélations pour veiller à ce que tous les messages adressés à la liste de destinataires soient envoyés et reçus. Les connexions entre les applications principales et l'agrégation peuvent être synchrones pour les mêmes raisons. L'agrégation a besoin des réponses des trois applications principales pour préparer la réponse à la demande. Les temps de réponse doivent être courts afin que les connexions synchrones soient appropriées et simplifient la solution.
Dans le modèle d'agrégation, il existe généralement une condition d'exhaustivité. Dans les cas où il existe plusieurs serveurs principaux et de longs temps de réponse, la condition d'exhaustivité peut être, par exemple, la réception d'au moins une réponse dans une période donnée. Cette solution orientée services nécessite les trois réponses afin de construire le message final. Par conséquent, ici, la condition d'exhaustivité est la réception des trois réponses.
Notes
Lors de la réception de requêtes via IBM WebSphere MQ, la solution ajoute un identificateur de corrélation en copiant la valeur MQMD_MsgId dans le MQMD_CorrelId du message de réponse. Cela fait partie de la méthode d'utilisation standard de l'adaptateur MQSeries dans les scénarios de requête-réponse afin d'éviter une possible condition d'engorgement. Pour plus d’informations, consultez Corrélation des messages à l’aide de Request-Reply.
Identification des limites de l'orchestration
La solution doit être compatible avec les demandes d'une file d'attente IBM WebSphere MQ et via l'interface de service Web. Placer l'interface de service dans une orchestration, l'entrée IBM WebSphere MQ dans une autre et la majeure partie du traitement dans une troisième permet de garder la communication externe séparée du traitement.
Conversion des composants en formes d'orchestration
Les modèles à convertir en formes sont, dans la solution finale, dans une seule orchestration. Il existe de nombreux moyens de créer un routeur basé sur le contenu dans BizTalk Server, y compris la création d'abonnements MessageBox. Dans la solution, le routage utilise des abonnements MessageBox. Une forme Expression évalue si le message inclut ou non des valeurs pour les champs requis. Une forme Décision évalue la variable définie dans la forme Expression et sélectionne le chemin via l'orchestration.
L’orchestration CustomerService utilise la forme parallèle pour envoyer des messages aux applications back-end et recevoir des réponses simultanément. Elle ne doit pas attendre la fin d'une application avant de procéder à la demande suivante. Si le nombre d'applications devait changer régulièrement ou si les connexions aux applications n'étaient pas fiables, alors l'orchestration devrait convertir le modèle différemment.
Dans la solution, l'agrégation doit combiner des éléments de trois messages de réponse. L'utilisation de la forme parallèle permet de s'assurer que la communication avec les systèmes principaux est parallèle. Comme la forme ne s'arrête pas avant la réception de toutes les réponses ou un délai d'attente, l'agrégation sait toujours quand elle peut procéder. L'orchestration utilise une forme Transformer qui mappe des éléments des trois messages de réponse principaux et le message de demande d'origine aux éléments du message de réponse.
Notes
Les communications avec les systèmes principaux peuvent également expirer. Vous pouvez définir la période de délai d’expiration en englobant la forme De réception dans une forme Étendue et en définissant la propriété Timeout de l’étendue.
Pour obtenir la liste complète des formes d’orchestration, consultez Formes d’orchestration.
Voir aussi
Modèles dans la solution orientée services
Composants de la solution orientée services