Aria Automation Custom Resource Types - Onboarding

How to onboard existing instances of a custom resource type

Why we need onboarding

Often there are existing real world objects at the time of introducing Aria Automation custom resource types. These brown field scenarios require a way to onboard existing instances of the resource without recreating them. This post will present a way to do that.

Recap of the previous posts

In the previous posts Aria Automation Custom Resource Types - The Easy Way and Aria Automation Custom Resource Types - Schema update we created and updated a custom resource type definition.

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

How to onboard

For the sample myObject type, let's add a new input called existing meaning we do not want to create a new object but rather reuse an existing one.

Create myObject workflow modifications

We need to introduce a new input "existing" to the workflow, and use it to find the existing object, instead of creating it. In our case this will be an SQL SELECT instead of an SQL INSERT:

 1var id;
 2if (existing) {
 3    var records = db.readCustomQuery("SELECT id,name FROM myObjects WHERE name='" + name + "'");
 4    if (records.length) id = records[0].getProperty("id");
 5    else throw "Object with name '" + name + "' not found";
 6}
 7else {
 8    id = System.nextUUID();
 9    var date = new Date();
10
11    db.executeCustomQuery("INSERT INTO myObjects (id,name,weight,created) VALUES " +
12        "('" + id + "','" + name + " - (" + comment + ")'," + Math.round(weight) + ",'" + date.toISOString() + "')");
13}
14myObject = DynamicTypesManager.getObject("myNS", "myObject", id); // call Find by Id
15
16System.log(myObject.toSource());

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
 9  existing:
10    type: boolean
11resources:
12  myObject_1:
13    type: Custom.myObject
14    properties:
15      name: ${input.name}
16      weight: ${input.weight}
17      comment: ${input.comment}
18      existing: ${input.existing}

This is the new input form when deploying:

Our table with the pre-existing record we want to onboard:

and the deployment resource:

Id and create timestamp are fetched from the database table.

How to offboard

There are no input parameters for deleting a deployment or deployment resource, so we need to find another way to prevent deleting an object from the database. There are many options, like introduction an extra column with "protected" flag, or use some naming scheme to distinguish the objects we want to keep. In our example we choose a simple method: if the comment is (keep), the custom resource delete workflow will not remove the database entry.

Destroy myObject workflow modifications

1System.log("Destroying: " + input.toSource());
2if (-1 != input.name.indexOf("(keep)")) System.log("Keeping " + input.name);
3else db.executeCustomQuery("DELETE FROM myObjects WHERE id='" + input.id + "'");
4actionResult = true;

Deleting a deployment

Let's delete a deployment with (keep) comment of the resource:

The workflow logs:

The object still exists on the backend (in the DB table, in our case):

Wrap-up

We may need to onboard or offboard custom resource type objects. The above method allows us to do that without modifying the "real world" instances.

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