Catalog Variables – snhackery

Service Account Management, Part IX

Posted on December 28, 2022 | by snhackery

“There is joy in work. There is no happiness except in the realization that we have accomplished something.”
— Henry Ford

Last time, we fixed a few problems with our ServiceNow account password, which wrapped up the work on that particular Subflow. That was also enough to prove out our primary Flow for fulfilling the Catalog Item we built to request a new Service Account. Now it is time build another Subflow for our other example account type, Active Directory. This time, instead of an automated fulfillment process (which, of course, is possible for A/D with some integration) we are going to assume that some technician has to create the account, so we will be issuing a Catalog Task to the folks who would be doing that. This is just to demonstrate the manual fulfillment process as opposed to the automated approach that we used last time.

Before we do that, though, let’s take a quick side trip to add Stages to our primary Flow. Flows associated with Catalog Items should always identify the fulfillment stages to provide insight into the status of the fulfillment process. We can add Stages to the Flow in the App Engine Studio by pulling up the Flow, clicking on the More Actions menu (‘…’) in the upper right-hand corner, and selecting Flow stages from the drop-down menu. Select Requested Item from the Add stages from a template selection and then click on the Add stages button. This will pull in all of the Stages defined for a Requested Item. Now all we have to do is to click on the Add a Stage button in the space above each step that begins a new Stage and choose the appropriate stage from the available list.

I selected Fulfillment for the initial Stage, Delivery for the step that creates the record in our account table, and Completed when the password email is sent out. Also, not shown on that screen shot, I selected Request Cancelled when the Service Account could not be created. That should be enough to get us started, but we may find the need to fine tune that a little bit once we see how it all comes out in testing.

There is one other thing that we need to do before we jump into building out the manual Subflow for Active Directory accounts. Since we are assuming that a technician will be creating the account and setting the initial password, we will need some way for the technician to provide the password back to the primary Flow so that it can be communicated to the requestor via the notification email. One way to do that would be to add one more variable to our Catalog Item and hide it everywhere except on the task record. Once the task is closed, we can then lift the value off of the task, pass it back to the primary Flow and then clear the value on the task record, as it will no longer be needed. With that out of the way, we should now be able to build out our new Subflow.

To begin, let’s pull up our old friend the Flow Designer and create a new Subflow called Active Directory Service Account Creation. We will use the same inputs and outputs that we created for our ServiceNow Subflow, as that is what our calling Action requires.

The first thing that we will want to do is to create the task, and there is an action already set up to do just that, so we select that and populate all of the appropriate fields.

We also want to check the Wait box, as we do not want the rest of the Flow to run until the task has been completed and we can see how it turns out. And we want to snag the variables that we need from the request so that they will be available on the task record.

*Catalog Task creation step (continued)*

Once the task is no longer active, we will want to check to make sure that it was completed successfully. We can do that with an If condition that looks to make sure that the State of the ticket is Closed Complete. If it is, then we will want to grab the password entered by the technician so that we can pass it back to the calling Flow. To do that, we use the Get Catalog Variables action.

*Grabbing the password from the task record*

Once we have a data pill with the password value that we can use for our Subflow outputs, we do not need to have the value in the database. We will want to clear the value from the new password variable that we just added. Unfortunately, while there is an existing Get Catalog Variables action shipped with the platform, there is no corresponding Set Catalog Variables action that we can use to remove the value of the variable. For that, we are going to have to create yet another custom Action.

Even though an Action that clears the value of a variable is relatively simple, creating a custom Action is a little bit of an involved process. This seems like a good place to stop for now, then, and we can jump right into creating that new Action right at the top of our next installment.

Service Account Management, Part VI

Posted on November 30, 2022 | by snhackery

“Never discourage anyone who continually makes progress, no matter how slow.”
— Plato

Last time, we built out a fulfillment Subflow for one of our two example Service Account types, so now we can build the primary Flow that will call that Subflow and do all of the other work required to fulfill the request. Although you can configure a Flow to call a Subflow using the Flow Designer, you have to specify the Subflow during the development process. In our case, the Subflow that we will want to use will be dependent on the type of Service Account requested, so we will not know which Subflow will need to be called until execution time. Ideally, we would want to look the type requested, read the record for that type to get the Subflow, and then execute the Subflow specified in the type record. Since there doesn’t seem to be a way to do that out of the box, we will need to build out a custom Action to make the Subflow call via script. I created a simple Action called Create Service Account that takes the name of the Subflow and the Requested Item record as input and returns the same outputs as our fulfillment Subflows. The script for that Action looks like this:

