SDK object types can be differentiated from other property types by the colon (“:”) used to separate the plug-in name and the type name. For example, AD:UserGroup is a SDK object type used to manage Active Directory user groups.
By default, you can run up to 300 workflows per node, and up to 10,000 workflows can be queued if the number of actively running workflows is reached.
vRealize Orchestrator 8.x does not currently support memory snapshots. Before taking the snapshot of your vRealize Orchestrator deployment, verify that the Snapshot the virtual machine’s memory option is deactivated.
With the default memory limit of 6000M, you can run approximately 100 Polyglot scripts in parallel. ref
vRO uses JGit for its Git version control system.
Each Workflow run consumes around 4 KB (average), and most objects (for example, vCenter Server object) require around 50 KB each on vRO database.
The JavaScript engine used by vRO Web client UI (including IntelliSense functionality) is not the same engine that vRO server backend uses (Mozilla’s Rhino). There are some minor differences between the two engines, that’s the reason why we see stuff available in the UI but not really available server-side. Watch out!
Version 8.9 onwards, vRealize Orchestrator adds support for the ECDSA algorithm to the list of already available ciphers in the Generate a key pair workflow. This change addresses the default SSH daemon configuration of newer versions of ESXi (7.0.3 and later) that require a stronger encryption algorithm.
While making in-script REST calls, URL must be percent-encoded if it contains one or more special characters.
vRealize Orchestrator Client 8.x tracks the version history of the following vRealize Orchestrator objects:
Workflows
Actions
Packages
Policies
Configuration elements
Resources
ActionBundles (Polyglot actions)
Environments (8.8 onwards)
In vRealize Orchestrator 8.4 and later versions, plug-in development is decoupled from the vRealize Orchestrator platform and you have to download and install the Plug-in SDK on your machine. For earlier versions of vRealize Orchestrator, you can access the SDK through the vRealize Orchestrator Appliance Maven repository.
Encrypted Strings: Before being stored in vRO’s database, the AES-CBC algorithm is used to encrypt the contents of the string. (AES here on Wikipedia). An Initialization Vector (IV) is used as a key to encrypt and decrypt the data.
Two XML parsers are available in vRealize Orchestrator: DOM (legacy) and E4X (dot notation). However, it is strongly recommended to use only E4X. Note: This parser is now deprecated by Mozilla foundation, but as the Rhino engine version used by vRealize Orchestrator is not the latest version, it is safe to use it.
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 does.
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("module.name").action_name() method.
For intensive Presentation Layer operations, there is a cache that you can use to put something into cache or retrieve from cache, this improves performance at an incremental scale. Methods that can be used to access cache are putInCache() & getFromCache().
For workflows that require pausing or sleeping:
For short sleeps, you only need to do a System.sleep() to avoid serializing and deserializing the workflow inputs, attributes, and so on. -> Consumes Mem & CPU cycles for waiting.
Sleeping for an extended period of time should be done with a Workflow sleep, by using a Waiting Timer versus a sleep within a scriptable task. -> Saves WF state in vRO Database while waiting.
XML type is not automatically serialized by vRealize Orchestrator between workflows or actions, it must be converted to string before being used as output of a workflow.
var xmlString = xmlObj.toXMLString();
Command-Line Utility: You can use the Orchestrator command-line utility to automate the Orchestrator configuration. Access the command-line utility by logging in to the Orchestrator Appliance as root over SSH. The utility is located in /var/lib/vco/tools/configuration-cli/bin. To see the available configuration options, run ./vro-configure.sh --help.
Orchestrator is bundled with a fluentd-based logging agent. The agent collects and stores logs so that they can be included in a log bundle and examined later. You can configure the logging agent to continuously forward vRealize Orchestrator logs to vRLI/Syslog servers by using the supplied vracli command line utility (vracli vrli --help).
Orchestrator now ships with cryptographic modules that have successfully passed NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP) testing. When these modules are configured to run in ‘FIPS-mode’, they will cover all cryptographic operations in the product that perform a security function and/or process sensitive data.
The maximum size for a Resource Element in vRealize Orchestrator is 16 MB.
The vRealize Orchestrator Client uses a set of default memory and timeout values for Python, Node.js, and PowerShell action scripts: