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, to support and simplify software development in the Orchestrator. This post will show local approaches to achieve this in a simple way, for the JavaScript execution environment.
The JavaScript runtime environment of VMware Aria Automation bases on the Mozilla Rhino engine 1.7R4. It is programmed in Java and to execute it, Aria Automation uses the Bellsoft JDK 11. To build an equivalent environment, it is necessary to download the desired 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 two scenarios are considered in more detail below.
Before that, we still consider the possibilities of the isolated operation of these equivalent environments. This may be necessary, on the one hand for IT security reasons and on the other hand 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.
// Begin----------------------------------------------------------------
function log(text) {
java.lang.System.out.println(text);
}
log('Hello World');
// End------------------------------------------------------------------
Now one or the other may object 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. This allows us to come very close to reality. Yes, it is more costly, but it also gives us a good opportunity to get to know structures better.
Another fantastic perspective is the use of the integrated JavaScript debugger. When the Java API is used, it can be used to analyze return structures in detail, especially the deeply nested ones.
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.
Thanks for posting this. I've always thought there must be a better way to develop code for vRO JavaScript than using the web GUI. I think this might nicely complement vRBT and vRDT in making the developer experience more devops IaC-ish, especially if this could be used for unit testing.
Announcing Build Tools for VMware Aria: DevOps capabilities for your Aria Suite content
https://blogs.vmware.com/management/2023/02/announcing-build-tools-for-vmware-aria-devops-capabiliti...