Showing posts with label BPEL Processes. Show all posts
Showing posts with label BPEL Processes. Show all posts

Monday, October 13, 2008

Create instance with Pick

Break the receive idea!

Well if you think that receive activity is the only way to create BPEL instances, think twice. You can do this with Pick onMessage activity as well. Well if this is a surprise to you then read on else dump this stupid post.

Why do this with PICK

Well if you think about it, it makes it clear that you can have multiple Pick onMessage activities at the same time. What that means in plain english is, you can have multiple operations calling in, to create a instance in BPEL. Is that not cool.

You create BPEL process for each operation in onMessage Pick.
Generally you have single operation to create a instance in BPEL.

How to create instance with PICK

Just check the create instance in the activity, that it. You are done.

What can not be done in this

You can not use a onAlarm activity in this Pick onMessage activity.
If you think about why, it is not logical at all.
How do you expire time on some thing that was not created.

Word of caution

At design time there should be strong reason that you are trying to simulate this at operation level. Use this with caution and for some strong reasons.
For example if you want a single web service for each operation from a source system.

Friday, August 22, 2008

Relate BPEL process instance parent to child relationship

Why I want to relate these?

Before I start I consider this scenario that prompted me to write this stuff.
Well I have a sequence of BPEL processes that get called.
A
--> B
----> C
-------> D
-------> E
----> F

I want a way to relate all the process together in the BPEL console or bespoke application built on top of the BPEL Database.

How to do this?

There are multiple ways to relate these BPEL process.

Title approach

Well the one I prefer is to set the title of the BPEL process instances as some logical value that makes sense to business. What that would mean is all the BPEL processes from "A" to "F" will all be name as "XYZ".
But this is good for the bespoke applications.
Well some times before the actual title of the process is set the BPEL process might go into manual recovery. How do you solve?

Database approach

Well go into the BPEL database and look.
Now how do I relate all the processes in the database.
Well first you need to go the table "ORABPEL"."CUBE_INSTANCE"

There are 3 specific columns that you should know about.
"TITLE" - sets the title of the BPEL process in this column as seen in the BPEL console

"ROOT_ID" - CIKEY (instance id as in BPEL console) of the root parent basically instance ID of A as in BPEL console

"PARENT_ID" - Immediate parents ID i.e the caller process

Sample Scenario

A is the parent
A calls B
B calls C and F
C calls D and E
-------------------------------------------------------
Process Name - Instance ID - Root ID - Parent ID --> comment
-------------------------------------------------------
A - 1 - 1 - --> parent Id blank as no parent for it but root Id is 1
B - 2 - 1 - 1 --> both parent and root ID as same as A
C - 3 - 1 - 2 --> root is still 1, but parent now is B
D - 4 - 1 - 3 --> root is still 1, but parent now is C
E - 5 - 1 - 3 --> root is still 1, but parent now is C
F - 6 - 1 - 2 --> root is still 1, but parent now is B

Sample Query

So sample queries to find all the children in a parent BPEL tree would be to use the root ID
================ Query START ==================================================
select * from cube_instance where root_id = {ROOT aprent instance number}
================ Query END ====================================================


A query to find all root BPEL process i.e BPEL process that are the initiators

================ Query START =================
select * from cube_instance where parent_id is NULL
================ Query END ===================


Why not use Tree Finder?

Itz a good question to ask why not use tree finder.

In the projects that I worked, access to the BPEL console is restricted and access to the BPEL is only through a bespoke J2EE application. But that application does not allow viewing of BPEL instances are that is for functinal people to see work flow tasks related to business errors.

The alternative that was implemented was a read only user to the BPEL database from where these queries are helpful to relate BPEL instances. Especially when performing manual recovery of stales instances and to identify the tree chain that has stalled in the flow.

Hope this answers question raised as a commnet here.

Thursday, August 14, 2008

Count Number of BPEL processes Instantiated in 15 minutes intervals

Why count number of instance that too in 15 minutes interval?

Count Number of BPEL processes instantiated in 15 minutes intervals for what is a good questions.

Well, post GO LIVE to identify what is the rate of arrival of BPEL processes at 15 minutes interval is some thing that upper management is always interested in.
Also can be used for performance stats collection.

Query

Well here I have only used the "Hello World BPEL" process for listing. Add process names to identify the rate of arrival of messages in BPEL system.

=================Query START ====================
SELECT processname sourcesystem, time_interval timeinterval,
COUNT (1) numberoftransactions
FROM (

SELECT process_id processname, creation_date,
CASE
WHEN (EXTRACT (MINUTE FROM (creation_date)) / 15 ) <>
TO_CHAR (creation_date, 'DD-MM-YYYY HH24')
'Hrs 1-(First 15 Minutes)'
WHEN (EXTRACT (MINUTE FROM (creation_date)) / 15) <>
TO_CHAR (creation_date, 'DD-MM-YYYY HH24')
'Hrs 2-(15 to 30 Minutes)'
WHEN (EXTRACT (MINUTE FROM (creation_date)) / 15) <>
TO_CHAR (creation_date, 'DD-MM-YYYY HH24')
'Hrs 3-(30 to 45 Minutes)'
ELSE TO_CHAR (creation_date, 'DD-MM-YYYY HH24')
'Hrs 4-(Last 15 Minutes)'
END AS time_interval
FROM orabpel.cube_instance
WHERE process_id IN ('Hello World BPEL')
AND creation_date > TO_DATE (:starttime, 'DD-MON-YYYY HH24:MI:SS')
AND creation_date <>
)
GROUP BY processname, time_interval
ORDER BY time_interval DESC;
=================Query END ====================

BPEL process states

Why Identify states?

To identify the states of the BPEL processes from the database can be quite handy while for housekeeping jobs in production and building some bespoke application to monitor BPEL servers.

Where to find?

Well the the states of the BPEL processes can be found from the database.
This is what I do and I prefer as it gives a lot more control of what you like to see and customize.

Core table and columns

Well the core table to look at is "ORABPEL"."CUBE_INSTANCE"

The states of the BPEL processes are stores in "STATE" column.
This is defined as INTEGER in the database and does not help in first glance, unless it is know what each state means.

What do the states mean?

Well this is what each integer in the "STATE" column mean they mean:
0 - INITIATED in BPEL
1 - OPEN and RUNNING in BPEL
2 - OPEN and SUSPENDED in BPEL
3 - OPEN and FAULTED in BPEL
4 - CLOSED and PENDING_CANCEL in BPEL
5 - CLOSED and COMPLETED in BPEL
6 - CLOSED and FAULTED in BPEL
7 - CLOSED and CANCELLED in BPEL
8 - CLOSED and ABORTED in BPEL
9 - CLOSED and STALE in BPEL
ELSE UNKNOWN in BPEL

Sample Query

A sample query to find count of BPEL process in various states with in start and end date
=================== Query START ======================
SELECT

CASE state
WHEN 0 THEN 'initiated'
WHEN 1 THEN 'open.running'
WHEN 2 THEN 'open.suspended'
WHEN 3 THEN 'open.faulted'
WHEN 4 THEN 'closed.pending_cancel'
WHEN 5 THEN 'closed.completed'
WHEN 6 THEN 'closed.faulted'
WHEN 7 THEN 'closed.cancelled'
WHEN 8 THEN 'closed.aborted'
WHEN 9 THEN 'closed.stale'
ELSE 'unknown'
END state_text,
COUNT (1)
FROM orabpel.cube_instance
WHERE creation_date < (:startdate) AND creation_date > (:enddate)
GROUP BY state;
=================== Query END ======================