ACTUALLY RESOLVED: Unable to Create List using SharePoint 2013 REST API in SPD2013 29


Are you ready for this?

Im never satisfied with the answer “No you cant do that”, not as a Developer 🙂 So, i began to read through some TechNet and MSDN articles for Workflow and found this Gem. http://msdn.microsoft.com/en-us/library/jj822159.aspx 

What this Gem does is EXACTLY what Chris Givens found out and did in his PowerShell but as we discussed in my “Resolved post”, we cant run those scripts inside Office 365 SharePoint Online. So, it seems that you have to activate a Site Feature in your Site that you need this “elevated permission” then you need to copy the App Principal ID from the one you want elevated then take that to a “hidden” link inside the App Catalog Site http://{hostname}/{catalog site}/_layouts/15/appinv.aspx and then work your magic to elevate the permissions via an XML node copy / paste magic.

Anyway the GOOD NEWS is that I have tested this in SharePoint Online, and it works like a champ, see below for screenshots.

If you would like the full history of this, see the following post in chronology

  1. http://fabiangwilliams.wordpress.com/2013/09/06/help-unable-to-create-list-using-sharepoint-2013-rest-api-in-spd2013/
  2. http://fabiangwilliams.wordpress.com/2013/09/07/resolved-unable-to-create-list-using-sharepoint-2013-rest-api-in-spd2013/

Proving it out

First me activating the Feature

image

Next grabbing the App Principal ID needed for the Workflow in question. Now i purposely cut off all of the ID, i dont want some crafty person out there using it. Just realize that this is the same account that Chris and I talked about in the PowerShell

image

then moving the piece of Workflow logic that does the List Creation inside the App Step inside SharePoint Designer

image

and finally re-running the Workflow will yield the below in the Workflow History

image

and just to bring it home, here is the new List or (App i guess) Created

image

 

Cheers FGW


Leave a comment

Your email address will not be published. Required fields are marked *

