Article archive

2026

Articles & guides

Introducing the VCF Automation Assessment Tool

Understanding an established VCF Automation environment takes more than counting projects and deployments. You need to know how its configuration fits together, who can request its services, and which parts need attention. I created the VCF Automation Assessment Tool to bring that information into one report. It reads the platform’s REST APIs and produces a self-contained HTML report covering configuration, usage, governance and extensibility. This article introduces the tool and walks through a first assessment of a VCF Automation 8.x environment. The tool currently targets VCF Automation 8.x. Compatibility with VCF Automation 9 VM Apps organisations has not been verified. All Apps organisations are not supported. The source and full documentation are available in the VCF Automation Assessment Tool repository. The tool combines an inventory with findings that identify potential problems and configuration worth reviewing. It is read-only against the platform: it does not repair configuration, delete deployments or execute the automation it analyses. The report starts with Summary, showing inventory counts, severity totals and a findings table. Assessment Coverage follows, then separate sections let you work through each area in more detail. For example, a deployment can fail while still holding machines. The report identifies that situation so you can investigate the resources that remain. Other checks highlight exhausted project quotas, invalid templates, disabled…

  • VCF Automation

How I Teach an AI Assistant to Write VCF Operations Orchestrator Code My Way

I have a particular way of writing VCF Operations Orchestrator code. Most of the logic lives in actions, integrations use reusable services, and workflows connect those pieces together. Logging, parameter validation and documentation are part of that structure. An AI assistant needs that context to produce a useful change. A request to “write an Orchestrator action” leaves plenty of room for code that solves the immediate problem but doesn’t fit the repository. My approach is to keep the development conventions alongside the code. Repository instructions describe the project, skills explain recurring tasks, and a separate reviewer checks the changes against those conventions. This article explains how I have organised those pieces in my Orchestrator project using Claude Code. In Why I Write Actions and Not Workflows (Mostly), I explain why I keep most of my logic in JavaScript actions. That makes the code easier to work with outside the Orchestrator editor and gives development tools something useful to inspect. The same structure gives an AI assistant useful examples to follow. It can read an existing service, see how that service calls another module, and compare a proposed change with the surrounding code. However, examples need context. A file may contain an older pattern or an exception for a particular integration. Asking the assistant to copy whichever file it finds first leaves that decision to chance. I want the repository to answer three questions: Those questions…

  • VCF Operations Orchestrator
  • Development
  • AI

2025

Articles & guides

Getting Started with Ansible Development on Windows Using WSL and Visual Studio Code

Windows Subsystem for Linux (WSL) lets you run Ansible and other Linux tools while working on a Windows desktop. Visual Studio Code (VS Code) connects to that Linux environment, so you can edit files, use Git and run commands from one editor. This guide sets up AlmaLinux 10 in WSL 2, creates a Python virtual environment and connects it to the Ansible extension in VS Code. The result is a workspace with code completion, syntax highlighting, YAML validation and linting, plus access to the Ansible command-line tools. WSL 2 runs a Linux kernel inside a lightweight virtual machine managed by Windows. You do not need to configure a separate virtual machine or dual-boot installation. See Microsoft’s comparison of WSL versions for the architectural differences. The screenshots come from the original July 2025 article. They illustrate the setup, but current extension screens and settings can differ. Use the updated commands and configuration below when following the guide. The examples use AlmaLinux 10 and its Python 3.12 packages. My preference remains AlmaLinux for its compatibility with Red Hat Enterprise Linux. Ubuntu is another option, but its package installation commands differ. You can install more than one WSL distribution. Check Python compatibility when choosing another distribution. The current ansible-dev-tools package metadata requires Python 3.11 or later, while individual tools can have stricter requirements. The ansible-core support matrix lists supported controller…

How I Write Beautiful Code in VCF Operations Orchestrator using ESLint and Prettier

