Cancel
Showing results for 
Search instead for 
Did you mean: 

Release Status progression in workflows - TC 11.3

Pioneer
Pioneer

Hi Experts,

 

How do you implement/ recommend Release status progression in workflow templates i.e. how to append/replace/delete statuses.

I looked into following options

 

1.Use OOTB handlers in same workflow?

2. Create 0 step subprocess workflows to switch status

3. Write your own custom handler.

 

Let me write down challanges I faced with each option

 

1.  Use OOTB handlers in same workflow?

 with this approach we have two options

 

(i) Use EPM-create-status on start action of 'Status -Task' and append/replace

 

    If creating new status each time, in case of rejections there would be multiple instances of same release object on ROOT task; ex this is very simple scenario  (actual scenario includes multiple statuses and review tasks and branches)

 

Start -> assemble ->submit for review (gets IN-Review status) ->  Review task  -> if Ok, gets Approved status

                                                                                                                     |

                                                                                                              reject, goes back to assemble task

 

Now in above scenario in case of multiple rejections - There will be multiple In-review status objects linked to Root task

 

Behavior observed in TC11.3

 

first I have put EPM-set-status -action =delete // to delete exisitng statuses from target

 

If I use EPM-set-status -action = append -status=In-Review => this will append ALL instances of In-review to target

If I use EPM-set-status -action = replace -status=In-Review => this  will put first instance of IN-review instance on 

                     targets; thus execution time will not match with Released date and effectivity

 

 

Note-  EPM-set-status -action =delete only removes status from targets and does not delete releasestatus object from Root task.

 

(ii) Use EPM-create-status on start action of ''ROOT-TASK' and append/replace whereever needed later

To avoid mulitple instances of same release status object ; I tried creating only one instance of each release status object(I may need in the workflow) 

 

with this approch in TC 11.3 I observed a bug.

Example: Create In-review, Approved, Released => Three statuses on root task

 

As soon as you will assign any one status (say in-review) to targets - this date released and effectivity will be copied to rest of statuses also. Thus irrespective of execution time for other statuses Date released and effectivity will be same for all statuses/targets. 

 

Thus I ruled out approach #1.

 

2. Create 0 step subprocess workflows to switch status

 

This is how we have it currently in production

 

This gets too complex too manage

 

  • Too many associated workflows
  • Stuck workflows – sub-process gets stuck after process initiation and does not even start ( in a more complex scenario - real time observation)
  • Complex Audit Reports
  • Slow Impact Analysis tab etc

Thus we thought of going for Approach #3

 

3. Write custom handler to append/delete/replace

 

There is OOTB API only to ADD(append) release status but not to delete or replace.

Replace and delete are more complex scenarios as we may have to delete previous RELEASE STATUS object if the target it is being replaced/deleted from is the LAST object referencing it.

GTAC has also confirmed it to be a complex thing and our objective is not to write complex code and spend time and money in its testing and maintenance.

GTAC says there is existing ER already

 

When I approached GTAC for issues/bugs found with first two approaches they closed first one saying approach 2 as workaround and vice -versa but not comitting on issue reported.

 

I have provided simple (using OOTB handlers) workflow templates to GTAC for both the issues and they could replicate it.

 

This is a long post and I may have made typo errors; please excuse. I will go through it again and will correct if required.

 

 

 

3 REPLIES

Re: Release Status progression in workflows - TC 11.3

Solution Partner Honored Contributor Solution Partner Honored Contributor
Solution Partner Honored Contributor

You may want to investigate handlers that come with PLM-Easy. Specifically, the TCPB_RH_checkStatus and TCPB_RH_checkObject. Both are quite useful but checkStatus directly addresses your scenarios. PLM-Easy is used mainly in Germany and I don't know if its available in the US but is worth checking into.

 


Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Release Status progression in workflows - TC 11.3

Solution Partner Experimenter Solution Partner Experimenter
Solution Partner Experimenter

Gunjan, 

For revisions to be released, it must be ensured that all necessary prerequisites for release are met. BCT is offering an add-on to Teamcenter called BCT CheckIt which supports the user with automated checks in different ways. This also includes checks on the release status of the current and it's previous revisions. BCT CheckIt provides the necessary validation mechanisms as an item revision release status check.

BCT CheckIt can also be integrated into workflow designs by using BCT CheckIt workflow handlers. By using BCT CheckIt you can reduce custom rule handlers and avoid complex workflow designs. Basically, you could run various validations by BCT CheckIt and only if everything passes workflows will be triggered automatically. 

Check out our website for more information about BCT CheckIt

Best regards, 

Thomas

 

Re: Release Status progression in workflows - TC 11.3

Solution Partner Experimenter Solution Partner Experimenter
Solution Partner Experimenter

Hi Gunjan,

 

Here you can also find out more about the BCT CheckIt tool, which Thomas mentioned in his comment: Controlled Status Change for Revisions Like he already wrote, the Teamcenter Add-On supports the user with various automated checks. This includes checks on the release status of the current revisions and their respective previous revisions.

 

Kind regards,
Marlene