Oracle Fusion Interview questions - Part 1

Oracle Fusion Interview questions - Part 1

Qn. What is a wsdl? Explain its structure.
Ans. WSDL is a xml based language for describing web services and how to access them. The major elements in wsdl are.
       <types> the data types used by the WS
       <message> the messages used by the WS
       <porttype> operations performed by the WS
       <binding> the communication protocols used by the WS.
eg:-  <message name ="getTermRequest">
           <part name = "term" type ="xs:string">
        </message>
        <message name ="getTermResponse">
           <part name = "value" type ="xs:string">
        </message>
        <portType>
           <operation name ="getTerm">
            <input message = "getTermRequest"/>
            <output message = "getTermResponse"/>
           </operation>
       </portType>

Qn. What is SOA? What is a Service?
           SOA provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems.
          A service is a distinct unit of business functions.


Oracle Mediator


Qn.  Difference between SOA suite 10g and 11g?
Ans: Basically all the SOA components like BPEL, ESB (Called Mediator in 11g), & OWSM are brought into one place in 11g using SCA composite concept.
The major difference between 10g & 11g would be the app server container. 10g by default runs on OC4J while 11g runs on Weblogic Server.


Qn. What is the role of Oracle Mediator?
Ans: Oracle Mediator provides a lightweight framework to mediate between various components within a composite application. Oracle Mediator converts data to facilitate communication between different interfaces exposed by different components that are wired to build a SOA composite application.
 
Qn.What is resequencing and dynamic routing in mediator?
Ans: The resequencing feature of the Oracle Mediator reorders sets of messages that might arrive to the Oracle Mediator in the wrong sequence. You can define resequencing for all operations in an Oracle Mediator or for a specific operation.
A dynamic routing rule lets you externalize the routing logic to an Oracle Rules Dictionary, which in turn enables dynamic modification of the routing logic in a routing rule.


Qn. What is echo in Oracle Mediator?
You can also echo source messages back to the initial caller after any transformation, validations, assignments, or sequencing operations are performed. An echo can only be specified if the Oracle Mediator component has a synchronous or asynchronous interface. Whether the echo is synchronous or asynchronous depends on the WSDL file of the caller. The echo option is only available for inbound service operations and is not available for event subscriptions.

The purpose of the echo option is to expose all the Oracle Mediator functionality as a callable service without having to route it to any other service. For example, you can call an Oracle Mediator to perform a transformation, a validation, or an assignment, and then echo the Oracle Mediator back to your application without routing it anywhere else.

Qn. What is schematron validation?
Ans: You can specify Schematron files for validating an inbound message and its various parts. Schematron version 1.5 is the supported version.
Schematron is an XML schema language, and it can be used to validate XML.

Qn. Difference between OSB and Mediator?
Ans:  Mediator:

• Light weight intra composite mediation
• Domain Value mapping and Xref(cross referencing) support.
• Capability to create data type assertions in XML trees
• Message transformation using XSLT.
• Development within Jdeveloper

OSB

• Larger,more heavy weight inter composite enterprise service bus
• Serves as a logical proxy to physical services effectively providing service virtualization
• Message throttling, service pooling and reliable messaging.
• Message transformation using XQuery and XSLT.
• Eclipse or web console based development

File Adapter:-

Qn. What is file debatching?
Ans: When a file contains multiple messages, you can choose to publish messages in a specific number of batches. This is referred to as debatching. During debatching, the file reader, on restart, proceeds from where it left off in the previous run, thereby avoiding duplicate messages. File debatching is supported for files in XML and native formats.

Qn. What is sync read option in file adapter? How is it different from read?

Ans: Sync Read option in BPEL file adapter allows us to read the file from the middle of the process, this is different from the Read option which polls for the new files and is the start of the BPEL process.

As we design the file adapter for sync read it asks for the file name whcih is static, this means that only file with this given name will be read.

BPEL Activites:-

Qn. Compensate Activity

Ans: This activity invokes compensation on an inner scope activity that has successfully completed. This

activity can be invoked only from within a fault handler or another compensation handler. Compensation

occurs when a process cannot complete several operations after completing others. The process must return

and undo the previously completed operations.

Qn. Pick Activity

Ans:  This activity waits for the occurrence of one event in a set of events and performs the

activity associated with that event. The occurrence of the events is often mutually exclusive

(the process either receives an acceptance or rejection message, but not both). If multiple

