A workflow without any conditional branching at all is very rare — so much so, that if you have created any kind of workflow you are probably already very familiar with the basics of conditions. However, how you use these rules has evolved as WebFlow has matured, so it is worth taking another look at conditions, the WebFlow rule processor, and the tools now available for evaluating and checking the rules in your workflow. Along the way, you may even discover some new tricks for more sophisticated and streamlined workflow design.
Even if you do not use WebFlow directly to develop business processes, you will find the WebFlow’s rule processor helpful in a number of scenarios, such as:
- Defining SCM processes in the SAP Event Manager
- Setting up the activity conditions used in mySAP CRM one-order processing
- Using the post-processing framework for creating alerts in the SAP Web Application Server
In fact, the power, speed of execution, and quality assurance mechanisms built into the rule processor make it useful in any environment.
The Fundamentals of Conditions
Conditions are logical rules that are evaluated for a particular result while the workflow or process runs. They determine such things as which branch to take or whether an action or loop has been completed or needs to be triggered. At its simplest, a condition is a comparison that leads to either a true or false result (evaluation). Typically, a condition compares two values with each other. Business objects (including ABAP classes1), attributes, constants, container elements, and the elements of XML documents (via the intermediary of a proxy class) can all be used in the condition evaluation.
For example, you may want to compare the attribute of a business object with a constant value (e.g., material-category = “raw”), or with another attribute belonging to another business object (e.g., employee-assignment = project-name). The use of attributes is particularly maintenance-friendly because it allows the rule to be expanded later to take into account new data, irrespective of how this data is extracted from the database — no matter whether the data exists in the same system or resides elsewhere.2
In addition to standard comparisons such as “less than” or “greater than,” WebFlow also allows for more sophisticated checks, such as comparisons with patterns (e.g., product-code conforms to the pattern “010*223”) or making sure that a value is included within a list (e.g., that the cost center value is included in a list of cost centers available as part of a business object’s attribute).
Two Tips for Creating Better Condition Rules
When you combine conditions using Boolean operators such as AND, OR, and NOT, for example —
Cost-center = 100 and plant = 3
— the fun really begins.
As you know, Boolean operators have a hierarchy that affects how an expression is evaluated (e.g., AND statements take precedence over OR statements). In other words, a Boolean expression is not evaluated on a strictly left-to-right basis, making it tricky for the non-scientifically minded to verify that the complicated condition will give you the results that you anticipate.
Use Parentheses to Simplify Complex Condition Rules
To avoid problems with complex conditions, make sure that you use parentheses in your condition definition.
(Cost-center = 100 and
(plant = 3 or plant = 5)) or
cost-center = 300
This provides three advantages:
- You are far less likely to make a mistake when creating the rule. The parentheses override the Boolean hierarchy and directly determine the order in which the rule is interpreted.
- Anyone viewing the rule can see, at a glance, what was intended.
- You can implode or explode the parentheses in the condition editor (including nested parentheses), making the rule easier to edit.
The end result is a complex condition that is far easier to interpret. And because the condition is compiled when it is saved, the extra parentheses do not cost performance at execution time.
Check Your Rules with WebFlow’s Condition Editor and Workflow Trace Tools
Even when you use parentheses to clarify the evaluation of the condition, it is still worth checking that the rule is working as you intended. With the condition editor, you can simulate the condition by plugging in your own values (or better still, the values provided by one of the project stakeholders) and double-checking that the condition evaluates as expected. The analysis of the condition is displayed in tree form, and shows each individual part of the condition that is evaluated (as shown in Figure 1). This makes it easy to spot any mistakes. For the simulation results in Figure 1, we’ve plugged in
100 for the cost center value and
5 for the plant value. This results in a
True evaluation, which is just what we expected.
||Viewing the Results of the Condition Rule Simulation
Although the displays of both the simulation and the workflow trace are identical, errors in each respective test will usually come from different sources:
- Errors found in the simulation are most likely caused by an incorrectly modeled rule. In other words, the rule is syntactically correct but not what the business owner required.
- Errors that appear during workflow execution are most likely caused by dirty data coming from legacy systems.
This display also looks a lot like what you’ll see in the results of a workflow trace, another useful tool to check how the condition evaluates (“CondEval” entries in the condition log). In this case, you’re checking the results after the workflow executes the data.
Ways to Use Conditions for More Sophisticated Workflows
Let’s move on from looking at the most common conditions to how they’re used in the WebFlow context:
The most common condition is a start condition. These determine if an event will trigger a workflow, and are based on the contents of the event container. In a typical scenario, you might want to trigger one workflow for, say, an amount below $1000, but another workflow for an amount above $1000.
As you can see, currencies can be taken into account in the WebFlow rule processor — a useful feature for your business processes.
Another common use for start conditions is when you want a workflow to be triggered, but only when no other workflow instance currently covers this particular scenario. For example, when a customer order is changed, you have a workflow to make sure that the custom-manufacturing team is kept informed. But if the fickle customer increases this same order a second time, there is no need to trigger a completely new workflow — as long as the first workflow is still running and has not passed the preliminary production stages, of course.
How would you design a workflow to accommodate this scenario? You could have a virtual attribute3 added to the relevant business object. This attribute reflects whether or not workflows are already in progress, and it can be used in a start condition that would check this (e.g., if the attribute OrderAlreadyBeingProcessed is false, then start the workflow).
As an alternative to start conditions, you could have created a check-function module. However, these are relics of releases where sophisticated start conditions were not available, so try to avoid this. They are harder to read, more difficult to maintain, and can no longer be used in all SAP components (e.g., mySAP SRM procurement cannot use them). And of course, simulation and tracing are not possible.
Loops and Branches
Within the workflow builder, there is no shortage of places where workflow conditions can be used. The most obvious are in loops (a condition determines when the loops can stop repeating) and branches. These are maintained directly from workflow builder, and most workflow developers have a good grasp of how these work.
However, there are other, still more subtle ways that conditions can enhance the behavior of a workflow:
Work Item Generation
If such a condition is specified, the work items remain in a pending status and will not appear in anyone’s inbox until the condition has been met. This condition is specified in a workflow step. Once this condition has been met, the final stage of the work item generation is performed (including the agent determination), and the work item becomes visible in the inboxes.
The work item generation approach is particularly useful when an object is created in the “Update task” because you can stipulate that the work item will not be activated until the database update has completed (for example the condition
object exists is true). This prevents the WebFlow engine from performing the nonsensical task of determining agents for an object that does not yet exist — a mistake commonly made by inexperienced developers. Seasoned developers know that the use of asynchronous task4 also avoids this problem, but the work item generation method is simpler for developers in a hurry.
Work Item Termination
It’s helpful to think of these as “conditions for premature termination.” If the work item has been created and the condition is met, then the work item will terminate immediately (with the status
completed), and an alternative path specified in the workflow is followed. This is useful for handling exceptions, such as a request for approval being withdrawn (e.g., the person making a vacation request decides not to go on holiday after all). Once again, this can be handled with events (wait steps), but the workflow modeling is simpler and easier to use if this condition is used.
Complete Work Item Execution
With this approach, only when the condition is met is the work item completed. This differs from the work item termination approach because it provides a check that the work really has been done, rather than whether the work item has been prematurely aborted.
For example, when the work item Select a processing status is executed, the agent will see a description of how to select the processing status of the object. Of course, whether the agent actually does this is another matter! A primitive solution is to create a loop in the workflow, re-creating the work item if no status has been selected; but this adds complexity to the workflow log, making it difficult to read for the other agents in the process.
Far better is to specify a “complete execution” condition of the form
status not initial. Only when the agent actually selects a new status will the workflow proceed to the next step.
So now you have a taste of what you can achieve with WebFlow rules. But watch this space — there’s plenty of opportunity for even more flexibility in future releases. For more information on the WebFlow rule processor, see http://service.sap.com/webflow.
A useful, advanced modeling approach is to use work item conditions to achieve a status-driven scenario.
For example, if you wait for a condition such as
project_status = phase_two_complete then your workflow will be driven according to the value of the status element
project_status. In other words, the workflow will advance only when the requested status (
phase_two_complete) has been reached.
The status variable can be set easily using data-binding (perhaps in some parallel branch) or
wait for event, thus integrating workflow events in the status model. A condition that employs status variables is the most general way to synchronize activities based on status changes. Using this technique, the process does not depend on when or where a relevant status change occurs. If the event or activity has already occurred in the past, then the condition will be met straight away. If the desired status has not yet been reached, then the workflow will wait until it is met.
1 ABAP classes are supported as of the SAP Web Application Server Release 6.40.
2 The maintenance is simple, but querying external systems can cost significant performance, so don’t overdo it!
3 A virtual attribute is an attribute that is a wrapper for custom code that calculates a value.
4 See my article “Unraveling the Events at Work in Your Landscape — How Workflows Use Events to Better Manage Business Processes” in the October 2002 issue of SAP Insider (www.SAPinsider.com).
Alan Rickayzen has been with SAP since 1992 and in data processing since 1988. Since 1995, he has been performing development work as well as process technology consulting for various major US customers, and, as a result, he has amassed a good deal of technical knowledge in collaborative process technology. Alan Rickayzen is co-author of the book Practical Workflow for SAP, available at SAPinsider Store, and may be contacted at firstname.lastname@example.org.