29 thoughts on “ACTUALLY RESOLVED: Unable to Create List using SharePoint 2013 REST API in SPD2013

  • Jim Bob Howard

    Make sure that your App Principal permission has the right scope.

    If you’re creating a list, it can be as granular as /web. If you’re creating a web, it can be as granular as /sitecollection.

    In the msdn article you suggested, the text box has:

    <AppPermissionRequests>
    <AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web” Right=”FullControl” />
    </AppPermissionRequests>

    But the image below it has:

    <AppPermissionRequests>
    <AppPermissionRequest Scope=”http://sharepoint/content/sitecollection” Right=”FullControl” />
    </AppPermissionRequests>

    See http://msdn.microsoft.com/en-us/library/fp142383.aspx#Perm_types for details. Of course, you will need to have SCA to set the latter.

  • Scott

    On SharePoint Online this works through Fiddler or Posting an item to the same site. However, trying to POST between site collections and web applications produces an Access Denied error.

    Thanks for picking this difficult issue apart.

  • Scott

    Never mind. I got it to work. You need to allow workflows to use app permissions on the target site. Then trust the workflow app from the source site. Once I did that I was able to post across site collections.

    Once again, thanks for the article. No way I would have gotten this far without your help!

    Cheers

  • Soma Choudhuri

    Thanks Fabian, great post.
    Now I can able to create item in another site with Designer Work Flow using Rest API .
    But how to update or delete list item in another site with Rest API ?
    Can you please help on this?

  • Simon Kirkby

    Hi Fabian, Your work is very interesting, but did you ever get the worklow in sharepoint to create a list item?
    I have followed what you have done but I cannot get around the 255 character limit on a string field in SPD 2013 as the header with the Accept, Content-type, content-length and X-RequestDigest elements must add up to more than 255 characters.

    • fabiangwilliams

      Actually, I got it to work on many scenarios including List Creation and List Item creation. These are string workflow variables and I haven’t met any limits when creating my headers and Im sure you will see others out there as well with similar experiences. Ensure that you are making separate variables for Accept, Content-Type, Content-Length etc. Its not just one long Header, that is how I am interpreting your comment and if that is what you are doing, it will not work. in all my examples I am building distinct workflow variables for each header.

  • Oleg Slyusarchuk

    Fabian,

    [I will be referring to SharePoint Online version of the issue]
    Are you sure than “stealing” authentication cookies from Fiddler is the only option to get authenticated?
    Is this the best practice?

    Can you make even GET call without cookies?

    Personally, I’m still getting
    {“error”:{“code”:”-2147024891, System.UnauthorizedAccessException”,”message”:{“lang”:”en-US”,”value”:”Access denied. You do not have permission to perform this action or access this resource.”}}}
    with the same set of request headers as in Fiddler where everything works fine.

    Adding App step and all related app permissions to workflow also did not resolve issue.

    I also got the following response (http://community.office365.com/en-us/f/148/p/178921/692891.aspx?pageindex=2 — see the bottom)

    Essentially, this means that REST cannot be used with workflows or InfoPath forms deployed/published to SharePoint online. Right?

    Since is very important piece of missing functionality, hopefully this will be fixed at some point.

    Answer (from Evan Zhang MSFT Support)
    Yes, it’s correct. ):

    Fabian,
    It bothers a lot of people. Most of attempts to replicate your approach just fail.
    Can you clarify the issue ?

  • Mike Bloom

    Great article!

    I tried this on my O365 SharePoint Online, however my workflow keeps getting suspended with this error…

    Internal Status: Suspended

    RequestorId: bc9a0444-b4ab-f652-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Activities.Messaging.SendHttpRequest.GetAcceptHeader(DynamicValue requestHeaders) at Microsoft.Activities.Messaging.SendHttpRequest.OnReceiveResponse(NativeActivityContext context, Bookmark bookmark, Object value) at System.Activities.Runtime.BookmarkCallbackWrapper.Invoke(NativeActivityContext context, Bookmark bookmark, Object value) at System.Activities.Runtime.BookmarkWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager) Exception from activity SendHttpRequest HttpPost Switch[String] Sequence Microsoft.SharePoint.WorkflowServices.Activities.CallHTTPWebService Sequence Microsoft.SharePoint.WorkflowServices.Activities.AppOnlySequence Stage 2 Sequence Flowchart Sequence Remote Desktop Request – Submit Item to ITS.WorkflowXaml_bf5a993b_6e83_4a35_ae3d_d5080da78e11

    • fwadmin Post author

      the fact it says dynamic value would lead me to believe it is one of your dictionary variable that has a null value set, use the log to history to check before you write to your variable

  • Laurent

    Hi Fabian,
    I’m referring SharePoint online… as you said : “The key is to do it in the App Step” those the header change if your doing it in the context of the App.
    Do I still need in the Header ; Accept, Content-Type, Content-Length, host, cookie and X-RequestDigest ?

    • fwadmin Post author

      even though the header will change rightfully so, you are doing a call to the api to get the values minus a few like accept, content type etc.. but regardless, I would suggest you history log out your items iteratively to see if one them is a null value and not getting captured.

  • Rob Wagner

    Fabian, this post saved my sanity! I am able to get list details from another site as promised. However, I’m unable to get list items from an external list (I can request the list details and they show up fine, but I request “/Items” and I get the “unauthorized” error again.) I know external lists are a different species, but I was really hoping this method would get me over that hurdle too. Any thoughts on this?

    • fwadmin Post author

      Hmm, I think I have done this too, try doing it in Fiddler first but you will have to modify your Headers if this is SPO accordingly, I have a post on that too. Like I said, im pretty sure I have done, this just cant put my hands on the post now, Ill research it and if you are still stuck, I will post back to this comment. But if you can do it in Fiddler, which is an easy test, you can do it in your workflow.

      • Rob Wagner

        I had never used Fiddler before….pretty neat. So, I’m able to get the list items on the external list using the REST API directly in the browser (example: /_api/lists/getByTitle(‘ExternalListName’)/items). I’m also able to get them from using Fiddler. For testing purposes, I created a site workflow that gets the count of items from a custom list within the current site, then a custom list in another site (using the App Step with elevated permissions), and then the external list which happens to be in the current site (again, using the App Step). The workflow successfully gets the first two, but not the external list.

        We’re using a workaround for now, but it would be great to get the data straight from the horse’s mouth!

  • Fran

    How about creating a site group and adding member’s/permissions? Can’t seem to find anything/anyway to do this so far in a workflow in designer.