Eseguire la migrazione dall'adapter MSMQT all'adapter MSMQ

In questo argomento vengono descritti gli aspetti relativi a recapito ordinato end-to-end, coerenza delle transazioni, disponibilità elevata e scalabilità da considerare prima di eseguire la migrazione dall'adapter Accodamento messaggi di BizTalk (MSMQT) all'adapter Accodamento messaggi (MSMQ). Ai fini di questo argomento, i termini recapito ordinato, coerenza delle transazioni, disponibilità elevata e scalabilità sono definiti nel modo seguente:

• Recapito ordinato. Garanzia che i messaggi vengano inviati da BizTalk Server nello stesso ordine in cui vengono ricevuti.

• Coerenza delle transazioni. Garanzia che i messaggi da elaborare non vengano persi o duplicati a causa di errori hardware, software o di rete.

• Disponibilità elevata. Garanzia che i servizi utilizzati per l'elaborazione dei messaggi siano sempre disponibili.

• Scalabilità. Possibilità di aumentare la capacità di elaborazione dei messaggi esistente.

Recapito ordinato end-to-end

L'adapter MSMQT assicura il recapito ordinato end-to-end dei messaggi. Questo significa che se un'applicazione MSMQ invia i messaggi 1, 2 e 3 a un indirizzo di ricezione associato all'adapter MSMQT, tali messaggi verranno recapitati a un'orchestrazione o a una porta di trasmissione di BizTalk Server nello stesso ordine, ovvero 1, 2, 3. Questa funzionalità può essere utilizzata ad esempio per le contrattazioni del mercato azionario, che è necessario inviare ed eseguire nello stesso ordine in cui vengono ricevute.

Il recapito ordinato end-to-end con MSMQT richiede l'interazione di diversi componenti, come illustrato nella sequenza di eventi seguente:

1. L'API MSMQ in un computer remoto riceve i messaggi 1, 2 e 3 in questo ordine e li inserisce in una coda locale transazionale nello stesso ordine.

2. Un client MSMQ nel computer remoto preleva i messaggi dalla coda e li invia alla coda di MSMQT nell'ordine 1, 2, 3.

3. L'adapter MSMQT riceve i messaggi nell'ordine 1, 2, 3 e li trasferisce al componente BizTalk MessageAgent nello stesso ordine.

4. Il componente BizTalk MessageAgent assicura che i messaggi vengano inviati al database MessageBox nell'ordine 1, 2, 3.

5. Il componente MessageBox instrada i messaggi e assicura che, se vengono instradati alla stessa istanza di un'orchestrazione o di una porta di trasmissione, vengano recapitati a tale istanza nello stesso ordine.

   In BizTalk Server 2004, MSMQT era l'unico adattatore in grado di garantire il recapito ordinato end-to-end. Tutti gli altri adapter integrati di BizTalk possono modificare l'ordine dei messaggi nei passaggi da 3 a 5 illustrati in precedenza. La maggior parte degli altri adapter integrati completa il passaggio 3 tramite un componente denominato Gestione endpoint che, essendo intrinsecamente multithreading, non mantiene l'ordine. L'adattatore MSMQ BizTalk Server 2004 ha usato una funzionalità di "elaborazione seriale" che mantiene l'ordine per il passaggio 3, ma non chiede a MessageAgent di mantenere l'ordine in futuro, in modo che i messaggi possano essere instradati a un'orchestrazione o a una porta di trasmissione non in ordine.

   Recapito ordinato end-to-end con l'adapter MSMQ

   Per ottenere il recapito ordinato end-to-end con l'adattatore MSMQ, seguire questa procedura:

6. Abilitare la proprietà Recapito ordinato sulla porta di ricezione per l'orchestrazione o la porta di trasmissione di sottoscrizione. In BizTalk Server le porte di ricezione nelle orchestrazioni e nelle porte di trasmissione hanno un'opzione di configurazione Recapito ordinato. Se questa opzione è abilitata, la porta di ricezione nell'orchestrazione o la porta di trasmissione chiede a MessageBox di recapitare i messaggi nello stesso ordine in cui sono stati inviati a MessageBox.

7. Impostare la proprietà Elaborazione ordinata per il percorso di ricezione associato all'adapter MSMQ su True. In BizTalk Server, le posizioni di ricezione che utilizzano il trasporto MSMQ possono essere configurate per l'utilizzo dell'elaborazione ordinata che, se abilitata, garantisce che i messaggi vengano inviati al MessageBox nello stesso ordine in cui sono stati ricevuti.

