Navigation
TAG: vcac

vCloud Automation Center 6.1 GA – What’s New?

Now that vCloud Automation Center 6.1 is generally available (grab it!) we can go more into the details of whats new! I’ve been waiting for this release for quite some time, as it improved some nice things and set a standard for next versions. So are you ready? lets go!

 

Installation Changes Quick-guide

Some notable installation changes can be seen with this new version. In terms of install steps, they are still the same:

  1. vCAC SSO (Id Appliance / Windows Install / vCenter Server)
  2. vCAC VA (Clustered or not)
  3. vCAC IaaS (Distributed or not)

An important note regarding the identity appliance – Upgrades from 6.0.x will still need the <id appliance FQDN>:7444 format in the host name field, BUT a fresh install will not require the port, only the host FQDN.
On the vCAC appliance side – achieving HA is now a breeze. Simply install 2 vCAC VA Appliances, configure the primary one, and add a secondary to the cluster by clicking an “HA Mode” option. This will configure the Web app, and messaging for HA mode, PostgresSQL will still have to be configured manually.

vCAC VA HA

HA Mode in vCAC VA Configuration Page

As for the vCAC IaaS component, the installation of the components is pretty much the same, but a couple of things changed. .Net 4.5.1 is now the new IaaS operating framework, but you will also need Java 1.7 x64 or later to be installed on the db machine as well.

UPDATE: Looks like it might be the Manager server that specifically needs Java rather then the DB, I’ll re-check and update pre-req script soon.

The new pre-req checker will obviously warn you about this, also another tiny thing i’ve noticed – When you download java from Oracle, using a server box (an 2008 R2 for that matter) the Java you will get is an x86 one since IE is a 32 bit application, thus your computer is detected as such. So pay a good attention to which version of Java you download, since x64 is a must here.
The install script below will handle all pre-reqs, as well as attempt to download the Java 1.7 x64 and set JAVA_HOME (which is also required) for you.

After we’re done configuring everything, it’s time to login! At a first glance we can notice the vCAC UI got a nice minor revamp , showing the vCloud Suite colors & theme, and also a bit of a flat design. I like it overall.
Oh and another minor thing, you can now also access vCAC through –
https://vcac-host-fqdn/vcac/org/tenant (no more shell-ui-app, though it will work as a soft link)

New Features

vcac6 ui

New vCAC 6.1 UI

A major change that had to go deep into the vCAC 6.x code base was support for the standard i18n language codes, which includes some standard languages such as German, Japanese, Chinese and more. This is actually something coming all the way from Pat Gelsinger for all of the VMware products.

Enhanced NSX Support

This version of vCAC is mostly ‘the NSX version’ it brings some major improvements to the way multi-machine blueprints are deployed with complex networking and supports NSX in order to do so. A good example of this is the support for NSX features like:

  • Logical Switches
  • Distributed Logical Routers
  • Security Groups & policies
  • Distributed Firewall Rules
  • Load Balancers

Basically all of these improve a lot of the NSX functionality, for instance, the ability to utilize DLR enables us to deploy single-arm edge devices, with an internal link that serves as a gateway, and the external link is served by the ESXi DLR.

Also, vCAC 6.1 comes with a builtin vCO 5.5.2 Server, which contains by default, a new version of the NSX plugin for vCO! This is actually crucial in running some of the logic for vCAC / NSX integration, so if you configure vCAC for an external vCO IaaS endpoint, and plan to use NSX, be sure to install the NSX plugin on that vCO server!

This plugin will also enable you to perform some great day 2 operations on your VMs, like adding a machine to a load balanced configuration, or a security group.

ASD Capabilities

Add Day2

Add a new day2Op. Notice the ‘Status equals On’

Advanced Service Designer has been around since 6.0.x release, and VMware has extended some of the things it can perform. For example, you can now assign a day 2 operation to a VM on a VM filter basis.
This means that from now on you will be able to decide when does a VM shows its ASD Day 2 operations, according to its properties. For example, show a custom day 2 operation only if a VM is Powered On, since it is only relevant to that state of the VM.

