HTTP-Sendeadapter

Der HTTP-Sendeadapter ruft Nachrichten von BizTalk Server ab und sendet sie in einer HTTP POST-Anforderung an eine Ziel-URL. Der HTTP-Sendeadapter ruft den Nachrichteninhalt aus dem Textteil des BizTalk-Nachrichtenobjekts ab. Alle anderen Teile des BizTalk-Nachrichtenobjekts werden vom HTTP-Sendeadapter ignoriert.

Nachdem der Adapter die Nachricht an eine Ziel-URL gesendet und die BizTalk-Messaging-Engine den HTTP-Statuscode für Erfolg empfangen hat, löscht der HTTP-Sendeadapter die Nachricht aus der MessageBox-Datenbank.

Die Umleitung von HTTP-Nachrichten wird unterstützt und kann am Sendeport konfiguriert werden.

BizTalk Server hostet den HTTP-Sendeadapter als native BizTalk-Anwendung. Dabei wird das unidirektionale Senden von Nachrichten ebenso wie die Übertragung vom Typ „Antwort anfragen“ unterstützt. Der Sendespeicherort für den HTTP-Sendeadapter ist eine eindeutige URL, die über den Sendeport konfiguriert wird. Diese eindeutige URL kann Abfragezeichenfolgen umfassen, die an die Basis-URL angefügt werden.

Batchverarbeitungsunterstützung für den HTTP-Sendeadapter

Der HTTP-Sendeadapter unterstützt keine Batchvorgänge.

Unterstützung der aufgeteilten Codierung für den HTTP-Sendeadapter

Wenn die Option Konfiguration für die blockierte Codierung aktivieren aktiviert ist, sendet der HTTP-Sendeadapter Anforderungsnachrichten mit blockierter Codierung, wenn die Anforderungsgröße 8 KB überschreitet. Wenn der HTTP-Proxyserver verwendet wird, verwendet der HTTP-Sendeadapter die aufgeteilte Codierung nicht und stellt die Daten immer vor dem Senden bereit. Die Konfigurationsoption Blockcodierung aktivieren ist standardmäßig aktiviert.

Der Sendeadapter kann beim Empfang Antwortnachrichten mit einem Textteil mit aufgeteilter Codierung akzeptieren.

Clientauthentifizierung für den HTTP-Sendeadapter

Der HTTP-Sendeadapter verwendet einen der folgenden Authentifizierungstypen, um sich beim Zielserver zu authentifizieren:

• Anonym Der HTTP-Adapter sendet beim Herstellen der Verbindung mit dem Zielserver keine Anmeldeinformationen. Wenn der Zielserver die anonyme Authentifizierung zulässt, werden die Anmeldeinformationen des auf dem Zielserver konfigurierten anonymen Kontos verwendet.

• Standard. Die HTTP-Adapter sendet den Benutzernamen und das Kennwort als unverschlüsselten Text (Nur-Text-Format) über eine HTTP-Verbindung.

• Digest. Der HTTP-Adapter sendet Kennwörter in einem verschlüsselten Format über die HTTP-Verbindung.

• Kerberos. Weder der Benutzername noch das Kennwort werden über eine HTTP-Verbindung gesendet. Der HTTP-Adapter verwendet die Anmeldeinformationen des Prozesses, unter dem der HTTP-Sendeadapter für diesen Authentifizierungstyp ausgeführt wird.

  Zusätzlich kann der HTTP-Sendeadapter dem Webserver ein SSL-Zertifikat (Secure Sockets Layer) bereitstellen, wenn der Server ein solches Zertifikat erfordert oder akzeptiert.

Clientzertifikate für den HTTP-Sendeadapter

Der HTTP-Sendeadapter kann sichere Verbindungen mit Servern herstellen, die Clientzertifikate akzeptieren oder erfordern. Wenn ein Clientzertifikat angegeben wird, verwendet der HTTP-Sendeadapter das Zertifikat, wenn er eine Verbindung mit einem Server herstellt, der Clientzertifikate erfordert oder akzeptiert. Wenn kein Clientzertifikat angegeben wird, der Zielserver aber ein Zertifikat erfordert, kann der HTTP-Sendeadapter die Nachricht nicht senden. Der Adapter geht dann entsprechend der Standardwiederholungslogik vor.

