Komponenten der dienstorientierten Lösung
In diesem Abschnitt werden die Hauptkomponenten der dienstorientierten Lösung von BizTalk Server beschrieben. Die folgende Abbildung zeigt die Hauptkomponenten der Lösung:
Die dienstorientierte Lösung verfügt über drei Versionen der Orchestrierungen:
Eine Version, in der alle drei Back-End-Anwendungen in einen Stub ausgelagert sind.
Eine Version, in der alle drei Back-End-Anwendungen inline aufgerufen werden.
Eine Version, die Adapter zum Herstellen einer Verbindung mit den Anwendungen verwendet werden.
Alle Versionen der Orchestrierungen sind im Verzeichnis SDK\Scenarios\SO\BTSSoln\Orchestrations enthalten.
Die Inlineversion der Orchestrierungen stellt die geringste Wartezeit in der Lösung zwischen Anforderungen und Antworten zur Verfügung.
Informationen zu den Quelldateien finden Sie unter Dateiinventur für die dienstorientierte Projektmappe.
Orchestrierungen in der dienstorientierten Lösung
Die drei Orchestrierungen CustomerServiceReceiveSend, CustomerServiceNativeRequestResponse und CustomerService bilden den Großteil der Lösung. Die Orchestrierungen CustomerServiceReceiveSend und CustomerServiceNativeRequestResponse fungieren als Front-Ends, die die CustomerService-Orchestrierung aufrufen. Die CustomerService-Orchestrierung übernimmt den größten Teil der Arbeit: Senden von Anforderungen an die Back-End-Anwendungen, Sammeln der Antworten, Kombinieren der Antworten zu einer einzelnen Nachricht und Senden der Nachricht an die entsprechende Front-End-Orchestrierung. Da die Front-End-Orchestrierungen die CustomerService-Orchestrierung aufrufen, warten die Front-End-Orchestrierungen, bis die CustomerService-Orchestrierung abgeschlossen ist.
Die Lösung macht die CustomerServiceNativeRequestResponse-Orchestrierung als Webdienst verfügbar. Die CustomerServiceReceiveSend-Orchestrierung akzeptiert Nachrichten aus einer MQSeries-Warteschlange.
Back-End-Anwendungen
Die dienstorientierte Lösung kommuniziert mit drei Back-End-Anwendungen
Die PaymentTracker-Anwendung gibt eine simulierte Liste der letzten Zahlungen zurück. PaymentTracker liest die Anforderung aus einer MQSeries-Warteschlange und sendet die Antwort an eine andere MQSeries-Warteschlange.
Die Anwendung PendingTransaction meldet die Summe der ausstehenden Transaktionen für das Kundenkonto. Die Anwendung ist ein Webdienst, der seinerseits HIS (Microsoft Host Integration Server) für die Kommunikation mit einem CICS/COBOL-Programm auf einem Mainframecomputer verwendet.
Die SAP-Anwendung stellt Informationen zum Gesamtkreditrahmen des Kunden zur Verfügung. Die Lösung stellt die Verbindung mit der SAP-Anwendung als Webdienst her. Die Anwendung verwendet den SAP-Adapter im BizTalk-Adapterpaket für die Kommunikation mit einem SAP-System.
Pipelines
Die dienstorientierte Lösung verwendet Standardpipelines, außer an zwei Stellen: der Empfangspipeline für die CustomerServiceReceiveSend-Orchestrierung und der Sendepipeline der CustomerService-Orchestrierung an paymentTracker. Beide Pipelines verwenden benutzerdefinierte Komponenten.
Die Empfangspipeline für CustomerServiceReceiveSend enthält eine benutzerdefinierte Parteiauflösungskomponente, SSO Ticket Issuer Pipeline Component. Die Nachrichten, die die CustomerServiceReceiveSend-Orchestrierung empfängt , verfügen nicht über Anmeldeinformationen. Auf diese Weise wird der Eingang von Nachrichten von einem System für interaktive Sprachantworten (Interactive Voice Response, IVR) simuliert. Die benutzerdefinierte Pipelinekomponente fügt Anmeldeinformationen mithilfe des Dienstkontos des BizTalk-Empfangshosts hinzu.
Im Gegensatz dazu verfügen die Nachrichten, die die CustomerSericeNativeRequestResponse-Orchestrierung empfängt, bereits über Anmeldeinformationen. Da der virtuelle Ordner für den Webdienst für integrierte Sicherheit und der SOAP-Empfangsspeicherort für die Integration von Einmaligem Anmelden für Unternehmen (SSO) konfiguriert ist, generiert der SOAP-Adapter ein Ticket für die Nachricht.
Die andere benutzerdefinierte Pipeline wird in der CustomerService-Sendepipeline an die PaymentTracker-Anwendung angezeigt. Die Komponente (Pipelinekomponente zum Festlegen von MQSeries-Headern) legt Werte für zwei MQSeries-Nachrichtenheadereigenschaften fest. Die Komponente legt zuerst das Nachrichtendatenformat (MQMD_Format) fest, um anzugeben, dass die Nachricht in Form einer MQCIH-Struktur vorliegt, einer Struktur, die häufig für die Kommunikation mit CICS-Programmen verwendet wird. Die zweite, das Format der Daten selbst innerhalb der MQCIH-Struktur (MQCIH_Format), wird so festgelegt, dass die Nachricht eine Zeichenfolge ist.
Mit dem MQCIH-Format können Sie die Benutzer-ID und das Kennwort in der MQCIH-Struktur übergeben. SSO-Partneranwendungen ordnen die Windows-Benutzer-ID der BizTalk-Anwendung den Benutzer-IDs des Zahlungsnachverfolgungssystems zu, die in der MQCIH-Struktur übergeben werden.
Hinweis
Die Inlineversion der Lösung verwendet die gleichen Pipelines durch Aufruf aus der Orchestrierung. Auf diese Weise wird die Wiederverwendung des Pipelinecodes ermöglicht.
Clientanwendung
Die Lösung enthält eine Clientanwendung, die in C# programmiert wurde. Sie können die Anwendung zum Senden von Anforderungen als SOAP- oder MQSeries-Nachrichten verwenden und die Ergebnisse untersuchen.
Zusätzliche Assemblys
Die Anwendung enthält mehrere Hilfsassemblys, die in der Zusammenfassungsabbildung oben nicht enthalten sind. Das Hilfsprogramm "Hilfsprogramme " funktioniert für die Projektmappe.
Die ErrorHelper-Assembly enthält Klassen zum Übersetzen von Fehlercodes in Meldungen und zum Konvertieren von Fehlermeldungen in Fehlercodes.
Die ServiceLevelTracking-Assembly enthält Hilfsmethoden, die die BAM-API (Business Activity Monitoring) verwenden, um Vereinbarungsdaten auf Dienstebene nachzuverfolgen.
Die ConfigHelper-Assembly enthält Hilfsmethoden zum Abrufen von Konfigurationswerten für die Lösung aus der SSOConfigStore-Anwendung .
Weitere Informationen
Entwickeln einer dienstorientierten Lösung
Dateibestand für die dienstorientierte Lösung