Batchverarbeitung von Nachrichten für die Sendeverarbeitung
Batchverwaltung für Sendeadapter
Beim Verwenden von Transaktionen auf Absenderseite wird zum Löschen einer erfolgreich gesendeten Nachricht dieselbe Transaktion verwendet, die von BizTalk Server erstellt und für das Senden an das Zielsystem genutzt wurde. Tritt dabei ein Fehler auf, kann die Transaktion beendet werden. In diesem Fall wird der Löschvorgang abgebrochen. Die Daten verbleiben in BizTalk Server und werden dem Zielsystem nicht hinzugefügt. Dies verhindert die Duplizierung von Nachrichten. Transaktionen werden nur für asynchrone Sendeadapter unterstützt. Transaktionen sollten nicht mit synchronen Sendeadaptern verwendet werden.
Der Adapter kann die Transaktion jedoch nicht beenden, ohne den Status der ihm übermittelten Nachrichten zu verarbeiten. Insbesondere sollte der Adapter die Methoden Resubmit, MoveToNextTransport und MoveToSuspendQ entsprechend der Wiederholungsanzahl und davon aufrufen, ob ein Sicherungstransport verfügbar ist.
Es ist wichtig, die Delete - und SubmitResponse-Vorgänge zusammen in einem Batch zu platzieren, der dieselbe Transaktion verwendet. Ein Fehler wird durch Beenden der Transaktion verarbeitet (um sicherzustellen, dass Daten nur einmal an ein externes System übermittelt werden). Sie möchten jedoch weiterhin MoveToNextTransport erneut übermitteln oder aufrufen, um die Nachricht wieder auf BizTalk Server. Verwenden Sie dazu für diese Vorgangstypen einen separaten normalen (nicht transaktionalen) Batch.
In der folgenden Abbildung wird die Verwendung separater Batches für Antwortnachrichten dargestellt.
Sortieren der transaktionalen Batches auf Sendeseite nach Endpunkt
Von BizTalk Server an den Adapter gesendete Nachrichtenbatches können mehrere Sendeports (oder Endpunkte) umfassen. Da der Adapter in der Regel eine Transaktion mit einem einzelnen Endpunkt haben möchte, muss der Adapter die Nachrichten basierend auf dem Sendeport (SPName oder OutboundTransportLocation) sortieren. Dadurch kann der Adapter eine Transaktion erstellen, die nur einen bestimmten Sendeport umfasst.
Wenn ein FTP-Sendeadapter beispielsweise einen Nachrichtenbatch von BizTalk Server empfängt, erhält er einen gemischten Nachrichtenbatch für alle aktuell aktiven FTP-Sendeports. Das liegt daran, dass die API Singleton-basiert ist, d. h. es wird nur ein einzelner FTP-Adapter geladen, nicht ein Adapter pro Sendeport.
Der Adapter muss zuerst den von BizTalk Server übermittelten Nachrichtenbatch in separate Batches, einen für jeden Endpunkt, sortieren. Dann kann er wiederum die Bearbeitung für jeden Endpunkt vornehmen und wird wahrscheinlich Löschbatches für jeden Endpunkt erstellen. Die generischen, wiederverwendbaren BaseAdapter-Klassen im SDK-Codebeispiel funktionieren auf die gleiche Weise.
Sortieren für dynamisches Senden
Eine BizTalk Server-Orchestrierung kann eine Nachricht an einen Port senden, der nicht konfiguriert wurde, solange sie ausreichende Konfigurationsdetails im Nachrichtenheader und in der URL selbst zur Verfügung stellt. BizTalk Server muss das Protokoll der URL erkennen.
Beim Sortieren von Nachrichten muss darauf geachtet werden, dass die Definition eines Endpunkts festgelegt wurde. Dies gilt speziell für dynamisches Senden. Wenn der Endpunkt nur durch die URI definiert wird, ist die Handhabung einfach. Während einer FTP-Sitzung muss der FTP-Server jedoch möglicherweise die Anmeldedetails des Benutzernamens verwenden, um den wahren Endpunkt zu definieren. Wenn der Adapter sich in diesem Fall unter einem anderen Konto anmeldet, wird er möglicherweise mit einem anderen Verzeichnis verbunden.
In einigen Fällen ist der wahre Endpunkt erst bekannt, wenn Sie den Befehl ValidateAndRedeemTicket (Enterprise Single Sign-On, SSO) ausgeführt haben.
Im Fall von MQSeries ist die Festlegung, ob Transaktionen verwendet werden sollen, konfigurierbar. Bei vorgegebener Architektur und Verwendung eines Remote-COM+-Objekts werden transaktionale Endpunkte am besten als verschieden von nicht transaktionalen Endpunkten betrachtet.
Zusammenfassend gilt: das Sortieren von Nachrichten in ihre einzelnen Endpunktbatches ist in manchen Fällen eine komplexe Aufgabe und kann zusätzliche Schritte beinhalten, wie z. B. die Berücksichtigung der Kontextwerte oder auch der Ergebnisse eines SSO-Aufrufs.
Sortieren für statisches Senden
Wenn der Endpunkt statisch konfiguriert wurde, ist für den Nachrichtenkontext eine eindeutige GUID vorhanden. Diese wird als ID des statischen Ports (SPID) bezeichnet. Dieser Wert kann zum Sortieren des Endpunkts verwendet werden. Mit folgendem Code kann die SPID abgerufen werden:
string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");
Dies ist hilfreich hinsichtlich der Probleme, die durch das XSD-basierte Konfigurationsframework auftreten. Mit diesem Framework verfügen Sie über eine Eigenschaft, die Teil des Endpunktschlüssels sein kann und sich in einer einzelnen Kontexteigenschaft in Form von XML-Code befinden kann. Wenn eine SPID für den Kontext vorhanden ist, kann diese zum Sortieren des Batches verwendet werden. Andernfalls verwenden Sie dynamisches Senden. Dabei muss der Batch mit einem zu erstellenden alternativen Schlüssel sortiert werden.
In der folgenden Abbildung ist das Sortieren von Nachrichten nach ihrem Endpunkt dargestellt.
Beachten Sie, dass bei der Wiederholungsanzahl einer Nachricht nicht berücksichtigt wird, ob ein Batch erfolgreich oder fehlerhaft verarbeitet wird. Auf der Sendeseite kann die Verarbeitung eines Nachrichtenbatches dann fehlschlagen, wenn ein Batchfehler bei einigen Nachrichten im Batch auftritt. Der Adapter muss für jede Nachricht, die er empfängt, eine Festlegung treffen. In dem Szenario mit Batchfehler können Sie davon ausgehen, dass jede Nachricht erneut gesendet wird. Wenn jedoch alle Nachrichten eines fehlerhaft verarbeiteten Batches erneut gesendet werden, wird die Wiederholungsanzahl (die von der BizTalk Server-Engine verwaltet wird) nicht ordnungsgemäß inkrementiert. Dies gilt auch für die erfolgreich übermittelten Nachrichten, da sie sich in demselben Batch befinden, in dem auch die fehlerhaft übertragenen Nachrichten enthalten sind. In diesem Fall kann ein Adapter den ausgehenden Batch neu zusammenstellen und die erfolgreichen Nachrichten erneut an das externe System senden.