VCF Automation Blog

from Stefan Schnell

If you are working in secured environments and you do not have the opportunity to work with or to connect external editors or other tools, building an equivalent execution environment in parallel can be very helpful. This post will show local approaches to achieve this in a simple way for the JavaScript execution environment, to support and simplify software development with VMware Aria Orchestrator.

Local Approaches to Simulate
the JavaScript Runtime Environment


The JavaScript runtime environment of VMware Aria Automation bases on the Mozilla Rhino engine 1.7R4, whose detection I explain in more detail here. It is programmed in Java and to execute it Aria Automation uses, up to release 8.14, the Bellsoft JDK 11, whose access I explain in more detail here. After that the JDK 17 from Bellsoft will be used. To build an equivalent environment, it is necessary to download these components. On the one hand, it certainly makes sense to build an environment very similar to the one that exists in Aria Automation. On the other hand, it can also be interesting to use newer releases or other JDKs to see which new possibilities or which different behaviors shows up. These scenarios are considered in more detail below.

Isolated Environments

Before that, we still consider the possibilities of the isolated operation of these equivalent environments. This may be necessary e.g. for IT security reasons or to minimize external influences. Three kinds of environments for isolated operation are available: Each of these approaches offers different advantages and disadvantages and it must be decided individually whether and which one to choose. We should consider isolated execution, also to ensures a higher level of security for software developers, e.g. when experimenting.

In each scenario the usage is very similar, if not identical. After downloading the desired components and unpacking them, only the path to JAVA_HOME must be set and added to the PATH variable. After that the environment is ready for use.

In the following scenarios only a simple helloWorld example is used.

function log(text) {
  java.lang.System.out.println(text);
}

log("Hello World");

Scenario 1

Virtual Machine with Linux, Rhino 1.7R4 and Bellsoft JDK 11

local simulation of javascript runtime environment in a virtual machine with linux

Scenario 2

Sandboxed Windows with Rhino 1.7.14 and Oracle Open JDK 20

local simulation of javascript runtime environment in a windows sandbox

Scenario 3

Virtual Machine with Linux, Rhino 1.7.14 and Bellsoft JDK 21

export JAVA_HOME=~/Dummy/jdk-21.0.1
export PATH=$JAVA_HOME/bin:$PATH
java --version
cd ~/Dummy
java -cp .:rhino-1.7.14.jar org.mozilla.javascript.tools.jsc.Main helloWorld.js
java -cp .:rhino-1.7.14.jar helloWorld
java -cp .:rhino-1.7.14.jar org.mozilla.javascript.tools.debugger.Main helloWorld.js
java -jar rhino-1.7.14.jar
uname -or

local simulation of javascript runtime environment in a virtual machine with linux

Scenario 4

Virtual Machine with Windows, Rhino 1.7R4 and Bellsoft JDK 17

set JAVA_HOME=%PUBLIC%/Dummy/jdk-17.0.9
set PATH=%JAVA_HOME%/bin;%PATH%
java --version
cd %PUBLIC%/Dummy
java -cp .;rhino-1.7R4.jar org.mozilla.javascript.tools.jsc.Main helloWorld.js
java -cp .;rhino-1.7R4.jar helloWorld
java -cp .;rhino-1.7R4.jar org.mozilla.javascript.tools.debugger.Main helloWorld.js
java -jar rhino-1.7R4.jar
ver

local simulation of javascript runtime environment in a virtual machine with windows

Debugging

Another fantastic perspective is the use of the integrated source-level JavaScript debugger. It provides possibilities to set and clear breakpoints, control executions, view variables and observe the behavior of the JavaScript code. E.g. when the Java API is used, it can analyze return structures in detail, especially the deeply nested ones. You can open the debugger with the command

java org.mozilla.javascript.tools.debugger.Main [options] [filename.js] [script-arguments]

debugging window of the rhino javascript engine

Class Emulation Libraries

Now someone could say that these possibilities exclude the use of the Automation API. A very clear yes, that is true. But this disadvantage can be compensated by the use of mock-ups and class emulations, so that a simulative JavaScript execution environment allows us to come very close to reality. Emulations imitate behavior. Yes, it is more costly, but it also gives us a good opportunity to get to know structures better. With the class emulations a simulative environment can be built very similarly to the original environment. This approach gives us the possibility to code and test Actions a bit more independently, without the direct use of an Orchestration environment. This makes adopting the code much easier.

Here a set of classes and objects to emulate VMware Aria Automation objects: Each of these classes includes the methods and properties known from Aria Automation. Some features have been added to provide a more comprehensive offering, which is better adapted to requirements of the local development environment. Each of these classes can be integrated with the load command.

Simulating Aria Automation Calls

To achieve a most realistic reproduction of Aria Automation calls it is necessary to use a shell with the optimization level -1. Here a description how the optimization level can be detected.

VMware Aria Automation uses always the optimization level -1. That means that the interpretive mode of the Rhino engine is used. Therewith the compilation time is minimized at the expense of runtime performance and no class files are generated.

To emulate an equivalent call, the following command must be used.

java -cp ".;rhino-1.7R4.jar" org.mozilla.javascript.tools.shell.Main -opt -1 "%1"

Examples

As a further example, to execute a JavaScript program unmodified in different system environments, a combination of different approaches to get system information.

Conclusion

Using local approaches to simulate the JavaScript execution environment opens up other perspectives in software development for Aria Automation, especially in secure environments. By expanding the possibilities, the approach to certain aspects of software development can be changed. In these cases, it can be simplified and accelerated. The scope of the necessary software and the preparatory activities are very manageable. For these reasons, it can not be wrong to take a look it and bring them into use when needed.