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.