K2 5.1 REST API integration

  • 31 July 2018
  • 9 replies

Badge +5

I reviewed most of the  forum threads around migrating from K2 4.7 to 5.1 on-premises but I am not clear on what the recommended replacement is for the K2 context we currently use in K2 for Visual Studio. In other words, our K2 4.7 environment uses ASP.NET interfaces along with K2 DLLs (e.g. SourceCode.*.dll) to build our deployment packages.


Since K2 for Visual Studio is deprecated, we would need to move all the custom code into REST API endpoints and integrate with the K2 engine.  But when I look at the Workflow REST API documentation, I see high level API endpoints around Task and Worklist management. Where can I find the REST API for the following


  1. K2 String Table (read)
  2. K2 Process Instance XML data (read & write)
  3. K2.ProcessInstance.Originator.Email (object)
  4. K2.ActivityInstanceDestination.Activity.Name
  5. K2.ActivityInstanceDestination.User

Sample code in our current DLLs that uses this is below


So how can we migrate our custom code from K2 for Visual Studio into the new designers in K2 5.1 and use REST API integration?


Any help would be appreciated. Thanks.


Private Function GetDestinationsEmailIDs(ByVal K2 As Object) As String

        For Each oDest As SourceCode.KO.Destination In K2.ActivityInstanceDestination.Destinations


      ElseIf oDest.Type = SourceCode.KO.DestinationType.Queue Then   ' this is a Role (that can be a set of user and/or group)

                strEmail &= GetK2RoleUsers(oDest.Name) & ";"

9 replies

Userlevel 4
Badge +12

My understanding for this issue at the moment (and how I have been moving forward with my development) is that you should still use the K2 API dlls as references in custom services of your choice (REST, WCF, etc.) to integrate with K2 functions that aren't yet available in the REST services. It seems like every update to K2 is adding more functionality to the built-in REST services, but they don't match the power of the original API dlls just yet.

Badge +5

I am not sure I understand, could you please elaborate? 


And would this approach require K2 for Visual Studio? If so, that's a problem because that is no longer supported past 12/31/2019.


Userlevel 4
Badge +12

I'm suggesting that whatever you are currently using the "K2 Context" for in your workflow processes, you would instead move to custom web services (which seems to be the path you are taking). You can then migrate away from using Visual Studio as your workflow designer.

Then, in your custom web services, you would still reference those sourcecode.* DLL files to get the K2 context functionality that you are looking for. If a REST service exists that provides the functionality you want, use it as over time I believe these services will be expanded and you can slowly move away from dependency on the sourcecode.* DLL files.


Badge +5

Understood, thanks.


One more followup question: Would I have to rebuild the process itself ("boxes and arrows") from scratch using the new browser-based designer in K2 5.1 or does the 4.7 to 5.1 upgrade wizard automatically convert the process to a format that the new designer can import?



Userlevel 4
Badge +12

You'll have to rebuild the processes unfortunately... there isn't an upgrade option that migrates the VS processes to the web designer.

Badge +12


What's the proper way to use these in the 5.1 external API calling .NET DLL? 



Client Destinatoin - need to run custom code based on each destination user, or add destination based on other logic.


In 4.7 we could pass these context to DLL:

Client Event - SourceCode.KO.ClientEventContext

Server Event - SourceCode.KO.ServerEventContext

Escalation Event - EscalationRuleContext where we can set K2.SetEscalationRule(dteEscalation)  based on custom logic.

Userlevel 4
Badge +12

Depending on what you are tying to accomplish, you would reference the SourceCode.Workflow.Client or SourceCode.Workflow.Management dlls. Between the two of them you should have a hook into any K2 function that would be needed. If you can clarify what your custom code was trying to accomplish I may be able to offer more guidance

Badge +12

Use Escalation Event as example:

In 4.7 when it fires, it runs the custom DLL code in Escalation Event.

EscalationRuleContext is passed to the DLL sets a new escalation date K2.SetEscalationRule(dteEscalation).

After the DLL function returns to K2, Escalation event ends.


In 5.1 this is done out of process.

When escalation event fires K2-5 calls external API synchronously w/a procssinstid?

External API uses Mgmt DLL to open processinstid?


External API needs to know the information for that specific instanceID/Serial# (in case of parallel routes):

ClientEventContext - obtain or assign the destinations

ServerEventContexxt - obtain/set activity's data field.

Userlevel 4
Badge +12

Ah, I see - the escalation scenario is not what I was considering. I'm sorry, I don't have a K2 Five instance in front of me at the moment so I'm not sure how to get an escalation event to call a SmartObject. If it is possible to have to have an escalation event call a SmartObject, I'd pass in as much context as I can to the SmartObject which would in turn pass it to your custom web service to process.