Database Reference
In-Depth Information
duration of your choice. Set the statuses for (N)ew, (P)olling and (R)ead Orders
accordingly; you will need them for the select criteria.
2. Add a mediator initially with sequential operations and one transformation, for in-
stance, changing the order ID. Use the current
dateTime()
for timestamp ele-
ments. Deploy and test the application. Everything should be fine, calm, and
simple.
3. Let's emulate the error while operations are sequential (3). Any method will do if
you are running it on Unix chmod 444 on the destination file folder; simply as-
sign the OrderID initially defined as
xs:integer
in the message XSD, any
string value in DB, and so on. Redeploy and test the application. You will see the
dull and simple red-marked status
Failed
on the SOA Dashboard for Recent In-
stances. Recent Faults and Rejected Messages will inform you that
Exception
occurred when...
. Go to the Flow Trace and check what the reason was,
which you already know. The main point here is that we can't do much about it;
we cannot even Retry or perform any other action, and Recovery actions are un-
available.
4. Copy the following two files to the
project
folder (or any other location, in-
cluding MDS, but then change the references for
fault-bindings.xml
and
fault-policies.xml
in
composite.xml
as explained earlier).
The following is the first file that contains the Fault Policy XML definition:
<?xml version="1.0" encoding="UTF-8" ?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/
faultpolicy">
<faultPolicy version="2.0.1" id="SendOrderFaults"
xmlns:env="http://schemas.xmlsoap.org/
soap/envelope/"
xmlns:xs="http://www.w3.org/2001/
XMLSchema"
xmlns="http://schemas.oracle.com/bpel/
faultpolicy"
xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance">
<Conditions>
<faultName>
<condition>
<action
Search WWH ::
Custom Search