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

can be done in a traditional way, but you surely remember that DVMs are tradi-
tionally stored in OFM MDS, and transformations could be scattered across ad-
apter projects. So, the maintenance of any form of centralization is a question.
• After cleansing/normalization, an error's technical information is properly logged.
Obvious things such as squeezing the entire stack trace dump into the 2K
VARCHAR2 field are solved during the development stage, but the question is a
bit broader than the completeness of stored information. According to generic
SOA principles, the core requirements for Abstraction and Discoverability (which
are not exactly the best of friends) are as follows:
◦ Interpretability of logged data. Data elements that are necessary for mak-
ing a decision must be easily discoverable and understandable, as many
policies will trust their meanings. Just think of this: not all reactions on
an event should be immediate; it is desirable to have different handling
policies for the same error, and it should depend on the time window and
the number of event occurrences in a certain time interval. This means
that some abnormal events which happen between business hours
(09:00-17:00) should be handled in 5 minutes (retried, passed to com-
pensation, send to human tasklist, or canceled), whereas 02:00-04:00
batch operations' mishaps of the same type must be handled after one
hour (the question of why someone could decide to run batch jobs using
SOA compositions is not critical for this example; it can be done any-
way). Conditions for this kind of discriminant handling with sliding time
windows could be really complex, so the data for making decisions must
be precise and easily extractable.
◦ Interpretability also requires proper error classification, and for immedi-
ate exceptions, this can be done on an acting service. Even simple segreg-
ation of Technical and Functional errors will be helpful for event pattern
recognition, but actually, we can do a lot during the initial service design
phase. It is our responsibility to identify the framework that will be host-
ing our service (we will identify the closest neighbours of our service)
and types of compositions it will participate in. Thus, for runtime errors,
it's quite possible to compose a list of errors and their causes. Right from
the start, we can say that most technical errors will be related to utility
services, whereas functional types belong to task-orchestrated services.
This classification must be stored in the Service Repository, but we
should warn you about making it too formal. Example of this registering
and classification exercise will be demonstrated further.
◦ The preceding requirement is the main prerequisite for a low EH foot-
print. The exception handling system should not consume vital server re-