Build Complex Logic into Teamcenter Workflow using Rule Handler Quorum

Have you ever wondered how to build complex logic in your Teamcenter workflow templates without writing your own custom rule handler? Read on – Here I will show you how to build complex logic using – Rule Handlers with Quorums, and Or Tasks.

Rule Handler Requirements

Suppose you have an ECN workflow that cannot proceed until the following conditions are met:

• If ECN Class is “4”, then Item Revision Status must be either “Preliminary” or “Experimental”. OR
• If Item Revision Status is “Production”, then ECN Class must be either “1” or “2”. OR
• If ECN Class is “3”, then Item Revision Status must be “Concept”.

Any other combination of Item Revision Status and ECN Class is not allowed.

There certainly are many other means of enforcing this requirement. Such as – employ BMIDE extensions, pre- or post- methods, Java customization, or even a custom workflow rule handler. What was the first thought that crossed your mind about implementing this requirement? How many of you thought of writing a custom rule handler?

I have chosen to implement this requirement using out-of-the-box workflow capabilities.

Analysis

In a simplistic manner this requirement can be represented by the following code:

if ((((status == "Preliminary") || (status == "Experimental")) && (class == 4)) ||
     ((status == "Production") && ((class == 1) || (class == 2))) ||
     ((status == "Concept") && (class == 3)))
{
    // Allow workflow to proceed
}
else
{
    // Issue error and halt workflow
}

Snippet 1: Code for the Conditions from Table 1

Here we have three clauses joined together using OR. The first clause has two sub-clauses joined together using AND. The first sub-clause itself contains 2 additional sub-clauses joined together using OR. The second clause is syntactically very similar to the first clause. The third clause has just two sub-clauses joined together using AND.

Teamcenter workflow designer has a nice feature of associating a quorum with a set of rule handlers. This feature can be quite handy in some cases. Let’s explore.

Rule Handler Quorum Explained

Quorum means a minimum required number to satisfy some condition. For example in a workflow review task, a signoff quorum specifies the number of minimum required approvals before the review task can complete. For example, if a review task has five reviewers with a quorum of four, then the task is considered as approved if any four of the five reviewers approve the task. Consequently the task is considered rejected as soon as there is a second rejection.

Similarly, a quorum can also be applied to a set of rule handlers too. For example, if the start action of a task has a group of five rule handlers with a quorum of two, then the task is started as soon as any two of the five rule handlers are satisfied (i.e. they return EPM_go). Consequently the task will fail to start if any four of the five rule handlers fail to be satisfied (i.e. they return EPM_nogo).

A quorum of -1 specifies “all” – In case of review tasks, all reviewers must approve the task in order to proceed. In case of rule handlers, all rule handlers in a group must satisfy the condition in order to proceed.

Rule Handler Group – OR

If a group quorum is set to one then it creates an OR condition between those rule handlers. In the example below, the Check Properties task is good to start as long as any one EPM-check-object-properties rule handler is satisfied.

Figure 1: Rule Handler Group – OR

Rule Handler Group – Quorum

If a group quorum is set to any number greater than one but less than the total number of rule handlers in the group, then it creates an OR condition (subject to quorum) between those rule handlers. In the example below, the Check Properties task is good to start as long as any two EPM-check-object-properties rule handlers are satisfied.

Figure 2: Rule Handler Group – Quorum

Rule Handler Group – AND

If a group quorum is set to the total number of rule handlers (or -1), then it creates an AND condition between those rule handlers. In the example below, the Check Properties task is good to start only if all EPM-check-object-properties rule handlers are satisfied.

Figure 3: Rule Handler Group – AND

Rule Handler Groups – AND

Just like action handlers, rule handler groups are executed in the order in which they appear in the task handler panel. Rule handlers in each group are subject to the groups’ quorum, which determines if the group as a whole satisfies the condition or not. If one group fails to satisfy the condition the subsequent groups are not executed. This creates an AND condition between those groups.