Der HTTP-Sendeadapter verwendet das Clientzertifikat aus dem persönlichen Speicher des Kontos, unter dem der BizTalk Server Prozess ausgeführt wird. Das Zertifikat wird durch seinen Fingerabdruck angegeben. Kann der HTTP-Sendeadapter das Zertifikat aus irgendeinem Grund nicht laden, wird die Nachricht, die der Adapter gesendet hat, angehalten.

SSO-Unterstützung für den HTTP-Adapter

Mithilfe der BizTalk-Verwaltungskonsole können Sie die Funktion Einmaliges Anmelden für Unternehmen (Single Sign-On, SSO) für einen HTTP-Empfangsspeicherort oder einen Sendeport konfigurieren. In diesem Thema wird die Verwendung von SSO mit dem HTTP-Adapter beschrieben.

SSO-Unterstützung für den HTTP-Empfangsspeicherort

Wenn Microsoft Internetinformationsdienste (IIS) eine HTTP-Anforderung von einem Webclient empfängt, authentifiziert IIS den Benutzer. Die ISAPI-Erweiterung (Internet Server Application Programming Interface) nimmt die Identität des Microsoft Windows-Benutzers an und ruft dann den SSO-Anmeldeinformationenspeicher auf, um ein verschlüsseltes Ticket abzurufen. Dieses Ticket wird als SSOTicket-Eigenschaft im Kontext der Nachricht gespeichert.

Im Pass-Through-Szenario wird die Nachricht von der BizTalk-Messaging-Engine zur MessageBox-Datenbank geleitet. Wenn der Adapter die Nachricht von der MessageBox-Datenbank empfängt, ruft der HTTP-Adapter die ISSOTicket.RedeemTicket-Methode mit dem verschlüsselten Ticket zusammen mit dem Anwendungsnamen auf, um die Back-End-Anmeldeinformationen aus dem SSO-Speicher abzurufen. Der HTTP-Adapter verwendet anschließend die externen Anmeldeinformationen, um eine Verbindung mit dem Back-End-System herzustellen und die Anforderung zu verarbeiten. Weitere Informationen zu den Partneranwendungen finden Sie unter SSO-Partneranwendungen.

In dem Szenario, in dem eine Orchestrierung den Adapter aufruft, wird die Nachricht von der BizTalk-Messaging-Engine zur MessageBox-Datenbank gesendet. Die Orchestrierung sollte sicherstellen, dass sowohl die SSOTicket-Kontexteigenschaft als auch die Kontexteigenschaft Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID der Nachricht, die das Ticket enthält, beibehalten werden. Wenn der Adapter diese Nachricht aus der MessageBox-Datenbank empfängt, ruft der Adapter RedeemTicket mit dem verschlüsselten Ticket auf, um die Back-End-Anmeldeinformationen aus dem SSO-Speicher abzurufen. Der Benutzer, der den Plan entwirft, muss insbesondere diese Eigenschaft in die Nachricht kopieren.

SSO-Unterstützung für die HTTP-Sendeadapter

Wenn SSO aktiviert ist und ein HTTP-Sendeport eine Nachricht mit der Secure-Eigenschaft empfängt, ruft er den SSO-Server auf, um das Ticket für eine Partneranwendung zu überprüfen und einzulösen. Die Verwaltungsanwendung, Partneradministratoren und SSO-Administratoren der Partneranwendung können SSO aufrufen, um ein Ticket einzulösen. SSO entschlüsselt anschließend das Ticket und ruft die Back-End-Anmeldeinformationen ab. Das Pass-Through- und das Orchestrierungsszenario sind mit denen für den HTTP-Sendeport identisch.

Standardmäßig ist SSO für den HTTP-Sendeport deaktiviert. Weitere Informationen zum Aktivieren des einmaligen Anmeldens für den HTTP-Sendeport finden Sie unter Konfigurieren eines HTTP-Sendeports.

Hinweis

Sie können SSO nur mit der Standard- und der Digestauthentifizierung verwenden.

Damit die SSO-Unterstützung für den HTTP-Empfangs- und -Sendadapter ordnungsgemäß implementiert werden kann, müssen die folgenden Bedingungen erfüllt sein:

• An den folgenden Orten muss jeweils dasselbe Benutzerkonto angegeben werden:

  • Die Anwendungspoolidentität (IIS 7.0) oder die Identität der COM+-Hostanwendung für das virtuelle IIS-Verzeichnis, das vom HTTP-Empfangsadapter überwacht wird. Weitere Informationen zum Konfigurieren von IIS für HTTP-Empfangsspeicherorte finden Sie unter Konfigurieren von IIS für einen HTTP-Empfangsspeicherort.

  • Die Anmeldeinformationen, die für den isolierten Host verwendet werden, instance, in dem der HTTP-Adapter ausgeführt wird. Informationen zum Konfigurieren der Anmeldeinformationen für einen Host instance finden Sie unter Ändern von Hostinstanzeigenschaften.

• Der isolierte Host, den der HTTP-Adapter verwendet, muss für vertrauenswürdige Authentifizierung konfiguriert sein. Informationen zum Konfigurieren eines Hosts als vertrauenswürdige Authentifizierung finden Sie unter Ändern von Hosteigenschaften.

Negative Bestätigungsnachrichten (NACK), die der HTTP- oder SOAP-Adapter bei gescheiterten Übertragungen generiert

Wenn eine Nachricht erfolgreich übertragen wurde, veröffentlicht die BizTalk-Messaging-Engine eine zugeordnete Bestätigungsnachricht (ACK) in MessageBox, wenn Übermittlungsbenachrichtigungen aktiviert sind. Wenn eine Nachricht von der BizTalk-Messaging-Engine angehalten wird oder eine Orchestrierung von der Orchestrierungs-Engine angehalten wird, veröffentlicht BizTalk Server eine zugeordnete negative Bestätigungsnachricht (NACK) in MessageBox. Die NACK-Nachricht enthält Kontexteigenschaften und einen Nachrichtentextteil, der aus einem SOAP-Fehler besteht. Wurde die NACK-Nachricht wegen einer gescheiterten Übermittlung vom HTTP- oder SOAP-Adapter generiert, enthält der SOAP-Fehler das Headers-Element und das Body-Element der Antwort des Zielwebservers. Das folgende Beispiel zeigt den SOAP-Fehler (SOAP Fault) in einer NACK, die für eine gescheiterte HTTP-Übertragung generiert wurde:

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">  
   <SOAP:Body>  
      <SOAP:Fault>  
         <faultcode>Microsoft BizTalk Server Negative Acknowledgment</faultcode>   
         <faultstring>An error occurred while processing the message, refer to the details section for more information</faultstring>   
         <faultactor>http://localhost/receivestandard.asp</faultactor>   
         <detail>  
            <ns0:NACK Type="NACK" xmlns:ns0="http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd">  
            <NAckID>{4E646707-03AA-4493-95C7-A64B09E2987D}</NAckID>  
            <ErrorCode>0x80131600</ErrorCode>  
            <ErrorCategory>0</ErrorCategory>  
            <ErrorDescription>The remote server returned an error: (404) Not Found.</ErrorDescription>  
            <ErrorDetail>  
            <HttpErrorDetail xmlns="http://schema.microsoft.com/BizTalk/2006/HttpErrorDetails.xsd">  
               <Headers>Server: Microsoft-IIS/5.1 Date: Wed, 21 Apr 2005 00:27:47 GMT X-Powered-By: ASP.NET Connection: close Content-Type: text/html Content-Length: 67 </Headers>  
               <Body>We could not locate the page you requested. Please check the URL.</Body>  
            </HttpErrorDetail>  
            </ErrorDetail>  
            </ns0:NACK>  
         </detail>  
      </SOAP:Fault>  
   </SOAP:Body>  
</SOAP:Envelope>  

Hinweis

Das Headers- und das Body-Element sind auf 48 KB beschränkt. Das Headers-Element wird auf das nächste vollständige Header-Wertepaar gerundet, ohne dass die Beschränkung überschritten wird. Das Body-Element wird auf 48 KB gekürzt.

Hinweis

NACK- und ACK-Nachrichten werden verworfen, wenn es keine entsprechenden Abonnements für sie gibt. NACK- und ACK-Nachrichten werden nicht von der BizTalk-Messaging-Engine angehalten.

Wenn Sie eine NACK-Nachricht abonnieren möchten, haben Sie folgende Möglichkeiten:

• Erstellen Sie einen Sendeport mit einem Filter für die entsprechende Nachrichtenkontexteigenschaft. Eine Liste der Eigenschaften des Systemnachrichtenkontexts, einschließlich der Eigenschaften im Zusammenhang mit der Nachrichtenbestätigung, finden Sie unter Eigenschaften des Nachrichtenkontexts in der Benutzeroberflächenanleitung und in der API-Namespacereferenz für Entwickler .

• Senden von einem Orchestrierungsport, der mit Übermittlungsbenachrichtigung = Übertragen gekennzeichnet ist. Wenn ein Orchestrierungsport mit Übermittlungsbenachrichtigung = Übertragen gekennzeichnet ist, wartet die Orchestrierung, bis sie entweder einen ACK oder einen NACK für die übertragene Nachricht empfängt. Wurde eine NACK generiert, wird diese an die Orchestrierung weitergeleitet, und die Orchestrierung löst eine Übermittlungsfehlerausnahme (DeliveryFailureException) aus. Die DeliveryFailureException wird aus dem SOAP-Fehler deserialisiert, der im NACK-Nachrichtentext enthalten ist. Zum Abrufen der Zeichenfolge der Ausnahmenachricht aus dem SOAP-Fehler, der an die Orchestrierung zurückgegeben wurde, wandeln Sie die DeliveryFailureException in eine SOAP-Ausnahme (SoapException) um und greifen dann im SOAP-Abschnitt Detail auf das InnerXml-Element zu. Das folgende Codebeispiel veranschaulicht die dafür erforderliche Vorgehensweise:

  // Cast the DeliveryFailureException to a SoapException…  
  System.Web.Services.Protocols.SoapException se = (System.Web.Services.Protocols.SoapException)e.InnerException;  
  System.Diagnostics.Trace.WriteLine(se.Detail.InnerXml);  
  //e is an Microsoft.XLANGs.BaseTypes.DeliveryFailureException  
  //object type created in an Exception handler  
  
  

  In diesem Codebeispiel wird ein XML-Fragment zurückgegeben, das dem folgenden Fragment ähnelt:

  <ns0:NACK Type="NACK" xmlns:ns0="http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd">  
  <NAckID>{4E646707-03AA-4493-95C7-A64B09E2987D}</NAckID>  
  <ErrorCode>0x80131600</ErrorCode>  
  <ErrorCategory>0</ErrorCategory>  
  <ErrorDescription>The remote server returned an error: (404) Not Found.</ErrorDescription>  
  <ErrorDetail>  
  <HttpErrorDetail xmlns="http://schema.microsoft.com/BizTalk/2006/HttpErrorDetails.xsd">  
     <Headers>Server: Microsoft-IIS/5.1 Date: Wed, 21 Apr 2005 00:27:47 GMT X-Powered-By: ASP.NET Connection: close Content-Type: text/html Content-Length: 67 </Headers>  
     <Body>We could not locate the page you requested. Please check the URL.</Body>  
  </HttpErrorDetail>  
  </ErrorDetail>  
  </ns0:NACK>  
  

Weitere Informationen

HTTP-Adaptern
SSO-COM-Objekte in der Api-Namespacereferenz für Benutzeroberflächen und Entwickler