(function execute(inputs, outputs) {
	try {
        var result = sn_fd.FlowAPI.getRunner()
            .subflow(inputs.subflow)
            .inForeground()
            .withInputs({requested_item: inputs.requested_item})
            .run();
		var returned = result.getOutputs();
		for (var name in returned) {
			outputs[name] = returned[name];
        }
    } catch (e) {
        outputs.success = false;
		outputs.failure_reason = 'Subflow execution failed with error: ' + e.getMessage();
    }
})(inputs, outputs);

All it does is launch the Subflow with the Requested Item record passed and returns whatever is returned by the called Subflow. This will essentially perform the same function as the Call Subflow action, but with the added benefit of allowing us to pass in the name of the Subflow to be called rather than have it hard-coded in the Flow.

Now that we have the ability to call a configured Subflow, we can jump back into the App Engine Studio and build out the primary Flow. On the dashboard for our application, we can scroll down to the Logic and automation section and then click on the Add button right after the section header.

*To create a new Flow, click on the Add button near the Logic and automation section header*

Once you click on the Add button, a selection list appears, with Flow being the first option.

On this screen, we simply select Flow from the available options, which takes us to the next screen.

On this screen we enter Service Account Request Fulfillment in both the Name and the Description fields and then click on the Continue button.

The next screen just comes up long enough for the basic Flow to be created, after which we are brought to the successful completion screen.

At this point, the Flow now exists, but it has no steps, so we will want to click on that Edit this flow button to start building out the logic of the Flow. We will select Service Catalog as the trigger, and as we did with our sample Subflow, the first thing that we will want to do is to gather up the variable values from the Requested Item.

*Grabbing the variable values from the Requested Item*

This time, we will need the type, the responsible_group, and the account_id from the request. The next thing that we will want to do is to read the Service Account Type record for the requested type, so we will select Look Up Record for our action.

*Fetching the Service Account Type record*

We are looking for the record where the Name field matches the type selected on the Catalog Request. Once we have the variable values from the request and the matching type record, we can call our type-specific Subflow using the Action that we created for that purpose.

*Creating the Service Account using the type-specific Subflow*

Now we need to check to make sure that the account was created, so we add an If condition based on the success flag returned by the Subflow.

If the account was created successfully, we will want to create a record for the account in our Service Account table, but before we can do that we need to fetch the record for the responsible group from the sys_user_group table. We have the name of the group from the catalog item variables, but we need the sys_id of the record to populate the Service Account record. We can do this with another Look Up Record action, searching the table for a record with the same name.

With the user group record now in hand, we have enough information to create the new record in our Service Account table.

*Creating the new Service Account table record*

Once we have created a record for the new Service Account, we will want to inform the user that the account has been created and is available for use. I took a short-cut here and just stubbed out a simple email, but ideally you would want to use a mail template and include some boiler-plate verbiage about company policies on the use of Service Accounts, security concerns, and related information on the owner’s responsibilities. All of that would ultimately be up to anyone attempting to implement such as system, and has little relevance to the workings of the process, so I will leave that to others and just include something simple as an example.

*Informing the user of the account’s availability*

The password for the account should be sent out in a separate email, but before we do that, let’s go ahead and close the Requested Item now that the account has been created and the requested notified. To do that, we will select Update Record for our action and then drag in the pill for the Requested Item record, which will then populate the Table value.

Now all that is left to do is to send the password for the account to the requester. I took another short-cut here in that the only contents of the body of the email is the password itself with no other information, but again, this is only a sample. An encrypted email from a template would obviously be preferable here, but this at least provides a placeholder for performing this task in a much better way.

That completes the process for a successful account creation, but if the account could not be created for any reason, we still need to close out the Requested Item with that information. To do that, we will add an Else condition to our If and then insert one more step under the Else.

*Closing the Requested Item on account creation failure*

And that’s all there is to that. Now that we have our completed Flow, we can go back into our Catalog Item and specify this Flow for fulfillment. Once that has been done, we can finally request the item to generate a Requested Item record that we can use to test all of this out. That will probably be a little bit of an adventure, so let’s save all of that for our next time out.

Service Account Management, Part IV

Posted on November 18, 2022 | by snhackery

“For the things we have to learn before we can do them, we learn by doing them.”
— Aristotle

Last time, we finished up our two data tables and got started on the Catalog Item that people will use to request a Service Account. Today we need to jump back into the App Engine Studio and complete the work on that Catalog Item. To begin, we can pull up the dashboard for our Scoped Application and select our new Catalog Item from the list of Experiences.

*Selecting the Catalog Item from the list of Experiences*

Once we select our Catalog Item, a new tab opens up with all of the details.

Here we can see that there is quite a lot more detail that we can add, but before we start exploring all of the links on the right-hand side, let’s go ahead and scroll down and complete the information for the Item details section.

For now, we will just use the same image that we used for the app itself and the same text as the Short Description that we entered earlier. We may improve all of that later on, but this will get us going for now. At this point, we can click on the Continue to Location -> link.

