Chapter 18: Extensibility overview

18.1 Extensibility Options and Tools

In most projects, sooner or later, a time will come when not all of the requirements can be covered by means of the administrative graphical user interface. The same also applies to vRealize Automation.

Simple extensibility scenarios often apply to the customization of existing workflows. For example, a user wants to choose a script, which should be executed after the provisioning of a machine (such as change the hostname or specify the way of provisioning). While a lot of examples can be realized by means of custom properties, property groups and the property dictionary, there are often requirements which require programming.

These use cases are often quite sophisticated. For example, there might be the case that vRealize Automation is integrated with the external infrastructure – e.g. an existing IP address management tool, a tool for defining host names, or an integration with some kind of business tool. To meet these sorts of requirements, VMware provides vRealize Orchestrator and the vRealize Automation Center Designer (however, the latter should only be used for legacy reasons, as it will be removed at some time in the future).

Another scenario covers Anything-as-a-Service (XaaS) offerings. The basic idea behind XaaS is that vRealize Automation could be used to publish all kinds of services – not only IaaS offerings. vRealize Automation provides a self-service portal with a fine-grained permission system. This can be used to host a variety of services. For example, members of the HR department could use vRealize Automation to create Active Directory users. Jobs can be invoked or any other tasks, which can be managed with VMware Orchestrator in the background. The only task for administrators is to publish these services via the Advanced Service Designer.

In prior versions, VMware allowed implementation of code directly in .NET, by means of the Cloud Development Kit. This would then install that code to the Model Manager. However, as VMware moves away from Microsoft .NET, this feature has been removed from the product.

With the latest version of vRealize Automation, the product also has a new component, the Event Broker. The Event Broker allows administrators to centrally manage the events and decide when Orchestrator workflows should run.

In addition, VMware ships the Cloud Client, a command-line utility that provides verb-based access with a unified interface across vRealize Automation APIs. Users can use the Cloud Client to automate various kinds of tasks as well as to import and export blueprints.

18.2 Extensibility with the vRealize Automation Center Designer

Basically, adaptations can be performed by using vRealize Designer as well as VMware Orchestrator. The reason for two different tools lies in the development history of vRealize Automation.

vRealize Designer is a .NET based Windows application. Historically, it is the older one of the two tools (when it comes to vRealize extensibility) and was implemented to customize workflows (however, not to create new workflows). Its strength is that – at a programming level – it works in much the same way as a standard Windows application and therefore is quite easy to understand for developers.

In the current version of vRealize Automation, provisioning workflows is based on the Windows Workflow Foundation (WWF) library of the .NET framework. As the vRealize Automation Designer is also implemented in .NET, there is a seamless interaction between the tool and vRealize automation. Furthermore, .NET developers will feel quite at home with this tool.

The tool itself is depicted in Fig. 1. There is a toolbox to the left. Developers can easily use Drag’n Drop techniques to move tasks into the main pane. Workflows can be implemented by using predefined tasks and connecting them.

However, the use of this tool also has some drawbacks. Firstly, because it is .NET based, it must be installed on a Windows operating system. Furthermore, workflows can be customized, but there is no real programming experience. Although there are a set of different predefined tasks that can be used (for example for declarations, control flow, variable assignments, etc.), there is no possibility to implement your own code with any kind of programming language. Another disadvantage is that there is no direct access to external systems like web services or databases. This is only possible by calling an external script (e.g. Microsoft PowerShell script) or by the use of the CDK. Also the future of this tool is not clear. Currently, the vRealize Automation IaaS components are implemented in .NET, but this is not guaranteed for future versions. Hence, developers should not rely on their current vRealize Automation Designer customization to be running in any future versions of vRealize Automation.

18-1

Fig 1: vRealize Automation Center Designer

18.3 vRealize Orchestrator

Shortly after the acquisition of Dynamic Ops by VMware, the integration of vRealize Automation into Orchestrator was started. Finally, with vRealize Automation release 6, nearly all features of the vRealize Automation Designer are also supported in Orchestrator.

Orchestrator is VMware’s central tool for all kinds of automation within the datacenter. In contrast to vRealize Automation Designer, it is implemented in Java and hence runs on nearly every operating system. Orchestrator is feature-rich. First of all, it is an intuitive Integrated Development Environment (IDE). Similar to vRealize Automation Designer, it is possible to create workflows by means of Drag’n Drop techniques. However, developers can also use JavaScript to implement their own code. Orchestrator already provides a set of plug-ins, which allow the integration of external systems without adding any lines of code (for example Active Directory, SSH, Databases, SOAP, REST, vCenter, etc.). Many other plug-ins also exist on the market and these can be easily installed in Orchestrator. Furthermore, workflows can be easily invoked from within Orchestrator. There is even an integrated source code versioning system, with the possibility to see historical workflow runs.

Fig. 2 shows the graphical user interface of Orchestrator. Similar to vRealize Automation Designer, there is a toolbox on the left side, where a lot of tasks and activities for many use cases are already available.

18-2

Fig 2: vRealize Orchestrator

Compared to vRealize Automation Designer, Orchestrator offers more features. Firstly, it is possible to create own workflows – not only customize existing ones. Besides the ability to implement custom code, the huge set of existing plug-ins and modules is a real benefit. The vRA plug-in offers the following features among others:

  • Configuration of the Advanced Service Designer (ASD)
  • Automation of approval policies
  • Accessing the service catalog
  • Access to the vRealize entity model
  • Creating and maintaining tenants, business groups, reservations and endpoints
  • Coding of own workflows
  • Maintaining virtual machines
  • Programming of custom properties, build profiles and the property dictionary

Because of this huge feature set, the use of Orchestrator should be preferred in comparison to vRealize Automation Designer. However, as it is often the case, there is an exception to the rule – that is when there is already a large number of implemented .NET workflows. However, in most projects, this should not be the case.

18.4 Advanced Service Designer

The vRealize Advanced Edition allows the use of the Advanced Service Designer. This allows the publishing of XaaS services to the self-service catalog. From a technical point of view, these workflows run within Orchestrator. Hence, the Advanced Service Designer gives administrators the possibility to integrate existing workflows into vRealize Automation. This integration encompasses two steps. Firstly, the user interfaces for calling a workflow must be defined. Secondly, the XaaS workflow must be published to the service catalog.

There are plenty of use cases for the ASD:

  • Creation of Active Directory accounts for new personnel
  • Password management for end users
  • Triggering restore or backup processes
  • Performing software updates
  • Providing lab environments
  • Installation of additional software
  • Integration of third party software

18.5 Event Broker

As a cloud management platform vRealize Automation manages the lifecycle of various kinds of resources. Those resources usually have a lifecycle of its own and from time to time it is necessary to perform custom actions during the lifecycle of those resources. In previous versions, it was quite hard to manage the events where adaptations should take place centrally. VMware addressed this issue with the new Event Broker.

Basically, the Event Broker acts as a service that manages events to be published and allows potential consumers to register to those events. The Event Broker allows to register Orchestrator workflows with the following categories of events:

  • Post Approval
  • Pre Approval
  • Event Logging
  • Blueprint configuration
  • Resource reclamations
  • Business group configuration
  • XaaS events
  • Machine lifecycle
  • Machine provisioning

18.6 Cloud Client

In the previous chapters we have spent a lot of time on how to configure vRealize Automation. So far, we have done all the administrative work manually. However, during operations a lot of repetitive administrative work is being carried out. Consequently, there is a need to automate these tasks. Performing bulk operations would be a common use case. For example, if you want to make resource changes to multiple systems or need to power on/off a number of systems at a specified time. You can also coordinate changes across tenants, groups or vRealize Automation instances. Using the CloudClient you can call vRealize Automation functionality from other applications and even perform composite tasks across different VMware products.

VMware published vRealize CloudClient – a command line tool that provides easy access to vRealize Automation, vRealize Orchestrator and VMware Site Recovery functions.

Amongst others, the following tasks can be automated with CloudClient:

  • Creating blueprints and catalog items
  • Requesting catalog items
  • Activating vRealize Automation actions
  • Creating IaaS endpoints
  • Automating SRM fail-overs under vRealize Automation management
  • Launching vRealize Orchestrator workflows
  • Importing and exporting Advanced Service Designer content
  • Importing and exporting blueprints

18.7 Summary

This chapter gave an overview of the extensibility options within vRealize Automation. All the different tools – vRealize Automation Designer, Orchestrator, Advanced Service Designer, Event Broker and CloudClient were introduced. The following chapters will now give a more in-depth look at how to work with these tools.