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.

Overview

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,

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:

aaaa-nnnn

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:

nnnn-aaaa

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"

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.

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.

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.

Questions

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?

Related Posts

• No related posts found

The post A First Look at Teamcenter Conditions appeared first on The PLM Dojo.

As I’ve covered in previous posts covering the basics of Teamcenter’s Conditions and discussing how to use Conditions in your ITK, I’ve been playing around with Conditions in Teamcenter lately and have generally found them to be useful and promising. But not everything has been wine and roses. There are some warts, some deficiencies, and some straight up errors with how they work. I feel that I would be remiss if I did not spend some time discussing the problems and pitfalls I’ve found.

WARNING: Don’t redefine parameter type

I could go into a long story about how I managed to cause a lot of grief for our admin, but I’ll cut to the chase: Once you define a condition, don’t go changing the parameter type. For example, if you create and deploy a Condition that works on Items, don’t change it to ItemRevision later. There is a known bug and that change will not be deployed to the server. The BMIDE will not tell you that there is any problem and you’ll appear to be able to deploy the change, but it won’t actually take. You’re better off either deleting the condition and then re-defining it, Or creating a new condition with a different name.

They’re tempting to overuse

This not a problem with Conditions, per se but with over-eager developers. Once you start using conditions, particularly within ITK, you may find yourself using them for every condition you need to check. If you’re not careful you could end up with a whole lot of very trivial Condition objects in the database, many of which might even be unused. There is only one “namespace” for conditions, and it is easy to clutter it up. So try to use some judgement and common sense about it.

If it’d take you two lines of code to do the same check as what the condition will give you, you’re probably better off using the ITK. You should also consider if the check involves any business logic or not. For example, you can probably create a Condition to check if a revision is an assembly or not. But the definition of assembly isn’t really something that depends on your business logic and it’s something easily enough to determine strictly with ITK. On the other hand, checking if an object has one of a particular set of release statuses to determine if it’s valid for some operation is dependent on your business logic and is conceivably something that could change over time, so for that I would give consideration to using a Condition.

Signature restrictions

Probably the first frustration that users experience is that the hooks in the BMIDE to use Conditions have very specific signatures. Usually the BMIDE will only let you use Conditions that take the UserSession object as input. This means that most Conditions used to configure the BMIDE can only check things like the current Group, Role, or Project of the user. For example, if you want to check if the current user has membership in ProjectX, even though they’re not logged into it right now, you can’t. You’d have to find some other way of checking for group membership.

Can’t Check for unset values

Another snag I ran into is that you can’t test for unset attribute values unless they’re a reference to another Business Object, i.e. tag_t references. In database SQL terms I want to test if any attribute IS NULL or IS NOT NULL. For example, say I had a Drawing item with a string attribute, checker_name, and an initial value of NULL. I might want to define a condition to determine if a checker has been assigned yet or not,

hasChecker(DrawingRevision d) := 
    d.checker_name != NULL # Error!

Unfortunately this isn’t possible because the BMIDE complains that the types don’t match. NULL can currently only be compared to object references (i.e. tag_t attributes), but checker in this example is a string attribute. Since NULL is a valid value in the underlying database tables, we should be able to test for it.

One note: I could test d.checker_name != "", but an empty string is not the same thing as NULL.

Few Functions

There are only three functions that you can use to manipulate the values you’re examining and apparently there’s no way for customers to add their own. The three functions provided are INLIST, which allows you to search for a value in a list, and ToUpper and ToLower, which transform a string value into upper or lowercase. It certainly didn’t take me long to come up with several functions that I wish I had or could define myself, for example:

• Length(string or list)– return the number of characters in a string or elements in a list. 

  Example: Check if an string property has a minimum number of characters

  minimumLength(Workspace Object obj) := Function::Length(obj.object_name) > 5 # Error: No such Length function exists

  Example: Check if an object has multiple statuses

  hasMultipleStatuses(WorkspaceObject obj) := Function::Length(obj.release_status_list) > 1

• ANY(Condition, list) – return true if the condition is true for anyvalue in the list 

  Example: Check if any revision of an item has multiple statuses

  hasRevWithMultipleStatuses(Item item) := Function::Any(Condition::hasMultipleStatuses, item.item_revision_list)

• ALL(Condition, list) – return True if the condition is true for allvalues in the list.
  Example: Check if all revisions of an item have multiple statuses

  allRevsHaveMultipleStatuses(Item item) := Function::All(Condition::hasMultipleStatuses, item.item_revision_list) # Error - no such function

No access to Constants

Conditions can’t access Global or Business Object Constants. I had hoped to create a Business Object Constant, valid_statuses, which defined a list of status names. Then I wanted to test if an object had a valid status by defining a condition something like,

hasValidStatus(WorkspaceObject o) := 
    Function::INLIST(o.last_release_status, 
                     o.valid_statuses)

Where valid_statuses is the value of the Business Object Constant. It seems that your options are to either explicitly list the statuses in your condition definition,

hasValidStatus(WorkspaceObject o) := 
    o.last_release_status=”StatusA” 
    OR 
    o.last_release_status=”StatusB”

Or, to define an Business Object Operation and then use that in your condition,

hasValidStatus(WorkspaceObject o) := 
    o.hasValidStatus()

