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.
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.
In questo business case, si fa leva su un processo BPEL per il processo AccountCreation.
I processi short running sono noti come microflussi.
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:
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.
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.
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
e modificare il valore nel campo Numero massimo di consegne non riuscite.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.
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 |
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 | Sì | |
Asincrona - Risposta rinviata | Sì | |
Asincrono - Callback | Sì | |
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 | Sì |
Ulteriori informazioni relative alla visualizzazione e al reinoltro degli eventi non riusciti, si trovano nella sezione Reinoltro degli eventi non riusciti.
Destinazione del modulo SCA
Facendo nuovamente riferimento al business case in questione.
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)
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 .
È 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
Nome nodo: WESBNode Nome server: server1 Destinazione dell'eccezione di ripristino: WBI.FailedEvent.WESBNode.server1In 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.
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.
Capability amministrativa | Associato a WebSphere ESB Y/N? | Riepilogo |
---|---|---|
Gestore eventi non riusciti | Sì | 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) |
Sì |
Lettura/Eliminazione. Utilizzare il Browser SIB (Service Integration Bus) nella console di gestione per sfogliare ed eseguire le attività operative giornaliere nei SIB. |