NOTE: ON APRIL 1, 2016 ACCENTURE COMPLETED THE ACQUISITION PROCESS OF CLOUDSHERPAS. AT THAT TIME THE CLOUDSHERPAS BLOG SITES WERE DOWNED FOREVER.
THIS IS THE RE-PUBLICATION OF MY ARTICLE FROM September 22, 2015 ON THE CLOUDSHERPAS SERVICENOW SCRIPTING 101 BLOG.
____________________________________________________________________________
Calling sub-workflows can help build upon existing functionality and reduce workflow complexity, making it a best practice if you're using ServiceNow Orchestration. But how do you do this?
In the first half of this post, I shared what you need to get started, including how to set up your own local MID server and create the sub-workflow. Today, I'll pick up where that post left off, describing how to create a framework workflow to call the sub-workflow, how to pass information to the sub-workflow and how to retrieve and work with the results.
Before we get into how to do all of this, I want to remind you about the Scripting 101 post on Orchestration Best Practices I wrote with mamann. In that post, we describe the concept of a framework for calling sub-workflows in order to best organize a large workflow into manageable, and hopefully, reusable components. With that in mind, the model for a framework I present here is extensible and demonstrates this concept.
Prerequisites
Conduct labs 1.1 and 1.2 of the previous article: ServiceNow Scripting 101: Calling a Sub-Workflow, Part I
Lab 1.3 — The Framework
1. Create a new Workflow
a. Navigate to Orchestration > Workflow Editor
b. A new tab on your browser should open to the Workflow Welcome page
c. To the far right, click on the Workflows tab, then click the plus button. This will display the New Workflows form.
d. Fill in the form with the following:
i. Name: Framework
ii. Table: Global
iii. If condition matches: -- None —
iv. Click the Submit button to create the new workflow
e. Your workflow desktop should look like this:
2. Click on the triple bar in the upper left of the desktop, then click on Edit Inputs. We will use this to define two test input variables for our workflow.
3. Add two new input variables:
a. Name: Host IP
i. Column Name: u_host_ip
ii. Type: String
iii. Order: 100
iv. Length: 100
v. Default Value: localhost
b. Name: Powershell Command
i. Column Name: u_powershell_command
ii. Type: String
iii. Order: 200
iv. Length: 100
v. Default Value: ls
c. Close the Workflow Inputs form
We will use these values to test our framework and sub-workflows.
4. On the far right, click on the Core tab to view the available Activities
5. At the bottom of the Core Activities list, expand the Utilities section
6. Left click and drag a Run Script activity out onto the desktop
7. Fill in the form as follows:
a. Name: Initialize
b. Script:
workflow.scratchpad.hostname = workflow.inputs.u_host_ip;
workflow.scratchpad.command = workflow.inputs.u_powershell_command;
gs.info('---> WF:PowerShell Sub-Workflow.initialize:\nFQDN: {0}, PS Command: {1}',
workflow.scratchpad.hostname,
workflow.scratchpad.command);
c. Click the update button to save.
This will initialize our scratchpad variables that we will use throughout the lifetime of the workflow.
8. Wire up your workflow to look like the following diagram:
9. Attach the sub-workflow that you built in the previous lab from the first half of this post. From the list of workflows, drag out the Powershell Sub-Workflow onto the workflow desktop.
10. The Activity Properties: Workflow form will be displayed.
11. Fill in the form with the following:
a. Workflow: Powershell Sub-Workflow
b. Map return value to: ${workflow.scratchpad.message}
c. Host FQDN: ${workflow.scratchpad.hostname}
d. PS Command: ${workflow.scratchpad.fqdn}
e. Click the Submit button to save your work.
12. Wire up your workflow to look like the following:
13. From the Core Activities tab, drag out a Condition -> If Activity onto the desktop.
14. Fill in the If Activity form with the following:
a. Name: Check for Error
b. Advanced: Checked
c. Script:
answer = ifScript();
function ifScript() {
if (JSUtil.nil(workflow.scratchpad.message.error)) {
return 'yes';
}
return 'no';
}
d. Click the Submit button to save your work.
This will be used to determine if any errors were encountered in the sub-workflow. If there were any errors, we will need to handle them.
15. Wire up your workflow to look like the following:
16. From the Core Activities tab, drag a Utility -> Run Script Activity onto the desktop.
17. Fill in the Run Script activity form with the following:
a. Name: Error Handler
b. Script:
var results = workflow.scratchpad.message;
for (var i=0; i < results.error.length; i++) {
gs.log('---> ' + i + ' - ERROR: ' + results.error[i], 'WF: Framework.Error Handler');
}
c. Click the Submit button to save your work.
This will be used to handle any errors that came from the sub-workflow.
18. Wire up your workflow to look like the following:
That's it: You have now completed construction of the framework workflow to call your sub-workflow! Now to test everything...
Testing for an Error
It is a best practice to exercise all of your code. This goes for workflows as well!
First, let's test a normal condition. Click on the Run Workflow button in the upper right corner of the desktop to display the Start Workflow form.
2. Accept the defaults and click the start button.
3. The workflow will begin executing. The context form will display and you will be able to watch the workflow progress by clicking on the refresh command in the upper right corner of the form. If your setup is correct, you should see a successful path.
4. Upon completion, close the context window.
5. From the ServiceNow browser tab, navigate to Orchestration > Definition > ECC Queue. Once the ECC Queue list view appears, sort by Created in descending order. You should see the same entries that were displayed in the sub-workflow testing we did in the last post.
6. Now, let's test the error handling. Click on the Run Workflow button, and this time enter "xyz" in the PowerShell Command field.
7. Click the start button.
8. Keep clicking on the refresh command to see the path.
9. You will notice that on the context form, the path is now diverted into our Error Handler Run Script Activity.
10. When the workflow has finished executing, navigate to Orchestration > Definition > ECC Queue from the ServiceNow browser tab. Once the ECC Queue list view appears, sort by Created in descending order.
11. Click on the entry "Windows — Powershell (nodes — 3)" with the Queue name of "input." The Queue — Powershell form will display. Click on the XML button and your error should look like this:
12. Close the form.
13. Navigate to System Log > System Log > All to display a list view of all log records for today and sort by Created in descending order.
14. Search the Message Field for: --->
15. You should see something similar to the list view below:
NOTE: We looped through all of the returned errors (even though the first one came back blank).
That's all there is to it... Congratulations you have written your first Framework to Orchestration Sub-Workflow project!
Learn More
You can review the code for this lab on ServiceNow Share here. Plus, if you're interested in learning more ServiceNow Orchestration best practices, I recommend reading Orchestration Best Practices.
Steven Bell
If you find this article helps you, don't forget to log in and "like" it!
Also, if you are not already, I would like to encourage you to become a member of our blog!
For a list of all of my articles: Community Code Snippets: Articles List to Date
