In a previous article, I taught you how to explore and use the REST API to start a Workflow using a generic browser based REST Client. In this article, I will provide a perl based example of running the “Create a Record” workflow that was created in Part 2 of my SQL Plug-in Dynamic Types Simple CMDB for vCAC article. I have barely more experience with perl than Python so this will be another very short article!
In a previous article, I taught you how to explore and use the REST API to start a Workflow using a generic browser based REST Client. In this article, I will provide a Python based example of running the “Create a Record” workflow that was created in Part 2 of my SQL Plug-in Dynamic Types Simple CMDB for vCACarticle. Since I’m not even close to being proficient with Python, this will be a very short article!
Welcome back! This is the third article of a multi-part series that steps you through the process of exposing our workflows from the last article to vRealize Automation’s (vRA) Advanced Service Designer (ASD). Introduction This third article will cover the following topics: How to add the simple CMDB to vRealize Automation’s Advanced Service Designer Add a Day 2 operation to delete an Asset from our table Future article will cover the following topic:
Welcome back! This is the second article of a multi-part series that steps you through the process of mapping a SQL table into vRealize Orchestrator, building out a DynamicTypes plug-in inventory based on that table, then exposing it to vRealize Automation’s Advanced Service Designer (ASD). In the first article, we got our database table mapped using the SQL Plug-in and generated some CRUD workflows. Introduction Let’s build a simple Dynamic Types plug-in around our SQL Table that we created in our previous article.
This multi-part series will step you through the process of mapping a Microsoft SQL Server table into vRealize Orchestrator, building out a DynamicTypes plug-in inventory based on that table (using my workflow package), then exposing it to vRealize Automation’s Advanced Service Designer (ASD). Introduction vRealize Automation (vRA) features an Advanced Service Designer (ASD) that allows for you to offer nearly anything as a service (XaaS). In order to take advantage of that feature, it requires a vRealize Orchestrator (vRO) Inventory object.
A frequent requirement when performing orchestration tasks is to have input fields interdependent. For example, if I input XYZ into the first input, I want the second input to be relevant to XYZ. In the past, I have frequently done such workflows where you select a Datacenter for the first input, then the second input would present a list of Datastores (or VMs or Clusters or Hosts). In this tutorial, I’m going to do something a little different.
vCO has again been extended with a new plug-in an updates of existing plug-ins. VMware vCenter Orchestrator AWS 1.0 Plug-in (New) VMware vCenter Orchestrator Auto-Deploy 5.5.1 Plug-in (Updated) VMware vCenter Orchestrator Multi-Node 5.5.1 Plug-in (Updated) VMware vCenter Orchestrator AMQP 1.0.3 Plug-in (Updated) VMware vCenter Orchestrator PowerShell 1.0.4 Plug-in (Updated) VMware vCloud Automation Center 6.0.1 Plug-in (Updated) - released date April 25, 2014 (article updated to include this entry)
You may have noticed that the vCO 5.5.1 release notes are listing a new feature called “Dynamic Types” “Workflow developers are now able to explore the new Dynamic Types which currently is being shipped with Beta quality. They can easily extend vCenter Orchestrator plug-ins by adding their custom types accessible from the scripting API. New types become available in the inventory right after creation and they could be directly leveraged from the vCAC ASD context as part of the cloud provisioning process and XaaS definition.
If you’re reading this article, it may be because you have installed vCloud Automation Center (vCAC) and are interested in using an account other than firstname.lastname@example.org to login to the embedded vCenter Orchestrator (vCO) server. By default, the vCO Server uses a “vcoadmins” group in the “vsphere.local” domain provided by the SSO server that vCAC was configured to use. This short tutorial will step you through a pretty basic configuration where I have just deployed a vCAC 6.
A frequent question around vCenter Orchestrator is: Can I read/write to shared folders? The answer is always yes, but the documentation may be difficult to find - especially when you are referring to a Windows share - aka CIFS in samba and *nix mounting terminology. Read on to learn EXACTLY what you need to do to allow your vCO server to read/write to a Windows Share! Overview: vCO allows limited access to its local filesystem.