≡ Menu

A First Look at Teamcenter Conditions

Share the knowledge

Lately I’ve been working with Teamcenter 8.3 and one of the new features that has  caught my attention is Conditions. Well, they’re new to me, anyhow. Conditions come to Teamcenter via the Teamcenter Enterprise bloodline so since my background is Teamcenter Engineering they’re new. If you’ve spent any time at all working with Teamcenter’s BMIDE application you’ve undoubtedly bumped up against Teamcenter conditions already, especially the ubiquitous isTrue. But, what the heck do they do?

Today I’ll review what the are and some basics of how you might use them. In later posts I’ll get into some more detail regarding some other ways I’ve been using them and, perhaps more importantly, what I’ve found that doesn’t work about them, because one thing I’ve learned is that the documentation and the training never tell you what won’t work.


Conditions are rules defined within the BMIDE which take one or more input parameters and evaluates a single boolean expression from them. For example,

inGroupA(UserSession session) := 

is a Condition named inGroupA which takes a single parameter, session, of type UserSession and then evaluates the expression session.group_name=”A” and then returns either True or False.

Well, whooo-oop-de-doo. What’s so great about that, you ask. Well, there’s two main advantages to conditions,

  1. Ease of creation. They give you direct access to the data model while you’re building the expression. You can directly access any property, and certain operations, defined for the parameters using the familiar dot notation. And if those attributes represent other objects in the database you can access their attributes as well. For example,
    revision.owning_user = revision.items_tag.owning_user

    compares the owning user of a revision to the owning user of that revision’s parent item. The equivalent ITK code would require many lines of code to do the same thing.

  2. Secondly, Conditions can be directly used throughout the Business Model. They let you customize your business model’s behavior in a variety of ways. I’ll give some examples shortly.

The foundation template defines a few default Conditions, including isTrue which simply always returns true and isFalse which is always (wait for it…) false.

Using Teamcenter Conditions in the BMIDE

There is a wealth of places within a BMIDE template definition where you have an opportunity to use conditions. In fact, they’re mandatory. However you typically use the default isTrue Condition. They show up when you attach a Naming Rule to an attribute, when you define Display Rules, when you attach extensions to Operations, when you defining LOVs, and when you’re attaching LOVs to fields; and that’s not an exhaustive list.

To attempt to generalize, the opportunity to use Conditions presents itself in various places where you are attempting to configure some sort of behavior, e.g. that a particular naming rule will be invoked or that a particular LOV will present a certain set of options. When a  behavior’s configuration includes specifying a condition there are two particular effects:

  1. The behavior will only apply if its condition evaluates as True. Usually this is a non-issue because by default behaviors use the isTrue condition which is always True, so the behavior is simply enabled as if there were no such thing as conditions at all. Conversely you could disable the behavior without removing it by using the isFalse condition instead. Of course, the more interesting applications come from using conditions which don’t always evaluate to True or False.
  2. You can usually (I hesitate to say, “always,” because I haven’t taken the time to verify that) configure multiple behaviors at a single extension point, e.g. multiple naming rules or LOVs attached to a single attribute, and the application will apply the first behavior for which its Condition is True. Don’t worry, there’s an example below that shows what I’m talking about.

As I said, generally you’ll simply just use the isTrue condition which means that what you’re configuring is always valid for everyone. Let’s take a look at an example where you wouldn’t use the default.

Pretend for a minute that you’re developing a TC Business Model that will support two different sites which will both be on a single instance of TC.

Now, SiteA has very strict naming rules for their parts. All parts must be identified by four alphabetic letters and a dash followed by four numeric digits. that is:


where a is any letter an n is any numeric digit.

SiteB, on the other hand cannot fathom how SiteA stays in business because SiteB has to give all of their parts numbers which follow this pattern:


Numbers first, then letters. Your job then is to come up with a Naming Rule for part numbers that keeps both sites happy.

In Teamcenter Engineering your only choice would be to create a single naming rule that allowed both patterns, because you can only have one naming rule defined for part numbers:

PartNumbers :=

Of course this would mean that either site could inadvertently create a part that followed the other site’s part numbering scheme and then the next thing you’d know you’d be dealing with human sacrifice, dogs and cats living together, and mass hysteria.

Well, now with Teamcenter Unified we can avoid the madness of cohabiting dogs and cats because we have Conditions to play with. What you could do is first divide up your users into Groups based on their site. Then, you’d create a pair of conditions:

atSiteA(UserSession u) := 
atSiteB(UserSession u) := 

[box type=”note”]Note: A hierarchical group structure could be supported by comparing to either *.siteA or siteA.* depending on whether siteA is the Root group or the leaf group in your organization structure. The “*” character here acts just like a wildcard on the unix or windows command line.
Now you create two naming rules:

PartNumbersSiteA := 
PartNumbersSiteB := 

and attach both naming rules to your Part.item_id attribute, only you take care to specify that PartNumbersSiteA uses the atSiteA condition while PartNumbersSiteB uses the atSiteB condition.

Now when TC attempts to determine which naming rule to enforce it will go down the list of attached naming rules and select the first one where the corresponding Condition evaluates to True. This will mean that SiteA users will see their SiteA naming rules while SiteB users will see their SiteB naming rules.

And no humans need to be sacrificed.
[box type=”note”]
Let’s Review: In Teamcenter Engineering we created one naming rule that allowed both part numbering patterns; TC Engineering only allowed you to attach one naming rule to the item_id attribute.

However, now in “Unified” we can create two naming rules that define one pattern each and attach both naming rules to item_id. However, only one of the naming rules will actually used. Which one depends on the evaluation of the Conditions associated with each naming rule.

Extra Credit

How would you define a default naming rule for users who are not at either SiteA or SiteB?

Using Conditions in ITK

You can also invoke Conditions in your code via the ITK CE library (CE = Condition Evaluation). As I discuss in an upcoming post, I’ve found this to be one of the most useful applications for Conditions for me. I’ll discuss this aspect of their usage then.

More Information

If you have access to the PLMWorld file library at http://www.plmworld.org, the presentation entitled Business Modeler IDE – Conditions, from the 2010 conference is a good introduction.

Also, the official documentation on Conditions is found in the Business Modeler IDE guide, which you can download from GTAC.


Have you used Conditions in Teamcenter “Unified”? Do you have prior experience with Conditions from Teamcenter Enterprise? If so, how does the current implementation compare to Enterprise’s? Do you plan on using Conditions in Teamcenter?

  • Pingback: What's wrong with Conditions?()

  • Pingback: Bugs in TC's Hierarchy of Types and Subtypes | The PLM Dojo()

  • Daniel

    Where can conditions referring to items other than the UserSession be used? Apparently, if they include some other business object in their signature, they cannot be included in Naming Rules, LOV attachments, or Property Renderer attachments.

    • http://plmdojo.com/ Scott Pigman
      • Daniel

        I see. I was hoping to avoid going directly to codeful customisation (we’re new to Teamcenter).

        Really enjoying your site though! It has been difficult to find good information without calling GTAC.

        • http://plmdojo.com/ Scott Pigman

          By all means, avoid ITK if you can; prefer configuration over customization whenever you can. If you have a requirement that you’re not sure if you need to write ITK for, ask at plmworld.org’s forums or the PLM dojo linkedin group.

  • http://plmdojo.com/ Scott Pigman
  • Shatabdi

    Hi Scott.. Could you please tell the difference between EPMJob and EPMTask in Workflows? Why is there a cyclic relation between the two? Why we need both to represent the complete workflow related information?

    • Teamcenter Heretic

      The tasks are the discreet steps within a Job. The Job is essentially the an instantiation of the workflow template. The root task is an important one because it contains a bunch of important info about the running Job.

      In an ITK handler you are given the EPM message. From there you ask for the job. You ask the Job for the root task and then head down the tree form there.

      tagTask = tMessage.task; // this is the task where the handler was invoked

      EPM_ask_job( tagTask , &tagJob ); // this is the job

      HNICHECK( EPM_ask_root_task( tagJob , &tagRootTask ) ); // this is the root task for the job

      You can ask any task for attachments, but the root task is most interesting IMHO.

  • Don Knab

    Well done Venkman! However I can’t condone the moral aspect of dogs and cats living together.

    Seriously…excellent post.

Optimization WordPress Plugins & Solutions by W3 EDGE