WebSphere Enterprise Service Bus, Versione 6.2.0 Sistemi operativi: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Caso d'uso: Ripristino dei dati dagli eventi non riusciti

Uno scenario di utilizzo fornisce un contesto per uno scenario di ripristino. Nello scenario di utilizzo, un'azienda ha un'applicazione che riceve una richiesta di creazione di un nuovo account.

La soluzione è composta da più moduli come consigliato dalle migliori pratiche del modulo.

IL primo modulo media la richiesta e delega il lavoro ad un processo di creazione account. Nel seguente esempio è stata implementata la soluzione come moduli separati in cui la richiesta è stata trasferita tra il modulo di mediazione (AccountRouting) e il modulo di elaborazione (AccountCreation) mediante un'importazione/esportazione SCA. Prendere visione della seguente immagine per l'illustrazione dei due moduli.

Figura 1. Diagramma di assemblaggio del processo di indirizzamento dell'account
Una richiesta viene trasferita tra il modulo di mediazione (AccountRouting) e il modulo di elaborazione (AccountCreation) dall'importazione SCA all'esportazione SCA.

Dal diagramma di assemblaggio mostrato in Figura 1, è possibile iniziare a vedere le ubicazioni del flusso in cui potrebbero essersi verificati i malfunzionamenti. Qualsiasi punto di chiamata nel diagramma di assemblaggio può propagare o interessare una transazione. Vi sono alcune aree nel flusso in cui i dati verranno raccolti come risultato dei malfunzionamenti dell'applicazione o del sistema.

In generale, i limiti della transazione vengono creati e gestiti dall'interazione (sincrona e asincrona) esistente tra i componenti e i bind di importazione/esportazione e i loro qualificatori associati. I dati di business vengono raccolti in ubicazioni di ripristino specifiche, molto spesso a causa della non riuscita, al deadlock o al rollback della transazione.

Le capacità delle transazioni in WebSphere Application Server sono utili a WebSphere ESB per l'instaurazione di transazioni con i fornitori di servizi. Tali interazioni utilizzate sono particolarmente importanti da comprendere rispetto ai bind di importazione ed esportazione. La comprensione della modalità di utilizzo delle importazioni e delle esportazioni all'interno di business case è importante per la determinazione dell'ubicazione in cui vengono accumulati gli eventi che necessitano un ripristino.

Una strategia di gestione degli errori deve definire i modelli di interazione, le transazioni utilizzate, l'utilizzo dell'importazione e dell'esportazione prima di sviluppare l'applicazione. L'architetto della soluzione deve identificare le preferenze di utilizzo, le linee guida, che verranno utilizzate durante la creazione dell'applicazione. Ad esempio, l'architetto deve sapere quando utilizzare le chiamate sincrone e le chiamate asincrone, quando utilizzare la gestione dell'errore BPEL e così via. L'architetto deve sapere se tutti i servizi possono partecipare alle transazioni e per quei servizi che non possono partecipare come gestire la compensazione se si verificano errori.

Inoltre, l'applicazione mostrata nel diagramma di assemblaggio in Figura 1 fa leva sui gruppi di connettività e le migliori pratiche dello sviluppo del modulo. Sfruttando questo pattern, ora si ha la capacità di arrestare il flusso in entrata di nuovi eventi, arrestando il modulo AccountRouting.

Le seguenti sezioni trattano l'ubicazione dei dati di business nel caso di malfunzionamento e ripristino.

Gestore flusso di business o Gestore di attività umane

In questo business case, si fa leva su un processo BPEL per il processo AccountCreation.

In merito al ripristino, vi sono alcune domande, come le seguenti, che occorre chiedersi rispetto alla gestione di BPEL e delle attività umane:
  1. Quale tipo di processo viene eseguito (breve esecuzioneo lunga esecuzione, state machine di business, attività umana)?

    I processi short running sono noti come microflussi.

  2. Il processo è stato sviluppato correttamente e sta utilizzando la gestione degli errori per promuovere l'integrità dei dati?
  3. Come sono configurate le proprietà dei pattern di chiamata e delle unità di lavoro per prevedere e controllare i limiti delle transazioni?

