Servienow is continuously increasing feature in Flow Designer from its London to Madrid release. Below are the changes and addition in brief to what is going to be new in Madrid.
SERVER-SIDE FLOW APIS
The London release had two APIs, startAsync for Flows and SubFlows. In Madrid, this has been increased to a core set of six calls.
- startAction(String name, Map inputs, Number timeout)
- startFlow(String name, Map inputs, Number timeout)
- startSubflow(String name, Map inputs, Number timeout)
All of these are asynchronous calls, the equivalent of the previously available calls but with the addition of being able to call a single Action. All of these require passing a Map object that will contain name-value pairs that would match the inputs that would be passed to that Action, Flow or Subflow in the same context as their execution by the Flow engine. When invoking yourself via script, it is the caller’s responsibility to verify all necessary inputs are provided in your script.
In addition, there is another set:
- executeAction(String name, Map inputs, Number timeout)
- executeFlow(String name, Map inputs, Number timeout)
- executeSubflow(String name, Map inputs, Number timeout)
These APIs are all synchronous and thus must be used with care. This can be valuable in a situation such as an integration where the invoking code may need a return value that will take time. The flip side is that any of these actions can theoretically take a very long time such as when asking for approvals or waiting for a set time. If it takes longer than the timeout limit, this may cause your client code to have execution cut short. Knowing that time of execution ranges will drive your choice of synchronous or asynchronous APIs.
More detail on these APIs is available at the Docs site and the Developer site.
CLIENT-SIDE GLIDEFLOW APIS
New in Madrid is the concept of client-side execution of server-side flows. It is an interesting notion and one that opens up a lot of logic and functionality.
These would be used on the client-side as GlideFlow. The invocation APIs are analogous the the above:
- startAction(String scopedName.actionName, Map inputs)
- startFlow(String scopedName.actionName, Map inputs)
- startSubflow(String scopedName.actionName, Map inputs)
All of these APIs return an execution object. That object has some APIs:
- execution.awaitCompletion()
- execution.getExecutionStatus()
- execution.getOutputs()
The awaitCompletion() call is a blocking API that will return a completion object, so it can be used to wait on the final output of the server-side execution. As above, it pays to know how long that might take but there will be different timeouts in play.
This could conceivably be used to show some sort of real-time status in a Service Portal widget or other interesting uses.
Again, more detail on these APIs is available at the Docs site and the Developer site.
Source: Dave Slusher’s blog- Servicenow™
https://developer.servicenow.com/blog.do?p=/post/new-for-developers-in-madrid-flow-apis/
ServiceNow 