locked
Error when calling Sharepoint 2010 workflow from Sharepoint 2013 workflow RRS feed

  • Question

  • Hi,

    We are upgrading all our old sharepoint infopath forms and workflows to 2013. Some of our workflows have the impersonation step so we can change list item permissions when our infopath forms are submitted.

    Microsoft have gone and depreciated this list permission changing functionality (would love to know why) in 2013. To work around this you need to call a Sharepoint 2010 List workflow from the 2013 workflow.

    This is all setup and works great when the author of the workflows runs these work flows. However when the 2010 workflow is run for any user other than the author of the workflows it fails.

    The error is below:

    RequestorId: 5145b770-177f-48cd-b11e-723ae64e4b27. Details: System.ApplicationException: HTTP 401 {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPClientServiceRequestDuration":["10"],"SPRequestGuid":["5145b770-177f-48cd-b11e-723ae64e4b27"],"request-id":["5145b770-177f-48cd-b11e-723ae64e4b27"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":["15.0.0.4420"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Mon, 02 Sep 2013 04:37:06 GMT"],"Server":["Microsoft-IIS\/7.5"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]}   at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context)   at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)   at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem

    This specific error was hard to search on because it doesn't give any details as to the actual causae. I have read a number of blogs on this. The users exists within sharepoint and the user profile service is running. I've even tried giving the users full control to the list but always the same error.

    Does anyone know how we can fix this issue.

    Thanks in advance.

    Simon.

    Monday, September 2, 2013 5:05 AM

Answers

  • Hi Linda,

    I have done some more investigation and found that appears to be the source of the issue.

    Our plan in terms of security is to create all our security groups in active directly so security can be managed here. We then create groups in SharePoint which we add these AD groups too. Therefore the sharepoint groups manage permissions however AD manages who belongs to those groups.

    This seems to work find for access to the lists, sites etc. However this is the cause of the problems.

    If a user is in one of these AD groups and has the correct access they can submit browser based InfoPath forms without issue. However when the interop bridge workflow runs it fails.

    If we then add the actual AD user account to the sharepoint group and repeat the process the workflow works exactly how is expected.

    Unfortunately it doesn't end there. I have two groups Site Members and Site Visitors. Both have contribute to the list that has the form. If the person is added to Members the workflow works. If the person is added to Visitors it doesn't work (same error as mentioned in previous post). Both the groups are exactly the same permission wise.

    Seems to me that in addition to the user needed to be in the group there is a problem with access rights being synced within the application.

    Thanks.

    Simon.

    • Marked as answer by Lindali Monday, September 9, 2013 9:21 AM
    Friday, September 6, 2013 3:26 AM

All replies

  • Hi,

    Base on the description, you get error when calling SharePoint 2010 workflow which is run for any user other than the author of the workflows from SharePoint 2013 workflow.

    The “Impersonation Step” is deprecated in SharePoint 2013. The SharePoint 2013 workflow infrastructure is built on Windows Workflow Foundation (WF) 4 and therefore executes workflows in Windows Azure. For this reason, some actions from SharePoint 2010 workflows are available in SharePoint 2013 only when using the SharePoint workflow Interop Bridge. SharePoint workflow Interop enables SharePoint 2010 workflows to be called from SharePoint 2013 workflows, this allows you to execute 2010 workflows within 2013 workflows. More information: http://msdn.microsoft.com/en-us/library/jj728659.aspx

    According to the error message, I suggest to clear SharePoint Designer cache before loading the workflow again. And the cache is located in

    - %APPDATA%\Microsoft\Web Server Extensions\Cache;
    - %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache.

    If the error still exist, I suggest you to trawled through the ULS logs and view workflow reports.

    Also I suggest to track down bugs with workflows, this is the best resource I have found so far: http://ranaictiu-technicalblog.blogspot.com/2013/03/sharepoint-2013-workflow-debugdiagnosis.html

    In addition, I suggest to  use Fiddler, it is the best tools to check what is going on behind the scene when the Browse talks with the SharePoint Server.

    http://fiddler2.com/get-fiddler

    Best Regards,

    Linda Li


    Linda Li
    TechNet Community Support

    Tuesday, September 3, 2013 8:05 AM
  • Hi Linda,

    I have done some more investigation and found that appears to be the source of the issue.

    Our plan in terms of security is to create all our security groups in active directly so security can be managed here. We then create groups in SharePoint which we add these AD groups too. Therefore the sharepoint groups manage permissions however AD manages who belongs to those groups.

    This seems to work find for access to the lists, sites etc. However this is the cause of the problems.

    If a user is in one of these AD groups and has the correct access they can submit browser based InfoPath forms without issue. However when the interop bridge workflow runs it fails.

    If we then add the actual AD user account to the sharepoint group and repeat the process the workflow works exactly how is expected.

    Unfortunately it doesn't end there. I have two groups Site Members and Site Visitors. Both have contribute to the list that has the form. If the person is added to Members the workflow works. If the person is added to Visitors it doesn't work (same error as mentioned in previous post). Both the groups are exactly the same permission wise.

    Seems to me that in addition to the user needed to be in the group there is a problem with access rights being synced within the application.

    Thanks.

    Simon.

    • Marked as answer by Lindali Monday, September 9, 2013 9:21 AM
    Friday, September 6, 2013 3:26 AM