Databases Reference
In-Depth Information
For the fault in our example, we will evaluate this to true, so the fault management
framework would execute the action
ora-retry
; if
flt:code
contained some other
value, then it would move to the next condition. As this doesn't include a
test
element, it will result in a match and execute the
ora-human-intervention
action.
The
message
element for some faults, including the extension faults
defined by BPEL PM, contains multiple parts. For example,
code
,
summary
, and
detail
. To evaluate the content of any of these parts, just
append the part name to
$fault.
. Therefore, to check the content of the
code
part, you would specify
$fault.code
.
Defining fault policy actions
The second part of our fault policy defines the actions referenced in the
Conditions
section. This consists of an
Actions
element, which contains one or more
Action
elements.
Each
Action
element contains an
id
attribute, which is the value referenced by the
action
ref
attribute within a condition. For the conditions defined in the preceding
policy, we have defined two actions:
ora-retry
and
ora-human-intervention
, as
shown here:
<Actions>
<Actionid=
"ora-retry"
>
<retry>
<retryCount>5</retryCount>
<retryInterval>15</retryInterval>
<exponentialBackoff/>
<retryFailureActionref="ora-human-intervention"/>
</retry>
</Action>
<Actionid=
"ora-human-intervention"
>
<humanIntervention/>
</Action>
</Actions>
The content of the
action
element is used to specify and configure the actual action
to be executed by the fault management framework, which can be one of
retry
,
humanIntervention
,
rethrow
,
abort
,
replayScope
, or
javaAction
.
The actions
rethrow
and
replayScope
cannot be used
for the Mediator component.
