Can't connect to the server using WorkFlowManagementServer

Reply

kotomi Posted: Mon, Jun 16 2008 3:37 AM

rated by 0 users

I am trying to connect to the server to get global worklists.

I've just tried the code from the K2 BP Developers Reference, but have been having just enough troubles getthing thorough connection problem.

The code looks like this below. I am not sure what went wrong and would really appreciate the help!
I am running the code on the server machine (K2 BP SP1), which is the vpc machine running Windows 2003 SP2.

string server = "mossvpc";
string host = "localhost";
string user = "admin1";   // example admin user name (admin in local mahine as well as K2)
string password = "admin1";
uint port = (uint) 5556;   // K2 Host server is set up to use 5556 port.

WorkflowManagementServer workflowServer = new WorkflowManagementServer(
    server, port, user, password, "K2", true);
workflowServer.Open();

When I run this code on ASP.NET form on the server, I get this error:
"Requested Authentication Provider not hosted
   at SourceCode.Workflow.Management.WorkflowManagementServer.Open()...."

Instead of using the server name, I changed to using the host name.
WorkflowManagementServer workflowServer = new WorkflowManagementServer(
    host, port, user, password, "K2", true);
workflowServer.Open();

And I still got the same error.

I also changed the port number from 5556 to 5252 (K2 server port).
Then I got this error:
"Error Receiving Buffer
   at SourceCode.Workflow.Management.WorkflowManagementServer.Open()..."

Console error for the above one showed:
Debug   8047 Connected to 172.17.1.8:1 Bytes From 8
Debug   8039 Receiving 172.17.1.8.:1
Error     8050 Received BAD Header From 172.17.1.8:1

While I can't connect to the workflow server from the code, Workspace works fine and displays all processes and runs reports without problems.

Why is it that I can't seem to get connection from the code?

Reply

blake replied on Mon, Jun 16 2008 7:24 AM

rated by 0 users

Hi Kotomi,

The latest example for accessing the global worklist in the current release of the documentation (803 release) uses the SCConnectionStringBuilder class in the SourceCode.HostClientAPI namespace to build the connection string.

You will need to add a reference to SourceCode.HostClientAPI.dll in your project.  The example is similar to the following.

SourceCode.Hosting.Client.BaseAPI.SCConnectionStringBuilder connectionString = new SourceCode.Hosting.Client.BaseAPI.SCConnectionStringBuilder();
connectionString.Authenticate = true;
connectionString.Host = "localhost";
connectionString.Integrated = true;
connectionString.IsPrimaryLogin = true;
connectionString.Port = 5555;
            
WorkflowManagementServer workflowServer = new WorkflowManagementServer();
workflowServer.CreateConnection();
workflowServer.Connection.Open(connectionString.ToString());

Give this a try. 

Blake

Reply

kotomi replied on Mon, Jun 16 2008 3:20 PM

rated by 0 users

Hi Blake,

Thanks heaps for a quick reply.
Yes, passing SCConnectionStringBruild works !

I was initially using another function to build connection string using SCConnectionStringBuilder, which simply returns the end-result string, then pass this string to the WorkFlowServer Open method.

Obviously, just passing any string didn't work at all.

Thanks again.

Note:
The codes which worked are as follows, just in case someone needs it.

-------------------------------------------------------
SCConnectionStringBuilder connString = new SCConnectionStringBuilder();
connString.Authenticate = true;
connString.Host = "localhost";
connString.Integrated = true;
connString.IsPrimaryLogin = true;
connString.Port = 5555 (or 5556 in  my case);
connString.UserID = "[admin user name]";
connString.Password = "[password]";

WorkflowManagementServer workflowServer = new WorkflowManagementServer();
workflowServer.Open(connString.ConnectionString);

-------------------------------------------------------

Reply

bsorensen replied on Wed, Mar 10 2010 10:27 AM

rated by 0 users

I think if you use Integrated = true that it will ignore UserID and Password (instead connecting with your current Windows credentials). You might want to test that (specify an invalid password).

EDIT: I was only half right. You must set connString.WindowsDomain as well (when specifying a UserID and Password) or it will use the logged on credentials to authenticate.