Here we can specify that we want the item in the Technical Catalog and assign it to the Services category. Then we will click on the Continue to Questions -> link to move on to the next section.

Questions are the means through which we collect information from the requester about their request. For our purpose, we will need to know the type of account requested, the desired user ID or account name, and the name of the group that will be responsible for the account. For the benefit of the request approvers, we may also want to collect the purpose of the account or the justification for its creation. We can add these questions, one at a time, but clicking on the Insert new question button.

On the Question insert screens, we can define a name and a label for our question as well as type, which in our case will be a choice list from our Service Account Type table. You can see the two options that we added to the table come up on the drop-down list in the Question Preview section. We can Save this Question and continue to add more Questions using the Insert new question button. When we are all through adding our questions, they appear on the list.

Once we have completed all of the Questions for our item, the next step is to move on to the Settings section.

Here we select the label for the submit button and check a few boxes to configure how our item will appear on the Service Portal. Once that is done, we move on to the Access section.

Here, we make our item available to admins, ITIL users, and the Service Desk. Once that has been established, we move on to the Fulfillment section.

Here we need to select the fulfillment flow that will be used to respond to the request. We have not yet built out a fulfillment flow for our Catalog Item, so we will need to do that first before we can complete this section. Once it has been completed, we can circle back and select it from the list to complete this section, after which the only thing left to do will be to go to the final Review and Submit section. Creating a flow that will handle all of the various types of Service Accounts will be a bit of work in and of itself, so let’s stop here for now and jump right into that next time out.

Scripted Value Columns, Part VI

Posted on August 5, 2022 | by snhackery

“Do not be too timid and squeamish about your actions. All life is an experiment. The more experiments you make the better.”
— Ralph Waldo Emerson

Last time, we used the new scripted value columns feature to create columns from the comments and work notes of an Incident. Today we are going to do something similar, but instead of working with journal entries, we will try something with the optional variables that can be associated with Service Catalog items. For our demonstration, we will use the Executive Desktop catalog item, which has a number of defined ordering options.

Let’s see if we can’t create a list of all orders for this item, and include some of the catalog item variables on the list. To begin, let’s make another copy of our example scripted value provider and call it ScriptedCatalogValueProvider.

var ScriptedCatalogValueProvider = Class.create();
ScriptedCatalogValueProvider.prototype = {
	initialize: function() {
	},

	getScriptedValue: function(item, config) {
		return Math.floor(Math.random() * 100) + '';
	},

	type: 'ScriptedCatalogValueProvider'
};

Let’s also make a copy of our last configuration script and change things over from the Incident table to the Requested Item table, and define some scripted value columns for some of the catalog item variables associated with this item.

var ScriptedValueConfig2 = Class.create();
ScriptedValueConfig2.prototype = Object.extendsObject(ContentSelectorConfig, {
	initialize: function() {
	},

	perspective: [{
		name: 'all',
		label: 'all',
		roles: ''
	}],

	state: [{
		name: 'all',
		label: 'All'
	}],

	table: {
		all: [{
			name: 'sc_req_item',
			displayName: 'Requested Item',
			all: {
				filter: 'cat_item=e46305bdc0a8010a00645e608031eb0f',
				fields: 'number,request,requested_for',
				svcarray: [{
					name: 'cpu',
					label: 'CPU Speed',
					heading: 'CPU Speed',
					script: 'global.ScriptedCatalogValueProvider'
				},{
					name: 'memory',
					label: 'Memory',
					heading: 'Memory',
					script: 'global.ScriptedCatalogValueProvider'
				},{
					name: 'drive',
					label: 'Hard Drive',
					heading: 'Hard Drive',
					script: 'global.ScriptedCatalogValueProvider'
				},{
					name: 'os',
					label: 'Operating System',
					heading: 'Operating System',
					script: 'global.ScriptedCatalogValueProvider'
				}],
				aggarray: [],
				btnarray: [],
				refmap: {},
				actarray: []
			}
		}]
	},

	type: 'ScriptedValueConfig2'
});

Finally, let’s make a copy of our last test page and call it scripted_value_test_2, and then edit the widget options to use our new configuration file. Now let’s jump out to the Service Portal and pull up the page and see what we have so far.

So far, so good. Everything seems to work, but of course all we have in our new columns is the random numbers that we threw in there for demonstration purposes earlier. But that just means that all we have left to do now is to figure out what kind of script we need to pull out the actual variable values that are associated with each catalog item order. To begin, let’s map our variable names, which are also our column names, to their catalog item variable (question) sys_ids.

questionMap: {
	cpu: 'e46305fbc0a8010a01f7d51642fd6737',
	memory: 'e463064ac0a8010a01f7d516207cd5ab',
	drive: 'e4630669c0a8010a01f7d51690673603',
	os: 'e4630688c0a8010a01f7d516f68c1504'
}

