Service Runtime Exceptions são exceções não declaradas. Em geral, elas representam condições de erro que não são previstas pelo aplicativo.
Service Runtime Exceptions são utilizadas para sinalizar uma condição inesperada no tempo de execução.
Os desenvolvedores de componentes podem manipular Service Runtime Exceptions das seguintes maneiras:
Por exemplo, se um parceiro não puder atender a um pedido, talvez outro possa.
Por exemplo, um tempo limite para um parceiro pode resultar em uma exceção de negócios que indica que a maioria dos pedidos foram processados, mas houve uma parte do pedido que não foi concluída e deve ser tentada outra vez posteriormente com diferentes parâmetros.
Se uma exceção não for capturada, a exceção será transmitida para o componente que chamou o componente atual. Esta cadeia de chamadas continua de volta ao responsável pela chamada original na cadeia. Por exemplo, o Módulo A chama o Módulo B e o Módulo B chama o Módulo C e então o Módulo C lança uma exceção, o Módulo B pode capturar ou não essa exceção. Se o Módulo B não capturar a exceção, então a exceção viaja de volta para o Módulo A.
Quando um ServiceRuntimeException é lançado de um componente, a transação atual é retornada. Esse tipo de processamento de exceção é repetido para todos os componentes na cadeia. Por exemplo, se uma ServiceRuntimeException é lançada de um Módulo C, essa transação será marcada para retroceder. Em seguida, a exceção é lançada para o Módulo B, onde se ela não for capturada e uma outra transação estiver presente, essa transação também retrocederá. Desenvolvedores de componente podem utilizar qualificadores quality of service (QoS) para controlar se chamadas ocorrem na transação atual ou em uma nova transação. Assim, se o Módulo A chama o Módulo B e o Módulo B é parte de uma nova transação, então o Módulo A pode "capturar" um ServiceRuntimeException do Módulo B e continuar o processamento, sem precisar do retorno da transação do Módulo A.
Você precisa estar ciente de que o conteúdo da transação retornada pode variar, dependendo da natureza da transação. Por exemplo, processos BPEL de execução longa podem ser segmentados em muitas transações menores. Pedido assíncrono e chamadas de resposta são interrompidas por uma transação automaticamente (caso contrário o aplicativo de chamada teria que aguardar muito tempo pela resposta).
Em ocorrências em que uma transação é dividida em várias chamadas assíncronas (em oposição a uma transação grande), o trabalho inicial da transação seria retornar a ocorrência de um ServiceRuntimeException. Entretanto, a resposta da chamada assíncrona seria enviada de uma transação diferente, e como a resposta da chamada assíncrona não teria lugar para ir, um evento é criado no Failed Event Manager (FEM).
A lista a seguir é de 4 subclasses atuais de ServiceRuntimeException:
Esta exceção é utilizada para indicar que uma mensagem SCA assíncrona expirou. Os tempos de expiração podem ser configurados utilizando o qualificador RequestExpiration em uma referência de serviço.
Esta exceção é utilizada para indicar que a resposta a um pedido assíncrono não foi recebida dentro do período de tempo configurado. Os tempos de expiração podem ser configurados utilizando o qualificador ResponseExpiration em uma referência de serviço.
Esta exceção é utilizada para indicar que foi lançada uma exceção durante a chamada de um serviço externo através de uma importação.
Esta exceção é utilizada para indicar que a referência de serviço no componente não está conectada corretamente.