This is the approach used by the Foundation Condition isOtherSideLatestMature which invokes the isLatestRevisionMature() operation which evidently looks up the MaturityStatuses constant.

No “Dynamic Casting”

If you’re checking a revision object you can use the items_tag to get back to the parent Item and evaluate its properties.

# test if revision has the same name as it's parent item: 
hasItemsName(ItemRevision revision) := 
    revision.object_name = revision.items_tag.object_name

Now, you might expect, or at least I would, that If I had my own custom Item Type with its own custom attribute, that I could do the same thing for my custom Item type’s properties:

myRevHasSamePropertyAsItem(MyItemRevision my_revision) := 
    my_revision.my_rev_attribute = 
        my_revision.items_tag.my_item_attribute # Error!

As it turns out, items_tag cannot access properties defined on subtypes of Item. The reason is simple enough: items_tag is defined as a property of ItemRevision which refers to an object of type Item. So even though there’s no way for the items_tag of a MyItemRevision object to refer to anything but MyItem, you’re limited to accessing the properties defined for the base type, Item, and there isn’t any way to “cast” (to borrow a programming term) the reference to its proper type.

Small Beer: Minor, but Annoying Issues

In my examples above I used line breaks and # comments to clarify my examples. Neither is actually possible in real conditions, however. Line breaks will get you an error from the BMIDE and there is no such thing as a comment in the condition definition.

I won’t cry in my beer over it, but it is annoying.

Conclusions

This wraps up the series on Conditions for now. I hope the information will be useful. Have you tried using Conditions for anything yet? What have you found, good, bad or indifferent, about them? Please share you experiences with us.

Related Posts

• No related posts found

The post Critical Conditions appeared first on The PLM Dojo.

You know what? Users are a pain in the butt. An awful lot of the work that goes into setting up Teamcenter is directed towards preventing users from making too big of a mess of things. And the very first thing that users will try to do to screw up your database is to mess around with the part numbers they assign to data. If a part number is supposed to be XXXX-YYYY, and you don’t have the proper controls in place, you’ll be pretty lucky if you don’t end up with thirteen variations of it: XXXX-YYYY, XXXX_YYYYY, CURLY.XXXX-YYYY, LARRY.XXXX-YYYY, MOE.XXXX-YYYY, XXXX-YYYY.REWORK, my_left_bracket.XXXX-YYYY, projectZ.XXXX-YYYY, etc. etc. ad infinitum, ad nauseam.

I know because I’ve had to deal with the mess users have created, and because I used to be one of those users who contributed to the mess. (doh!)

So, what kind of proper controls can you put in place? Well, keep reading…

As you might guess, there isn’t a single, one-size-fits all solution. There are three types of solutions which I have utilized myself. Which one, or which combination, you use depends on the nature of what you need to enforce and how much convenience and automation you want to supply to your users. I love to complain about users as much as anyone, but frankly, a good solution shouldn’t just focus on slapping them on the wrist; it should also try to help them do their job more efficiently.

The three solutions I’ve used are:

1. Naming Rules
2. User exits
3. pre-conditions

Naming Rules

These will likely be your first line of defense. Naming rules allow you to define one or more patterns which constitute a valid item ID. The syntax for defining the patterns allows for some pretty complex patterns. A naming rule may refer to other naming rules, Lists of Values (LOV), system variables, or use regular expressions. You define them from within the BMIDE application and then attach them to Business Object properties; typically item_id.

Even if you limit yourself to only using Naming Rules, there are a many ways you could define them. For example, say that you wanted to set up a naming rule that allowed part numbers that began with the letter A, B, C or D, and was followed by four numeric digits. There are a few ways to define the naming rule:
(disclaimer: I’m not actually creating these rules, deploying them to a test instance of Teamcenter, and verifying them. So my syntax may not be 100% correct in each case. Still, it’s close enough to make the point)

1. You could explicitly list out all of the possible patterns:

    "A"nnnn "B"nnnn "C"nnnn "D"nnnn 

2. You could, perhaps at the expense of clarity, define it with a single regular expression:

    %[ABCD][0-9]{4}$ 

3. If you wanted to use the same set of four prefix letters in multiple naming rules, you could define it as it’s own naming rule and then refer to it from the other naming rules:

    prefix_naming_rule := "A" "B" "C" "D" part_number_naming_rule_1 := {RULE:prefix_naming_rule}nnnn part_number_naming_rule_2 := {RULE:prefix_naming_rule}nnnn-nnnn 

   In this case the Naming Rule, prefix_naming_rule, wouldn’t actually be attached to any attributes. It only exists to build up other naming rules.

4. And finally, if the prefix was something that you wanted to reference from other parts of the data model — say it defines the list of possible values for some attribute, you could define the prefix as a LOV and then refer to that within your naming rule:

    {LOV:prefix_lov}nnnn 

   Auto Generation

   In addition, naming rules allow you to define one or more patterns which will auto-generate new part numbers when users click an Assign button. This is new in TCUA; Teamcenter Engineering only allowed you to define one pattern which could be used to auto-generate numbers. Now the TCUA rich client will allow you to pick which of the naming rules for which there are auto-generate counters defined. Unfortunately, so far NX 7.5 isn’t hasn’t caught up; If you create a file from within NX and click the Assign button you can only get a number from the first pattern listed in the Naming Rule.

   Naming Rule Limitations

   The limitations of naming rules are that they only allow a simple Pass/Fail result, they cannot modify the attempted part number except to change the case to either upper or lowercase, and they don’t allow you to make any semantic checks, e.g. “the number is valid if it matches this pattern AND some other condition in the database is also True.” Also, setting up counters to auto-generate part numbers only works with the simple naming rule patterns, “A”nnnnn, for example. Naming rules that contain regular expressions or refer to other naming rules or LOVs cannot be used to auto-generate IDs. And finally, the error message reported to users basically just shows then the definition of the naming rule they violated. So, expect that users will be confused by the error messages they get if your patterns at all complicated.

   To be continued…

   That’s enough for now. Tune in next time when I get into the codeful customizations you can do with user exits and pre-conditions.

