Post

How to setup the workstation for Build Tools for VMware Aria - part 2

In the previous step, we reached a point where we had an empty project with all the default, pre-defined packages and settings. This should look like the following:

project_folder_structure

One important thing to remember is that certain elements, such as types, unit tests, etc., cannot be transferred to vRO. However, Build Tools can convert cool features like Classes and Promises to pure JS, making them compatible with vRO, which is using Rhino Engine to execute JS code.

Folders structure review

By default, when a new project is created, a few default examples are provided (Actions, Config Elements, Workflows, etc.), covering most of the use cases to start with, at least initially.

project_folder_structure

Let’s quickly review what we have in our project:

  • actions - can hold .js and .ts files, which will be converted to the Action Elements
  • element:
    • config - can hold .ts or .yaml files, which will be converted to the Configuration Elements
    • resource - can hold .txt, .json, .yaml, .xml files, which will be converted to the Resources
  • policies - .pl.ts files, which will be converted to the Policy
  • types - .ts files, which will hold the types/interfaces. Not mandatory, but recommended, to store types/interfaces in that folder. Here is an example.
  • workflows - holds .wf.ts and wf.form.json, which will be converted to the Workflow
  • pom.xml - includes all the necessary dependencies and defaults to build the package. This file can be adjusted accordingly to your needs.

Creating a dedicated test folder in /src/test for test files is mandatory to compile and work properly. Unit tests are executed automatically each time we run mvn clean install vrealize:push -Pvro01 if at least one test file is located anywhere in the project.

Workflow cannot be tested. This means less logic and more functions imported from action elements - better. Because actions can be tested.

First push

All the pre-defined files can be removed from your project. They are here just for an example.

Firstly, let’s confirm our ability to communicate with vRO by creating a vRO package and pushing it to vRO. More information can be found here.

1
mvn clean install vrealize:push -Pvro01

Maven will use the NodeJS we installed last time to convert the TS code into the JS code and build the vRO package. Let’s see what is happening:

  • clean - will delete node_modules and target folders and re-generate them based on the latest changes.
  • install:
    • mvn will look in pom.xml, which has all the instructions it needs to build, test, package, and deploy your project in a consistent and automated manner, and will store them in the node_modules folder
    • mvn will generate a target folder and export into all transpiled TS files
    • mvn will generate a package based on the groupId, artifactId and version stored in pom.xml. In our case, the package’s name will be test.test-1.0.0-SNAPSHOT.package. This is an encrypted container, which will be pushed to vRO and extracted there.

project_folder_structure

If, for some reason, target or node_modules should be kept, remove clean from the command: mvn install vrealize:push -Pvro01

  • vrealize:push -Pvro01 - will push created package into vRO instance called vro01 (the same we configured in settings.xml before). -P stands for Profile.

Maven will add a few supporting packages to the main package, like com.vmware.pscoe.library.ecmascript-2.38.0, which are includes all the magic code, that will help vRO “understand” the ECMAScript 6 the features. There are some of the features. At the end, we should see our package in vRO packages menu:

vro_package_structure

If we will open the test package, we’ll see all the files transferred to vRO.

vro_package_structure

Compare those files with the files you have in the VSCode project and see if there are some differences. Usually, there will be fewer files in the package because files like tests or types will not be added.

Tricks

Enable null checking

One of the first things to do is adjust Typescript defaults by adding the following to the tsconfig.json file. This will make our code safer during development.

1
2
3
4
{
  "strictNullChecks": true,
  "strict": true,
}

More information can be found here and here. It’s worth noting that regular npm packages cannot be downloaded and used, so it’s impossible to use Fetch for REST API calls, for example. However, there are a few workarounds that may be helpful. We’ll explore these in more detail later on.

Performance

We can speed up our build a bit if we use more CPU cores. To do that, we need to add to Maven the following switches:

1
mvn -T 1C

-T - thread count, for instance 4 (int) or 2C/2.5C (int/float) where C is core multiplied

Summary

If you did work with vRO for some time, the default state of mind was to use vRO’s canvas, drag the elements into, connect between them, etc. This is what my workflows were look like. Until now.

workflow example

Build Tools for VMware Aria provides a different perspective, allowing us to approach tasks uniquely. We no longer need to create numerous scriptable tasks, each containing a small or large code snippet, linking one task’s output to the next’s input and so on. We no longer use canvas elements like Timer, Exception, Decision, or Counter elements. We can have only one scriptable task containing all our code, replacing all those elements. Additionally, all supporting functions can be (should be) written as Action Elements and imported within our primary scriptable task (see the example here). This approach significantly improves code quality, making it much cleaner and more accessible to test. We can test our main code and all its Action Elements within the same project, ensuring it is far more stable.

That’s how my Workflows are looks now :)

workflow example

The statement above represents my personal viewpoint. You may consider trying it out. It may require altering your mindset and coding habits, which can take some time, but the result is fantastic. If things don’t work out, it’s alright to keep creating multiple elements, linking them together, and so on while still utilizing Build Tools to make them where they are applicable.

In the upcoming section, we will delve deeper into the capabilities of Build Tools for VMware Aria. We will cover fundamental and advanced features, providing you with a comprehensive understanding of utilizing this tool to its fullest potential.

This post is licensed under CC BY 4.0 by the author.