The vCAC plug-in for vCO comes with an out of the box workflow for requesting catalog items from any vCAC host configured in the plug-in. Let's see how it's used and how to extending to request specific catalog items.

 

How to use the default "Request a catalog item" workflow

 

When you run it, the workflow presentation looks like:

Request a catalog item.PNG

 

where the "Catalog item" field opens a tree chooser to select the catalog item that you want to request, and the "Input value" field opens a pop-up editor for an array of composite types (key/value pairs basically):

Array of composite types.PNG

 

One limitation of this workflow is that the list of expected parameters is not pre-populated in the array of composite types. Another limitation is that for all the inputs the type of the value is "string". These limitations come from the vCO workflow presentation itself (difficulty of creating/loading default workflow input parameters involving composite types), and the fact that when you define an array of composite types all the elements must have the same value type (i.e. it's not possible to have some parameters as string and other as integers or booleans for example).

 

The good thing is that this approach works just fine for simple scenarios ("simple" catalog items) and, as you'll see, it's very easy to adapt it to more complex scenarios where, for example, a fixed collection of inputs is needed or inputs of different types are required. And the same applies for similar workflows like:

  • Request a catalog item on behalf of a user
  • Request a resource action
  • Request a resource action on behalf of a user

 

Then, how to get the list of expected input parameters for a specific catalog item? There are few approaches:

  • You know them already. For example if you are requesting a catalog item based on some ASD service blueprint that you created and published, or if you are requesting some well-known catalog item with well-known parameters. The important thing here to take into consideration is that once the blueprints are published the input parameters names coming from them start always with the prefix "provider-", in other words, if the blueprint defines for example a parameter called "username", the expected input parameter name will be "provider-username".
  • In case you don't know them, the most straightforward way is to run the "Request a catalog item" workflow itself for the catalog item, providing some dummy input parameter, and to check the log of the workflow execution. Most probably the workflow will fail, typically with a 400 BAD REQUEST message coming from the server, but you will get the list of expected input parameters printed.

 

get_input_parameters.png

  • Also, if you want to get them and populate them more dynamically from a piece of scripting, you can use directly the action "getRequestFormInputsForCatalogItem" from the module "com.vmware.library.vcaccafe.request".
  • Finally, as alternative, you can access the catalog item or request the catalog item from the catalog and, for example, use a browser functionality or plug-in like FireBug to capture the specific request and its inputs parameters. You can find more details about it (and related topics) in blog posts like:

 

And once you have the list of input parameters you can run again the workflow and set them and their values accordingly in the "Input value" field. Now let's see how to create custom workflows based on the default one to define custom workflow inputs forms and to combine different input values types.

 

How to create a custom workflow for requesting service-oriented catalog items

  • The first step is to duplicate the default workflow, e.g., to "Request a catalog item (service)".
  • After that you can edit the inputs of the workflow to include the default ones (instead of using the generic "inputs" parameter):
    • description (string, mandatory)
    • reasons (string, optional)
  • And depending on the service you may expose more or less input parameters depending on the catalog item that you want actually to request (which, at the same time can be another input of the workflow or "fixed" as a workflow attribute). For the example let's say that you want to expose the following inputs:
    • aString (string)
    • anInteger (catalog item type integer, vCO type number)
    • aDecimal (catalog item type decimal, vCO type number)
    • aBoolean (boolean)
  • Then you'll get a presentation like:

2014-06-13_1527.png

  • After that you have to replace, from the workflow schema, the "compositeTypeToProperties" action call with a custom Scriptable task:

2014-06-13_1521.png2014-06-13_1521_001.png

  • With the following scripting code:
  • 2014-06-26_1439.pngAnd that's all. The previous block of scripting code will set the proper values in the scripting object "properties", and after that the next "requestCatalogItem" action will receive that "properties" object and it will uses it to prepare and send the request.

 

How to create a custom workflow for requesting machine-oriented catalog items

This scenario is pretty much the same like the previous one, the only difference is the list of usual parameters that are needed to request a typical machine. For example, from the machine blueprint used in the beginning, these are:

  • blueprintId (string)
  • provisioningGroupId (string)
  • Cafe.Shim.VirtualMachine.NumberOfInstances (integer)
  • Cafe.Shim.VirtualMachine.TotalStorageSize (decimal)
  • VirtualMachine.LeaseDays (integer)
  • VirtualMachine.CPU.Count (integer)
  • VirtualMachine.Memory.Size (integer)
  • VirtualMachine.Disk0.Size (decimal)
  • VirtualMachine.Disk0.IsClone (boolean)

And defining them as inputs of a vCO workflow, for example as:

  • blueprintId (string)
  • provisioningGroupId (string)
  • numberOfInstances (vCO number)
  • totalStorageSize (vCO number)
  • leaseDays (vCO number)
  • cpuCount (vCO number)
  • memorySize (vCO number)
  • disk0Size (vCO number)
  • disk0IsClone (boolean)

Then at the end the scripting code to prepare the parameters for the request should look like:

2014-06-26_1442.pngThe values for the "blueprintId" and "provisioningGroupId" could be extracted from the requested catalog item itself in case it's provided as an input parameter as well, but a bit more of scripting code is needed.

 

Conclusion

The out of the box workflow "Request a catalog item", because of the reasons exposed previously, won't work by default in all the possible scenarios, but as you can see it's very easy to (re-)use it as the base for customized "Request my catalog item" workflows.

 

 

Edited (06/26):

vNico let me know that the expected way of setting a boolean within the properties didn't work in his scenario:

 

properties.put("provider-aBoolean", vCACCAFEBooleanLiteral.fromBoolean(aBoolean).getValue());

 

So that I updated the example and I propose as workaround his suggestion of using a plain string:

 

properties.put("provider-aBoolean", aBoolean ? "true" : "false");

 

Edited (10/31):

After Jase Machado and other colleagues comments it looks like somehow (I'm not sure how or why for now) some Machine Blueprints are published with their parameters 'Disk0.Size' defined as of type 'string' instead of type 'decimal' as described in the post. This causes the request to fail and an error with the message "A server error was encountered. Error requesting machine. Input string was not in a correct format.". The solution in this case is just replacing the line:

 

properties.put("provider-VirtualMachine.Disk0.Size", new vCACCAFEDecimalLiteral(disk0Size).getValue());

 

with:

 

properties.put("provider-VirtualMachine.Disk0.Size", disk0Size);

 

and to be sure that the workflow variable 'disk0Size' is of type 'string' and not of type 'number'.