I use a consistent code style for VCF Operations Orchestrator development. It makes files easier to navigate, patterns easier to identify and code easier to read. Applying industry conventions and team preferences manually can be tedious. Configured tools automate formatting and keep the codebase consistent. I use two tools: Together, these tools can detect issues such as: You can customise the rules to suit your preferences or team standards. Prettier deliberately offers fewer choices to keep formatting consistent with minimal configuration. The tools can also apply fixes automatically when you save a file. This reduces the time spent correcting formatting and syntax issues by hand. This example shows style issues the tools can detect and fix: The screenshot shows three issues: With the tools configured, saving the file corrects these issues automatically. These screenshots show Visual Studio Code, which I configure later in the post. You can get the same results from the command line, including in a CI pipeline or without an IDE. This guide uses Windows and assumes you have: Open a command prompt in the project's root directory. Run this command to install the ESLint and Prettier dependencies: Place both configuration files in the project root. These examples come from my project: After installing the dependencies and adding the configuration, run either tool from the command line. Both can check files without changing them or write automatic fixes. The following commands…

VCF Operations Orchestrator: Auto-Document Your Actions with Ease

I spend much of my time developing VCF Operations Orchestrator code. Even with a structured development process, documentation can fall behind frequent code changes. I created a script to automate the documentation. It needed to meet these requirements: The vcf-operations-orchestrator-doc-generator repository contains the tool and usage instructions. It requires code managed with Build Tools for VMware Aria in a JS-Based Actions-Only Project. The documentation tool provides the following features: If you’re not using the Build Tools, Mayank Goyal has created a tool called VRODoc that can connect to Orchestrator and document Actions in a package. If you want to document your Workflows, Josh Broadway also has a tool, vcf-automation-orchestrator-automated-workflow-documentation. ActiveDirectoryService.md documents a class and all its methods in one file. vm.md documents the com.simplygeek.vcenter.vm module. It presents each action in that module as a function. README.md provides a top-level table of contents for all generated files. The script generates documentation automatically. I can integrate it into my pipeline and publish the output to my preferred wiki. I hope this helps you automate your documentation. This is the initial release, so there may be issues. I welcome feedback and will help where I can. Please feel free to reach out with any questions or suggestions.

VCF Operations Orchestrator: Why I Write Actions and Not Workflows (Mostly)

99% of my VCF Operations Orchestrator code is written as actions. This lets me write pure JavaScript that is easier to read and maintain. It also works with linters, unit testing frameworks and code analysers. Workflows provide a visual, drag-and-drop interface for automation with little code. They were originally intended to help system administrators and infrastructure teams automate vCenter Server tasks without needing a traditional development background. This simple workflow contains small script tasks, a for each loop and error handling, shown by the red line: Orchestrator's role has changed since its first release in 2009. A platform for simple scripts and automation flows now needs to support complex solutions that integrate dozens of systems. Developers still build these solutions with the traditional workflow model. In my view, that approach no longer fits: large, complex workflows are difficult to understand, maintain and troubleshoot. This larger workflow runs a script on a virtual machine: This is a relatively tidy example compared with others I have seen. Even so, changing a large workflow can mean spending more time rearranging the visual layout than developing the solution. Workflows also store their content primarily as XML. In Git, you work with those raw files, which makes development outside the visual editor cumbersome. Large XML diffs are difficult to read and assess during peer review. A workflow's XML can contain hundreds or thousands of lines. Here…

Process locking made easy in VCF Operations Orchestrator, featuring automatic unlock

VCF Operations Orchestrator has a built-in locking semaphore provided by the LockingSystem class. When a lock is created, the workflow is placed into a waiting state, and any additional executions of the workflow will be placed in a queue until the lock is released. Locking protects data consistency by preventing multiple processes from updating the same resource at once. This matters when concurrent workflows share resources. The LockingSystem method lock attempts to acquire a lock for a given lockId and owner. It returns true if successful, or false otherwise. LockAndWait waits indefinitely if it cannot acquire a lock. I use lock instead because it allows a timeout or other corrective handling. Release an acquired lock with unlock. My LockingService extends LockingSystem with these features: You can download my LockingService module as a package here or as native JS here. Import LockingService into an action or workflow with the following code: The code creates a LockingService instance in locking. Use that variable to create and remove locks, or rename it if needed. Use these LockingService methods to create and remove locks: locking.createLock(lockOwner, lockId, retryMaxAttempts, retryDelay, autoRemoveLock) → {Boolean} Parameters: Returns a boolean. locking.removeLock(lockOwner, lockId) Parameters: Thanks for reading, and please let me know if you have any suggestions for improving this service.

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,…

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…

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.…

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…

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.…

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…

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,…

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.…