Condividi tramite

Adapter di trasmissione HTTP

  • Articolo

L'adapter di invio HTTP ottiene messaggi da BizTalk Server e li invia a un URL di destinazione in una richiesta HTTP POST. Il contenuto dei messaggi viene ricavato dalla parte corpo dell'oggetto messaggio BizTalk, mentre tutte le altre parti dell'oggetto vengono ignorate.

Dopo che l'adapter invia il messaggio a un URL di destinazione e che il motore di messaggistica BizTalk riceve il codice di stato HTTP indicante la riuscita dell'operazione, l'adapter di trasmissione HTTP elimina il messaggio dal database MessageBox.

Il reindirizzamento dei messaggi HTTP è supportato e può essere configurato sulla porta di trasmissione.

BizTalk Server ospita l'adapter di trasmissione HTTP come applicazione BizTalk nativa. Sono pertanto supportati l'invio unidirezionale dei messaggi e la trasmissione sollecitazione-risposta. L'indirizzo di trasmissione per l'adapter di trasmissione HTTP è un URL distinto che viene configurato tramite la porta di trasmissione. Questo URL univoco può includere stringhe di query aggiunte all'URL di base.

Supporto dell'invio in batch per l'adapter di trasmissione HTTP

L'adapter di trasmissione HTTP non supporta le operazioni batch.

Supporto della codifica Chunked per l'adapter di trasmissione HTTP

Se l'opzione abilita la configurazione della codifica in blocchi è abilitata, l'adattatore di invio HTTP invia messaggi di richiesta usando la codifica in blocchi se le dimensioni della richiesta superano 8 KB. Se viene utilizzato il server proxy HTTP, l'adapter di trasmissione HTTP non applicherà la codifica Chunked ed eseguirà sempre la gestione temporanea dei dati prima di inviarli. L'opzione Abilita la configurazione della codifica in blocchi è abilitata per impostazione predefinita.

Quando l'adapter di trasmissione riceve un messaggio di risposta, può accettarlo se per la parte corpo è stata utilizzata la codifica Chunked.

Autenticazione client per l'adapter di trasmissione HTTP

L'adapter di trasmissione HTTP esegue l'autenticazione con il server di destinazione utilizzando uno dei seguenti tipi di autenticazione:

  • Anonimo. L'adapter HTTP non invia credenziali quando si connette al server di destinazione. Se quest'ultimo consente l'autenticazione anonima, verranno utilizzate le credenziali dell'account anonimo configurato sul server.

  • Base. L'adapter HTTP invia il nome utente e la password attraverso una connessione HTTP come testo non crittografato.

  • Digest. L'adapter HTTP invia password in formato crittografato attraverso la connessione HTTP.

  • Autenticazione Kerberos. Né il nome utente né la password vengono inviati attraverso una connessione HTTP. Per questo tipo di autenticazione l'adapter HTTP utilizza le credenziali del processo all'interno del quale viene eseguito l'adapter di trasmissione HTTP.

    L'adapter di trasmissione HTTP potrà inoltre fornire un certificato SSL (Secure Sockets Layer) client al server Web se quest'ultimo lo richiede o lo accetta.

Certificati client per l'adapter di trasmissione HTTP

L'adapter di trasmissione HTTP può stabilire una connessione sicura con i server che accettano o richiedono certificati client. Se viene specificato un certificato client, l'adapter di trasmissione HTTP utilizzerà il certificato al momento di connettersi a server che richiedono o accettano tali certificati. Se il certificato client non viene specificato e il server di destinazione richiede certificati di questo tipo, l'adapter di trasmissione HTTP non riuscirà a inviare il messaggio e seguirà la logica standard per effettuare ulteriori tentativi.

L'adattatore di trasmissione HTTP usa il certificato client dall'archivio personale dell'account in cui è in esecuzione il processo di BizTalk Server. Il certificato è specificato dalla relativa identificazione personale. Se per qualsiasi motivo l'adapter di trasmissione HTTP non riesce a caricare il certificato, il messaggio che stava tentando di inviare verrà sospeso.

Supporto di Single Sign-On per l'adapter HTTP

La Console di amministrazione BizTalk consente di configurare Enterprise Single Sign-On (SSO) per l'utilizzo con la porta di trasmissione o l'indirizzo di ricezione HTTP. In questo argomento viene descritto il funzionamento del servizio SSO con l'adapter HTTP.

Supporto di Single Sign-On per l'indirizzo di ricezione HTTP

Al momento della ricezione di una richiesta HTTP da un client Web, Microsoft Internet Information Services (IIS) esegue l'autenticazione dell'utente. L'estensione ISAPI (Internet Server Application Programming Interface) rappresenta l'utente di Microsoft Windows, quindi chiama l'archivio delle credenziali SSO per ottenere un ticket crittografato, Questo ticket viene archiviato come proprietà SSOTicket nel contesto del messaggio.

Nello scenario di tipo pass-through, il motore di messaggistica BizTalk indirizza il messaggio al database MessageBox. Quando l'adapter riceve il messaggio dal database MessageBox, l'adapter HTTP chiama il metodo ISSOTicket.RedeemTicket con il ticket crittografato insieme al nome dell'applicazione per recuperare le credenziali back-end dall'archivio SSO. L'adapter HTTP utilizza quindi le credenziali esterne per connettersi al sistema back-end ed elaborare la richiesta. Per altre informazioni sulle applicazioni affiliate, vedere Applicazioni affiliate SSO.

Nello scenario in cui un'orchestrazione richiama l'adapter, il motore di messaggistica BizTalk invia il messaggio al database MessageBox. L'orchestrazione deve garantire che sia la proprietà di contesto SSOTicket che la proprietà di contesto Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID del messaggio che contiene il ticket vengano mantenute. Quando l'adapter riceve questo messaggio dal database MessageBox, l'adapter chiama RedeemTicket con il ticket crittografato per recuperare le credenziali back-end dall'archivio SSO. È consigliabile che l'utente che definisce la pianificazione copi specificamente tale proprietà nel messaggio.

Supporto di Single Sign-On per gli adapter di trasmissione HTTP

Se SSO è abilitato, quando una porta di trasmissione HTTP riceve un messaggio con la proprietà Secure , chiama il server SSO per convalidare e riscattare il ticket per un'applicazione affiliata. L'applicazione di amministrazione, gli amministratori affiliati o gli amministratori SSO dell'applicazione affiliata possono chiamare SSO per riscattare un ticket. SSO esegue la decrittografia del ticket e ottiene le credenziali back-end. Lo scenario pass-through e quello di orchestrazione sono analoghi a quelli previsti per la porta di trasmissione HTTP.

Per impostazione predefinita, SSO è disabilitato per la porta di trasmissione HTTP. Per altre informazioni sull'abilitazione dell'accesso Single Sign-On per la porta di trasmissione HTTP, vedere Configurazione di una porta di trasmissione HTTP.

Nota

È possibile utilizzare Single Sign-On solo con l'autenticazione di base e con l'autenticazione del digest.

Per una corretta implementazione del supporto di Single Sign-On per l'adapter di ricezione e di trasmissione HTTP, è necessario che vengano soddisfatte le seguenti condizioni:

  • Deve essere specificato lo stesso account utente nelle seguenti posizioni:

    • Identità del pool di applicazioni (IIS 7.0) o identità dell'applicazione COM+ di hosting (IIS 5.1) per la directory virtuale di IIS monitorata dall'adapter di ricezione HTTP. Per altre informazioni sulla configurazione di IIS per i percorsi di ricezione HTTP, vedere Come configurare IIS per un percorso di ricezione HTTP.

    • Credenziali di accesso usate per l'istanza host isolata in cui è in esecuzione l'adapter HTTP. Per informazioni su come configurare le credenziali di accesso per un'istanza host, vedere Come modificare le proprietà dell'istanza host.

  • L'host di tipo Isolato utilizzato dall'adapter HTTP deve essere configurato come Considerato attendibile in base all'autenticazione. Per informazioni su come configurare un host come attendibilità di autenticazione, vedere Come modificare le proprietà dell'host.

Messaggi NACK (Negative Acknowledgment) generati per trasmissioni non riuscite da parte dell'adapter HTTP o SOAP

Quando un messaggio viene trasmesso correttamente, il motore di messaggistica BizTalk pubblica un messaggio ACK (Acknowledgment) associato nel database MessageBox se le notifiche di recapito sono abilitate. Analogamente, quando un messaggio viene sospeso dal motore di messaggistica BizTalk o un'orchestrazione viene sospesa dal motore di orchestrazione, BizTalk Server pubblica un messaggio di riconoscimento negativo associato (NACK) nel MessageBox. Nel messaggio NACK sono contenute proprietà di contesto e una parte corpo costituita da un errore SOAP. Se il messaggio NACK viene generato a causa di una trasmissione non riuscita da parte dell'adapter HTTP o SOAP, nell'errore SOAP saranno contenuti gli elementi Headers e Body della risposta proveniente dal server Web di destinazione. Di seguito è riportato un esempio dell'errore SOAP incluso in un messaggio NACK generato per una trasmissione HTTP non riuscita:

<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>

Nota

Le dimensioni degli elementi Headers e Body sono limitate a 48 KB. L'elemento Headers viene arrotondato alla coppia di valori di intestazione completa più vicina senza superare il limite. L'elemento Body viene troncato a 48 KB.

Nota

I messaggi NACK e ACK vengono rimossi se non sono presenti sottoscrizioni corrispondenti. Non vengono sospesi dal motore di messaggistica BizTalk.

Per eseguire la sottoscrizione a un messaggio NACK, è possibile effettuare una delle seguenti operazioni:

  • Creare una porta di trasmissione con un filtro per la proprietà di contesto del messaggio appropriata. Vedere Message Context Properties (Proprietà contesto messaggio) nelle linee guida dell'interfaccia utente e informazioni di riferimento sullo spazio dei nomi dell'API developers per un elenco delle proprietà del contesto dei messaggi di sistema, incluse quelle correlate al riconoscimento dei messaggi.

  • Inviare da una porta di orchestrazione contrassegnata con notifica di recapito = trasmessa. Se una porta di orchestrazione è contrassegnata con notifica di recapito = trasmessa, l'orchestrazione attenderà finché non riceve un ACK o un NACK per il messaggio trasmesso. Se viene generato un messaggio NACK, verrà instradato all'orchestrazione e questa genererà un'eccezione DeliveryFailureException. Tale eccezione viene deserializzata dall'errore SOAP contenuto nel corpo del messaggio NACK. Per recuperare la stringa del messaggio di eccezione dall'errore SOAP restituito all'orchestrazione, eseguire il cast di DeliveryFailureException in un'eccezione SoapException, quindi accedere a InnerXml dalla sezione Detail. L'esempio di codice seguente illustra come eseguire questa operazione:

    // 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

    Con il codice di esempio precedente verrà restituito un frammento XML simile al seguente:

    <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>

Vedere anche

HTTP Adapter
Informazioni di riferimento sugli oggetti COM SSO nelle linee guida dell'interfaccia utente e nelle informazioni di riferimento sullo spazio dei nomi delle API per sviluppatori