Come gestire gli errori dell'adapter

È in genere opportuno che gli adapter sospendano i messaggi che non sono in grado di elaborare. Ad esempio, nella maggior parte dei casi, un adapter di ricezione in cui si verifica un errore di invio deve sospendere i messaggi, anche se questa decisione dipende dallo scopo dell'adapter. Per la gestione degli errori esistono inoltre considerazioni sulla sicurezza. Ad esempio, se un adapter sospende automaticamente tutti i messaggi per cui si è verificato un errore, è possibile che si crei una vulnerabilità agli attacchi di tipo Denial of Service che causano il riempimento della coda degli elementi sospesi di BizTalk Server. Alcuni adapter, quali l'adapter HTTP, possono restituire al client un codice di errore in cui si indica che la richiesta è stata rifiutata. Per questi tipi di adapter spesso risulta più utile restituire un codice di errore anziché sospendere il messaggio. In genere gli adapter di trasmissione sospendono i messaggi soltanto dopo aver esaurito tutti i tentativi sia per il trasporto primario sia per quello secondario.

Associazione dell'elaborazione degli errori a una singola operazione anziché al batch contenente l'operazione

Il batch dei messaggi di un adapter deve essere invisibile agli utenti. Ciò significa che se si verifica un errore in un'operazione del batch le altre operazioni non devono subire alcun effetto. Tuttavia, i batch sono atomici, quindi il verificarsi di un errore in un messaggio equivale al verificarsi di un errore nel batch e pertanto non viene elaborata alcuna operazione.

In questo caso occorre scrivere il codice che si occupa della gestione dell'errore, inviando nuovamente i messaggi privi di errore e sospendendo quelli in cui si è verificato un errore. Tuttavia, grazie a una dettagliata struttura degli errori, BizTalk Server consente all'adapter di determinare in quale operazione specifica si è verificato l'errore. In BizTalk Server è inoltre possibile creare ulteriori batch in cui le operazioni prive di errori vengono inviate nuovamente mentre quelle in cui si è verificato un errore vengono sospese.

Lo stato finale di ogni operazione non deve dipendere da quello delle altre operazioni nel batch dell'adapter.

Utilizzo di SetErrorInfo per segnalare un errore a BizTalk Server

Quando si sospende un messaggio è necessario fornire a BizTalk Server delle informazioni sull'errore relative al contesto del messaggio precedente. BizTalk Server fornisce funzionalità di segnalazione degli errori usando il metodo SetErrorInfo nelle interfacce IBaseMessage e ITransportProxy. È possibile segnalare gli errori nel seguente modo:

• Quando si verifica un errore durante l'elaborazione di un messaggio, impostare l'eccezione usando SetErrorInfo(Exception e) nel messaggio (IBaseMessage) da sospendere. In questo modo si consente al motore di conservare l'errore e il relativo messaggio per effettuarne una diagnosi in seguito e di scrivere tali dati nel registro eventi per avvisare l'amministratore.

• Se si verifica un errore durante l'inizializzazione o la contabilità interna (non durante l'elaborazione dei messaggi), è necessario chiamare SetErrorInfo(Exception e) sul puntatore ITransportProxy passato all'utente durante l'inizializzazione. Se l'adapter in uso si basa sull'implementazione BaseAdapter, questo puntatore risulta sempre accessibile. Altrimenti, assicurarsi di memorizzarlo nella cache.

  Entrambi i metodi di segnalazione degli errori consentono di scrivere il messaggio di errore nel registro eventi. Se possibile, è importante associare l'errore al relativo messaggio.

Gestione della condizione di database disconnesso

In caso di disconnessione di uno dei database di BizTalk Server, il servizio BizTalk si ricicla da solo. Prima di riciclare il servizio, il motore di messaggistica cerca di arrestare in ogni modo possibile tutti gli indirizzi di ricezione. Se l'operazione richiede più di 60 secondi, il servizio viene terminato. Poiché il motore supporta le transazioni, non si verificano perdite dei dati.

Questo timeout può essere regolato nel Registro di sistema tramite la chiave:

DWORD   
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host Guid}\MessagingDBFailoverShutdownTimeLimit  

Nel caso di adapter isolati, poiché il processo non appartiene a BizTalk Server, quando uno dei database BizTalk Server viene disconnesso gli indirizzi di ricezione vengono disattivati. Una volta ripristinata la connessione del database, tali indirizzi di ricezione vengono riattivati.