La conoscenza delle risposte a tali domande influenzerà la propria strategia di ripristino per le chiamate 7 e 8 mostrate nel diagramma di assemblaggio, come evidenziato nell'immagine seguente:

Figura 2. Diagramma di assemblaggio dell'indirizzamento dell'account - chiamate 7 e 8
Immagine che mostra il diagramma di assemblaggio con le chiamate 7 e 8 evidenziate.

I componenti stateful, come i processi BPEL a lunga esecuzione e state machine di business, interessano molte transazioni del database in cui viene eseguito il commit, nel database, delle modifiche di attività del processo e delle modifiche dello stato. Il lavoro procede aggiornando il database e immettendo un messaggio su una una coda interna che descrive cosa va eseguito successivamente.

Se si verificano dei problemi durante l'elaborazione dei messaggi interni al Gestore flusso di business, tali messaggi vengono spostati in una Coda di conservazione. Il sistema prova a continuare l'elaborazione dei messaggi. Se un messaggio successivo viene elaborato correttamente, i messaggi sulla coda di conservazione vengono reinoltrati per l'elaborazione. Se lo stesso messaggio viene immesso cinque volte sulla coda di conservazione, viene poi immesso sulla coda di attesa.

Ulteriori informazioni relative alla visualizzazione del numero di messaggi e la ripetizione dei messaggi si trovano in Ripetizione dei messaggi dalla Coda di ritenzione / Coda di attesa.

Manager degli eventi non riusciti

Il FEM (Failed Event Manager, gestore eventi non riusciti) viene utilizzato per ripetere gli eventi o le richieste di chiamata dei servizi effettuate in modalità asincrona tra la maggior parte dei tipi di componenti.

Gli eventi non riusciti vengono creati se il componente AccountRouting effettua una chiamata asincrona al bind di importazione SCA AccountCreationSCAImport e viene restituita una ServiceRuntimeException.

È importante notare che gli eventi non riusciti non vengono generati nella maggior parte dei casi dove BPEL è il client nell'interazione del servizio. Ciò indica che la chiamata 7 e 8 (come mostrate in Figura 2) non risulteranno tipicamente in un evento non riuscito. BPEL fornisce dei gestori errori e altri modalità da modellare per gli errori. Per questo motivo, se si verifica un errore SRE (ServiceRuntimeException) con la chiamata a "JDBCOutboundInterface", l'SRE viene restituito al BPEL per l'elaborazione. La strategia di gestione degli errori per il progetto deve definire la modalità di gestione costante delle eccezioni di runtime in BPEL.

È importante notare tuttavia, gli eventi non riusciti vengono creati per il messaggio di risposta asincrona per il client BPEL se tali messaggi non possono essere distribuiti sull'istanza del processo a causa di un errore dell'infrastruttura.

Il seguente diagramma illustra come funziona il componente Gestore eventi non riusciti. Le descrizioni dell'elaborazione associata ad ogni operazione numerata, vengono fornite dopo il diagramma.

