Process Instances Life-Cycle

[fcauti]

Hello,

I know that a process, by definition, has always an end state and that the workflow has to be completed in a limited time.
But if I would like to map exactly the workflow with a real-life entity life-cycle I would end the workflow only when that object is destroyed.
In my case the real life objects are documents and I would like that all the related process instances remain active as long as the documents exist in the application.
This implies that I will have a human task (or suggest me some other task) like "document published" that will never be claimed except when the document is deleted.
Do you see any drawback on this? Consider that document number will be huge, and so huge number of processes instances blocked in a task.

Thank you for the help
Federico

[webcyberrob]

Personally, I prefer a design where the process lifecycle and the business object lifecycle are two distinct things. Often the process will change the state of the business object, hence there is some synergy.

I advise my BAs to think of a lifecycle as 3 distinct stages;Create, Use, Destroy. Hence define the business object lifecycle making sure there is representation at each one of these stages.

So in your case, in the create stage, your document may go through states, authored, reviewed, published and you may have a process which manages the transition through these states. Once its published however, there would be no running processes.

Now in the use stage, you may want to track who is reading the document etc. Hence you may have a process (like a library process) which manages a checkout, checkin state change. The duration of this process instance would be until the item has been checked back in.

In the last stage, you may have a purge process to cleanup. The tricky bit with processes in this part of the lifecycle is identifying the start trigger event. Often they may be temporal, eg after 'n' years, purge the document.

As a design rule, I use the business object key as a process instance variable, hence the process instance knows which business object it is 'bound' to. Occasionally, I embed the process instance ID as a transient attribute on the business object. Hence I can navigate from process to business object or vice-versa. Can be useful if a process gets stuck or crashes etc…

In summary, Im not an advocate of having a very long lived process managing the entire lifecycle…

R

[fcauti]

Thank you R.

In effect it is good practice not to couple too much application objects and processes instances.
So, I will have to create at least two workflows: creation/validation and update/delete.
Some issues happen if someone start to update a document when it is not yet validated. In this case I have either to make the two processes communicate each other with signals or messages, either duplicate some states/activities to allow performing update in the validation flow.
Sorry to get too deep into my specific business case

Bye
F

[webcyberrob]

Hi F,

perhaps you need three process designs, author (includes validate step), update and delete. Your business object seems to have states authored->validated->updated->deleted. Lets assume your three process templates are started by a user gesture (eg user form submission) and the form submission contains the key of the business object so the process instance is then bound to the correct business object reference…

You could have logic in the update process which tests the state of the business object; If object.state == validated then continue else throw exception. If you want to avoid concurrent updates etc, then add a semaphore mechanism to the business object…

Hence whilst signals and inter-process messages can work, would simpler process designs suffice?

R