Brad Tilton

4 minute read

On this past week’s Live Coding Happy Hour show we continued to enhance our cooking management application, which manages and tracks long cooks like smoking meat for 18 hours. The scenario we were looking to solve was that we needed a way to use Siri to create a cook record and then create some additional records during the cook. We ended up creating a subflow, creating a scripted REST API that calls the subflow, and then calling that scripted REST API from an Apple Shortcut. In this blog, we’ll walk through that process in more detail, but here is the recording of the show if you’d like to watch it.

(I’m not sure why this is the thumbnail we ended up using. I blame Andrew…)

Create the Subflow

So what’s a subflow anyway? A subflow is a flow designer flow without a trigger that you can call from a flow or any client or server-side script area in ServiceNow. You create a set of inputs and outputs, add your actions and flow logic, and then assign values to the outputs. At this point in my flow designer journey, I pretty much always start whatever I’m doing in a subflow so that it can then be called from anywhere. This is similar to doing all of your scripting logic in a script include that can be called from any server-side code and maintained in one place.

On this episode, the first thing I did was create a subflow in my app’s scope, which in this case was cooking management. Once the flow was created I added inputs and outputs to my subflow. For inputs, I wanted to know from where this subflow was kicked off, and then I want to return the sys_id and number of the cook record we were creating.

2020-11-11-13-29-36.png

After that, I used Create Record actions to create a cook record, and then create an associated log record.

2020-11-11-13-32-59.png

Lastly, I used the Assign Flow Outputs flow logic to set the subflow outputs to the sys_id and number of the associated cook record. Andrew pointed something out at this point in the video after I had mentioned that it seemed strange to do this through an action rather than from the inputs and outputs section (like you might in the action designer). He pointed out that there could be multiple places in your subflow where you might need to set outputs if you’re using any sort of if/else or branching logic.

2020-11-11-13-37-26.png

Scripted REST API

After creating our subflow that performed the automation that we needed we created a Scripted REST API to call our subflow. This is the step that allowed our subflow to be called from an external source. We called the Scripted REST API Cook with an associated resource we called Create.

2020-11-11-13-41-03.png

We could have looked up the FlowAPI to write our code, but thankfully flow designer can generate it for us from the subflow.

2020-11-11-13-43-33.png

Then we pasted that into the script field and added some code at the beginning to populate the cook source as a subflow input.

(function process( /*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {

    try {
        var cookSource = request.pathParams.cook_source ? request.pathParams.cook_source : '';
        
        var inputs = {
            'source': cookSource
        };
        sn_fd.FlowAPI.getRunner().subflow('x_snc_cook_mgmt.create_cook').inBackground().withInputs(inputs).run();

    } catch (ex) {
        var message = ex.getMessage();
        gs.error(message);
    }

})(request, response);

We then tested that through the REST API Explorer.

2020-11-11-13-46-28.png

Apple Shortcuts

The last step was to setup an apple shortcut so that I could use Siri to kick off my subflow. That step is pretty straightforward as you can see from the screenshot below. I assume that Android has a comparable feature.

shortcuts.jpg

After all of that, it was just a matter of kicking off the shortcut and getting our record created.

Conclusion

There are of course a few different ways of creating a record in ServiceNow from an external source. I could have used Web Service Import Sets, the REST Table API, or written a script that creates the record directly in the Scripted REST API, but there are a number of advantages of the Scripted REST API + Subflow route we ended up taking. First, by doing all of our record creation logic in a flow we didn’t have to write any scripts for that part, made it easy to test (it’s very easy to test in flow designer), and made it easier to maintain since anyone who can use flow designer would have the skills to modify it. Most of the scripting we ended up doing was generated for us by Flow Designer. Also, by putting this record creation logic in a subflow I can call it from pretty much anywhere and maintain it in one place, the subflow.

Was this LCHH recap helpful to you and would you like to see more of these on the blog? If so, let me know in the comments or on LinkedIn or Twitter.


Comments