Scrittura nel registro eventi

L'adattatore può scrivere voci del registro eventi usando l'interfaccia IBTTransportProxy passando un'eccezione. Gli adattatori sviluppati nel codice nativo devono passare un'interfaccia IErrorInfo , IBTTransportProxy.SetErrorInfo( Exceptione).

Il motore di messaggistica scrive nel registro eventi per conto dell'adapter quando, ad esempio, un adapter tenta di inviare nuovamente un messaggio dopo un tentativo fallito, sposta un messaggio nel relativo trasporto di backup oppure sospende un messaggio. Per le operazioni di questo tipo l'adapter deve solo impostare l'eccezione sul messaggio prima di chiamare l'interfaccia API. Nel frammento di codice che segue viene illustrata questa alternativa:

IBaseMessage msg;  
...  
// Set exception on msg to indicate why transmission failed...  
msg.SetErrorInfo(  
 new ApplicationException(  
 "The TCP connection was closed by the destination"));  

Gestione degli errori di batch specifici della ricezione

Gestione degli errori di ricezione

Quando un adapter invia a BizTalk Server un'operazione (o un batch di operazioni), il verificarsi di un errore può essere causato da più motivi. I due più importanti sono:

• Si è verificato un errore nella pipeline di ricezione.

• Si è verificato un errore di routing durante la pubblicazione di un messaggio.

  Quando rileva un errore nella pipeline di ricezione, il motore di messaggistica tenta automaticamente di sospendere il messaggio. L'operazione di sospensione non sempre ha esito positivo. Ad esempio, se nel motore di messaggistica si verifica un errore di routing durante la pubblicazione di un messaggio, il motore non tenta nemmeno di sospenderlo.

  È sempre possibile che si verifichino errori in un messaggio. In una situazione di questo tipo, l'adapter deve chiamare in modo esplicito l'API MoveToSuspendQ e deve provare a sospendere il messaggio. Quando un adapter tenta di sospendere un messaggio, è opportuno che sussista una delle seguenti situazioni:

• Lo stesso oggetto messaggio inviato dall'adapter viene sospeso (opzione consigliata).

• Se l'adapter deve creare un nuovo messaggio, è opportuno che ne imposti il contesto includendo il puntatore al contesto del messaggio che è stato inviato inizialmente. Ciò è dovuto al fatto che nel contesto di un messaggio sono contenuti numerosi dati preziosi sul messaggio e sull'errore. Questi dati sono necessari per eseguire il debug del messaggio in cui si è verificato l'errore.

Nota

Se l'adapter crea un nuovo oggetto messaggio e lo sospende, l'adapter deve copiarvi le informazioni sull'errore contenute nell'oggetto messaggio precedente.

Alcuni adapter, quali l'adapter HTTP fornito in BizTalk Server, non richiedono la sospensione del messaggio. Gli adapter di questo tipo sono infatti in grado di restituire un errore al client.

Cause degli errori

Le cause semplici di errore sono gli errori che possono verificarsi quando il batch viene costruito o quando viene chiamato IBTTransportBatch::D one .

• Invio non riuscito. La chiamata Submit può non riuscire per un numero limitato di motivi e tutti sono irreversibili. Di seguito sono elencati alcuni motivi per cui questa scelta è consigliabile:

• Errori di memoria insufficiente che si verificano nello spazio di elaborazione di BizTalk Server.

• L'assembly dello schema è stato eliminato dalla distribuzione. In questo caso, l'oggetto Submit ha esito negativo con un errore criptico. Nell'adapter MQSeries, BizTalk Server rileva l'eccezione di errore generico e un messaggio di errore esteso viene scritto nel registro eventi di sistema. Nel messaggio si indica che una delle possibili cause dell'errore è che in qualche modo l'assembly dello schema è stato eliminato dalla distribuzione.

  In generale, se Submit non riesce, provare a sospendere il messaggio usando la stessa transazione.

