I have been dabbling in the world of vRO plugin development. Yes, I know, vRO is a product that doesn't get much love from the VMware community, and I do not think that is fair. People seem to have decided that the product is too complicated and where possible would rather write a PowerCLI script to automate things. The truth is, that when you take a little bit of time to look at vRO, you will find that it is not that complicated to develop vRO workflows and the possibilities are endless. I know, so I'm telling people that vRO isn't that complicated in a blog post which is targeted at myself for when I run into this issue in the future! So, if you are finding workflow development too complicated a task, this post is not for you, as I doubt you will be interested in plug-in development.
I have been developing workflows for a few years, and up until now, I have not come up against an automation problem with vRealize that I could not solve in some way with vRO. However, sometimes I find that the plugins that are available for vRO can in some ways be restrictive, and workarounds have to be made in the vRO workflow development process. These workarounds are in my opinion some of the things that can make workflow development more complicated than need be. If you are unfamiliar with the term plugins, they are the things that provide JavaScript objects and classes that you can use in your workflows in vRO. They, in turn, interact with APIs of external systems via either APIs with Java SDKs or REST APIs. So, to further enhance my abilities with vRO past simply being able to write good functional workflows, I have been thinking about plugin development. What if I can write vRO plugins, especially for APIs for which there aren't any published plugins available? Moreover, what if I can develop a plugin to provide me with those features that the vRA plugin does not provide, or provide in a less than desirable way?
So right from the outset, I hit my first problem. vRO plugin projects are built with Apache Maven, using a published archetype that is provided by your vRO appliance. Maven has an archetype plugin for this. With the JDK and Apache Maven installed, you should be able to build the basic starting point for a plugin with the following command:
mvn archetype:generate -DarchetypeCatalog=https://<vro-server>:8281/vco-repo/archetype-catalog.xml -DrepoUrl=https://<vro-server>:8281/vco-repo -Dmaven.repo.remote=https://<vro-server>:8281/vco-repo -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true
Running the above command on my version of Maven, resulted in Maven not being able to find the archetype catalog as defined in the command. Strange! It turns out that there is a problem in the latest version of Maven and the archetype plugin for Maven (I have Maven version 3.3.9 and maven-archetype-plugin version 3.0.0
To get around the problem, force Maven to use archetype plugin version 2.4 with the following command:
mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate -DarchetypeCatalog=https://<vro-server>:8281/vco-repo/archetype-catalog.xml -DrepoUrl=https://<vro-server>:8281/vco-repo -Dmaven.repo.remote=https://<vro-server>:8281/vco-repo -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true
Ok, so we are good, but we are not. Because now Maven is complaining about not trusting the vRO server SSL certificate. We can fix the SSL issue by following these steps:
1. Using Chrome, download the ROOT certificate of the issuing authority of the server certificate. Save the file in DER format. (.i.e. rootcert.der)
2. If you are using Java JDK 1.8, your CA store should be in %JAVA_HOME%\jre\lib\security\cacerts. Import the ca root certificate (DER file) into the cacerts keystore file with the following command:
%JAVA_HOME%\bin\keytool.exe -import -alias <root-CA-Name> -keystore %JAVA_HOME%\jre\lib\security\cacerts -file C:\temp\rootcert.der
When prompted for a password, enter:
changeit
I hope this helps someone save a few minutes.
