Microsoft BizTalk, Azure BizTalk Services Blog

Um Nachrichten im BizTalk zu versenden gibt es verschiedene Methoden. Wenn inhaltlich gleiche Nachrichten basierend auf Parametern an verschiedene Ziele gesendet werden müssen, stehen drei Wege zur Auswahl:

1. Direkte Bindung von Orchestrierung an Sende-Port:

Die Sendeports werden direkt mit der Orchstrierung verbunden, es kann nur ein Sendeport pro Sende-Aktion in der Orchstrierung verwendet werden. Dabei ergibt sich das Problem, dass für jedes Ziel, die Sende-Orchestrierung dupliziert werden muss. Dies hat einen gewaltigen Wartungsaufwand zur Folge und ist auch aus Performance-Gründen nicht empfehlenswert.

2. Verwendung von dynamischen Ports

Die Ports werden dynamisch in der Orchstrierung konfiguriert. Es ergibt sich hierbei das Problem, die Ports mit den Zielparametern zu versorgen. Diese müssen entweder hart kodiert werden, oder die Konfigurationslogik muss entwickelt werden. Die Ports können nicht mit der BizTalk Administrationskonsole konfiguriert werden. Daraus erhöht sich nicht nur der Entwicklungsaufwand sondern auch das Risiko von Fehlern sowie der Wartungsaufwand. Auch haben die unterschiedlichen Ports unterschiedliche Konfigurationsparameter, die untereinander inkompatibel sind und somit keine wahre Dynamik gegeben ist.

3. Verwenden von direkter Bindung zur Messagebox sowie Filter bei den Sende-Ports

Bei direkter Bindung der Sende-Orchestrierung zur Messagebox, kann per Subscription-Filter eine unbegrenzte Anzahl an Sende-Ports (auch zur Laufzeit) erstellt werden, wobei jeder Sende-Port nur die für ihn relevanten Nachrichten versendet. Damit ist die Anzahl der Ziele dynamisch und zur Laufzeit ohne Entwicklungsaufwand anpassbar. Einziges Problem hierbei ist, dass bei dieser Variante keine implizite Sendebestätigung an die Orchestrierung zurück gegeben wird. Wie dies dennoch möglich ist, wird im Folgenden beschrieben.

BizTalk Server verwendet zur Steuerung der Nachrichten und zum Ermöglichen des Publish/Subscribe-Prinzips eine Vielzahl an Meta-Parametern. Die Nachrichten werden bildlich gesprochen in einen Umschlag gepackt, der mit diversen Informationen versehen wird, beispielsweise einer Adresse und der Art, wie die Nachricht versendet werden soll. Die verschiedenen Artefakte (Empfangsports, Orchestrierungen, Sende-Ports, ...) werten diese Meta-Informationen aus, verändern sie, löschen sie oder erstellen neue. Auch die direkte Verbindung einer Orchestrierung mit einem Sende-Port läuft über eine Meta-Information. Die Publish / Subscribe Methodik funktioniert in dem Falle über die Sende-Port UID. Der erstellte Sende-Port erhält eine eindeutige ID. Die Orchestation veröffentlicht („publish“) die entsprechenden Nachrichten dann mit dieser ID als Thema („topic“). Der Sende-Port abonniert („subscribe“) standardmäßig dieses Thema. Damit ist die Orchstration „fest“ mit dem Sende-Port verbunden.

Diese Verbindung kann aber auch explizit und über andere Themen stattfinden. Damit entkoppelt man die Orchstrierung von den Sende-Ports und kann diese auch zur Laufzeit austauschen. Um dies zu erreichen, muss in der Orchestrierung eine Korellation erstellt werden. Sie ist notwendig, wenn Informationen als Meta-Information an die Nachricht angehängt werden sollen. Nur dann kann im Sende-Port per Filter darauf zugegriffen werden.

Damit der Sende-Port eine Bestätigung an die Orchestrierung zurückgibt muss diese Korellation zwei Parameter beinhalten. Erstens eine eindeutige ID, um die Bestätigung einer Nachricht zuordnen zu können und zweitens den Parameter „AckRequired“ der den Sende-Port anweist, eine Bestätigung zu erzeugen. Die Orchstrierung beinhaltet dann, neben der Sende-Aktion, zwei Empfangs-Aktionen die direkt auf das Senden folgen. Eine erhält eine Kopie der Nachricht (basierend auf der Subscription, die aus den Korrelationseinstellungen resultiert), die andere erhält die Bestätigung vom Sende Port.

Anschließend kann dann die Bestätiung auf erfolgreiches oder fehlerhaftes Senden geprüft werden und die Bearbeitung, abhängig vom Ergebnis fortgesetzt werden.  

Im nächsten Blogbeitrag wird dieses Prinzip in einem praktischen Beispiel veranschaulicht...

Im zweiten Teil der Blog-Reihe zum Thema Entkoppelung von Sende-Ports von den Orchestrierungen folgt nun eine praktische Anleitung eines solchen Szenarios. Erstellt wurde eine einfache Orchestrierung, die eine beliebige Datei empfängt und weiterleitet.

Um die Entkoppelung mit Sendebestätigung zu erreichen, wird ein Sende-Port in der Orchestrierung erstellt [DirectSendPort], dessen Bindung zur MessageBox konfiguriert wird.

Damit das funktioniert und außerdem verschiedene Ports auf Basis von Parametern benutzt werden können müssen noch folgende Konfigurationen vorgenommen werden.

1. Erstellung von Korrelationstypen: Für die Sendebestätigung werden zwei Typen benötigt. Der erste Typ verwendet den Metaparameter BTS.CorrelationToken, der zweite Typ BTS.AckRequired und der dritte einen eigens erstellten Parameter "Property". Dieser Parameter muss in einem PropertySchema definiert sein und die Eigenschaft "MessageContextPropertyBase" besitzen. Er steuert später über welchen Sende-Port die Nachricht letztendlich gesendet wird.
   

2. Erstellung von Korrelations-Sets: Für jeden Korrelationstyp muss ein Korrelations-Set erstellt werden, damit es für die Zuordnung der Bestätigungen zu den Nachrichten verwendet werden kann.
   

3. Zuordnung der initiierenden Korrelation: In der Sende-Aktion müssen alle Korrelationssets als initiierende Sets konfiguriert werden.
   

4. Zuordnung der Folgekorrelationen: In den beiden Empfangs-Aktionen muss jeweils das Korrelationsset mit "BTS.CorrelationToken" als Folge-Korrelation ausgewählt werden. Es müssen zwei Empfangsaktionen sein, da es immer zwei Nachrichten mit dem Token gibt. Einmal die Original-Nachricht und die Sendebestätigung.
   

Im Anschluss muss noch geprüft werden, welche der beiden empfangenen Nachrichten die Sendebestätigung ist. Hierfür wird das Vorhandensein des Metaparameters "BTS.AckType" geprüft, der vom Sende-Port hinzugefügt wird. Dieser Parameter beinhaltet dann entweder den Wert "ACK", wenn die Datei erfolgreich versendet wurde, ansonsten den Wert "NACK".

Basieren auf dem Ergebnis kann dann eine unterschiedliche Bearbeitung stattfinden. Im Beispiel wird die Sendebestätigung in verschiedene Verzeichnisse abgelegt.

Außerhalb der Orchestrierung müssen dann die Sende-Ports konfiguriert werden. Im Beispiel gibt es einen einfachen Datei-Port, der die Dateien in einem bestimmten Ordner ablegt. Wichtig ist hierbei die Einstellung der Filter. Um die Ports fest mit der Sende-Orchestrierung zu verbinden wird der erste Filter mit der Einstellung "BTS.Operation" mit dem Wert der Sende-Operation aus der Orchestrierung konfiguriert. Der zweite Filter gibt dann einen Wert für die Meta-Information "Property" vor. Damit werden alle Nachrichten aus der Orchestrierung mit diesem Wert von dem Port verschickt. Der Parameter könnte zum Beispiel den Schnittstellennamen oder den Kundennamen beinhalten. Je nach Kunde oder Schnittstelle werden unterschiedliche Sende-Adapter und –Ziele verwendet.

Ein zweiter Port könnte zum Beispiel den Wert auf „SendMail“ filtern und eine Mail mit dem Inhalt der Datei als Anhang verschicken. Die restlichen Ports für die Demo sind einfache Datei Ports. In der Übersicht der Applikationskonfiguration fällt auf, dass die Orchestrierung keinerlei Verbindung zum Sende-Port hat. Dieser ist unabhängig und funktioniert ausschließlich auf Basis des Publish / Subscribe Prinzips.

Bei dieser Konfiguration ist es nicht möglich Kopie-Ports zu erstellen. Kopie-Ports sind Ports mit der gleichen Subscription, das heißt sie haben die gleichen Filter und würde eine Kopie der Nachricht an das konfigurierte Ziel schicken. In diesem Fall würden 3 Nachrichten zurück an die Orchestration geschickt: die Kopie, die ACK/NACK von Port 1 und die ACK/NACK von Port zwei. Da die Orchestration aber nur zwei Nachrichten empfängt und dann die Bearbeitung fortsetzt, wird die letzte Nachricht nicht mehr von der Orchestrierung konsumiert. Die Orchestrierungsinstanz bekommt dann den Status „suspended“ mit dem Fehler: „Instance did not consume all messages“. Sobald die BizTalk Instanz-Dienste durchgestartet werden, werden alle „suspended“ Instanzen neu gestartet und die Nachrichten werden erneut versendet. Das ist für eine Produktionsumgebung fatal und muss unbedingt verhindert werden.

Wie man in diesem Szenario Kopie-Ports ohne diese Probleme erstellen kann, zeigt der 3. Teil dieses Blogs ...