≡ Menu

4 Steps to Follow When Updating Workflow Templates

Dojo-wf-01.png
Share the knowledge

Teamcenter’s Workflow Designer interface is horribly bad. Just one of the flaws is that workflow templates do not have proper revisions. I mean, just think of the irony here. Pretty much the primary task of Teamcenter is to allow you to track what changes have been done to a piece of data. And one of the primary tools in Teamcenter is the workflow template. But they didn’t give you the ability to easily keep track of changes to your workflow templates.

But that’s not all, they set it up so that any time you make a change it’s instantly saved to the template. It’s not like most other applications on your desktop where you can say, “Oops! What was I thinking? Time to close without saving!” Even other TC applications give you that ability, Structure Manager and Access Manager to name two. So they make it really easy to make inadvertent, permanent, changes to your workflow template and really hard to figure out what exactly has changed. Lovely.

Unless you’re capable of never making a mistake when working with workflow templates, you need a system that will keep you out of trouble. Here is mine.

My System for Workflow Template Sanity

Let’s say I want to make some changes to my Dojo-Release workflow process. Here is what I would do.
My original Workflow Template

1. Create a new workflow template based on the current template

The basis of my system is that I do not make changes to the current definition of my workflow template. Instead I create a new template, based on the one I want to change, and make my changes to the new template.

Create a new root template

I name my new template {old template name}.DEV.

Add .DEV to the name

2. Make my changes to .DEV and Test Them

Now that I have a duplicate Template that looks just like my original, I make my changes to the duplicate.

Edit the DEV template

3. Rename original template

Once I have my .DEV template doing what I want it to do it’s time to swap the .DEV and production versions. First I rename the production version to something like {template name}.old-{datestamp}, e.g. Dojo-release.old-20120324a.

Rename the original template
Add a datestamp suffix to the original template

Remember that you have to take the original template into Edit Mode in order to rename it.

4. Remove .DEV suffix

Finally I remove the suffix from my .DEV template, which is the updated workflow.

Remove the .DEV suffix

So now the .DEV template replaces my original template.

the .DEV template replaces the old production template

Various and Sundry

Of course all this happens in your test database before you make any changes to production. I mean, you would never ever ever make changes to your production workflows, no matter how trivial, without trying them in test first, right? Yeah, that’s what I thought.

It may not be a bad idea to create a new template based on your updated template as a snapshot of how it originally looked. It’s just a bit of extra protection just in case someone (not you, of course) ever goes and makes a change to the production version of the template without following this procedure.

I generally leave my old versions in the under construction state, just so they’re not available for someone to accidentally use.

I understand there is a way to go back and find your old versions of your templates. From what I saw it was a pain in the butt. And I can never remember how to do it. So I follow this procedure here.

