Furthermore, I hope that the client will be developed further, to fulfill our needs as vRO enthusiasts. Please don’t be irritated by the fact, that I am using the embedded vRO of vRealize Automation 8, because I am planning a series of articles for that product too.This article can be considered as part 2 to my previous one, and I will not discuss content already available in part 1, except: I still would like to see a tree view again. Finding workflows only using tagging is horrible. Let’s discuss why. I had the need to attach a vCenter Server to vRO. In the past, I navigated into the library, vCenter, configuration, done. Now I had to know the name of the workflow. Guess what, took me a couple of minutes to basically find it.
First starting with a very simple workflow, just writing to the log. What’s really funny is, that, if you use the cursor keys to navigate in the scripting pane, the selected element in the schema moves around as well. That is kind of weird, because I tend to arrange my schema elements in a certain way and I don’t want them to move afterwards, by just using the cursor keys. Furthermore, no mechanism to snap elements to the grid is missing too.
On the other hand, finally we have auto completion or auto suggestion in place. I like that. I am aware, that it was there in the Java client, but you had to press CTRL+Space to activate it. Now it kind of feels like an IDE.
Also having variables, declared inside the code, in the auto completion menu is very good and improves the IDE like feeling.
What I don’t like, because I am used to it for a long time, is the fact, that bound variables are not displayed using a different color anymore. Yes, they can be added by just clicking on them in the top row and yes, they are also part of the auto completion menu, but I would like to have them highlighted in the code again. My opinion is, that this would improve doe readability but immediately knowing if a variable is declared inside the code or bound from the workflow.
I am a huge fan of using workflow notes to visualize certain areas of a workflow containing elements for a specific larger task. In the Java client, we were able to change the color of the note itself, but that has gone. Now all workflow notes are yellow. Doesn’t sound like a big deal, I think having different colors back would be a great improvement. Furthermore, double-click allows me to change the text, but afterwards you have to click outside to persist the change. If you hit Enter after entering the text, the change is lost, and the default text is displayed instead. Should be changed too.
Very interesting, what happened right now: if you’re not clicking “Save” all the time and get logged out, all changes are gone. That is really bad, be careful! Need to check if there is a possibility to change the default logout timer to disable for example. Why is that important? From my point of view, it happens that you get distracted and forget to click Save, coming back to your computer, all changes are lost.
Another feature which is missing, at least my point of view, if you click save the version of the workflow is not increased anymore. That needs to be done manually. I know, people have different opinions on that, but I would like to have this option back, clicking Save, vRO asks me if I would like to increase the version. In the old client, that was configurable.
In the HTML5 client, we have two options. Either navigate to the Summary tab of the workflow and manually provide a version number, which is only inside vRO, or click the Version button at the bottom left corner and commit the workflow with a title, message, and number. The second option is used for GitHub which is now natively integrated, which is pretty cool.
GitHub commit:
Back to our schema and workflow development. Decisions have changed a bit. In the past we had a decision and a custom decision element. They have been combined into a single element called Decision.
As marked, by default a Decision behaves like a custom decision compared to the Java client. We can add inputs and write code to decide which path to use. If you would like to have a decision needing a Boolean input, just flip the switch to Simple.
The “new” simple decision offers more flexibility compared to the decision we had in the Java client as shown in the next screenshot.
As we can see, using simple we can bind a variable of, I guess, any simple type and use a comparison. If the comparison is true, the green path is taken. That might ease things for some people, and I think this new implementation is a very good idea.
Already mentioned binding a bit. In the HTML5 client, the visual binding option is no longer available. To be honest, I haven’t used it a lot to create the binding, but for an overview it was really good. I would like to see that again in the new UI.
Speaking about variables: a huge missing feature is the ability, to move attributes to either input or output, and vice versa. That is completely missing. My opinion, this is a must have during workflow development, because it changes from time to time.
The version history tab allows us to compare two different workflow versions as code including highlighting. I think that is great, because in the past, you had to know what you’re looking for to find the difference, now the code includes highlighting and exact positioning which makes it very useful.
After building a workflow we need to test it. Simple click on run. That moves us to the “Workflow Runs” section of the UI. On the one hand, that’s where workflow runs are stored, but on the other hand, if we need to change something in code because the result wasn’t as expected, you need to click the workflow now in the top left of the pane. Otherwise you are not brought back to your workflow. I would say that is a UI behavior we need to get used too, it’s neither useful nor weird.
Let’s have an additional look at the Summary page of a workflow, especially the tags.
Tagging is great, no discussion about that, but the implementation is not ideal. Within the summary tab we can add and create tags for workflows. Cool, they enable us to group workflows, find them faster (if we remember the tag name), use the tags whilst adding workflow as elements in the schema of other workflows, and so on. Overall, sounds great, doesn’t it? BUT, dear VMware, in the whole vRO UI, there is no section providing an overview or summary view of all the tags available in the system. I guess, after a while working with an Orchestrator instance, we end up having multiple tags for the same purpose, because we just can’t remember which ones we’ve already created. At least I’ll end up like this, because there is no overview available.
Now I discovered something in the menu which brings up new hope. A dedicated API Explorer compared to the one we had in the Tools menu in the old client.
In the past I was picking on the API explorer being available in the scriptable task. New hope is rising opening the “dedicated” API explorer. Good thing, it automatically opens in a new browser tab. Remember, navigating away or getting logged out discards all changes made without saving. The API explorer looks different, but all functions we previously had, are available. Hope has been destroyed within a minute, because this one is not alphabetically sorted too. Sadly, that makes it unusable too. At least I desperately need a working API explorer inside the vRO UI. I know, there are external tools provided a better look and feel, faster search, …. - but only for the vSphere API. What if we need to deal with other products connected to vRO via a plugin?
Alright guys, I tried to provide a more in-depth view on the new HTML5 vRO UI on things which are working, and things are not working and yes, I am aware of, that this article is not covering every single aspect of the new client. Please feel free and send me comments if I missed something important. More than happy to add it to this article. I hope that VMware picks up some ideas or comments to improve vRO further.
Have fun reading and keep automating!!
