Import Package with Actions - should their IDs change?

[jmedd]

vRO 6.0.4

Say I create a vRO package containing actions and I know what the ID of each action is. When I import that package into a new vRO system, what is the expected behaviour of the IDs of those actions? In my testing it would appear that the actions get new IDs. Workflows of course maintain their existing IDs.

Can anyone confirm the expected behaviour?

It's not causing a problem, I am just curious

[iiliev · Accepted solution]

Yes, this is the expected behavior. In vRO 6.0.4, action IDs are not guaranteed to be globally unique (unlike workflow IDs).

[jmedd]

Great - thanks for the response!

[juancayuso]

Hi, 

Related to this question, I would like to do a new one.

Is it possible to import a package which contains workflows, actions, resources, etc, but with new IDs ?

It would be usuful for me and my team because we are several developers working in the same vRO server, therefor we could work with the same code of the project/package, and after make some changes, sinchronize with a repository like GIT.

Is this possible ? Can we do the import and using a new ID for each import, each one for a developer ?

Hi, 

Related to this question, I would like to do a new one.

Is it possible to import a package which contains workflows, actions, resources, etc, but with new IDs ?

It would be usuful for me and my team because we are several developers working in the same vRO server, therefor we could work with the same code of the project/package, and after make some changes, sinchronize with a repository like GIT.

Is this possible ? Can we do the import and using a new ID for each import, each one for a developer ?

Kind regards,

Juan Carlos

[iiliev]

Hi,

You can't. Workflow IDs are globally unique. If you somehow change workflow's ID, it will become a new workflow (even if all other properties like name, version, content are equal).

[juancayuso]

Thanks for your reply,

And is there any possibility to import the same package in different directories in order to work in parallel  several developers in the same vRO server? In this way each developer could modify his project and after that synchronize with control version server (GIT).

Currently it is not possible because the id of each developer collides.

Thanks in advance.

[iiliev]

No, you cannot have several objects (eg. workflows) with the same ID in different folders.

You can 'duplicate' the workflow using vRO client, but this will create a new workflow instance with different ID. If you go this path and give different duplicate to every developer, you have to figure out how to 'merge' their changes back into the original workflow.

[jmedd]

I believe the general guidance from VMware is for a development vRO server per developer to avoid some of the issues you are encountering.

Of course that is not always possible. I have the same scenario as you on my current project, with multiple developers per vRO server and it is far from ideal. It typically means we work out of our own development folders, with a 'Live' folder for the finished workflows.

Newly developed workflows can be worked on in the developers own folder structure, then moved to the Live folder when complete. Bugs / enhancements to existing Live workflows happen in-place.

To work with source control a package is created with the content only of the Live folder.

As mentioned it is not ideal, requires discipline and good co-operation between the developers, but it does work well enough for us. IMHO VMware needs to improve vRO significantly in this area to make it easier for multiple developers to collaborate on the same project.