You will also be able to filter-out operations to be displayed based on other parameters as well, kind of like the parameters available with approval policies.
Also, one of the problems with vCAC 6.x was the lack of ability to specify that a certain Day 2 operations is an ‘Un-provision’ operation. You had do delete the item off of vCO’s cache, and get vCAC to refresh its inventory as well. With the 6.1 ASD, you can specify whether a Day 2 operation is a ‘Provisioning’ one like lets say – clone a vCAC VM (and provision a second VM off of it) , or un-provisioning an ‘abstract’ item.

Last thing new and exciting about ASD is the ability to show output to the users from an ASD Day 2 operation! Meaning, you can have the output of the vCO workflow displayed to the user after the day 2 operation is done, if you need to let him know of a specific output. This is a lot nicer then an email in some cases.

Application Services

ApplicationsS

Application Services 6.1

As part of the vCAC 6.1 release, VMware’s former ‘App Director’ or now, Application Services , is also released in a new version. This version has better integration to vCAC , allowing for users to deploy fully blown multi tier apps as service catalog items.
Some of the new features include:

  • Resuming a failed App deployment
  • Multi tenancy support
  • Allowing for additional day 2 ops

Users will now be able to own the infrastructure holding the application requested from the ‘Application Services’ provider (unlike in vCAC 6.0.x) so they are easier to manage, from the central vCAC item portal.

Also, the new Application Services platform is more tightly integrated with puppet, to be able to deliver puppet configured platforms, enabling application teardown, scale in / scale out using the puppet nodes.

Infrastructure Bulk Import

vCloud Automation 6.1 now allows you to bulk import your existing infrastructure into vCAC’s management, with the help of CSV files. Although you could also import brownfield environments in 6.0.x using the infrastructure organizer, things would get complicated when you would try to import a lot of machine with multiple owners to multiple business groups. The bulk import tool comes to simplify all of that, and generates a much simpler importing flow for the end user / admin.

vCloud Automation Center CLI

vcaccli

vCAC CLI

This version of vCAC comes built in with a little tool called vCAC-CLI. It’ll help you do some rest operations on vCAC with ease, and allow you to get well formatted JSON responses when you perform GET operations. This tool is not ‘CloudClient’ as some of you may or may not know, but more of a vCAC cURL tool.
The tool is Java based, so you can use it from any client OS (Mac / Windows / Linux). You can download the vCAC-CLI tool directly from the vCAC Appliance.
Expect some more in-depth posts about this one later on.

vCloud Automation Center API

The fruits of the vCAC 6.0.x API have ripened and the vCloud Automation Center 6.1 exposes a fully blown Rest APIs accessible even without the help of our friend vCO !

XaaS & Dynamic Types Plugin

vCO 5.5.2 Dynamic Types plugin should now be in full sync with vCAC 6.1, allowing for users to create any vCO inventory item (and thus, a vCAC ASD item) off of services equipped with external REST/SOAP APIs … I’ll be fiddling with these capabilities soon, so expect some interesting updates in the posts to come. Meanwhile, you can check out this few guides at vCOTeam.Info to get your game going on new XaaS options and capabilities!

Downloads

vRealize Air Announced

vRealize Air had been just announced at VMworld 2014 as a suite of new services that will be available in a SaaS model, this brings very interesting news to our customers.
vRealize Air Automation, is the name for our offering of vCAC-as-a-Service in a SaaS operating model. So Instead of deploying cloud management solutions on premise, you will now be able to consume vCAC’s great IaaS & XaaS services – As A Service, from the Cloud! I think that’s a good pun by the way.
So with vRealize Air Automation, you will be able to connect your private cloud & public cloud, both to a single seamless management platform, that you don’t need to deploy, just consume, off of a vRealize Air Automation instance located on vCloud Air.
Currently, the solution is open for beta registration at vrealizeair.vmware.com. So go right ahead and register!

