A Primer for vRealize Orchestrator tool by VMware created by Mayank Goyal (https://imtrinity94.github.io)

1. 1
vRealize Orchestrator Training Document
Author: Mayank Goyal
Role: vRO Developer
Key Areas: vSphere, vRO, vRA
Date: 28th
Oct 2018

2. 2
Contents
S. No Title
1. Introduction
2. Orchestrator Architecture
3. Distributed Design
4. Limitations of the JavaScript in Orchestrator
5. Key Features of the Orchestrator Platform
6. Plugins
7. Start Developing with vRO
• Workflow
• API Explorer
• Action
• Policy
• Package
8. Load Balancing/Virtual IP
9. Proxy Workflows
10. vAPI
11. Overview of Operations Client
12. vRO Tweaking
13. Appendix
14. References

3. 3

4. 4
Preface
This documentation describes product concepts of vRO and the tasks that you can perform when you use
vRO to automate common administrative tasks. It lets you create workflows that automate activities such as
provisioning virtual machine, performing scheduled maintenance, initiating backups, and many others. You
can design custom automations based on vRO out-of-the-box workflows and run your automations from
the workflow engine.
Prerequisites for working on vRO:
> Knowledge of Cloud Infrastructure
> Hands-on JavaScript Experience
> Logical Thinking
> ability to hit & trial, googling etc...and lastly not to depress when you are unable to find the right
functions or classes etc....KEEP TRYING
> A little grasp on Linux and Windows PowerShell commands
Note:
VSO (Virtual Service Orchestrator), VMO (VMware Orchestrator), vCO (vCenter Orchestrator) are deprecated names
of vRO (vRealize Orchestrator).
Installation & Configuration of vRO & its interaction with vRA is out-of-scope for this document.

5. 5
Introduction
VMware vRealize Orchestrator is a drag-and-drop workflow software that simplifies the automation of
complex IT tasks. It integrates with VMware vRealize Suite and vCloud Suite® to adapt and extend service
delivery and operational management capabilities as well as with 3rd
Party Solutions. This allows for more
seamless integrations with existing infrastructure, tools and processes.
KEY BENEFITS
• Accelerate Cloud Automation: Integrate VMware solutions into your IT environment and processes to
rapidly accelerate IT operations and management.
• Automation: Reduce IT Operating expenses by designing scalable workflows to automate simple to
complex IT processes.
• Extensibility: Automate management and operational tasks across both VMware and third-party
applications, tools and infrastructure.
Fig: vRO interacting with various entities
VRO offers various types of client/interfaces to allow users/services to interact with Orchestrator server.
• Java Orchestrator Client

6. 6
The most famous client of all. It provides developer the access to Workflow Engine, JS Compiler and other
programming facilities. More about it later in this document.
Accessible at https://<vro_fqdn>:8281/vco
• Operations Client
This Client is available from version 7.5 onwards. Find more detail on Operations Client under “Overview of
Operations Client” later in this document.
Accessible at https://<vro_fqdn>:8283/vco-controlcenter/client
• REST Client (SWAGGER UI)
Allow Web Applications (eg. Service NOW) to communicate with vRO programmatically.
Accessible at https://<vro_fqdn>:8281/vco/api/docs for vRO API
Accessible at https://<vro_fqdn>:8283/vco-controlcenter/docs for vRO Control Center API
• Control Center
This UI console gives admins the power to change the configurations of vRO Server avoiding logging in to
the virtual server itself. One use case can be for optimizing the vRO for medium/large organizations. The
Control Center also contains a collection of Java metrics. To access them, click on Runtime Metrics and then
on Generic. These metrics are also stored every five minutes in
/var/log/vco/app-server/metrics.log
Accessible at https://<vro_fqdn>:8283/vco-controlcenter
• VAMI Interface

7. 7
It is used to perform basic administrative tasks to the appliance configuration. These tasks included
changing the host name, the network configuration, NTP configuration, and applying patches and
updates.
Accessible at https://<vro_fqdn>:5480

8. 8
Orchestrator Architecture
Fig: High Level Architecture (i) & Network Connectivity & Port Specifications (ii)
Orchestrator contains a workflow library and a workflow engine to allow you to create and run workflows
that automate orchestration processes. You run workflows on the objects of different technologies that
Orchestrator accesses through a series of plug-ins.
Orchestrator provides a standard set of plug-ins, including a plug-in for vCenter Server, to allow you to
orchestrate tasks in the different environments that the plug-ins expose.

9. 9
Orchestrator also presents an open architecture to allow you to plug in external third-party applications to
the orchestration platform. You can run workflows on the objects of the plugged-in technologies that you
define yourself. Orchestrator connects to a directory services server to manage user accounts, and to a
database to store information from the workflows that it runs. You can access Orchestrator, the
Orchestrator workflows, and the objects it exposes through the Orchestrator client interface, through a Web
browser, or through Web services.
You can install the Orchestrator server only on a 64-bit operating system platform.
The Orchestrator client can run on both 32-bit and 64-bit Windows machines.
You can install the Orchestrator client on a 32-bit machine.

10. 10
Distributed design
When we talk about distributed, we mean that you have multiple Orchestrator installations that are not in the same
place or not looking after the same things. For example, your main corporate data center sits in Europe and you have
others in North America, Asia, and Oceania.
If you have one Orchestrator sitting in Europe that manages all other centers, the result would be massive problems
from various sources, such as bandwidth, time zones, workflow distribution, and versioning. But that's not the only
example. One can generally differentiate Orchestrator deployments into Geographically Distributed and Logically
Distributed ones:
Geographically Distributed
The use of geographically dispersed Orchestrators is common in large companies. Here, a central Orchestrator
instance executes workflows on remote environments. The amount of bandwidth used to execute a workflow
remotely (using the multi-node plugin) is much less than the amount that would be needed to run the workflows
directly. This is especially true when a lot of input variables have to be collected to run the workflow.
Logically Distributed
Logically Distributed means that your Orchestrators are located in different environments, such as production,
development, and so on. In this case, you may have an Orchestrator infrastructure that creates and manages your
different infrastructure, or is used for deployments or automation. Central management is then also quite important.
Please note that the remote Orchestrator doesn't necessarily have to be paired with a vCenter. A remote
Orchestrator could be used to handle your server, storage, or any other add-on infrastructure services or hardware.

11. 11
Limitations of the Javascript (Mozilla Rhino Implementation) in Orchestrator
Orchestrator implements the Mozilla Rhino 1.6 JavaScripting engine. However, the implementation of Rhino
in Orchestrator presents some limitations.
When writing scripts for workflows, you must consider the following limitations of the Mozilla Rhino
implementation in Orchestrator.
• When a workflow runs, the objects that pass from one workflow element to another are not
Javascript objects. What is passed from one element to the next is the serialization of a Java object
that has a Javascript image. As a consequence, you cannot use the whole Javascript language, but
only those classes that are present in the API Explorer. You cannot pass function objects from one
workflow element to another.
• Orchestrator runs the code in scriptable task elements in a context that is not the Rhino root context.
Orchestrator transparently wraps scriptable task elements and actions into Javascript functions,
which it then runs. A scriptable task element that contains System.log(this); does not display the
global object this in the same way as a standard Rhino implementation.
• You can only call actions that return nonserializable objects from scripting, and not from workflows.
To call an action that returns a nonserializable object, you must write a scriptable task element that
calls the action by using the System.getModule(ModuleName).action() method.
• Workflow validation does not check whether a workflow attribute type is different to an input type of
an action or subworkflow. If you change the type of a workflow input parameter, for example from
VIM3:VirtualMachine to VC:VirtualMachine, but you do not update any scriptable tasks or actions
that use the original input type, the workflow validates but does not run.

12. 12
Key Features of the Orchestrator Platform
Orchestrator is composed of three distinct layers: an orchestration platform that provides the common
features required for an orchestration tool, a plug-in architecture to integrate control of subsystems, and a
library of workflows. Orchestrator is an open platform that can be extended with new plug-ins and libraries,
and can be integrated into larger architectures through a SOAP API.
The following list presents the key Orchestrator features.
1. Persistence: Production grade external databases are used to store relevant information, such as
processes, workflow states, and configuration information.
2. Central management: Orchestrator provides a central way to manage your processes. The
application server-based platform, with full version history, allows you to have scripts and process-
related primitives in one place. This way, you can avoid scripts without versioning and proper
change control spread on your servers.
3. Check-pointing: Every step of a workflow is saved in the database, which allows you to restart the
server without losing state and context. This feature is especially useful for long-running processes
4. Versioning: All Orchestrator Platform objects have an associated version history. This feature allows
basic change management when distributing processes to different project stages or locations.
5. Scripting engine: The Mozilla Rhino JavaScript engine provides a way to create new building blocks
for Orchestrator Platform. The scripting engine is enhanced with basic version control, variable type
checking, name space management and exception handling. It can be used in the following building
blocks:
o Actions
o Workflows
o Policies
6. Workflow engine: The workflow engine allows you to capture business processes. It uses the
following objects to create a step-by-step process automation in workflows:
o Workflows and actions that Orchestrator provides.
o Custom building blocks created by the customer
o Objects that plug-ins add to Orchestrator
7. Policy engine: The policy engine allows monitoring and event generation to react to changing
conditions in the Orchestrator server or plugged-in technology. Policies can aggregate events from
the platform or any of the plug-ins, which allows you to handle changing conditions on any of the
integrated technologies.
8. Security: Orchestrator provides the following advanced security functions:
o Public Key Infrastructure (PKI) to sign and encrypt content imported and exported between
servers
o Digital Rights Management (DRM) to control how exported content might be viewed, edited
and redistributed

13. 13
o Secure Sockets Layer (SSL) encrypted communications between the desktop client and the
server and HTTPS access to the Web front end.
o Advanced access rights management to provide control over access to processes and the
objects manipulated by these processes.

14. 14
Plugins
This is a list of what a plug-in can provide, not all the features are mandatory.
• Objects and methods on the orchestrated technology.
• A hierarchical inventory of these objects.
• Choosers and pickers to be able to select these objects.
• Events on object states and gauges.
• An API documentation for using these.
• Scripts for function level functionality.
• Workflows for higher level operations.
• Transparent session management.
• Object caching.
• Object persistence.
Java is the language used to develop plug-ins. You can bridge Java to other technologies using standard
communication interfaces and bridge technologies.
In the below diagram, please notice the plugins in blue box. These plugins come by default with the
installation of Orchestrator server. Each plugin has a set of workflows which can be find under Library
workflow category in vRO.

15. 15
Start Developing with vRO
On a typical day of a vRO developer, first thing he sees is this.
This is the vRO Java Client which exposes the JavaScript Engine to the users in the form of scripting
elements. As we have read, a developer can code into vRO via actions, workflows or policies. All these 3
elements are few of what vRO offers to the users. Other than area for hand-written codes, it provides many
out-of-the-box functionalities which helps the developer to code faster, effectively, neatly as well as less
error-prone. We will go through this Java Client and all its functionalities in an exhaustive manner.
The Orchestrator Client has three modes: Run, Design, and Administer. The setting can be changed by
selecting the value from the top drop-down menu. You will use the Orchestrator Client mostly in the Design
mode when you program. If you are a user, you probably will use the Run mode.

16. 16
Icon Use(s)
My Orchestrator Overview & non-admin access
Scheduler Mgmt. Of Scheduled WFs
Policies An Event Trigger
Workflows Manage WFs and everything related to them
Inventory Shows all plugins & objects they have access to/exposes
to vRO
Actions Manage actions & everything related to them
Resources A file(any) that can be used by WFs
Configuration Centrally defined attributes that are available to WFs
Packages It contains WFs, actions, etc to allow export/import of
Orchestration Solutions
Policy Templates Templates for Policies
Authorization (Deprecated) leftover

17. 17
Workflow
A workflow is a series of actions and decisions that you run sequentially. Orchestrator provides a library of workflows that
perform common management tasks. Orchestrator also provides libraries of the individual actions that the workflows
perform.
Workflows combine actions, decisions, and results that, when performed in a particular order, finish a specific task or a
specific process in a virtual environment. Workflows perform tasks such as provisioning virtual machines, backing up,
performing regular maintenance, sending emails, performing SSH operations, managing the physical infrastructure, and
other general utility operations. Workflows accept inputs according to their function. You can create workflows that run
according to defined schedules, or that run if certain anticipated events occur. Information can be provided by you, by
other users, by another workflow or action, or by an external process such as a Web service call from an application.
Workflows perform some validation and filtering of information before they run.
Workflows can call upon other workflows. For example, you can reuse in several different workflows a workflow that starts a
virtual machine. Workflows are tied in with each other via their ID (which can't be changed and is unique) and not their
name. So, renaming or moving a workflow has no impact.
You create workflows by using the Orchestrator client interface’s integrated development environment (IDE), that provides
access to the workflow library and the ability to run workflows on the workflow engine. The workflow engine can also take
objects from external libraries that you plug in to Orchestrator. This ability allows you to customize processes or implement
functions that third-party applications provide.

18. 18
You create and edit workflows by using the workflow editor. The workflow editor is the Orchestrator client's IDE for
developing workflows.
Various operations that can be performed during workflow editing can be step-by-step referenced from vRO
development guide. For ex. Scheduling WFs, debugging, Validating, user permissions etc.
Key Concept of Workflows
Workflows consist of a schema, attributes, and parameters. The workflow schema is the main component of a
workflow as it defines all the workflow elements and the logical connections between them. The workflow attributes
and parameters are the variables that workflows use to transfer data. Orchestrator saves a workflow token every time
a workflow runs, recording the details of that specific run of the workflow.
Workflow Parameters Workflows receive input parameters and generate output parameters when they run.
Input Parameters Most workflows require a certain set of input parameters to run. An input parameter is an argument
that the workflow processes when it starts. The user, an application, another workflow, or an action passes input

19. 19
parameter to a workflow for the workflow to process when it starts. For example, if a workflow resets a virtual
machine, the workflow requires as an input parameter the name of the virtual machine.
Output Parameters A workflow's output parameters represent the result from the workflow run. Output parameters
can change when a workflow or a workflow element runs. While workflows run, they can receive the output
parameters of other workflows as input parameters. For example, if a workflow creates a snapshot of a virtual
machine, the output parameter for the workflow is the resulting snapshot.
Workflow Attributes Workflow elements process data that they receive as input parameters, and set the resulting data
as workflow attributes or output parameters. Read-only workflow attributes act as global constants for a workflow.
Writable attributes act as a workflow’s global variables. You can use attributes to transfer data between the elements
of a workflow. You can obtain attributes in the following ways: n Define attributes when you create a workflow n Set
the output parameter of a workflow element as a workflow attribute n Inherit attributes from a configuration element
Workflow Schema A workflow schema is a graphical representation that shows the workflow as a flow diagram of
interconnected workflow elements. The workflow schema is the most important element of a workflow as it
determines its logic.

20. 20
Workflow Presentation When users run a workflow, they provide the values for the input parameters of the workflow
in the workflow presentation. When you organize the workflow presentation, consider the type and number of input
parameters of the workflow.
Tip: vRO Presentation layer allows use of OGNL expressions #{Variable_Name}.
Workflow Tokens A workflow token represents a workflow that is running or has run.

21. 21
For attributes and parameters, use CAPITAL_CASE and for internal variables, use camelCase.
Workflow Version Control Version control is a very important tool in software development. It not only helps you
keep track of your code development, but also helps you in other ways. For instance, when you import a workflow or
a package, you can directly see whether the import is newer or older than the existing one. The other thing is that
you can check versions against each other, as well as revert to different versions. You can use the revert function to
make duplicates of older versions.
Tip: Version control is available for Workflows, Actions, Configurations, Resources, and Policy Templates.
Standard Workflows in the Workflow Library
Orchestrator provides a standard library of workflows that you can use to automate operations in the virtual infrastructure.
The workflows in the standard library are locked in the read-only state. To customize a standard workflow, you must create
a duplicate of that workflow. Duplicate workflows or custom workflows that you create are fully editable.
The contents of the workflow library is accessible through the Workflows view in the Orchestrator client. The standard
workflow library provides workflows in the following folders.
Configuration
Configure authentication settings, database, certificates, licences, and troubleshoot Orchestrator.
JDBC
Test the communication between a workflow and a database by using the SQL plug-in shipped with Orchestrator.
Locking
Demonstrates the locking mechanism for automated processes, that allows workflows to lock the resources they use.
Mail
Send and receive emails from workflows.
Orchestrator
Automate certain common Orchestrator operations.
SQL
Manage databases and database tables, as well as run SQL operations.
SSH
Implement the Secure Shell v2 (SSH-2) protocol. These workflows allow you to run remote command and file transfer
sessions with password and public key-based authentication. The SSH configuration allows you to specify paths to objects
to expose in the Orchestrator inventory through secure connections.
Troubleshooting

22. 22
Export application settings and log files to a ZIP archive that you can send to VMware support for troubleshooting.
vCenter Server
Access the functions of the vCenter Server API, so that you can incorporate all of the vCenter Server functions into the
management processes that you automate by using Orchestrator.
Workflow documentation
Export information about workflows or workflow categories as PDF files.
XML
A Document Object Model (DOM) XML parser that you can use to process XML files in workflows.
API Explorer
To be efficient in programming using Orchestrator plugins, one needs to know how to work with the
Orchestrator API.
The API Explorer opens, and you have four sections, as marked in the preceding screenshot:
A (search): Here, you can enter a search word, such as virtualmachine, as well as select what kinds of results
you are after.
B (search results): This section shows you the result of the search: the name, the type (refer to the How it
works... section of this recipe), and a short description.

23. 23
C (API tree): Double-clicking on a search result in section B will browse the selected result and open the API
tree on that element.
D (detail): Clicking on an item in section C will show a more detailed description of the item in the API.
The Orchestrator API contains all types, methods, attributes, objects, and so on that can be used for
programming. All the content comes from Orchestrator or its plugins and gives the Orchestrator
programmer a wide range of tools to use.
As you can see in the preceding showcase, the items in the API are color-coded; the following table shows
you all the item colors along with a short description of their meaning:
Icon Name Usage
Gray bullet Type Types are complex variables.
Purple bullet Function set A set of functions that centers on
certain topics, for instance, the
System function set that contains
the .log and .warn methods.
Blue Bullet Primitive A primitive is a basic variable
type. These are array, function,
number, object, secure string,
string, Boolean, and char. String
and array contain methods.
Green bullet Object Objects contain attributes,
constructors, and methods.
Gray and blue gear Module Modules contain actions.
Color icons SDKModule SDKModule is part of the plugins
and contains types and objects.
C-shaped icon Constructor A constructor creates a new
entity of a given type.
Sometimes, there is no
constructor; in this case, you can
try to copy and paste the parent
object.
Empty square Attribute An attribute is a property of an
object; it can be either read-only
or read-write.
FILLED SQUARE Method The function (action) that is
implemented with the object and
acts on square the object.

24. 24
Actions
Actions are what programmers call functions. It is a piece of code that you intend to reuse often in different
programs.
There are multiple differences between a workflow and an action. The main difference is that an action can
return only one variable, whereas a workflow can return multiple variables. Another difference is that actions
are purely JavaScript-based and do not contain any visual programming.
In an action, the in-parameters are defined the same way as in a workflow. However, the return type is a bit
different. The return code is always one variable and its value is assigned by using the JavaScript return
command. If you don't want or need any return code, define the return code as void.
When you create an action, you must use basic guidelines.
• Every action must include a description of its role and function.
• Write short, elementary actions and combine them in a workflow.
• Avoid writing actions that perform multiple functions, because this limits the potential for reusing the
action.
• Avoid actions that run for long periods of time. Instead, create a loop in the workflow and include a
Waiting Event or Waiting Timer element after the action element.
• Do not write check points in actions. Workflows set a check point at the start and end of each
element's run.
Avoid writing loops in an action. Create loops in the workflow instead. If the server restarts, a running
workflow resumes at its last check point, at the start of an element. If you write a loop inside an action and
the server restarts while the workflow is running that action, the workflow resumes at the check point at the
beginning of that action, and the loop starts again from the beginning.
• Start action names with a lowercase letter. Use an uppercase letter at the beginning of each
conjoined word in the name. For example, myAction.
• Make action names as explicit as possible, so that the function of the action is clear. For example,
backupAllVMsInPool.
Use the inverse Internet address format for module names. For example,
com.vmware.myactions.myAction.

25. 25
Policy
Policies monitor certain events in the plugged-in technology and start operations in the Orchestrator server
if the events occur. Policies can monitor policy triggers and policy gauges. Policy triggers define an event in
the plugged-in technology that, when it occurs, causes a running policy to start an operation in the
Orchestrator server, for example running a workflow. Policy gauges define ranges of values for the
attributes of an object in the plugged-in technology that, when exceeded, cause Orchestrator to start an
operation. Policies are optional.

26. 26
Package
You export workflows, policies, actions, plug-in references, resources, Web views, and configuration
elements in packages. All elements that an element implements are added to the package automatically, to
ensure compatibility between versions. If you don't want to add the referenced elements, you can delete
them in the package editor.
Prerequisites
Elements such as workflows, actions, and policies to add to a package.
Procedure
1. In the Orchestrator client, click the Packages view.
2. Click the menu button in the title bar of the Packages list and select Add package.
3. Name the new package and click OK.
The syntax for package names is domain.your_company.folder.package_name. For example,
com.vmware.myfolder.mypackage.
4. Right-click the package and select Edit.
The package editor opens.
5. Add a description for the package in the General tab.
6. Click the Workflows tab to add workflows to the package.
7. Click Insert Workflows.
(Optional) Click the Policies, Actions, Web View, Configurations, Resources, and Used Plug-Ins tabs to add
policy templates, actions, Web views, configuration elements, resource elements, and plug-ins to the
package.

27. 27
Load Balancing/Virtual IP
Load-balancing is a method by which a central unit (the load-balancer) is contacted by the user instead of
one of the Orchestrator installations. The load-balancer has two functions. The first is to check the
availability of the underlying Orchestrators for that, the load-balancer is checking each Orchestrator's health
status by contacting https://[vro]:8281/vco/api/healthstatus. If the Orchestrator service is alive then it will
respond with the following:
<node-status xmlns="http://www.vmware.com/vco">
<state>RUNNING</state>
<health-status state="OK" time="1463231814183"/>
<instance-id>9d40b766-e278-4f6c-8fa1-ab143d5b73e7</instance-id>
The other function of a load-balancer is to forward the connection request to one of the active
Orchestrator nodes. The method we should use for this with Orchestrator is called Round-
Robin, which will give a connection to the next available Orchestrator node. For example, if
there are three active Orchestrators (vro1, vro2, and vro3) then the first request will be given
to vro1, the next one to vro2, then to vro3, and then again to vro1, and so on.
The following settings are usable for all load-balancers. The settings may be called
something slightly different, but they all function in the same way:
Setting Value
Health check protocol HTTPS
Health check link GET/vco/api/healthstatus
Health check return RUNNING
Health check interval 3 sec
Health check timeout 9 sec
Health check max retries 3
Load-balancing mechanism Round-Robin
Load-balancing port 8281
SSL certificate Offload or passthrough
SSL persistency None
Note: VMware NSX can be used to deploy load-balanced vROs. Other tools are F5 etc.

28. 28
Managing remote Orchestrators via Multi-Node Plugin (Proxy Workflows)
The Multi-Node plugin will allow developers to manage other Orchestrators in a distributed design. It is
also quite important that both Orchestrator instances are compatible with each other, meaning they should
preferable be of the same version and build.
We will call the first Orchestrator installation the local Orchestrator, and the one we add will be called the
remote Orchestrator. The remote Orchestrator can be a cluster.
Adding an Orchestrator server requires start the workflow in Library | Orchestrator | Server Management |
Add an Orchestrator server in the local orchestrator. After the workflow has successfully finished, go to the
inventory and have a look under the vRO multi-node plugin. There, you will find all the items that exist in
the remote Orchestrator.
Creating proxy workflows
1. Using the local Orchestrator Client, start the workflow by navigating to Library |
Orchestrator | Remote Executions | Create a proxy workflow.
2. Select the remote workflow you would like to use. Click on Next.
3. Choose to create proxy workflows that are executed synchronously (Yes) or asynchronously (No).
Synchronous means that Orchestrator will wait until the workflow is executed completely (use the default,
which is Yes).
4. Wait until the workflow has finished. Then, check whether the new folder has been created in the
workflow tree called VRO@[IP or FQDN Orchestrator]:8281, as well as the workflows under it.
5. Now, execute one of the proxy workflows. When finished, check on both Orchestrators; you will find that
the proxy workflow will have executed on both sides. However, log messages and variable tracking will only
be in place on the remote server.
6. It's a good idea to go and check what happened on the remote Orchestrator. Look at the execution and
the logs.
Instead of just creating one proxy workflow, you can create proxies of all the workflows of the remote
Orchestrator by navigating to Library | Orchestrator | Remote Executions | Server Proxies | Create proxy
workflows for an Orchestrator Server, or a workflow folder, Library | Orchestrator | Remote Executions |
Create proxy workflows from a folder.
Also, note that you can refresh the proxy workflows. This will make sure that changes in the input or output
variable are synced to the proxy workflows.

29. 29
Managing packages on the remote Orchestrator
Another useful function is the ability to deploy packages to remote servers. Perform the following steps:
1. Using the local Orchestrator Client, start the workflow by navigating to Library | Orchestrator | Remote
Management | Packages | Deploy a package from a local server.
2. Select the package you would like to deploy from the local Orchestrator to the remote Orchestrator.
3. When selecting the remote server, you are actually able to choose multiple remote Orchestrators. An
array window will open; select Insert Value. An additional popup will show up here; select the remote
Orchestrator and click on Add.
4. The chosen package is now installed on the remote Orchestrator.
The multi-node plugin can be used in quite a lot of situations. The first and foremost is to manage remote
servers that are in a cluster. Using the Multi-Node Plugin, we can now manage the Orchestrator clusters
workflows and packages as shown in the following image:
Another good idea is to make sure that workflows, or basically any other Orchestrator element (by building
a specific workflow), are replicated between Orchestrator installations. For example, for load-balancing or
audit reasons, you have multiple Orchestrator servers and you need to make sure that elements are the
same on all of them.
A very common use of the multi-node plugin is for maintenance work, such as cleaning out all finished
workflows from remote Orchestrators.
Last but not least, you can execute workflows from a different Orchestrator. For example, you can write a
workflow that automatically configures a new Orchestrator installation.
As a last note, when you delete an Orchestrator server using the workflow by navigating to Library |
Orchestrator | Server Configuration | Delete a vCO Server, all the proxy workflows of the remote
Orchestrator will also be deleted from the local Orchestrator.

30. 30
VAPI (Extension to vCloud Suite SDK)
With vSphere 6, VMware also released the vAPI. The vAPI is a REST-based package that is actually called
VMware vCloud Suite SDK. At this stage it has some limited functionality such as tagging, transfer services,
and access to the content library; however, VMware has announced that functionality will be increased in the
future.
As VMware (and lots of other vendors) are moving towards a REST-based API, the common old SOAP API
of vCenter will be replaced more and more with the vAPI. However, never fear: too much money and effort
has been sunk into vCenter API programming for it to vanish overnight.
The most interesting thing about the vAPI is the way that the API content is delivered. Traditionally, the API
content is included in the plugin, but with the vAPI, you import the content and the metamodel. This makes
it possible to have one plugin to handle multiple API contents. It is reminiscent of the SOAP model, where
the API documentation is contained in the interface.

31. 31
Overview of vRO Operations Client
Using this new VMware vRealize Orchestrator Operations Client provides information about the workflow
automation features and functionality of the new Orchestrator HTML5 client. It is intended for experienced
system administrators who are looking for a tool that can help them to run and manage Orchestrator
workflows and not for vRO Developers/Workflow Designers as workflow editor is missing from this new
client as of now. In other words, it cannot replace the existing Java Client.
Use the new HTML5 user interface to manage Orchestrator services.
You can monitor, troubleshoot, and run workflows by using the Orchestrator Operations Client. The
Operations Client supplements the functionality of the existing Orchestrator Java Client and does not
replace it. You can find the Operations Client at https://your_orchestrator_server_ip_or_dns_address:8283
REST API communication
The Orchestrator Operations client runs on the Orchestrator Control Center server. The client
communicates with the Orchestrator REST API through a REST proxy.
Run and manage workflows
Run Orchestrator workflows and view recent workflow runs.
Scheduling workflows
Automate workflow operations by creating and editing scheduled workflow tasks in the Operations Client.

32. 32
Optimize workflows by using metric data
Use the profiling feature of the Operations Client to gather useful metric data about your workflow runs.
Package management
Export and import packages containing workflow elements through the Operations Client.
Note: Creating and deleting packages is done by using the Orchestrator Java Client.
Roles management
Users with administrator rights can assign roles to users in the Operations Client.
Workflow element management
View workflow action elements, the plug-in inventory, and workflow tags available in your Orchestrator
deployment. Import resource and configuration elements.
API Explorer
Explore the API commands available in Orchestrator. The API Explorer includes a list of the Orchestrator
complaint RESTful objects. The API explorer includes information about the attributes, constructors, and
HTTP methods associated with a specific object.
*Performance View
Viewing workflow runs in Performance View provides useful metric data.
Metric Description
Duration The total duration of the workflow run.

33. 33
Size (Bytes) The size of the workflow token stored on the database. This metric can be used to
evaluate the resource price of checkpointing workflow runs.
CPU Times Captures the runtime of the workflow run thread.
Note:
If the workflow is suspended during the run, like when the workflow is waiting for further
input, this metric only captures the runtime thread that occurs before completion.
Plugin Times Displays the names and total runtime of the plug-ins used by the workflow run.
* most important feature of Operations Client

34. 34
vRO Tweaking
I have found these tweaks that can be helpful to gain more control on vRO functionalities.
1. Enable access to vRO internal filesystem from vRO Client
vCO allows limited access to its local filesystem. The access is determined by the js-io-rights.conf file
found in /etc/vco/app-server/ folder on the appliance.
+rwx /working_directory/
working_directory – the Linux directory from where the WFs will read/write.
As you can see, Orchestrator has full access preconfigured for the /var/run/vco directory.
2. SOAP Operation Auto-Generated Workflow
The workflow can be auto-generated when you right-click an Operation from the vCO SOAP
Inventory and choose the option to Generate workflow. This could be of great help either as
reference or to use directly.
3. Enable Contextual Menu
If you enable the Use contextual menu in inventory option from the Inventory tab of the User
preferences tool, all of the workflows that you can run on the selected inventory object appear in a
pop-up menu.
4. Use of action elements for faster execution
When you define actions independently from the workflows that call on them, you can update or
optimize the actions more easily. Defining individual actions also allows other workflows to reuse
actions. When a workflow runs, Orchestrator caches each action only the first time that the workflow
runs it. Orchestrator can then reuse the cached action. Caching actions is useful for recursive calls in
a workflow, or fast loops.
5. Workflow run logs are not shown in Java Client.
Workflow run logs might be missing in the Orchestrator Java Client. To see the workflow logs, restart
the Orchestrator server service.
6. Orchestrator Client and 4K display scaling
This recipe shows a hack to make the Orchestrator Client scale on 4K displays.
a. Download and install Resource Tuner.
b. Run Resource Tuner as administrator.
c. Open the file javaws.exe in your Java directory.

35. 35
d. Expand manifest and then click on the first entry (the name can change due to localization).
e. Look for the line <dpiAware>true</dpiAware>.
f. Exchange the true for a false
g. Save and exit.
h. Repeat the same for all the other java*.exe in the same directory as well as j2launcher.exe.
i. Start the Client.jnlp (the file that downloads when you start the web application).
In Windows 10 you can set the scaling of applications when you are using high definition monitors
(4K displays). What you are doing is telling Java that it is not DPI aware, meaning that it will use the
Windows 10 default scaler, instead of an internal scaler.

36. 36
Appendix
Attribute and Parameter Naming Restrictions
You cannot use the following keywords in workflow attribute and parameter names.

37. 37
Useful References
• https://www.vcoteam.info
• www.vroapi.com
• https://ssbkang.com