Last month we announced the latest release of vRealize Orchestrator, today I want to dive a little deeper into some of the newly released functionality. To recap, these are the main features vRealize Orchestrator 8.1 brings to the table:
- Git integration – branch configuration support
- Additional scripting languages
- Run and debug actions
- Debug workflow schema
- Graphical comparison of workflow schema
- Tree view
- Remote syslog support
So, without any further pre-amble, let’s get stuck into the features!
Git integration – branch configuration support
vRealize Orchestrator can be configured to synchronise with a specific branch within your git repository, allowing you to manage the progression of Workflows and Actions through environments. For example, this would allow you to synchronise code between a development, staging and production vRealize Orchestrator instance using branches in the same repository. Controlling the release of new content is as easy as merging changes to the respective git branches.
The screen grab below shows the configuration of my git repository (this one’s on Gitlab)
Once the Git repository has been configured, workflow developers can use the VERSION action from within the workflow editor to commit a new version to the repository.
The commit is merged and pushed to the git repository, including the commit title, message and version – the image below shows the commit message from the form above.
Commits, updates and versions stored in Git are also available to view on the Git History page. You can also manually trigger a PUSH (to push local changes to the remote repository) or a PULL (to pull changes in the remote repository to the local vRealize Orchestrator instance).
Any conflicts can be manually resolved with a comparison of the conflicting item and selecting USE THEIRS, USE OURS, or if the conflict is manually resolved, MARK RESOLVED
Additional supported scripting languages
vRealize Orchestrator Workflow and Action developers can now write code in a selection of languages – not just the traditional JavaScript. Python, Node.js and PowerShell are now supported runtimes, and in addition to this you can actually use any of the different runtimes within the same Workflow!
When creating a new Scriptable task within a Workflow, or when creating a new Action, you simply select the runtime to use for development:
Writing a Scriptable task in PowerShell, Python or NodeJS is slightly different when compared to the way the JavaScript engine executes. Developers must define a main handler function that receives a context and inputs object. The context object contains details of the execution, while inputs object contains the input variables. The handler must return an object with that contains the Workflow Item output variables.
For example, below you can see that I’ve created a Workflow called “Polygot Demo” with three scriptable task Workflow Items. The Workflow has one input, a string “Name”. Each Workflow Item has two input variables (Name and strOutput), and one output variable (strOutput). The idea is to manipulate and pass the strOutput variable between the different runtimes.
The code for each of my scriptable tasks is below:
Running the Workflow executes the code in each of the new execution runtimes, passes the strOutput variable between each runtime and adds the runtime name to the string. strOutput’s final value is [PowerShell] [Python] [NodeJS]. Below you can see a successful execution of the Workflow and the logs generated – I’ve highlighted the PowerShell, Python and NodeJS output.
Run and Debug actions
Even in previous versions of vRealize Orchestrator it was not possible to run and debug Actions, you had to drag and drop the Action into a Workflow to manually run and debug it from there. vRealize Orchestrator 8.1 introduces the ability to run and debug Actions directly in the Action editor itself – you simply click RUN or DEBUG. If the Action requires inputs, a simple form is generated to capture them before running or debugging.
Break points can be added to the script (see line 3 above) to pause the execution of the code and allow you to see the value of variables during the Action run, as well as creating “Watch expressions” to be evaluated as you step through the code – for example, I’ve concatenated two variables below and can see the returned value:
Debug workflow schema
Another improvement for Workflow development is the ability to set breakpoints on particular Workflow Items. Similar to break points within Scriptable tasks or Actions, this allows you to run the Workflow in Debug mode and pause execution at the break point.
To set a Workflow schema break point you can hover over a Workflow Item on the Schema pane and select the breakpoint toggle ( 
), or select the toggle in the item configuration pane to the right.
With breakpoints enabled you can evaluate each of the Workflow variables at each breakpoint, and decide to continue, step into, step over, or step return.
For example, in the Workflow below I have set a break point at the Workflow Item named “Step 2”. Since the break point is set on “Step 2” it has not yet executed the code in the Scripting task. You can see this because Variable1 and Variable2 are still at the values set in “Step 1”.
If I click CONTINUE, the Workflow will just continue with normal execution.
If I click STEP INTO I can execute the scripting inside “Step 2” line by line and evaluate watch expressions as described above. I can keep clicking STEP INTO to move line by line through the execution, or I can click STEP RETURN to execute the remaining code in this Workflow Item and move onto the next Workflow Item (“Step 3”) and suspend execution there. 
If I click STEP OVER then “Step 2” will be executed and it will move onto the next Workflow Item (“Step 3”) and suspend execution there. In the screenshot below you can see that “Step 2” has executed and updated the variables’ values, and the execution has suspended at “Step 3”.
Graphical comparison of workflow versions
In addition to being able to compare the code definition between Workflow versions you can now use the VISUAL DIFF to compare how Workflows have changed between versions. This is particularly useful for larger and more complex Workflows where it may not be immediately obvious what’s changed between versions.
You may also notice that when viewing the Version History, vRealize Orchestrator now displays the date/time and version in history, which allows for a much friendlier user experience when you’re looking for versions to compare.
Tree view navigation
Tree view navigation of Workflows and Actions is back! The familiar (and much missed) ability to organise and browse workflows in a hierarchical folder-like fashion is now available in the HTML5 user interface.
Remote Syslog support
In addition to the vRealize Log Insight integration provided in vRealize Orchestrator you can now configure remote syslog support for one or more syslog servers. Remote syslog is configured using the vracli command line tool (for both vRealize Orchestrator embedded in vRealize Automation, and the standalone vRealize Orchestrator appliance).
You can view the configuration using vracli remote-syslog, set named syslog configurations using vracli remote-syslog set, and clear syslog configurations using vracli remote-syslog unset. The screenshot below shows the viewing, creation and setting of syslog servers.
Some example usage:
$ vracli remote-syslog set --agent_id syslog-config1 tcp://10.20.30.40:514
$ vracli remote-syslog set --agent_id syslog-config2 --disable-ssl tcp://10.20.30.40:514
$ vracli remote-syslog set --agent_id syslog-config2 --force udp://10.20.30.40
$ vracli remote-syslog set --agent_id syslog-config3 --ca-file /etc/ssl/certs/ca.crt udp://10.20.30.41
$ vracli remote-syslog --force --agent_id syslog-config1 unset
$ vracli remote-syslog --force unset
Note: Using the –force parameter to set a configuration will overwrite the existing named configuration. Using –force to unset configurations will suppress the confirmation warning.
Conclusion
Whew – congratulations on making it this far – this has been a bit of an epic post! I think you’ll agree that this is a massive release for vRealize Orchestrator, with some features bringing parity with what was previously available, and others that are fantastic new features!
