Consolidating Contexts - CN workflows

[vmcdaniel]

Hi All,

WC 10.2 M030 CSP 06

We are consolidating many contexts down to a few.

I think the straight forward way is to Move the Folder/Files, PR's, CR, CN's.

Anyone have an experience doing this?

I'm mostly concerned how active workflows for CN's will transfer to the new context. Does this occur without issue?

[ChrisPLM]

Hello

I have not done such things myself but I would go through some sample steps

     Use a test environment as close as possible as your production environment

     move/merge a few context/data

     test the workflows.

Even if this is successful, one cannot be 100% sure, a safe step would be to coordinator with all your users and ensure they complete as many workflow as possible before to ensure that only a minimum number of workflow will need moving.

Something else crossed my mind, in your workflow rules, do you have any that includes context not as a parameter but "hard coded "

[vmcdaniel]

Thanks Chris, these are good thoughts.

Anyone have any experience with such a project?

[bsindelar]

Hi Vaughn.

My company has experience with this type of task.  Regarding active workflows, the people assigned to the roles of any particular CN is typically assigned at the time the object is created, so if a workflow is launched in "Context 1" then is moved to "Context 2", the next user step that gets kicked off in the flow will still use the assigned member that was pulled from "Context 1".  I say "typically" because there are ways to change "when" the role is resolved for the task activity (i.e. creation of the object or wait until the task is actually sent out), so depending on your use case you can either "remember" the original team for future tasks or "pick up" the new team.

I am interested more in the reasoning for consolidation.  How many contexts do you have now, how many are you trying to consolidate to, and what us the business case for it?

Depending on the number of objects to be moved, there may be better ways to perform the mass move than through the GUI as well.  Feel free to e-mail me a robert.sindelar@eccellent.com if you're interested in more information.

[vmcdaniel]

Thanks Brian. Neat info on the role resolution options.

The business case is we are moving from a product centric to a site centric context architecture.

[ddemay]

Vaughn,

So here's the deal...access controls.  How complicated are we discussing?  What level is the workflow template defined? Lifecycle? Team?

Yes, they will move, and yes, it can be done safely, and yes they will run...for large quantities relocation at the database level is feasible also.

Furthermore, you can move a foldered object (item in a folder - CN's filtered out in default views) .  Activities are not foldered, but stored in cabinets (on purpose, at root of a context  (any non-personal cabinet will do though)).

When configured correctly, you can move anything to anywhere and it operates as-is today. For the salient point...access control(s).

Workflows generate a team from a team template to create an instance of a team. This team instance is bound to the workflow.  Workflows are container managed which is fancy for a context. Context(s) are Site, Organization, Product, Project, and Library types.

Most, if not all Windchill admins are familiar with the Workflow template. Keep in mind, it is a good idea to ensure regardless of where you move running workflows and the the PBO, the templates for the workflow, lifecycle, and team(s).  Read permission if not relocated...

Obviously someone also has to have the means to perform the move, which is separate permissions entirely.

I have done this type of activity all the way back to 6.2.6. I have even taken historical workflows, exported them as custom XML and re-executed them, using original timestamps.  A nice treat for system consolidation or segregation. The customization just killed emails so nothing was actually sent. This was handy to take old business data, but represent it in a newer version of Windchill, using an exact copy of a workflow/lifecycle/team template recreated manually in the new version of Windchill.  (This sounds difficult, but really is not, but surprisingly many companies resort to more painful ways out of bad advice and desire for consulting dollars.)

Movement of anything should not trigger any issues with anyone actively modifying activities, or workflow related content provided (even in stages/phases of movement) provided the access controls are correct in advance!

Anything you rehearse should not depend on anything static, you will always need to ensure the latest data and updates thereto are captured.

Hopefully this information is useful to you and the community (and no one is looking to do something as advanced as I discussed).

Regards,

David DeMay

p.s. if access controls can not change, this too is possible, but much more effort!!

[vmcdaniel]

Thanks David!

I'm able to maintain the same ACs in the source and target contexts. Any the workflows all pull the team in from the Context Team at initialization.

After some testing, I'm not scared yet. 🙂

[doehr]

Hi there,

As was mentioned above the Members of the change objects (PRs, CRs, CNs etc) get set on creation via a Team Template, I usually refer to it as the "team snapshot copy" (I think PTC calls it the team local instance but that's not quite as obvious as to what it is). When you move a change object between contexts the team snapshot copy stays the same unless you use the Reset Team function on it as well to re-grab people for the relevant roles. Also, you have to make sure that the members of that team copy have the required access in the new location; I'm guessing you've set access rules by context team role, including general read access? If the members of the team copy are not in the new host context they will not be able to do the work or even find the change object; access is defined via the host context, not the role map on the change object.

The Workflows should still crunch along as normal, they also work off of a snapshot copy set on the change objects.