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) := session.group_name=”A”
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,
- 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.
- 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:
- 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.
- 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 := aaaa"-"nnnn nnnn"-"aaaa
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) := u.group_name="siteA" atSiteB(UserSession u) := u.group_name="siteB"
[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 := aaaa"-"nnnn PartNumbersSiteB := nnnn"-"aaaa
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.
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.
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.
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?