Siebel Business Process Framework: Workflow Guide > Developing a Workflow Process > Process of Planning a Workflow Process >
Determining the Workflow Rule Constructs
This task is a step in Process of Planning a Workflow Process. When planning to build a workflow process, you can determine the general rule constructs that guide the flow of control within the process. Table 10 describes several ways to implement decision rules in a workflow process.
Table 10. Description of Ways to Implement Rules in a Workflow Process
|
|
|
|
Workflow Decision Point |
A step in a workflow that arbitrates between one or more alternative branches in the flow. Each connector out of a decision point has one or more conditions. If the conditions evaluate TRUE for the connector, flow proceeds down the branch represented by the connector. |
When you need a simple articulation of whether one or more alternative actions in flow must be taken. |
Conditional expressions lack support for some key operators, including:
- AND
- OR
- Order of precedence control, as determined by parentheses.
|
Scripted Business Service |
Script within a business service action step that evaluates a potentially complex set of inputs and returns a simplified output that can be evaluated by a workflow decision point. |
When Workflow decision point semantics are not sufficiently expressive to encapsulate decision criteria. |
Undermines the readability and simplicity of the workflow by hiding logic within a business service. |
Other Specialized Rule Frameworks |
Other rule frameworks that can be used directly or indirectly by a workflow, such as personalization rules, assignment rules, EAI Dispatch Service, or the Siebel rules engine. The Siebel rules engine allows you to maintain business process logic declaratively and in a location external to your Siebel applications. For information on implementing rules in a workflow process, see Siebel Business Rules Administration Guide. |
When it is deemed appropriate to use a specialized rule framework, such as when you must assign work to people based on their workload. |
Limitations vary depending on the rule framework used. |
Wait Step |
A workflow step that puts the workflow into a holding pattern until a releasing event is fired or a timeout occurs. |
When you must support time-based escalations or long-running flows that can last for days or weeks. For example, waiting for a customer response. |
The releasing event must be triggered through the Object Manager. |
The Decision Point
A decision point can exit with multiple connectors that represent logical branches. For each connector that provides branching, a conditional statement is evaluated. A conditional statement makes a comparison between two of the items in the following list:
- Process properties.
- Business component fields.
- Literal values.
The terms of comparison include:
- Two values are equivalent.
- One value exists among a series of others. For example, child record values, One Must Match, or All Must Match.
- Greater Than (>) or Less Than (<).
- Between or Not Between.
- Null or Not Null.
For an example of the Compose Condition Criteria dialog box displaying decision criteria, see Defining Condition Criteria for the Workflow Process. For a description of properties in the Compose Condition Criteria dialog box, see Defining Conditional Logic on a Branch Connector. The Wait Step
The Wait step allow you to suspend workflow process execution for a specified period of time or until a specific event occurs.
|