January 2023 – snhackery

Service Account Management, Part XIV

Posted on January 30, 2023 | by snhackery

“Take chances, make mistakes. That’s how you grow.”
— Mary Tyler Moore

Last time, we modified and tested the automated example Subflow using our new approach, so now we have to do the same thing with our manual example. Because we are now creating our Catalog Task in the primary Flow, much of the work that was previously done in the earlier version of the Subflow has now been moved to the primary Flow, so there won’t be much left to do in the manual version of the Subflow. In fact, it may even be possible to create a generic Subflow that would handle all manual implementations. For now, though, let’s just create one specifically for our example and we can explore that possibility at some later point.

Under our new approach with two parallel tracks (one for the task creation and the other for launching the type-specific Subflow), we cannot put any post-task-closure logic in our Subflow since the wait logic is in one track and the Subflow is running independently in another. In our original example, once the task closed we pulled the password out of a catalog variable and then removed that value from the variable so it would not be left on the records after processing. We still need to do this, but since it cannot be done in the Subflow, we will have to move these steps to the primary Flow. And since the password was originally sent back in the Subflow outputs, which will continue for all automated implementations, we need to set up a Flow Variable that can be populated from either track to make all of this work for both types.

To create a Flow Variable in the App Engine Studio, pull up the primary Flow and use the ellipses menu in the upper right-hand corner to select Flow Variables.

We will call our new variable password and set the type to String. It would be nice to set the type to Password or some other masked data type, but in the current version, that does not appear to be an option.

Now that we have our variable defined, we can populate it in both parallel branches where appropriate, and then use in the outgoing email instead of using the Subflow outputs. Under the branch that creates the Catalog Task, we can add a new step to pull the password value out of the variables linked to the task.

*Pulling the password value out of the Catalog Task variables after task closure*

Now, the one thing that we do not want to do is to overlay a value provided by the other branch running the Subflow, so before we use this value to populate our new variable, we will want to make sure that a value is there. To do that, we add a simple If condition.

*Checking for the presence of a password value*

Once we know that a password was provided, indicating a manually fulfilled request, we then use that value to populate our Flow Variable.

*Setting the value of the Flow Variable*

That should take care of the first parallel branch. Now we need to do something similar for the second branch. After we run our Subflow, we can pull the password value returned by the Subflow and use it to populate our new variable.

*Populating the variable from the Subflow outputs*

Now we just need to go into the step that sends out the email containing the password and change the source of the email body from the Subflow outputs to the new variable.

*Sending out the password from the variable instead of the Subflow outputs*

That should take care of all of changes for the primary Flow. In fact, virtually all of the work that was done in the original manual example Subflow has now been moved to the primary Flow, so there isn’t much left to do in the Subflow. Let’s pull that guy up now and strip out everything that we are now handling in the Flow and see what’s left.

*Stripped down version of the manual fulfillment Subflow*

As you can see, the only thing left in the Subflow is to assign the Subflow outputs. This would indicate that we could do yet another redesign and have either a generic manual Subflow, or make the Subflow optional and only include one if the fulfillment is automated. We could add the owner instructions to the type record, fetch both the password and the success/failure from the task, and then even the automated Subflows would have no need for outputs. They would communicate to the primary Flow via the task record. But before we get too far ahead of ourselves, let’s see if all of this works as it is. Now that we have modified the primary Flow, we will need to retest both the automated example and the manual example to see if they both work. That sounds like a good subject for our next installment.

Service Account Management, Part XIII

Posted on January 25, 2023 | by snhackery

“Challenges are what makes life interesting and overcoming them is what makes life meaningful.”
— Joshua J. Marine

Last time, we finished up with the modifications to our primary fulfillment Flow, so now we need to modify one of our example Subflows so that we can test out this new approach to the design. Since we already had the first example working under the old design, let’s start with that one, the one that builds ServiceNow Service Accounts. Even though we did not build the Subflows in the App Engine Studio, they do appear there once they are created, so we can edit them while in the studio without having to resort to the older Flow Designer.

*Selecting the Subflow from the dashboard*

The first thing that we will want to do is to alter the input from a Requested Item to a Catalog Task.

Next, we will need to alter the source of the Requested Item record in the first step. Now that we are using the Catalog Task as input, we will have to pull the Requested Item record from the appropriate Catalog Task property.

*Getting the Requested Item record from the Catalog Task*

