#321 BPM Best Practice Resources from the SOA Community

Thanks Juergen!

Available Here

#320 Using Signals for inter process communication

BPM Start Activities of type Signal - subscribe to Oracle EDN events.
BPM End Activities of type Signal - publish Oracle EDN events.
BPM Wait activities of type Signal - subscribe to Oracle EDN events.
BPM Throw Activities of type Signal - publish Oracle EDN events.

I have the following composite -

Process 1 is as follows -

It takes an as input, one of it's attributes is the unique orderNr.
It waits for the Signal Event - OrderOKEvent for that specific orderNr.

Process 2 is as follows -


It takes an as input, checks for a large order(value > 1000).
If it's a large order, then the LargeOrderEvent is raised.
The End activity throws the Signal - OrderOKEvent.
The payload for both events is . 
These are EDN events (Oracle Event Delivery Network).

Process 3 is as follows -

The Signal start activity is subscribing to the  OrderOKEvent.

Process 4 is as follows -

The Signal start activity is subscribing to the  LargeOrderEvent, but is only interested in large orders for
Irish customers. The contains the attribute custCountry, so we can query this.

So what correlation/filtering is required here?

Process 1 wants to subscribe to the OrderOKEvent for a specific orderNr, so correlation is required here.
Start Activity -

The Wait activity leverages this as well -

Process 3 subscribes to all OrderOKEvents, so no extra configuration is required here.

Process 4 subscribes to LargeOrderEvents for Irish customers - so filtering is required here. This can be set as follows -

Set the filter -

I deploy the composite and create 2 instances of Process 1 for orderNrs 1 and 2.

I now instantiate an instance of process 2, thus resulting in signals being published.

Check in em -

So we see 4 new instances -

290041 - Process 2 instance

290042 - the Process 4 Subscription

290043 - the Process 3 Subscription

290044 - the Process 1 Subscription

You can also view EDN Messages in enterprise manager -

Here we see a list of Events  our two are included -

here we see the subscriptions -

JDev project available here

#319 Free SOA training for Oracle partners

Check it out here

#318 BPM Partner Solution Catalog

Available here

This is a live catalog of partner solutions available on Oracle BPM 11g .The solutions showcased here in the catalog have been nominated by Oracle BPM Partners. In addition, to the Partner solutions, Oracle Process Accelerators are also available for customers and Partners to get started with Oracle BPM.

Available here

#317 BPM 11g Timeout Heuristics

Here are some basic heuristics to defensively deal with timeouts in your BPM processes.

The basic rule is - follow the hierarchy

JTA Timeout > BPM EJB Transaction Timeout > resource timeout

We can look at this as referring to the 3 different technical levels involved -

JTA Timeout - set at weblogic engine, this is the Java Transaction timeout. You want to avoid this ever happening. It can be set at weblogic domain level (JTA tab) via the weblogic console - By default this is set to 30 seconds. You will have to increase this, as the BPM EJB Tx Timeout is set, per default, to 300 seconds.

BPM EJB Transaction Timeout - set at BPM engine level. These BPMXXX EJBs are listed under deployments in the weblogic console (Deployments --> soa-infra - EJBs) and the Tx Timeout can be set there.

Resource Timeout - e.g. the web service your BPM process is calling -

Each resource may be unique from this perspective, so it may not be a case of one size fits all. Some research may be needed here to work out what one could term the “normal” response time. You want to avoid inefficient use of the BPM engine – i.e. the engine waiting too long for a response from a service, be it a web service or a DB adapter service. My rule of thumb - add 30% to the "normal" time.

·        














      DB Adapter - QueryTimeout is the attribute you set here. This you can set at design time in JDev, or via em.

·         Binding Component – e.g. the web service you are calling - Connect and Read timeout attributes. 

       These can be set in em. 

Ok, once you have set all of these, see Mark Foster's excellent article for screenshots etc. You can then 

configure an appropriate fault policy bound to the reference(s) with various retry models optimized for the resource (e.g. accounts for different restart times etc.). This policy can then revert to human intervention if the retry does not succeed

#316 - BPM Workspace iPad App

Now available via the App Store -

I finally updated my iPad to iOS 7, thus enabling me to download the Oracle BPM Workspace App which gives us a subset of workspace functionality on the iPad.

Here are the steps to getting the whole thing up and running -

1, Install BPM PS6
2. Install the bp3 patch - 18072286
3. Download the app to your iDevice
4. Configure - Click on iPad --> Settings --> BPM --> set the server and port entries to point to your BPM Server.
5. Create a simple order approvals process --> just containing 1 human task
6. Auto-generate ADF task form
7. Deploy all
8. Create a test instance
9. Login to the iPad BPM app e.g. weblogic/welcome1
10. Approve Orders to your heart's content.

Pictures taken by my iPhone ;--)

#315 BPM Re-deployment, keeping running instance on.

This post covers what can happen internally when you re-deploy a BPM process, keeping running instance on. Essentially I deploy the process below, create an instance. I then remove the script task and redeploy, keeping running instances on. The post details what goes on internally to manage this.

Simple example -

I deploy and create an instance of the process -

I check the trace in EM

Process started at 8:57 am

Check the work_item table, note the 2 rows with state 3 (OPEN, Pending Completion)

Note the expiration time for the Timer (8:57 + 70 minutes)

Now delete the script task from the process and redeploy - keep instances on

Re-visit the work_item table - you will see that the state is still set to 3.

Now I use the following SQL to check the WF_TASK table -

select wf.instanceid,

  wf.taskid,

  wf.tasknumber,

  wf.ecid,

  wf.state,

  wf.componentname,

  wf.componenttype,

  wf.updatedDate,

  wf.thread,

  wf.parentthread

from wftask wf

where

  wf.state in (

    'SUSPENDED',

    'PENDING_MIGRATION',

    'PENDING_MIGRATION_SUSPENDED',

    'ERRORED',

    'ALERTED',

    'STALE')

    order by updatedDate desc;

Three rows – thread 0 is a shadow process –

The other 2 are for the parallel gateway paths –

1 - human task

2 - timer

Open workspace as Admin user –go to Process Tracking

Migrate the instance

Re-check the work_item table

There are now 4 rows – 2 for each activity (Human task & Timer)

The originals are from 08:57 and now have the state 8 (Closed_Cancelled)

2 new rows with state = 3 have been created. The new timer expiry time is now –

Here in the trace from em –

The take-away here is - don't get confused if you see the state of the work_item changed to 8. The relevant new rows with state 3 will have been crested.