Interview Q&A 1

SOA Interview Question & Answers

 How fault can be handled without using catch & throw?

Ans.  Oracle SOA Suite provides a generic fault management framework for handling faults in BPEL processes. If a fault occurs during runtime in an invoke activity in a process, the framework catches the fault and performs a user-specified action defined in a fault policy file associated with the activity.

This section provides an overview of the components that comprise the fault management framework.

·  The fault management framework catches all faults (business and runtime) for an invoke activity.
·  A fault policy file defines fault conditions and their corresponding fault recovery actions. Each fault condition specifies a particular fault or group of faults, which it attempts to handle, and the corresponding action for it. A set of actions is identified by an ID in the fault policy file.
·  A set of conditions invokes an action (known as fault policy).
·  A fault policy bindings file associates the policies defined in the fault policy file with the following:

·         SOA composite applications

·         BPEL process and Oracle Mediator service components

·         Reference binding components for BPEL process and Oracle Mediator service components

The framework looks for fault policy bindings in the same directory as the composite.xml file of the SOA composite application or in a remote location identified by two properties that you set.

Note:

A fault policy configured with the fault management framework overrides any fault handling defined in catch activities of scope activities in the BPEL process. The fault management framework can be configured to rethrow the fault handling back to the catch activities.
·  The fault policy file (fault-policies.xml) and fault policy bindings file (fault-bindings.xml) are placed in either of the following locations:

·         In the same directory as the composite.xml file of the SOA composite application.

·         In a different location that is specified with two properties that you add to the composite.xml file.

2.       How to manage fault?

Ans.  The purpose of the Fault Management Framework is to provide error handling that is external to SOA and does not impact the SOA/BPEL design or runtime. The framework is implemented using policies defined in XML. These policies are reusable across composites/components and can catch both runtime and business faults. Once a fault is caught, the policy defines actions that can be used for the SOA instance such as retry, human intervention, replay scope, rethrow fault, abort, and custom Java actions. When human intervention comes into play, the Enterprise Manager provides a GUI for managing the faulted instance.

The fault policy files are loaded at startup, so when any changes are made to them a server restart is required.  The location for the fault policy files can be in the same directory as the composite.xml or in a location identified by a property in the composite.xml:

<property name="oracle.composite.faultPolicyFile">
   oramds:/apps/faultpolicyfiles/fault-policies.xml
</property>

<property name="oracle.composite.faultBindingFile">
   oramds:/apps/faultpolicyfiles/fault-bindings.xml
</property>

3.      

      How can more than one operation call from BPEL? Operation means Update, Select, Insert, delete.

Ans. Pick Activity.

4.      

     How to develop BAM Reports?

Ans.

1. Create Data Object (Exp. Student) Using BAM Architect
2. Create BAM Report Using BAM Active Studio
3. Configure BAM Adapter Using Weblogic Server Administration Console
4. Create BPEL Sensor Activity and Sensor Action Using Jdeveloper.

For more information http://www.orafmwschool.com/bam-tutorial/

5.      What is resequence 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 defineresequencing for all operations in an Oracle Mediator or for a specific operation.

6.       What is Transit & Durable BPEL?

Ans. 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

Durable processes are typically long-living and initiated through a one-way invocation. Because of out-of-memory and system downtime issues, durable processes cannot be memory-optimized.

7.       What is fault-policy? When it is called?

Ans. Oracle SOA Suite gives us an option of configuring fault and fault actions using policies. This means that we can create policies in response to a specific type of exception. Policies are defined in a file that by default is called fault-policies.xml

Policies for fault handling consist of two main elements:

1. The fault condition that activates the policy block—we specify what type of fault(s) the policy is relevant for. We can then apply even more finer grained policy and actions based on error codes, error messages etc.
2. The action(s) that should be performed when the condition is satisfied. An action for an fault may be to retry it for a certain number of time at a specified interval, or to mark it in recovery for human intervention, use a custom Java code or simply to throw the fault back. If the fault is rethrown then if we have specified any explicit ‘catch’ block in our BPEL process that will be executed.

We can keep these files either local to project or in MDS and in both the cases we have to specify the path in composite.xml file.

BPEL Timeout
Ans.How to configure BPEL timeout? I have changed the JTA timeout to 7200 seconds but my processes are still timing out after 300 seconds. Where else can we configure the timeout for Bpel processes?

syncMaxWaitTime < (BPEL) EJB's Timeout < global transaction timeout (JTA) < session timeout < distributed_lock_timeout

The following settings seem mostly used for SOA:
syncMaxWaitTime = 120 (default 45)
The EJB timeouts should not be touched. (default 300)
JTA = 360 (default 30)

There is a remark on the following link that says if transactions always timeout beyond the default 30 seconds, you may need to revisit the design approach: http://docs.oracle.com/cd/E15586_01/fusionapps.1111/e14496/soa_trouble.htm

In general the JTA value 30 or 360 is arbitrary. The goal is find optimal value for JTA timeout so that the user will see no / very few JTA timeout exceptions in a day. My customer actually has these values much higher (1 hour) because of the nature of some legacy systems in the backend.

It could be the syncMaxWaitTime property: "The maximum time a request and response operation takes before timing out". See chapter 7.3 in the Oracle Fusion Middleware
Developer’s Guide for Oracle SOA Suite 11g Release 1 at http://docs.oracle.com/cd/E28280_01/dev.1111/e10224.pdf