The remainder of the existing workflow should be OK as it is, but under our new approach, our automated Subflow has one additional responsibility: we need to close the Catalog Task, both for a successful completion and for any kind of failure. Let’s handle the success story first by inserting an Update Record action just before we assign the Subflow outputs.

*Closing the task on a successful completion*

On the failure branch, we need to do the same thing, with different values, right before we assign the Subflow outputs at the end of that process.

At this point, all we need to do is to Save and Activate the Subflow and take it out for a spin. The easiest way to try it out would be to jump into the Service Catalog and place another order.

Looking at the resulting Requested Item reveals that the Flow and Subflow executed successfully and the account was created.

*Resulting Requested Item in Closed Complete state*

So the Subflow that was working before is now working again using our new approach. Now we have to modify the manual example that wasn’t working before and see if that guy works under our new approach as well. Let’s jump into that next time out.

Service Account Management, Part XII

Posted on January 13, 2023 | by snhackery

“Never put off until tomorrow what you can do the day after tomorrow.”
— Mark Twain

Last time, we started reworking our primary fulfillment Flow to resolve the problem that we encountered during the testing of our second example Subflow. In the midst of that process, we found that we needed to rework the inputs on our custom Action that calls the type-specific Subflow, so let’s fire up our old friend the Flow Designer and take care of that now. The first thing that we will want to do is to delete the existing Requested Item record input.

*Deleting the existing input for the Requested Item*

Once that is gone, we will want to replace it with a new input for the Catalog Task.

Next, we need to jump down to the script step and modify its inputs in the same way and map the new catalog task input to the matching action input.

*Mapping the new Catalog Task input to the script step’s inputs*

And finally, we will want to modify the script to pass in the new catalog_task variable instead of the original requested_item variable.

