This is a reposting of an article Patrick Roth originally wrote on my Developing for Dynamics GP blog.
Recently one of the support engineers had a case they asked for my help on.
Dynamics Workflow was installed and a new PO Workflow was created and activated in Sharepoint. From the Sharepoint side, everything seemed to be working correctly.
In the Dynamics Workflow Setup window, after marking the checkbox to activate workflow for the company and hitting the OK button, Dynamics returns the error:
Unable to access workflow services. Contact your system administrator.
Permissions on the Sharepoint server were checked as well as various install settings, and everything turned up correct. But yet from the Dynamics side, Workflow couldn’t be activated.
The Dynamics GP Workflow Setup window doesn’t actually contact Sharepoint using the Dynamics Workflow Web Service methods directly. Instead the Microsoft.Dynamics.GP.Workflow.Client.dll uses Visual Studio Tools to handle the calls to the Workflow web service from the Microsoft.Dynamics.Workflow.Proxy.dll and then sets values on hidden fields that Dexterity reads.
Thinking perhaps the method call was failing and the exception silently swallowed, I wrote a small .NET winform to call the IsWorkflowEnabled method for each workflow type which would then enable the corresponding checkbox for each enabled workflow (that’s a mouthful!). The thought was that my application call would fail and we’d see the unhandled exception being thrown to give us a clue on the real issue.
The customer ran the application on their system for the company and it ran successfully without error. It also successfully marked the PO Workflow as being enabled so we knew for sure that everything was running normally.
Interesting – calling the web service directly works correctly. So what gives?
Sample C# code calling IsWorkflowEnabled for 2 workflow types
// Create an instance of the web service
DynamicsWorkflow wsWorkflow = new DynamicsWorkflow();
// Specify the URL used to access the Workflow web service
wsWorkflow.Url = WFURL.Text;
// Be sure that default credentials are being used
wsWorkflow.UseDefaultCredentials = true;
// Create the company key for the selected company
companyKey = new CompanyKey();
companyKey.Id = Convert.ToInt16(CompanyID.Text);
// Is the workflow enabled?
workflowKey = new WorkflowAssociationKey();
workflowKey.OrganizationKey = companyKey;
workflowKey.WorkflowName = "Dynamics GP Purchase Order Approval Workflow";
isEnabled = wsWorkflow.IsWorkflowEnabled(workflowKey);
this.checkBox2.Checked = isEnabled;
workflowKey.WorkflowName = "Dynamics GP Sales Quote Approval Workflow";
isEnabled = wsWorkflow.IsWorkflowEnabled(workflowKey);
this.checkBox3.Checked = isEnabled;
When the IsWorkflowEnabled method is called, Dynamics assumes the call will fail and marks a variable for the current call as “failed”. After the Microsoft.Dynamics.GP.Client.dll makes the web service call, if there is no exception the current call is marked as “successful” and the next workflow type is checked. If an exception is thrown, Dynamics will then not make any more web service calls and the error message “Unable to access workflow services. Contact your system administrator.” is thrown.
How can it be that Dynamics fails and my app runs OK?
Looking at the Dynamics GP source code, the only thing I could see is that there never was a web service call made. To prove that for sure, the next step would have been to use a tool such as fiddler to capture the client outgoing http calls. Or a script.log would also possibly show that the VSTools method was run which was calling the web service.
But given that my application runs and the only way to fall into the “else” clause that gives the message above, the only thing that makes sense is that the web service call was never made.
How could that be?
To invoke the web service methods for workflow, Dynamics GP uses ‘run script’ on various fields on the ‘Main Menu’ form. The Microsoft.Dynamics.GP.Client.dll has focus notifications on those fields and invokes the proper web service calls in response and sets the return data back into different window fields which the Dexterity then reads.
The only conclusion that I could come up with that fits is that the web service calls weren’t being made by the client assembly. And the only way that could happen is if the Microsoft.Dynamics.GP.Client.dll was disabled. This could be done by not having the client assembly in your GP folder but then you get errors launching Dynamics and the customer didn’t mention that they were getting errors. The 2nd way is if in the Customization Status window (or from the Support Debugging Tool) the Customization Status for Microsoft Dynamics GP was set to “Disabled”.
The suggestion was that the partner check to make sure that indeed the Customization Status for Microsoft Dynamics GP was set to “Enabled” and let us know the results.
Was that the issue? Well unfortunately we don’t know that for sure. After repeated failed attempts to contact the partner to verify that this was the issue, the support engineer closed the case. But I’m pretty sure that this was the issue as I can’t see any other conclusion given the facts we saw. One other note, the support engineer was familiar with the partner and their habits. If the solution offered for an issue didn’t solve it, the partner was quick to reply “Now what do we try?”, but if the case was solved, the partner tended not to respond back. Certainly not proof positive but sounds likely this was the resolution.
// Copyright © Microsoft Corporation. All Rights Reserved.
// This code released under the terms of the
// Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.)
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.