Pinned topicWPS deffers commit on initiation of Long Running Flow using EJB's initiate

‏2012-06-01T04:33:45Z
|Tags:

Answered question
This question has been answered.

Unanswered question
This question has not been answered yet.

Hi All,
Any of IBMs EJB API, eg.initiate, initiateAndClaim, sendMessage (or complete, completeAndClaim) APIs which starts long running flows/completes tasks on a Long Running Flow, reverts with a response, without committing data into WPS. So any immediate subsequent call/query, may or may not return a result depending on when WPS decides to commit the data. (eg. so an early query to fetch pending tasks may not return with any result while a latter call after say one minute may result with pending tasks) This behavior is seen when WPS BPEL flows have sub processes.PFA, a screen of the whole architecture.

Is there any IBM API which would initate a long running BPEL flow with Sub Processes and commit the data into the WPS DB and finnaly return back the result to the client? (we also require a similar API for Completing a task)

Any pointers wrt to the ones mentioned below would help us

Suggest/provide an API which would initiate a Long running flow and revert back a PIID only once it has committed the task data into the WPS DB. Require the same also for Complete?

Another alternative would be if, we could explicitly from the client program commit a WPS transaction (API).

Query Uncommitted Data in WPS.

Note : IBM's initiateAndClaimFirst API does not work for sub processes.

Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

if you didn't have an existing ditributed transaction in place when calling wps bfm ejb, the transaction started by wps will be committed/rollback once the response/exception returns to caller. so not really understand your question.

Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

1. J2EE client calls the WPS's intiate API to start a long running BPEL flow.
2. J2EE client then calls the WPS's Query API, to query any pending tasks (of the newly started BPEL flow with subprocesses).
3. The result of the query is no rows found.Reason, whenever WPS BPEL flows have sub processes, the commit happens later. (ie. the initiate API returns a response, even though it has not committed the task data into the WPS database)
4. The same query is run after one minute.....this time, it returns one row. (due to the late commit of WPS Task data into WPS Database)

I require the first query call to return back a row.In other words, i want WPS to initiate the long running flow, commit data into its DB and then return back the response of the initiate call.Currently WPS is initiate the long running flow, returning back the response and after a period of time committing data into the WPS DB.

Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

ok, i understood your problem. the strange result you observed is reasonable because long running process is made up of many chained transaction and it has transaction behavior setting that can impact the transaction boundary. also if long running process invokes another service, depending on the invocation style (sync or async), the transaction boundary is also differernt.

there are some valuable articles on this topic:
sca transaction: http://www.ibm.com/developerworks/websphere/library/techarticles/0904_fong/0904_fong.html

one more: http://www.ibm.com/developerworks/websphere/library/techarticles/0906_fasbinder/0906_fasbinder.html

w.r.t to your specific problem, if the human task is in the invoved process (not in sub process), you can configure receive activities' transaction behavior to participant (default is commit after). if the human task is directly linked to the receive activity, you should get the task instance after the ejb call is made. if the human task is in sub process,there are many factors that will impact the transaction boundary. you may can or can't get the human task instance created after the ejb call is made (because it may be created in later transactions).

i can help to review your business process design if you can provide the PI file.

Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

Basically in WPS, long running flow are asynchronous in nature.Due to which it does not commit data immediately into WPS DB.
My Business Requirement mandates me to use Sub Processes, I cannot avoid this.Also the BPEL flow is huge.

Effectively Single Person workflow pattern fits my requirements perfectly, http://publib.boulder.ibm.com/bpcsamp/humanTaskFeatures/singlePersonWorkflow.html. But that does not work for Sub Processes.

Had read the links given by you earlier, but none describe how to call long running flows or Sub Processes in a single transaction.

Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

because sub-process 5 is long running, it can only be invoked asynchronously. which means the request has to be in-queue first and then another transaction can pick up the request from queue and then start a new process instance. so there is no way to make it joining your calling transaction.

why you want to get the task instance ready (or ready to be querable) after the ejb call complete? can you have other design alternative? like using api event handler to callback you once the task is created?

Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

To answer your question "why you want to get the task instance ready (or ready to be querable) after the ejb call complete?"

Our Business Requirement is that "if the user initiating/completing the BPEL flow/task is a potential owner of the task, the task should be auto claimed with current user credentials". Now in the Custom properties of the task we store the screen name of the task.That screen needs to be rendered to the user synchronously.Hence we query for pending task and try to derived the screen name from that.We have a CUSTOM UI in the J2EE client which will then render that Screen.

Basically this is the similar to Single Person Workflow pattern.(http://publib.boulder.ibm.com/bpcsamp/humanTaskFeatures/singlePersonWorkflow.html)
(User does not have to go to dashboard and claim task)

So User will synchronously see first task screen, he would then enter data, complete the task (using WPS complete API & query) and then immediately see the second task screen...etc.The flow would be smooth.

Therefore, even the api event handler would not help, since that is a call back, and we would not be able to render a smooth screen flow.