BizTalk Zombies - alcun modo per rimuovere in modo esplicito un abbonamento da dentro un'orchestrazione BizTalk

Question

Background:

Noi facciamo uso di un sacco di aggregazione, Singleton e orchestrazioni multiton, simile a Seroter's Round Robin tecnica qui descritta (BizTalk 2009) .

Tutti questi tipi di orchestrazione dispongono di punti di continuazione o di continuazione arbitrari (per le aggregazioni), generalmente definiti da un timer, ad esempio se un'Orch non ha ricevuto altri messaggi entro X minuti, quindi procedere con il batch e se dopo Y sono trascorsi altri minuti e quindi non ci sono più messaggi. (Escludiamo anche i nostri Single/N-Tons a causa di timori su degraded performance after large numbers of messages sono abbonati al singleton per un periodo).

Tanto quanto abbiamo cercato di mitigare contro gli zombi, ad es. Avviando un'elaborazione di continuazione in un'orchestrazione asincrona con refactoring, c'è sempre un punto di debolezza in cui un messaggio a tempo "buono" potrebbe causare uno zombi. (ovvero ricevere più messaggi in arrivo correlati alle forme "già completate" di un'orchestrazione),

Se un messaggio causa uno zombie su uno degli abbonamenti, il messaggio non sembra essere stato propagato a ALTRI abbonati (es. totalmente disaccoppiato dall'orchestrazione 'zombie che causa'), cioè il messaggio che causa zombi non viene elaborato.

Domanda

Quindi sarei molto interessato a vedere se qualcuno ha un altro modo, a livello di codice o in altro modo, per rimuovere in modo esplicito un abbonamento correlato da un'orchestrazione in esecuzione una volta che l'orchestrazione è 'progredito' oltre il punto in cui è interessato a questo messaggio correlato. (Questo nuovo messaggio sarebbe quindi tipicamente iniziare una nuova orchestrazione con le sue correlazioni, ecc)

A questo punto vorremmo prendere in considerazione anche una soluzione mod quale una chiamata API riflessa BizTalk o SQL diretta eliminare contro il MsgBoxDB.

Answer 1

No, non è possibile rimuovere esplicitamente l'abbonamento in un'orchestrazione.

La sottoscrizione verrà rimossa man mano che l'orchestrazione si abbatterà, ma un messaggio che arriva a quell'istanza esatta verrà instradato all'Orchestrazione ma l'orchestrazione terminerà senza elaborarlo e questo è il tuo Zombi.

Microsoft Articolo su Zombies http://msdn.microsoft.com/en-us/library/bb203853.aspx

una volta ho anche dovuto avere un ricevere, debatch, aggregare, trasmettere modello. Ricezione di messaggi con involucro da più mittenti, rimuovendoli, aggregandoli per destinatario (in base a due regole, numero di messaggi o ritardo temporale, a seconda di quale evento si è verificato prima). Questo scenario era maturo per gli zombi e quando ho letto su di loro ho progettato in modo che non si verifichino. Questo era per BizTalk 2004 Ho rimosso i messaggi e li ho inseriti in un database. Avevo una procedura memorizzata che veniva interrogata da una porta di ricezione che avrebbe funzionato se ci fosse un batch da inviare se ci fosse il trigger di una orchestrazione che avrebbe preso quel messaggio e lo avrebbe indirizzato in modo dinamico. Dal momento che nessuna Orchestrazione ha dovuto attendere un altro messaggio, potrebbe finire con grazia e non ci sarebbero stati Zombi.