If you are like me, I am sure you were quite frustrated by Teamcenter Engineering when you edited Teamcenter workflow template and wanted all active jobs to reflect those changes. Imagine that you were given a task of editing a workflow template (e.g. add an action handler or rule handler to a task, remove an existing handler from a task, modified an existing handler to add/modify/remove an argument, add a new task to a template, etc.) and to make sure that those changes are reflected in all active jobs based on the template.
Some of you may have already known this, but please bear with me while I explain it for the benefit of those who don’t know about it.
Process of Updating Active Jobs in Teamcenter Engineering
In Teamcenter Engineering (and in Teamcenter Unified 2007), you had very limited choices to update active jobs after editing workflow template:
- If you were lucky, you had just a few handful jobs to update. But what if there were hundreds of active jobs?
- First, you would have to find all active jobs based on the template.
- Next, one by one you would send each of those jobs to Workflow Viewer application and set the job in Design mode.
- Then, you would go to the task or tasks that you had edited in the template and make exact same changes to those tasks.
- Finally, you would set the job back to Execute mode.
- And then enjoy yourself while you repeat this process for all active jobs. Not exactly a fun activity.
- There, of course, was an alternative choice of not updating any active jobs or only updating few handful active jobs on case by case basis.
If the change was in the custom action handler or custom rule handler logic then there was nothing to update in the active jobs. You simply build & deployed updated DLL to all machines running tcserver processes, asked users to restart their Teamcenter sessions, restarted 4-tier services if required and you were done. But that’s not what I want to discuss here.
Teamcenter Unified (V8.3) introduces an option to automate this process. I tested this with limited test cases and I must admit that it works fairly well.
New Way of Updating Active Jobs in Teamcenter
Siemens introduced a new functionality in Teamcenter 8.3 to automate the process of updating active jobs after editing the workflow template. This functionality is enabled/controlled by the preference:
EPM_enable_apply_template_changes
This is a SITE preference. It accepts one value of type string. It is set to one of following three values:
- NONE: This value basically retains the legacy behavior. Setting this preference to NONE would offer user the same choices as in Teamcenter Engineering. See Process of Updating Active Jobs in Teamcenter Engineering section above. This is the default value.
- OPTIONAL: This value enables this new feature, but user gets to decide what template changes are to be applied or not applied to active jobs. When the administrator makes workflow template changes available (by selecting Set Stage to Available check-box after completing template edits) or imports updated workflow template (using either Workflow Designer application or using plmxml_import utility), s/he would get a confirmation box. There the administrator must indicate if s/he wants to apply current template changes to all active jobs or not.
- AUTOMATIC: This value also enables this new feature, but automatically updates all active jobs every time when workflow template is updated. I.e. the administrator does not get to choose which template changes are applied to active jobs and which are not.
How those templates updates are applied (if the preference is set to OPTIONAL or AUTOMATIC value) depends on where those changes occur in the template relative to the current active task (i.e. the tasks which are started). Teamcenter documentation explains it well, but I have included it here also:
- If the edits in the workflow template occur later in the workflow than the active workflow process has reached, the edits are applied to the workflow.
- If the edits in the workflow template occur earlier, and the active workflow has already passed the place where the edits were made, the edits are applied to the workflow but do not take effect, unless the task/path is re-executed using backward branching/loops, or when a task is demoted.
- If the edits in the workflow template impact an active task, the edits are applied after the task completes and only take effect if the task is re-executed.
- If the edits delete the currently active task, the next task is started.
Final Thoughts
I did some limited testing and found that it is pretty nice feature that works fairly well – when there are not too many active jobs. I tested following template changes:
- Adding signoff profile,
- Modifying signoff quorum,
- Adding a task later in the process
- Adding/removing/editing handler arguments
In my opinion most critical test would be to make template changes that impacts active tasks (i.e. tasks which are in started state) and test those jobs with reject and demote. This is where there is high risk of job corruption if changes are not applied properly.
Another interesting use case would be to see how template changes are applied to the active task if there are multiple edits. According to documentation, “…if the edits in the workflow template impact an active task, the edits are applied after the task completes…”. The question is what would happen if there are multiple edits in the template impacting active task before active task completes. This is certainly possible in industries (such as defense, aerospace, etc.) where workflow cycles are very long and a task could remain in reviewers’ inbox for long time. Would all those changes queue up? Would all of those edits be applied in sequence or only first/last edit would make it to the active task?
Yet another interesting use case would be to see what would happen if administrator deletes an active task and replaces it with new task with the same name?
Yet another interesting use case would be to see what would happen, if you do multiple changes in multiple batches and decide not to apply first template change but apply the second change?
Based on some issues reported by my clients, most errors occur when workflow edits are performed that impacts active tasks. It would certainly be safe to say that:
- Before you decide if the template changes are automatically applied to active jobs, you run a query to find out all active tasks and see if any of your edits are impacting active tasks. If there are then you need to be cautious before you apply those template changes to active jobs automatically. You can create your own query to find all active tasks of jobs based on a particular template or you can download it from here.
- Changes that renames the task, adds/removes/modifies action handler or rule handler argument, adds/removes action handler or rule handler are probably safe to apply to active jobs.
- Changes that renames/deletes the task and adds another one with exact same name should not be applied automatically to active jobs. This is where one of my clients saw job corruption.
- Changes that modifies signoffs (such as quorum, signoff profiles, etc) could be applied to active jobs. However, I don’t have enough data to suggest that these kind of changes are safe or not.
This new functionality, although very interesting and time saving, raises more questions than what documentation answers.
It would be my suggestion that, if you want to turn this functionality on, this preference be set to OPTIONAL, until this functionality is perfected. This will give you an option to decide if you want to apply certain change to active jobs or not. It would certainly be wise to know what and how many active tasks are out there before workflow template changes are blindly applied to active jobs.
Further Information
For more information please refer to Teamcenter documentation on workflow related preferences.
Download a simple query to find active tasks of jobs based on particular workflow template from here.
Next Steps
Please feel free to comment on this topic. We also encourage you to explore our website to learn about products and services we offer. If you have questions or wish to discuss this topic or any other topic with us in private, please contact us.
What prompted me to write this blog was that one of my clients reported lot of corrupted jobs and very bizarre behavior when workflow template was edited. They had this preference set to AUTOMATIC. Jobs are corrupted to such an extent that they can neither complete them nor delete them.
When perfected this functionality would be phenomenal, time saver and cool. But I don’t think it is production ready yet.
It is very easy to test this in test environment, where there are not many active jobs in various stages. But production environment is entirely different story.
I probably gained some confidence with this update active jobs feature now 🙂
I have been on the nightmare side of this feature not working properly. It is a great feature that would be amazing if it worked as planned. Chalking this up to another life lesson. Test, Test, Test, then apply.
Thanks Barbara for the comment. We fixed these issues couple of times. Are you still facing the same issue?