evoke it logo white with clear backContact

ODATA Batch Processing Support in Microsoft SharePoint

ODATA Batch Processing Support in Microsoft SharePoint

SharePoint 2010 introduced the ListData.svc. This ODATA service supports ODATA batch processing. The ListData.svc is still available in SharePoint 2013, however, SharePoint 2013 also introduced a new _api REST service, supposed to replace the ListData.svc. The _api REST service did not initially support ODATA batch processing though. In SharePoint Online (Office 365), ODATA batch processing support was added in November 2014. This ODATA batch processing support has not (yet) been added to SharePoint 2013 on-premise though.

Bugs in the _api REST service ODATA batch processing support

Unfortunately, the _api REST service in SharePoint Online does not properly support ODATA batch processing.

• First of all, when using Microsoft’s own datajs library (http://datajs.codeplex.com/) to submit a batch request containing a change set, the response from the _api REST service is not in the expected format resulting in datajs being unable to parse the response. This is not a problem with the ListData.svc

• Second, the _api REST service does not support referencing requests in a change set. For instance, you have a Projects list and a ProjectResources list that has a lookup to the Projects list. You want to insert an item in a Projects list and insert an item in a ProjectResources list, with a lookup to the item you’re inserting in the Projects list, all in the same batch. While you do not know the Id of the Project item you’re inserting at this stage, you can still specify the lookup on the ProjectResources item using a Content-ID as follows:

changeRequests.push({requestUri: “Projects”,method: “POST”,data: {Title: “Project 1”},headers: {“Content-ID”: “1”}});

changeRequests.push({requestUri: “ProjectResources”,method: “POST”,data: {Title: “Project Resource 1”,Project: { __metadata: { uri: “$1” } } // $1 refers to the Content-ID of the project above}});

This works when using the ListData.svc, but this is not supported in the _api REST service.

I created a little test SharePoint hosted App that demonstrates these issues. It tests both the ListData.svc and the _api REST service. See https://github.com/RemcoBlok/SPBatchChangeSets.Andrew Connell created a UserVoice suggestion to get Microsoft to fix the issues with ODATA batch processing support. Please add your vote to that suggestion. See http://officespdev.uservoice.com/forums/224641-general/suggestions/7013224-fix-rest-api-batch-responses-to-include-changeset

Bugs in the ListData.svc ODATA batch processing support

It should be assumed that any ODATA service processes the change requests in a change set in the same order that they appear in the change set. So, if a change set contains an insert into a list A, an update of an item in a list B and a delete of an item in list A in that order, SharePoint should process the changes in that order. Unfortunately it does not.This causes a problem when you try to enforce referential integrity in your data store by restricting deletes in a list A, when a list B has a lookup to list A. You would specify the relationship behaviour on the lookup as restrict delete.

Say you have an existing item B1 in list B with a lookup to an existing item A1 in list A. You now want to insert a new item A2 in list A, update the item B1 in list B so that its lookup is now to the new item A2 in list A, and then finally delete the existing item A1 in list A, all in a single change set. You would have to do those changes in that specific order. When you specify the relationship behaviour as restrict delete, you could not first delete the existing item A1 in list A, when the item B1 in list B still has a lookup to that item A1. You would have to change the lookup of the item B1 in list B first. Only when the existing item A1 in list A is not referenced anymore will you be able to delete it.So your change set needs to contain inserts, updates and deletes in that order. Unfortunately SharePoint does not process it in that order. SharePoint will attempt the deletes first, then the inserts and then the updates. This can be observed with list item event receivers on list A and B for ItemAdding, ItemUpdating and ItemDeleting. You’ll see that the deletes are handled first, then the inserts and then the updates. So, if you enforce relationship behaviour by restricting deletes, this change set with inserts, updates and deletes will fail with an error. The only way around is to not enforce relationship behaviour.

Then your change set with inserts, updates and deletes will succeed.This is of course a bug in SharePoint. SharePoint should process the changes in a set in the order they appear in the set. You should not have to disable the enforcing of referential integrity in your data store. Hopefully Microsoft will fix this. I’m not sure how likely it is to get fixed in SharePoint 2010. I’m also not sure how likely it is to get fixed in the ListData.svc service in SharePoint 2013 either as Microsoft will be deprecating this service in favour of the new _api REST service

Further Information

For further information on ODATA batch processing, see http://www.odata.org/documentation/odata-version-2-0/batch-processing for the ListData.svc, which supports ODATA version 2, or http://www.odata.org/documentation/odata-version-3-0/batch-processing for the _api REST service, which supports ODATA version 3.

Be the First to Get Our Ebook
Microsoft SharePoint 2019

What you need to know!

Back To The BlogContact Support

View Post's Via Catagory

Terms & ConditionsPrivacy PolicyDeveloped by Evoke IT