Friday, April 11, 2014

#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,
from wftask wf
  wf.state in (
    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.

No comments: