Le eccezioni del runtime di servizio sono delle eccezioni non dichiarate. In generale, esse rappresentano le condizioni di errore che non vengono anticipate dall'applicazione.
Le eccezioni del runtime di servizio vengono utilizzate per segnalare una condizione imprevista nel runtime.
Gli sviluppatori dei componenti possono gestire le eccezioni del runtime di servizio nei seguenti modi:
Ad esempio, se un partner non è in grado di soddisfare una richiesta, forse un altro partner potrebbe esserlo.
Ad esempio, un timeout per un partner può risultare in un'eccezione di business che indica che la maggior parte della richiesta è stata elaborata, ma una parte della stessa non è stata completata e occorre riprovare successivamente oppure provare con parametri diversi.
Se un'eccezione non viene ricevuta, viene inviata al componente che ha chiamato il componente corrente. Questa catena di chiamate arriva fino al chiamante originale. Ad esempio, Modulo A chiama Modulo B e Modulo B chiama Modulo C e Modulo C genera un'eccezione, Modulo B potrebbe cogliere o non cogliere l'eccezione. Se Modulo B non coglie l'eccezione, questa ritorna a Modulo A.
Quando viene generata un'eccezione ServiceRuntimeException da un componente, verrà eseguito il rollback della transazione corrente. Questo tipo di elaborazione dell'eccezione viene ripetuta per tutti i componenti presenti nella catena. Ad esempio, se viene inviata un'eccezione ServiceRuntimeException da Modulo C, tale transazione verrà contrassegnata per il rollback. Successivamente l'eccezione viene inviata al Modulo B, nel caso in cui non venisse ricevuta e fosse presente un'altra transazione, verrà eseguito il rollback anche di tale transazione. Gli sviluppatori dei componenti possono utilizzare qualificatori QoS (quality of service) per controllare se la chiamata si verifica nella transazione corrente o in una nuova. Pertanto, se Modulo A chiama Modulo B e Modulo B fa parte di una nuova transazione, Modulo A può "cogliere" un'eccezione ServiceRuntimeException da Modulo B e continuare l'elaborazione, senza il rollback della transazione di Modulo A.
Tenere presente che il contenuto della transazione di cui è stato eseguito il rollback può variare, a seconda della natura della transazione. Ad esempio, i processi BPEL di lunga durata possono essere suddivisi in molte transazioni più piccole. Le chiamate di richieste e risposte asincrone vengono suddivise da una transazione automaticamente (altrimenti l'applicazione chiamante potrebbe dover attendere un lungo periodo per la risposta).
Nelle istanze in cui una transazione viene suddivisa in più chiamate asincrone (in opposizione ad un'unica grande transazione), verrebbe eseguito il rollback del lavoro iniziale della transazione alla ricorrenza di un'eccezione ServiceRuntimeException. Tuttavia, la risposta dalla chiamata asincrona viene inviata da una transazione diversa, e poiché la risposta dalla domanda asincrona non avrebbe un posto dove andare, viene creato un evento nel FEM (Failed Event Manager).
Il seguente elenco è composto da 4 sottoclassi correnti di ServiceRuntimeException:
Questa eccezione viene utilizzata per indicare che un messaggio SCA asincrono è scaduto. I tempi di scadenza possono essere impostati utilizzando il qualificatore RequestExpiration su un riferimento del servizio.
Questa eccezione viene utilizzata per indicare che la risposta ad una richiesta asincrona non è stata ricevuta entro il periodo di tempo configurato. I tempi di scadenza possono essere impostati utilizzando il qualificatore ResponseExpiration su un riferimento del servizio.
Questa eccezione viene utilizzata per indicare che si è verificata un'eccezione durante la chiamata di un servizio esterno mediante un'importazione.
Questa eccezione viene utilizzata per indicare che il riferimento del servizio sul componente non è collegato correttamente.