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

1. We employ Oracle's Composite Sensors to monitor ErM's incoming and outgo-
ing messages. This information will be available for search and analysis of the In-
stances page of the SB SOA composition application in the Oracle Enterprise
Manager Fusion Middleware Control Console. From the following figure, you
can see what elements we decide to concatenate in the Sensor's expression. Bear
in mind that all these elements must be parts of the payload. Thus, as mentioned
earlier, ECID could actually be part of the ProcessName element. Assigning a
Sensor for an outgoing message is much simpler: it's an ErM Response. Here, we
are not using Mediator as the central component of the handler; all inbound mes-
sages are going to the BPEL process, which will help us with dispatching faults to
other components, thereby fulfilling generic requirements.
2. For error code conversions, a resolution action's lookup, and the extraction of
compensation workflows, we have to call ServiceInventoryEndpoint . If the first
task is optional, as it can be handled by Domain Value Maps ( DVM ) in SCA
Mediators, the second and third are the core of Error Manager.
3. It would be prudent to notify Ops or other involved parties as part of the resolu-
tion action. This part is implemented as NotificationService , employing the
whole bunch of Oracle communication adapters.
4. When the resolution action is identified, it will be passed back to the caller. If the
resolution is complex and requires a new instance of Service Broker (as a com-
pensative EP), then we assign the extracted EP to the new Process Header's con-
tainer and invoke an async SB.
5. Our last resort is the manual resolution that is used when automation is not pos-
sible, number of retries has exceeded, or we get a critical error during rollback.