Umgang mit Adapterfehlern

Im Allgemeinen werden Nachrichten, die nicht verarbeitet werden können, von Adaptern angehalten. So hält beispielsweise ein Empfangsadapter bei einem Sendefehler die Nachrichten in der Regel an. Diese Entscheidung ist jedoch vom Zweck des Adapters abhängig. Im Zusammenhang mit der Fehlerbehandlung sind auch Sicherheitsüberlegungen zu beachten. Wenn ein Adapter zum Beispiel automatisch alle Nachrichten, bei denen ein Fehler aufgetreten ist, anhält, könnte er sich damit dem Risiko eines Denial-of-Service-Angriffs aussetzen. Ein solcher Angriff führt dazu, dass die BizTalk-Warteschlange "Angehalten" aufgefüllt wird. Manche Adapter (z. B. HTTP-Adapter) können einen Fehlercode an den Client zurückgeben, der angibt, dass die Anforderung zurückgewiesen wurde. Bei diesen Adaptertypen ist es häufig sinnvoller, einen Fehlercode zurückzugeben, als die Nachricht anzuhalten. Sendeadapter halten Nachrichten normalerweise erst dann an, wenn alle Wiederholungen für den primären und sekundären Transport ausgeschöpft wurden.

Verbinden Sie die Fehlerverarbeitung mit einem einzelnen Vorgang und nicht mit dem Batch, der den Vorgang enthält

Die Batchverarbeitung von Nachrichten in einem Adapter sollte für den Benutzer des Adapters nicht sichtbar sein. Dies bedeutet, dass durch Fehler bei einem Vorgang in einem Batch andere Vorgänge in keinster Weise beeinträchtigt werden sollten. Batches sind jedoch atomarisch, daher führt ein Fehler bei einer Nachricht zu einem Fehler für den gesamten Batch, sodass keine Vorgänge verarbeitet werden.

Sie schreiben den Code, der für die Fehlerbehandlung, die erneute Übermittlung der erfolgreichen Nachrichten und das Anhalten der nicht erfolgreichen Nachrichten verantwortlich ist. BizTalk Server bietet glücklicherweise eine detaillierte Fehlerstruktur, mit deren Hilfe der Adapter gezielt den Vorgang ermitteln kann, bei dem ein Fehler aufgetreten ist. Dies ermöglicht die Konstruktion weiterer Batches, in denen die erfolgreichen Vorgänge erneut übermittelt und die nicht erfolgreichen angehalten werden.

Der Abschlussstatus des Vorgangs sollte von der Batchverarbeitung im Adapter nicht beeinflusst werden.

Verwenden von 'SetErrorInfo' zum Melden des Fehlers an BizTalk Server

Wenn Sie eine Nachricht anhalten, müssen Sie BizTalk Server Fehlerinformationen aus dem vorhergehenden Nachrichtenkontext bereitstellen. BizTalk Server bietet Funktionen zur Fehlerberichterstattung mithilfe der SetErrorInfo-Methode sowohl für die IBaseMessage- als auch für die ITransportProxy-Schnittstelle. Sie können Fehler auf folgende Weise melden:

• Wenn beim Verarbeiten einer Nachricht ein Fehler auftritt, legen Sie die Ausnahme mithilfe von SetErrorInfo(Exception e) für die Nachricht (IBaseMessage) fest, die angehalten werden soll. So kann die Engine den Fehler mit der Nachricht für die spätere Diagnose beibehalten, und der Fehler wird im Ereignisprotokoll festgehalten, durch das der Administrator benachrichtigt wird.

• Wenn während der Initialisierung oder der internen Buchhaltung (nicht während der Nachrichtenverarbeitung) ein Fehler auftritt, sollten Sie SetErrorInfo(Exception e) für den ITransportProxy-Zeiger aufrufen, der während der Initialisierung an Sie übergeben wurde. Wenn Ihr Adapter auf der BaseAdapter-Implementierung basiert, sollten Sie stets Zugriff auf diesen Zeiger haben. Andernfalls müssen Sie ihn zwischenspeichern.

  Wenn Sie einen Fehler mit einer dieser Methoden melden, wird die Fehlermeldung in das Ereignisprotokoll geschrieben. Sie sollten den Fehler unbedingt der entsprechenden Nachricht zuordnen, wenn dies möglich ist.

Umgang mit einer Datenbank im Offlinestatus

Wechselt eine der BizTalk Server-Datenbanken vom Online- in den Offlinestatus, wird der BizTalk-Dienst wieder verwendet. Die Messaging-Engine unternimmt den Versuch, alle Empfangsspeicherorte vor der Wiederverwendung des Diensts herunterzufahren. Dauert dieser Vorgang länger als 60 Sekunden, wird der Dienst beendet. Aufgrund der transaktiven Natur der Engine führt dies nicht zu Datenverlusten.

Dieser Timeoutwert kann in der Registrierung mit folgendem Schlüssel optimiert werden:

DWORD   
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host Guid}\MessagingDBFailoverShutdownTimeLimit  

Da BizTalk Server nicht Besitzer des Prozesses ist, sind bei isolierten Adaptern die Empfangsspeicherorte deaktiviert, wenn eine der BizTalk Server-Datenbanken in den Offlinestatus wechselt. Wenn die Datenbank wieder online ist, werden diese Empfangsspeicherorte erneut aktiviert.

Schreiben in das Ereignisprotokoll

Der Adapter kann Ereignisprotokolleinträge schreiben, indem er die IBTTransportProxy-Schnittstelle verwendet, die eine Ausnahme übergibt. Adapter, die im nativen Code entwickelt wurden, müssen in einer IErrorInfo-Schnittstelle , IBTTransportProxy.SetErrorInfo( Exceptione) übergeben werden.

Die Messaging-Engine schreibt für den Adapter in das Ereignisprotokoll. Dies geschieht z. B. dann, wenn ein Adapter nach einem Übertragungsfehler versucht, die Nachricht wiederholt zu senden, eine Nachricht in den sekundären Transport verschiebt oder eine Nachricht anhält. Bei Vorgängen dieser Art muss der Adapter lediglich die Ausnahme für die Nachricht festlegen, bevor er die API aufruft. Der folgende Codeausschnitt stellt dies dar:

IBaseMessage msg;  
...  
// Set exception on msg to indicate why transmission failed...  
msg.SetErrorInfo(  
 new ApplicationException(  
 "The TCP connection was closed by the destination"));  

Umgang mit empfangsspezifischen Batchfehlern

Umgang mit Empfangsfehlern

Wenn bei der Übermittlung eines Vorgang (oder eines Batches von Vorgängen) durch einen Adapter an BizTalk Server Fehler auftreten, können dafür verschiedene Gründe vorliegen. Die beiden wichtigsten Gründe sind folgende:

• Die Empfangspipeline ist ausgefallen.

• Während der Veröffentlichung einer Nachricht ist ein Routingfehler aufgetreten.

  Die Messaging-Engine versucht automatisch, die Nachricht anzuhalten, wenn es einen Empfangspipelinefehler erhält. Dieser Versuch kann jedoch fehlschlagen. Wenn die Messaging-Engine beispielsweise während der Veröffentlichung einer Nachricht auf einen Routingfehler stößt, versucht sie gar nicht erst, die Nachricht anzuhalten.

  Die Möglichkeit, dass bei einer Nachricht Fehler auftreten, besteht immer. In einer solchen Situation sollte der Adapter explizit die MoveToSuspendQ-API aufrufen und versuchen, die Nachricht anzusetzen. Wenn ein Adapter versucht, eine Nachricht anzuhalten, sollte einer der folgenden Punkte zutreffen:

• Das Nachrichtenobjekt, das der Adapter übermittelt hat (empfohlen), sollte angehalten werden.

• Wenn der Adapter eine neue Nachricht erstellen muss, sollte er den Nachrichtenkontext der neuen Nachricht mit dem Zeiger auf den Nachrichtenkontext der Nachricht festlegen, die ursprünglich übermittelt wurde. Dies empfiehlt sich deshalb, weil der Nachrichtenkontext der Nachricht zahlreiche wertvolle Informationen zur Nachricht und zum Fehler enthält. Diese Informationen sind für das Debuggen der fehlerhaften Nachricht erforderlich.

Hinweis

Wenn der Adapter ein neues Nachrichtenobjekt erstellt und anhält, sollte er die Fehlerinformationen aus dem alten Nachrichtenobjekt in das neue Nachrichtenobjekt kopieren.

Bei manchen Adaptern (z. B. der HTTP-Adapter in BizTalk Server) muss die Nachricht nicht angehalten werden. Diese Adapter können einen Fehler an ihren Client zurückgeben.

Ursachen für Fehler

Einfache Fehlerursachen sind Fehler, die auftreten können, wenn der Batch erstellt wird oder wenn IBTTransportBatch::D one aufgerufen wird.

• Fehler bei der Sendeübergabe. Der Submit-Aufruf kann aus einer begrenzten Anzahl von Gründen fehlschlagen, und alle sind fatal. Zu den Gründen gehören die folgenden:

• Im Speicherplatz des BizTalk Server-Prozesses treten Fehler aufgrund von unzureichendem Arbeitsspeicher auf.

• Die Schemaassembly wurde aus der Bereitstellung gelöscht. In diesem Fall schlägt die Übermittlung mit einem kryptischen Fehler fehl. Im MQSeries-Adapter wird der generische Ausnahmefehler in BizTalk Server erfasst, und in das Systemereignisprotokoll wird eine erweiterte Fehlermeldung geschrieben. Laut dieser Meldung besteht eine der möglichen Fehlerursachen darin, dass die Schemaassembly aus irgendeinem Grund aus der Bereitstellung gelöscht wurde.

  Im Allgemeinen sollten Sie bei einem Submit-Fehler versuchen, die Nachricht mit derselben Transaktion anzusetzen.

• IBTTransportBatch::Done failure. Der IBTTransportBatch::D einer Aufruf kann aus mehreren Gründen fehlschlagen. Im Allgemeinen gilt, dass Sie immer einen Versuch zum Anhalten unternehmen und die Transaktion nur dann beenden sollten, wenn dieser Versuch fehlschlägt. Einer der Fehlercodes, die Sie möglicherweise vom Fehler von IBTTransportBatch::D one erhalten, ist, dass BizTalk Server versucht, herunterzufahren. In diesem Fall sollten Sie die Transaktion einfach beenden und belassen, da der Terminaufruf wahrscheinlich gleichzeitig erfolgt. Andere Szenarien treten auf, wenn Sie den Batch erfolgreich erstellt und IBTTransportBatch::D one erfolgreich ausgeführt haben. In diesen Fällen werden die Fehler in BatchComplete zurückgegeben, und der Adapter muss bestimmen, was damit zu tun ist. Der übrige Teil des Abschnitts ist diesem Fall gewidmet.

Verarbeiten von BatchComplete-Fehlern

BatchComplete ist ein vom Adapter bereitgestellter Rückruf, der von BizTalk Server aufgerufen wird, um die Vervollständigung status eines Batchvorgangs anzugeben.

Der wichtigste Parameter, der an BatchComplete übergeben wird, ist der Batch status hResult. Er zeigt Erfolg oder Fehler für den Batch an. Bei einem Batchfehler wird keiner der Vorgänge im Batch erfolgreich ausgeführt. Der Adapter durchläuft die Batch-status-Struktur und bestimmt, welche Nachrichten fehlgeschlagen sind (dies wird als Filtern des Batches bezeichnet).

Nicht transaktionale BatchComplete-Fehler

Für nicht transaktionale Adapter müssen Sie Ihre Antwort auswählen, wenn ein Fehler für einen SubmitMessage/SubmitRequestMessage - oder SubmitResponseMessage-Vorgang auftritt. In der Regel wird die Nachricht von Adaptern durch Aufrufen von MoveToSuspendQ angehalten.

Es wird immer erwartet, dass die folgenden Vorgänge ausgeführt werden: DeleteMessage, MoveToSuspendQ, ResubmitMessage. Treten bei diesen Vorgängen Fehler auf, deutet dies in aller Regel auf einen Fehler im Adapter hin. Es ist nicht erforderlich, Code zu schreiben, um einen Fehler in diesen Fällen zu verarbeiten. Wenn der Batchfehler jedoch von einem Fehler bei einem anderen Vorgang verursacht wurde, müssen diese Vorgänge in einem neuen Batch erneut ausgeführt werden.

Wenn der Adapter MovetoBackupTransport aufruft und dies fehlschlägt (weil kein Sicherungstransport vorhanden war), sollte der Adapter MoveToSuspendQ aufrufen, um die Nachricht anzusetzen.

Transaktionale BatchComplete-Fehler

Wenn Sie Batches mithilfe einer vom Adapter erstellten Transaktion an BizTalk Server senden, sollten Sie einem dieser beiden Szenarien folgen:

• Verwenden Sie Batches mit Einzelnachrichten. Senden Sie einen Batch mit einer Einzelnachricht an BizTalk Server. Tritt bei dieser Einzelnachricht ein Fehler auf, haben Sie die Möglichkeit, im Rahmen derselben Transaktion einen zweiten Batch an BizTalk Server zu senden. Die den Fehler verursachende Nachricht müssen Sie jedoch in die Warteschlange "Angehalten" verschieben, anstatt sie erneut zu senden. Nach dem Entfernen der fehlerhaften Nachricht sollte die Übermittlung des zweiten Batches erfolgreich sein. Anschließend können Sie ein Commit der Transaktion ausführen, wenn BizTalk Server bestätigt, dass der zweite Batch erfolgreich übermittelt wurde. Wenn ein Batchfehler beim zweiten Batch auftritt, muss der Adapter die Transaktion abbrechen oder einen anderen Ablageort für diese Nachricht finden. In diesem Szenario kommt es sofort zu spürbaren Leistungseinbußen, die durch die Verarbeitung des Rollbacks der Transaktion verursacht werden.

  Es gibt verschiedene Techniken zur Verbesserung der Adapterleistung. Der MQSeries-Adapter passt sich z. B. dynamisch zur Laufzeit an. Er wird mit Batches zu je 100 Nachrichten ausgeführt. Wenn er auf einen Fehler stößt, muss er den Batch beenden, wechselt jedoch kurzzeitig zu Batches mit Einzelnachrichten, um an der fehlerhaften Nachricht vorbeizukommen. Dann erfolgt ein erneuter Wechsel zu Batches mit 100 Nachrichten. Stößt er wieder auf den Fehler, wird das Tempo erneut gesenkt.

• Halten Sie Nachrichten präemptiv an. Erstellen Sie einen Batch mit vielen Nachrichten, in dem fehlerbehaftete Nachrichten von vornherein angehalten werden. Der Batch enthält eine Mischung aus Submit - und MoveToSuspendQ-Vorgängen und ist der erste und einzige Batch unter der Transaktion. Er sollte erfolgreich übermittelt werden können, da die fehlerhaften Daten präemptiv angehalten wurden, und nun ein Commit der Transaktion ausgeführt werden kann (nach dem Warten auf die Bestätigung von BizTalk Server).

  Scheinbar ist es dafür erforderlich, in die Zukunft sehen zu können, diese Technik wurde jedoch im MSMQ-Adapter angewendet. Eine Voraussetzung dafür ist das Vorhandensein zuverlässig eindeutiger Nachrichten-IDs. Dieser Adapter konstruiert einen Batch von Nachrichten. Tritt ein Fehler auf, wird ein Rollback der Transaktion (und daher des Batches) ausgeführt; der Adapter "erinnert" sich jedoch an die Nachrichten-ID in einer temporären Datenstruktur. (Damit diese Struktur nicht unbegrenzt wachsen kann, werden nach einer festgelegten Zeitverzögerung Objekte daraus entfernt.) Vor der Übermittlung der einzelnen Batches überprüft der Adapter die Liste der IDs fehlerhafter Nachrichten. Findet der Adapter eine solche ID, „weiß“ er, dass die Nachricht nicht erfolgreich übermittelt werden kann (da es in der Vergangenheit bereits zu Fehlern gekommen ist), und hält die Nachricht präemptiv an, anstatt eine Übermittlung zu versuchen.

  Nicht alle Adapter haben eine zuverlässig eindeutige Nachrichten-ID, und die Wahrscheinlichkeit, eine solche ID zu besitzen, ist für einen Transaktionsspeicher geringer. Daher sind viele transaktionale Adapter auf das Senden von Batches mit Einzelnachrichten beschränkt.

Verarbeiten anderer Fehler

In allen anderen Fällen (z. B. bei Fehlern beim Anhalten von Nachrichten) muss der Adapter die Transaktion beenden. Andernfalls würden Nachrichten entweder dupliziert oder gelöscht werden.

Der Adapter sollte die Transaktion bei einem Batchfehler nach Möglichkeit immer abbrechen. Es gibt jedoch auch Szenarien, in denen der Adapter die Transaktion nicht abbrechen kann. In einem solchen Fall sollte er die Nachricht mithilfe derselben Transaktion anhalten.

Verarbeiten von Fehlern beim transaktionalen Empfang

Ein häufiges transaktionales Verarbeitungsmuster besteht darin, eine Transaktion zu beenden, wenn ein Fehler auftritt. In diesem Fall wird der vorherige Status wiederhergestellt, und es gehen keine Daten verloren. Wenn Sie jedoch Daten aus einer transaktionalen Eingabe verwenden (z. B. einzelne Zeilen nacheinander aus einer Stagingtabelle in einer Datenbank oder einzelne Nachrichten nacheinander aus einem Warteschlangenprodukt wie MQSeries oder MSMQ abrufen), ist dies möglicherweise nicht ausreichend. Wenn Sie die Transaktion einfach beenden, zurückgehen, und dieselben Daten erneut abrufen, tritt wahrscheinlich wieder derselbe Fehler auf, und das System bleibt in einer sich wiederholenden Schleife hängen.

Der SQL-Adapter, der zum Funktionsumfang einer früheren Version von BizTalk Server gehörte, unterstützte dieses Verhalten. Kurze Zeit nach der Veröffentlichung wurde das Adapterverhalten jedoch geändert. Der Adapter versuchte nun, eine fehlerhafte Nachricht anzuhalten und ein Commit der Transaktion durchzuführen. Durch Verschieben einer Nachricht in die Warteschlange "Angehalten" im Rahmen derselben Transaktion und anschließendes Commit der Transaktion wird sichergestellt, dass die Daten nicht verloren gehen. Außerdem kann der Adapter so an fehlerhaften Daten vorbeikommen.

Wenn der Empfangsteil eines Adapters als Reaktion auf einen Vorgang zum Senden einer Nachricht eine Fehlermeldung übergeben wird, sollte der Adapter diesen Fehler verarbeiten und die Nachricht in die Angehaltene Warteschlange verschieben.

Im Fall von transaktionalen Batches, bei denen der Adapter das Transaktionsobjekt erstellt hat und die Nachrichten im Rahmen der Transaktion sendet, sollte der Adapter die Nachricht bei Fehlern folgerichtig im Rahmen derselben Transaktion in die Warteschlange "Angehalten" verschieben. Die Transaktion stellt sicher, dass keine Daten verloren gehen und dass selbst Daten, die einen Fehler verursachen, niemals gelöscht werden.

Umgang mit Nachrichten ohne Abonnements

BizTalk Server akzeptiert Nachrichten zur Veröffentlichung in der MessageBox-Datenbank nur dann, wenn entsprechende Abonnements definiert sind. Abonnements werden entweder von Orchestrierungen oder Sendeports registriert. Es ist möglich, mehrere Abonnements zu definieren. In diesem Fall wird die Nachricht an mehrere Ziele gesendet. Existieren keine Abonnements, weist BizTalk Server die Nachricht zurück und unternimmt keinen Versuch, sie anzuhalten. Wenn der Adapter diesen Fehler nicht verarbeitet und die Nachricht explizit anhält, wird die Nachricht gelöscht, und die Daten können verloren gehen. Ein transaktionaler Adapter könnte natürlich die Transaktion beenden und die Nachricht an ihr Ziel zurücksenden.

Unterstützen der Seek-Methode mit dem Empfangsstream

Der empfangsseitige Stream muss die Seek-Methode unterstützen, damit BizTalk Server die Nachricht bei einem Pipelinefehler anhalten kann. Wenn der Nachrichtendatenstrom nicht durchsuchbar ist, generiert BizTalk Server beim Ausführen von Seek einen Fehler.

In vielen Fällen ist die Unterstützung von Seek nicht einfach. Beim Streaming von Daten aus einem Netzwerk kann es beispielsweise schwierig sein, an die Netzwerkressource zurückzugehen und die Daten erneut anzufordern.

Verschiedene Adapter, die im Lieferumfang von BizTalk Server inbegriffen sind, spoolen die Nachrichtendaten zur selben Zeit, da BizTalk Server die Daten liest, in eine Datei auf der Festplatte. Dadurch kann der Adapter Seek für diese Datei verwenden, wenn ein Fehler auftritt (z. B. bei der Pipelineverarbeitung der Nachrichtendaten). Intern verwendet der Adapter die ReadOnlySeekableStream-Klasse , die einen eingehenden, nicht suchbaren Stream umschließt und auf den Datenträger überläuft, wenn ein konfigurierbarer Größenschwellenwert erreicht wird. Für Nachrichten mit einer Größe unterhalb des Schwellenwerts wird die Festplatte nie beansprucht.

Vom Benutzer konfigurierbare Optionen zur Fehlerbehandlung

In manchen Situationen sind mehrere korrekte Reaktionen auf einen Fehler vorstellbar. In diesem Fall sollten Sie eine vom Benutzer konfigurierbare Option in Erwägung ziehen, die Ihnen die Auswahl zwischen Verhaltensoptionen ermöglicht. Hierfür eignet sich der MQSeries-Adapter.

Wenn der Adapter angewiesen wird, Nachrichten anzuhalten, sobald er einen Fehler entdeckt, ergibt sich ein Problem. Dieses Problem besteht darin, dass die Warteschlange "Angehalten" in BizTalk Server so etwas wie ein "schwarzes Loch" ist. Es ist zwar relativ einfach, Nachrichten in die Warteschlange zu verschieben, jedoch wesentlich schwieriger, sie von dort wieder abzurufen.

Es wäre möglich, dass einige Benutzer des Adapters grundsätzlich nicht möchten, dass Nachrichten in der Warteschlange "Angehalten" abgelegt werden. Im Fall des MQSeries-Adapters steht dem Benutzer beispielsweise eine Konfigurationsoption zur Verfügung, mit der er einen der folgenden Schritte ausführen kann:

• Er kann den Adapter so konfigurieren, dass er die aktuelle Transaktion beendet und sich selbst deaktiviert, wenn er auf einen Fehler stößt.

• Er kann die fehlerhafte Nachricht anhalten und ein Commit der Transaktion durchführen. Der Adapter führt diesen Schritt selbst dann aus, wenn BizTalk Server die Nachricht erfolgreich angehalten hat. Diese Aktion erfüllt die Anforderungen des Kunden, auch wenn sie dazu führt, dass das Ereignisprotokoll nicht absolut korrekt ist.

Implementieren der Empfangssortierung durch Verwendung eines einzelnen Threads und Warten auf 'BatchComplete'

Die Schnittstelle mit BizTalk Server wurde mit Blick auf die Leistung und die Fähigkeit zur dezentralen Skalierung durch Unterstützung der Parallelität konstruiert. Wenn Sie jedoch einen streng geordneten Empfang von Nachrichten wünschen (wie manchmal beim Empfangen von Nachrichten aus einem Warteschlangenprodukt wie MQSeries oder MSMQ erforderlich), müssen Sie im Adapter einige zusätzliche Arbeitsschritte ausführen, um diese Parallelität in einem gewissen Umfang zu deaktivieren. Um dies zu erreichen, müssen Sie zwei Schritte ausführen:

1. Sie müssen für die gesamte Datenverarbeitung im Adapter einen einzelnen Thread verwenden.

2. Sie müssen warten, bis BizTalk Server jeden Batch vollständig verarbeitet hat. Diesen wichtigen Schritt können Sie ausführen, indem Sie .NET-Threadsynchronisierungsprimitive verwenden. Wenn Sie beispielsweise ein AutoResetEvent verwenden, würden Sie:

   • Deklarieren Sie das Ereignisobjekt, auf das sowohl der Standard-Workerthread als auch das BatchComplete-Rückrufobjekt zugreifen können.

   • Übermitteln Sie im Standard Workerthreads die Nachrichten wie üblich an den Batch, rufen Sie dann autoResetEvent.Reset für das Ereignisobjekt kurz vor dem Aufruf des Batches IBTTransportBatch::D one auf.

   • Rufen Sie AutoResetEvent.WaitOne für das Ereignisobjekt aus diesem Thread auf. Dadurch wird der Hauptarbeitsthread blockiert. Im BatchComplete-Rückruf von BizTalk Server rufen Sie dann AutoResetEvent.Set für dasselbe Ereignisobjekt auf, um die Blockierung des Workerthreads aufzuheben, damit er bereit ist, eine andere Nachricht zu verarbeiten.

   Es wird dringend empfohlen, die Empfangsreihenfolge wie diese konfigurierbar zu machen, da dies zu erheblichen Leistungseinbußen führt. Für viele (wenn nicht gar die meisten) Benutzerszenarien ist die Sortierung von Nachrichten nicht erforderlich. Durch das Anhalten von Nachrichten kann die Sortierung ebenfalls unterbrochen werden. Was in solchen Fällen zu tun ist, hängt von der jeweiligen Anwendung ab. Daher ist es ideal, wenn Ihr Adapter dem Benutzer einen Konfigurationspunkt bietet.

   In Szenarien mit Sortierung würden einige Kunden es vorziehen, die Verarbeitung zu beenden (d. h., den Adapter zu deaktivieren), anstatt die Sortierung zu unterbrechen. Der MQSeries-Adapter, der den sortierten Empfang unterstützt, gibt dem Benutzer diese Möglichkeit.

Umgang mit sendespezifischen Batchfehlern

Behandlung der Wiederholung und Batchverarbeitung auf der Sendeseite

Es folgt ein typisches Beispiel der Batchverarbeitung auf Sendeseite:

• BizTalk Server übermittelt einen Nachrichtenbatch an den Adapter.

• Wenn der Adapter feststellt, dass die Nachricht korrekt an das Ziel übergeben wurde, führt er einen Löschvorgang in BizTalk Server aus, der anzeigt, dass die Aufgabe abgeschlossen wurde. (Wie üblich können mehrere Löschnachrichten beliebig in einem Batch zusammengefasst werden, um die Leistung zu verbessern.)

  Wenn der Adapter auf der Sendeseite eine Nachricht nicht verarbeiten kann, stehen ihm mehrere Optionen für den Umgang mit dieser Nachricht zur Verfügung:

• Der Adapter sollte BizTalk Server mitteilen, dass die Nachricht wiederholt werden soll, da BizTalk Server die Nachrichtenübermittlung nicht automatisch wiederholt. BizTalk Server hält die Anzahl der Wiederholungen fest; diese Zahl kann dem Nachrichtenkontext entnommen werden.

