MongoDB Trigger Model Documentation

Overview

This document outlines the strategy for handling MongoDB triggers within the ADB system. We now utilize a unified trigger approach, enabling the processing of multiple database operations (INSERT, UPDATE, REPLACE, DELETE) through centralized application logic. This model simplifies configuration and provides flexibility for handling various use cases.

Unified MongoDB Trigger

General Trigger Configuration

A single trigger is used for all operation types on a collection. The trigger listens for changes in the MongoDB collection and sends messages to an SQS queue for processing. The key attributes of the trigger are:

  • Operations: Supports INSERT, UPDATE, REPLACE, DELETE.
  • Self URL: Points to the service responsible for handling events.
  • Message Type: Specifies the structure of the event message.
  • Queues: Defines the SQS queue where messages are sent.

You can define custom triggers for specific use cases if needed, allowing flexibility for specialized processing.

CallbackProvider

The CallbackProvider interface serves as a mechanism to define custom handlers for each operation type. It enables you to:

  • Specify Handlers for Operations: You can provide distinct callbacks for operations like INSERT, UPDATE, REPLACE, or DELETE.
  • Use Default Handlers: If no handler is specified for a particular operation, a default handler will be invoked. This ensures the system behaves predictably and avoids unhandled scenarios.
  • Extend Functionality: Add custom logic for specific operation types, or define fallback behavior for unrecognized actions.

A prebuilt implementation of CallbackProvider is available for use. This implementation allows for easy configuration of operation-based callbacks, ensuring flexibility and simplicity.

Default Behavior

If no specific handler is configured for an operation, the system will log a warning and execute the default handler. The default handler can be customized to perform actions such as logging, auditing, or simply ignoring the operation.

Notes for Developers

  • Always define appropriate callbacks for critical operations to avoid relying solely on the default handler.
  • Use the prebuilt CallbackProvider implementation for consistency and ease of configuration.
  • When creating custom triggers, ensure they align with the overall system design and data flow requirements.
  • Monitor and log trigger activity to ensure smooth operation and identify areas for improvement.