Archive for May, 2013

Auto Recovery BPEL Use Case

Published May 13, 2013 BPEL 1 Comment
Tags: , ,

Having seen ‘Auto Recovery’ feature in previous post, I tried the following use case to observe the behavior as we have some BPEL processes that follow this pattern. An asynchronous BPEL process (BPELA) calls synchronous BPEL (BPELB) having mid dehydration point and both of these BPEL processes don’t have the fault handlers.

BPELA:

BPEL A

BPELB:

bpel b

Flow Trace:

flow trace

If we observe, the auto recovery is happening for Sync BPEL from dehydration point and also the entire flow. This is because of the fault is not caught either in caller or calle which was propagated to runtime. One should be careful about such scenario if we are relying on auto recovery. This can be avoided by using reply activity to send the fault from sync process back to caller.

Advertisement

Database Polling in OSB – Part IV

Published May 13, 2013 OSB Leave a Comment
Tags: , , ,

In this final post of this series, we will look at remaining polling strategies in ACTION from OSB perspective. Based on my past experience, I would say these are the less frequent used polling strategies (Of course, you should not consider this as granted though).

All 3 strategies highlighted in the below screenshot are based on simple principle and can be used if we have any running sequence or date in the source table. Every time the row gets updated/inserted a new running sequence or date used in the respective table column.

poll strats. Once the polling is done, this running sequence can be stored external to the source table. So next time, when the polling happens it will be always that running sequence column value > stored value.

The only difference in these strategies is where we store the value that is used for polling query. In ‘Update a Sequence Table’ polling strategy, we use external table in same DB to store the value .  In ‘Update an External Sequencing Table on a different Database’ polling strategy, we use external table in different database altogether. We can have a single global table that can be used for this purpose. In ‘Update a Sequencing File’ polling strategy, we use the a file in server file system to store the value rather than DB tables. This file will reside in SOA server file system.

For this post also, the use case remains same where we migrate the data from SI_EMPLOYEE (source table) to SI_EMPLOYEE_COPY (target table). I will demonstrate using only one of these strategies as all 3 are similar. We will use EMPLOYEE_ID column as the sequence i.e. every time we insert a sequence value in this column every time we insert a new record (it does not make sense for the update scenario, then we can add update_date as the column and follow this strategy).

Create a new table to store running sequence with following table definition

CREATE TABLE SI_POLL_TAB(TABLE_NAME VARCHAR2(30), SEQ NUMBER);

Create DB adapter files in JDeveloper by selecting the polling strategy ‘Update a Sequence Table’ as shown above. Click on Next and enter the values as shown below.

Seq Table

Click on Next, observe Polling SQL and After Read SQL statements.

poll sql

Finish the DB adapter wizard, import the related files into OSB project and create a proxy service from the JCA file and complete the message flow to route the polled data to business service.

proxyservice

Now deploy configuration jar to OSB server and also disable all other proxy services polling on same DB table. Now do the insertion of a single row with using the following statement.

insert into si_employee(EMPLOYEE_ID, FIRST_NAME, LAST_NAME,EMAIL, PHONE_NUMBER,HIRE_DATE,JOB_ID,SALARY,COMMISSION_PCT, MANAGER_ID)
select EMPLOYEE_ID,FIRST_NAME,LAST_NAME,EMAIL,PHONE_NUMBER, HIRE_DATE, JOB_ID,SALARY,COMMISSION_PCT,MANAGER_ID
from employees where employee_id = 100

After polling interval, verify that target table is populated this row along with SI_POLL_TAB.

insertion1 

poll tab

Repeat this by inserting more number of records.

insert into si_employee(EMPLOYEE_ID, FIRST_NAME, LAST_NAME,EMAIL, PHONE_NUMBER,HIRE_DATE,JOB_ID,SALARY,COMMISSION_PCT, MANAGER_ID)
select EMPLOYEE_ID,FIRST_NAME,LAST_NAME,EMAIL,PHONE_NUMBER, HIRE_DATE, JOB_ID,SALARY,COMMISSION_PCT,MANAGER_ID
from employees where employee_id between 101 and 105;

insertion2

poll tab1

In case of ‘Update an External Sequencing Table on a different Database’, we also have to specify Data Source to connect to an external table in different DB as shown below. Except this, everything remains same as  discussed above.

external table

In case of ‘Update a Sequencing File’ polling strategy, we have to specify the location of file resides in SOA server as shown below. Except this, everything remains same as  discussed above. Make sure that file location is writable.

file

The updated configuration jar can be downloaded from here.

Auto Recovery feature in BPEL

Published May 8, 2013 BPEL 4 Comments
Tags: ,

Most of us are well versed with Fault Management Framework in 11g, where one of the generic feature that we implement is Retry mechanism. Recently I heard about the feature ‘Auto Recovery’ in BPEL and was a part of discussion to conclude when we should (not) rely on this feature during BPEL process execution. Actually this was a new feature for me as I ever explored and considered during the development though I heard of manual recovery. This made me realize that I am still novice :).

So the purpose of this post is to explore ‘Auto Recovery’ in BPEL that include the following. And does not discuss about required configuration in clustered environment, startup related configuration and Callback Recovery.

  • Configuration
  • BPEL Recovery Console
  • Auto Recovery Behavior
  • Auto Recovery in Action
    • Invoke
    • Activity

Configuration:

‘Auto Recovery’ configuration is done by setting few of the MBean properties in EM console. To configure it in EM console one should navigate to soa-infra -> SOA Administration -> BPEL Properties -> More BPEL Configuration Properties -> RecoveryConfig. This will bring up the following screen showing the default parameters. BPEL Auto recovery is enabled by default.

RecoveryConfig

