Skip navigation

Milko's Blog

August 2017 Previous month Next month

By design, vRealize Orchestrator (vRO) is an IT process automation tool that makes IT operations faster and less error-prone. However, to get the best out of vRO, you need to know how to overcome the most common challenges you may come across. In this blog, we will focus on how to properly set up your development environment and source code control system (SCCS) to gain full traceability of your development process and be able to resolve conflicts.

As with any type of software development, it all starts with an integrated development environment (IDE) and a SCCS. With vRO, the easiest way is not to change the vRO client with another IDE for developing workflows and actions, but just integrate a SCCS with it and define their interaction.

Depending on how much control you want to have over what you are doing, the interaction between the SCCS and vRO can be manual, semi-automated, and automated. The more manual the interaction is, the more control you will have; and you will be able to use all features of the SCCS. The more automated the interaction is, the more limited you will be on what you can do, especially if you use the fully automated one button approach.

In this post, we will focus on the manual, full-control approach, because if you are doing something serious, which as a reader of this blog I believe you do, the best is to have full control over your source code.

So, let's get started. You have to create a vRO package and put it under version control.

Initial project setup

Create an initial vRO package and store it on your file system

To create an initial vRO package, you need a vRO server and a vRO client.

  1. In the Orchestrator client, create a package and add the initial content to the package. See Create a Package in the vRO official documentation.
    Screen Shot 2017-07-31 at 13.54.01.png
  2. Right-click the package and select Expand package to folder.
  3. Choose a folder where you want to store your project files. It can be local or remote.
  4. Uncheck Export version history.

Although this feature may sounds useful, the expanded package cannot be build with the version history. So, it will just add more unnecessary files.

   5.  Click Save.

        The vRO client generates a pom.xml file.


Now, you have to modify the generated pom.xml file to generate your package from the initial project files.

Modify the generated pom.xml file


  1. Navigate to your project folder.
    The folder structure will look like this:
    Screen Shot 2017-07-31 at 14.07.27.png
  2. Open the generated pom.xml.

        The pom.xml will look like this:

<project xmlns="" xmlns:xsi=""
  <!--  Maybe you'd like to change this to point to your organization's groupId-->
    <keystoreLocation>--Specify me--</keystoreLocation>
    <keystorePassword>--Specify me--</keystorePassword>
    <!-- change to vf for releases: it will lock the workflows -->
      <name>This repo was added by the 'Expand to file system'</name>
      <name>This repo was added by the 'Expand to file system'</name>
          <!-- Set the local path to the *.vmokeystore file used to sign the content -->


  3.   Modify the Keystore location and password.

        The keystone contains the certificate used to sign the package when creating it. In this case, generate an example self-signed certificate in a keystone following the procedure.

    1. Generate the keystore.
      keytool -genkey -keyalg RSA -alias_DunesRSA_Alias_ -keystore example.keystore -storepass password123 -validity 3650 -keysize 2048
    2. Answer the questions.
    3. Modify the pom.xml

For production usage, use real certificates.


  4.  Modify the vRO Version.

       The vRO version is used as a version of the vRO maven plug-in and it needs to correspond to the version of the artifact in the maven repository. In this case, we are using vRO as a maven repository.

    1. Replace the IP address with the hostname/IP address of your server in the URL -
    2. Go to the URL and check the plug-in version. In this case, it shows 7.3.0:

Screen Shot 2017-07-31 at 14.37.43.png

          c.  Change the version in the pom.xml to 7.3.0.


Build the vRO package

Build the package from the project sources using mvn. Navigate to your project folder and run the command:

mvn clean install

If you use vRO as a repository, you have to change the self-signed certificates on the vRO server. Otherwise, use the -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true parameters.

mvn clean install -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true

Verify the build

Verify that the command has produced a package in the target folder. 

Screen Shot 2017-07-31 at 14.46.06.png

Put the vRO content under source control

In theory, you can use any kind of SCCS, but here is used Github.

Create new repository

Screen Shot 2017-07-31 at 14.50.30.png

Push the changes

Now you are ready to push changes to your Github repository. This is just an example on how to do it:

git init
git remote add origin
git pull origin master
git add .
git commit -m "Initial vRO package"
git push -u origin master


Continuous Development

Once you have set up your project and added everything under source control, follow this procedure to do incremental changes to your project:

  1. Create a branch in Git.
  2. Checkout the branch using SourceTree or Git cli, or any other Git client.
  3. Build the package and import it in vRO.
  4. Fix an issue or implement a new feature.
  5. "Expand" the package to your file system over the newly checkout branch.
  6. Commit changes to your local branch. (Might do several commits, repeat the steps 5 and 6).
  7. Push the branch to Git.
  8. Create a Pull Request:
    1. Inspect the automatically generated diff;
    2. Add reviewers.
  9. Reviewers inspect the diff and provide comments.
  10. (Optional) Adopt the reviewers suggestions by making new commits with their changes.
  11. Merge the Pull Request.

And there you have it!

Integrating your development environment and source code control system is the first step to proper software development in vRO. Adopting CI/CD will enable you to realize the full potential of agile development and delivery of use cases that fit better to the customers real needs. Following this series of blog posts will help you make it seamless and successful.

Stay tuned!

There are some situations in which you need to trace an issue, resolve a conflict, deploy in a predictable manner, or you have to respond quickly to changes in customer requirements and technology. These situations are often unpredictable and stressful. You may suddenly find yourself fixing the same issues again and again. In a blog post series we will try to identify what struggles you may face while working with vRO and how to address them with less effort and for less time.

Struggle 1: You think you have fixed an issue and it suddenly shows up again. Later, it turns out that someone else, in a good will, has changed the same workflow fixing another issue but overriding your changes.

Struggle 2: A colleague leaves the company and now you have to support his workflow. You have no idea what this workflow is about and how it works. You spend a lot of time trying to understand it and still have some troubles with it. And on top of that, you receive a request from the customer to add a new feature or a bug fix to it.

Struggle 3: You wrote a workflow 2 years ago and now you want to extend its functionality while keeping the old features working. You do the change and send it for testing, everything is fine. A week later, the QA comes with a report and tells you about a use case scenario that does not work any more.

Struggle 4: A solution works flawlessly in your development vRO environment but it does not work in staging. So, you go through each workflow and try to find why. It is like Spot 10 Differences but instead of comparing two pictures you compare two environments, and it takes a lot of time.

Struggle 5: You have to prepare a release package, but every time you miss an action or a resource element and you try to deploy to the staging environment, the package does not work. Or you pull everything from one environment and move it to another, and you are ready 2 weeks before the release. But one feature is still not working as it turns out to be more complex than you originally thought.

If you have ever experienced any of the situations above, you will find this blog post series extremely useful. We will show you how to address these problems by using different techniques and tools. We will focus on the DevOps toolchain phases from Code to Continuous Delivery, we will not discuss how you plan what to do or how you operate the solution.


Once you set up and configure your development environment, it will be really easy to follow the development process, as most of its steps are actually automated. In most cases, you will only interact with your development environment and when ready, you will push the changes to a source code control system, get an approval, and the fix or feature will go to production with no human intervention.

Here are some of the topics we will cover in this blog post series:

  1. Setting up Development environment and Source code control system
  2. Setting up Continuous Integration and Dependency management
  3. Setting up Continuous Delivery
  4. What principles to follow in architecting your solution and how the tools will support you
  5. Why you should write in Javascript and how to do it properly


Stay tuned!