The post How To Use Naming Rules appeared first on The PLM Dojo.

One of the things in my current to-do list was to figure out how to display a LOV value along with it’s description. For example, If I wanted to attach the foundation level Model Velocity Unit LOV to an attribute then the possible values would be the numbers 1–7. More valuable to the user would be to show them the descriptions, which include m/sec, mm/sec, in/sec, etc.

Well, I didn’t know how to do that. Fortunately for me, I came across Dave Merrit’s “technical how-to get stuff done better and faster blog,” Dave’s Rave and his how-to post on how to attach both an LOV value and description to properties.

Like Johnny Carson used to say, “I did not know that.” So thanks, Dave!

The post Displaying LOV Descriptions along with LOV Values appeared first on The PLM Dojo.

Without the label this would just be a painting of a pipe

Have you ever found yourself talking to a user on the phone who has no idea what a BOM View Revision is, so you end up trying to describe the icon they’re looking for? It’s the one with the three colored boxes that looks a bit like a two pronged fork….

Or how about datasets? Most of them use the generic icon of a gear and the default name is the Item Revision’s ID. There’s nothing like having three objects datasets with the exact same name and icon that you know are actually different types. Oh, and those two that do have custom icons — you can’t remember what the icons mean.

Yes, A picture is worth a thousand words, as the saying goes. But sometimes a few words would be a lot more useful. So today, if you’re using Teamcenter 8.1 or higher, we’ve got a tip for you to add a few descriptive words to your Teamcenter interface to make things a bit more clear. And best of all, you don’t have to write any custom code to do it.

Display Names

In the BMIDE application if you open the editor for a business object type you’ll see a section of the first page, entitled Business Object Constants, and within that list of constants you’ll see one called DisplayName. The default value for this constant is $object_name, which means that the display name is whatever value is stored in the object_name property. However, you can override the default value and use other properties. You can also hard-code specific strings of text by enclosing them in quotation marks, and you can join different properties and strings together with the plus sign, +.

Version Information I’ve done this in Teamcenter 8.3. According to the documentation it seems that the DisplayName constant was added in 8.1, but I can’t verify if it worked the same way or at all prior to 8.3. If anyone can verify this one war or the other, please leave a comment.

A few examples of how I’ve used this will make it clear.

Datasets

First of all, let’s label datasets so that we can always tell what type of dataset they are, regardless of whether they use a custom icon or the default icon:

New default DisplayName for all Datasets

object_type is the property that holds the name of the business object type of an object. By setting it on the base Dataset business object, all of the sub-types will display their own type in their display name. So AVI datasets will have Display Names that end in (AVI) and AutoCAD datasets will have AutoCAD.

UGMASTER

But maybe UGMASTER isn’t the best object_type value to display for that type; after all it’s been a few years since Unigraphics was renamed to NX. You know some new engineer out there would be wondering what an, Ugg Masteris. So let’s provide override our override with something that may make a bit more sense in today’s environment:

Overriding DisplayName for UGMASTER Datasets

Results

After deploying the data model to the database, here’s how the datasets will display:

Nicely Labeled Datasets, as seen in the Rich Client

Now, even for the datasets that use the generic gear icon, it’s easy to tell what’s what.

Workflow Process Creation Date

Have you ever looked at the referencers for an object that had been submitted to multiple workflows, or one workflow multiple times, and wondered in which order they had been done? How about we set up the display name of the workflow task to tell us when exactly it was created? Try setting the DisplayName of EPMTask business objects to $object_name+" ("+$creation_date+")". Then when you check your referencers you’ll see something more like this:

$creation_date tells us when the workflows were created

Conclusion

Personally, I think it makes things a lot easier to understand and communicate by showing the users exactly what type of object something is or when something was created (or modified or released or…). Do you have any other neat ideas for a DisplayName that will be helpful to the users? Leave a comment and share your idea with everyone.

The post Customizing Object Names Using the DisplayName Constant appeared first on The PLM Dojo.

I’ve got a tip to share today, but frankly, I’m hoping someone out there has a better solution — so if you do, please leave a comment and enlighten me!

Which BMIDE Template Version is Currently Deployed?

One advantage to the new BMIDE way of developing a data model is that the data model now exists as a set of XML files which can be managed with a version control system. It is very useful to be able to track changes to the model over time and to be able to coordinate development with others, however the problem is, how can I tell which BMIDE template version is actually deployed to each specific instance of Teamcenter? How can I check if we’re using this morning’s data model or if we’re still using the version that we deployed last week? How do I verify that all of our development, test, and production systems all have the save version of the data model?

I’ve found no good solution, but here’s the best we’ve been able to come up with:

A solution

When I’m ready to package and deploy an update to the data model I update the display name of the template with a date-stamp. For example, PLM Dojo Data Model 2011.12.29a.

Problems with the Solution

There are two things I don’t like about this solution. First, it’s dependent on me remembering to update the display name. I’m getting better, but I haven’t always been perfectly diligent about it. Second, as best as I can tell the only way to check the display name of the current template is to launch TEM and then check on what’s installed with that. I would much prefer to be able to tell from within a client session. Something on the About dialog window would be just about ideal.

Anyone Got a Better Idea?

Here’s where I’m hoping someone out there might have a more creative solution. My ideal solution would work without me having to remember to do something special and be something I could verify from the client.

So, any ideas out there?

The post How To Track The Deployed BMIDE Template Version appeared first on The PLM Dojo.

Here’s a story about the latest snag we’ve encountered in the process of migrating from Teamcenter Engineering to Teamcenter 8.3.

Background

In addition to upgrading from Teamcenter Engineering 2007 to Teamcenter 8.3, we’re also transmorgifying our data model at the same time, the precise reasons for which I may review in detail at another time or in another venue. Anyways, I’ve been using the BMIDE to design our new data model and others have been working to figure out how to get from the old data model to the new one. The current plan involves upgrading our TC Engineering instance in place, using some of the out of the box utilities for renaming types and changing item type — namely, item_to_part_design — and then installing the model I’ve been working on to arrive at our final, new, data model.

So anyways, a couple of weeks ago we ran through the first trial where we duplicated our production TC Engineering database and ran through the entire upgrade process until we ended up with what we thought was a TC 8.3 instance with our legacy data and our new data model. And at first glance, it seemed to have worked fine.

Trouble in Paradise

The first indication of a problem was when I went to look at the property page of one of our types. Immediately, the style sheet used to render the properties threw a slew of java NULL errors which indicated that the new properties I had added to the item type were not found where they were expected. Then, when I tried to save-as to a new item of that type, I could not, the problem being that a post-action I had set on item creation to populate the new attributes failed horribly because the attributes it was attempting to populate did not exist.

So, next we tried disabling all customizations and then creating a new item. Too our surprise, not only did that allow us to create an item, but the new item did have the new attributes. So somehow or the other, the legacy data did not have the new attributes, but new items did.

Class Problems

It took a day or two of investigation to figure out what had gone wrong. As it turned out, it was all because of a space.

In our Teamcenter Engineering instance we had this item type,

(the names have been changed to protect the guilty)
So, when I was designing the updated model in the BMIDE I created a business object called,

And that was all well and good.
Of course, if you’ve ever created a business object with the BMIDE you know that several other business objects and storage classes are created automatically. In particular, the BMIDE created a business object and class named,

And that’s where the problem was.
You see, when we had created DojoItem in TC Engineering, TC Engineering had created a type and class called,

You see the difference? That extra space before “Revision” was what killed us.

After the upgrade, we had a revision type called DojoItem Revision. When they deployed the template with the final data model, a new revision type was introduced, DojoItemRevision. All the legacy data had the old revision type, but any newly created items got the new one.

Next Steps

So now we’re running through a second attempt at upgrading from TC Engineering to TC 8.3. This time however, we’ll extract our legacy types out into an extracted template and then modify that template to finalize the data model. I expect I’ll be doing lots of hand editing of XML files to reconcile what’s been developed with what’s extracted.

Looking Back

I suppose you expect me to say, If I could do it again I’d do it differently. I’d start with an extracted data model first. I wouldn’t try to develop the new model from scratch in the BMIDE. Well, sorry. I’m not ready to say that. As it were, we’ve been hashing out our new data model for months. But it was only recently that the upgrade team settled on the current migration path. Had other options panned out we wouldn’t have been deploying my templates to an upgraded system anyways, and regardless (or irregardless, for those of you from Michigan) my data model development would have been set back months if I had waited for the first trial upgrades to happen.

So, moral of the story is… I dunno. I guess that it’s upgrades are hard, and changing your data model is hard, and doing both at the same time is hard squared. So expect there to be unexpected problems.

The post Item Revisions vs. ItemRevisions appeared first on The PLM Dojo.

Because I like to torture myself by reading what’s new and cool in the latest Teamcenter version, which I likely won’t be able to play with for a long time, I started to read through the What’s New document for Teamcenter 9.1, which you can check out for yourself at GTAC’s website.

One thing that jumped out at me, because we had just been discussing the rigamarole that you currently have go through, was the news that as of TC 9.1, icon configuration will be done directly inside the BMIDE. You no longer will have to create a separate Eclipse project to customize your icons.

From the documentation:

I like the sound of that. I’d much rather have a single BMIDE template to maintain than a template and a separate eclipse project.

Icon Overlays

It goes on to say this, which I think was pretty interesting:

As far as I know this is a new capability (please correct me if I’m wrong). I can think of plenty of uses for icon overlays. A common user request is to make more about an object’s state graphically obvious.

How well does it work?

Okay, the 64,000 dollar question is, has anybody tried this yet? How well does it work? If you’ve had a chance to deploy a TC 9.1 data model that customizes icons, let us know how it went.

The post What’s New in Teamcenter 9.1: Easier Icon Customization appeared first on The PLM Dojo.