The properties startWindowTime and stopWindowTime specify the period during which Auto Recovery is active. By default auto recovery feature will be active from 12AM to 4AM everyday (remember that it’s SOA server time), shown in above screenshot. We can change these settings by simply updating the time values in 24 hr format and do click on Apply.

The property maxMessageRaiseSize specifies the number of messages to be sent in each recovery attempt, in effect resembles the batch size.

The property subsequentTriggerDelay specifies interval between consecutive auto recovery attempts and the value is 300 sec by default.

The property threshHoldTimeInMinutes is used by BPEL engine, to mark particular instance eligible for auto recovery once the recoverable fault occurs which is 10 min by default.

If we observe closely, none of these properties mention about number of recovery attempts to be made which is altogether a separate MBean property. To set, navigate to soa-infra -> SOA Administration -> BPEL Properties -> More BPEL Configuration Properties -> MaxRecoverAttempt. The default value is 2.

RecoveryAttempt

To disable ‘Auto Recovery’, set the maxMessageRaiseSize property value to 0.

BPEL Recovery Console:

Navigate to soa-infra -> Service Engines -> BPEL -> Recovery to view the recoverable instances. Note that, the console shows all recoverable instances irrespective of enabled/disabled ‘Auto Recovery’. We can manually recover the  faulted instances from this console when Auto recovery is not enabled.

recoveryconsole

Auto Recovery Behavior:

Whenever a recoverable fault (this term is more abstract, I verified this behavior with Remote, Binding and User Defined Faults) occurs during the BPEL processing, it will be visible in Recovery console. If Auto Recovery is enabled, after threshHoldTimeInMinutes BPEL runtime will try to auto recover the instance. If it’s not successful, again number of recovery attempts will be made as given for MaxRecoverAttempt with an interval as given for subsequentTriggerDelay. If instance fails even after these maximum recover attempts, the instance will be marked as exhausted (can be queried on recovery console using message state as exhausted). We can use ‘Reset’ button to make these instances eligible for Auto Recovery again.

Note that, we observe this behavior only when the fault is thrown back to BPEL runtime or fault is not caught within BPEL process.

Auto Recovery in Action:

Developed a simple one-way BPEL process for demonstration. This BPEL has invoke activity that results in RemoteFault and dehydrate activity after that.

Scenarios Verified:

  • No Catch -> Got Remote Fault -> Auto Recovery happened.
  • Catch All -> Got Remote Fault -> Auto Recovery did not happen.
  • Catch All (Scope level) -> Got Remote Fault -> Re-throw Remote Fault -> Auto Recovery happened.
  • Catch All (Scope level) -> Got Remote Fault -> Re-throw User Defined Fault -> Auto Recovery happened.
  • Catch All (Scope level) -> Got Binding Fault -> Re-throw User Defined Fault -> Auto Recovery happened.
  • Catch All (Scope level) -> Got User Defined Fault -> Re-throw User Defined Fault -> Auto Recovery happened.

Configuration Used:

startWindowTime – 0.00

stopWindowTime – 7.00

maxMessageRaiseSize – 50

subsequentTriggerDelay – 300 (sec)

threshHoldTimeInMinutes – 5 (min)

MaxRecoverAttempt – 4

Invoke Auto Recovery in Action:

The instance is faulted with remote fault.

invoke1

The BPEL process instance is visible in Recovery console as ‘Undelivered’.

invoke2

Observed that, ‘BPEL Message Recovery Required’ notification is visible after expiration of time as given for the property threshHoldTimeInMinutes.

invoke3

After the first auto recovery attempt made by BPEL engine. Observe that retry happened by initiating process from the start as there is no dehydration point before faulted invoke.

invoke4

After the 2nd recovery attempt. Observe the time difference between the successive recovery attempts.

invoke5

After the 4 the and final recovery attempt.

invoke6

Now this BPEL process can be seen in recovery console with message state as ‘Exhausted’ (shown below) as all the 4 recovery attempts are done. Now we can recover this BPEL process manually by clicking on ‘Recover’ button or click on ‘Reset’ button to make this process eligible for auto recovery again.

invoke7

Clicking on Reset button which makes this process to be eligible for auto recovery again and BPEL engine will restart recovery attempts (shown below).

invoke8

Activity:

To demonstrate Activity auto recovery, modify BPEL process to add Dehydrate and Assign activity before faulted invoke. This case also demonstrates that auto recovery will happen from the last break point. The highlighted part shown below shows the difference from the previous scenario with Dehydrate activity along with remote fault at invoke activity level.

act1

In BPEL recovery console, we can search for the activities that are marked for recovery. Assign3 is the first activity after the dehydrate activity so the recovery should happen from this activity.

act2

Following screenshots show flow trace after the first auto recovery attempt made by BPEL engine. Observe the difference from previous run in this flow trace. Now the entire BPEL process is not started rather it starts from Assign 3 activity as expected.

act3

act4

After the 4 the recovery attempt.

act5

act6

act7

Now this BPEL process can be seen in recovery console with message state as ‘Exhausted’ (shown below) as all the 4 recovery attempts are done. Now we can recover this BPEL process manually by clicking on ‘Recover’. Observe that reset button is not available and it needs a manual recovery.

act8

Other Observations:

  • The above mentioned behavior is observed only for ASync BPEL and for Sync BPEL processes (Transient Sync) no auto recovery is performed. However, the same is not verified in case of Durable Sync BPEL processes for the time being.

 

Sample code can be downloaded from here.

References:

http://docs.oracle.com/cd/E17904_01/integration.1111/e10226/bp_config.htm

Pages

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 379 other subscribers

Enter your email address to follow this blog and receive notifications of new posts by email.

%d bloggers like this: