Suche

über alle News und Events

 

Alle News

 

Wir expandieren, bringen Kunden und Talente besser...

Weiterlesen

Um HTML zum PDF zu konvertieren, werden wir...

Weiterlesen

Die Logic Apps-Plattform von Microsoft ermöglicht...

Weiterlesen

Du bist neugierig auf aktuelle KI-Technologien und...

Weiterlesen

Am 27.09. ab 12.30h starten die vierten QUIBIQ...

Weiterlesen

"Das Beste von SAP und Microsoft nutzen": auf dem...

Weiterlesen

Azure Bicep wird verwendet, um Ressourcen in Azure...

Weiterlesen

In einer Welt, die immer digitaler wird, ist es...

Weiterlesen

Dieser Artikel beschreibt wie JSON-Dateien anhand...

Weiterlesen

Vom 5. bis 7. Juni findet in London wieder die...

Weiterlesen

How-to: Retrieve Acknowledgement in BizTalk Orchestration for oneway file Sendport with direct binding (via MessageBox)

In diesem Blogeintrag werden wir kurz erläutern, was notwendig ist, um eine Transport-Bestätigung für eine indirekt (direkt Binding an Message Box) auf eine File Location versendete Nachricht innerhalb der Orchestration zu empfangen und diese auszuwerten.

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.

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz