Condividi tramite

Modelli di scambio per gli adapter di ricezione

  • Articolo

Gli adattatori di ricezione ricevono dati dal "filo" e lo inviano come messaggio in BizTalk Server. Questo processo di invio può essere un modello di scambio dei messaggi unidirezionale o bidirezionale.

Invio unidirezionale

Per poter inviare un messaggio al motore di messaggistica BizTalk, l'adapter di ricezione deve prima creare un nuovo messaggio BizTalk. Nell'esempio di codice riportato nell'argomento IBaseMessage viene illustrata la modalità di esecuzione di questa operazione. Il flusso impostato dall'adapter come corpo del messaggio deve in genere essere un flusso di tipo forward-only, ovvero non deve memorizzare nella cache i dati letti in precedenza in memoria.

Prima che l'adapter invii il messaggio nel motore, deve scrivere la proprietà contesto del messaggio InboundTransportLocation nello spazio dei nomi di sistema nel messaggio BizTalk. Questa operazione viene illustrata nel frammento di codice seguente:

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);  
}

L'adapter inoltre può definire propri schemi di proprietà e scrivere le proprietà del contesto del messaggio relative all'endpoint in cui viene ricevuto il messaggio. Un adapter HTTP può ad esempio scrivere intestazioni HTTP nel contesto del messaggio e un ricevitore SMTP può scrivere l'oggetto del messaggio nel contesto del messaggio. Queste informazioni possono essere utili per i componenti downstream, come componenti della pipeline, pianificazioni di orchestrazioni o adapter di trasmissione.

Una volta preparati i messaggi, è possibile inviarli al motore di messaggistica. Per vedere come un adattatore di ricezione unidirezionale potrebbe inviare un messaggio al motore, vedere l'esempio di codice SubmitDirect (BizTalk Server Sample).

Richiesta-risposta

Gli adapter di ricezione bidirezionali vengono in genere usati su porte di ricezione unidirezionali o bidirezionali. L'adattatore determina se la posizione di ricezione che sta eseguendo la manutenzione è una porta bidirezionale o unidirezionale controllando il BizTalk Server contenitore delle proprietà di configurazione. Questo processo viene descritto nel riferimento allo spazio dei nomi dell'API IBTTransportConfig.AddReceiveEndpoint (COM)nell'interfaccia utente guidata e nei riferimenti agli spazi dei nomi delle API per sviluppatori.

Nel diagramma di interazione degli oggetti che segue viene illustrato il processo di esecuzione di uno scambio di messaggi di richiesta-risposta. L'adapter richiede un nuovo batch dal proxy di trasporto e passa il relativo riferimento all'interfaccia IBTTransmitter tramite il metodo SubmitRequestMessage . Il motore di messaggistica recapita il messaggio di risposta in questa interfaccia usando il metodo TransmitMessage .

Poiché i messaggi vengono elaborati dal motore in modalità asincrona, è possibile che si verifichi la situazione seguente:

  • Il callback batchComplete potrebbe verificarsi prima della restituzione di Done .

  • La chiamata a TransmitMessage può essere eseguita prima di BatchComplete e persino prima di Fine.

    Sebbene entrambi questi scenari siano rari, è opportuno che l'adapter implementi misure di protezione contro situazioni di questo tipo.

    È consigliabile trasmettere il messaggio di risposta mediante una chiamata non bloccante asincrona.

    Il progetto BaseAdapter ha una classe di utilità StandardRequestResponseHandler, che incapsula la semantica della risposta richiesta illustrata in questo argomento.

Timeout dei messaggi di richiesta-risposta

Quando un adattatore invia un messaggio request-request, deve specificare il timeout del messaggio di richiesta nell'API IBTTransportBatch.SubmitRequestMessage (COM) nella guida dell'interfaccia utente e nel riferimento allo spazio dei nomi api per sviluppatori. Un messaggio di risposta verrà inviato all'adapter solo entro questo periodo di timeout. Dopo la scadenza del timeout, un riconoscimento negativo (NACK) verrà inviato all'adapter anziché al messaggio di risposta. Se l'adapter non specifica un valore di timeout, il motore utilizzerà il valore predefinito di 20 minuti.

È possibile controllare il timeout predefinito per i messaggi di richiesta-risposta utilizzando la chiave del Registro di sistema seguente per gli adapter di ricezione In-Process:

DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host Guid}\MessagingReqRespTTL

La chiave del Registro di sistema si trova in una posizione differente per gli adapter di ricezione di tipo Isolato:

DWORD

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

I NACK (riconoscimenti negativi) sono errori SOAP ed è possibile gestirli in due modi. Il riconoscimento negativo viene in genere restituito dall'adapter al client e viene gestito dal client. In alternativa, è possibile configurare la pipeline di trasmissione che gestisce il messaggio di risposta per la modifica del contenuto del messaggio di risposta utilizzando una mappa o un componente della pipeline personalizzato.