I want to share some problems I’ve had with Teamcenter 8.3. I’ve come across two functions in Teamcenter 8.3 where I attempted to pass in the name of a base object type and expected the function to apply to all subtypes of that type, however the behavior was not inherited by the children types. I suspect there may be other examples of this problem waiting to be found.
EPM-validate-target-objects Doesn’t Apply to Subtypes
EPM-validate-target-objects is a workflow rule handler which allows you to check the targets submitted to a workflow and issue an error if the specified conditions are not met. In Teamcenter Engineering I would attach this handler to the start action of the root task to make sure that workflows for Item Revisions were not mistakenly invoked on an Item instead. I used the argument
-allowed_type ItemRevision to do this, and any Item Revision, regardless of specific item type (e.g. Drawing Revision, Part Revision, etc.) would be valid, but anything else (Item, Folder, Dataset) would not.
I tried to use the same handler in Teamcenter 8.3, but I discovered that
-allowed_type ItemRevision meant that only business objects specifically of type ItemRevision would be allowed. DesignRevision, PartRevision, and DrawingRevision would not. To me, this is a regression in functionality, and I know that mine is not the only customer IR that’s been filed with GTAC.
I presume that the problem is that the handler is specifically testing if the name of the underlying storage class matches “ItemRevision”, instead of doing a proper OO type inheritance check, “is DesignRevision a type of ItemRevision?”. In Teamcenter Engineering there was only one storage class for all item revisions, much like there’s only one storage class for all datasets now in Teamcenter 8, so the code would work no matter what the actual item type was.
I’m currently waiting to hear back from GTAC about if there’s a work-around or not.
It turns out there’s a formal term for the expected behavior that’s being violated. The Liskov substitution principle, or LSP, defines
substitutability in relation to object oriented programming as a desirable behavior. Substitutability is defined as,
if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).
Applying this principle to Teamcenter would mean that whatever behavior I expect when using an item revision should be the same behavior seen when using a subtype of item revision, such as design or drawing revision.
fnd0chkObjProp is an operation defined for ItemRevisions. Basically what it does is let you check if objects of a specified type that are attached to the revision with a specified relationship have a particular value or not.
The neat thing is that this is an item operation which you can call from a condition. My intention was to create a condition that used this operation to check if a revision had any checked-out specifications attached to it, so I passed in “IMAN_specification” and “WorkspaceObject” for my relation and object type parameters.
As you may have guessed, “WorkspaceObject” doesn’t work as I hoped it would. It turns out that I have to specify each object type I want to test for separately in its own call. So, Instead of,
has_checked_out_spec(ItemRevsion rev) := rev.fnd0chkOjProp("IMAN_specification", "WorkspaceObject", "checked_out", "Y", true, "=")
to test if the rev has any workspace objects, attached as specifications, whose “checked_out” property is equal to “Y”, I need to do something more like this:
has_checked_out_spec(ItemRevision rev) := rev.fnd0chkOjProp("IMAN_specification", "UGMASTER", "checked_out", "Y", true, "=") OR rev.fnd0chkOjProp("IMAN_specification", "UGPART", "checked_out", "Y", true, "=") OR // etc.
Question for you: have you seen any other problems of this sort in Teamcenter 8? Leave a comment to share your experience.