BizTalk - Errore di instradamento su una notifica di consegna

Question

Ho avuto un problema molto strano con le notifiche delevery ultimamente. Ecco lo scenario:

• ho un'orchestrazione che invia un messaggio a un senso unico send-porta configurata con notifica di consegna = trasmessa (btw la porta di trasmissione utilizza l'adapter FTP, ma penso che doesn' t importa quale sia l'adattatore).

• Quando c'è un errore di messaggistica, l'errore viene intercettato dall'orchestrazione (quindi significa che il meccanismo di notifica di consegna ha funzionato come previsto), che esegue alcune registrazioni e termina programmaticamente (forma terminata). L'istanza di messaggistica esiste ancora ed è sospesa e riprende.

• Dopo aver risolto il problema che ha causato l'errore di messaggistica, riprendo l'istanza di messaggistica sospesa.

A questo punto ottengo 2 istanze di messaggistica molto sospetti: un errore routing per l'ACK e l'istanza di messaggistica ancora attivo (ma non fare nulla ...). Sono sicuro che l'istanza di errore di routing è la notifica di consegna relativa all'istanza di messaggistica attiva poiché hanno lo stesso CorrelationToken. Un ulteriore dettaglio: se termino l'istanza attiva, viene sospesa (non ripristinabile) e il messaggio di errore dice che l'istanza è stata completata senza consumare tutti i suoi messaggi!

Ultimo ma non meno importante, ho questo problema solo in certi ambienti ...

UPDATE: Sembra che il problema sembra sulle scatole BizTalk che corrono BizTalk 2006 R2 SP1. Non si è mai verificato nelle caselle che eseguono BizTalk 2006 R2 senza SP1. Cercherò di confermare questo ASAP

UPDATE 2: Sembra che avevo ragione nel mio ultimo aggiornamento: il problema appare dopo l'installazione di SP1 CU1 ... Così passo successivo: cercherò di trovare se uno dei seguendo le CU si corregge il problema.

Answer 1

In realtà nessuna CU corregge il problema descritto. Ma c'è di più: sembra che siano interessate tutte le versioni più recenti di BizTalk: ho effettuato test su BizTalk 2009 con tutte le CU e BizTalk 2010 con tutte le CU, il problema esiste ancora !!!

L'unica soluzione che ho trovato è stata creare un'orchestrazione che sottoscriva tutte le notifiche di consegna ... Non molto pulito, ma fa il lavoro - beh, almeno la maggior parte di esso.

È un dato di fatto che ho identificato 1 più problema quando si abilitare il routing per i messaggi non riusciti con notifiche di consegna: la proprietà AckRequired e il token di correlazione vengono copiati sul messaggio non indirizzato, il che significa che un ACK verrà pubblicato se questo messaggio non riuscito viene utilizzato da una porta di invio (ad esempio: porta di invio delle eccezioni ESB) e che questo ACK può essere instradato all'orchestrazione di origine se ancora in esecuzione. Se è così, quello si concluderà in una classica situazione di messaggio zombie, poiché l'orchestrazione non consuma questo ACK! Ora, prova a spiegare ai tuoi clienti che i tuoi sviluppatori non devono essere incolpati ...: p