Composants de la solution orientée services
Cette section décrit les principaux composants BizTalk Server de la solution orientée services. Le diagramme suivant montre les principaux composants de la solution :
La solution orientée services possède trois versions des orchestrations :
Une version dans laquelle les trois applications principales sont toutes en version stub
Une version dans laquelle les trois applications principales sont toutes appelées inline
Une version qui utilise des adaptateurs pour se connecter aux applications
Toutes les versions des orchestrations apparaissent dans le répertoire SDK\Scenarios\SO\BTSSoln\Orchestrations.
La version Inline des orchestrations offre le temps de latence le plus faible dans la solution entre les demandes et les réponses.
Pour plus d’informations sur les fichiers sources, consultez Inventaire de fichiers pour la solution orientée service.
Orchestrations dans la solution orientée services
Trois orchestrations, CustomerServiceReceiveSend, CustomerServiceNativeRequestResponse et CustomerService composent l’essentiel de la solution. Les orchestrations CustomerServiceReceiveSend et CustomerServiceNativeRequestResponse agissent comme des serveurs frontaux qui appellent l’orchestration CustomerService . L’orchestration CustomerService effectue la majeure partie du travail : envoi de requêtes aux applications principales, collecte des réponses, combinaison des réponses en un seul message et envoi du message à l’orchestration front-end appropriée. Étant donné que les orchestrations frontales appellent l’orchestration CustomerService , les orchestrations frontales attendent la fin de l’orchestration CustomerService .
La solution expose l’orchestration CustomerServiceNativeRequestResponse en tant que service web. L’orchestration CustomerServiceReceiveSend accepte les messages d’une file d’attente MQSeries.
Applications principales
La solution orientée services communique avec trois applications principales :
L’application PaymentTracker retourne une liste simulée des paiements récents. PaymentTracker lit la demande à partir d’une file d’attente MQSeries et envoie la réponse à une autre file d’attente MQSeries.
L’application PendingTransaction signale la somme des transactions en attente sur le compte client. L'application est un service Web qui, à son tour, utilise Microsoft Host Integration Server (HIS) pour communiquer avec un programme CICS/COBOL sur un macroordinateur.
L'application SAP fournit des informations sur la limite de crédit générale du client. La solution se connecte à l'application SAP comme un service Web. L’application utilise l’adaptateur SAP dans BizTalk Adapter Pack pour communiquer avec un système SAP.
Pipelines
La solution orientée service utilise des pipelines par défaut, sauf à deux emplacements : le pipeline de réception pour l’orchestration CustomerServiceReceiveSend et le pipeline d’envoi de l’orchestration CustomerService vers PaymentTracker. Les deux pipelines utilisent des composants personnalisés.
Le pipeline de réception pour CustomerServiceReceiveSend comprend un composant de résolution de partie personnalisée, le composant pipeline d’émetteur de ticket d’authentification unique. Les messages que l’orchestration CustomerServiceReceiveSend reçoit n’ont pas d’informations d’identification. Cela simule ce qui se passerait si les messages provenaient d'un système de réponse vocal interactif. Le composant de pipeline personnalisé ajoute des informations d'identification à l'aide du compte de service de l'hôte de réception BizTalk.
En revanche, les messages que l’orchestration CustomerSericeNativeRequestResponse reçoit ont déjà des informations d’identification. Comme le répertoire virtuel pour le service Web est configuré pour la sécurité intégrée et que l'emplacement de réception SOAP est configuré pour intégrer l'authentification unique de l'entreprise, l'adaptateur SOAP génère un ticket pour le message.
L’autre pipeline personnalisé apparaît dans le pipeline d’envoi CustomerService à l’application PaymentTracker . Le composant, Composant de pipeline qui définit l'en-tête MQSeries, définit des valeurs pour les deux propriétés d'en-tête de message MQSeries. Le composant définit le premier, le format de données de message (MQMD_Format), pour indiquer que le message se présente sous la forme d’une structure MQCIH , structure couramment utilisée pour communiquer avec les programmes CICS. Le deuxième, le format des données proprement dites dans la structure MQCIH (MQCIH_Format), est défini pour montrer que le message est une chaîne.
L’utilisation du format MQCIH vous permet de transmettre l’ID utilisateur et le mot de passe dans la structure MQCIH . Les applications associées à l’authentification unique mappent l’ID utilisateur Windows de l’application BizTalk aux ID utilisateur du système de suivi des paiements transmis dans la structure MQCIH .
Notes
La version Inline de la solution utilise les mêmes pipelines en les appelant à partir de l'orchestration. Cela permet de réutiliser le code de pipeline.
Application cliente
La solution comprend une application cliente écrite en C#. Vous pouvez utiliser l'application pour envoyer des demandes en tant que messages SOAP ou MQSeries et examiner les résultats.
Autres assemblys
L'application inclut plusieurs assemblys auxiliaires qui ne figurent pas dans le diagramme récapitulatif ci-avant. L’utilitaire d’assembly Utilities fonctionne pour la solution.
L’assembly ErrorHelper contient des classes pour traduire les codes d’erreur en messages et pour convertir les messages d’erreur en codes d’erreur.
L’assembly ServiceLevelTracking inclut des méthodes d’assistance utilisant l’API Bam (Business Activity Monitoring) pour suivre les données de contrat de niveau de service.
L’assembly ConfigHelper contient des méthodes d’assistance pour récupérer les valeurs de configuration de la solution à partir de l’application SSOConfigStore.
Voir aussi
Développement d’une solution orientée service
Inventaire des fichiers de la solution orientée services