Workflow wrapping of an entity and binding to workflows

Question

I can't seem to find much guidance on this topic at all however I wondered how others typically model a business entity and it's associated workflow.

 

Do you use a property of the business object class to be a WorkflowInstance?

Do you pass around instances of the workflow object to other components directly?

If some components use the business object directly e.g. for data binding, and other components use a workflow instance how do you manage concurrency to ensure two objects aren't out of sync with each other

 

The workflowinstance can contain properties and I was thinking of modelling the business object identifier here however not sure if this is best practise

 

Thoughts?

Answer 1

Hello,

It doesn't make sense to store a WorkflowInstance in your business objects. It may however make sense to store the InstanceId. It depends on how your application is structured.

As you suggested, another option may be to use the workflow as a business object. Once again, it depends on your application.

The easiest way to deal with concurrency in this case is to avoid the problem. Keep the business object in the workflow and query the workflow to get information about the business object. You may need a wrapper that you would use for data binding. Basically, your wrapper would just call your workflow behind the scene.

Hope this helps.

Answer 2

Thanks Benoit

 

The issue with using the workflow instance wrapping the business object in places where the business object would usually used e.g. for data binding, is that typically you don't execute queries and return workflow instances you return the business object itself e.g. a query to get all invoices where created date > 5/5/2008.

 

There should be a recommended best practise way of doing this for a typical object e.g. invoice

Answer 3

Hi Matt,

 

The way we are doing it is to store the business objects in the workflow so that the workflow can operate on the classes/properties/methods.  You will also need to store the same data in a business database to drive your application.

 

In the case that users can change data in the database after the workflow has been started, you will need to devise a sync methodology.  Sometimes we sync while entering or exiting a state.  Most of the time the user will "tell" the workflow when to begin processing again which is a good time to sync.  If your WF runtime host detects a change it can raise a global event that the workflow will respond to in any state and sync and then begin processing again.