Figura 3. Elaborazione del gestore eventi non riusciti
Diagramma dell'elaborazione del gestore eventi non riusciti. Il diagramma è numerato e le operazioni numerate vengono fornite in un elenco che segue il diagramma.
Elaborazione del gestore eventi non riusciti
  1. Il componente di origine effettua una chiamata utilizzando un pattern di chiamata asincrona
  2. Il MDB SCA toglie il messaggio dalla destinazione SCA
  3. I MDB SCA effettua la chiamata al componete di destinazione corretto
  4. Il componente di destinazione emette una ServiceRuntimeException
  5. Viene effettuato il rollback della transazione MDB SCA alla destinazione SCA
  6. Le informazioni dell'eccezione vengono memorizzate nel database del gestore eventi non riusciti con uno stato non confermato
  7. La chiamata viene ripresa dal SIBus n volte

    Il valore predefinito del limite di tentativi è 5 - uno originale e 4 nuovi tentativi. È possibile modificare il valore predefinito nella console di gestione. Ad esempio, dato un modulo SCA M, è possibile accedere a Bus > SCA.SYSTEM.<CELL>.BUS > Destinazioni > sca/M e modificare il valore nel campo Numero massimo di consegne non riuscite.

  8. Una volta che il numero di tentativi raggiunge il limite specificato, il messaggio viene trasferito sulla destinazione FEM.
  9. Il gestore eventi non riusciti prende il messaggio
  10. Il database del gestore eventi non riusciti aggiorna l'evento non riuscito nel database e lo stato viene impostato su non riuscito.

Quando vengono creati gli "eventi non riusciti"?

Come affermato, gli eventi non riusciti non vengono creati per le chiamate asincrone, ne tipicamente per le interazioni del processo di business bidirezionale.

Gli eventi non riusciti vengono generalmente creati quando i client utilizzano un pattern di chiamata asincrona e una ServiceRuntimeException viene emessa dal fornitore del servizio.

Se tutte le operazioni vengono eseguite in modo sincrono e nella stessa transazione, i dati non vengono raccolti. Viene invece eseguito il rollback nel client da cui è partita la chiamata. Ogni volta viene eseguito un commit, vengono raccolti i dati. Se tutte le chiamate sono sincrone, ma vengono eseguiti più commit, tali commit diventano un problema.

In generale, si consiglia di utilizzare le chiamate di elaborazione asincrone o il BPEL long running se è necessario eseguire più transazioni. Quindi, ogni chiamata ASYNC rappresenta una possibilità di raccogliere i dati. I processi BPEL long running sono un punto di raccolta.

Tabella 1. Pattern di chiamata e relazione per la creazione di eventi non riusciti:Service Business Exceptions
Pattern di chiamata Evento non riuscito creato Y/N? Nota
Sincrono No Gli eventi non riusciti non vengono creati per le eccezioni SBE oppure quando si utilizza un pattern sincronizzato
Asincrono - Unidirezionale No Per definizione, le chiamate unidirezionali non possono dichiarare errori, ossia, non è possibile emettere una ServiceBusinessException.
Asincrona - Risposta rinviata No Gli eventi non riusciti non vengono creati per le eccezioni SBE
Asincrono - Callback No Gli eventi non riusciti non vengono creati per le eccezioni SBE
Tabella 2. Pattern di chiamata e relazione per la creazione di eventi non riusciti: Service Runtime Exceptions
Pattern di chiamata Evento non riuscito creato Y/N? Nota
Sincrono No Gli eventi non riusciti non vengono creati per le eccezioni SRE oppure quando si utilizza un pattern sincronizzato
Asincrono - Unidirezionale  
Asincrona - Risposta rinviata  
Asincrono - Callback  
BPEL - Bidirezionale No
Gli eventi non riusciti non vengono creati quando il componente di origine è un processo di business.
Nota: Per una chiamata asincrona, se la risposta non può essere restituita a BPEL, viene creato un evento non riuscito.
BPEL - Unidirezionale  
Per ulteriori informazioni, prendere visione dell'argomento del centro informazioni intitolato Gestione degli eventi non riusciti.

Ulteriori informazioni relative alla visualizzazione e al reinoltro degli eventi non riusciti, si trovano nella sezione Reinoltro degli eventi non riusciti.

Destinazioni del SIB (Service Integration Bus)

