A new Oba pattern ? Asynchronous Business Task Pattern
The only (efficient) way to have an asynchronous communication between a Sharepoint workflow (see the “Cooperating Document Workflow “OBA pattern) and a LOB (Line of Business Application) is to use what I call the "Asynchronous Business Task Pattern". It is a pattern that I frequently use for my customers, because there is no other alternative in Sharepoint:
1. a workflow create a business task (task is identified by an Task Id)
2. a workflow calls the Lob (provides the LOB with the Task Id)
3. the application (workflow) can go to the next step and in parallel can listen to the LOB by checking if the task is updated.
This pattern is illustrated in the following PDC session (after 5’38”) by Alex Malek (Sharepoint team)
http://channel9.msdn.com/pdc2008/BB47/ ; it was not presented as a pattern, but I’m realizing that is a real & nice pattern.
This pattern makes sense
· On the business point of View:
We create a task for the LOB and the LOB replies to this task. Tasks are not just for humans, they can also be used for business applications.
· On the technical point of view:
To be efficient when a workflow is idle (in our case, it is waiting for the LOB), it must automatically be persisted in the persistence store (the Sharepoint database here), and reanimated when the event comes up. If we don’t use the "Asynchronous Business Task Pattern", we have to provide some kind of polling to listen to the reply and Sharepoint, polling doesn’t allow the workflow to be persisted; a workflow will automatically be persisted if the running activity is “Listening” to an event (not any kind of event, there are a limited number of events an Sharepoint activity can listen to): in the picture below , the ListenToLOB activity is listening to an Out of the Box Sharepoint event: the OnTaskChanged event. The type of this activity is an OnTaskChanged activity and it is an out of the box activity.
Enjoy my new pattern 🙂