Austauschmuster für Empfangsadapter

Empfangsadapter empfangen Daten vom "Wire" und übermitteln sie als Nachricht an BizTalk Server. Bei dieser Übermittlung können Nachrichten unidirektional oder bidirektional ausgetauscht werden.

Unidirektionale Übermittlung

Damit ein Empfangsadapter eine Nachricht an die BizTalk-Messaging-Engine übermitteln kann, muss er zunächst eine neue BizTalk-Nachricht erstellen. Das Codebeispiel im Thema "IBaseMessage" zeigt, wie dies funktioniert. Der Stream, den der Adapter als Nachrichtentext festlegt, sollte üblicherweise ein Vorwärtsstream sein, d. h., der Adapter sollte die Daten, die er zuvor in den Speicher eingelesen hat, nicht zwischenspeichern.

Bevor der Adapter die Nachricht an die Engine übermittelt, muss er die InboundTransportLocation-Nachrichtenkontexteigenschaft im Systemnamespace in die BizTalk-Nachricht schreiben. Dies wird im folgenden Codefragment veranschaulicht.

Assembly References:

Microsoft.XLANGs.BaseTypes.dll

Microsoft.BizTalk.Pipeline.dll

Microsoft.BizTalk.GlobalPropertySchemas.dll

using Microsoft.BizTalk.Message.Interop;  
using Microsoft.XLANGs.BaseTypes;  
  
private static readonly PropertyBase InboundTransportLocationProp =   
new BTS.InboundTransportLocation();  
  
private void StampMsgCtxProps(  
IBaseMessage msg, string uri, string adapterType)  
{  
msg.Context.Write(  
 InboundTransportLocationProp.Name.Name,   
 InboundTransportLocationProperty.Name.Namespace,   
  uri);  
}  

Darüber hinaus kann der Adapter eigene Eigenschaftsschemas definieren und Nachrichtenkontexteigenschaften schreiben, die zu dem Endpunkt gehören, über den er die Nachricht empfangen hat. Ein HTTP-Adapter kann beispielsweise die HTTP-Header in den Nachrichtenkontext schreiben, ein SMTP-Empfänger den E-Mail-Betreff. Diese Informationen können nützlich sein für Downstreamkomponenten wie etwa Pipelinekomponenten, Orchestrierungszeitpläne oder Sendeadapter.

Sobald die Nachrichten vorbereitet sind, können sie an die Messaging-Engine übermittelt werden. Informationen dazu, wie ein unidirektionaler Empfangsadapter eine Nachricht an die Engine senden kann, finden Sie im Codebeispiel SubmitDirect (BizTalk Server Beispiel).

Request-Response

Bidirektionale Empfangsadapter werden in der Regel an uni- oder bidirektionalen Empfangsports verwendet. Der Adapter bestimmt, ob der Empfangsspeicherort, an dem er gewartet wird, ein unidirektionalen oder bidirektionalen Port ist, indem er den BizTalk Server Konfigurationseigenschaftenbehälter untersucht. Dieser Prozess wird in der IBTTransportConfig.AddReceiveEndpoint-Methode (COM) in der API-Namespacereferenz für Benutzeroberflächenanleitungen und Entwickler-API erläutert.

Das folgende Diagramm zur Objektinteraktion veranschaulicht den Austausch einer Nachricht vom Typ "Anforderungsantwort". Der Adapter fordert einen neuen Batch vom Transportproxy an und übergibt den Verweis auf die IBTTransmitter-Schnittstelle über die SubmitRequestMessage-Methode . Die Messaging-Engine übermittelt die Antwortnachricht auf dieser Schnittstelle mithilfe der TransmitMessage-Methode .

Da die Engine Nachrichten asynchron verarbeitet, kann Folgendes geschehen:

• Der BatchComplete-Rückruf kann erfolgen, bevor Done zurückgegeben wurde.

• Der Aufruf von TransmitMessage kann vor BatchComplete und sogar vor Done erfolgen.

  Beide Szenarien ereignen sich selten, zudem sollte sich der Adapter selbst davor schützen.

  Die Antwortnachricht sollte mit einem asynchronen, nicht blockierenden Aufruf übertragen werden.

  Das BaseAdapter-Projekt verfügt über die Hilfsprogrammklasse StandardRequestResponseHandler, die die in diesem Thema erläuterte Anforderungs-Antwort-Semantik kapselt.

Timeouts für Nachrichten vom Typ 'Anforderungsantwort'

Wenn ein Adapter eine Anforderungsanforderungsnachricht übermittelt, muss er das Timeout der Anforderungsnachricht in der COM-API (IBTTransportBatch.SubmitRequestMessage Method) in der Api für Benutzeroberflächenleitfäden und Entwickler-API-Namespace angeben. Nur innerhalb des Timeoutzeitraums wird eine Antwortnachricht an den Adapter übermittelt. Nach Ablauf des Timeoutzeitraums wird statt einer Antwortnachricht eine negative Bestätigung an den Adapter übermittelt. Wenn der Adapter keinen Timeoutwert angibt, verwendet die Engine den Standardwert (20 Minuten).

Der Standardtimeout für Nachrichten vom Typ "Anforderungsantwort" kann für Empfangsadapter vom Typ "In-Process" mit dem folgenden Registrierungsschlüssel festgelegt werden:

DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host-GUID}\MessagingReqRespTTL

Für isolierte Empfangsadapter befindet sich der Registrierungsschlüssel an einem anderen Speicherort:

DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\MessagingReqRespTTL

Negative Bestätigungen sind SOAP-Fehler, und es gibt zwei Möglichkeiten, damit umzugehen. In der Regel gibt der Adapter die negative Bestätigung zur Verabreitung an den Client zurück. Alternativ kann die Übertragungspipeline, die die Antwortnachricht verarbeitet, so konfiguriert werden, dass der Inhalt der Antwortnachricht mithilfe einer Zuordnung oder einer benutzerdefinierten Pipelinekomponente geändert wird.