Wait for external system timeout

Hello,

I believe the 'wait for external system' will put your workflow into an Active state, as it wait for your external system to tell K2 that it is finished with what it is doing.  I believe it will stay Active on that SmartObject call indefinitely, unless the external system calls back into K2 to tell it at is is done.

Completing the wait for external system/server event can usually be done through the WORKFLOW REST endpoint:

https://[K2 SERVER URI]/api/workflow/[version]/serverEvents/" + stepSerialNumber + "/finish

Or through Workflow Client API:

private void FinishK2StepbyAPI(string stepSerialNumber, string appResponse, string host) {
    using(SourceCode.Workflow.Client.Connection K2Conn = new Connection()) {
        try {
            K2Conn.Open(host);

            // Use the ServerItem object to open the SmartObject step that is waiting in the workflow. Do this by passing in the step serial number.
            ServerItem svrItem = K2Conn.OpenServerItem(stepSerialNumber);

            // Pass datafield values back to K2, if necessary. In this example, we're passing back a response from this external application of "Success" or "Fail"
            // through a datafield called "ExternalAppResponse", which corresponds to a variable defined in the running instance of the K2 workflow.
            svrItem.ProcessInstance.DataFields["ExternalAppResponse"].Value = appResponse;

            // Finish the server item to tell the workflow to continue
            svrItem.Finish();
        } catch(Exception ex) {
            // Handle errors accordingly.
        }
    }
}

https://help.nintex.com/en-US/k2five/userguide/current/default.htm#How-Tos/WaitExternal/Wait-External-System.htm

Are you asking what would happen if your external system call times out, and never get around to calling back into K2 to complete the server event/wait for external event?  If so, I think the workflow will stay in an Active state indefinitely until a call is made into K2 to complete that event.

Hi Laszlo,

I encountered a similar issue. My workaround involved a split before the external call, one path to the call, one path to a timer (set to a suitable timeout), then back through a merge that continues on first path to complete. This way the external call completes or the timer elapses either way the workflow will continue.

Sean