Batch di messaggi per l'elaborazione della trasmissione

Gestione dei batch dell'adapter di trasmissione

Quando si utilizzano transazioni sul lato trasmissione, la stessa transazione creata da BizTalk Server e utilizzata per la trasmissione al sistema di destinazione viene utilizzata per l'eliminazione del messaggio corrispondente dopo che questo è stato inviato correttamente. In caso di errore, la transazione può essere terminata, nel qual caso l'eliminazione viene interrotta e i dati restano in BizTalk Server senza essere inviati al sistema di destinazione. Si evita in questo modo la duplicazione dei messaggi. Le transazioni sono supportate solo per gli adapter di trasmissione di tipo asincrono. Non è consigliabile utilizzare le transazioni con adapter di trasmissione di tipo sincrono.

L'adapter non solo può interrompere la transazione, ma deve anche gestire correttamente lo stato dei messaggi inviatigli. In particolare, l'adattatore deve chiamare i metodi Resubmit, MoveToNextTransport e MoveToSuspendQ in modo appropriato a seconda del numero di tentativi e se è disponibile un trasporto di backup.

È importante inserire le operazioni Delete e SubmitResponse in un batch che usa la stessa transazione. L'errore viene gestito mediante terminazione della transazione, al fine di garantire l'invio dei dati a un sistema esterno una sola volta. Ma si vuole comunque inviare di nuovo o chiamare MoveToNextTransport per il messaggio di nuovo in BizTalk Server. utilizzare un batch normale (non transazionale) separato per questi tipi di operazioni.

Nella figura seguente viene illustrato l'utilizzo di batch separati per i messaggi di risposta.

Ordinamento dei batch transazionali lato trasmissione in base all'endpoint

I batch di messaggi inviati da BizTalk Server all'adapter possono comprendere più porte di trasmissione (o endpoint). Poiché l'adattatore vuole in genere avere una transazione a un singolo endpoint, l'adapter deve ordinare i messaggi in base alla porta di trasmissione (SPName o OutboundTransportLocation). In questo modo, l'adapter potrà creare una transazione che includa solo una determinata porta di trasmisione.

Ad esempio, quando un adapter di trasmissione FTP riceve un batch di messaggi da BizTalk Server, riceve un batch eterogeneo di messaggi per tutte le porte di trasmissione FTP attualmente attive. Questo avviene perché l'API è basata su singleton, il che significa che viene caricato un unico adapter FTP e non uno per porta di trasmissione.

L'adapter dovrà prima ordinare il batch di messaggi inviatogli da BizTalk Server in batch separati, uno per ogni endpoint, quindi potrà gestire ogni endpoint in successione e costruire eventualmente batch di eliminazione per ogni endpoint. Le classi riutilizzabili generiche BaseAdapter del codice di esempio SDK presentano lo stesso funzionamento.

Ordinamento per la trasmissione dinamica

Un'orchestrazione BizTalk Server può inviare un messaggio a una porta non configurata purché vengano forniti dettagli di configurazione sufficienti nell'intestazione del messaggio e nell'URL stesso. È necessario che BizTalk Server riconosca il protocollo dell'URL.

Nell'ordinamento dei messaggi, occorre prestare attenzione nello stabilire l'elemento che definisce un endpoint. Questo vale soprattutto nel caso di una trasmissione dinamica. Se l'endpoint è definito solo dall'URI, l'operazione è semplice. Tuttavia, in una sessione FTP è possibile che i dettagli di accesso relativi al nome utente siano utilizzati dal server FTP per definire l'endpoint effettivo. In questo caso, se l'adapter utilizza per l'accesso un account diverso, è possibile che la connessione venga eseguita a una directory diversa.

In alcuni casi, l'endpoint true non è noto fino a quando non si esegue il comando Enterprise Single Sign-On (SSO) ValidateAndRedeemTicket.

Nel caso di MQSeries, è possibile configurare se utilizzare le transazioni o meno. Data l'architettura e l'utilizzo di un oggetto COM+ remoto, è consigliabile considerare un endpoint transazionale distinto da un endpoint non transazionale.

In breve, l'ordinamento dei messaggi in relativi batch per singoli endpoint è talvolta un'operazione non semplice e può comportare passaggi aggiuntivi in considerazione dei valori di contesto e persino del risultato di una chiamata a SSO.

Ordinamento per la trasmissione statica

In caso di un endpoint configurato staticamente, nel contesto del messaggio è disponibile un GUID univoco, definito ID della porta statica (SPID, Static Port ID), che può essere utilizzato per ordinare l'endpoint. Per recuperarlo è possibile utilizzare il codice seguente:

string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");  

Questo valore risulta utile quando si prendono in considerazione i problemi introdotti dal framework di configurazione basato su una definizione XSD (XML Schema Definition). In questo framework è presente una proprietà che potrebbe essere parte della chiave dell'endpoint nascosta all'interno dell'XML in una singola proprietà di contesto. Se si dispone di uno SPID nel contesto, è possibile utilizzarne il valore per ordinare il batch. In caso contrario, si effettuerà una trasmissione dinamica e sarà necessario costruire una chiave alternativa con cui ordinare il batch.

Nella figura seguente viene illustrato l'ordinamento dei messaggi in base all'endpoint.

Ricordare che per il numero di tentativi di un messaggio non viene considerato l'esito positivo o negativo di un batch. Sul lato trasmissione, l'esito di un batch di messaggi potrebbe risultare negativo a causa di alcuni messaggi con errori. L'adapter deve eseguire una determinazione per ogni messaggio che riceve. In uno scenario di batch con esito negativo, si potrebbe supporre che ogni messaggio sia inviato di nuovo. Tuttavia, se tutti i messaggi di tale batch vengono inviati di nuovo, il numero di tentativi (gestito dal motore di BizTalk Server) aumenta erroneamente anche per i messaggi privi di errore poiché si trovano nello stesso batch di quelli con errore. In questo caso, un adapter potrebbe riformare il batch in uscita e ritentare il messaggio privo di errore verso il sistema esterno.