events occur, the selection of the activity to perform depends on which event occurred first.

 If the events occur nearly simultaneously, there is a race and the choice of activity to be

performed is dependent on both timing and implementation.

Qn. Replay Activity

Ans: This activity enables you to reexecute the activities inside a selected scope

Name value Pair Usage in SOA

Multiple Source Transformation in BPEL

There will be many instances in your project where you will be having requirements to transform data from multiple sources into a single destination. An example scenario will be the need to do selective data enrichment (from a different source) to a collection of existing records. Currently multiple source transformations are not supported out of the box in 10g. Only single source can be mapped to single destination. As always there is a workaround for every problem. I will list down the steps for the workaround .In one of my previous blog that I had written on Payload splitting using XSL uses similar steps.

There is a pre-requisite for this, a schema. In case you are using AIA below is the location

<xsd:import namespace="http://schemas.oracle.com/service/bpel/common" schemaLocation="http://<hostname>:<port>/AIAComponents/UtilityArtifacts/bpel-common.xsd" />

Or else you have create your own custom XSD

Code Snippet :: Custom schema - Param.xsd

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:p="http://schemas.oracle.com/service/bpel/common"

xmlns="http://schemas.oracle.com/service/bpel/common"

targetNamespace="http://schemas.oracle.com/service/bpel/common"

elementFormDefault="qualified">

<xsd:element name="parameters">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="item" minOccurs="1" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="name" type="xsd:string"/>

<xsd:element name="value" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

1. Initialization

Create a Variable Params which should be of type parameters(Refer Param.xsd)

2. Assign XML fragment mentioned below to the parameters

Code Snippet :: XML fragment in Assign

<assign name="AssignXMLFragment">

<copy>

<from>

<common:parameters xmlns:common="http://schemas.oracle.com/service/bpel/common">

<common:item>

<common:name>InputDataFromSource2</common:name>

<common:value/>

</common:item>

</common:parameters>

</from>

<to variable="Params" query="/common:parameters"/>

</copy>

</assign>

3. Read the data from second source using a ora:getContentAsString() function into the InputDataFromSource2 parameter

Code Snippet :: Assign in .bpel file

<assign name="AssignDataFromSource2To Params">

<copy>

<from expression="ora:getContentAsString(bpws:getVariableData('InputSource2Msg','InputParameters','/ns12: InputParameters'))"/>

<to variable="Params" query="/common:parameters/common:item[common:name=' InputDataFromSource2']/common:value"/>

</copy>

</assign>

4. Now we will use transformations leveraging the feature of Passing Parameters into XSLT. We will pass the data in Params variable as the 3^rd parameter so that it can be accessed in the XSL

Code Snippet :: Assign in .bpel file

<assign name="MultipleSourceTransformation">

<copy>

<from expression="ora:processXSLT('Xform_From_Two_Sources.xsl',bpws:getVariableData('inputVariable','TestInABM','/ns8:'TestABM'),bpws:getVariableData('Params'))"/>

<to variable="outputVariable" part="TestOutABM”/>

</copy>

</assign>

5. Inside the XSL we will be accessing the Param data using xsl:param tag . The entire data will be available in the InputDataFromSource2 parameter. We will use orcl:parseEscapedXML function to convert the string data into proper XML format.

Code Snippet :: .xsl file

<xsl:stylesheet>

………………………………

…………………………………

<xsl:param name="InputDataFromSource2">

<xsl:text disable-output-escaping="yes"><test:InputSource2Msg

xmlns:test="http://xmlns.geo.com/test/"/></xsl:text>

</xsl:param>

<xsl:variable name="Source2Data"

select="orcl:parseEscapedXML($InputDataFromSource2)"/>

6. After step 5 the data in XML format will be available in Source2Data variable which can be used as any other variable definition and all child elements can be accessed using this variable.

Code Snippet :: .xsl file

…………………………………

<geo:FirstName>

<xsl:value-of select=”$Source2Data /test:inputData/test:First_Name"/>

</geo: FirstName >

That’s it.. Compile and deploy. You will be able to access the data from different sources in same XSL.

CorellationSet in SOA 11g

https://plus.google.com/photos/105829056368720567005/albums/5464695333166405041?banner=pwa&sqi&sqsi

SOA Suite 11g: Coordination between two BPEL processes

While scanning the FMW 11g SOA Suite developer guide, I noticed the feature that enables coordination between master and detail BPEL processes by using so- called signals.

