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.

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.

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.

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?

Thanks

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

tbyrn777,

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

Examples:

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.

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

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.

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.