#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.