As far as I know, this feature is introduced in 11g and is very useful in situations where a parent process has to control the processing of the child processes. And, vice versa, where child processes has to notify their parent process when a specific task is completed. Most of the time a signal is enough and no additional information has to be sent along. Therefore, for example, a BPEL invoke activity with correlation might be a bit too complex for this purpose.

Ok how does it work? The tutorial gives you a clear explanation how to use signaling in Oracle BPEL so I will describe the rough details about how you can use signaling and also some limitations that I discovered while praticing with this feature.

How-to

1. Create a BPEL master detail proces in the composite.
• Use the process type asynchronous for the master process and the the type one-way for the detail
  
2. Add an Invoke activity to the master process to invoke the detail process
• Open the source view of the BPEL editor and add the following property to the invoke activity:
  
  

  bpelx:invokeAsDetail="true"

  
  
3. Add a Wait activity to the master process for demo purposes
   
4. Add a Signal activity to the master process
• Remember the Label value
• Set the To value to details
5.  Add a Receive Signal activity to the master process
• Remember the Label value
• Set the From value to details
6.  Add a Receive Signal activity to the detail process
• Use the Label value used in step 4
  
• Set the From value to master
7. Add a Wait activity to the detail process for demo purposes 
8. Add a Signal activity to the detail process
• Use the Label value used in step 5
• Set the To value to master
9. You're done! Deploy the composite to the server and test your composite.

The signaling feature also supports correlation to correlate signals between the master and different detail process types. It seems that correlation of signals between different composite master/detail instances are correlated automagically.

Unfortunately, the coordination functionality has some limitations:

• Labels can not be set dynamically using XPath
• Correlation labels can not be set dynamically using XPath
  
• Only a single signal pair (signal/receive signal) can be used for a unique label

These limitations make it, for example, not possible to coordinate by using signals between a master and multiple detail instances of the same BPEL process type which are invoked in parallel or even sequential..

Oh..I still have to figure out how signaling is implemented 'under the hood'.. However, happy signaling...

The Difference Between RPC and Document Style WSDL

Summary

RPC style and document style are catchphrases frequently heard in the context of web services and the SOAP protocol. What exactly do they mean? How do they relate to the pair of terms "encoded/literal"? Where does the confusion about these terms come from? This article describes the WSDL binding style and use attributes.

By Susanne Rothaug
20 Nov 2004

Binding Style and Use

A web service is usually described by a WSDL (Web Services Description Language) document. In this document, the supported web service operations and messages are described abstractly and then bound to a concrete network protocol and message format. A typical WSDL document consists of the following elements: "types," "message," and "portType" for the abstract definitions; "binding" and "service" for the concrete specification. All of these elements are wrapped inside a "definitions" element.

In the context of RPC and document style, it is the binding element that we need to take a closer look at. A WSDL binding describes how the service is bound to a messaging protocol, either HTTP GET/POST, MIME, or SOAP. In practice, SOAP is the most universally used protocol; it is SOAP that the RPC/document distinction refers to. Usually HTTP(S) is used as transport protocol for the SOAP message – "SOAP over HTTP(S)."

The <wsdl:binding> element of the WSDL contains a pair of parameters that influence the form of the resulting SOAP messages: binding style (RPC or document) and use (encoded or literal). See how style and use are defined in the WSDL fragment below:

<wsdl:binding name="Config1Binding" type="prt0:CreditLimitLocalWebServiceVi_Document">

    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> 

    <wsdl:operation name="creditLimitCheck">

        <soap:operation soapAction="" /> 

        <wsdl:input>

            <soap:body use="literal" parts="parameters" /> 

        </wsdl:input>

        <wsdl:output>

            <soap:body use="literal" /> 

        </wsdl:output>

  </wsdl:operation>

 </wsdl:binding>

The "Style" Attribute

WSDL 1.1 specifies the style of the binding as either RPC or document. This choice corresponds to how the SOAP payload - i.e., how the contents of the <soap:Body> element - can be structured. Here are some details of how each style affects the contents of <soap:Body>:

• Document: the content of <soap:Body> is specified by XML Schema defined in the <wsdl:type> section. It does not need to follow specific SOAP conventions. In short, the SOAP message is sent as one "document" in the <soap:Body> element without additional formatting rules having to be considered. Document style is the default choice.
• RPC: The structure of an RPC style <soap:Body> element needs to comply with the rules specified in detail in Section 7 of the SOAP 1.1 specification. According to these rules, <soap:Body> may contain only one element that is named after the operation, and all parameters must be represented as sub-elements of this wrapper element.

