Verarbeiten der Nachricht
Alle bisher beschriebenen Komponenten spielen bei der Verarbeitung von Nachrichten auf ihrem Weg durch BizTalk Server eine eigene Rolle. In diesem Abschnitt erhalten Sie eine detaillierte Beschreibung dazu, wie diese Komponenten funktional interagieren, beginnend mit dem Empfang einer Nachricht. Die folgende Abbildung zeigt die Bestandteile eines Empfangsports und den Verlauf einer Nachricht durch den Empfangsprozess.
Ein Empfangsport besteht aus einem oder mehreren Empfangsspeicherorten und 0 (null) oder mehr Zuordnungen. Zuordnungen sind XSLT-Stylesheets (Extensible Stylesheet Language Transformations), die zum Transformieren von XML-Nachrichten von einer Struktur oder einem Format in ein anderes dienen, und die im Empfangsprozess häufig zum Normalisieren von Nachrichten in ein internes Format verwendet werden. Empfangsspeicherorte steuern die Endpunkte, welche die Nachrichten empfangen. Ein Empfangsspeicherort enthält die Konfiguration eines Endpunkts für einen Empfangsadapter und eine Empfangspipeline.
Die Rolle des Adapters
Der Empfangsadapter initiiert den Prozess des Nachrichtenempfangs, indem er einen Datenstrom liest und eine Nachricht erstellt. Der Dateiadapter beispielsweise erkennt, dass an seinem konfigurierten Speicherort eine Datei abgelegt wurde, und liest diese Datei in einem Datenstrom. Der Adapter erstellt eine Nachricht (eine Implementierung der Schnittstelle Microsoft.BizTalk.Message.Interop.IBaseMessage), fügt ihr einen Textteil hinzu (eine Implementierung der Schnittstelle Microsoft.BizTalk.Message.Interop.IBasePart), und stellt den Datenstrom als Inhalt des Textteils zur Verfügung.
Außerdem schreibt der Adapter Eigenschaften in den Nachrichtenkontext, die mit dem Speicherort, Adaptertyp und anderen verbunden sind, oder stuft diese höher. Nachdem die Nachricht und ihr Kontext erstellt wurden, übergibt der Adapter die Nachricht an den Endpunkt-Manager. Die Nachricht wird dann in der Empfangspipeline verarbeitet, die für den Empfangsspeicherort konfiguriert wurde. Nachdem die Nachricht von der Pipeline verarbeitet wurde, kann die Nachricht mithilfe einer Zuordnung in das gewünschte Format transformiert werden, bevor sie vom Endpunkt-Manager mit dem Nachrichtenagenten veröffentlicht wird.
Die Rolle der Pipeline
Während die ursprüngliche Nachricht zwar vom Adapter erstellt wird, findet jedoch das meiste der Verarbeitung der empfangenen Nachricht in der Empfangspipeline statt. Die Pipelineverarbeitung betrifft sowohl den Nachrichteninhalt als auch den Nachrichtenkontext. Der Nachrichteninhalt wird im Allgemeinen beim Decodieren, Disassemblieren und Überprüfen verarbeitet, während der Nachrichtenkontext in jedem Stadium verarbeitet werden kann. Eine Pipeline muss sich jedoch nicht notwendigerweise mit dem Inhalt oder dem Kontext befassen. Die standardmäßige Durchleitungspipeline (Pass-Through-Pipeline) beispielsweise besitzt keine konfigurierten Komponenten und verarbeitet weder Nachrichteninhalt noch -kontext. Der Einfachheit halber konzentriert sich dieses Dokument auf die Disassemblierungskomponenten, da sich diese am stärksten auf das Nachrichtenrouting auswirken.
Die Aufgabe des Disassemblers besteht darin, eine von einem Adapter eingehende Nachricht zu verarbeiten und in viele Nachrichten zu zerlegen und die Nachrichtendaten zu analysieren. Enthält eine eingehende Nachricht viele kleinere Nachrichten, wird dies als Austauschbezeichnet. Sowohl beim Flatfile- als auch beim XML-Disassembler hat ein Entwickler für die Verarbeitung von Austauschvorgängen die Möglichkeit, Informationen zum Wrapping Content“ (d. h. ein Header- und Nachspannschema für den Flatfile-Disassembler und ein Umschlagschema für den XML-Disassembler) sowie zum (sich potentiell wiederholenden) Textteilinhalt zu konfigurieren. Außerdem verarbeiten beide Disassembler die ursprüngliche Nachricht in XML-Inhalt. Ein benutzerdefinierter Disassembler verarbeitet den Inhalt nicht unbedingt in XML, wenn keine weitere XML-Verarbeitung in BizTalk Server erforderlich ist. Ein Beispielszenario hierfür ist eine einfache Routingsituation, in der Nachrichten, die an einem bestimmten Empfangsspeicherort im System eingehen, ohne Zuordnung oder andere XML-Verarbeitung an einen bestimmten Sendeport gesendet werden.
Routing mit dem Nachrichtentyp
Der Nachrichtentyp ist eine der häufigsten Nachrichteneigenschaften, die beim Routing verwendet wird. Wenn ein Entwickler ein Schema erstellt, um die Struktur von Nachrichten zu definieren, definiert dieses Schema den Nachrichtentyp für diese Nachricht. Der Nachrichtentyp wird anhand des Stammknotens und Namespace in der Schemadefinition bestimmt. Ein XML-Dokument, das wie folgt aussieht, weist beispielsweise den Nachrichtentyp von http://tempuri.org/samples/MessageType#Message
<Message xmlns=http://tempuri.org/samples/MessageType>
<SomeOtherElement type="sample"/>
</Message>
Um den Nachrichtentyp beim Routing zu verwenden, muss er in den Kontext höher gestuft werden. Disassembler werden dazu verwendet, diesen Wert sowie die Pipelinekomponenten, die die Nachrichtenstruktur am besten beschreiben können, in den Nachrichtenkontext höher zu stufen. Der XML- und der Flatfile-Disassembler stufen den Nachrichtentyp bei der Nachrichtenverarbeitung höher. Auch jeder benutzerdefinierte Disassembler sollte diese Eigenschaft höher stufen, um ein ordnungsgemäßes Routing zu gewährleisten.
Hierbei ist es wichtig zu wissen, dass eine Nachricht nicht zwingend einen Typ haben muss. Wie schon erwähnt, können die Nachrichtenteile aus beliebigen Binärdaten bestehen und müssen kein Schema besitzen, das ihre Struktur definiert. Dieser Typ von Nachrichtenteil durchläuft BizTalk Server normalerweise ohne großen bzw. gar keinen Verarbeitungsaufwand seitens BizTalk Server. Es ist jedoch möglich, dass benutzerdefinierte Pipelinekomponenten, Adapter oder von Orchestrierungen aufgerufener Code mit diesen Teilen interagieren.
Pipelinekomponenten schreiben Eigenschaften ebenfalls in den Nachrichtenkontext, wie Adapter, und stufen diese höher. Tatsächlich sind Pipelinekomponenten der Mechanismus, den die meisten Entwickler am häufigsten zum Schreiben oder höher Stufen von Eigenschaften in den Nachrichtenkontext verwenden. Entwickler erstellen Schemas und können Eigenschaften im Schema höher stufen. Diese Informationen werden im Schema als Anmerkungen gespeichert, die dann von Pipelinekomponenten verwendet werden können. Alle integrierten Disassembler- und Assemblerkomponenten (FlatFile, XML und BizTalk Framework) verwenden das Dokumentschema zum Abrufen von Informationen über Eigenschaften, die höher gestuft werden sollen. Anhand der XPath-Anweisung (XML Path Language) aus den Anmerkungen kennt der Disassembler die Stelle im Dokument mit den höher zu stufenden Elementen. Während des Streamens durch das Dokument findet der Disassembler jene Elemente, die mit einer der XPath-Anweisungen übereinstimmen, und schreibt oder stuft den Wert in den Kontext höher.
Benutzerdefinierte Pipelinekomponenten können auch dafür geschrieben werden, Eigenschaften für beliebige Daten in einer empfangenen oder gesendeten Nachricht in den Kontext zu schreiben oder heraufzustufen. Um eine Eigenschaft in den Kontext höher zu stufen und beim Routing nutzen zu können (was ja der eigentliche Grund dafür ist, dass ein Wert höher gestuft wird), sollte ein Eigenschaftsschema mit einer Definition für die Eigenschaft erstellt und für BizTalk Server bereitgestellt werden. Bevor Sie ein Eigenschaftsschema erstellen, das von benutzerdefinierten Komponenten verwendet wird, sollten Sie die verschiedenen Typen von höher gestuften Eigenschaften kennen und verstehen. Die in einem Eigenschaftsschema definierten höher gestuften Eigenschaften können einen der beiden Basistypen haben:
Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase
Eine Eigenschaft mit dem Basistyp MessageDataPropertyBase zeigt an, dass der Wert für diese Eigenschaft aus dem Nachrichteninhalt stammt. Dies ist der Standardwert für die in einem Eigenschaftsschema definierten Eigenschaften und wird am häufigsten verwendet. MessageContextPropertyBase gibt eine Eigenschaft an, die Teil des Nachrichtenkontexts sein soll, jedoch nicht notwendigerweise direkt aus den Nachrichtendaten stammt. Eigenschaften mit dem Basistyp MessageContextPropertyBase werden häufig von Adaptern und Disassemblern höher gestuft und enthalten häufig verwendete Eigenschaften wie Nachrichtentyp und Adaptertyp.
Es ist wichtig, die unterschiedlichen Typen zu kennen und zu verstehen, um sie beim Definieren von Eigenschaften richtig einsetzen zu können. Eine der deutlichsten Implikationen tritt ein, wenn in einer Orchestrierung auf Kontexteigenschaften für eine Nachricht zugegriffen wird. Wird eine Eigenschaft als MessageDataPropertyBase identifiziert, überprüft der Orchestrierungs-Designer das Schema der empfangenen Nachricht und stellt sicher, dass es eine übereinstimmende höher gestufte Eigenschaft definiert. Wenn keine Eigenschaft in dem Schema gefunden wird, das an die höher gestufte Eigenschaft gebunden ist, auf die ein Zugriff erfolgt, verweigert der Designer den Zugriff darauf. Wenn die Eigenschaft andererseits als Typ MessageContextPropertyBase definiert ist, spielt der Nachrichtentyp keine Rolle und der Zugriff auf die Eigenschaft ist möglich.
In benutzerdefinierten Pipelines funktioniert der Mechanismus zum Schreiben oder Höherstufen von Eigenschaften in den Kontext ganz ähnlich. Verwenden Sie zum Schreiben von Eigenschaften einen Aufruf der Methode IBaseMessageContext.Write, um den Wert in den Kontext zu platzieren. Verwenden Sie für höher gestufte Eigenschaften stattdessen einfach die Methode IBaseMessageContext.Promote. Jede dieser Methoden nimmt einen Eigenschaftsnamen, einen Namespace und einen Wert entgegen. Für höher gestufte Eigenschaften werden der Name und der Namespace aus der im Eigenschaftsschema definierten Eigenschaft verwendet. Der Zugriff erfolgt am einfachsten über einen Verweis auf die Eigenschaftsschemaassembly und mithilfe der Eigenschaften der für die Eigenschaft erstellten Klasse. Distinguished Fields verwenden einen allgemeinen Namespace, und der XPath-Ausdruck,
http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFieldsder zum Abrufen des Werts verwendet wird, wird normalerweise als Name verwendet.Der nachfolgende Code zeigt ein Beispiel zum Hochstufen und Schreiben von Eigenschaften in den Kontext. Beachten Sie, dass in diesem Beispiel ein gekennzeichnetes Feld in den Kontext geschrieben wird. Dies ist nur für Orchestrierungen sinnvoll, in denen das Nachrichtenschema das gekennzeichnete Feld identifiziert, sodass dieses vom Orchestrierungs-Designer erkannt wird. Es kann nützlich sein, Eigenschaften für die Verwendung von anderen Pipelinekomponenten auf der empfangenden oder sendenden Seite in den Kontext zu schreiben.
//create an instance of the property to be promoted
SOAP.MethodName methodName = new SOAP.MethodName();
//call the promote method on the context using the property class for name
//and namespace
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,
"theSOAPMethodName");
//write a distinguished field to the context
pInMsg.Context.Write("theDistinguishedProperty",
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",
"theDistinguishedValue");
Denken Sie beim Schreiben oder Heraufstufen von Werten in den Kontext an die folgenden Punkte:
Wenn Sie einen Wert in den Kontext schreiben, der denselben Namen und Namespace verwendet, die zuvor zum höher Stufen der Eigenschaft verwendet wurden, ist diese Eigenschaft nicht mehr höher gestuft. Der Schreibvorgang überschreibt also die Heraufstufung.
Wenn Sie einen Nullwert in den Kontext schreiben, wird der Wert gelöscht, da Eigenschaften mit einem Wert von Null nicht erlaubt sind.
Höher gestufte Eigenschaften dürfen maximal 256 Zeichen lang sein. Für geschriebene Eigenschaften gibt es hingegen keine Längenbeschränkung.
Höher gestufte Eigenschaften werden beim Nachrichtenrouting verwendet und unterliegen aus Effizienzgründen hinsichtlich des Vergleichs und der Speicherung einer Längenbeschränkung. Geschriebene Eigenschaften haben zwar keine Größenbeschränkungen, die Verwendung besonders langer Werte kann sich jedoch negativ auf die Leistung auswirken, da diese Werte verarbeitet und mit der Nachricht übergeben werden müssen.
Wenn eine Nachrichten zum Senden aus BizTalk Server bereit ist, wird sie im Sendeport einem zusätzlichen Prozess unterzogen. Vor dem Ausführen der Sendepipeline werden Zuordnungen auf die Nachrichten angewendet, sodass eine Nachricht in ein kunden- oder anwendungsspezifisches Format umgewandelt werden kann, bevor es von der Pipeline verarbeitet und über den Adapter gesendet wird. In der Sendepipeline werden Eigenschaften nicht in den Nachrichtenkontext heraufgestuft, sondern aus dem Kontext in die Nachricht herabgestuft.
Weitere Informationen
Architektur des Laufzeitmoduls
Verarbeitung großer Nachrichten in BizTalk Server