• IBTTransportBatch::Done failure La chiamata IBTTransportBatch::D one può avere esito negativo per uno dei diversi motivi. In generale, è opportuno tentare sempre di eseguire un'unica operazione di sospensione e quindi terminare la transazione solo se questa non riesce. Uno dei codici di errore che è possibile ricevere dall'errore di IBTTransportBatch::D one è che BizTalk Server sta tentando di arrestare. In questo caso, è consigliabile terminare la transazione e lasciarla perché è probabile che la chiamata Terminate venga eseguita contemporaneamente. Altri scenari si verificano quando il batch è stato costruito correttamente ed è stato eseguito correttamente IBTTransportBatch::D one. In questi casi, gli errori vengono restituiti in BatchComplete e l'adapter deve determinare cosa fare con essi. Il resto della presente sezione è dedicato a questo caso.

Elaborazione degli errori BatchComplete

BatchComplete è un callback fornito dall'adapter richiamato da BizTalk Server per indicare lo stato di completamento di un'operazione batch.

Il parametro più importante passato a BatchComplete è lo stato hResultdel batch . Tale parametro indica se l'esito del batch è positivo o negativo. Se è negativo, ciò indica che non è riuscita alcuna delle operazioni del batch. L'adattatore passa attraverso la struttura dello stato del batch e determina quali messaggi non sono riusciti (questo è noto come filtro del batch).

Errori nel corso di operazioni BatchComplete non transazionali

Per gli adattatori non transazionali, è necessario scegliere la risposta se si verifica un errore per un'operazione SubmitMessage/SubmitRequestMessage o SubmitResponseMessage . Gli adapter sospendono in genere il messaggio chiamando MoveToSuspendQ.

È sempre previsto che vengano passate le operazioni seguenti: DeleteMessage, MoveToSuspendQ, ResubmitMessage. L'esito negativo di tali operazioni è in genere dovuto alla presenza di un errore nell'adapter. Pertanto, non è necessario scrivere un codice che gestisca gli errori che si verificano durante queste operazioni. Se tuttavia nel batch si presenta un problema dovuto a un errore in un'altra operazione, queste operazioni devono essere rieseguite in un nuovo batch.

Se l'adattatore chiama MovetoBackupTransport e ha esito negativo (perché non è presente alcun trasporto di backup), l'adattatore deve chiamare MoveToSuspendQ per sospendere il messaggio.

Errori nel corso di operazioni BatchComplete transazionali

Quando si inviano batch a BizTalk Server utilizzando una transazione creata dall'adapter, è opportuno attenersi a uno dei due scenari seguenti:

• Utilizzo di batch con un solo messaggio . Inviare un batch con un solo messaggio a BizTalk Server. Se questo messaggio ha esito negativo, è possibile inviare a BizTalk Server un secondo batch nel contesto della stessa transazione, spostando tuttavia nella coda degli elementi sospesi il messaggio in cui si è verificato l'errore anziché inviarlo nuovamente. Una volta rimosso tale messaggio, l'invio del secondo batch avrà esito positivo. A questo punto, quando BizTalk Server avrà confermato l'esito positivo del secondo batch, sarà possibile eseguire il commit della transazione. Se anche il secondo batch avrà esito negativo, l'adapter deve interrompere la transazione o trovare un'altra destinazione in cui posizionare il messaggio. In questo scenario si verifica un immediato e notevole calo delle prestazioni dovuto all'elaborazione del rollback della transazione.

  Per migliorare le prestazioni dell'adapter è possibile ricorrere ad alcune tecniche. Ad esempio, l'adapter MQSeries regola il proprio approccio dinamicamente in fase di esecuzione. Di base vengono utilizzati batch con 100 messaggi. Se tuttavia si verifica un errore, l'adapter termina il batch e passa a utilizzare batch con un solo messaggio per un breve periodo di tempo mentre procede oltre il messaggio errato. Risolto il problema, torna a utilizzare i batch con 100 messaggi. Se si verifica un altro errore, il ritmo di elaborazione viene nuovamente ridotto.

