Utilizzo di serie di istruzioni
Una chiamata esiste in qualsiasi momento in cui più singoli messaggi devono essere correlati per ottenere il risultato richiesto. Esistono due tipi principali di convogli: sequenziali e paralleli.
In alcune circostanze, un'istanza di orchestrazione può ricevere un gruppo di messaggi correlati contemporaneamente. In tale situazione, è possibile che si verifichi una race condition, in cui uno dei messaggi del gruppo deve inizializzare un set di correlazioni nell'istanza di orchestrazione prima che altri messaggi possano essere correlati a tale istanza di orchestrazione.
Per assicurare che tutti i messaggi correlati vengano ricevuti dalla stessa istanza di orchestrazione, BizTalk Server rileva il potenziale per una tale race condition e tratta questi messaggi come serie di istruzioni. Al momento dell'integrazione, il runtime crea una sottoscrizione generale e la identifica come parte della serie di istruzioni. Dopo aver completato tale sottoscrizione, il motore di messaggistica crea una sottoscrizione temporanea in base ai valori delle proprietà di correlazione predefinite. Questa sottoscrizione temporanea viene chiamata un set di convogli. Un set della serie è un gruppo di set di correlazioni utilizzato in una serie di istruzioni. Tutti i messaggi successivi che corrispondono alla sottoscrizione generale vengono valutati a fronte del set della serie e indirizzati a una porta esistente.
Utilizzo di serie di istruzioni con processi di business
Di seguito sono riportate considerazioni utili per l'elaborazione di serie di istruzioni con un processo di business:
Un set di correlazione è un elenco di proprietà con valori specifici usati per instradare i messaggi a un processo aziendale specifico. Il set di correlazione usato in una forma di ricezione non può contenere più di tre proprietà usate per la correlazione. Ciò perché tali valori sono identificati e memorizzati a livello di database, che supporta un massimo di tre parametri.
Le serie di istruzioni sequenziali e parallele possono coesistere nello stesso processo di business, ma non possono condividere alcun set di correlazioni tra loro. Ciò perché ogni set di correlazioni può appartenere a una unica serie di istruzioni.
BizTalk Server non supporta l'elaborazione della chiamata quando si usa la forma Start Orchestration per passare un set di correlazione già inizializzato in una nuova orchestrazione. Ciò perché i set della serie vengono gestiti a livello di database, independenti dalle istanze di orchestrazione già in esecuzione.
Non è possibile usare una singola forma di ricezione per inizializzare due o più set di correlazione che verranno usati in convogli separati. Ad esempio, si supponga che il ricevitore r1 inizializzi i set di correlazioni c1 e c2 per la prima serie di istruzioni, il ricevitore r2 segua c1 per la seconda serie di istruzioni e il ricevitore r3 segua c2 per la terza serie di istruzioni. I set della serie previsti per la seconda serie di istruzioni sono c1, r2 e i set della serie previsti per la terza serie di istruzioni sono c2, r3, tutti inizializzati da r1. In questo caso, il motore di orchestrazione non tratterà tali set come serie di istruzioni. L'esempio costituisce uno scenario di serie di istruzioni valido se sia r2 che r3 seguono entrambi c1 e c2 (c1, r2, r3 e c2, r2, r3), entrambi seguono solo c1 (c1, r2, r3) o entrambi seguono solo c2 (c2, r2, r3).
Zombie
L'utilizzo di serie di istruzioni può dare origine a messaggi "persi" denominati zombie. Quando una sottoscrizione di ricezione di non attivazione in un'orchestrazione in esecuzione corrisponde a un messaggio nel database MessageBox, quest'ultimo recapita il messaggio all'orchestrazione. Dal momento che MessageBox non conosce la regola business all'interno dell'orchestrazione, recapita semplicemente all'orchestrazione tutti i messaggi che corrispondono alla sottoscrizione. Se uno di qualsiasi di questi messaggi viene recapitato quando il flusso di esecuzione dell'orchestrazione ha passato i messaggi che possono essere utilizzati dalle sottoscrizioni di ricezione, tali messaggi diventano zombie.
Un esempio di una tale situazione che crea zombi è la ricezione all'interno di un ciclo che esegue un'iterazione 17 volte, ma vengono recapitati 18 messaggi che corrispondono alla sottoscrizione di ricezione del ciclo. MessageBox non sa che la logica di orchestrazione gestisce solo 17 messaggi. Il 18° messaggio recapitato non viene utilizzato dall'orchestrazione perché il flusso di esecuzione ha già chiuso il ciclo. L'orchestrazione viene completata con messaggi ignorati (zombie) che non possono essere recuperati in quanto l'istanza di orchestrazione è già stata completata.
È possibile gestire i messaggi ignorati utilizzando lo script Strumentazione gestione Windows (WMI) per eseguire una query sulle istanze con stato "Sospeso (non può essere ripristinato". Il motore di messaggistica scrive un messaggio di errore, "Completato con messaggi ignorati", nel registro eventi.
Inoltre, se si dispone di una serie di istruzioni sequenziali con un ambito transazionale a esecuzione prolungata e l'ambito ha un'impostazione di timeout, alcune istanze di orchestrazione possono terminare con lo stato "Sospeso (non può essere ripristinato". È anche possibile notare che il numero di messaggi di output più il numero di istanze "Sospeso (non può essere ripristinato" è inferiore al numero dei messaggi di input messages. Questo comportamento dipende dalla progettazione. Quando si verifica un'eccezione di timeout, il codice viene inserito nel gestore eccezioni. BizTalk Server effettua una chiamata al gestore eccezioni perché gestisca l'eccezione, compresi gli zombi. È possibile utilizzare una porta di trasmissione nel gestore eccezioni per inviare gli zombie a una destinazione per ulteriore verifica ed elaborazione.
Anche scenari differenti dalle serie di istruzioni possono generare zombie. Ad esempio, si supponga che un'istanza di orchestrazione attenda un messaggio di risposta da un processo di business, e che per qualche motivo, riceva due messaggi di risposta della sottoscrizione corrispondente. In questo caso, il secondo messaggio di risposta diventa uno zombie. Un altro esempio è quando si dispone di una forma Listen con una forma Di ricezione in un ramo e una forma Ritardo nell'altro ramo. Se un messaggio arriva proprio al momento del timeout, il messaggio diventa uno zombie.
Per altre informazioni su come gestire gli zombie, vedere Rimozione delle istanze del servizio sospese nelle indicazioni sull'interfaccia utente e informazioni di riferimento sullo spazio dei nomi delle API per sviluppatori.
Passaggi successivi
Serie di istruzioni sequenziali