Home > Blogs > VMware vCenter Orchestrator Blog

Many ways to start vCenter Orchestrator workflows

I noticed a tweet recently by someone who was “surprised that vCenter Orchestrator has so few ways to trigger the starting of a workflow.” This came as a surprise, because there ARE many ways you can trigger our workflows. I’d like to take this opportunity to educate the community on just how many ways there really are…

vCenter Orchestrator provides the following base methods of triggering workflows:

  • vCenter Orchestrator Client
    • Scheduler
    • Policies
  • Web Interface
    • WebOperator Webview
    • Perspectives Plug-in
    • Custom Webview
    • Wavemaker
  • vCenter Orchestrator API
    • vCenter Orchestrator SOAP Web Service
    • vCenter Orchestrator REST Web Service

vCenter Orchestrator Client

The vCenter Orchestrator Client allows administrators and permitted groups to launch workflows manually on a local or remote vCenter Orchestrator server. The functionality of running remote workflows is greatly enhanced when using the Multi-Node plug-in. Use of the vCenter Orchestrator Client is most common during the design, test, and troubleshooting of workflows. Additionally, the client offers the following methods of automated workflow triggering:

  • Scheduler: provides the ability to schedule workflows to be running at user-defined intervals. Use-cases would include recurring maintenance tasks such as disconnecting media from all VMs prior to backup, deleting old snapshots, automatically creating snapshots, etc…
  • Policies: Allows plug-ins such as the SNMP, AMQP, and vCenter to trigger workflows based on defined criteria. Use-cases would include remediating systems based on SNMP traps that exceed defined thresholds, responding to vCloud Director blocking tasks that have been posted to an AMQP bus, and starting a workflow based on state Change or thresholds of vCenter objects.

Web Interface

Lightweight administration may be performed using vCenter Orchestrator’s built-in webview functionality. The system uses Tapestry and Dojo technologies.

  • Weboperator: The Weboperator that ships with the product gives administrators the ability to browse the entire workflow library, start and/or schedule workflows. It also allows them to:
    • Tasks: View, Suspend, Cancel, and Delete tasks (Scheduled workflows)
    • Workflows: Start/Schedule, view schema, variables, and events, respond to workflows waiting for input
    • Policies: Start/Stop/Reset and view defined Parameters
  • Perspectives: The Perspectives fling allows an administrator to define a set of workflows to be accessible to an LDAP Group. For example, one could define 5 administrative/maintenance workflows to be visible to the Backup Admins group. Upon logging into the web interface, these Backup Admins would be able to start workflows, schedule them, view workflow execution events, schemas, etc…
  • Custom webview: Custom webviews are created by developers to present specific workflows in custom layouts not afforded by the auto-generated layouts presented by the Weboperator and Perspectives. Service providers have used this method for public offerings, providing “Cloud” services years before “Cloud” was the big keyword.
  • Wavemaker: There have been numerous blog posts on creating web interfaces for vCenter Orchestrator using this free product.


vCenter Orchestrator has always had a SOAP API available for interacting with it from remote systems. As of version 5.x, it also now has a more powerful REST API. The first visible use of the REST API is the vSphere Web Client. When properly configured, one can launch any number of workflows directly from the vSphere Web Client. Other VMware products that incorporate the ability to launch workflows include vSphere Service Manager and vCloud Automation Center. 3rd parties have also built in support to their products so that vCenter Orchestrator workflows may be launched.

Using either of these APIs, any number of scripting and/or programming languages are capable of triggering vCenter Orchestrator workflows. Examples may be found on blogs as well as in the VMware Communities.   A quick search on google reveals examples of using PowerShell, PERL, Python, PHP, C#, JAVA, .NET, and Ruby to interact with a vCenter Orchestrator server.

As we can see above, there are many different methods of triggering vCenter Orchestrator workflows. Providing standard APIs around SOAP and REST greatly increases ones ability to incorporate vCenter Orchestrator into existing systems.