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:
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):
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.
- 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:
- After that you have to replace, from the workflow schema, the "compositeTypeToProperties" action call with a custom Scriptable task:
- With the following scripting code:
- And 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:
The 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.