Szenario 1: Orchestration bedient bekannte Anzahl an Subscriber
Wir haben eine BizTalk Orchestration, die über ein direct Binding eine Nachricht mit einer promoteten Property an die Message Box legt. Der zugehörige (One-way) File-Sendport holt sich die Nachricht ab und versendet sie. Bei dieser Implementierung darf nur ein Nachrichten-Subscriber vorhanden sein! Bei einer höheren Anzahl an bekannten Subscribern müsste diese Funktionalität in einer Loop aufgerufen werden.
Ziel ist es nun, eine Rückmeldung zu bekommen, um verifizieren zu können, dass die Nachricht erfolgreich im Zielpfad abgelegt wurde.
Um dies zu erreichen, müssen folgende Properties zusätzlich beim Versenden aus der Orchestration über Correlation-Sets initialisiert werden:
Wir erstellen nun also folgende Correlation-Types:
- CT_AckRequired
- Beinhaltet die BTS.AckRequired Property
- CT_CorrelationToken
- Beinhaltet die BTS.CorrelationToken Property
- CT_SPName
- Beinhaltet die BTS.SPName Property
Basierend auf diesen Correlation Types erstellen wir nun drei Correlation-Sets:
- CS_AckRequired
- Basierend auf CT_AckRequired
- CS_CorrelationToken
- Basierend auf CT_CorrelationToken
- CS_SPName
- Basierend auf CT_SPName
Anschließend initialisieren wir die Properties im Message Assignment Shape:
Und initialisieren diese beim Versenden:
Nun sind wir an dem Punkt, an dem die Nachricht aus der Orchestration versendet wird. Um jetzt das Ack auf die Nachricht nachvollziehen zu können, benötigen wir ein Receive Shape, welches dem Correlation Set (welches das Correlation Token beinhaltet) folgt. Da jedoch die versendete Nachricht selbst ebenfalls das Correlation Token promoted im Kontext beinhaltet, muss dieses in einer parallelen Aktion ausgeführt werden (um 1x die versendete Nachricht und 1x das Acknowledgement empfangen zu können).
Dies sieht so aus:
- Receive Shape 1 folgt CS_CorrelationToken und empfängt Nachricht msgAckCandidate1 ( XmlDokument )
- Receive Shape 2 folgt CS_CorrelationToken und empfängt Nachricht msgAckCandidate2 ( XmlDokument )
In einer der beiden Nachrichten steckt später die versendete Nachricht selbst und in der anderen das Acknowledgement.
Um jetzt herauszufinden, welche der beiden Nachrichten der Ack ist, prüfen wir den Kontext der Nachricht auf die Eigenschaft BTS.AckType in einem Entscheidungsshape:
- Bedingung Zweig Candidate 1
- BTS.AckType exists msgAckCandidate1
- Bedingung Zweig Candidate 2
- BTS.AckType exists msgAckCandidate2
Innerhalb des Zweigs wird ein Message Assignment ausgeführt, bei dem der AckCandidate in die „reale“ Ack Nachricht (ebenfalls XmlDokument) überführt wird (z.B. msgAck = msgAckCandidate1).
Zum Schluss muss noch geprüft werden, ob das Acknowledgement positiv oder negativ war.
- Positiv = „ACK“
- Negativ = „NACK“
Dies wird in einem abschließenden Entscheidungsshape geprüft und dementsprechend reagiert:
- Bedingung Zweig True
- msgAck(BTS.AckType) == "NACK"
- Orchestration terminated with uncosumed messages
Szenario 2: Orchestration bedient unbekannte Anzahl an Subscriber
Dieses Ausgangsszenario würde z.B. wie folgt aussehen:
Wir haben eine BizTalk Orchestration, die über ein direct Binding eine Nachricht mit einer promoteten Property an die Message Box legt. Die zugehörigen (One-way) File-Sendports holen sich die Nachricht ab und versenden sie.
Das würde bedeuten, dass pro Sendport eine Acknowledgement Nachricht zurück an die Messagebox gelegt wird und die Orchestration im oben beschriebenen Aufbau nicht in der Lage ist, all diese Nachrichten zu verarbeiten, da sie lediglich auf 1 Ack/Nack wartet.
Hierfür wäre es empfehlenswert, eine dedizierte Orchestration anzulegen, die nur die Aufgabe hat, die Acknowledgment-Nachrichten zu sammeln und auszuwerten.
Dieser quiTeq-Tipp kommt aus Stuttgart von Nico.
