Taking Care – Error Handling - Applied SOA Patterns on the Oracle Platform - page 483

This is one of the reasons why in your design, you should separate Error Manage-
ment and Audit. The same is true for errors that occur in Audit, but they are def-
initely not life threatening and business can continue as usual. Only Error Handler
can inform you about the possible causes: invalid Audit message input, JMS
queue as an Audit service is unavailable, Audit MDB has malfunctioned, Audit
service is down, and Audit DB is down.
Tip
The OFM Audit Framework by default is undisruptive for business processes/ap-
plications because of the chain of bus-stops and Audit loaders. The situation
could not be so simple in OFM if you decide to include
COMPOSITE_INSTANCE , CUBE_INSTANCE , CI_INDEXES , and
DLV_MESSAGE tables into your Audit schema to trace a runtime trail of a mes-
sage flow, identified by an execution context ID (ECID) outside of the OEM con-
sole. Actually, you should do this, as all together these tables can provide you
with about 100 status codes regarding the composite instance's state. We do not
have space to present them here; you will easily find them in the Oracle docu-
mentation. Thus, if your Audit, based on information from these tables, hangs, it's
a very bad sign of the health of your SCAs. So, do not build SQL Audit statement
killers that could slow down the SCAs' database; on the other hand, missing in-
consistent Audit data from these tables indicates the critical situation in SCA.
Talking about the status code in general, only STATE_CLOSED_COMPLETED
(5) should make you happy. Be extra careful about STATE_CLOSED_STALE
and STATE_OPEN_FAULTED . Code 12 (running with faults, recovery required,
and suspended) must have the highest priority in your recovery routines. We will
talk about SCA Mediator code from MEDIATOR_INSTANCE a little further.
5. The next error situation ( 5 on the previous figure) is similar to the previous error,
but occurred on the master controller. Generally speaking, there are two main
reasons that are associated with this: either we do not have something to execute
or we are unable to invoke something. The first one cannot be handled at runtime,
as it's a result of a design-time or deployment mistake. In the controller operation,
you do not even have to stop it for fixing this situation. You can disable the fail-
ing service first in ESR, then deploy the corrected EP, and enable the service
again. Situations where we cannot invoke something or receive an erroneous re-
sponse from the composition member during runtime are the main reasons why
we should have Error Handler with dynamic error resolutions. Exceptions will be
handled automatically when: the Service Broker SCA is down; the queue for