Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sensenet Events in enterprise use cases #1368

Open
herflis opened this issue Mar 29, 2021 · 0 comments
Open

sensenet Events in enterprise use cases #1368

herflis opened this issue Mar 29, 2021 · 0 comments
Labels

Comments

@herflis
Copy link
Contributor

herflis commented Mar 29, 2021

sensenet EVENTS

This backend feature is meant to serve as a foundation of different event handling features. The center of the Events feature is the repository, even outside events are directed through the repository service.

It consists of two parts: an Event Distributor and the Processors. Both run inside the sensenet application app domain.

Event Distributor

  • content events (CRUD, versioning/approval events) are recorded
  • when an event occurs, all processors are notified in parallel
  • there are two types of processors:
    • synchronous: audit log, node observer
    • asynchronous: all new processors. These will run in the background, not blocking the content operation.

Later

  • other events (permission change, login/logout)
  • events are stored persistently
  • changed data (metadata only) is stored, one per event
  • called flags - if all set?, the event can be deleted (TBD)
  • short life cycle, events are cleaned up regularly to save storage space
  • the stored data is event-specific, but not related to the subscribers (observers), because the same event can be used by multiple different subscribers

Processor

  • a processor examines the event and decides whether it is relevant or not
  • processor types:
    • WEBHOOK
    • EMAIL (formerly Notification) (later)
    • SignalR (push notification for clients) (later)
  • all processors get the same event data
  • all processors get all events
  • aggregating events is the responsibility of the processor (e.g. sending batch emails once a week)

Considerations

  • the feature should not interfere with the events (does not block content save), runs in the background
  • processing should be scalable
  • new types of observers can be plugged in
  • how and where do we store subscriptions? (TBD)
  • filtering (for type, path, etc.) happens on the processor? (TBD)
  • robustness and disaster recovery:
    • an event should be passed to an observer once and only once
    • if processing terminates before calling all observers, the processor should resume the calling after recovery

Some UML

Components and data

webhook-1

Collaboration

webhook-2

@herflis herflis added the Epic label Mar 29, 2021
@herflis herflis modified the milestone: Sprint 232 Mar 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant