Verarbeitung großer Nachrichten durch Adapter

Die BizTalk-Messaging-Engine ist in der Lage, sehr große Nachrichten zu verarbeiten. Im Hinblick auf die maximale Größe einer Nachricht werden von der Engine keine Beschränkungen auferlegt. Es empfiehlt sich jedoch, die Nachrichtengröße zu begrenzen, um die Leistung nicht zu beeinträchtigen und eine optimale Ressourcenverwaltung zu gewährleisten. Mit zunehmender Nachrichtengröße nimmt die Anzahl der pro Sekunde verarbeiteten Nachrichten ab. Berücksichtigen Sie die durchschnittliche Nachrichtengröße, den Nachrichtentyp und die Anzahl der nachrichten, die von BizTalk Server verarbeitet werden, wenn Sie Ihr Szenario entwerfen und die Kapazität planen.

Streambasierte Verarbeitung

Bei der Entwicklung von Adaptern ist es wichtig, die Verarbeitung großer Nachrichten zu berücksichtigen. Auf keinen Fall sollte der gesamte Datenstrom unabhängig von seiner Größe in den Arbeitsspeicher geladen werden, da hierdurch der BizTalk Server-Prozess gestoppt werden könnte. Je nach Größe und Anzahl der von der Engine zu einem beliebigen Zeitpunkt verarbeiteten Nachrichten kann der Mangel an virtuellem Arbeitsspeicher zu einem Problem werden. Nachrichten sollten daher nach dem Streamingprinzip verarbeitet werden, wie im Folgenden beschrieben:

• Eingehende Nachrichten. Bei eingehenden Nachrichten wird der Netzwerkstream vom Empfangsadapter an die BizTalk-Nachricht angehängt und das "Pulling", also das Abrufen des Streams, der BizTalk-Messaging-Engine überlassen.

• Ausgehende Nachrichten. Bei ausgehenden Nachrichten ist der Adapter für das Pulling des Streams verantwortlich. Hierbei wird der Stream gewissermaßen aus der MessageBox-Datenbank und durch die Sendepipeline abgerufen. Der Adapter sollte die Daten nach dem Streamingprinzip über die Verbindung senden.

  Die folgende Abbildung zeigt die streambasierte Verarbeitung auf der Empfangsseite der Messaging-Engine.

  

  Wenn ein Adapter eine Nachricht an die Engine sendet, muss er deren Datenstrom an die BizTalk-Nachricht anhängen. Einige Adapter müssen hierzu unter Umständen einen Netzwerkstream implementieren. Wenn die Nachricht gesendet wird, führt die Engine die Empfangspipeline aus. Während der Ausführung der Pipeline klonen die Pipelinekomponenten, die die Daten ändern möchten, die Nachricht, und knüpfen den Stream aus der neuen Nachricht an den Stream der vorherigen Nachricht. Nach Ausführung der Pipeline entnimmt die Engine der Pipeline eine Nachricht und führt eine Schleife aus, mit der der Stream in dieser Nachricht gelesen wird. Durch das Lesen des Streams wird ein Lesezugriff auf den vorhergehenden Stream aufgerufen, der wiederum einen Lesezugriff auf den vorhergehenden Stream aufruft, usw. bis zurück zum Netzwerkstream. Die Engine entleert die Daten in regelmäßigen Abständen in die MessageBox, um ein flaches Speichermodell beizubehalten.

  Tipp zur Problembehandlung: Auf der Sendeseite ist der Adapter für das Lesen des Datenstroms verantwortlich. Wenn der Sendeadapter Nachrichtenkontexteigenschaften lesen möchte, die in der Sendepipeline höher gestuft oder geschrieben werden, dürfen diese Eigenschaften erst dann geschrieben werden, wenn der gesamte Stream gelesen wurde. Erst wenn der Stream vollständig gelesen wurde, kann der Adapter sicher sein, dass die Ausführung sämtlicher Pipelinekomponenten abgeschlossen ist.

Suchen eines bestimmten Byte im Stream

In manchen Szenarien muss ein Adapter den Stream unter Umständen bis an den Anfang zurückverfolgen, um fehlgeschlagene Nachrichten zu verarbeiten, die angehalten werden müssen. Ein Beispiel hierfür ist ein HTTP-Adapter, der Daten mittels aufgeteilter Codierung empfängt, um die Antwortnachricht in einem Paar vom Typ "Antwort anfragen" zu senden.

In vielen Szenarien ist es jedoch vielleicht nicht möglich, den Datenstream zu verfolgen. Nehmen wir beispielsweise einen HTTP-Adapter an, der Daten mittels aufgeteilter Codierung empfängt. Damit der Datenstream so ausgelegt ist, dass Sie die fehlgeschlagenen Nachrichten finden können, müsste der Adapter die Daten beim Lesen zwischenspeichern (entweder im Arbeitsspeicher oder auf der Festplatte). Diese Lösung ist alles andere als optimal und würde zusätzliche Ressourcen erfordern. Dazu kommt, dass viele der im Lieferumfang enthaltenen Pipelinekomponenten nur nach dem Prinzip des Vorwärtsstreaming funktionieren. Für diese Szenarien verwendet der BaseAdapter im SDK eine Hilfsklasse namens VirtualStream. Die Datei, die diese Funktionalität enthält, heißt VirtualStream.cs.

Hinweis

Die Datei VirtualStream.cs befindet sich an zwei verschiedenen Speicherorten im Verzeichnis SDK\Samples\Pipelines\: SDK\Samples\Pipelines\ArbitraryXPathPropertyHandler und SDK\Samples\Pipelines\SchemaResolverComponent\SchemaResolverFlatFileDasm.

Dem virtuellen Stream liegt die Idee zugrunde, dass die Daten im Stream in einem Arbeitsspeicherstream zwischengespeichert werden, bis eine Schwelle erreicht wird, jenseits derer die Daten nach dem Überlaufprinzip an einen sicheren Speicherort auf der Festplatte verschoben werden. Nach Abschluss des Streams wird die Datei auf der Festplatte automatisch gelöscht. Auf diese Weise können Vorwärtsstreams entworfen werden.