• Utilizzo della sospensione in modalità preemptive . Creare un batch con più messaggi in cui i messaggi errati vengono sospesi in modalità preemptive. Il batch contiene una combinazione di operazioni Submit e MoveToSuspendQ ed è il primo e solo batch nella transazione. Tale batch avrà esito positivo in quanto i dati errati sono stati sospesi in modalità preemptive e, dopo aver atteso la ricezione della conferma da parte di BizTalk Server, è possibile eseguire il commit della transazione.

  Benché sembri richiedere capacità di preveggenza, questa tecnica è stata utilizzata nell'adapter MSMQ. Il suo funzionamento si basa sul poter disporre di ID di messaggio la cui univocità sia garantita. L'adapter crea un batch di messaggi. In caso di errore viene eseguito il rollback della transazione (e quindi del batch) e gli ID dei messaggi vengono memorizzati in una struttura di dati temporanea. Per impedire la crescita indefinita di questa struttura, gli elementi in esso contenuti vengono rimossi dopo un ritardo di tempo fisso. Prima di inviare ogni batch, l'adapter controlla l'elenco di ID messaggio non valido. Se ne viene rilevato uno, l'adapter può prevedere che esso avrà esito negativo (in quanto ciò è già accaduto in precedenza) e quindi lo sospende in modalità preemptive anziché tentare di inviarlo.

  Non tutti gli adapter dispongono di ID di messaggio a univocità garantita, e per un archivio transazionale ciò è ancora meno probabile. Di conseguenza, la maggior parte degli adapter transazionali è costretta a inviare batch con un solo messaggio.

Elaborazione degli errori di altro tipo

In tutti gli altri casi (ad esempio nei casi di errore durante la sospensione dei messaggi) l'adapter deve terminare la transazione. Non attenersi a questa indicazione comporta la duplicazione o la perdita dei messaggi.

Se in un batch si verifica un errore, l'adapter deve interrompere la transazione ogni volta che sia possibile. Tuttavia, esistono situazioni in cui l'adapter non è in grado di interrompere la transazione. In questi casi l'adapter deve sospendere i messaggi utilizzando la stessa transazione.

Elaborazione degli errori in caso di ricezione transazionale

Una comune prassi di elaborazione transazionale è terminare una transazione quando si verifica un errore. In questo caso si ripristina completamente lo stato precedente e non si verificano perdite di dati. Tuttavia, se si utilizzano dati provenienti da un'origine dati transazionale (ad esempio, se si recupera una riga per volta dalla tabella di staging di un database oppure se si recupera un solo messaggio alla volta da un prodotto di accodamento quale MQSeries o MSMQ), questa prassi potrebbe risultare inadeguata. Se si termina la transazione e si riprendono gli stessi dati è probabile che si verifichi lo stesso errore, portando in questo modo il sistema a bloccarsi in un ciclo infinito.

In una versione precedente di BizTalk Server l'adapter SQL presentava questo tipo di funzionamento. Tuttavia, poco dopo il rilascio di tale versione, questo funzionamento è stato modificato in modo che l'adapter tentasse di sospendere i messaggi errati ed eseguire il commit della transazione. Lo spostamento di un messaggio nella coda degli elementi sospesi nel contesto della stessa transazione e la successiva esecuzione del commit di quest'ultima impedisce la perdita dei dati e consente inoltre all'adapter di procedere oltre i dati errati.

Quando la parte di ricezione di un adattatore viene passata un messaggio di errore in risposta a un'operazione Invia messaggio, l'adapter deve elaborare tale errore e spostare il messaggio nella coda sospesa.

In questo caso di batch transazionali in cui l'adapter ha creato l'oggetto transazione e invia i messaggi nel relativo contesto, quando si verificano errori l'adapter deve spostare logicamente il messaggio nella coda degli elementi sospesi nel contesto della stessa transazione. La transazione garantisce che i dati non vengano persi ed è opportuno evitare sempre di scartare perfino i dati che causano un errore.

Gestione dei messaggi senza sottoscrizioni

BizTalk Server non consente nel proprio database MessageBox la pubblicazione dei messaggi per cui non è stata definita alcuna sottoscrizione per accettarli. Le sottoscrizioni vengono registrate dalle orchestrazioni o dalle porte di trasmissione. È possibile definire più sottoscrizioni. In questo caso il messaggio viene inviato a più destinazioni. Se non esiste alcuna sottoscrizione, BizTalk Server rifiuta il messaggio e non tenta di sospenderlo. Se l'adapter non gestisce questo errore e sospende esplicitamente il messaggio, questo viene scartato e i dati in esso contenuti possono andare persi. Naturalmente, un adapter transazionale può terminare la transazione e restituire il messaggio alla destinazione prevista.

Supporto per il metodo Seek nel flusso di ricezione

Il flusso lato ricezione deve supportare il metodo Seek per BizTalk Server per poter sospendere il messaggio in un errore della pipeline. Se il flusso di messaggi non è ricercabile, BizTalk Server genera un errore quando tenta di eseguire Seek.

In molti casi il supporto di Seek non è facile. Quando il flusso di dati proviene da una rete, ad esempio, può risultare difficile risalire alla risorsa di rete e richiedere nuovamente i dati.

Alcuni adapter forniti con BizTalk Server eseguono lo spooling dei dati del messaggio su un file memorizzato su disco mentre BizTalk Server esegue la lettura dei dati. In questo modo, l'adapter può usare Seek su tale file se si verifica un errore (nell'elaborazione della pipeline dei dati del messaggio, ad esempio). Internamente la scheda usa la classe ReadOnlySeekableStream che esegue il wrapping di un flusso non ricercabile in ingresso e overflow su disco quando viene raggiunta una soglia di dimensioni configurabili. Per i messaggi aventi dimensioni inferiori a tale soglia il disco non viene mai utilizzato.

Opzioni di gestione degli errori configurabili dall'utente

Talvolta non esiste un'unica risposta corretta a un errore. In questo caso è opportuno considerare la possibilità di utilizzare un'opzione configurabile dall'utente in modo da poter scegliere fra più modalità di funzionamento. Questa funzionalità è disponibile in MQSeries.

Il problema con la sospensione dell'adattatore quando viene visualizzato un errore è che la coda sospesa in BizTalk Server è qualcosa di un "buco nero". È relativamente facile ottenere messaggi nella coda, ma più difficile recuperarli di nuovo.

È possibile che alcuni utenti dell'adapter desiderino che la coda degli elementi sospesi resti vuota. Ad esempio, nel caso dell'adapter MQSeries, l'utente può scegliere fra le modalità di funzionamento seguenti:

• L'adapter termina la transazione corrente e si disattiva quando rileva un errore.

• Il messaggio in cui si è verificato l'errore viene sospeso e viene eseguito il commit della transazione. L'adapter esegue questa procedura anche se BizTalk Server riesce a sospendere correttamente il messaggio. Questa azione soddisfa le esigenze del cliente anche se il contenuto del registro eventi non risulterà rigorosamente corretto.

Implementazione dell'ordinamento della ricezione dei messaggi utilizzando un unico thread e attendendo il completamento dell'elaborazione dei batch

L'interfaccia di BizTalk Server è progettata per ottimizzare le prestazioni e per offrire scalabilità orizzontale grazie al supporto della concorrenza. Tuttavia, se si desidera una ricezione rigorosamente ordinata dei messaggi (esigenza che talvolta si presenta quando si ricevono messaggi da un prodotto di accodamento dei messaggi quale MQSeries o MSMQ), occorre eseguire delle operazioni aggiuntive nell'adapter al fine di disattivare parzialmente la concorrenza. Questa operazione può essere eseguita in due passaggi:

1. Utilizzare nell'adapter un unico thread per tutte le attività di elaborazione dei dati.

2. Attendere che BizTalk Server completi l'elaborazione di ogni batch. Questo requisito è importante e può essere soddisfatto utilizzando le primitive di sincronizzazione dei thread di .NET. Ad esempio, usando un oggetto AutoResetEvent, è possibile:

   • Dichiarare l'oggetto evento a cui è possibile accedere sia dal thread di lavoro principale che dall'oggetto callback BatchComplete .

   • Nel thread di lavoro principale inviare i messaggi al batch come di consueto, ma quindi chiamare AutoResetEvent.Reset nell'oggetto evento appena prima della chiamata al batch IBTTransportBatch::D one.

   • Chiamare AutoResetEvent.WaitOne nell'oggetto evento da questo stesso thread. Ciò comporta il blocco del thread principale di lavoro. Nel callback batchComplete da BizTalk Server si chiama AutoResetEvent.Set nello stesso oggetto evento per sbloccare il thread di lavoro in modo che sia pronto per elaborare un altro messaggio.

   Si consiglia vivamente di ricevere l'ordinamento come questa configurabile perché causa una riduzione significativa delle prestazioni. Molti, se non la maggior parte, degli scenari utente non richiedono l'ordinamento dei messaggi. Inoltre, la sospensione dei messaggi può interferire con l'ordinamento. Le azioni da intraprendere in questo caso variano a seconda dell'applicazione. Di conseguenza la soluzione migliore è fare in modo che l'adapter offra agli utenti un punto di configurazione.

   Negli scenari ordinati alcuni clienti hanno affermato di preferire l'interruzione dell'elaborazione, ovvero la disattivazione dell'adapter, al non poter disporre di una ricezione ordinata. L'adapter MQSeries, che supporta la ricezione ordinata, offre questa opzione agli utenti.