Was this helpful? What are your tips for keeping track of your workflow template changes?

  • Menk Slot

    Hai Scott, I use a similar system, but put always a revision character in the name of the workflow. So a new Workflow will have the name DOJO-release;A. If I have to make changes then I make a new template based on the last one. The new workflow will be available for a group who can test the workflow. The moment this Workflow is released I use the template filter and the new one will replace the old one. With this you can keep a complete history of the Workflows and if you don’t need the old ones anymore, delete them.

    What I mis in the workflow designer is the possibility to copy parts of other workflows to the new one. Ofcourse you can start with a copy of an older template, but sometimes you also need parts of another one.

    Then the graphical options are poor. To have a good overview of the flow of a Workflow is sometimes difficult.

    regards,

    Menk Slot

    • http://plmdojo.com/ Scott Pigman

      Thank you for your comments, Menk. I always appreciate them. I don’t put the revision in the workflow name because we have NX customizations that invoke the workflows by name via PDM Server calls, so I’d have to recompile and redistribute the DLLs if I changed a revision letter in the wf name.

      Having said that it occurs to me that perhaps the wf names should be kept in an external resource instead of being hard-coded. Well, maybe we’ll make that change for the next big update.

      The other thing is we have a lot of groups (too many), and updating the template filters is a pain in the butt.

      Copy-n-paste functionality would be wonderful to have. And yes, the graphical representations are terrible. There are standard ways of visualizing process flows that most everyone is familiar with. But TC had to come up with their own. The fact that your start and end nodes are really the same node is worth a post in and of itself.

  • Teamcenter Heretic

    Did you know there is a Round Table at the next PLMWorld dealing with Workflow enhancements?

    Currently there is discussion on lots of Workflow topics, but one specifically on handlers: http://www.plmworld.org/p/fo/st/thread=2596

    One of the issues I constantly deal with is that I would like to place SCM tags in the workflow description but the xml format of the templates keeps stripping them out :(

    • http://plmdojo.com/ Scott Pigman

      I knew there was a roundtable, but to be honest I thought it was specifically on handlers.

      Do you have an agenda for the round table?

      I’d like to see wf diagrams that looked like the process diagrams that everyone draws in visio when they’re trying to decide on what the process should look like.

      And “start” and “finish” really being the same node bugs me. But I repeat myself.

      edit: I know that the systems engineering module integrates with visio now. I’m not crazy about having dependencies with MS products in TC, but maybe it would be a good option to use visio in the wf designer.

      • Teamcenter Heretic

        There is no real agenda for this session. Since the topic is “enhancements” I was just using handlers as a start point. Seems logical to me that if everyone has similar handlers that would be a good set of enhancements.

        The typical format that I like is to simply moderate discussions between the users.

        Last session when we were talking about Sys Admin in general there was lots of talk about how much time Workflow stuff took.

        • http://www.facebook.com/randy.ellsworth Randy Ellsworth

          I seem to remember a lot of dog barking at that session…

  • Teamcenter Heretic

    It’s not like most other applications on your desktop where you can say, “Oops! What was I thinking?

    Yep. That one really fries my bacon.

  • Jeremie FEBURIE

    Hello all,
    By PCO Innovation, we manage all codeless and codefull customization in a SCM (source code management system) like subversion.

    Our best practice is the following :
    - each time you modify a template, export it as plmxml format in your working copy folder
    - remove site and accessintend tags
    - commit your file in the svn depot

    With this methodology, the complete history of your workflow template versions is kept.
    Your production database is not polluted with old template versions.

    If you want some beta testers to try it, import your template in a test database (replicated with production data)
    It avoids to corrupt production data with a bug in modified workflow template

    • http://www.facebook.com/randy.ellsworth Randy Ellsworth

      I do the same. WF are exported using plmxml and saved for posterity. Pay special attention to what Jeremie said about removing the tags. This is useful for making the WFs plmxml environment agnostic (read “test database” above).

    • http://plmdojo.com/ Scott Pigman

      Hey, Jeremie. I’m actually about to do this myself. Thank you for sharing your best practices.

      One issue — I believe you meant to say that you delete the AccessIntent tag, not AccessIndend. I just wanted to get that out there for anyone else who, like me, searched for the wrong tag and figured that they just must not have that tag in their particular XML file.

      • Jeremie FEBURIE

        Yes,(sorry) it is a mistake from me.
        The most important tag to remove is the “site” one …

  • Raghav

    This might or might not work if your current workflow is calling a sub-process(es), in that case the handlers on the subprocess calls will also have to be modified to address the change in name of your DEV template and reverted back when the DEV template can be moved to production. My thoughts!

    • http://plmdojo.com/ Scott Pigman

      Interesting point. I’ve not worked with subprocesses. So they need to refer to the parent wf by name?

      • Raghav

        Yes, that is one of the ways you can have a subprocess launched.

  • ashokreddy chintapalli

    Teamcenter does not have this change tracking control on WFs, it is same behavior from many years and I guess Siemens will not changes for years, I do not know why they are not implementing for WFs. Easy way I work is export original or Workflow which is looking better as xml for backup and will do changes. If I do not like will import old one just by importing xml file