I messaggi in attesa di essere elaborati, possono essere accumulati in alcune destinazioni SIB (Service Integration Bus). La maggior parte di queste destinazioni sono destinazioni del "sistema". I messaggi all'interno di queste destinazioni solitamente sono un misto di tre tipi, come di seguito riportato:
  • Richieste asincrone per l'elaborazione
  • Risposte asincrone alle richieste
  • I messaggi asincroni che non hanno superato la deserializzazione o la risoluzione del selettore funzioni
    Nota: Le risposte asincrone possono essere degli oggetti di business validi oppure malfunzionamenti restituiti come risultato di una richiesta.

Destinazione del modulo SCA

Facendo nuovamente riferimento al business case in questione.

Vi sarebbero due destinazioni del "Modulo SCA" nella soluzione:
  • sca/AccountRouting
  • sca/AccountCreation

Queste destinazioni vengono create quando il modulo viene distribuito in un server delle applicazioni o in un cluster.

Vi sono poche possibilità perché i messaggi si accumulino in queste destinazioni. L'accumulo dei messaggi in tali destinazioni è una forte indicazione che vi possa essere un problema di prestazioni o un difetto dell'applicazione. Esaminare immediatamente tale situazione. È importante monitorare la profondità delle destinazioni del modulo (con la soluzione di monitoraggio IT scelta) dato che un backup dei messaggi potrebbe portare ad un'interruzione del sistema oppure ad un tempo di riciclaggio prolungato.

Queste destinazioni vengono denominate "Modulo SCA" perché il nome generato è lo stesso del nome del modulo con l'aggiunta di "sca/". Tali destinazioni sono fondamentali nel funzionamento delle chiamate asincrone SCA (richieste e risposte di broker). Esistono un numero variabile di altre destinazioni che vengono generate durante l'installazione dell'applicazione sul bus SCA.SYSTEM, ma per lo scopo della discussione verrà trattata l'importanza della destinazione "Modulo SCA".

Tentativo del SIB (System Integration Bus)

Come visto in precedenza, il gestore eventi non riusciti ha un meccanismo integrato per i tentativi con il MDB (message driven bean) SCA. Questo funzionamento dei tentativi può essere controllato modificando l'attributo "Numero massimo di consegne non riuscite" sulla destinazione del modulo.
Nota: Solitamente, non vi è motivo di regolare questa capability dei tentativi. Tali informazioni vengono fornite qui per completezza.

Facendo riferimento al business case corrente, vi sono diverse destinazioni SIB create da SCA per supportare la comunicazione asincrona.

Come è stato appreso, una di queste destinazioni viene chiamata "sca/AccountRouting". È possibile regolare il numero di tentativi che si verificano durante una ServiceRuntimeException di una chiamata del servizio asincrona, modificando il valore della proprietà "Numero massimo di consegne non riuscite" mediante la console di gestione. Tuttavia, è possibile non impostare inferiore a 2 nei moduli con un processo BPEL. La seconda distribuzione è necessaria per restituire ServiceRuntimeExceptions al BPEL per l'elaborazione.

Destinazione delle eccezioni del sistema

Il gestore eventi non riusciti è uno dei mezzi da poter utilizzare per gestire i malfunzionamenti. Quando si ha a che fare con le importazioni e le esportazioni basate su JMS o EIS, occorre considerare un'altra ubicazione importante.

Le destinazioni sul bus SCA.Application vengono configurate per indirizzare i messaggi non riusciti sulla destinazione dell'eccezione del sistema SIB di tale bus. Quindi, se un'esportazione JMS prende un messaggio dal bus dell'applicazione SCA e incontra una situazione di rollback, il messaggio non riuscito verrà indirizzato sulla destinazione dell'eccezione del sistema SIB invece della destinazione dell'eccezione del ripristino WBI. Questo scenario è diverso da quello trattato in precedenza nella discussione relativa all'evento non riuscito, nel quale la deserializzazione di un messaggio non riuscita sul bus SCA.Application non risulterà in un evento non riuscito. Vi è una destinazione dell'eccezione del sistema su ogni bus all'interno della soluzione. Tali destinazioni devono essere monitorate e gestite come la "coda di messaggi non recapitabili" comune alle infrastrutture MQ.