• Der Adapter kann bestimmen, dass er nicht in der Lage ist, eine Nachricht zu verarbeiten. In diesem Fall ist es möglich, dass er die Nachricht in den nächsten Transport verschiebt. Der Adapter führt dies mit dem MoveToNextTransport-Aufruf für das Batch-Objekt aus.

• Der Adapter verschiebt die Nachricht möglicherweise in die Warteschlange "Angehalten".

  Der Adapter bestimmt, was mit der Nachricht geschieht. Es wird allerdings empfohlen, die Adapter so zu konfigurieren, dass sie sich einheitlich verhalten - dies erleichtert die Unterstützung einer BizTalk Server-Installation.

  Adapter sollten sich unbedingt gemäß den nachstehend beschriebenen Regeln verhalten. Die mit BizTalk Server ausgelieferten Adapter erfüllen diese Anforderung.

Empfohlenes Verhalten für den Umgang mit Sendefehlern in einem Batch

Der Sendeadapter empfängt einige Nachrichten, die er an BizTalk Server übermittelt.

Jedes Mal, wenn eine Nachricht erfolgreich gesendet wurde, sollte der Adapter diese Nachricht in BizTalk Server löschen. Die Kommunikation mit BizTalk Server erfolgt grundsätzlich über Batches, und die gelöschten Nachrichten können im Batch zusammengefasst werden. Dabei muss es sich nicht um denselben Batch handeln, den BizTalk Server im Adapter erstellt hat. Sind Antwortnachrichten vorhanden (wie im SolicitResponse-Szenario), sollten diese zurück an BizTalk Server gesendet werden (mit SubmitResponse), und zwar zusammen mit den dazugehörigen Löschvorgängen.

• Wenn die Nachrichtenverarbeitung im Adapter nicht erfolgreich war, überprüfen Sie die Wiederholungsanzahl.

  • Wurde der Wert für die Wiederholungsanzahl nicht überschritten, senden Sie die Nachricht erneut an BizTalk Server, wobei Sie für die Nachricht die Wiederholungszeit festlegen. Die Wiederholungsanzahl und das Wiederholungsintervall, die bzw. das der Adapter verwenden sollte, können dem Nachrichtenkontext entnommen werden.

  • Wenn die Wiederholungsanzahl überschritten wurde, sollte der Adapter versuchen, die Nachricht mithilfe von MoveToNextTransport zu verschieben. Die Nachrichten "Erneut übermitteln" und "MoveToNextTransport" können mit den Löschvorgängen im selben Batch wieder in BizTalk Server gemischt werden. Dies ist nicht erforderlich, kann jedoch nützlich sein.

• Die erneute Übermittlung und die MoveToNextTransport-Instanz sind Möglichkeiten für den Adapter, Fehler zu beheben. Es ist jedoch möglich, dass bei der Verarbeitung des Fehlers ein Problem auftritt. In diesem Fall muss der Adapter bei der Verarbeitung der Antwort von BizTalk Server (in der BatchComplete-Methode) einen weiteren Batch für BizTalk Server erstellen, um anzugeben, was mit diesem Fehler zu tun ist.

  Führen Sie bei der Verarbeitung eines Fehlers, der bei der Verarbeitung eines anderen Fehlers auftritt, die folgenden Schritte aus:

  • Wenn die erneute Übermittlung fehlschlägt, verwenden Sie MoveToNextTransport.

  • Wenn MoveToNextTransport fehlschlägt, verwenden Sie MoveToSuspendQ.

  Sie müssen mit dem Erstellen von Batches in BizTalk Server so lange fortfahren, bis Sie eine erfolgreiche Aktion in BizTalk Server empfangen.

Serialisierung der Nachrichtenkontexteigenschaft

Alle Objekte, die einer Nachrichtenkontexteigenschaft zugewiesen sind, müssen serialisierbar sein. Andernfalls löst die Messaging-Engine eine Ausnahme vom Typ E_NOINTERFACE aus. Dieser Rückgabewert ist eine mehrdeutige Darstellung eines nicht serialisierbaren Objekts, das versucht, dem Nachrichtenkontext zugewiesen zu werden.