SOA 12c: How to add conditions based on fault data in fault-policies.xml

Little bit of back ground on Fault-policies.xml and fault-bindings.xml:
Fault Policy File contains differenct policies. Each policy Maps "conditions" to "Actions"
    "Conditions": Group of Faults or a single fault.
    "Actions": single action or Set of actions identified by and ID
Fault Bindings file maps Policies to applications/components/bindings.

In this example, we will see how to put a condition on the fault data the Client receives.

With in a single fault policy, for the same fault, we can add test conditions and trigger different actions based on the condition results. Below is a snippet for example.

 <faultName name="custom:InvalidCreditCard"
                       xmlns:custom="http://xmlns.oracle.com/12cLearning/CCStatus/QueryCCStatusBpel"
                        xmlns:cs="http://ns.example.com/ccstatus"
                       path="SOA\WSDLs\queryccstatusbpel_client_ep.wsdl">
            <condition>
                <test>$fault.payload/cs:faultReason="Date Expired"</test>
                <action ref="HumanIntervention"/>
                <!--action ref="ora-retry"/-->
            </condition>
                <condition>
                    <action ref="ora-retry"/>
                </condition>
</faultName>

You can make the condition based on the fault definition in the WSDL provider. for e.g. Fault: InvalidCreditCard is defined in the wsdl as below.
$fault.<wsdl Part Name>/<namespace>:<XPath As per Schema Definition>
Make sure <namespace> is added as shown in the above example.

<wsdl:fault name="InvalidCreditCard" message="client:QueryCCStatusBpelFaultMessage"/>

    <wsdl:message name="QueryCCStatusBpelFaultMessage">
        <wsdl:part name="payload" element="ns1:CCFault"/>
    </wsdl:message>

 

SOA 12c: Develop a Synchronous service which also returns a fault data

A synchronous service wsdl can be updated with additional schema element to represent fault message and make it as an output variable in the event of fault.

In this example, we will show how to update WSDL and how various faults(system and business) can be caught and how to dynamically pass fault message through variables.

(1) Designed a simple web service to return a credit card status. The Reference component is a simple DB Adapter which queries a table with Credit card number as input and get status as output. The dummy values are as below.

1234-1234-1234-1234 VALID
1111-1111-1111-1111 INVALID
9999-9999-9999-9999 DATE EXPIRED

(2) Update the WSDL to include fault as output.
step1: Extend the schema to represent fault element.
step2: add a message to represent message type for fault data.
    <wsdl:message name="QueryCCStatusBpelFaultMessage">
        <wsdl:part name="payload" element="ns1:CCFault"/>
    </wsdl:message>
step3: Add wsdl:fault within the wsdl operation.
        <wsdl:operation name="process">
            <wsdl:input message="client:QueryCCStatusBpelRequestMessage"/>
            <wsdl:output message="client:QueryCCStatusBpelResponseMessage"/>
            <wsdl:fault name="InvalidCreditCard" message="client:QueryCCStatusBpelFaultMessage"/>
        </wsdl:operation>
(3) As you noted above, the process should return InvalidCreditCard as a fault message in all fault scenarios. However, we will design in a way that proper message is sent to Client within the CCFault element.
(4) With in BPEL, check the DB Adapter output. Following that ,implement below If logic.
 a. If credit card status is INVALID, throw a fault with faultName as InvalidCreditCard. Do not choose any fault variable.
b. If credit card status is DATE EXPIRED, throw a fault with faultName as InvalidCreditCard. create a fault variable based on message type. We did not choose fault variable in previous case just to demo on how the catch activity is chosen when there are multiple for same fault.

(5) Create multiple catch activities.
step1: Create catch for the fault: InvalidCreditCard with out any fault variable.
step2: Create catch for the same fault: InvalidCreditCard with same variable which is created in step: 4.b.
You can note how the catch activity is choosen. The one with variable is chosen with priority.
step3: Create a catchall activity to handle all the system faults. You can use the function ora;getFaultAsString() to get runtime fault message.
(6) In all the catch Activities do a reply with Fault along with Fault variable. Update the fault element with appropriate fault reason message.

 