8. Impostare la proprietà Transactional per il percorso di ricezione associato all'adapter MSMQ su True.

9. Verificare che le code MSMQ monitorate dagli indirizzi di ricezione di MSMQ siano contrassegnate come "Transazionale". Questa proprietà deve essere impostata sulle code per garantire il recapito ordinato dei messaggi.

Nota

Il recapito ordinato è garantito solo se la coda o le code MSMQ monitorate dagli indirizzi di ricezione di BizTalk vengono utilizzate da un unico computer. Ciò può presentare problemi di scalabilità, come descritto di seguito.

Utilizzo delle transazioni per l'elaborazione di messaggi: differenze tra l'adapter MSMQT e l'adapter MSMQ

Per quanto riguarda l'utilizzo delle transazioni, i messaggi vengono elaborati in modo diverso dagli adapter MSMQT e MSMQ.

Quando si utilizza l'adapter MSMQT, i processi di ricezione dalla rete e di elaborazione di un messaggio con BizTalk Server vengono gestiti in una singola transazione. Quando si utilizza questo adapter, i messaggi ACK generati per il mittente indicano che il messaggio è stato ricevuto ed elaborato correttamente da BizTalk Server.

Quando si utilizza l'adapter MSMQ, i processi di ricezione dalla rete e di elaborazione di un messaggio con BizTalk Server vengono gestiti in due transazioni distinte, una per la ricezione dalla rete e l'altra per l'elaborazione con BizTalk Server. Quando si utilizza questo adapter, i messaggi ACK generati per il mittente indicano solo che il messaggio è stato ricevuto correttamente dalla rete, non che è stato elaborato da BizTalk Server. Il mittente riceve un messaggio ACK dal server Accodamento messaggi Microsoft quando il messaggio viene ricevuto dalla rete e reso persistente nella coda MSMQ locale, indipendentemente dal fatto che BizTalk Server sia o meno installato. I messaggi resi persistenti nella coda MSMQ vengono prelevati dall'adapter MSMQ di BizTalk, elaborati e pubblicati in MessageBox. Se il processo non viene completato, i messaggi vengono inviati nella coda dei messaggi sospesi di BizTalk o lasciati nella coda MSMQ locale (quando si utilizza l'elaborazione transazionale) e il mittente non riceve alcuna indicazione dell'elaborazione non riuscita in BizTalk Server.

Nelle architetture che richiedono la ricezione di messaggi ACK quando i messaggi vengono elaborati correttamente da BizTalk Server, è necessario aggiungere ACK a livello di applicazione se si esegue la migrazione dall'adapter MSMQT all'adapter MSMQ. Per implementare ACK a livello di applicazione, è necessario aggiornare l'applicazione mittente e di orchestrazione.

Disponibilità elevata (transazionale, in ordine)

Per garantire la disponibilità elevata per la scheda MSMQT, è possibile aggiungere più computer all'host di ricezione e configurare bilanciamento carico di rete per la tolleranza di errore oppure è possibile raggruppare l'host BizTalk predefinito. Se l'adapter MSMQT viene eseguito insieme a Bilanciamento carico di rete, in caso di arresto di un server il carico viene gestito dagli altri server. Se i gestori dell'adapter MSMQT vengono eseguiti in un host incluso in un cluster, in caso di errore di un nodo viene eseguito il failover dell'host all'altro nodo tramite il software di cluster. Quando si utilizza l'adapter MSMQ, Bilanciamento carico di rete non funziona se è necessario eseguire l'elaborazione transazionale senza perdita di dati, perché l'adapter MSMQ utilizza le code MSMQ locali per l'archiviazione intermedia. In questo scenario, se un messaggio è stato recapitato nella coda MSMQ locale ma non è stato utilizzato dall'adapter MSMQ, in caso di errore del computer il messaggio va perso.

Per garantire la disponibilità elevata e la coerenza transazionale con l'adattatore MSMQ, eseguire le operazioni seguenti:

1. Configurare Accodamento messaggi Microsoft (MSMQ) come risorsa inclusa in un cluster all'interno di un gruppo di cluster Windows Server dei server BizTalk Server.

2. Configurare il gestore di ricezione dell'adapter MSMQ in un'istanza dell'host BizTalk configurata come risorsa cluster nello stesso gruppo di cluster della risorsa MSMQ inclusa in un cluster.

3. Configurare la risorsa cluster per l'istanza dell'host BizTalk in modo che mantenga una dipendenza dalla risorsa MSMQ inclusa in un cluster.

   Per implementare il recapito ordinato con questa architettura, seguire i passaggi presentati in precedenza in "Recapito ordinato end-to-end con l'adapter MSMQ".

Disponibilità elevata (non transazionale, non in ordine)

Se è necessaria disponibilità elevata ma non è richiesta l'elaborazione transazionale, è possibile ottenere questo risultato con l'adapter MSMQ implementando Bilanciamento carico di rete ed eseguendo le istanze di un host configurate con i gestori di invio e ricezione di MSMQ in più server BizTalk dietro Bilanciamento carico di rete. Quando si implementa Bilanciamento carico di rete con MSMQ, è consigliabile seguire le procedure consigliate, come documentato nell'articolo della Microsoft Knowledge Base 899611: Come può funzionare accodamento messaggi su Bilanciamento carico di rete (NLB). In questo scenario, se si verifica un errore in uno dei server BizTalk, i messaggi eseguiti nell'istanza dell'host di tale server non saranno disponibili fino al ripristino del sistema. Questa configurazione fornisce disponibilità elevata perché se uno dei server BizTalk non è disponibile, Bilanciamento carico di rete instrada le richieste all'altro server BizTalk.

Scalabilità (non transazionale, non in ordine)

È possibile ottenere scalabilità seguendo le linee guida per la disponibilità elevata (non transazionale) e aggiungendo altre istanze host. Questa architettura assicura il recapito rapido e la scalabilità, ma non il recapito ordinato.

Scalabilità (transazionale, non in ordine)

Per il recapito transazionale non ordinato dei messaggi, è possibile combinare l'utilizzo di Bilanciamento carico di rete con MSMQ e Servizio cluster di Windows. Per questa architettura è necessario configurare almeno due gruppi di cluster in due ambienti cluster di Windows distinti, attenendosi alla procedure descritta in "Disponibilità elevata (transazionale, in ordine) per ogni cluster di Windows. Implementare quindi Bilanciamento carico di rete per distribuire il carico tra i gruppi di cluster. Poiché Bilanciamento carico di rete di Windows non è supportato nei cluster di Windows, questo scenario richiede una soluzione di bilanciamento del carico di rete hardware. Nella figura seguente viene illustrata questa architettura.

Nota

Questa architettura non fornisce il recapito ordinato.

Scalabilità (transazionale, in ordine)

La scalabilità orizzontale di un'architettura che fornisce disponibilità elevata, coerenza delle transazioni e recapito ordinato presenta problemi quando si utilizza MSMQ 3.0 o versione precedente, perché le letture transazionali remote non sono supportate se il computer BizTalk Server e il server MSMQ remoto non eseguono entrambi MSMQ 4.0. Se si utilizza MSMQ 3.0 o versione precedente, per ottenere scalabilità orizzontale è necessario utilizzare più code MSMQ locali. Inoltre, in questo scenario, se la connessione TCP/IP della sessione MSMQ con Bilanciamento carico di rete viene interrotta, è possibile che in seguito venga ripristinata da Bilanciamento carico di rete su un computer diverso, generando un recapito non in ordine.

Una delle possibili soluzioni a questa limitazione consiste nell'eseguire il bilanciamento del carico manuale del recapito dei messaggi allocando le code di destinazione a computer diversi. A tale scopo, collegare istanze specifiche dell'host BizTalk a code MSMQ specifiche. Se ad esempio si riceve un numero elevato di documenti da un determinato partner commerciale, è possibile creare una coda host e di ricezione distinta in un server BizTalk specifico solo per tale partner.

Se possibile, eseguire MSMQ 4.0 nei computer remoti quando è necessario supportare sia le letture transazionali remote sia il bilanciamento del carico.

Riepilogo

Nella tabella seguente sono riepilogate le architetture che è possibile implementare per supportare funzionalità specifiche.

Funzionalità	Né Bilanciamento carico di rete né cluster	NLB	Cluster	Bilanciamento carico di rete e cluster
Recapito ordinato end-to-end	Sì	No	Sì	Possibile con configurazione manuale
Coerenza delle transazioni	No (i messaggi possono essere persi o duplicati se si verifica un errore del servizio)	No	Sì	Sì
Ad elevata disponibilità	No	Sì	Sì	Sì
Scalabile	No	Sì	No	Sì

Vedere anche

Uso del cluster Windows Server per fornire disponibilità elevata per gli host BizTalk Server 2