Currently, vRealize Air runs the latest vCAC version (not yet GA available), and i’m pretty sure that with vCAC on a SaaS platform it will always have the most up to date features, and capabilities of the product.  That way, you won’t need to upgrade your local premise vCAC , and will now be able to always have the latest and greatest stuff.

Personally, i’m very excited about this announcement and solution, and I will be actively helping promoting it, and get our users and customers to consider consuming vCAC on a SaaS model. Expect to hear more about my personal involvement on this great new platform soon.

vCAC XaaS: Requester Details

The next couple of posts will be more focused about some nice vCAC XaaS things i’ve been doing lately. This post is probably a good way to get to know some XaaS tips & tricks.
When you create an ASD Service – e.g – XaaS / Day 2 Operation, you can get some of requester details , which are handed to you by the ASD/XaaS engine. This comes in VERY handy.

How can this be used? Well, for an example, if you build a catalog item that grants the user with a Virtual Desktop, meaning, a Desktop-as-a-Service , you will be able to determine who you need to entitle the new desktop for – seamlessly.
No need to query the user for their details (user name, department ) you might just want to query what the desktop is used for and why , and that’s itץ Advanced Service Designer will automatically fill the gaps for you.

The information that is retrievable is:
– By whom the Request was made
– Who was the item/day 2 requested for (in case of an ‘On behalf of’ request
– Tenant reference (which in vCAC is the tenant name)
– Subtenant reference – The business group uuid
– The catalog request id
– Any static parameter that was inserted in the ASD form.

In order to get these essential parameters, all we have to do is to build our Day 2 / XaaS request as usual, but then we can achieve the data within the vCO workflow in to simple ways:
1. Download this vCO package, containing actions to get the parameters
2. In scriptable tasks, you can use the code I’ll exhibit below

This code is essentially the same that makes up the vCO Actions in the ASD package I linked – but i’ll break it down anyway for you lazies :)
vco asd actions

Essentially what we’re doing is just grabbing some info from the vCO server runtime, by using this code to get the ‘Requested For’ parameter

[code]
System.getContext().getParameter("__asd_requestedFor")
[/code]

What this piece of code will return, is basically the user name for the user who the requested XaaS , Day 2 Op is for, in a user@domain format.

This can also be used in conjunction to other parts of the vCAC plugin, grabbing useful business group information like the amount of Memory or Storage that the user’s business group is currently using. Though i’d generally recommend not to rely on implementing your own policy logic, and try to enforce business group policies through the IaaS engine when you can.

Again to break everything completely down, i’ll list the options of scriptable code writing in order to retrieve these details:

