X

Vielen Dank, dass Sie sich für unsere Dienstleistungen interessieren. Leider sind Sie auf einer veralteten Seite gelandet. Das sollte nicht vorkommen.

Besuchen Sie gerne unsere aktualisierte Webseite.

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.

C:\Users\peter.eismann\AppData\Local\Microsoft\Windows\INetCache\Content.Word\Solution.png

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.
    C:\Users\peter.eismann\AppData\Local\Microsoft\Windows\INetCache\Content.Word\PropertyBase.png

  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".

ACK:

(BTS.AckType exists Message_Copy && Message_Copy(BTS.AckType) == "ACK") ||

(BTS.AckType exists Message_ACK && Message_ACK(BTS.AckType) == "ACK")


NACK:

(BTS.AckType exists Message_Copy && Message_Copy(BTS.AckType) == "NACK") ||

(BTS.AckType exists Message_ACK && Message_ACK(BTS.AckType) == "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.


ACHTUNG!!!!

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 ...

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 
Go to Top