(function execute(inputs, outputs) {
	try {
		var result = sn_fd.FlowAPI.getRunner()
			.subflow(inputs.subflow)
			.inForeground()
			.withInputs({catalog_task: inputs.catalog_task})
			.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);

Now we can Save and Publish our modified Action and get back to our work on the primary Flow, but before we can test anything, we will need to modify all of our Subflows. For one thing, our Subflows are not expecting to receive a Catalog Task right now, and of course, since we are sending in a Catalog Task, that will requiring altering the logic in both of our example Subflows. But let’s finish up the primary Flow before we worry too much about that.

Now that our Create Service Account custom Action takes a Catalog Task as an input, we can drag the data pill from the Look Up Record step into the appropriate input and click on the Done button.

*Mapping the Catalog Task to the action input*

At this point, the rest of the primary Flow should continue to work as originally conceived. Future steps will not execute until both parallel branches have been completed, so automated Subflows should end when the second branch is completed and manual Subflows should end when the first branch is completed. Either way, the rest of the primary Flow should execute as before once both branches have finished their work.

The next thing that we will need to do before we can resume testing is to modify one or both of the example Subflows. Both of those will require a bit of redesign to accommodate our new approach, so that sounds like a great subject for our next installment.

Service Account Management, Part XI

Posted on January 10, 2023 | by snhackery

“Don’t waste your time being upset about something you can’t change. Begin again and do it better this time.”
— Joyce Meyer

Last time, we finished up our second fulfillment Subflow and took it out for a spin. Unfortunately, our first test of the new process died before it ever really got off of the ground. It turns out that you cannot launch a Subflow from a script when that Subflow contains a manual task that may not be completed for some time. Our Subflow ended with an error message indicating that the Subflow was in a wait state, which is actually true, as the Subflow was waiting for the manual task to be completed.

*Failed text of second fulfillment Subflow*

This is no small problem. If we cannot convince the script to wait for the manual task to be completed, then we are going to have to rethink the entire approach to the primary Flow. We don’t really need a task to be created when the process is automated, but we could still open up the task in the primary Flow, and then pass the task to the Subflow instead of the Requested Item. This would mean that any automated Subflows would have the responsibility of closing the task, but that would work. The problem, of course, is that if you check the Wait box on the task, no further steps in the process will execute until the task is closed, and the task isn’t set to be closed until you execute those future steps. That’s not going to work!

Fortunately, the Flow Designer allows you to run separate steps in parallel. We can create the task in one branch and then call the Subflow in a separate parallel branch. This should work, although it is a complete redesign of everything that we have put together so far in the fulfillment realm. Oh, well … as one of my previous supervisors used to tell me all the time, if it was easy, then anyone could do it!

So here is what we need to do: instead of calling the appropriate Subflow and passing in the Requested Item, we will need to create two parallel paths with one responsible for creating the task and waiting for its completion and the other responsible for calling the appropriate Subflow. Since you cannot drag data pills from one parallel branch to another, our second branch will need to wait for a bit to insure that the task has been created, and then read the task from the database so that it can have a task data pill to pass in to the selected Subflow. This changes quite a number of artifacts that we have already built, so let’s dive in and start hacking things up. To begin, let’s pull up our primary Flow in the App Engine Studio and insert a Do the following in parallel Flow Logic step right after we fetch the Service Account Type record.

Under the first parallel path we will create our task using the Create Catalog Task action.

We will assign the task to the fulfillment group specified in the type record so that the task gets routed to the appropriate fulfillment group. For automated fulfillment processes, the automation will need to close the task with the appropriate closure code before returning to the primary Flow, which should keep the task from showing up in that group’s active work queue.

Our other branch will need access to that task record, but since you cannot drag data pills from one parallel branch to another, we will need to fetch the record from the database. Before we do that, though, we will want to make sure that the other branch has created the record, so we will want to wait a bit before we go searching for it. We can do that with another Flow Logic option, Wait for a specific duration of time.

*Waiting for the task record to be created*

10 seconds may be way too much time, or it may not be enough in some circumstances, but it is a good place to start and we can adjust it in the future if needed. After waiting for the record to be created, the next thing that we will want to do is to fetch the record so that we can pass it in to our appropriate Subflow. To do that, we will use a Look up record action.

Now that we have our task record in hand, we can drag our existing Create Service Account action in under this second parallel branch as the next step. However, the current version of the action is expecting a Requested Item record as input, and under this new approach, we are going to want to pass in the Catalog Task instead. We will need to modify that action to alter the input, which will also affect all of our existing Subflows as well. That sounds like a good subject for our next installment.

Service Account Management, Part X

Posted on January 3, 2023 | by snhackery

“The only difference between a problem and a solution is that people understand the solution.”
— Charles Kettering

Last time, we started building out the second of our example fulfillment Subflows when we determined that we needed to build a custom Action to clear out the password value from the new Catalog Item Variable that we created so that the fulfilling technician could provide the new account’s password to the Flow. This is a relatively simple Action, so let’s jump right into the Flow Designer and get to it.

To begin, let’s click on the New button and select Action from the drop-down list.

We will give our new Action the name Clear Password From Task, and give it a single input, the task record that contains the password variable.

Since all we want to do here is to clear the value from the password variable, there is no need for any outputs, so we will just add a single Script step and insert the following code:

(function execute(inputs, outputs) {
	var task = inputs.catalog_task;
	task.variables.account_password = '';
	task.update();
})(inputs, outputs);

For that to work, we need to map the task record from the Action inputs to the script step’s inputs.

And that is all that there is to that. At this point, all we need to do is to Save and Publish our new Action and then we can jump back into our Subflow and use it in our next step.

*Using our new custom Action to clear the password variable*

Now all we have to do is to assign values to the Subflow outputs and that should complete the successful branch of our Subflow. Then we will need an Else condition to handle the possibility that the task was not completed successfully. But first, let’s wrap up the successful branch by assigning values to the Subflow outputs.

Here we run into a bit of a snag, as you cannot use the password value pill to populate the password output because the password output variable is a 2-way encrypted value and the password value pill is a simple string. To solve that problem, we resort to scripting, with the following code:

return fd_data._3__get_catalog_variables.account_password

This may or may not work — we will have to try it. If it doesn’t properly convert, then we will have to come up with something else. But let’s give this a shot and see what happens.

So now all that is left is to assign the Subflow outputs in the event of a failure. We do that under an Else condition, and grab the reason from the task’s closure notes.

*Setting the Subflow outputs for failure condition*

Once we Save and Publish our new Subflow, we can jump back into the Service Catalog and place another order to try it out. This time, we will select Active Directory from the list of types so that we can drive the process through our new Subflow and see what happens.

After clicking on the Request button, we are brought to our new Request record.

Clicking on the item will bring us to the Requested Item record.

At this point, we can see that something went terribly wrong somewhere along the line. The item is sitting at the Closed Incomplete state, and we never even got the chance to work the manual task that should have been created by our Subflow. That’s definitely not good. Well, that’s obviously not an optimal outcome for our test, but it should make for a fun debugging exercise for our next installment!

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