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 10, 2015 ON THE CLOUDSHERPAS SERVICENOW SCRIPTING 101 BLOG.
____________________________________________________________________________
If you're using ServiceNow Orchestration, I recommend introducing sub-workflows to "build upon" existing functionality and reduce workflow complexity. Of course this recommendation often leads to some questions. In fact, the question I'm asked most frequently in Orchestration classes and beyond is: What is the best practice for calling a sub-workflow from a workflow in ServiceNow?
To answer these questions, I created a set of labs that you can use to learn about this with your Developer Instance and your local device (laptop or desktop). Part one will describe how to set up your own local MID Server and create the sub-workflow, and part two will review how to create the framework that will drive the sub-workflow.
Prerequisites
For this lab to be effective, you will need:
1. Familiarity with the ServiceNow Workflow Editor and ServiceNow Scripting
2. Your own Personal Developer Instance of ServiceNow
https://community.servicenow.com/community?id=community_blog&sys_id=a2bc2e25dbd0dbc01dcaf3231f9619e0
3. The Orchestration Plugin installed on your Personal Instance
https://community.servicenow.com/community?id=community_blog&sys_id=919c2ee1dbd0dbc01dcaf3231f961930
4. A new Update Set to contain your changes set to current
All set? Let's get started then!
Lab 1.1: Set up a Local MID Server
To start, you need to set up a local MID Server. For a step-by-step guide on how to do this, click here. For this lab, you'll need to configure the MID Server as follows:
1. Select tabbed forms (Eureka, Fuji, Geneva)
2. Navigate to Orchestration > MID Server Properties
3. The default MID Server field should be filled in with your MID Server's name
4. Navigate to Orchestration > MID Servers
5. You should see a list of MID Servers pointed at your instance
6. Click on the MID Server name link of the default MID Server from step 4
7. The MID Server detail form will appear
a. Click on the Configuration Parameters Tab. If the mid.use_powershell parameter is not present, you will need to add it.
NOTE: Since you will be working with your own MID Server, you won't need to set up Credentials. Since there is only one MID Server in use, you also won't need to set up capabilities.
Now that we have our environment set up, let's get to work!
Lab 1.2: The Sub-Workflow
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: Powershell Sub-Workflow
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
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
8. Wire up your workflow to look like the following diagram:
9. Drag the Resolve DNS Name activity out of the Core Activities > Orchestration tab. This activity takes a fully qualified domain name (like xyz.servicenow.com) and returns the IP representing that name (note that IPs are the desired host designation when working in Orchestration).
10. Fill in the form as follows:
a. Name: Resolve FQDN to IP
b. FQDN: ${workflow.scratchpad.hostname}
c. Click the update button to save
11. Wire up your workflow to look like the following diagram:
12. Drag out a Run Powershell activity from Core Activities > Orchestration — PowerShell
13. Fill in the form as follows:
a. Name: Get OS Details
b. Hostname: ${workflow.scratchpad.resolved_ip}
c. Command: ${workflow.scratchpad.command}
d. Script:
var results = {output : '', error : ''};
results.output = output;
results.error = error;
gs.log('---> ' + results.output, 'WF:PowerShell Sub-Workflow.Get OS Details');
workflow.scratchpad.output = results;
e. NOTE: The workflow.scratchpad.resolved_ip variable is auto-populated by a successful Resolve DNS Name activity
f. Click the update button to save
14. Wire up your workflow to look like the following diagram:
15. Drag out another Run Script Activity. You can use this to manage any errors returned from the Resolve DNS Activity.
16. Fill the the form as follows:
a. Name: Handle Error
b. Script:
var results = {output : '', error : ''};
results.error = 'Failed to properly resolved DNS for: ' + workflow.scratchpad.hostname;
workflow.scratchpad.output = results;
c. Click the update button to save
17. Wire up your workflow to look like the following diagram:
18. Drag a Return Value Activity out of the Core Activities > Utilities. This activity will return information back to a calling Workflow.
19. Fill in the form as follows:
a. Name: Handle Return
b. Value: ${workflow.scratchpad.output}
c. Click on the update button to save
20. Wire up your workflow to look like the following diagram:
Testing
Still with me? Good! Now it's time to test the workflow…
1. 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.
6. Click on the entry "Windows — Powershell (nodes — 3)" with the Queue name of "input." The Queue — Powershell form will display and should look like this:
7. Close the form
8. 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
9. Search the Message Field for: --->
10. You should see something similar to the list view below:
That completes the testing: You now have a working sub-workflow!
What's Next?
In part two of this post, I'll review how to call this sub-workflow from another workflow and how to interpret the results.
In the meantime, I recommend reviewing these Orchestration best practices. You can also check out the code for this lab on ServiceNow Share.
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