As a consequence of the freedom of choice that the document style offers, the SOAP messages conforming to a document style WSDL may look exactly the same as the RPC equivalent.

The decisive question now is: What are the consequences of choosing one option or another? Why choose RPC over document, or document over RPC? In many cases, the SOAP messages generated from either RPC or document style WSDLs look exactly the same - so why offer the choice at all? The reason may be found in the history of the SOAP standard.

SOAP has its roots in synchronous remote procedure calls over HTTP and the appearance of the document accordingly followed these conventions. Later, it was seen as a simplification to use arbitrary XML in the SOAP body without adhering to conventions. This preference is reflected in the document style WSDL documents. So far, both options are represented in the WSDL specification and the choice of one or the other is mainly a question of personal taste since most SOAP clients today accept both versions.

The "Use" Attribute

The use attribute specifies the encoding rules of the SOAP message. This is also done within the <wsdl:binding> element, as seen in the example above. The value can be encoded or literal. It refers to the serialization rules followed by the SOAP client and the SOAP server to interpret the contents of the <Body> element in the SOAP payload.

• use="literal" means that the type definitions literally follow an XML schema definition.
• use="encoded" refers to the representation of application data in XML, usually according to the SOAP encoding rules of the SOAP 1.1 specification. The rules to encode and interpret a SOAP body are in a URL specified by the encodingStyle attribute. Encoded is the appropriate choice where non-treelike structures are concerned, because all others can be perfectly described in XML Schema.

The combination of the style and use attributes leads to four possible style/use pairs:

1. RPC/encoded
2. RPC/literal
3. document/encoded
4. document/literal

Some of these combinations are rarely used in practice, such as document/encoded. In general, the literal use is gaining importance, and as far as RPC/encoded is concerned, the Web Services Interoperability Organization (WS-I) in its Basic Profile Version 1.0a of August 2003 ruled out the use of SOAP encoding with web services. Document/literal and RPC/literal will be the only allowed style/use combinations in the future.

Exception handling in SOA Suite 10g and SOA Suite 11g

Introduction