The comments section for my earlier post about icon customization in Teamcenter 9.1, kicked off a discussion between me and The Teamcenter Heretic® about the BMIDE. I think a fair summary of Heretic’s position is that the older command line tools from iMan worked very well and that the BMIDE is overcomplicated and unreliable.

Since a discussion of the BMIDE is probably a topic of interest for many of the Dojo’s visitors I thought it should be promoted into its own post. You can review the earlier post’s discussion to catch up. And now I’ll try to lay out my thoughts on the topic.

Was the BMIDE an improvement?

Quoting The Heretic:

1. I like that the data model definition has been separated from the application itself, making it easier for me to design a data model independent of a live instance of TC to work with.
2. I like that there’s one place to define and manage my entire data model, rather than having several different applications or utilities to jump between to do exports and imports
3. I like that data model is now stored as simple XML files that I can manage with my source control system (Subversion, for the record). Sure, I could have done exports of various parts of the data model in iMan, but it was something done after the fact and piecemeal.
4. I like that they’ve done a better job of cross referencing different areas of the application. For example, I can edit a single naming rule and attach it to all the properties it controls, or I can go to an object’s property view and attach multiple naming rules to a single property.

Regarding the interface itself and its complexity, I am a child of the GUI generation I guess (my first PC came with Windows 3.0). I do appreciate command line tools for speed and accuracy, but I also like being able to navigate around a GUI applications and figure out what to click rather than having to remember 27 command line parameters. I also like having the visual layout of the tree structure for the business objects so I can understand the relationship between them and the inheritance model more easily. I don’t know how you could have an application that does all that the BMIDE does that wasn’t complex. It seems to me that only by breaking things out into chunks, like it was before, could you really simplify things — but then you lose the big picture view of what is going on.

Are you sure you want to push that button?

But I’m not always sure that that’s the BMIDE’s fault. From what I’ve seen the same template deployed to two different instances of TC could be fine in one and cause problems in another. For example, I learned the hard way to be careful about changing the type signature of an existing Condition definition. However if the same template was deployed to a system where no such Condition was already defined it would have been simply accepted as a new Condition definition. It seems to me that it’s not so much the BMIDE’s fault as TEM’s and the mechanism by which templates are installed.

What else is wrong?

I have to admit that there are significant design flaws in the BMIDE. The most famous of which is probably the initial requirement that updating Naming Rules and Lists of Values (LOVs) necessitated kicking everyone out of the system to update the template. Supposedly that’s now fixed with a supported Live Update mechanism, but I’ll be honest that I haven’t tried that yet and so I don’t trust it.

Refactoring is Hard

One of my biggest complaints is that it’s very hard to refactor or otherwise make large modifications to the the data model. Just try to move a Business object from underneath one base type to another. Or try to factor out common properties and behaviors from two types into one common, abstract (uninstantiable) base type. It’s not readily supported. Granted, those are not the kind of changes you want to deploy to an existing instance, but if you’re still in the early design and development stage, such rework is perfectly normal.

Bugs!

I’d be remiss to not mention the fact that the BMIDE seems overly buggy, at least in the 8.3 version I primarily work with. I’ve filed several PRs against it myself. It is getting better with each patch, but a lot of the ones I’ve seen should have been caught before it was released to the public.

Your Opinions?

I could write more, but I think it would be better to get more voices in the conversation at this point. If you have any opinions one way or the other please share them. Here are some questions to consider to get you started:

• Do you use the BMIDE?
• What do you use it for?
• What is your overall opinion of it?
• If there’s anything you like about it, what is it?
• What are your BMIDE complaints?
• How can the BMIDE be improved? Or should it be scrapped? What would replace it?
• Do you use any command line utilities? Which ones?
• What am I wrong about? What haven’t I considered?
• What is the Heretic wrong about?

The post Should the BMIDE Stay or Should it Go? appeared first on The PLM Dojo.

I’ve spent a lot of time working with Teamcenter’s BMIDE over the past year. When I use a tool a lot I start thinking of ways to improve it. So I thought I’d share a few of the ideas that I’ve had. None of these would require changes to Teamcenter itself. These are all simply changes to the BMIDE interface. I’m currently using Teamcenter 8.3. I haven’t looked at Teamcenter 9.1 yet, so it is possible that some of these are already available.

I don’t claim that any of these suggestions will revolutionize the BMIDE, but I think they’d improve it for me. Maybe they’d improve it for you too. Please take a look. Give me your opinions on these. Even better, make your own suggestions.

Editing The Data Model

1. Inherit name of compound property source When I create a compound property I usually give it the same name as the source property. The BMIDE should give me the option of automatically inheriting the source property’s name instead of having to manually type it and triple check it to be sure I got it right.
2. Create multiple Compound Properties at once Usually if there’s one property I want to map from one object to another, there’s at least two. After drilling down through the types and relationships to get to the correct source object I should be able to multi-select multiple properties to map at once.
3. Don’t require a connection to Teamcenter I’m creating a new data model for a new instance of Teamcenter. I want to configure Type Display rules. The BMIDE forces me to connect to my instance (which doesn’t yet exist) so it can determine what the organization structure looks like. I’m stuck. The only option other than waiting is to edit the XML files by hand. The BMIDE should allow me to manually enter the group names to use in the Type display rules.

Project maintenance