Building Complex Rules Using Simple Rule Handlers

The ability to combine rule handlers in a group to create an OR or an AND conditions among them, and the ability to create an AND condition between those groups is very flexible and powerful. It can be used to build fairly complex condition. Our requirement in this example is quite complex. It consists of three clauses joined together with an OR condition. Let’s focus on each of these clauses one by one and see how they can be implemented using rule handler groups.

First Clause

Here we have a group of two sub-clauses – each checking the value of status and joined with an OR condition. This group is then joined with another sub-clause checking the value of class with an AND condition.

(((status == "Preliminary") || (status == "Experimental")) && (class == 4))

Snippet 2: First Clause

Here is how the first clause is implemented:

Figure 4: First Clause

Second Clause

Here we have a group of two sub-clauses – each checking the value of class and joined with in OR condition. This group is then joined with another sub-clause checking the value of status with an AND condition.

((status == "Production") && ((class == 1) || (class == 2)))

Snippet 3: Second Clause

Here is how the second clause is implemented:

Figure 5: Second Clause

Third Clause

Here we have a two sub-clauses – one checking the value of status and the other checking the value of class, joined together with an AND condition.

((status == "Concept") && (class == 3))

Snippet 4: Third Clause

Here is how the third clause is implemented:

Figure 6: Third Clause

This clause can also be implemented like this:

Figure 7: Third Clause – Alternative

The Final Implementation

Now we have all three clauses implemented separately. The final trick is to place all of them together so that they all form an OR condition. For this I use an “Or Task”. As long as any one path completes, the “Check Properties OR” task will be satisfied, completing this task, thus allowing the workflow to proceed.

Figure 8: Final Implementation

Final Thoughts

We explored how rule handler groups, and a group quorum can be used along with a creative workflow template design to create and enforce a complex set of rules. Let’s review some pros and cons of this type of implementation. For the purpose of discussing pros and cons, I am assuming that the rule handler requirements are not extremely complex. I understand that “complex” or “not complex” is a vague attribute of the requirement. I don’t claim that every single requirement can be implemented using this approach. There are cases when writing your own custom rule handler is the best way to implement your requirements, but at the same time there are cases when this approach can be useful.

• The requirements are implemented using Teamcenter workflow configuration rather than customization. Some businesses prefer code-less customization whenever possible.
• Simple changes in requirements (such as adding logic to handle “Void” status, or allowing “Production” revisions on class “3” ECN) can be implemented in Workflow Designer. New Teamcenter preference, EPM_enable_apply_template_changes, can be set to control if template changes are automatically applied to existing active jobs. You can read more about this functionality in my blog: Applying Workflow Template Changes to Active Jobs).
• Such implementation assumes that existing out-of-the-box rule handlers can be used for basic checking. Of course, if there is no such rule handler (such as EPM-check-object-properties) to implement the basic building blocks of a complex condition, then you will have to write one. In this case you have to choose between writing multiple but simple custom handlers which take advantage of the out-of-the-box capabilities implemented above, or a single but complex handler which implements the logic in its entirety.
• One advantage of writing a custom handler is the ability to make changes in the business logic without affecting the existing workflow template.  Once customization is deployed, all jobs (existing or new) will instantly start using the new logic.
• If one of the three clauses is satisfied, then task will complete. However, it leaves some harmless messages about rule handler conditions not being satisfied on other two clauses. On the other hand if none of the three clauses are satisfied then Check Properties task remains in the Task to Perform folder of the responsible party of the Check Properties task. This behavior will, however, change depending upon how these rule handlers are placed and how these conditions are organized.

Further Information

• Applying Workflow Template Changes to Active Jobs

Next Steps

Please feel free to comment on this topic. We also encourage you to explore our website to learn about products and services we offer. If you have questions or wish to discuss this topic or any other topic with us in private, please contact us.