Sometimes, the longer you think about how to solve a problem, the less complex the solution becomes. Error handling in SOA Suite 11g is one of those examples. It is tempting to implement an own mechanism for exception/error handling (for example http://javaoraclesoa.blogspot.com/2012/05/re-enqueueing-faulted-bpel-messages.html), although there already is an extensive fault management framework part of the SOA Suite. In this post I describe the method used in SOA Suite 10g to implement fault-policies using a custom Java class. I implement a similar exception handling mechanism in Oracle SOA Suite 11g.

Marcel Bellinga has provided most code in the below example.

Challenges to tackle

Some of the challenges involved when implementing exception handling;
- how do I make it easy for the people monitoring and maintaining the application to detect and recover from errors?
- how do I make sure no messages are lost?
- how do I make sure the order in which messages are offered to the application, does not change when exceptions occur?
- how do I prevent 'hammering' a system (continuously retrying faulted messages)

With these questions in mind, the following solution provides a good option.

A bit of background

Oracle BPEL 10g has the option to use fault-policies and fault-bindings (and use custom Java classes in the policies), which are put on the application server and referred to by a bpel process in the bpel.xml. See; http://docs.oracle.com/cd/E14101_01/doc.1013/e15342/bpelrn.htm#BABCHCED.

Oracle SOA Suite 11g has (in addition to the method described above) the option to deploy custom Java classes, fault-policies and fault-bindings as part of the composite to the application server. This mechanism makes it easier to use the fault management framework on a per-composite basis. See http://docs.oracle.com/cd/E12839_01/integration.1111/e10224/bp_faults.htm

Keep in mind, when using the fault management framework that the fault-policies get triggered before a catch branch as defined in a BPEL process. If you want the catch branch to be activated, the action to rethrow the fault, needs to be part of the policy.

Solution in short

The solution for handling faults while taking into account the above questions, will use the following method;
- in Oracle BPEL 10g, a custom Java class and a specific policy xml-file is deployed on the application server
- the bpel.xml file will refer to the policy defined in the specific policy XML file
- the custom Java class will first deactivate the activation agents of the process and then retire the process (avoiding the issue that messages are picked up while the process is already retired causing loss of messages)
- the faulted message is put in manual recovery mode so the error hospital can be used to recover (retry) the message after the problem is fixed
- if the problem is fixed, the process can be activated again
- the ORABPEL schema tables can be monitored for messages which can be recovered or to trigger someone something has gone wrong and a recovery action is required

In Oracle SOA Suite 11g the method is similar, however, the activation agents do not need to be deactivated explicitly, the API calls are a bit different (due to the SCA implementation) and the error handling is deployed as part of the composite (in this example, see http://mazanatti.info/index.php?/archives/75-SOA-Fault-Framework-Creating-and-using-a-Java-action-fault-policy.html for an example on how to deploy custom Java code centrally on the server).

Implementation

Implementation BPEL 10g exception handling

Custom Java action

Create a new Java project and include the orabpel.jar from your BPEL distribution in the root folder of your project. Update the project libraries to include the library.

Create a new Java class. I've used the following;

package testapi;

import com.oracle.bpel.client.BPELProcessMetaData;
import com.oracle.bpel.client.IBPELProcessConstants;
import com.oracle.bpel.client.IBPELProcessHandle;
import com.oracle.bpel.client.Locator;
import com.oracle.bpel.client.config.faultpolicy.IFaultRecoveryContext;
import com.oracle.bpel.client.config.faultpolicy.IFaultRecoveryJavaClass;

public class RetireProcess implements IFaultRecoveryJavaClass {
    public RetireProcess() {
    }

    /**     * This method is called by the BPEL Error Hospital framework when this    
     * * action is selected as retrySuccessAction (with the retry option) or    
     * * when this action is selected as successor in the human intervention    
     * * screen in the BPEL Console.     *     
     * * @param iFaultRecoveryContext     */
    public void handleRetrySuccess(IFaultRecoveryContext iFaultRecoveryContext) {
        System.out.println("RetireProcess RetrySucces start");
        setLifeCycle(iFaultRecoveryContext,
                     IBPELProcessConstants.LIFECYCLE_ACTIVE);
        System.out.println("RetireProcess RetrySucces einde");
    }

    /**     * This method is called by the BPEL Error Hospital framework when this    
     * * class is configured as action in the fault handling policy     *     
     * * @param iFaultRecoveryContext   
     * * @return String that can be used to influence choice for next action (not used in this case)     */
    public String handleBPELFault(IFaultRecoveryContext iFaultRecoveryContext) {
        System.out.println("RetireProcess HandleFault start");
        setLifeCycle(iFaultRecoveryContext,
                     IBPELProcessConstants.LIFECYCLE_RETIRED);
        System.out.println("RetireProcess HandleFault Einde");
        return null;
    }

    private void setLifeCycle(IFaultRecoveryContext iFaultRecoveryContext,
                              int status) {
        IBPELProcessHandle procHandle = null;
        Locator loc = null;
        BPELProcessMetaData bpelProcessMetadata = null;
        String processName;
        String revision;

        try {
            processName = iFaultRecoveryContext.getProcessId().getProcessId();
            revision = iFaultRecoveryContext.getProcessId().getRevisionTag();
            /*
                 * get Locator Instance
                */
            loc = iFaultRecoveryContext.getLocator();
            /*
                 * Lookup Process. Revision optional.
                */
            if (revision == null || revision.trim().equals("")) {
                procHandle = loc.lookupProcess(processName);
            } else {
                procHandle = loc.lookupProcess(processName, revision);
            }
            if (procHandle == null) {
                throw new Exception("Unable to find process: " + processName);
            }

            System.out.println("RetireProcess set lifecycle to retired");
            /*
                 * Get Metadata of the process.
                */
            bpelProcessMetadata = procHandle.getMetaData();
            if (bpelProcessMetadata.getLifecycle() != status) {
                /*
                 * Set Lifecycle to Retired.
                 * Use setState(IBPELProcessConstants.STATE_OFF) to change process state to off.
                 */
                bpelProcessMetadata.setLifecycle(status);
                System.out.println("RetireProcess Lifecycle set to retired");

                /*
                 * Stop activation agents
                 */
                if (status == IBPELProcessConstants.LIFECYCLE_RETIRED) {
                    procHandle.stopAllActivationAgents();
                } else {
                    procHandle.startAllActivationAgents();
                    ;
                }
                /*
                 * Finally update the process with the modified metadata.
                 */
                procHandle.updateMetaData(bpelProcessMetadata);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}


Noteworthy here are the method to retire the process; obtain a locator, use the locator to get a processhandle, use the processhandle to get to the metadata, update the metadata. The processhandle can also be used to stop the activation agents. Compile the project using JDK 1.5.0.06.

Place this class in;
[ORACLE_HOME]/bpel/system/classes/

Fault policy and fault binding

Create a fault policy like for example

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicy version="2.0.1" id="RetireProcessPolicy" 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">
    <!-- This section describes fault conditions. Build more conditions with faultName, test and action -->
    <Conditions>
        <!-- Fault ALL -->
        <faultName>
            <condition>
                <action ref="RetireProcess"/>
            </condition>
        </faultName>
    </Conditions>
    <Actions>
        <!-- This action will attempt 8 retries at increasing intervals of 2, 4, 8, 16, 32, 64, 128, and 256 seconds. -->
        <Action id="ora-retry">
            <retry>
                <retryCount>8</retryCount>
                <retryInterval>2</retryInterval>
                <retryFailureAction ref="ora-terminate"/>
                <exponentialBackoff/>
            </retry>
        </Action>
        <!-- This is an action will cause a replay scope fault-->
        <Action id="ora-replay-scope">
            <replayScope/>
        </Action>
        <!-- This is an action will bubble up the fault-->
        <Action id="ora-rethrow-fault">
            <rethrowFault/>
        </Action>
        <!-- This is an action will mark the work item to be "pending recovery from console"-->
        <Action id="ora-human-intervention">
            <humanIntervention/>
        </Action>
        <!-- This action will cause the instance to terminate-->
        <Action id="ora-terminate">
            <abort/>
        </Action>
        <Action id="RetireProcess">
            <javaAction className="testapi.RetireProcess" defaultAction="ora-human-intervention"/>
        </Action>
    </Actions>
</faultPolicy>

Place the fault policy in
[ORACLE_HOME}/bpel/domains/{domain}/config/fault-policies

Create a reference to the faultpolicy in the bpel.xml of the process like;
(below </activationAgents>)
     <faultPolicyBindings>
         <process faultPolicy="RetireProcessPolicy"/>
         <partnerLink faultPolicy="RetireProcessPolicy"/>
      </faultPolicyBindings>

Noteworthy in this policy is the defaultAction. My custom Java class returns null. This triggers the defaultAction which is set to ora-human-intervention. This causes the invoke to be visible in the error hospital (Activities tab in the process manager). From the error hospital it is also possible to specify an on retry success method to be executed (by clicking the specific error).

Result

When an error occurs, the failed messages arrive (in order) in the error hospital (usually a small number before the process is retired). The process instances which have faulted, remain open. The process is retired. You can retry the activities to check whether the error is fixed. In the error is fixed, the process can be activated again resuming normal action. This way the order of messages is guaranteed, there is no useless hammering and retrying the action which has failed. The process can be activated when the problem is fixed avoiding a lot of manual re-offering of messages.

Implementation BPEL 11g Exception handling

The 11g implementation is very similar to the 10g implementation. Deployment does not require any server side configuration. You can download the example project here; http://dl.dropbox.com/u/6693935/blog/TestExceptionHandling.zip. If you encounter errors deploying the project, you should remove the MDS entry in .adf\META-INF\adf-config.xml causing the issue. The example project requires the setup as described in; http://javaoraclesoa.blogspot.com/2012/05/re-enqueueing-faulted-bpel-messages.html. Also mind that when importing the project, your MDS configuration might differ. Remove the entries not relevant for your configuration from the .adf/META-INF/adf-config.xml file.

Custom Java class


I've used the following Java class (created in SCA-INF/src). No additional project configuration (like including libraries) is required in 11g.


package ms.testapp.exceptionhandling;
import com.collaxa.cube.engine.fp.BPELFaultRecoveryContextImpl;
import java.util.logging.Logger;
import oracle.integration.platform.faultpolicy.IFaultRecoveryContext;
import oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass;
import oracle.soa.management.facade.Composite;
import oracle.soa.management.facade.Locator;
import oracle.soa.management.facade.LocatorFactory;
public class RetireProcess implements IFaultRecoveryJavaClass {
    private final static Logger logger = Logger.getLogger(RetireProcess.class.getName());
    public RetireProcess() {
        super();
    }
    public void handleRetrySuccess(IFaultRecoveryContext iFaultRecoveryContext) {
    }
    public String handleFault(IFaultRecoveryContext iFaultRecoveryContext) {
            System.out.println("handleFault started");
            BPELFaultRecoveryContextImpl bpelCtx =
                (BPELFaultRecoveryContextImpl)iFaultRecoveryContext;
        try{
            Locator loc = LocatorFactory.createLocator();
            System.out.println("locator obtained");
            Composite comp = loc.lookupComposite(bpelCtx.getProcessDN().getCompositeDN());
            System.out.println("compisite found");
            comp.retire();
            //bpelCtx.addAuditTrailEntry("retired " + comp.getDN());
            System.out.println("process retired");
            logger.info("retired " + comp.getDN());
        } catch (Exception e) {
            System.out.println("fault in handler");
            //bpelCtx.addAuditTrailEntry("Error in FaultHandler " + RetireProcess.class.getName());
            logger.severe("Error in FaultHandler " + RetireProcess.class.getName());
            e.printStackTrace();
        }
        return null;
        }
}

Fault policy and fault binding

My fault-policy file is called fault-policies.xml (the composite.xml picks that file by default but a different file can be specified in the composite.xml file if required) and it looks like;

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <faultPolicy version="2.1.3" id="ConnectionFaults">
    <Conditions>
      <faultName>
        <condition>
          <action ref="handle-fault-through-custom-java"/>
        </condition>
      </faultName>
    </Conditions>
    <Actions>
      <Action id="handle-fault-through-custom-java">
        <javaAction className="ms.testapp.exceptionhandling.RetireProcess"
                    defaultAction="ora-human-intervention">
        </javaAction>
      </Action>
      <Action id="ora-rethrow-fault">
        <rethrowFault/>
      </Action>
<Action id="ora-human-intervention">
 <humanIntervention/></Action>
    </Actions>
  </faultPolicy>
</faultPolicies>

My fault-bindings.xml looks like;


<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1"
                     xmlns="http://schemas.oracle.com/bpel/faultpolicy"
                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite  faultPolicy="ConnectionFaults"/>
</faultPolicyBindings>


These files are placed in the same folder as the composite.xml.

Result

The behavior in 11g is similar to the behavior described in 10g in both examples. One thing to notice is that the API works on composite level and I've not found a way to directly stop of start the activation agents. I did however not encounter the 10g error that the JCA adapter tried to start a retired process.
First the correct situation. Use the testscript to enqueue a message.

DECLARE
  queue_options DBMS_AQ.ENQUEUE_OPTIONS_T;
  message_properties DBMS_AQ.MESSAGE_PROPERTIES_T;
  recipients          DBMS_AQ.aq$_recipient_list_t;
  message_id RAW(16);
  message SYS.XMLType;
BEGIN
  recipients(1) := sys.aq$_agent('EXCEPTIONTEST', NULL, NULL);
  message_properties.recipient_list := recipients;
  message := sys.XMLType.createXML('<itemCollectionArray xmlns:msg_out="http://test.ms/itemcollections" xmlns="http://test.ms/itemcollections"><msg_out:itemsCollection><msg_out:item><msg_out:name>Name</msg_out:name><msg_out:value>Piet</msg_out:value></msg_out:item></msg_out:itemsCollection></itemCollectionArray>');
  DBMS_AQ.ENQUEUE( queue_name => 'TESTUSER.TEST_SOURCE_QUEUE',
                   enqueue_options => queue_options,
                   message_properties => message_properties,
                   payload => message,
                   msgid => message_id);
  COMMIT;
END;

The result is a correct execution of the process;

Next disable the TEST_TARGET_QUEUE

Again submit a test message and confirm the error handler has activated in the Enterprise Manager.

Conclusion

Error handling in SOA Suite 11g is more extensive (has more options) then error handling in SOA Suite 10g. Also SOA Suite 11g provides options for implementing fault handling on a per process basis. This was absent in SOA Suite 10g. For accessing the API, there have been many changes going from 10g to 11g. The most significant changes have been caused by the implementation of the SCA framework. SOA Suite 11g makes it a lot easier to use the Java API.

Also a lesson learned is to think about error handling very early on in a project and not start with the implementation which seems logical to a single developer but discuss the different options and requirements with the customer and other developers. In this case a relatively simple solution using standard Oracle functionality causes many requirements to be met. However if the purpose is to make as many hours as possible and tackling every requirement as a new change, then this solution is not for you!

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:BPEL Properties Set Inside a Composite

Oracle SOA 11g 11. 1.1.6 Performance Tuning of BPEL Processes

BPEL Properties Set Inside a Composite

This section lists the config properties of some sections of the deployment descriptor. For each configuration property parameter, a description is given, as well as the expected behavior of the engine when it is changed.

All the properties set in this section affect the behavior of the component containing the BPEL process only. Each BPEL process can be created as a component of a composite. These properties can be modified in composite.xml or in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control. 

Some Concepts First

As a general practice, it is better to design your BPEL processes as transient instead of durable if performance is a concern. Note that this may not always be possible due to the nature of your process, but keep the following points in mind.

The dehydration store is uses to maintain long-running asynchronous BPEL instances storing state information as they wait for asynchronous callbacks. This ensures the reliability of these processes in the event of server or network loss. Oracle BPEL Process Manager supports two types of processes; transient and durable.

Transient Processes

Transient processes do not incur dehydration during their process execution. If an executing process experiences an unhandled fault or the server crashes, instances of a transient process do not leave a trace in the system. Thus, these instances cannot be saved in-flight regardless if they complete normally or abnormally. Transient processes are typically short-lived, request-response style processes. Synchronous processes are examples of transient processes.

Durable Processes

Durable processes incur one or more dehydration points in the database during execution. Dehydration is triggered by one of the following activities:

• Receive activity
• OnMessage branch in a pick activity
• OnAlarm branch in a pick activity
• Wait activity
• Reply activity
• checkPoint() within a <bpelx:exec> activity

 inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.
Values:
This property has the following values:

• False (default): instances are persisted completely and recorded in the dehydration store database.
• True: The completionPersist policy is used to determine persistence behavior. 

completionPersistPolicy

This property configures how the instance data is saved. It can only be set at the BPEL component level. The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).

Value	Description
On (default)	The completed instance is saved normally
Deferred	The completed instance is saved, but with a different thread and in another transaction.
Faulted	Only the faulted instances are saved. Note: When an unhandled fault occurs, regardless of these flags, audit information of the instance is persisted within cube_instance table.
Off	No instances of this process are saved.

<component name="BPELProcess">
   <implementation.bpel src="BPELProcess.bpel" />

   <property name="bpel.config.completionPersistPolicy">faulted</property>
   <property name="bpel.config.inMemoryOptimization">true</property>
   ...
</component>

auditLevel

You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels.

Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project as shown in the example below:

<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

Partner Link Property

You can dynamically configure a partner link at runtime in BPEL. This is useful for scenarios in which the target service that BPEL wants to invoke is not known until runtime. The following Partner Link properties can be tuned for performance:

idempotent

An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). Oracle BPEL Server saves the instance after a nonidempotent activity. This property is applicable to both durable and transient processes.

Values:

This property has the following values:

• False: Activity is dehydrated immediately after execution and recorded in the dehydration store. When idempotent is set to False, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently.
• True (default): If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed. Some examples of where this property can be set to True are: read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.

A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.

If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.

When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.

nonBlockingInvoke

By default, Oracle BPEL Process Manager executes in a single thread by executing the branches sequentially instead of in parallel. When this property is set to True, the process manager creates a new thread to perform each branch's invoke activity in parallel. This property is applicable to both durable and transient processes.

Consider setting this property to True if you have invoke activities in multiple flow or flow n branches. This is especially effective if the parallel invoke activities are two-way, but some benefits can be realized for parallel one-way invokes as well.

Note:

Invocations to the same partner link will happen in sequence and not in parallel. If you invoke different partner links each time with nonBlockingInvoke set to True, then each link will work in parallel even if all of the partner links point to the same source.

Values:

• True: Oracle BPEL Server spawns a new thread to execute the invocation.
• False (default): Oracle BPEL Server executes the invoke activity in the single process thread.

validateXML

Enables message boundary validation. Note that additional validation can impact performance by consuming extra CPU and memory resources.

Values:

• True: When set to True the engine validates the XML message against the XML schema during <receive> and <invoke> for this partner link. If the XML message is invalid thenbpelx:invalidVariables run time BPEL Fault is thrown. This overrides the domain level validateXML property.
• False (default): Disables XML validation.

General Recommendations:

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicyto faulted, So that we can get better throughput, only faulted instances gets dehydrated in the database, its goes easy on the purge (purging historical instance data from database)

2. Do not include any settings to persist your process such as (Dehydrate, mid process receive, wait or Onmessage)

3. Have good logging on your BPEL Process, so that you can see log messages in the diagnostic log files for troubleshooting.

What should you do?

• If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
• If the design of the process allows it, avoid the activities listed above.

Any time your process is dehydrated to the dehydration store, this naturally impacts the performance of the process, and becomes a concern particularly in high volume environments.