Considerare il seguente scenario .

Diagramma che mostra l'elaborazione delle eccezioni del sistema
Un client JMS esterno immette un messaggio su una coda in entrata esposta mediante un'esportazione JMS. L'MDB del bind di esportazione JMS prende il messaggio per elaborarlo. Da qui, si verificherà una delle seguenti due situazioni:
  1. L'esportazione JMS analizza correttamente il messaggio e determina quale operazione sull'interfaccia richiamare, a qual punto il messaggio viene inviato al runtime SCA per l'elaborazione.
  2. L'esportazione JMS non riesce a riconoscere il corpo del messaggio come un oggetto di business valido oppure il bind di esportazione JMS deserializza il corpo del messaggio ma non è in grado di determinare l'operazione appropriata sull'interfaccia da richiamare. A questo punto il messaggio viene immesso nella destinazione dell'eccezione del sistema del bus.

È possibile avere questo tipo di malfunzionamento quando si prova a ricevere le richieste da AccountRoutingJMSExport (1). Questa esportazione è un'esportazione JMS e vi è la possibilità che gli eventi si possano accumulare sulla destinazione dell'eccezione del sistema sul bus SCA.Application.Bus. Utilizzare la soluzione di monitoraggio IT scelta per osservare la profondità di tale destinazione.

Destinazioni del gestore eventi non riusciti e di SIB

Per WebSphere ESB, la destinazione dell'eccezione è impostata sulla coda di destinazione dell'eccezione di WebSphere ESB. Questa coda segue una convenzione di denominazione come quella seguente:
Nome nodo: WESBNode
Nome server: server1
Destinazione dell'eccezione di ripristino: WBI.FailedEvent.WESBNode.server1
In generale, tutte le destinazioni create sul bus SCA.System verranno configurate per indirizzare i messaggi non riusciti sulla destinazione dell'eccezione di ripristino.

Quando si verifica un errore del sistema, oltre a catturare il messaggio non riuscito in questa destinazione dell'eccezione, la funzione di ripristino di WebSphere ESB genera anche un evento non riuscito che rappresenta l'errore del sistema e lo memorizza nel database di ripristino come descritto nella sezione Gestore eventi non riusciti di questo documento.

Riepilogo

Per riepilogare, WebSphere ESB fornisce capacità amministrative che vanno oltre la piattaforma di WebSphere Application Server fondamentale. È necessario prendere le misure appropriate per comprendere e utilizzare tali capacità insieme alla seguente guida fornita nella sezione di pianificazione della prevenzione degli errori in Pianificazione della prevenzione degli errori e del ripristino.

Tabella 3. Capacità amministrative per facilitare la gestione degli errori
Capability amministrativa Associato a WebSphere ESB Y/N? Riepilogo
Gestore eventi non riusciti Accesso Lettura/Modifica/Eliminazione. Questo è il punto centrale per gestire le eccezioni di runtime del servizio e altre forme di malfunzionamenti dell'infrastruttura.

Browser SIB (Service Integration Bus)

Lettura/Eliminazione. Utilizzare il Browser SIB (Service Integration Bus) nella console di gestione per sfogliare ed eseguire le attività operative giornaliere nei SIB.

Nota: Il numero di eventi o record che possono essere amministrati simultaneamente da questi strumenti è determinato da fattori esterni, come ad esempio l'allocazione della memoria, le serie di risultati e l'ottimizzazione del DB, il timeout di connessione. Eseguire i test ed impostare le soglie appropriate per evitare eccezioni (OOM, TransactionTimeOut).

concept Argomento Concetto

Termini di utilizzo | Feedback


Icona data/ora Ultimo aggiornamento: 02 Luglio 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. Tutti i diritti riservati.
Questo centro informazioni utilizza la tecnologia Eclipse. (http://www.eclipse.org).