Friday, February 25, 2011

Changes to SPD Workflow not reflected in MOSS 2007

On more than one occasion, I and my team have faced a problem where my updates to SPD workflow were not getting applied, and older version of workflow kept running. This usually occurred where the workflow had become large with multiple steps, and manually recreating each and every step would have been painful.

To resolve, we had to:
1.     Create new workflow on the same list
2.     Add dummy if condition to generate xoml.rules file in the new workflow
3.     Copy paste the steps and rules from existing workflow to new workflow by opening the files in notepad
4.     Publish new workflow, Disassociate the existing workflows and Associate the new workflow
5.     Post validation that things are working as expected, rename existing workflow to Workflow_Corrupted or Workflow_Old to clearly identify the same in future.

The solution is also described in another blog here, difference being my preference to rename instead of delete the existing workflow. 

Like Samar, what I really want to know is the root cause of what causes the workflow to get corrupted?

My colleague Rajdeep Chakraborthy suggests it’s a Caching issue. It’s a hosted server, and we don’t have access to server to do IIS reset and immediately validate. I am ruling out XML Well Formedness as we are copy pasting existing xml and it works. Wondering what else can cause the issue?

Rajdeep found a simpler solution. Detaach existing workflfow, do required changes, and attach it again to the list.
“Go to List Settings > Workflow settings > Remove a workflow > Select Remove option from the radio button and click OK. Then open the workflow again from SharePoint designer, make some changes and click Finish, so it is associated again.
Your changes should now appear”
The problem is likely to occur if there are running instances of previous version of the workflow. I did not have any pause/delay activity and ideally, all my workflows should have run to completion.

Thursday, February 24, 2011

MOSS 2007 Excel Services SoapException - You do not have permissions to open this file on Excel Services

We were programmatically trying to read an Excel file, uploaded to a SharePoint 2007 Document library, by making a Web Service call to Excel Services.
And the code was giving System.Web.Services.Protocols.SoapException error with message “You do not have permissions to open this file on Excel Services”.
We initially thought that it’s a permissions issue, the context under which code is running does not have access to the Excel file. To verify, we opened the file in browser using Excel Services View in Browser option, and the excel file was rendered correctly. Permissions issue was ruled out.
On closer look at code and debugging, the bug was found in the code. We were referring to the wrong Excel Services URL. The URL gets hardcoded when you add the Web Service Reference in Visual Studio.  The error can occur when you move from one Development machine to another and URL changes, or refer the Excel Service of SSP.
To resolve the error, simply update the Url of the ExcelService object.
ExcelService exlObj = new ExcelService();
exlObj.Url = oweb.Site.Url + "/_vti_bin/excelservice.asmx";
exlObj.Credentials = System.Net.CredentialCache.DefaultCredentials;
Status[] status;
string sessionId = exlObj.OpenWorkbook(filePathUrl,"en-US", "en-US", out status);