How To Use Naming Rules - The PLM Dojo http://plmdojo.com/bmide/naming-rules/#.

Xo8hA2BS-00

How To Use Naming Rules - The PLM Dojo

by Scott in BMIDE

Share the knowledge

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:

1 of 2 4/9/2020, 3:22 PM
How To Use Naming Rules - The PLM Dojo http://plmdojo.com/bmide/naming-rules/#.Xo8hA2BS-00

"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_nami

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.

2 of 2 4/9/2020, 3:22 PM