Gestione degli errori di batch specifici dell'invio

Gestione dei tentativi di ripetizione dell'invio e del batch

Di seguito è riportato un tipico esempio di batch lato trasmissione:

• BizTalk Server invia un batch di messaggi all'adapter.

• Quando rileva di aver inviato correttamente il messaggio a destinazione, l'adapter esegue un'operazione di eliminazione su BizTalk Server per segnalare il completamento delle proprie attività. Come consueto, per migliorare le prestazioni è possibile inserire nello stesso batch più messaggi di eliminazione.

  Se l'adapter sul lato trasmissione non riesce ad elaborare un messaggio, questo può essere gestito in più modi:

• L'adapter può richiedere a BizTalk Server di effettuare un nuovo tentativo per il messaggio. BizTalk Server non effettua automaticamente il nuovo tentativo e tiene traccia del numero di tentativi. Tale numero è visibile nel contesto del messaggio.

• L'adapter può stabilire di non essere in grado di elaborare il messaggio. In questo caso, è possibile che l'adapter sposti il messaggio sul trasporto successivo. L'adapter esegue questa operazione con la chiamata MoveToNextTransport nell'oggetto Batch .

• L'adapter può spostare il messaggio nella coda degli elementi sospesi.

  L'adapter stabilisce il modo in cui gestire il messaggio. È tuttavia consigliabile fare in modo che gli adapter funzionino in modo coerente, poiché in questo modo un'installazione di BizTalk Server risulta più facile da supportare.

  È inoltre consigliabile fare in modo che il funzionamento degli adapter corrisponda a quello descritto di seguito, così come accade per gli adapter forniti con BizTalk Server.

Funzionamento consigliato per la gestione degli errori di invio in un batch

L'adapter di trasmissione riceve alcuni messaggi e li invia a BizTalk Server.

Per ogni messaggio riuscito, l'adapter deve eliminare il messaggio su BizTalk Server. Le comunicazioni verso BizTalk Server vengono eseguite in batch e le operazioni di eliminazione possono essere incluse in batch. Non occorre che tali batch corrispondano al batch creato da BizTalk Server sull'adapter. Se presenti, i messaggi di risposta (come nel caso di un SolicitResponse) devono essere inviati a BizTalk Server (tramite SubmitResponse) insieme alle operazioni di eliminazione associate.

• Se l'elaborazione dei messaggi dell'adapter ha avuto esito negativo, verificare il numero di tentativi eseguiti.

  • Se il limite di tentativi non è stato superato, inviare nuovamente il messaggio a BizTalk Server, ricordando di impostare nel messaggio il numero di tentativi già effettuati. Il numero di tentativi e l'intervallo di tempo fra i tentativi da utilizzare sono indicati nel contesto del messaggio.

  • Se il conteggio dei tentativi è stato superato, l'adapter deve tentare di spostare il messaggio usando MoveToNextTransport. I messaggi reubmit e MoveToNextTransport possono essere combinati con le eliminazioni nello stesso batch in BizTalk Server. Benché non sia necessario, questo passaggio è consigliato.

• Il resubmit e moveToNextTransport sono modi per gestire gli errori dell'adapter. Tuttavia, è possibile che durante l'elaborazione degli errori si verifichi un errore. In questo caso, nell'elaborazione della risposta da BizTalk Server (nel metodo BatchComplete) l'adapter deve creare un altro batch contro BizTalk Server per indicare cosa fare con tale errore.

  Se durante l'elaborazione di un errore si verifica un altro errore, attenersi alla procedura riportata di seguito:

  • Se la resubmit ha esito negativo, usare MoveToNextTransport.

  • Se MoveToNextTransport ha esito negativo, usare MoveToSuspendQ.

  Occorre continuare a creare batch su BizTalk Server finché non si riceve la segnalazione di un'azione riuscita su BizTalk Server.

Serializzazione della proprietà di contesto dei messaggi

Tutti gli oggetti assegnati alla proprietà di contesto di un messaggio devono essere serializzabili. In caso contrario, il motore di messaggistica genererà un'eccezione di tipo E_NOINTERFACE. Questo valore restituito rappresenta in modo ambiguo un oggetto non serializzabile che tenta di essere assegnato al contesto del messaggio.