This will allow us to use some common code for all of the columns by passing in the correct sys_id for the catalog item variable associated with that column.

getScriptedValue: function(item, config) {
	var response = '';

	var column = config.name;
	if (this.questionMap[column]) {
		response = this.getVariableValue(this.questionMap[column], item.sys_id);
	}

	return response;
}

Now we need to build the getVariableValue function, which takes the sys_id of the question and the sys_id of the requested item as arguments. To locate the value selected for this question for this order, we use the sc_item_option_mtom table, which maps requested items to individual question responses.

getVariableValue: function(questionId, itemId) {
	var response = '';

	var mtomGR = new GlideRecord('sc_item_option_mtom');
	mtomGR.addQuery('request_item', itemId);
	mtomGR.addQuery('sc_item_option.item_option_new', questionId);
	mtomGR.query();
	if (mtomGR.next()) {
		response = mtomGR.getDisplayValue('sc_item_option.value');
	}

	return response;
}

Now let’s save that and give the page another look.

Well, that’s better, but it is still not exactly what we want. The values that appear in the columns are the raw values for the variables, but what we would really like to see is the display value. To get that, we have to go all the way back to the original question choices and find the choice record that matches both the question and the answer. For that, you need the sys_id of the question and the value of the answer.

getDisplayValue: function(questionId, value) {
	var response = '';

	var choiceGR = new GlideRecord('question_choice');
	choiceGR.addQuery('question', questionId);
	choiceGR.addQuery('value', value);
	choiceGR.query();
	if (choiceGR.next()) {
		response = choiceGR.getDisplayValue('text');
	}

	return response;
}

To utilize this new function, we have to tweak our getVariableValue function just a little bit to make the call.

getVariableValue: function(questionId, itemId) {
	var response = '';

	var mtomGR = new GlideRecord('sc_item_option_mtom');
	mtomGR.addQuery('request_item', itemId);
	mtomGR.addQuery('sc_item_option.item_option_new', questionId);
	mtomGR.query();
	if (mtomGR.next()) {
		var value = mtomGR.getDisplayValue('sc_item_option.value');
		if (value) {
			response = this.getDisplayValue(questionId, value);
		}
	}

	return response;
}

Now let’s take one more look at that page now that we have made these modifications.

*Third and final test of our new portal page*

That’s better! Now we have the same text in our columns that the user saw when placing the order, and that’s what we really want to see here. Or at least, that’s what I wanted to see. You may be interested in something completely different, but that’s the whole point of this approach. You can basically script whatever you want to put whatever you want to put in whatever column or columns you would like to define. These are just a couple of examples, but there really is no limit to what you might be able to do with a little imagination and some Javascript.

So here is the final version of our second close-to-real-world example value provider script:

var ScriptedCatalogValueProvider = Class.create();
ScriptedCatalogValueProvider.prototype = {
	initialize: function() {
	},

	questionMap: {
		cpu: 'e46305fbc0a8010a01f7d51642fd6737',
		memory: 'e463064ac0a8010a01f7d516207cd5ab',
		drive: 'e4630669c0a8010a01f7d51690673603',
		os: 'e4630688c0a8010a01f7d516f68c1504'
	},

	getScriptedValue: function(item, config) {
		var response = '';

		var column = config.name;
		if (this.questionMap[column]) {
			response = this.getVariableValue(this.questionMap[column], item.sys_id);
		}

		return response;
	},

	getVariableValue: function(questionId, itemId) {
		var response = '';

		var mtomGR = new GlideRecord('sc_item_option_mtom');
		mtomGR.addQuery('request_item', itemId);
		mtomGR.addQuery('sc_item_option.item_option_new', questionId);
		mtomGR.query();
		if (mtomGR.next()) {
			var value = mtomGR.getDisplayValue('sc_item_option.value');
			if (value) {
				response = this.getDisplayValue(questionId, value);
			}
		}

		return response;
	},

	getDisplayValue: function(questionId, value) {
		var response = '';

		var choiceGR = new GlideRecord('question_choice');
		choiceGR.addQuery('question', questionId);
		choiceGR.addQuery('value', value);
		choiceGR.query();
		if (choiceGR.next()) {
			response = choiceGR.getDisplayValue('text');
		}

		return response;
	},

	type: 'ScriptedCatalogValueProvider'
};

The added columns still do not align with the original columns, which I would like to fix before I build a new Update Set, and we still have a couple more wrapper widgets to address, but I think we are getting close. Maybe we can wrap this whole thing up in our next installment.

Useful ServiceNow links:
Main web site:	https://servicenow.com
Developer site:	https://developer.servicenow.com
Annual Conference:	https://knowledge.servicenow.com