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