I'm currently involved in a project where OBPM 10g is being used in combination with another system providing the user interface.
The idea is that this external system (let's call it system X), polls the engine to find out if there is a task to perform by some logged on user, and if so supports that task as (what is called) an external activity. This polling mechanism would allow you to go from one activity to another where each activity supports one single screen. As a result you are basically modeling a screen flow rather than a business process.
The problem is that you cannot model the screen flow 100%. Think for example about a screen that should provide a pop-up to do some things and then return. There is no (reasonable) way to use OPBM to support this pop-up functionality.
Another problem becomes apparent when you need to call services inside a screen flow. What are the criteria to decide whether OPBM or system X should call the services?
After a couple of weeks and progressive insight, I have come to the conclusion that you should try to prevent modeling a screen flow as a process. So my guideline is to let system X handle the complete screen flow (including the service calls that are specific for that screen flow), in a similar way how you would use a native OBPM screenflow. That really makes life simpler. More over, if you later decide to implement the screen flow in OPBM instead, there is a straight-forward "migration" that won't impact the business process itself.
Wednesday, October 13, 2010
Subscribe to:
Posts (Atom)