4. Comments People forget why they did things the way they did. People leave their jobs. Work is done by consultants. There should be a way to add comments throughout the data model so that people could understand why and how things were done
5. Automatic Extension File Organization I like to break my data model up into several separate files. I like the modularity so I can compare similar types, check for changes, and generally just navigate the source code. My wish is that whenever I create a new Business Object that the BMIDE would automatically create an extension file with a matching name and populate it with the Item, Revision, Master Form, and storage class definitions. I also want a separate file for my LOVs, another for my Conditions, etc. etc. This could be optional behavior to accommodate those who prefer one monolithic source file.
6. Setting Project Properties anywhere In Teamcenter 8 you have to select the Navigator view in order to edit project properties. This seems like an unnecessary restriction.
7. Prominent Consistency Stamp I learned from a commentator on a previous post about the Consistency Stamp that acts a checksum for the data model template. It’d be nice is this was more prominently displayed in the data model properties and it was made more apparent what it is.

Navigation

8. Flat List View Toggle We should have the option to list Business Objects and Classes in a simple flat list. Tree views are great for understanding the inheritance structure of the data model but sometimes related types are scattered throughout the tree. For example each Item Type has several related Business Object definitions, the item, the revision, the item and revision master forms, etc. There has been many times I have wished that I could have just had them all listed together. The search dialog already does this, but of course that only lasts until you make a selection. The same option should be available in the Extensions view too. Just show me all of the Conditions, LOVs, Naming Rules, etc. in one alphabetically sorted list.
9. View Filters I’d like to be able to configure filters to select which types are visible. Types of filters I’d like include:
   • By wildcard string DOJ9*, *Drawing*, etc.
   • By Template Show or hide objects based on which template they come from. This goes a step further than search’s ability to filter by COTS/non-COTS.
   • By Type In the Extension view in I want to be able to select exactly which type of extensions are visible (LOVs, Naming Rules, Conditions, etc.)

UML

10. Operations in UML It’s great that the UML diagram shows data members. Now let’s see the operations defined for each class.
11. Navigation by UML Let’s be able to click on class block in the UML diagram and go directly to the property page for that type.

Miscellaneous

12. A better warning when reloading a modified model I’ve talked about this before. This dialog drives me nuts. Every single time I have to stop and read the dang thing. Carefully.
    

Your Turn

What are twelve ways you would improve the BMIDE interface? What are your favorite suggestions? Which ideas don’t you like? Share them below!

The post 12 Ways to Improve the BMIDE Interface appeared first on The PLM Dojo.

I know I should lay off the BMIDE, but I have another complaint suggestion.

As you probably know a BMIDE data model has lots of dependencies and most of those dependencies exist within the data model itself. For example, a property may have a naming rule attached, and that naming rule may depend on a List of Values (LOV). The property, naming rule, and LOV all exist within the data model.

But data models also contain external dependencies. These are dependencies on things that aren’t in the data model. They are expected to be defined in the Teamcenter instance before the data model is deployed. And those are the problem.

External Dependency Examples

Groups can be an external dependency for Type Display rules which determine which groups can create which item types. The type display rules are in the data model but they refer to groups in the organization structure which are not. And if you try to deploy a template to a Teamcenter instance which doesn’t have those groups defined you will get an error.

PLMXML Transfer Modes can also be an external dependency. I’m not even all that sure what in the data model refers to transfer modes. But I know it’s an issue because the other day we spent a lot of time dealing with a template that failed to deploy because a transfer mode was missing. The template had been extracted from an upgraded Teamcenter Engineering instance which had a lot of accumulated junk in it, the dependency on this transfer mode being one such item. We had to hand-edit the XML of the data model to make it refer to a generic out-of-the-box transfer mode that we knew existed.

External Dependency BMIDE View

My suggestion is to add a new view to the BMIDE that shows all the external dependencies in one place. I think they should be organized by type — groups, transfer modes, etc. Each external dependency should also indicate where the dependency is defined, such as “DojoDesignItem – Type Display Rules”. If that listing can also be linked to the actual definition so we can click on it and go to where it is defined, that would be great.

Armed with this information we could check that the target systems already have the necessary groups, transfer modes, etc. defined or we could make sure we’ve added commands to the install scripts to create the necessary definitions.

Feasibility

I could be wrong but I don’t think there’s anything particularly challenging about this idea, other than just the time it takes to implement. I believe that the list of all possible dependencies is well defined. So all the BMIDE would have to do would be to scan for the types of XML elements which may have external dependencies and then collect any references that it finds.

Enhancement Request?

Is this an enhancement we should try to get Siemens PLM to implement? Do you have a better suggestion? If you just want to show your support, click the Google +1 button.

The post Enhancement Request: An External Dependencies BMIDE View appeared first on The PLM Dojo.

Before we begin I want to thank Don Knab of SiOMSystems for his assistance in verifying my work for this post. His help was invaluable. Additionally, his colleague at SiOM, Yogesh Fegade, has recently started his own Teamcenter Blog, which I heartily recommend with my highest recommendation. Go check it out.

How to See Your NX CAD Model’s Mass Properties on Your Item Revision

Yesterday I got an email from somebody I took the Teamcenter 2007 Application Administration class with several years ago. He reminded me that I had showed him how to display the mass properties of an NX model on the Item Revision, using compound properties. I thought that it would make a good post to show how to do it for Teamcenter Unified. In trying to redo it in Teamcenter Unified I quickly discovered that I had forgotten most of what I knew and had to figure it out all over again. So I decided it would be even better to show you how I figured out how to do it. So, here we go.

