PLM & Solution Architects
Call: +1 (281) 989-6360

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.

Rule Handler Group - OR

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.

Rule Handler Group - Quorum

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.

Rule Handler Group - AND

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

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.

18 Comments
  1. Excellent Post.

  2. Great Info Yogesh !!

  3. Thanks for sharing this excllent post.

  4. Very Informative

  5. But if we look at it from a performance standpoint, would it be better to write a single complex custom rule handler than having 3 different sub tasks and an OR task.
    Thanks for the post. It was insightful.

    • From the performance point of view, it probably won’t matter much. I don’t think performance difference would be in terms of few seconds v/s few minutes. Using three sub-tasks will be slower than using a single custom rule handler because of additional overhead of workflow management for those tasks. But that would still be relative. For example:

      • How complex your condition is? If your condition is complex, then you would be better off writing a custom handler anyway.
      • How does your complex condition breaks down to simple conditions? If you are able to break down your complex condition into simple conditions (using simple rule handler), performance would still depend on how those simple conditions are configured. I.e. using sub-tasks v/s rule handler quorum, etc.

      But again, the advantage of using rule handler quorum is the simplicity without writing code rather than performance gain:-)

      Thanks for the comment.

  6. Hi:
    FOr OOTB handler error appears as “Business rule for handelr .. failed..” User has to click on more button and user can understand the Last line of that error other stuff is not relevant to the end user. So can we have the user understandable error in Production system

    Regds
    Rajeev Jain

  7. I want to know whats the difference between action handler and root handler from testing point of view

    • I assume, you meant to say the “rule” handler. There is no such thing as root handler.

      Action handler is where some action is supposed to happen. Something like data is generated/edited/deleted.

      Where as rule handler is where only checking is supposed to happen. No data editing, creating, or deleting. Only validation.

      On any given task and given action on the task, rule handlers are evaluated first. Only if the rule handler quorum is satisfied, action handlers are executed.

      Technically, you can write action handler to do rule handler’s job and rule handler to do action handler’s job. But that won’t be a good practice.

      There is no difference between them from testing point of view.

      Let me know if you need any more information.

  8. I have to extract data from a form and include it in a drawing title block. Which handler is to be used. if any one has an idean please share .

    • There is no handler to do that. You will have to write a custom handler to do what you want. An alternative is to define NX attribute mapping and then use those in NX Drawing.

  9. 10^3 Thanks for sharing this excellent and informative post..

  10. Nice post. Get clear idea Quorum. Do you have any idea about how to register custom handler in TCUA.

    • There is a complete section in Workflow Designer documentation on how to write and register workflow handlers.

      You use:
      1. EPM_register_action_handler to register action handler
      2. EPM_register_rule_handler to register rule handler.

      However, there is whole lot to it about what you can do and how to do those things once inside the handler code.

  11. Thanks YOGESH.

  12. I have a question.
    I want to use EPM_NOGO in this case i.e if property == x then the workflow should exit

    • First of all: returning EPM_nogo decision will not make workflow exit. It will stop workflow from moving to the next step, until the rule handler satisfy the rule – i.e. return EPM_go. If you never correct the condition that failed, then that workflow path will be stuck in that state forever.

      Second: If you want workflow to exit (as in workflow should stop) then either you will have delete the job.

      Third: If you want workflow to exit (as in bypass everything and proceed to completion) then you will have to use Conditional Task and take a different path when the condition fails.

      However, to answer your question – how to return EPM_nogo when property has certain value?…. What you desire is exact opposite of what the OOTB handler, EPM-check-object-properties, does. The OOTB handler returns EPM_go when when property has certain value. In your case you will have to write a custom handler to do what you want.

Leave a Reply to Yogesh Fegade

SiOM Systems

Expertise in Teamcenter security & access management, configuration management, options & variant configuration, engineering change management, NX CAD data management, document management, workflow/process management, absolute occurrences, appearances, and data migration.

Our Philosopy

‘Siddhi’ means perfection, mastering a difficult skill, success. ‘Om’ is the source of all the energy; it is the source of the energy behind the creation, preservation and destruction of the universe. This philosophy guides us in providing perfect, flexible, future proof, high quality solutions to every customer.

Testimonials

... A true professional who can help guide Teamcenter implementations, mentor and teach staff new to Teamcenter, and architect and guide a client to the best practical solution. Read more