7 minute read
Flow Designer is a great tool to create business logic, particularly by those outside of traditional development roles: process owners, subject matter experts and the like. However, it is almost certain that sooner or later they will want to create Flows that require Actions that do not exist in the baseline system nor easily available Spokes. So then what? My suggestion is that this is where the traditional developers should step in, by creating Actions for use by those business users who don’t want to get deep in the implementation details. It is pretty straightforward to create an Action, so let’s walk through the steps.
For our example in the blog, let’s say that a Flow author needs an Action to take in the ID of a YouTube live broadcast and return the chat messages. They don’t want to know about the details of what that takes but just to get the information. This is a perfect type of thing for a Flow author to request, and an nicely bundled bit of functionality to wrap into an Action.
Note for the purpose of this post, I am not going to discuss the authentication piece. It needs to exist but adds a lot of complexity to the post. In the near future there will be a post all about Connections and Credential Aliases and how they interact with OAuth but not today. For this example, take it as a given that it is there.
Step 1 - Create the Action
Before anything else happens, the Action must be created via the “New Action” button. This will open the initial dialog in which the Action is named and description plus annotation are filled in. Like Flows, this is one aspect of the ServiceNow interface where the scope can be chosen independently of the scope selected in the system. After submitting, you’ll now have a newly created empty Action.
Step 2 - Define Inputs and Outputs
Our interface is pretty simple and easy to understand. We will pass in the ID of the YouTube Broadcast and expect to receive back a block of text that will contain all chat messages. We will set up the input and outputs first, although the output will remain empty until the very end when we actually populate the value.
Click the “Create Input” button in order to show the dialog to enter inputs.
Note: If your browser window is narrow and you have the side data panel showing, it might be sitting behind that panel.
In this case, we have a single input we are passing in and it is mandatory. If you had multiples, you would define them all here and mark them mandatory or not as necessary. Next, we’ll create the Output by clicking the “Create Output” button. Each time you click that button you create a new set so if you have multiple outputs, you would create multiples here. For now we will name it but leave the value blank. Later on we will populate the value from the Data Pill Picker.
Step 3 - Build the Action from Steps
With the setup done, now it is time to build some functionality. Because of the YouTube APIs, we can’t go directly from the Broadcast ID to the chats. First we need to look at the Broadcast resource which will contain the LiveChat ID needed to pull down the chat messages. This implies that we will need a few steps to request and extract that ID first.
By clicking the plus button, we can add a step. First we’ll add a REST step to get that liveChatId. We’ll take the ID passed in as input to the Action and pass it to the YouTube API along with an extra parameter common to Google APIs where you specify information you want returned. This REST call will return a JSON packet with information about the live broadcast. The one part we want is the ID for the chat.
After the step to do the REST call, we’ll add a script step with one job - to take that JSON packet and extract our one piece of information. The input to this step will be the response body of the previous step, which will be converted to a JSON object then our info dereferenced. The output of this step is that piece we want, the liveChatId.
Next we’ll repeat the process with a similar REST call but to the live chat API. The input to this step is the liveChatID from before. The call returns a JSON object with the chat messages and information about the authors of each message. We again follow this with a Script Step to act on the JSON object.
This time we have a little more complex situation. The JSON response contains an array of the chat messages with metadata about each message. In this step, we will loop over that array and for each item concatenate a line that is the author and the actual message. By the time this is done, we’ll have a string variable containing the full text of all the messages associated with the broadcast. That will be the output of this step.
Step 4 - Return the Output
Now that we’ve done the processing, we have information to return. The Action as a whole has a return value that we left blank before. Now, with the results of the final step in our action we have a value to populate that output value. Using the Data Pill Picker we put the chat message from the last step into the value field. This will make the Action as a whole return that bundle of the messages, which was the goal all along.
Step 5 - Review What Was Done
Looking back over what has been done so far, we see the power and the use case of custom Actions. The end user has a desire to receive the text of the chat messages with as little configuration as possible. Doing this from the id of a live event on YouTube has multiple steps of calling APIs and looking up values, but the end user does not care or want to know about these details. That is for use the developer of the Action. Chaining these REST API calls and script steps allowed all that to happen with the end result being the desired bundle of chat messages.
Step 6 - Test it Out
In order to test the newly created Action, I created a Flow that contained only that one Action and a simple scheduled trigger. If I had a record that contained a YouTube ID, I could have used that as the trigger. In this case, I created my own live event on YouTube and passed that ID directly to the action in my test Flow.
By executing the test, I called the Action with my hard coded input value. Lo and behold, it did what was expected! The first step correctly called the liveBroadcasts API, the second step pulled out the liveChatId. The third step correctly called the liveChat/messages API and the fourth step looped over the array of messages and assembled them into one big string. Success!
Action in Review
You can see from this example the power of this technique in building Actions. Although there are a number of implementation details, none of them are pertinent to the Flow creators. The developer of the Action has handled those details and provided a simple-to-use bundle of functionality.
One of the low-level concerns I hear from developers relates to the emphasis of low-code and no-code tools in the ServiceNow platform. If you worry for your future as a developer, fear not. You see that even low-code tools still have a lot of room for development. It’s just that you can now work at a different layer in the stack. Think of the role as that of creation custom Lego bricks. Your job is not so much to build the big structures, it is to provide those odd shaped bricks that don’t come in the standard packs. Developers still get to create interesting Actions, and then they deliver them to the business owners to hook together in the Flows they desire. In the long run, everyone is doing work most appropriate to their place in the chain.
This is the part of Flow Designer I most want to spend time with in the coming months. There are a number of pieces I want to control with IntegrationHub but require Actions that do not currently exist. By building some of those actions and the posting them to Share I get to help my own needs but also those of the greater developer community and the ServiceNow ecosystem. What could be better than that?
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email