Skip to content

RabbitMQ Messaging in Content Distribution

Overview

This document describes when and how the MlsUniversalController writes messages to RabbitMQ for content distribution.

When Messages Are Sent

The MlsUniversalController writes to RabbitMQ in the following scenarios:

1. PUT /statistic/{id} (Update)

Location: MlsUniversalController.php:605

When updating a statistic via updateAction() → saveEntry(): - Calls sendQueueMessage() with action='update' - Only sends if the entity is in the validContents parameter - Only sends if content has actually changed (no message for HTTP 304 Not Modified) - Routing key: contenttool.contentdist.Statistic (depth=0)

2. POST /statistic (Add/Insert)

Location: MlsUniversalController.php:605

When adding a new statistic via addAction() → saveEntry(): - Calls sendQueueMessage() with action='insert' - Same conditions as update apply - Routing key: contenttool.contentdist.Statistic

3. DELETE /statistic/{id}

Location: MlsUniversalController.php:216

When deleting via deleteAction(): - Calls sendQueueMessage('delete', $entity, $id) - Note: Sends before checking if the entity exists - Routing key: contenttool.contentdist.Statistic

4. POST /statistic/{id}/copy (Copy)

Location: MlsUniversalController.php:373

When copying a statistic via copyAction(): - Calls sendQueueMessage('insert', $entity, $idAdded, $serializedData, 0) - Routing key: contenttool.contentdist.Statistic

Message Flow

MlsUniversalController::sendQueueMessage() (line 1058)
  ↓
QueueService::sendMessage() (line 62)
  ↓
MessagesService::publish() (line 67)
  ↓
PublisherRabbitMq::publish() (line 41)
  ↓
OldSound\RabbitMqBundle Producer (line 47 or 52)

Message Structure

The RabbitMQ message contains a StatistaMessageDao object with:

{
  "sender": "mlsContent",
  "action": "insert|update|delete",
  "entityName": "Statistic",
  "idEntity": 34,
  "typeName": 0,
  "idType": 0,
  "tstamp": 1234567890,
  "metadata": {
    "tstamp": 1234567890,
    "isExecForced": false,
    "msgSource": "mls",
    "queue": null,
    "data": "{ serialized JSON }",
    "checksum": "md5hash"
  }
}

Message Fields

  • sender: Always "mlsContent" for MLS operations
  • action: "insert", "update", or "delete"
  • entityName: The entity type (e.g., "Statistic")
  • idEntity: The entity ID
  • typeName: The depth value (0 for direct actions, 99 for dependencies)
  • idType: Always 0 for content messages
  • tstamp: Unix timestamp when message was created
  • metadata.data: Full serialized JSON of the entity (not included for delete)
  • metadata.checksum: MD5 checksum of the data
  • metadata.msgSource: Source of the message ("mls")

Routing Keys

Routing keys follow the pattern: {sender}.{action}.{entity}

  • sender: "contenttool" when depth=0, "contentbackend" when depth=99
  • action: Typically "contentdist" (or "publish" for publish operations)
  • entity: Lowercase entity name (e.g., "statistic")

Examples

  • contenttool.contentdist.statistic - Direct user action on statistic
  • contentbackend.contentdist.statistic - Dependency update (depth=99)
  • contenttool.publish.statistic - Publish action

Code References

sendQueueMessage() Method

Location: MlsUniversalController.php:1058-1070

private function sendQueueMessage($action, $entity, $id, $data = '', $depth = 99)
{
    $queueService = $this->get('queue_service');

    $queueService->setId($id);
    $queueService->setEntityName($entity);
    $queueService->setAction($action);
    $queueService->setData($data);
    $queueService->setDepth($depth);
    $queueService->setMsgSource('mls');

    return $queueService->sendMessage(false);
}

QueueService Configuration

Location: content-bundle/Resources/config/services.yml:119-126

queue_service:
    class: Stat\ContentBundle\Services\QueueService
    lazy: true
    arguments:
        - '@Stat\ContentBundle\Services\Queuing\MessagesService'
        - '@Stat\ContentBundle\Services\Queuing\PublisherRabbitMq'
        - '@Stat\ContentBundle\Services\Logging\MonologWrapper'
        - "%validContents%"

Important Behaviors

Synchronous Sending

  • The controller sends to RabbitMQ synchronously
  • If the message fails to send, the HTTP request returns a 500 error (line 609)
  • This ensures consistency - the database change only succeeds if the message is sent

Depth Parameter

  • depth=0: Direct user action from content tool (sender=contenttool)
  • depth=99: Dependency action from backend (sender=contentbackend)

Content Validation

  • Messages are only sent for entities in the validContents configuration parameter
  • For updates, messages are only sent if content actually changed
  • The change is detected by comparing checksums of serialized data

Delete Behavior

  • Delete messages are sent before verifying the entity exists
  • This ensures downstream systems are notified even if the entity was already deleted
  • content-bundle/Controller/MlsUniversalController.php - Main controller
  • content-bundle/Services/QueueService.php - Queue service implementation
  • content-bundle/Services/Queuing/MessagesService.php - Message publishing service
  • content-bundle/Services/Queuing/PublisherRabbitMq.php - RabbitMQ publisher
  • content-bundle/Resources/config/services.yml - Service configuration
Last updated: November 18, 2025 at 14:59
By: Jan Brauer