6

I read a long article about two types of event receivers inside SharePoint server 2013:-

  1. Server side event receivers (available inside SP 2013 & SP 2010)
  2. Remote event receivers(available inside SP 2013 only)

now i know that remote event receivers do NOT allow having event receivers for features, and are used to define event receivers for APPs.

but can anyone advise on these points:-

  1. What are the major differences between these 2 types of event receivers ?

  2. Which one is recommended to use inside SP 2013 ?

  3. Let's say I have an Issue tracking list , which contain data , and I created the issue tracking list using the UI. Now I want to add an event receiver to the existing list , when an item is created. Mainly to add an HTML table at the end of the item body field.So which approach is best to use Server side Event receiver OR Remote event receiver and why ?

  4. If I want to add a validation to existing list, mainly to prevent creating or editing an item which have its "Status" field = "In progress" & its "Assign To" is empty.So which approach to follow ?

3 Answers 3

8
+100

Answering your 4 questions:

  1. Differences

    1. Remote Event Receiver (RER) -
      1. A provider hosted app is must, which means you need additional infra. Apparently, as pointed out by Mihail-Florin Popa, it is no longer true.
      2. Works using web services, you expose web services on your provider hosted app, that are called when an event is fired.
      3. Only Client Object Model is available inside the event receiver code, so you'll be limited by CSOM's limitations.
      4. This is the only option to override events if you have O365/SharePoint online.
      5. Using this approach makes your code future safe, when SOM is killed finally.
      6. This is the list of events available to override.
    2. SharePoint Event Receivers (SER)
      1. No additional infra required to host event receiver code.
      2. Works using code running in context of W3WP.exe in case of farm solutions and spucworkerprocess.exe in case of SandBox solutions.
      3. Full fledged SOM API is available in case of farm solutions, no limits.
      4. This is only available in On-Premises environment.
      5. This might be deprecated or unsupported in future releases.
      6. This is the list of events available to override in SER.
  2. You have a choice only in case of On-Premises otherwise you HAVE to use RERS. However, to be future safe, you should start using RERs if it fulfills all your requirements as the App Model is the future of SharePoint.

  3. Both will fulfill your requirements reliably and efficiently, the decision depends upon your decision about future readiness and investment in hosting another application.

  4. This can be achieved by List Validation formula without using event receivers at all, in fact event receivers would be an unnecessary overhead. That would be the recommended approach to do it. You can refer this article to learn about it.

5
  • now seems even on sharepoint 2016 it support farm solutions and fully trusted code,, so not sure if farm solution will not be available in the furure.. so if i have on-premise sharepoint then there is not any issue of using SER ,, even for future consideration , because in SP 2016 it will support farm solutions.. seems RER should be used if i am using office 365 ,, other wise regular SER should be fine.
    – John John
    Mar 21, 2016 at 17:16
  • 1
    Yes, SER is fine even for 2016 and it saves you additional infra cost and effort.
    – AmitWiki
    Mar 21, 2016 at 17:18
  • now since SP 2016 supports farm & sandbox the same way SP 2010 & 2013 support them, so my question is why you still consider using APP is more future safe, at-least we can guarantee that sharepoint will support farm and sandbox till early 2019. and no one know since then maybe MS will provide another technology which takes over APPs,i am really confused about the differences between SER and RER ,when i have on-premise sharepoint ? till now i can not identify a real benefit of using remote event receivers, Although MS and most recent documentations are pushing on using RER over SER
    – John John
    Mar 22, 2016 at 1:03
  • One benefit is if you want to move to cloud anytime soon, you are ready if you use RER. Moving to cloud has its own plethora of benefits.
    – AmitWiki
    Mar 22, 2016 at 1:07
  • Worth noting that point 1.1.1 is incorrect, namely a Provider-hosted Add-ins is not (any longer?) a must. For example, this article shows how a RER can be done without a PHA: blogs.msdn.microsoft.com/boodablog/2015/01/12/…. Part 2 at: blogs.msdn.microsoft.com/boodablog/2015/01/13/…
    – Mihail
    Jun 27, 2019 at 15:47
5

At first,

Remote event receivers are mainly introduced for cloud or office 365 environment (SharePoint Online) where the core logic will run in an hosted environment outside of SharePoint Sites and still try to achieve the regular event handler functionalities.

You can still develop them for as SharePoint Ad-In's even in 2013 server but i will list out couple of major differences here:

  1. Remote event recieverers have lot of complexity because you need to setup the app domain, app-catalog, trust and so on as they can be hosted in cloud or another iis server.

  2. Core logic will run outside of the SharePoint site calling a custom or out of the box web service, trigger workflows to handle the actual events.

Now coming to your two requirements, ITEM Added and Adding events in the regular SharePoint Farm solution are best suitable for you to add or append the html and also it (Item Adding event) can stop/prevent the event firing during the course based on the conditions of the field values.

if you want a future proof solution, then you should consider using remote event receiver else you can opt for the standard Farm solution based event receivers as you can achieve this functionality with both.

3
  • thanks for the reply, but if i got your point correctly, you mean i can not achieve my 3 and 4 points using remote event receivers ? is this what you mean ? and i have to create server-side event receivers ?
    – John John
    Mar 15, 2016 at 14:14
  • Your Points 3&4 can both be done using Remote ER. His point was that it is much harder to implement Remote Receivers as you have to manage App-Setup. The Question is really if you need your Logic to run outside of the SharePoint Environment. If you are developing Farm Solutions anyway, you might want to stick to the more easier regular Event Receiver :)
    – t0.
    Mar 16, 2016 at 17:48
  • @kesava but can you advice why you mentioned that using remote event receiver is more future proof solution?as seems on SP 2016 it support server-side code and farm solution and sandbox solution the same way SP 2010 and 2013 support them ... so do you really consider using APPs a more future proof solution ??and why?
    – John John
    Mar 22, 2016 at 1:06
2
  1. In Remote event receiver custom logic is executed outside of Sharepoint runtime
  2. If you are sure you move in the future to the cloud use the remote, otherwise use server side.
  3. Answer depends on question, will you move to cloud (o365) because server side event are not supported in the cloud.

  4. you need to wire your event to item updated to stop the update from saving.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.