Sometimes you need to remove status, or
unstatus, something in Teamcenter.
Typically removing status from objects would be an administrator task to repair some sort of mistake. But you could have a standard workflow where objects go through state changes from statused to unstatused and back again.
Here’s how to do it.
When you import NX parts and drawings into Teamcenter there are two main challenges. The first is selecting the right item ID. I previously covered how to automate that by implementing a custom clone-autotranslate function. The second is selecting the right item type. Today I’ll show how to automate that by writing a custom Convert callback.
Everyone says they want more choices. But the truth is that more choices just confuse people, particularly when there is only a single right choice. This is true with workflow templates. Your users don’t want to select from a huge list workflow templates every time they want to start a new process. It’s annoying and can lead to mistakes which you have to fix.
Fortunately you can limit their choices and make both your users and your own lives easier.
I used to think that any code I put into a post action registered against item or revision creation would be the last thing to run after the creating the item or revision. But that is not true when NX is involved.
I discovered this by implementing a post-action on Item creation that set the object_name field after consulting an external system. Everything appeared fine when I tested it in the Teamcenter rich client. However I discovered that when I created an item in NX the name that my code had applied had been lost. Stepping through the code with the debugger verified that it was still behaving properly but apparently the value was changing after my post-action had exited. So, what had happened?
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
- 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.
- 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.
…And another thing, what’s up with NX checking parts out without being asked? Mike paused to take another swig,
Somehow I’ll be able to save changes to a part without intending to, what’s up with that?
It was a typical wild and crazy night at The Dojo — a couple of engineers hanging out, drinking beer and talking about Teamcenter and NX.
What Mike had run into is one of my pet peeves with the NX integration with Teamcenter: you can’t prevent NX from checking parts out for you.