Business Process Choreographer fornisce una funzione per la gestione di errori di infrastruttura temporanei.
Questa sezione descrive come il contenitore dei processi aziendali gestisce i messaggi non recapitati. Questo meccanismo è in contrasto con quello più semplice utilizzato dal contenitore human task, descritto in Gestione dei messaggi non recapitati per human task.
I processi di lunga esecuzione consistono in una sequenza di transazioni. Le transazioni sono separate dai messaggi JMS (Java Message Service), che il server invia a un bean basato sul messaggio. Questo bean inoltra i messaggi in entrata al server del processo, per l'elaborazione. Ogni transazione consiste delle seguenti azioni:
Il server potrebbe non riuscire ad elaborare un messaggio ricevuto dal bean basato sul messaggio per una delle seguenti ragioni:
Le risposte a queste cause sono le seguenti:
Causa | Risposta |
---|---|
Infrastruttura non disponibile | Il bean basato sul messaggio cerca, per un tempo specifico, di correggere la situazione. Cerca di mantenere tutti i messaggi disponibili fino a che il server non sia di nuovo operativo. Questo problema potrebbe essere causato da un errore del database, per esempio. |
Messaggio danneggiato | Dopo un numero specificato di tentativi, il messaggio viene inserito nella coda di attesa, dove può essere modificato o verificato. Dalla coda di attesa, può anche essere riportato alla coda input, per ritentare la transazione. |
L'implementazione per i messaggi per i processi aziendali è la seguente:
Quando il bean basato sul messaggio opera in modalità inattività, periodicamente cerca di elaborare un messaggio. I messaggi impossibili da elaborare ritornano alla coda di attesa, senza incrementare il conteggio di consegna o il conteggio trasversale della coda di conservazione. Non appena un messaggio riesce ad essere elaborato, il bean basato sul messaggio ritorna alla modalità di elaborazione normale.
Questa funzione consiste in due limiti numerici, due code, modalità inattività e comportamento di tentativo di invio messaggio.
Il numero massimo di tentativi definisce il numero massimo di volte che un messaggio può essere trasferito alla coda di conservazione prima di essere inserito nella coda di attesa.
Per essere inserito nella coda di conservazione, l'elaborazione di un messaggio non deve avvenire per tre volte.
Ad esempio, se il numero massimo di tentativi è 5, un messaggio deve andare alla coda di conservazione cinque volte (non deve essere elaborato per 3 * 5 = 15 volte), prima che venga avviato il loop dell'ultimo tentativo. Se il loop dell'ultimo tentativo non riesce altre due volte, il messaggio viene inserito nella coda di attesa. Questo significa che un messaggio deve non essere recapitato (3 * Numero massimo di tentativi) + 2 volte prima che venga inserito nella coda di attesa.
In un'applicazione critica per le prestazioni in esecuzione su un'infrastruttura affidabile, il numero massimo di tentativi deve essere basso: uno o due, ad esempio.
Per ubicare questo parametro nella console di gestione, fare clic su Contenitore processi aziendali.
. Quindi, all'intestazione delle impostazioni del contenitore dei processi aziendali, fare clic suIl limite del messaggio coda di conservazione definisce il numero massimo di messaggi che si possono trovare nella coda di conservazione. Se la coda di conservazione eccede, il sistema va in modalità inattività. Per fare in modo che il sistema vada in modalità inattività quando un messaggio non riesce, impostare il valore a zero. Per fare in modo che il contenitore dei processi aziendali sia più tollerante con gli errori dell'infrastruttura, aumentare il valore.
Per ubicare questo parametro nella console di gestione, fare clic su Contenitore processi aziendali.
. Quindi, all'intestazione delle impostazioni del contenitore dei processi aziendali, fare clic suLa coda di conservazione mantiene i messaggi non recapitati che vengono riprodotti spostandoli nella coda lavoro interna del contenitore dei processi aziendali. Un messaggio viene inserito nella coda di conservazione se non riesce tre volte. Se il messaggio non riesce (3 * Numero massimo di tentativi) + 2 volte, viene inserito nella coda di attesa. (Per dettagli sul numero massimo di tentativi, consultare Numero massimo di tentativi.) Se la coda di conservazione è piena fino al limite definito dal limite messaggio della coda di conservazione e un altro messaggio non riesce, la coda eccede e il sistema va in modalità inattività. L'amministratore può spostare i messaggi da questa coda alla coda interna eseguendo l'attività Query e riproducendo i messaggi di non recapitati.
La coda di attesa contiene messaggi che non vengono recapitati (3 * Numero massimo di tentativi) + 2 volte. (Per dettagli sul numero massimo di tentativi, consultare Numero massimo di tentativi.) L'amministratore può spostare i messaggi da questa coda alla coda interna eseguendo l'attività Query e riproducendo i messaggi di non recapitati.
L'amministratore può spostare i messaggi dalle code di attesa o di conservazione nella coda interna. Questo può essere effettuato utilizzando la console di gestione o utilizzando i comandi di gestione.
La modalità inattività viene inserita quando la coda di conservazione eccede. Quando questo si verifica, viene assunto che si è verificato un errore dell'infrastruttura serio, sebbene possibilmente temporaneo. Lo scopo della modalità inattività è di evitare che il sistema utilizzi molte risorse, mentre un errore dell'infrastruttura significa che la maggior parte dei messaggi comunque non verrà recapitata. In modalità inattività, il sistema dorme per due secondi prima di tentare l'elaborazione del messaggio successivo. Non appena il messaggio viene elaborato in maniera corretta, il sistema riprende l'elaborazione normale dei messaggi.
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)