I'm trying to come up with a solution to do branching for vRO development so we can stop stomping all over our workflows. There isn't any native functionality in vRO to do this, nor does it seem there ever will be.
How can I import a workflow via the REST API? My thought is to pull a workflow via REST from the developer vRO instance, pull the gold vRO workflow, upload them both to a staging vRO server, putting the gold one in as version 0.0.1 and the dev version in as 0.0.2 so we can use native vRO diff functionality to allow the developer to resolve any issues that may have been pushed into Gold by another developer. I can easily download one and hit the upload URL, but I don't see any documentation around how i can modify the version, name, or destination folder.
Alternatively if someone has a great way to do branching to prevent a bunch of vRO developers stomping on each other, i'm all ears.
You can group your custom workflow into a vRO package, then use a tool provided by vRO to export the package to the file system (each workflow will be exported as a couple of XML files). Then you can put the folder with these XML files under a source control system (Git, SVN, etc.) accessible to all you developers.
So when a developer want to work on these workflows, he will checkout the files from the source control, use a vRO-provided Maven plug-in to build a package file, import the package into his vRO instance, and start working with the workflows in the vRO editor. When he wants to share his changes with the other developers, he again exports his local package with the modifications to the file system, and commits the changes to the source control system.
thinking more about this, it doesn't really solve the problem. If I start working on a bunch of workflows and a few days later someone else starts working on those same workflows in their developer instance, we're going to have merge issues that need to be resolved when it is pushed up to gold.
My thought was having a staging server where i can import the gold, then put the new copy of that workflow on the staging server and have it be the next version, then the developer can use native functionality in vRO to compare differences. its not great, but its the best i can come up with. So basically the vRO workflow to do the merge check would be:
1. export named workflow from gold
2. import named workflow into dev vRO as workflow-gold
3. export dev's workflow to get the binary data
4. import dev's workflow as new version to workflow-gold with new version
5. dev does manual merge check
6. all is good, dev pushes workflow to gold vRO server with new version
Functionality-wise, both approaches are pretty much equivalent.
The only difference is in the way how you would merge changes and resolve conflicts - either working with workflows as binary files and using vRO designer to merge/resole conflicts, or working with workflows as XML text files and using text diff tools to merge/resolve conflicts.
Does anyone want to chime in on their experience doing this type of thing? I don't know how readable the XML is and how likely it would be that someone will just break the workflow and put the wrong XML in there.
Also thoughts on how I can actually do the import via rest? there is no documentation around what JSON i can post with the binary file itself to influence location, name, or version number.
The vast majority of vRO plug-ins keep their content (workflows/actions) as XML files. Sure, it is possible to break the workflow during merging/resolving conflicts by putting in a wrong XML.
As for the import, the only parameter you can specify is the workflow category location. Workflow name and workflow version are part of the workflow binary/XML content and cannot be changed during REST import call; you have to change them before the actual import.
This is something I have been thinking about to do in our shop for awhile. My main driver though is to have an external-to-vro repo for backup/restore and vRO appliance upgrade purposes.
I don't intend to edit workflow elements outside and I agree that it is quite crude method, but it may be needed in certain situations. Check out this thread. The inability to retain workflow versioning after external edits was pretty big drawback for me.
Other than that I think Ilian's suggestion to use PackageToolCli.jar should work. I know several folks here implemented it in the past. I also heard that VMware PSO guys developed an import/export plugin for Orchestrator, but during our last engagement we just didn't get enough time to explore details properly. Keep the thread going, hopefully there will be enough eyes on it.