Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Batchverwaltung für Den Adapter senden
Bei Der Verwendung von Transaktionen auf der Sendeseite wird dieselbe Transaktion, die von BizTalk Server erstellt und zum Senden an das Zielsystem verwendet wird, für den entsprechenden Nachrichtenlöschvorgang verwendet, nachdem sie erfolgreich gesendet wurde. Wenn etwas fehlschlägt, kann die Transaktion beendet werden, in diesem Fall wird der Löschvorgang abgebrochen, und die Daten verbleiben in BizTalk Server und nicht im Zielsystem. Dadurch wird die Duplizierung von Nachrichten verhindert. Transaktionen werden nur für asynchrone Sendeadapter unterstützt. Sie sollten keine Transaktionen mit synchronen Sendeadaptern verwenden.
Der Adapter kann die Transaktion jedoch nicht einfach beenden; sie muss auch den Status der nachrichten, die sie erhalten hat, ordnungsgemäß verarbeiten. Insbesondere sollte der Adapter die Methoden "Resubmit", "MoveToNextTransport" und "MoveToSuspendQ " entsprechend der Wiederholungsanzahl aufrufen und ob ein Sicherungstransport verfügbar ist.
Es ist wichtig, die Vorgänge "Löschen" und " SubmitResponse " in einem Batch zusammenzufassen, der dieselbe Transaktion verwendet. Fehler werden behandelt, indem die Transaktion beendet wird (um sicherzustellen, dass Daten nur einmal an ein externes System übermittelt werden). Aber Sie möchten die Nachricht trotzdem erneut auf BizTalk Server übermitteln oder MoveToNextTransport aufrufen. Verwenden Sie dazu einen separaten normalen (nicht transaktionalen) Batch für diese Arten von Vorgängen.
Die folgende Abbildung zeigt die Verwendung separater Batches für Antwortnachrichten.
Sortieren der Send-Side Transaktionsbatches nach Endpunkt
Batches von Nachrichten, die von BizTalk Server an den Adapter gesendet werden, können mehrere Sendeports (oder Endpunkte) umfassen. Da der Adapter in der Regel eine Transaktion zu 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 beispielsweise ein FTP-Sendeadapter einen Batch von Nachrichten von BizTalk Server empfängt, erhält er einen gemischten Nachrichtenbatch für alle derzeit aktiven FTP-Sendeports. Dies geschieht, da die API singletonbasiert ist, d. h., dass nur ein einzelner FTP-Adapter geladen wird, nicht einer pro Sendeport.
Der Adapter muss zuerst den Von BizTalk Server bereitgestellten Batch von Nachrichten in separate Batches sortieren, eines für jeden Endpunkt. Anschließend kann er sich mit jedem Endpunkt befassen und erstellt wahrscheinlich Löschbatches für jeden Endpunkt. Die generischen wiederverwendbaren BaseAdapter-Klassen im SDK-Beispielcode 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 es ausreichende Konfigurationsdetails im Nachrichtenkopf und in der URL selbst bereitstellt. BizTalk Server muss das Protokoll der URL erkennen.
Beim Sortieren von Nachrichten sollten Sie darauf achten, festzulegen, was einen Endpunkt definiert. Dies gilt insbesondere bei einem dynamischen Senden. Wenn nur der URI den Endpunkt definiert, sind die Dinge einfach. In einer FTP-Sitzung können die Anmeldedetails des Benutzernamens jedoch vom FTP-Server verwendet werden, um den tatsächlichen Endpunkt zu definieren. Wenn sich der Adapter in diesem Fall als anderes Konto anmeldet, kann er mit einem anderen Verzeichnis verbunden sein.
In einigen Fällen ist der wahre Endpunkt erst bekannt, wenn Sie den Enterprise Single Sign-On (SSO)-Befehl ValidateAndRedeemTicket ausgeführt haben.
Im Falle von MQSeries ist die Bestimmung, ob Transaktionen verwendet werden sollen, konfigurierbar. Angesichts der Architektur und der Verwendung eines REMOTE-COM+-Objekts empfiehlt es sich, einen Transaktionsendpunkt als von einem nicht transaktionalen Endpunkt zu unterscheiden.
Zusammenfassend ist das Sortieren von Nachrichten in ihre einzelnen Endpunktgruppen manchmal eine nicht triviale Aufgabe und kann solche zusätzlichen Schritte wie das Berücksichtigen von Kontextwerten und sogar das Ergebnis eines SSO-Aufrufs umfassen.
Sortieren für statisches Senden
Wenn der Endpunkt ein statisch konfigurierter Endpunkt ist, gibt es eine eindeutige GUID im Nachrichtenkontext, die als statische Port-ID (SPID) bezeichnet wird. Dieser Wert kann zum Sortieren des Endpunkts verwendet werden. Der folgende Code kann zum Abrufen verwendet werden:
string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");
Dies ist hilfreich, wenn Sie die Probleme berücksichtigen, die durch das auf XSD-basierende XML-Schemakonfigurationsframework eingeführt wurden. Mit diesem Framework verfügen Sie über eine Eigenschaft, die teil des Endpunktschlüssels sein kann, der in XML in einer einzigen Kontexteigenschaft begraben ist. Wenn Sie über einen SPID im Kontext verfügen, können Sie dies als Möglichkeit zum Sortieren des Batches verwenden. Andernfalls führen Sie ein dynamisches Senden durch und müssen einen alternativen Schlüssel erstellen, mit dem der Batch sortiert werden soll.
Die folgende Abbildung zeigt die Nachrichtensortierung nach Endpunkt.
Denken Sie daran, dass die Anzahl der Wiederholungsversuche einer Nachricht nicht über den Erfolg oder das Scheitern eines Batches Bescheid weiß. Auf der Sendeseite kann ein Batch von Nachrichten fehlschlagen, da einige Nachrichten im Batch fehlgeschlagen sind. Der Adapter muss für jede empfangene Nachricht eine Bestimmung treffen. Im Szenario des fehlgeschlagenen Batches können Sie davon ausgehen, dass jede Nachricht erneut übermittelt wird. Wenn jedoch alle Nachrichten in einem fehlerhaften Batch erneut übermittelt werden, wird die Wiederholungsanzahl (die vom BizTalk Server-Modul verwaltet wird) falsch erhöht, auch für die erfolgreichen Nachrichten, da sie sich im selben Batch wie die fehlgeschlagenen Nachrichten befinden. In diesem Fall könnte ein Adapter den ausgehenden Stapel neu formen und die erfolgreichen Nachrichten an das externe System erneut senden.