[code]
System.getContext().getParameter("__asd_requestedBy")
System.getContext().getParameter("__asd_catalogRequestId")
System.getContext().getParameter("__asd_subtenantRef")
System.getContext().getParameter("__asd_tenantRef)
[/code]

Also, you can notice that these variables automatically appear at vCO’s execution tokens. Taking a close look at the ‘variables section’ we can see them:
vco asd vars

So, start XaaS-ing and build awesome services and day 2 operations, extending your Private cloud with automated!
More blogposts are coming up on cool use cases where I used this XaaS capability. Any comments you have – Below!

Using vCAC 6.X REST APIs – Part 2

Previously on the using vCAC API blog series, we learned how capture and analyze the JSON code going from the VCAC Web UI, to the appliance.  In this post we’ll learn how to modify the request in order to generate a brand new request that can easily requested using vCO REST APIs abstraction.

Lets get to it!

First, make sure you have a vCAC 6 vCO plugin installed, and that you’ve configured it to work with your vCAC Appliance by running the ‘add a vCAC Host’ workflow.

After we have that sorted out, i’ll explain the basics of the vCO workflow required to submit the request:

Rest Request Workflow

 

Breaking it down, what I do in the first scriptable is get the catalog item object by it’s name, in order to get some of its details like id and such, the second scriptable task basically just submits the JSON code we’ve captured, with a few changes in it for the different field modification’s i’d like to perform.

As inputs, I take:
– Catalog Item Name: <Debian / RHEL 6.4 / whatever else I have in my IaaS catalog>
– Memory Size <1024/2048 whatever you want to put in>
– Cpu Size <1/2/3/4 etc.>
– User Name <any user in the Business Group to request on behalf of>

Get Catalog Item

In the general post i’ve made about the vCAC 6 plugin for VCO i’ve mentioned an object worth getting to know – the vCACCAFEEntitiesFinder in the scriptable Javascript code:

[code lang=”js”]
var founditems = vCACCAFEEntitiesFinder.findCatalogItems(vcacHost, itemName);
if (founditems != null)
{
for (var i in founditems)
{
if (founditems[i].name == itemName)
{
var catalogItem = founditems[i];
}
}
}
[/code]

get item

After I’ve found the item and made sure it exists, i’ll submit the JSON request for that item.

Request Item via REST

I’ve actually modified the formatting so it would be simpler to understand the different key:values that are submitted. I’ll point out all of the changes i’ve made to the JSON in the section below it.

[code lang=”js” collapse=”true” title=”Click to see full REST scriptable task code”]
var item = {
"@type":"CatalogItemRequest",
"catalogItemRef":{"id":catalogItem.id},
"organization":{"tenantRef":"vmdemo", "subtenantRef":"ce43f3ed-a3f0-42d0-b8e6-897239f52dbc"},
"requestedFor":UserName,
"state":"SUBMITTED",
"requestNumber":0,
"requestData":
{"entries":[
//{"key":"provider-blueprintId", "value":{"type":"string", "value":"ab5f5a5c-281b-49bf-a549-595789c07957"}},
{"key":"provider-provisioningGroupId", "value":{"type":"string", "value":"ce43f3ed-a3f0-42d0-b8e6-897239f52dbc"}},
{"key":"requestedFor", "value":{"type":"string", "value":UserName}},
{"key":"provider-VirtualMachine.CPU.Count", "value":{"type":"integer", "value":CPUs}},
{"key":"provider-VirtualMachine.Memory.Size", "value":{"type":"integer", "value":MemorySize}},
{"key":"provider-VirtualMachine.Disk0.Size", "value":{"type":"string", "value":"1"}},
{"key":"provider-VirtualMachine.LeaseDays", "value":{"type":"integer", "value":0}},
{"key":"provider-__Notes", "value":{"type":"string", "value":""}},
{"key":"provider-Vrm.DataCenter.Location", "value":{"type":"string", "value":"Lab"}},
{"key":"provider-Cafe.Shim.VirtualMachine.TotalStorageSize", "value":{"type":"decimal", "value":0}},
{"key":"provider-Cafe.Shim.VirtualMachine.Description", "value":{"type":"string", "value":""}},
{"key":"provider-Cafe.Shim.VirtualMachine.NumberOfInstances", "value":{"type":"integer", "value":1}},
{"key":"provider-Cafe.Shim.VirtualMachine.Reason", "value":{"type":"string", "value":""}},
{"key":"provider-Cafe.Shim.VirtualMachine.AssignToUser", "value":{"type":"string", "value":UserName}},
{"key":"provider-Cafe.Shim.VirtualMachine.MinCost", "value":{"type":"string", "value":"0"}},
{"key":"provider-Cafe.Shim.VirtualMachine.MaxCost", "value":{"type":"string", "value":"0"}},
{"key":"description", "value":{"type":"string", "value":""}},
{"key":"reasons", "value":{"type":"string", "value":""}
}]}
}

var catalogRest = vcacHost.createRestClient(vCACCAFEServicesEnum.CATALOG_SERVICE);
var response = catalogRest.post("consumer/requests",item);
System.log(response);
[/code]

~UPDATE~
For this to work with vCAC 6.1, you’ll need to serialize the request prior to submitting it, with the following code:

[code]item = System.getModule("org.dojotoolkit.dojo.json").serialize(item);[/code]

So be sure to add this line in your scriptable with vCAC 6.1
~UPDATE~

Screen Shot 2014-06-10 at 12.14.30 PM

Running through the code, you can notice some replacements i’ve done to the JSON text strings with my own variables, like:

[code lang=”js”]
"@type":"CatalogItemRequest",
"catalogItemRef":{"id":catalogItem.id},
[/code]

I’ve used the catalog item object to get it’s id so the proper item would be requested.
Also I’ve modified the memory and cpu parameters to fit the users input values:

[code lang=”js”]
{"key":"requestedFor", "value":{"type":"string", "value":UserName}},
{"key":"provider-VirtualMachine.CPU.Count", "value":{"type":"integer", "value":CPUs}},
{"key":"provider-VirtualMachine.Memory.Size", "value":{"type":"integer", "value":MemorySize}},
[/code]

Last part of the scriptable task code actually creates an internal , pre authenticated REST Client in vCO , to actually submit the request itself:

[code lang=”js”]
var catalogRest = vcacHost.createRestClient(vCACCAFEServicesEnum.CATALOG_SERVICE);
var response = catalogRest.post("consumer/requests",item);
System.log(response);
[/code]

the response variable will hold the servers response to our request, which will usually consist of a request item we can follow on to get progress updates with the request’s ‘Phase’ field.

To summarize the workflow, you can opt to change any one of the JSON parameters to expose less or more properties for user input, it all depends what is your use case and who are you giving this capability to. Of course your organization could have other custom properties needed to provision a vm, these appear as just another key:value in the JSON request.
Keep in mind that in more complicated environments you will probably have to add error checks, and might need to change the ‘subtenantidref ‘ value which is the value for the Business Group that the item is being provisioned by.

Day 2 operations via REST API

To allow for a day 2 action of a catalog VM with vCAC , we will repeat the process depicted in this two part series, grab the JSON code for a ‘destroy’ operation for example, and we will get the same kind of workflow. This time we will use a different vCACCAFEEnititiesFinder function called ‘

[code lang=”js”]
var founditems = vCACCAFEEntitiesFinder.findCatalogResources(vcacHost, resourceName);
[/code]

After that, we’ll get the resource object id, and post a ‘destroy action’ JSON request, for that specific VM. The code below is for posting the ‘destroy action’ after we’ve found the catalog resource item (our provisioned VM)

[code lang=”js”]
var resourceAction = {
"@type":"ResourceActionRequest",
"resourceRef":{"id":resourceItem.id},
"resourceActionRef":{"id":"a7eb7daf-de73-4cf9-b2c7-0c8aeded3b01"},
"organization":{"tenantRef":"vmdemo", "tenantLabel":"vmdemo.local", "subtenantRef":"ce43f3ed-a3f0-42d0-b8e6-897239f52dbc", "subtenantLabel":"Lab-BG"},
"state":"SUBMITTED", "requestNumber":0,
"requestData":{"entries":[]}
}
var catalogRest = vcacHost.createRestClient(vCACCAFEServicesEnum.CATALOG_SERVICE);
var response = catalogRest.post("consumer/requests",resourceAction);
System.log(response);
[/code]

Rest operations

Calling a vCO workflow with REST API

The main thing after we built this workflow, is to wrap it all up by simply letting users access this vCO workflow with vCO’s REST API! Now, users or any 3rd party system , can simply call vCO’s REST interface to run this specific workflow, and get a VM of choice with a quick API call.
You can read about calling vCO via REST in this article by our awesome vCOTeam @ VMware.

Attached below is a very simple example of calling a vCO Worflow with python code (remember to change to py instead of txt)
and REST APIs
If you have any questions, feel free to drop them in the comment section!

Using vCAC 6.0 REST APIs – Part 1

vCloud Automation Center 6.x has a very extensive API that can allow you to automate everything done with your cloud. This ranges from auto creating new tenants, to auto generating catalog items & services. One could even ask to request a catalog item on behalf of another user defined in vCloud Automation Center. The thing is, is at the moment these API’s are considered in a beta state this is due to the fact that they are still under development in 6.0.x and that not all of the functionalities (as you’ll see soon) are still available.

Recently, VMware has released a vCO Plugin for vCAC, which consists of two parts:
– The IaaS ODATA API workflow interface
– A vCAC Appliance API workflow interface.

Interacting with vCAC API

For the purpose of this post, we will learn how to utilize the vCAC-VA APIs, which are the MAIN set of API’s exposed from vCAC to users. Thing is, in order to authenticate we will have to use the vCO Server + vCAC 6.x vCO Plugin , since the natural authentication mechanism isn’t yet exposed (remember? BETA APIs)

vco-vcac-rest

 

In this first of two-part series, i’ll demonstrate how to capture, and make sense of the JSON request generated by the vCAC UI. Next post, will discuss on how to utilize vCO and this JSON code, to generate new automated requests via REST calls.

Capturing the API Call


The first step here is to understand the JSON construct vCAC 6.0 requests (I’m assuming API usage of vCAC would be for using it to consume services like IaaS / ASD)

We’ll begin by downloading Firefox, and FireBug plugin. What firebug does, is to get in between the actual UI click and the HTTP REST call that the browser make. We can leverage this to easily poke around, and re-create some of the REST API calls! So lets dive deeper in the rabbit hole. We will open up our vCAC catalog , and request an item:
Requesting Deb6
We’ll need to enable firebug, and then click the submit button:
FIREBUGON
Once we do that, we’ll see the HTTP responses , GET and POST operations.

HTTP REST Requests

If we click the plus sign and open it, we will get the JSON code posted:

PostMakeRequest

Analyzing the Request’s JSON Code

if we grab the text and format it, we can make some sense out of it. I’ll put the formatted code here, in case you want to take a look, and analyze what we can do further down. An explanation on how to utilize this using vCO will follow.

[code lang=”js” collapse=”true” title=”Click to see full Item Request JSON Code (warning: it׳s a LONG one)”]
"@type": "CatalogItemRequest",
"catalogItemRef": {
"id": "e783893b-3068-498d-b5cc-3be78cf4742d",
"label": "Debian 6"
},
"organization": {
"tenantRef": "vmdemo",
"tenantLabel": "vmdemo.local",
"subtenantRef": "a88b5eb5-210f-4f25-b074-95475f599018",
"subtenantLabel": "Lab-BG"
},
"quote": {
"leasePeriod": null,
"leaseRate": {
"type": "moneyTimeRate",
"cost": {
"type": "money",
"currencyCode": null,
"amount": 177
},
"basis": {
"type": "timeSpan",
"unit": "DAYS",
"amount": 1
}
},
"totalLeaseCost": null
},
"requestedFor": "kushmaro@vmdemo.local",
"requestedBy": "kushmaro@vmdemo.local",
"requestorEntitlementId": "e2117850-88ed-4564-a8e8-6fff77e8fede",
"state": "SUBMITTED",
"requestData": {"entries": [
{
"key": "provider-Cafe.Shim.VirtualMachine.Description",
"value": {
"type": "string",
"value": ""
}
},
{
"key": "provider-blueprintId",
"value": {
"type": "string",
"value": "e0f0b0d0-681d-45ee-9dfe-5b3466b161ef"
}
},
{
"key": "provider-Cafe.Shim.VirtualMachine.Reason",
"value": {
"type": "string",
"value": ""
}
},
{
"key": "provider-Cafe.Shim.VirtualMachine.MaxCost",
"value": {
"type": "string",
"value": "177.0000"
}
},
{
"key": "provider-VirtualMachine.CPU.Count",
"value": {
"type": "integer",
"value": 1
}
},
{
"key": "provider-Cafe.Shim.VirtualMachine.NumberOfInstances",
"value": {
"type": "integer",
"value": 1
}
},
{
"key": "provider-Cafe.Shim.VirtualMachine.TotalStorageSize",
"value": {
"type": "decimal",
"value": 0
}
},
{
"key": "provider-__Notes",
"value": {
"type": "string",
"value": ""
}
},
{
"key": "provider-provisioningGroupId",
"value": {
"type": "string",
"value": "a88b5eb5-210f-4f25-b074-95475f599018"
}
},
{
"key": "provider-Cafe.Shim.VirtualMachine.MinCost",
"value": {
"type": "string",
"value": "177.0000"
}
},
{
"key": "provider-VirtualMachine.Disk0.Size",
"value": {
"type": "string",
"value": "16"
}
},
{
"key": "provider-Cafe.Shim.VirtualMachine.AssignToUser",
"value": {
"type": "string",
"value": "kushmaro@vmdemo.local"
}
},
{
"key": "provider-VirtualMachine.LeaseDays",
"value": {
"type": "integer",
"value": 0
}
},
{
"key": "provider-VirtualMachine.Memory.Size",
"value": {
"type": "integer",
"value": 1024
}
}
]},
"preApprovalId": null,
"postApprovalId": null,
"retriesRemaining": 3
}
[/code]

I’ll review some of the JSON Code above.
If we’ll look at the two first lines, we are able to see what type this JSON request is.

[code lang=”js”]
"@type": "CatalogItemRequest",
  "catalogItemRef":   {
    "id": "e783893b-3068-498d-b5cc-3be78cf4742d",
    "label": "Debian 6"
  },
 [/code]

As mentioned, this specific request is a catalog item request, referencing the specific id and name of the catalog item requested.
By changing these two parameters , and assuming we have multiple catalog items that look the same (in terms of request fields / input params) , we are able to easily shift our request from one item to the other. Like requesting a Red Hat VM or a Windows VM , all according to specific needs.

Next part of the code, depicts which BG & Tenant the request was made for:

[code lang=”js”]
"organization": {
"tenantRef": "vmdemo",
"tenantLabel": "vmdemo.local",
"subtenantRef": "a88b5eb5-210f-4f25-b074-95475f599018",
"subtenantLabel": "Lab-BG"
},
[/code]

The subtenantRef value is actually the Business group UUID within vCAC , and the tenantRef is the UUID kept for the tenant. vCAC keeps tenants by name, which represent a single UUID for the tenant.
Next comes an interesting part, specifying who is this requested for, and by whom:

[code lang=”js”]
"requestedFor": "kushmaro@vmdemo.local",
"requestedBy": "kushmaro@vmdemo.local",
"requestorEntitlementId": "e2117850-88ed-4564-a8e8-6fff77e8fede",
"state": "SUBMITTED",
[/code]

