Aria Automation Custom Resource Types - Schema update

How to change the schema of a custom resource type

Custom Resource Schema

When we create a Custom Resource type based on an Orchestrator Dynamic Type, the schema of the type is automatically generated. This schema defines the inputs to create the object and the properties to present on the object. We may have to modify those later on.

vRealize Automation 8.7 introduced schema modification of ABX based Custom Resources, but it was unavailable for vRO-based CRTs.

Without an announcement, (from) vRA 8.8 we can update the schema of CRTs based on Orchestrator Dynamic Types. This is a significant enhancement: prior to that change we had to delete the CRT (along with the deployments) and recreate the type to make any changes to its schema.

A walk-through of how to do this update follows.

Recap of the previous post

In Aria Automation Custom Resource Types - The Easy Way we examined how to define the namespace, the Dynamic Type and the required workflows. Then we created the Custom Resource Type and a Cloud Template based on that.

In this second part we assume the steps in the previous post are completed, we have the Dynamic Type, the CRT and the CT created.

Scenario 1: add a new property

Extend the dynamic type

We may realize that we missed to represent an important property of the custom resource. For example we created a BackupPolicy type with name, frequency and start time. Then we need the retention time too, so we decide to add that to the custom type after defining and using the type.

Let's extend our myObject with the timestamp of the creation time. So our first scenario we introduce changes only in the output, not on the input side.

First we need to modify the Dynamic Type (see UpdateType myObject workflow):

1DynamicTypesManager.updateType("myNS", "myObject", "myNS", "myObject", "/Library/Dynamic Types/images/item-16x16.png", 
2  ["id", "name", "lastrefreshed", "weight", "created"]);

We need to extend our database schema with the column called "created" and return this new property in the Find by Id workflow:

 1if (1 == records.length) {
 2    var record = new Properties(); // convert ActiveRecord to HashMap
 3    for each(var column in records[0].getFieldNames()) { record.put(column, records[0].getProperty(column)); }
 4
 5    myObject = DynamicTypesManager.makeObject("myNS", "myObject", id, record.name);
 6    myObject.setProperty("lastrefreshed", new Date().toISOString());
 7    myObject.setProperty("weight", record.weight);
 8    myObject.setProperty("created", record.created);
 9}
10else {
11    System.warn("Number of objects found with id '" + id + "': " + records.length);
12    myObject = DynamicTypesManager.makeObject("myNS", "myObject", id, "MISSING");
13    myObject.setProperty("lastrefreshed", "");
14    myObject.setProperty("weight", 0);
15    myObject.setProperty("created", "");
16}

Also, update the Create myObject workflow to save creation time in the database:

1var id = System.nextUUID();
2var date = new Date();
3
4db.executeCustomQuery("INSERT INTO myObjects (id,name,weight,created) VALUES " +
5    "('" + id + "','" + name + "'," + Math.round(weight) + ",'" + date.toISOString() + "')");
6
7myObject = DynamicTypesManager.getObject("myNS", "myObject", id); // call Find by Id
8
9System.log(myObject.toSource());

Update the custom resource type and the cloud template

Let's refresh the workflow inventory in Cloud Assembly (Start Data Collection):

Open the custom resource schema by clicking on the Properties tab, add the new property and click Update:

Then create a new deployment. Here is the new custom resource object:

The database table:

Existing deployment resources

If we open a deployment created prior to our modifications, we can see the new property but its value is empty:

Altough, if the represented "real" object has the required value (for example we can get the BackupPolicy retention by an API call), then the new property can display the additional property. Let's test this with adding a value to our database table:

The deployment resource is now showing the correct value:

You may have to refresh the object with the day 2 action described in the previous post.

Scenario 2: add a new input

We may realize that we miss an inportant input parameter to create the custom resource object. For example, we want to get the region where the BackupPolicy is defined in, because it is included in the naming convention of the policies.

For the sample myObject type, let's add a new input called comment that will be included in the name of the object within brackets.

Create myObject workflow modifications

We need to introduce a new input "comment" to the workflow, and add it to the input "name" before creating the record:

1db.executeCustomQuery("INSERT INTO myObjects (id,name,weight,created) VALUES " +
2    "('" + id + "','" + name + " - (" + comment + ")'," + Math.round(weight) + ",'" + date.toISOString() + "')");

No other vRO modifications are needed now.

Update the custom resource type and the cloud template

Refresh the workflow inventory in Cloud Assembly (Start Data Collection), and modify the custom resource schema: add the new property:

Add a new input into the cloud template and map it to the new property:

 1formatVersion: 1
 2inputs:
 3  name:
 4    type: string
 5  weight:
 6    type: integer
 7  comment:
 8    type: string
 9resources:
10  myObject_1:
11    type: Custom.myObject
12    properties:
13      name: ${input.name}
14      weight: ${input.weight}
15      comment: ${input.comment}

This is the new input form when deploying:

Resulting table entry:

and the deployment resource:

Wrap-up

Real-world changes often require modification both adding a new property to the custom resource type, and adding a new input for creation. This case you need to combine the two scenarios above.

You can find the sample workflows at GitHub: https://github.com/kuklis/vro8-packages
com.dynamictypes.myobject-2.package includes the modifications for Scenario 1, and com.dynamictypes.myobject-3.package for Scenario 2.

Stay tuned

In the next post we'll discuss how to onboard and offboard existing resources into/from deployments without actually modifying them.