VCF Automation Input Validations

Validating Automation inputs from GUI and API

Introduction

Validating inputs of VCF Automation can be implemented in a couple of ways. In this post we'll explore the different approaches and their limitations.

Cloud Template Validations

Cloud template syntax provides the first layer of validations. The input properties are documented at Broadcom documentation User input in VMware Aria Automation requests.

Here is a simple cloud template for demonstration purposes:

 1formatVersion: 1
 2inputs:
 3  count:
 4    type: integer
 5    default: 1
 6    minimum: 1
 7    maximum: 3
 8  zone:
 9    type: string
10    enum:
11      - lan
12      - dmz
13  dc:
14    type: string
15    minLength: 3
16    maxLength: 5
17    pattern: ^dc[0-9]+$
18  az:
19    type: string
20    $dynamicEnum: /data/vro-actions/com.test.validations/getAZs
21  security:
22    type: string
23    $dynamicEnum: /data/vro-actions/com.test.validations/protectionOptions?securityzone={{zone}}
24resources:
25  photon:
26    type: Cloud.vSphere.Machine
27    properties:
28      count: ${input.count}
29      image: photon
30      flavor: small
31      templateprop: value2
32      dc: ${input.dc}
33      az: ${input.az}
34      zone: ${input.zone}
35      tags:
36        - key: zone
37          value: ${input.zone}
38      networks:
39        - network: ${resource.net0.id}
40  net0:
41    type: Cloud.vSphere.Network
42    properties:
43      networkType: existing
44      constraints:
45        - tag: zone:${input.zone}

We have 5 inputs.

• The number of VMs in a deployment can be defined by the count input. The minimum and maximum values provide a simple validation for this field.

• The zone input has a predefined list of valid choices: lan and dmz.

• The dc field must be 3-5 characters long, must start by dc followed by digits.

• The az field values are defined by the return value of com.test.validations/getAZs Orchestrator action. This action returns an array of Strings: ["zone1", "zone2", "zone3", "zone4", "zone5"]

• The possible security input values are returned by the Orcherstartor action com.test.validations/protectionOptions. This action has a string input securityzone. We bind this action input to the template input zone. If the user selects dmz as zone, the only option of security input is hardened. For lan input there are 2 possible choices: hardened and relaxed. This is a simple illustration of inputs depending on each other.

Service Broker behaviour

Count field validated as expected:

Zone is a selectable dropdown:

The dc field must match the regex:

Az can be selected from the dropdown generated by Orchestrator action:

Security depends on the zone, here only hardened can be chosen for dmz zone.

These simple validations were provided by the Cloud Template syntax only.

REST API behaviour

Let's test our cloud template via the Catalog API:

If we provide valid inputs, the request is accepted and the deployment creation process starts:

Trying invalid count, zone, dc, az and security values:

The last case demonstrates the validation of combination of values provided to zone and security.

Custom Form value options

Custom Form provides an additional layer to provide input validations. This has already been discussed in the post vRA Custom Form Dropdowns with External Source.

Let's try to restrict the Prod1 project to allow to select AZs zone1 and zone2:

1if ("ffab9ffd-a072-4617-bbb4-54101b3b5dd1" == project) return ["zone1", "zone2"];
2return ["zone1", "zone2", "zone3", "zone4", "zone5"];

For the sake of simplicity we hardcode the projecId here.

Let's enable and add this to the custom form:

We cannot use this action on the cloud template, as we cannot bind the project to the action's input. The custom form allows that.

Service Broker functioning

Let's see how the form behaves now:

For the Prod1 project we can select only the first 2 zones.

REST API functioning

Let's try to ask for zone3:

Unfortunately that custom form dropdown action did not prevent the user to request zone3.

Service Broker Validations

To solve that, we can define additional validating actions on the form, and these also run in case the REST API is used. The validation action must return an empty string if the input is valid. Otherwise the returned string is displayed as a validation error message.

The script is written to avoid code dumplication: we call the custom form action to get the accepted values, and check if the input is on the list.

Drag this to the custom form, and bind inputs:

Now, if we try to request zone3 for Prod1 project:

Now REST API is also protected against invalid input combinations.

Summary

Cloud Template input properties, Custom Form value options and Custom Form validations has been demonstrated. Make sure to apply the correct combination of these to provide an easy-to-use GUI and prevent accepting invalid data via the REST API.

You can download the com.test.validations package containing the sample actions from GitHub: https://github.com/kuklis/vro8-packages