#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