Verarbeiten der Nachricht

Alle bisher beschriebenen Komponenten spielen eine Rolle bei der Verarbeitung von Nachrichten, während sie über BizTalk Server fließen. Dieser Abschnitt enthält weitere Details dazu, wie diese Komponenten funktionell interagieren, beginnend mit dem Empfangen einer Nachricht. Die folgende Abbildung zeigt den Aufbau eines Empfangsports und den Fluss einer Nachricht durch den Empfangsvorgang.

Ein Empfangsport besteht aus einem oder mehreren Empfangsstandorten und null oder mehr Karten. Zuordnungen sind XSLT-Stylesheets (Extensible Stylesheet Language Transformations), die zum Transformieren von XML-Nachrichten von einer Struktur oder einem Format in ein anderes verwendet werden und häufig beim Empfangen verwendet werden, um Nachrichten in ein internes Format zu normalisieren. Empfangsorte steuern die Endpunkte, die Nachrichten empfangen. Ein Empfangsspeicherort besteht aus der Konfiguration eines Endpunkts für einen Empfangsadapter sowie einer Empfangspipeline.

Die Rolle des Adapters

Der Empfangsadapter initiiert den Prozess des Empfangens von Nachrichten, indem er einen Datenstrom liest und eine Nachricht erstellt. Der Dateiadapter sieht beispielsweise, dass eine Datei am konfigurierten Speicherort abgelegt wurde und diese Datei in einem Datenstrom liest. Der Adapter erstellt eine Nachricht (eine Implementierung der Microsoft.BizTalk.Message.Interop.IBaseMessage-Schnittstelle), fügt einen Teil hinzu (eine Implementierung der Microsoft.BizTalk.Message.Interop.IBasePart-Schnittstelle), und stellt den Datenstrom als Teilinhalt bereit.

Darüber hinaus schreibt der Adapter Eigenschaften in den Nachrichtenkontext, die mit dem Standort, dem Adaptertyp und anderen Aspekten des Adapters zusammenhängen. Nachdem die Nachricht und der zugehörige Kontext erstellt wurden, übergibt der Adapter die Nachricht an den Endpoint Manager. Die Nachricht wird dann über die Empfangspipeline verarbeitet, die für den Empfangsstandort konfiguriert wurde. Nachdem die Nachricht von der Pipeline verarbeitet wurde, kann eine Zuordnung verwendet werden, um die Nachricht in das gewünschte Format zu transformieren, bevor der Endpoint Manager die Nachricht über den Message Agent veröffentlicht.

Die Rolle der Pipeline

Während es sich um den Adapter handelt, der die anfängliche Nachricht erstellt, erfolgt der Großteil der Verarbeitung, die in einer empfangenen Nachricht auftritt, in der Empfangspipeline. Die Pipelineverarbeitung behandelt Nachrichteninhalte sowie den Nachrichtenkontext. Nachrichteninhalte werden in der Regel in den Phasen Decodierung, Demontage und Überprüfung behandelt, während der Nachrichtenkontext in allen Phasen behandelt werden kann. Eine Pipeline reagiert jedoch nicht unbedingt auf den Inhalt oder den Kontext. Die Standarddurchlaufpipeline hat z. B. keine Komponenten konfiguriert und führt keine Verarbeitung für den Nachrichteninhalt oder den Kontext durch. Der Einfachheit halber konzentriert sich dieses Dokument auf die Zerlegungskomponenten, da sie im Allgemeinen die größten Auswirkungen auf das Nachrichtenrouting haben.

Die Aufgabe des Disassemblers besteht darin, eine eingehende Nachricht von einem Adapter zu verarbeiten und in viele Nachrichten zu zerlegen und die Nachrichtendaten zu analysieren. Wenn eine eingehende Nachricht viele kleinere Nachrichten enthält, wird dies als Austausch bezeichnet. Sowohl der Flat-File-Disassembler als auch der XML-Disassembler verarbeiten Austauschvorgänge, indem ein Entwickler Informationen zum Umbruchinhalt (d. h. ein Header- und Trailing-Schema für den Flat-File-Disassembler und ein Umschlagschema für den XML-Disassembler) und den (potenziell wiederholten) Hauptinhalt konfigurieren kann. Darüber hinaus analysieren beide Disassembler die ursprüngliche Nachricht in XML-Inhalte. Ein benutzerdefinierter Disassembler analysiert den Inhalt nicht unbedingt in XML, wenn keine weitere XML-Verarbeitung in BizTalk Server erforderlich ist. Ein Beispielszenario könnte eine einfache Routingsituation beinhalten, bei der Nachrichten, die an einem bestimmten Empfangsort in das System eintreffen, zu einem bestimmten Sendepunkt gesendet werden, ohne Mapping oder andere XML-basierte Verarbeitung.

Routing anhand des Nachrichtentyps

Eine der am häufigsten beim Routing verwendeten Nachrichteneigenschaften ist der Nachrichtentyp. Wenn ein Entwickler ein Schema zum Definieren der Struktur von Nachrichten erstellt, definiert dieses Schema den Nachrichtentyp für diese Nachricht. Der Typ wird durch den Stammknoten und den Namespace in der Schemadefinition bestimmt. Beispielsweise würde ein XML-Dokument, das wie folgt aussieht, einen Nachrichtentyp aufweisen: http://tempuri.org/samples/MessageType#Message

<Message xmlns=http://tempuri.org/samples/MessageType>  
<SomeOtherElement type="sample"/>  
</Message>  

Um den Nachrichtentyp im Routing zu verwenden, muss er in den Kontext heraufgestuft werden. Disassembler dienen dazu, diesen Wert in den Nachrichtenkontext und in die Pipeline-Komponenten mit dem am spezifischsten Wissen über die Nachrichtenstruktur zu integrieren. Die XML- und Flat File-Disassembler fördern den Nachrichtentyp bei der Verarbeitung von Nachrichten, und jeder benutzerdefinierte Disassembler sollte diese Eigenschaft auch höher stufen, um ein ordnungsgemäßes Routing sicherzustellen.

Es ist wichtig zu beachten, dass eine Nachricht nicht über einen Typ verfügen muss. Wie bereits erwähnt, können die Teile einer Nachricht binärdaten sein und benötigen kein Schema, das ihre Struktur definiert. Diese Art von Nachrichtenteil wird im Allgemeinen ohne wesentliche Verarbeitung durch den BizTalk Server weitergereicht, obwohl benutzerdefinierte Pipelinekomponenten, Adapter oder Code, der aus Orchestrierungen aufgerufen wird, mit diesen Teilen interagieren können.

Pipelinekomponenten, wie z. B. Adapter, schreiben Eigenschaften in den Nachrichtenkontext und heben sie hervor. Tatsächlich sind Pipelinekomponenten der am häufigsten verwendete Mechanismus, den die meisten Entwickler verwenden, um Eigenschaften in den Nachrichtenkontext zu integrieren. 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 Disassemblier- und Assemblerkomponenten – FlatFile, XML und BizTalk Framework – verwenden das Dokumentschema, um Informationen zu den Eigenschaften abzurufen, die heraufgestuft werden sollen. Mithilfe der XML Path Language (XPath)-Anweisung aus den Anmerkungen kennt der Disassembler die Position der höhergestuften Elemente im Dokument. Während des Durchsuchens des Dokuments findet der Disassembler die Elemente, die mit einem der XPath-Ausdrücke übereinstimmen, und fördert oder schreibt den Wert entsprechend in den Kontext.

Benutzerdefinierte Pipelinekomponenten können auch geschrieben werden, um Eigenschaften beliebiger Daten in den Kontext einer empfangenen oder gesendeten Nachricht einzubringen. Um eine Eigenschaft in den Kontext zu integrieren und für das Routing nützlich zu machen, was vermutlich der Grund für die Höherstufung des Wertes ist, sollte ein Eigenschaftenschema mit einer Definition für die Eigenschaft erstellt und auf BizTalk Server bereitgestellt werden. Bevor Sie ein Eigenschaftenschema definieren, das von benutzerdefinierten Komponenten verwendet werden soll, sollten Sie die verschiedenen Typen höhergestufter Eigenschaften verstehen. Höhergestufte Eigenschaften, die in einem Eigenschaftenschema definiert sind, können einen von zwei Basistypen aufweisen:

• Microsoft.XLANGs.BaseTypes.MessageContextPropertyBase oder

• Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase

  Eine Eigenschaft mit einem Basistyp von MessageDataPropertyBase gibt an, dass der Wert für diese Eigenschaft aus dem Inhalt der Nachricht stammt. Dies ist der Standardwert für Eigenschaften, die in einem Eigenschaftenschema definiert sind und die am häufigsten verwendete Verwendung ist. MessageContextPropertyBase gibt eine Eigenschaft an, die Teil des Nachrichtenkontexts sein soll, aber nicht unbedingt direkt aus den Nachrichtendaten stammt. Eigenschaften mit MessageContextPropertyBase als Basistyp werden häufig von Adaptern und Disassemblern heraufgestuft und enthalten allgemeine Eigenschaften wie Nachrichtentyp und Adaptertyp.

  Es ist wichtig, die verschiedenen Typen zu verstehen und beim Definieren von Eigenschaften entsprechend zu verwenden. Eine der wichtigsten Auswirkungen tritt beim Zugriff auf Kontexteigenschaften für eine Nachricht in einer Orchestrierung auf. Wenn eine Eigenschaft als MessageDataPropertyBase identifiziert wird, überprüft der Orchestration-Designer das Schema der empfangenen Nachricht und stellt sicher, dass sie eine übereinstimmende höhergestufte Eigenschaft definiert. Wenn keine Eigenschaft im Schema gefunden wird, das an die höhergestufte Eigenschaft gebunden ist, auf die zugegriffen wird, ermöglicht der Designer nicht den Zugriff darauf. Wenn die Eigenschaft dagegen als MessageContextPropertyBase definiert ist, spielt der Nachrichtentyp keine Rolle, und auf die Eigenschaft kann zugegriffen werden.

  In benutzerdefinierten Pipelines ist der Mechanismus zum Schreiben oder Befördern von Eigenschaften in den Kontext ähnlich. Zum Schreiben von Eigenschaften verwenden Sie einen Aufruf der IBaseMessageContext Write-Methode, um den Wert im Kontext zu platzieren. Für höhergestufte Eigenschaften verwenden Sie stattdessen einfach die IBaseMessageContext Promote-Methode. Jede dieser Methoden verwendet einen Eigenschaftsnamen, einen Namespace und einen Wert. Für die heraufgestuften Eigenschaften sind der Name und der Namespace die der im Eigenschaftenschema definierten Eigenschaft und werden am einfachsten aufgerufen, indem auf die Eigenschaftenschemaassembly verwiesen und die Eigenschaften für die Klasse verwendet werden, die für die Eigenschaft erstellt wurde. Unterscheidungsmerkmale verwenden einen gemeinsamen Namensraum, http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields, und der XPath-Ausdruck, der zur Ermittlung des Werts verwendet wird, wird üblicherweise als Name verwendet.

  Der folgende Code zeigt ein Beispiel für das Fördern und Schreiben von Eigenschaften in den Kontext. Beachten Sie, dass in diesem Beispiel ein hervorgehobenes Feld in den Kontext eingefügt wird. Dies ist nur für Orchestrierungen nützlich, bei denen das Nachrichtenschema das Distinguished Field identifiziert, sodass der Orchestration Designer dieses Feld kennt. Es kann hilfreich sein, Eigenschaften in den Kontext zu schreiben, um von anderen Pipelinekomponenten auf der empfangenden oder sendenden Seite verwendet zu werden.

//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");  

Beachten Sie beim Schreiben oder Fördern von Werten im Kontext die folgenden Fakten:

• Wenn Sie einen Wert in den Kontext mit demselben Namen und demselben Namespace schreiben, der zuvor zum Höherstufen der Eigenschaft verwendet wurde, wird diese Eigenschaft nicht mehr heraufgestuft. Der Schreibvorgang überschreibt grundsätzlich die Promotion.

• Durch das Schreiben eines Werts von NULL in den Kontext wird der Wert gelöscht, da nullwertige Eigenschaften nicht zulässig sind.

• Beworbene Eigenschaften sind auf 256 Zeichen Länge beschränkt, während geschriebene Eigenschaften keine Längenbeschränkung haben.

  Bevorzugte Eigenschaften werden im Nachrichtenrouting verwendet und sind aus Gründen der Effizienz in der Größe für Vergleich und Speicherung begrenzt. Während geschriebene Eigenschaften keine harten Größenbeschränkungen aufweisen, wirkt sich die Verwendung übermäßig großer Werte im Kontext auf die Leistung aus, da diese Werte weiterhin verarbeitet und mit der Nachricht übergeben werden müssen.

  Wenn eine Nachricht von BizTalk Server gesendet werden kann, wird sie einem ergänzenden Prozess im Sendeport unterzogen. Karten werden auf Nachrichten angewendet, bevor die Sendepipeline ausgeführt wird, sodass eine Nachricht in ein kunden- oder anwendungsspezifisches Format umgewandelt werden kann, bevor sie von der Pipeline verarbeitet und über den Adapter gesendet wird. In der Sendepipeline werden Eigenschaften vom Kontext in die Nachricht herabgestuft, anstatt Eigenschaften in den Nachrichtenkontext zu fördern.

  senden

Siehe auch

Laufzeitarchitektur
So verarbeitet BizTalk Server große Nachrichten