Symptoms
The following error is being thrown while accessing the Workflow Management Web Service hosted by K2 Host Server via custom code/broker:
"Error","Communication","8060","ProcessPacketError","SourceCode.Hosting.Server.Services.TCPClientSocket.ProcessMessage","8060 ProcessPacket Error, Authentication With Server Failed : User's Domain is not in list of valid Domains."
When connecting to the same web Web Service locally, it works fine, but when connecting over a proxy service hosted on another server following error is being thrown.
Problem appeared in previously working environment after upgrading of K2 platform.
Diagnoses
The fact that error appeared after upgrade of K2 platform and your previously working custom code/broker does not work may be interpreted that some breaking changes were introduced from K2 side which prevent your previously working code to work correctly.
In practice K2 rarely introduce breaking changes in its APIs and when it happens this is stated in documentation/release notes. For example if we take code related with authentication/error mentioned above there was not any changes in the way K2 handles this code starting from 4.6 RTM all the way up to 4.6.11.
There are different things you have to check in case you getting problems with previously working code. First you have to confirm that upgrade process was completed correctly and there is no issues with infrastructure.
Specifically for error mentioned above you and when you use proxy server you have proper version of assemblies everywhere (proxy server not exclusion) and your code uses assemblies from GAC and not from local directory.
To describe one specific case of investigation of error mentioned above it went as follows:
After investigating different possibilities for infrastructure misconfiguration and breaking changes introduced in K2 4.6.11 it was possible to establish that this issue was caused by mismatched versions of K2 interoperation assemblies. In this specific case in affected environment SourceCode.HostClientApi.dll on proxy server was from a really old version of K2 Host Server, and it behaved differently with a newer K2 Host Server.
To establish this it was necessary to use debug utility which worked fine on local developer's machine but was causing failures on proxy-server. After establishing this it was possible to add some debug calls in problematic custom code/broker to trace which dependent K2 assemblies were resolved and establish that on development machine it resolved GAC assemblies, and on proxy-server it was using locally-resolved files from current directory. It has been done by adding the following code:
private static void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
if (args.LoadedAssembly.FullName.Contains("SourceCode"))
Console.WriteLine("Loading {0}
from {1}", args.LoadedAssembly.FullName, args.LoadedAssembly.Location)
}
And output allowed to pin point mismatched versions of K2 interoperation assemblies.
Resolution
Verify that upgrade completed correctly and make sure that you do not have any lingering old K2 assemblies stored anywhere and possibly used by your code. See details in Diagnosis section.
