DevOps & Automation

Practical guides and lessons from the field.

Follow via RSS

2025

Articles & guides

Empower VCF Operations Orchestrator API integration with HttpRestClient

The HTTP-REST plugin in VCF Operations Orchestrator represents API endpoints as RestHosts in the inventory. After defining a RestHost, you can authenticate and send HTTP requests such as GET and POST to its endpoint. HttpRestClient handles common request tasks, including content types, errors and retries. HttpRestClient provides these features: HttpRestClient provides shared request handling between Orchestrator and API endpoints. It is designed to integrate with or extend any API service. You can download my HttpRestClient module as a package here or as native JS here. Import HttpRestClient into an action or workflow using one of these approaches: As a variable: As an object property: Alternatively, extend the class using classical inheritance: Parameters: The code creates an HttpRestClient instance in rest. Use this variable for API calls, or rename it if needed. Use one of the following methods to make an API call: rest.httpGet(uri, acceptType, expectedResponseCodes, headers) → {*} Parameters: Returns the request response object. rest.httpPost(uri, acceptType, content, contentType, expectedResponseCodes, headers) → {*} Parameters: Returns the request response object. rest.httpPut(uri, acceptType, content, contentType, expectedResponseCodes, headers) → {*} Parameters: Returns the request response object. rest.httpPatch(uri, acceptType, content, contentType, expectedResponseCodes, headers) → {*} Parameters: Returns the request response object. rest.httpDelete(uri,…

4 min read

Logger for better Logs in VCF Operations Orchestrator

VCF Operations Orchestrator cannot dynamically include an action or sub-workflow name in console logs. The expression this.workflow.name returns the top-level workflow name, even inside sub-workflows and actions. I described my solution on SimplyGeek several years ago. I still consider it the best option and believe it avoids these logging limitations. My Logger class provides consistent logging across actions and workflows. Import it wherever you need to identify the source of a message. You can download my Logger module as a package here or as native JS here. This example uses Logger in addComputerToAD, an action that adds a computer object to Active Directory: The output identifies messages from addComputerToAD and the actions it calls, with INFO, DEBUG and WARNING log types. This makes each message's source clear and helps with troubleshooting. To import Logger, add the following code at the top of the action or workflow scriptable task: Set these two parameters: Parameters: The code creates a Logger instance in log. Use that variable to send messages, or rename it if needed. Set logName manually to the action's name. A Jasmine unit test can check this. If you rename the action, you also need to update logMessage. Across the thousands of actions I have written, this has been a minor issue. Using arguments.callee to retrieve the action name dynamically causes problems with nested actions. Use one of the following methods to send a console message: The example above…

2 min read

VCF Automation – Native Git Integration vs Alternatives

Git integration with VCF Automation comes up regularly in conversations about GitHub and GitLab. Native integrations suit their intended uses, but misunderstandings about their scope can lead to disappointment. Before choosing an integration, establish which content it can manage from Git. This post explains the native options, their limitations and the alternatives you may need. VCF Automation relies on the bundled VCF Operations Orchestrator product for its full automation capabilities. Orchestrator is often overlooked because it is a separate product. The two products integrate with Git differently, so consider both. I divide the uses of Git into three categories: Each category is likely to need different tools, methods and a different lifecycle. This post focuses on Git support rather than examining orchestration tools in detail. The following tables list infrastructure configuration and content that could be stored in Git. They show which items the native integrations supported when I wrote this post. VCF Automation and VCF Operations Orchestrator have separate tables. These are the most common infrastructure configuration items: VCF Automation: VCF Operations Orchestrator: The following content is consumed by end users or supports that consumption: VCF Automation: VCF Operations Orchestrator: * Orchestrator can present and activate only one branch at a time. A typical branching strategy does not handle environment-specific content, such as configurations, by itself.…

5 min read

VCF Automation – Build Tools for VMware Aria – Useful Maven Command Reference

Earlier posts covered Build Tools setup and basic projects. This reference collects the Maven commands for creating projects, pushing and pulling content, and cleaning up packages, together with their parameters. In each example, replace groupId and artifactId with your values. Set archetypeVersion to the required Build Tools version. For new projects, use the latest available release. A TypeScript-based project manages all Orchestrator content: workflows, actions, resources and configurations. Create one with this command: A JavaScript-based project manages only Orchestrator actions. It does not support workflows, resources or configurations. Create one with this command: An XML-based project manages workflows, resources and configurations in Orchestrator's native XML format. It also supports actions, but I recommend a JavaScript-based project to avoid wrapping them in XML. Create an XML-based project with this command: Set workflowsPath to the top-level Orchestrator folder for the workflows. You can add more folders later. This Maven multi-module project contains JavaScript-based and XML-based subprojects. The Build Tools documentation recommends it for initial onboarding. I prefer creating the two projects separately and do not recommend this type. To create a mixed project, use this command: An ABX project manages a VCF Automation ABX action. ABX provides an alternative orchestration runtime to Orchestrator. Each action needs its own project, which adds management…

4 min read

VCF Automation – Build Tools for VMware Aria – Visual Studio Code Integration

The Build Tools for VMware Aria project provides a Visual Studio Code extension. It adds the following features for developing VCF Automation content in the IDE: I encountered several issues with the extension and found its support limited. For me, the main benefit of Build Tools is already being able to manage the code in VS Code. The vRealize Developer Tools extension for Visual Studio Code can be installed from the VS Marketplace. Restart Visual Studio Code after installing the extension. I encountered issues when I skipped this step. Match the extension's Build Tools version to your projects. On its extension page, select the cog icon, then Extension Settings. Set Build Tools Default Version to the required version. I used 4.2.1, the latest version when I wrote this post. Open the command palette and search for vrealize to see the extension's commands. Use vRealize: Change Active Profile to select the active connection to VCF Automation and VCF Operations Orchestrator. Profiles are those that have been defined in the Maven settings.xml file. I find profile switching useful for viewing content from a specific environment. I have not found another use for it. Use vRealize: New Project to create a supported Build Tools project. Part 2 of this series describes the options: VCF Automation – Build Tools for VMware Aria – Overview of VCF Automation Projects. Select a project type. This example uses vRO JavaScript-based. Enter the group ID. This example uses com.simplygeek.…

4 min read

VCF Automation – Build Tools for VMware Aria – Overview of VCF Automation Projects

Build Tools for VMware Aria supports several project types. This post explains those used to manage VCF Automation and VCF Operations Orchestrator content, when to choose them and how to create them. The available project types are: The project names use the older product acronyms:vRA = VCF AutomationvRO = VCF Operations Orchestrator. There are also two legacy project types, but I will not be covering these in this post. The examples use the Build Tools version available when I wrote this post, set by archetypeVersion. Check the GitHub project for newer releases. I recommend using the latest version. Create a root folder for your projects. My examples use aria-automation. This creates a TypeScript project for Orchestrator content. It supports development features such as ECMAScript 6 syntax, module dependencies and class inheritance. The project manages workflows, actions, configurations and resources as native TypeScript .ts files. You can maintain all of this content in one place using the same language. This project type requires a good understanding of JavaScript and TypeScript. Consider these limitations: If you have TypeScript experience and can work within these constraints, this project type lets you manage Orchestrator content as an application. Set ‘groupId‘ and ‘artifactId‘ to your values. The command creates a folder named after artifactId: vro-ts in this example. Inside it, src has the following structure: Additional folders can be created and referenced using…

5 min read

VCF Automation – Build Tools for VMware Aria – Up and Running

This post updates my IaC for vRealize series with Build Tools version 4.7.0, the latest release when I wrote it. The guidance is intended for version 2.30.x or later. Earlier versions may not work as described. vRealize Build Tools was renamed Build Tools for VMware Aria. The former VMware Fling is now an officially managed open-source project on GitHub. Its integrations extend beyond Orchestrator to manage content for these VCF solutions: Build Tools for VMware Aria is available in public Maven repositories. Except for the keystore, you no longer need to upload artefacts manually or use a vRO 7.3 appliance. With direct internet access, you can create a project and start using the tools. For enterprise environments, I recommend a supporting platform to provide greater control. I will not be covering the following in this post: These topics need dedicated posts and are not prerequisites for this setup. I strongly recommend an artefact repository manager to store supporting artefacts and integrate them with deployment targets and pipelines. Options include Artifactory, Nexus and GitLab. Many enterprises already have repositories, projects and permissions in place. The basic setup below is for guidance and demonstration. This guide does not cover every product or deployment option. I deployed JFrog Artifactory in a container managed by Podman on Rocky Linux 9, following this guide. You can follow the same guide or adapt the deployment to your environment. Before continuing,…

9 min read

Using a Service-Oriented Architecture Approach to VCF Operations Orchestrator Development

This post introduces service-oriented architecture (SOA) and explains how I apply it to my VCF Operations Orchestrator development. Service-oriented architecture (SOA) is a widely adopted approach to building loosely coupled, reusable services. These principles suit systems integration. Much of Orchestrator development involves integrating external systems, with Orchestrator coordinating the automation between them. Here are some key principles of SOA: SOA promotes reuse and modular design. In Orchestrator, this reduces the need to duplicate functionality across actions. SOA is particularly well-suited for developing integrations in Orchestrator, whether you’re working with built-in plugins or external systems via HTTP REST hosts. I often encounter the following approach in Orchestrator development. I have used it myself. Consider a hypothetical API called MyAPI with five endpoints: MyAPI/endpoint1 through MyAPI/endpoint5. Each supports the HTTP GET method. This example focuses on the structure of the integration rather than the details of making requests. Developers often create five separate actions (functions): getEndpoint1getEndpoint2…getEndpoint5 Orchestrator encourages this approach, and many built-in actions follow the same structure. You call each action using System.getModule(). Separate actions provide some reuse, but this approach has limits. With multiple integrations and dozens of endpoints, these actions can become difficult to manage, maintain and scale.…

4 min read