Siebel Business Process Framework: Task UI Guide > Implementing Task UI > Scenario for Iterative Development of a Task UI Implementation >
Creating an Executable Business Process Definition
By using Siebel Tools to model the business process, User A has saved User B a significant amount of time, because he is now able to use User A's model as a starting point for his iterative refinement. After some analysis, User B notices that—although logically it belongs to the business process model—the submission task must be taken out of the executable long-running workflow definition, because it is the submission task that must initiate the long-running workflow, and not vice versa. The submission task has to pass the expense report's ID as an input argument. For this purpose, User B decides to reuse the Object ID process property, which he now makes an input argument to the process. He lets User A know about the discovery. Next, User B considers the Decision step that decides whether further review of the expense report is required. Being familiar with the full range of technologies provided by the Siebel 8 platform, User B determines it is best to add a call out to the business rules engine to make the further-review decision. He knows this will improve the agility of the business process by allowing the approval rules to change without requiring changes (and consequently re-testing and re-deploying) to this executable process definition. When User B takes a closer look at the review task, he realizes that it must be assigned to a particular reviewer before it can be instantiated. He achieves that by calling Assignment Manager through a Business Service step that directly precedes the review task. The final flow is depicted in Figure 11.
Figure 11. Executable Business Process Flow
|
All these revisions to the draft business model help to illustrate the differences in the level of abstraction between a business process model and an executable process definition. They also help to show why the roles of business analyst and business process developer can rarely be played by a single person. User B continues refining (for example, by defining conditional branches, process properties, and input and output arguments) and unit-testing the long-running workflow process until it is ready for deployment, as explained in Siebel Business Process Framework: Workflow Guide.
|