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

clearly provided to Audit (Canonical Expressions in logging) and that the execu-
tion time can vary, depending on business hours. Let your developers wonder
about record subjects and log consolidation, and data cleansing will not be so
simple.
• Monitor the process footprint as a collection of individual invocations according
to the composition member's records in Service Repository. Obviously, there
should be no misses in the process log, and all entries and exits of individual ser-
vices must be according to the SLA.
• The last and obvious thing is that we should have no Error or Exception clauses
in the process log.
Frankly, if all conditions for technical and functional logging are met, all business com-
positions with related compensation logic are recorded in SR. The standard Oracle BAM
will perform monitoring gracefully, so triggering the recovery action is just a matter of
passing the initial message to any composition controller, with a new composition plan as
a parameter (this can be a dynamic EP, static BPEL/SCA, standalone PL/SQL, or a Java
function—whatever you can fire using IoC or NDS).
Some more side notes. Why should we consider an external simple Service Broker (or
message broker) for ART if we can follow the Redundant Implementation SOA pattern
for the entire OFM stack?
Well, it is always interesting to see how top management's opinion changes about absolute
necessity for the business to have HA with 99.95% availability (4,38 hours downtime per
year), when you explain in figures that moving to this presents from 95% (18 days) will
double the investments into infrastructure (and quite often more than double). Most im-
portantly, the Redundant Implementation pattern prevents you from HW malfunctions, not
from OFM misconfigurations (one of the top OWASP risks from the previous chapter),
poorly designed service, or a single illogical business rule.
Combining all the preceding factors, the basis for ART can be presented as a simplified
block diagram (refer to the next figure) with three generic parts:
• Log Collectors (deep green) are part of the adapter framework with individual ad-
apters for your custom logs, WSL/SOA Infra logs, and BPEL schema in particu-
lar. With every new source added, you have to implement a new adapter. Most of
these adapters already exist in OFM, so the trick here is to consolidate your own
formats that exist in OFM. This is not always straightforward; BPEL logs have
two records (entry and exit) for SCA components, where you could have one re-
cord with two related columns in your logs.