Diving Deep: How Content Management Handles Notifications Behind the Scenes

Ever wondered how Content Management delivers notifications? It can seem a bit complicated, with several moving parts working in sync. Let's peel back the curtain and take a look at the journey a notification takes.

The Trigger: NotifyEvents

The Notification process starts with the NotifyEvents table. Whenever an event happens in Content Management, a database trigger springs into action. It immediately adds a to this table. For metadata updates, as they do not interact with DTree a trigger is not possible. We instead depend on inserting the row to NotifyEvents from within oScript directly.

Think of it as the initial holding pen for notification requests. The EventConsumerAgent, runs every five minutes. It scoops up these records so that under normal circumstances, the NotifyEvents table should remain relatively lean, holding only a few thousand rows at most. If you notice it ballooning, it's a red flag indicating a potential problem.

The Sorting Hub: LLEventQueue

Once the Agent Controller does its thing, the records from NotifyEvents are moved and transformed into entries in the LLEventQueue table. This table acts as a sorting hub, categorizing notifications into two main types:

• eLink Notifications (id=5000): These are typically system-generated alerts, often related to content or workflow changes.
• Personal Notifications (id=9000): These are the notifications you see when you click "Personal > Notifications" in Content Management. As well as "Business Workspace" notifications that are piped into Notification Center.

Every five minutes, dedicated agents take over:

• Agent 5001 (eLink): This agent picks up all the notifications with id=5000 and sends them out as emails to the relevant users.
• Agent 9001 (CommunityEventProcessor): This agent grabs the notifications with id=9000 and inserts them into the NotifyMessages table.

The Notification Repository: NotifyMessages

The NotifyMessages table is where personal notifications reside, waiting for you to view them in Content Management. These messages aren't permanent. They stick around for a month by default, giving you ample time to catch up.

The Big Picture: Order of Operations

To summarize, the flow of notifications in Content Management is a sequential process:

1. NotifyEvents: The initial trigger and temporary holding area.
2. LLEventQueue: The sorting hub, categorizing notifications.
3. NotifyMessages/Email: The final destination, where personal notifications are stored or eLink notifications are sent out.

Why This Matters

Understanding this behind-the-scenes process can be invaluable for troubleshooting notification issues. If you're experiencing delays or missing notifications, knowing where to look can save you time and frustration.

By keeping an eye on the NotifyEvents and LLEventQueue tables, you can proactively identify potential bottlenecks and ensure that your Content Management notifications are running smoothly.

Back to post listing