SOA 12c: How to expose a schema without a namespace in Bpel

In few scenarios, we may have to process old style XML document  without namespaces. However, BPEL activities may not be able to work with variables properly without proper namespace.

In this example, we will see how to associate a namespace before bpel activities start.

Assume, we have below xsd: CustomerStauts.xsd
<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  elementFormDefault="qualified">
  <xsd:element name="custInput" type="custInputType">
    <xsd:annotation>
      <xsd:documentation>customer Input</xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:element name="statusOuput" type="custCreditStatustType">
    <xsd:annotation>
      <xsd:documentation>customer credit status Ouput</xsd:documentation>
    </xsd:annotation>
  </xsd:element> 
  <xsd:complexType name="custInputType">
    <xsd:sequence maxOccurs="unbounded">
      <xsd:element name="custNumber" type="xsd:string"/>
      <xsd:element name="custName" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="custCreditStatustType">
    <xsd:sequence maxOccurs="unbounded">
      <xsd:element name="custNumber" type="xsd:string"/>
      <xsd:element name="status" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType> 
</xsd:schema>

This does not have targetnamespace defined. To process this, we need to create a nxsd wrapper document in the same location Schemas folder of the BPEL project.
Below is the wrapper.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
   targetNamespace="http://www.ns.example.org/customerStatus"
   xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
   nxsd:version="DTD">
   <include schemaLocation="CustomerStatus.xsd"/>
</schema>

Use the wrapper.xsd with in the wsdl as wsdl:input instead of CusotmerStatus.xsd. It is important for the original schema to have elementFormDefault = "Qualified".

reference: 6.4.4 of the document:
http://docs.oracle.com/cd/E23943_01/integration.1111/e10231/nfb.htm#TKADP1079

Delivery and Transaction properties

When we create a BPEL process from templates, we can choose three values for Delivery setting to any of the there values below.

a. Async.Persist
This is used when Reliability is more important than performance. Messages are persisted in the database.
b. Async.Cache
Incoming messages are kept only in the in-memory cache. choose this if performance is important. However if the incoming messages are more than delivered messages, the messages can be lost.

This is also not recommended for High availability as the Invoke and callback messages at the time of server crash may be lost or duplicated.
c. Sync
Direct invocation happens on the same thread. The scheduling of messages in the invoke queue is bypassed and BPEL instance is invoked synchronously.

The above property can be referred as 'OneWayDeliveryPolicy' in the deploymentdescriptor. This property is applicable only for Asynchronous and One-way services.

For Synchronous services there is Transaction property which has below three values.

a. Required: This ensures that the transaction from caller application continues. If there is no caller application new transaction starts.

b.RequiresNew: A new transaction is created and existing is suspended. This is true for one-way interface with Delivery property as

c. notSupported: This does not bother about existing transaction and enables BPEL activities to continue without maintaining transaction.

Reference: https://docs.oracle.com/middleware/1213/soasuite/develop-soa/bpel-process-creation.htm#SOASE353

 

XSLT Error

Issue: XSLT Fails with error: SOA 11g Cannot convert result tree fragment to NodeSet..
Fix : Change the version of XSL Stylesheet from 1.0 to 2.0
Reference:

http://shantanu01.blogspot.com/2010/01/oracle-bpel-esb-error-resolution.html

Bpel process not cosuming from Topic.

Issue: Bpel process which is supposed to subscribe a message and process stopped after subscribing.
       Next activity in Bpel, after subscription, did not trigger.

Cause: Admin has paused and re-started JMS Server. It worked. Dont know what happened .. :) ..

OSB-> BPEL Subscription Failing

Problem: We have a simple OSB process which publishes message to a topic. A BPEL process ,which is supposed to subscribes to it, is not subscribing.

Issue: In the business service which posts it to topic, it was publishing with message type as 'Bytes'. It should be 'text' as subscribing service in Bpel process is accepting in 'text' format. Chaging it to 'text' solved the problem.

This may be obvious but took a while to figure it out.