SharePoint 2010 introduced a very nice feature that enables visual representation of workflow status on the workflow status page using Visio diagrams hosted in a Silverlight web part.
Recently I’ve created a simple declarative workflow in SharePoint Designer 2010 and configured it to display workflow visualization:
I then published and started the workflow and went to the workflow status page hoping that I would see the visual of the workflow status. Instead, all I saw was the error message “The server failed to process the request.”:
First I went to Central Administration>System Settings>Mange services on server and checked if the Visio Services were running:
So all fine there. Next step: go to Central Administration>Application Management>Service Application Association to check if the Visio Services was part of the Service Application Proxy associated with the affected web app:
No problem there either, so next I checked the ULS log to see if there are any errors. And indeed, this is the stack trace I found:
So it seems that the service account under which my Visio Services are running (CONTOSO\sp_serviceapp) couldn’t connect to my content database (WSS_Content_Team). I went to the SQL Server Management Studio and indeed, the CONTOSO\sp_serviceapp did not have permissions in my content database. So I went ahead and added the CONTOSO\sp_serviceapp to the dbo role in the content database:
Went back to my workflow status page and did Ctrl+F5 to reload, but still got the same error as before: “The server failed to process the request.”.
Back to the ULS log. This time a different exception popped up:
Huh? The error message implies that there is a potential compatibility problem with my database, which typically occurs when you attach a SharePoint 2007 database and attempt to use 2010 features in it before upgrading it to 2010. However, this was a brand new 2010 database, so this couldn’t be the case.
Then I remembered the golden rule: never touch SharePoint databases directly.
There’s always a better way. In my case I had given the dbo rights on the content DB to the service account directly, but that was obviously not enough to make it work. Looking for the solution, I stumbled upon this article and found and executed the following PowerShell snippet to provide the necessary DB access rights to the service account:
Went back to my workflow’s status page, did a refresh and voila:
You might need to restart the Visio Services from Central Administration and do an iisreset if it still doesn’t work.