Using List Collectors in Template Based Catalog Items

[Ashok Madhavan1]

Using List Collectors in Template Based Catalog Items

Often you would come across cases where the template ( ARM/CFT/GDM/Terraform) would need multiple values to be selected against a single parameter. For example, there could be a need for a single VM that needs to be provisioned and multiple security groups need to be associated with it. In some other cases we might need more than one subnet that needs to be supplied. This article describes how to do it in CMP.

Broadly there are two parts to this:

1. Catalog Item Variable changes 
2. Sending proper values to the provider

Catalog Item Variable Changes

ServiceNow catalog item supports many different types of variables. For multiple value backed by a table, the platform provides two options.

• Lookup Multiple Choice - It is a eager loaded radio box
• List Collector - Real multi select and is loaded as needed.

The 'List Collector' is the real option that works for us. This article describes this usage.

 Choose the catalog item variable that needs to be modified. Make the 'type' as 'List Collector'. In the 'Type Specifications' tab, make sure you choose the proper table. For real use cases you would need to provide the proper reference qualifier so that only the pertinent values are shown for the user. In these cases, the reference qualifier will filter the data so that only a subset of resources from the given Location/Region or some logic similar to that. Will not go into reference qualifier details in this article.

One of the most important things to know about List Collectors is that when the form is submitted, the value that is sent is a comma separated list of sys_IDs. We will need to remember this almost all the providers of templates expect the value to be comma separated set of resource IDs and not ServiceNow sys IDs. We will need to convert thisCSV of sys_IDs toCSV of resource IDs. That brings us to the next section.

Sending proper values to the provider

Now that the catalog item will send a CSV of sys IDs, the downstream system needs to convert it into aCSV of resource IDs. There are different ways to do it. The best way to do it would be using a Blueprint Operation Policy. In this policy we will intercept the data that was sent by the user, call a script that will update the value of the variable so that it is a CSV of resource IDs and not a CSV of sys IDs.

The below diagram shows the various policies and where they are applied during provisioning:

 

The Blueprint Provision policy would be the best one to apply in this use case. For this , we will need to do the following:

1. Create a Blueprint Provision policy on this blueprint.
2. Associate the script as an action to this policy.
3. Publish this policy.

The steps will be :

Get to Policy ( Cloud Admin Portal --> Governance --> Policy )

Create a new Policy, provide a nice name. Choose the trigger type to be 'on Blueprint Provision'.

Then choose the blueprint. This will be the catalog item you created and want to change. 

Then save it.

We need to create a action that will call a script include that will get the CSV of resource IDs. The script include that converts a give CSV of sys IDs to CSV of resource IDs could look something like this:

var SysId_to_ObjectIdConverter = Class.create();
SysId_to_ObjectIdConverter.prototype = {
    initialize: function() {
    },
	convert : function(sysIdCSV) {
		var gr = new GlideRecord("cmdb_ci_vm_instance");// Have your table name here
		gr.addQuery("sys_id", "IN", sysIdCSV);
		gr.query();
		var object_ids = [];
		while(gr.hasNext()) {
			gr.next();
			object_ids.push(gr.getValue('object_id'));
		}
		// return a json if needed.
		// if a CSV is needed, send CSV instead of json ==> return object_ids.join(",");
		return  JSON.stringify(object_ids);
	},

    type: 'SysId_to_ObjectIdConverter'
};

Create a script include like the above. 

Let us call this script from a Policy Action script so that a policy action can invoke this.

When you create it, the system will automatically create a placeholder info.

You will need to change the customScript() method to call the SysID2ObjectID convertor script.

Now change the customScript function to something like this: (you will change the 'formData.SecurityGroup' to the appropriate variable name as in your use case )

 

Save it and you are now done with the policy action script.

Then, Create a rule in the policy and provide a nice name.

For this use case, there is no need for any conditions. We will go ahead and create a new action.

 Choose 'Execute a Script' as the action type.

Provide a name for the action. Then choose the 'Action Script Category' and 'Action Script' from your previous steps.

Click submit.

Then publish your policy. Do not forget this step.

When the user submits an order, the system will convert the sys IDs into CSV ( or JSON as coded in the script include) and pass the values downstream. The template execution will go as expected.

[Ram Devanathan1]

Much awaited feature, glad to see a simple approach to do this Ashok. Thank you for all your excellent knowledge docs.

[Ashok Madhavan1]

Thanks Ram.