Hi Shawn.

The legacy .NET API will still work if you are upgrading from 4.7 to K2 Five. 

The REST documentation is available here.

The OData documentation is available here.

Installed and Supported:

4.7 Upgrade to K2 Five:

• Client API (.net)
• SOAP Workflow API
• SmartObject Services (legacy)
• REST Workflow API
• OData API
• ADO.Net Provider
• ADO.net Queries

K2 Five and K2 Cloud (new / clean install):

• REST Workflow API
• OData API
• ADO.net Queries

Will it work with v5 workflows/worklists or only v4?

You'd integrate with K2 Five workflows with REST. If you get me more specifics, I'll make sure we get you what you need.

We have built WCF services utilizing the client and management .NET APIs to display/manipulate worklists, worklist items and workflows. We have a custom smartform driven workspace that uses smartobjects utilizing those WCF services to provide the worklist/workflow functionality. The concern is that moving to K2 five we need a way to a) maintain the custom worklist and b) ensure that it can function with both v4 and v5 workflows. The best path forward for us is going to be maintaining our existing v4 workflows and slowly converting them while at the same time developing new workflows in v5. This is going to be very difficult if we have to use two different APIs to mix the two into a single custom workspace. If the only way to do this is to use the built-in K2 workspace, it's a complete non-starter for us. Our users find it overly complicated and confusing compared to the custom workspace.

If you upgrade, you can continue to use the existing APIs. It's up to you to determine what's best for you in moving to the new REST API.

1. Yes, you can use the existing client and managemnt API in K2 5.0 if you upgrade from 4.7 to 5.

2. The Workflow REST services are not necessarily enabled by default in a new K2 installation.
You may need to edit the web.config file located on your K2 server (default location is noted
below)
C:Program Files (x86)K2 blackpearlWebServicesK2Servicesweb.config
to enable the Workflow REST services

What disturbs me is that you are calling all of this functionality legacy.  There are features you just introduced in 4.7 that are now not supported in K2 Five.  Your company is very agressive in what you support.  How soon will you remove the legacy support from K2 Five?

This feels like we are beta testing your software for you and K2 Five is a incomplete release.

Hi webarchitect.

I'm sorry if we've made it confusing. There are no intentions of removing support. We have thousands of customers that rely on it. You're solid.

K2 Five is a full release. It's really good and I hope you'll spend some time with the product. 

Josh

I have found that NOT EVERYTHING works with the .net API when moving from 4.7 to 5.  

We have an extensive set of services that our applications use that are built on top of the .net APIs and I am finding things that do not work in 5, when they did work in 4.7 and below.  So, just beware.

The problems that I am seeing so far are when passing filters into method calls when specifying a column name.

Example:

This works on 4.7 and below.  On 5, it returns an error: "Invalid column name 'PI.ID'"

internal virtual ProcessInstance GetProcessInstance(GetProcessInstanceModel model, WorkflowManagementServer server)
{
    // create a filter for the procInstID
    var procInstIDFilter = new RegularFilter
    {
        ColumnName = "PI.ID",
        ParameterName = "@ICE_ProcInstID",
        ParameterValue = model.ProcessInstanceID,
        DbType = DbType.Int32,
        Comparison = Comparison.Equals
    };

    var filter = new ProcessInstanceCriteriaFilter();
    filter.AddRegularFilter(procInstIDFilter);

    var processInstances = server.GetProcessInstancesAll(filter);
    var processInstance = processInstances.Cast<ProcessInstance>().SingleOrDefault();

    return processInstance;
}

We're ultimately looking to rewrite our services to utilize the K2 REST web services and exposed smart object services.

-M.Ob

We've looked at the REST services but they are quite limited compared to the .NET API. I've since upgraded one of our test servers to K2 Five and everything we're using the API for works fine with both legacy and new workflows. The only issue we've found with cross-compatibility is K2 Five workflows don't expose Activities on the front end. On the back end they still exist and are just named "Task 1", "Task 2", etc. We've worked around that by switching from using Activity names to Event names in API calls and making sure Activity and Client/Server Event names match in our legacy workflows.
Edit: the Activity Name issue seems to be fixed in recent Fix Packs.

Our PROD customers are currently on 4.7. We have a K2 Five development environment set up where we've successfully converted workflows, and verified that our custom SmartForms Worklist and Process Management Portals work correctly in K2 5.1 .... for now. These custom Smarforms portals consume our custom WCF web services that in turn reference several K2.NET Assemblies.

We are concerned about the eventual deprecation of these K2 .NET Assemblies.  We've been told by K2:

"The management SmartObjects will be available through REST as soon as the new SmartObject REST endpoints are made available. Features that were not exposed in the new management portal are either deprecated features that we won’t build new interfaces for or are legacy features that are still on the backlog to be ported over and at that stage receive new interfaces. ".

Problem: The new K2 Five new Management Portal does not contain key functionality that was offered within the K2 Blackpearl Workspace (and that we also offered within our Custom SmartForms using the K2 .NET API Assemblies).

Some of these key functions are listed below, and are not offered in the K2 Five Management Portal (the listed functions below reference various K2 .NET Assemblies; i.e.: SouceCode.Workflow.Management.WorkflowManagementServer, SourceCode.Workflow.Client.WorklistItem, SourceCode.Security.UserRoleManager.Management.UserRoleManager: Method: GetRoles(), and several others.

• Allow Process Managers (not necessarily AD Supervisors), to view who (i.e. which individual Role Member or user) has Task items opened (both RoleUser based tasks)
• Allow Role Members to view which individual Role member has Role Based task items opened
• Allow Active Directory configured supervisors to view/action subordinate worklist items
• List all Workflow Roles of which operator is a member; This in turn allows Process Manager operators to select Role Members when redirecting tasks to individual Role Members
• Allow Process Managers (not K2 Admins, not role members, and not necessarily AD Supervisors), to redirect
  elease individual Role Member tasks. Note: Role assigned redirected items should continue to be Role assigned; not User assigned  (so that both Process Managers and Role members can view who has it opened). The new Tasks/actions/redirect REST API, ..does not do this. It instead creates a new individual User assigned task; such that no other role members can determine which individual Role member has the task opened. This does not work for our customers.
• Action tasks on behalf of users (using SourceCode.Workflow.Client.WorklistItem ImpersonateUser()
• Retrieve Process Instance Data for display alongside worklist instance data

We are looking for assurances from K2 that our PROD custom smartform solutions continue have a migration path that allows them continued execution success and support.

K2's response here:

"The management SmartObjects will be available through REST as soon as the new SmartObject REST endpoints are made available. Features that were not exposed in the new management portal are either deprecated features that we won’t build new interfaces for...."

... is not sufficient in assuring the continuation of required functionality for our PROD customers.