New Event Receiver Architecture

This documentation outlines the transition from the previous event receiver architecture to the new architecture designed to alleviate load and enhance efficiency. The previous architecture exhibited challenges related to throttling in event receivers, necessitating a reimagined approach to ensure smoother processing of requests and optimal resource utilization.

In our ongoing efforts to optimize performance, we have successfully mitigated throttling in our web jobs using a rate limiter mechanism. However, our event receivers have experienced increased throttling issues. Introducing the rate limiter to these event receivers is not a viable solution, as it could lead to API blockages and an accumulation of HTTP requests in the event receiver's queue.

The need for a novel architecture has emerged to address the load concerns associated with event receivers. Additionally, there's a requirement to ensure the handling of all requests sent to event receivers, including the capability to retry failed requests. Event receivers are categorized into two types: synchronous and asynchronous, each requiring distinct handling methods.

Synchronous Events

In the existing architecture, synchronous event receivers engage in various actions upon receiving events. These actions include:

• Updating Current Item: Changing item properties within the synchronous result of the event receiver.
• Field Value Change Detection: Identifying changes in field values to trigger web job initiation.
• Validation Process Triggers: Initiating system processes based on validation criteria.

Asynchronous Events

Similar to synchronous events, asynchronous event receivers perform immediate and delayed actions. Immediate actions are executed within the event receivers, while delayed actions are handed off to web jobs.

The previous event receivers were implemented as WCF services within Azure App Services. However, this architecture lacks flexibility for migration to .NET Core.

Offloading Logic to Azure Function App

To address the limitations of the previous architecture, we are adopting a new approach that involves offloading the majority of event receiver logic to an Azure Function App. The app will, depending on the complexity of the operation being performed distribute the task to a web job. This shift ensures efficient processing and scalability. Key elements of the new architecture include:

• Azure Service Bus Integration: Leveraging the Azure Service Bus to manage event requests and distribution.
• Function App Handling: The Function App evaluates whether a web job should be initiated and starts the job accordingly.

Revised Responsibilities of Event Receivers

Synchronous Events

The event receivers, under the new architecture, maintain the following responsibilities for synchronous events:

• Updating the current item, as described in point A above, remains within the event receivers.
• Pushing relevant information, including SPRemoteItemEventProperties, to the Service Bus.
• Fetching the current item in the synchronous event before modification and forwarding it to the Service Bus (if necessary).

Asynchronous Events

For asynchronous events, the responsibilities of the event receivers are:

• Forwarding pertinent information, including SPRemoteItemEventProperties, to the Service Bus.

List Item Event Receivers

Under the new architecture, specific examples of event processing include:

Business Module List (Entities)

• On Added: Initiating various actions including business module statistics, role inheritance adjustments, entity security rules, aggregations, and more.
• On Updated: Handling tasks such as updating entity stage fields, managing action triggers, and validating processes.
• On Deleted: Executing actions related to aggregations, process triggers, and more.

Entity Site List (Document/List Items/Identity Lists)

• On Added: Involves enforcing default values, triggering event bus, handling security rules, and more.
• On Updated: Tasks include managing aggregations, handling security rules, and invoking the event bus.
• On Deleted: Actions encompassing related content, maintaining document numbers, aggregations, and more.

The new event receiver architecture enhances efficiency and scalability by offloading logic to an Azure Function App while leveraging the Azure Service Bus for streamlined event management. This transition empowers improved handling of both synchronous and asynchronous events, offering a resilient and scalable framework for processing requests within SharePoint.