Objectives

Here’s what you should get out of this post.

1. You’ll learn how to use compound properties to make mass properties of NX CAD models visible on the item revision.
2. You’ll learn how forms store their properties. It isn’t like how most objects store their properties.
3. You’ll see examples of how to interrogate the data model to figure out how things are put together.
4. You’ll likely come away with a better understanding of why I prefer to not use forms for my data model customizations.

What are we trying to do?

A standard ability of MCAD applications, like NX, is the ability to calculate properties such as mass. After all, it’s usually useful to know how much something weighs, right? When we put the data into Teamcenter it would be nice to be able to see those properties in TC, without having to open the model in NX. It turns out that Teamcenter already does store the mass properties. The problem is, they’re sort of hidden.

Where does Teamcenter store mass properties?

If you right-click on a UGMASTER dataset and choose Named References, you’ll see several references, including a UGPartMassPropsForm.

If open the form, you’ll see all of the mass properties calculated for the model.

This only works if mass properties were actually generated at some point for the CAD model, from within NX. Otherwise there won’t be a mass properties form

We Need a Compound Property

I suppose that’s better than nothing, but I’d like to see the property listed as a property of the item revision itself. If you recall my previous post covering Teamcenter properties, you’ll know that compound properties let us take a property defined on one object and show that same value on another object, as if it was defined on that second object. The trick here is going to be figuring out the path of relations and object types that we need to traverse to get from an item revision down to a particular property on the mass properties form.

Building a Compound Property

Let’s review how we create compound properties. You start by adding a new compound property to an object type, in this case an Item Revision. You then define a series of segments which link the destination object type to the source object type. Each link is a pair of a relation or a reference type and the type of object to be found on the other end of that relation or reference type. Finally, when you get to the object type that actually has the property in question you add a final segment which references that source property.

Setup: Show the Real Property Names

Before we try to create the compound property, I suggest that we should configure Teamcenter to show the real property names for everything, instead of the display names. I find that real property names are less confusing for this type of thing. We can do this by setting the TC_display_real_prop_names preference to 1 and restarting the client.

Defining the Segments

Starting Point: Item Revision

When defining the compound property, we start with the object to which we’re adding the compound property, in this case Item Revision

Segment 1: Item Revision → UGMASTER

For the first segment we have to figure out which relationship type connects UGMASTERs to Item Revisions. If you select an item revision containing a UGMASTER dataset and look at the Details tab you’ll see that the UGMASTER is attached with an IMAN_specification relationship.

So that gives us our first segment pair, an IMAN_specification relationship and a UGMASTER object type.

I’m splitting the segment definition between two lines because that’s how it will appear when you add the segments to the property definition in the BMIDE.

Segment 2: UGMASTER → some sort of form

We know that the properties are stored in some sort of form that is a named reference of the UGMASTER. But what is a named reference anyhow? What relationship or property defines the list of named references? And what exactly what type of form is it that stores the mass properties?

Let’s take a look at the properties of the UGMASTER dataset itself (right click, view properties). Halfway down you’ll see a property called ref_list. Hey, that sounds sort of like it may have something to do with named references, doesn’t it? And it appears to have three forms and a .prt file attached to it, just like we saw in the named references view earlier. In fact, if you double click on the forms you’ll find that the second one down is in fact the mass properties form.

So now we know that the first half of this segment is a reference called ref_list.

But what type of object is ref_list pointing to?

Segment 2, continued: What is the form type?

Okay, so we know how to get to the mass properties form, but what type of form is it, exactly?

To answer that, instead of opening the form, view its properties (right click, view properties). Yes, viewing properties is different from opening the form.

When you do this you can see the type of form listed in the header. It’s a UGMassPropsForm form. So now we can complete this segment.

Actually, we already knew the form type from when we had looked at the named references of the dataset earlier, but it’s nice to have a second way of confirming our work.

We’re almost done, Right? (not so fast, skippy)

Up until now things have been fairly straight forward. Now they get a bit trickier.

We have traced a route from the Item Revision, through the UGMASTER, and now we’ve landed on the UGPartMassPropsForm. Since mass is a property of this form we should be able to apply the final segment now and be done, right?

In preparing this article we did try that and it didn’t work. The result was zero even though the form did have a mass value. Frankly, I think this is worth reporting a PR to GTAC.

Anyways, let’s take a look at the definition of the UGPartMassPropsForm object in the BMIDE.

Forms are Secondary Business Objects

Notice the Storage class is Form. Since the storage class has a different name from the business object, we know that this business object is a secondary business object. This means that this form has the same properties as the base class of Form. If we look at the Form business object we’ll see, unsurprisingly, that it does not have any mass properties defined. So, how from where does the UGPartMassPropsForm business object get its mass properties?

Forms have two Storage Classes

To answer that question, look a bit further down. Notice the field called, Form Storage Class. Its value is a storage class called UGPartMassProps (note that it does not end in …Form). This is actually the class where the properties are stored. For reasons long since forgotten, Forms, as originally implemented in iMan, used a second storage class to store their custom properties. The primary storage class for forms, Form, just defines basic attributes common to every type of form — date created, owner, last modification date, etc. It’s this second storage class we need for our compound property.

