Introduction

There are certain scenarios where a running process will need to wait for input or a trigger from an external system or process. One can always create a polling mechanism in the process, but that adds unnecessary overhead and is not a real-time trigger; if the external call comes back a second after the polling mechanism checked for updates, the process will need to wait another full cycle before processing is initiated. Example scenarios include waiting for an external system to complete batched or nightly jobs, long running transactions potentially involving multiple line of business systems or even something simple as a human completing a task in an external system.

To cater for scenarios like these, the K2 platform has the concept of an asynchronous event, where pretty much any SmartObject call can be configured to wait for an external call before proceeding to the next step. The advantages of taking this approach are:

1. No overheads when compared to polling. The SmartObject call completes as per normal and simply waits instead of proceeding to the next step.
2. The process continues almost instantaneously when the callback is completed.
3. No degradation in service. A step waiting for a call-back is just a record in the database, nothing is kept in memory, no additional pings or hogging resources better used by actively running processes.

Use Case

There are a couple of moving parts that need to be set up and to keep things easy to follow, the topic will be covered in two posts. For the first post, I will create the core settings and SmartObjects needed for a typical scenario. In the second post, I will cover an actual use case, making use of the artifacts created in this post.

Architectural Overview

The following components play a part in a typical asynchronous process:

1. A K2 process is started where a step in the process makes a call to an external system. However, the external system needs to perform additional operations that can either take a long time. The step will send along its unique identifier, we refer to this as its serial number, which the external system will send back to identify the originating step.
2. The external system runs its operations and completes what’s needed.
3. The external system instructs K2 to complete the step by calling the Workflow REST API and passing along the serial number provided in step 1. Additional values can also be passed back using datafields if needed.
4. The built-in K2 Workflow REST API will complete the originating step, identified by the serial number and the process will continue to the next step.

Coverage of the K2 Workflow REST API is outside the scope of this post, it is documented in detail here:
K2 Workflow REST API

 For this topic, the expectation is that the end point has been configured.

Configure the Workflow step

1. Open an existing or create a new process where the asynchronous step is needed.
2. Configure the SmartObject step as per normal, ensuring that the external system can save a field that used for storing the unique identifier of the step that makes the call. In this example, it is a SmartObject call to a SQL Table. Configure the step and use the Serial Number Context Field for the property that will store the serial number:
   

   To ensure that the process waits for the external call to complete, expand the Options section at the bottom and check the Wait for external system checkbox:
   

3. The SN column in the example table above is what the external system will need to use when making the call back to K2. Once the process has started, a sample row in the SQL table can look like the following:
   
   And here is the process, waiting at the SmartObject step:
   

4. Once the batch processing has been completed, the system can then use the 5_31 value and call the Workflow Rest Endpoint.
5. Looking at the swagger for the Workflow REST service, one of the Operation Set categories are Server Events, which has a POST operation called Finish Server Event:
   

    

6. To simplify this post, I will use this form to make the call. You will typically need to call the REST end point using the available options from the external system. I’ll provide the serialNumber and an empty array value for the userDefinedFields and click the Try it out! Button:
   
   
   Here is the expected 204 response code:
   
   
   Subsequently the process has also completed:
   

And that’s all that necessary to get a process to wait for external responses. In the next installment, I will take this a little further where we can get use a K2 Smartform to perform this task for us.