another part of the code determines who is the assigned user for the VM, its owner:

[code lang=”js”]
"key": "provider-Cafe.Shim.VirtualMachine.AssignToUser",
"value": {
"type": "string",
"value": "kushmaro@vmdemo.local"
[/code]

The ‘RequestedFor’ and ‘AssignToUser’ fields, indicates the user that this request is done on behalf of. This opens up some very nice possibilities, in automating requests for other users.
Lets say you want to perform a mass request automatically for new groups or users who joined the organization, or maybe a QA environment for each of your QE team’s members (hint: vCAC Devops Post), so that when they come to work, they have a new build ready for testing.
If you want the API Requested VM to be requested and assigned for a different user, you’ll have to change the ‘AssignToUser’ and ‘Requested For’ parameters for a user of your choice (having the proper entitlement).

Another interesting thing to notice here is the request state. A new request is tagged as submitted, while a request that’s been done is marked as completed.
This allows for tracking of the request, also with the help of a ‘phase’ field, that is non-existing at time of submitting the request.

Lastly comes the request details.
This part of the request details all of the item’s specific details, whether its customer properties, CPUs, Memory etc. For ASD requests , this would hold the ASD form values filled in by the user.

By modifying parameters below, we can easily set the CPU / Memory numbers for the specific request.

[code lang=”js”]
{
"key": "provider-VirtualMachine.Memory.Size",
"value": {
"type": "integer",
"value": 1024
}
{
"key": "provider-VirtualMachine.CPU.Count",
"value": {
"type": "integer",
"value": 1
}
[/code]

This concludes the first part of the vCAC6 REST API series, in the next part (coming soon!) i’ll demonstrate how to use vCO to regenerate a new API request, and help you automate vCAC for different purposes.
As always – Leave your comments below!