(Okay, the rumor I’ve heard was that the second storage class was used for performance reason on the ancient hardware on which iMan originally ran. The second storage classes were direct children of POM_object and so, supposedly, look up was faster).

Segment 3: UGMassPropsForm → UGPartMassProps

So how do we get from the form to the UGPartMassProps class?
Let’s take a look at the properties that storage class Form defines. We’ll sort them by the inherited column since the relevant property is most likely defined at this level. To me, there are two that look interesting, form_file and data_file. However, form_file is a string[32] property, so that can’t be the reference we’re looking for. form_file though, is a reference type of property. So that just might be the right one.

Okay, I’ll cut to the chase. It is the right one. But feel free to try some other property if you think that’s a more likely choice.

So now we have our third segment.

Final Segment: mass properties

Now we can finally finish off the compound property. We just have to select the mass property as the final segment.

Defining the Compound Property

Here’s what the actual compound property definition looks like in the BMIDE.

This compound property will show the mass value from the UGPartMassProps form as a property on the item revision itself. Pretty cool, eh? You can use the the same principle to show any of the other mass properties, or any of the properties stored on any of the other forms which are attached as named references. That’s even cooler.

Recap

Here are some of the key things we have learned:

• Named references are attached to Datasets by the ref_list property.
• Forms have two associated storage classes.
• The storage class that stores the custom form properties is linked to the form by a data_file property
• Opening a form is different from viewing the form’s properties. The latter displays information about the form object itself. While the former displays the custom properties the form stores about its parent object.
• The details view can be used to show you the relationship with which one workspace object is attached to another.
• The preference TC_display_real_prop_names configures the display to show us real property names instead of display names

Further investigation

• I would love to hear if anyone does something similar with other types of CAD datasets besides NX.
• You can actually pick Form instead of UGPartMassPropsForm and Dataset instead of UGMASTER and the compound property will (mostly) still work — I wonder if there is a difference in performance.
• One exception that Don found was that if the Item Revision had both a UGMASTER and a UGPART dataset attached, both of which had a mass property, then the compound property failed to display any value.
• I’m curious if there are any plans to do away with the secondary storage classes for forms. I suppose that would could introduce big backward compatibility issues though.

If anyone has any insight to share on these or any other related questions, please share them in the comments below. Thank you!

The post How To Build a Compound Property to a Form Inside a Dataset appeared first on The PLM Dojo.

One of the trickiest things about working with the BMIDE is making sure that your template isn’t about to introduce any unwanted or, worse, invalid, changes to the the system. You have to keep track of what changed between successive versions of your data model — for that matter, you have to keep track of which version was last deployed. It can be rather daunting.That’s why I’m pleased to share this recipe for checking your current template against what’s actually live on the system. It comes to use courtesy of long-time FOD (Friend Of the Dojo), The Teamcenter Heretic. TCH has dug into the utilities documentation to come up with a step-by-step process for generating a report that will tell you exactly what will change if you deploy your template.Take a look, I think you’ll find it useful.- Scott

Tested for Teamcenter V 10.1

1. Get a properly configured Teamcenter environment shell
   • Set TC_ROOT and TC_DATA appropriately
   • call %TC_DATA%\tc_profilevars.bat
2. Create a Temp directory to work in.
   • C:\temp\bmide
3. Make a sub-directory called lang:
   • C:\temp\bmide\lang
4. set an environment variable:
   • set TWORK=c:\temp\bmide
5. Copy the files from %TC_DATA%
   • copy %TC_DATA%\model\*_dependency.xml %TWORK%\*
   • copy %TC_DATA%\model\*_template.xml %TWORK%\*
   • copy %TC_DATA%\model\*_dependency.xml %TWORK%\*
   • copy %TC_DATA%\model\master.xml %TWORK%\*
   • copy %TC_DATA%\model\lang\*_template_.xml %TWORK%\lang\*
6. Find the packaged template zipfile:
   • workspace\<some_name>\output\packaging\full_update\<some_name>_template.zip
   • Inside the zip you will find a structure something like install\<some_name>
   • You should see lang (a directory), <some_name>_dependency.xml and <some_name>_template.xml
   • You need to copy these last three items from the zip file into your %TWORK% directory.
7. Change your current working directory into the Temp directory:
   • cd /d %TWORK%
8. Run the consolidator:
   • bmide_consolidator -dir=%TWORK% -file=cons.xml -consolidate=all
9. Run the extractor:
   • business_model_extractor -outfile=extr.xml -mode=all -u=infodba -g=dba -p=infodba
10. Run the comparator:
    • bmide_comparator -compare=all -old=extr.xml -new=cons.xml -delta=delta.xml -log=delta.log

The result of all this work is a html file called delta_report.html

The delta report will show in plain english the items that would be changed if you deployed this template to your site.

The post How to Compare Your BMIDE Template vs. What’s Installed appeared first on The PLM Dojo.

I don’t know about you but I sometimes find the Teamcenter documentation to be a bit hard to follow, “check the Werzengablatter checkbox in order to enable the Werzengablatter functionality.” Okay great, but why exactly would I want to enable the Werzengablatter functionality? However, if you dig in there are some gems to be found […]

The post Occurrence Validations vs BOM Grading appeared first on The PLM Dojo.