Skip to content

Application Topic Structure

When designing MQTT topic structures, it's important to thoughtfully organize your topic strings to facilitate effective messaging and data management across your MQTT broker. The topic structure often encodes information about the actor, action, place, and time.

emit/application/(context|functionality|namespace)/Event(Payload<objectId>/<actionId>)/<timestamp>/{"sta"}
Place Actor Action Time
Application ObjectID Payload Payload
emit Quickbooks Customer1 Update Timestamp
- Time: While not explicitly shown in this example, time-related information is often either embedded in the payload or encoded in the topic if it's critical for the message context
- Place: - This provides context on where the actor is located or where the action should take place.
- Action: - This usually describes what needs to be done.
- Actor: - This is usually the device or subject of the action. It represents the specific entity that is acting or being acted upon.

The following example and sections provide the application topic structure:

emit/application/(context|functionality|namespace)/Event(<objectId>/<actionId>)/<timestamp>/{"sta"}

Prefix Type

emit - for publishing

  1. emit/application/: This indicates the action of emitting an event within an application context.
  2. (context|functionality|namespace): This part represents different aspects of the event. It could be the context within the application where the event occurred, the functionality associated with the event, or the namespace that the event belongs to. It seems to offer flexibility in how events are categorized or grouped.
  3. Event: This is a descriptor indicating that what follows is an event.
  4. (<objectId>/<actionId>/): This part seems to represent additional details about the event, possibly the object affected by the event (objectId) and the action performed (actionId) on that object. It's enclosed in parentheses, suggesting it's optional.
  5. <timestamp>: This is a timestamp indicating when the event occurred. It's likely included for tracking and chronological ordering of events.
  6. {"sta"}: This appears to be a placeholder or could represent additional metadata or payload associated with the event. In this case, it's "sta," which could stand for status or some other context-specific information.

Putting it all together, the structure seems to provide a systematic way of naming and organizing events within an application, allowing for easy categorization, tracking, and potentially processing of events. Each part of the structure serves a specific purpose, such as identifying the context or functionality related to the event, the object and action involved, timestamp, and any additional metadata or payload.

For the Response

echo/application/(context|functionality|namespace)/Event(<objectId>/<actionId>)/<timestamp>/{"sta"}
  1. echo/application/: Indicates that what follows is a response within the application context.
  2. (context|functionality|namespace): Similar to the event structure, this part represents different aspects of the response, such as the context within the application where the response is relevant, the functionality it pertains to, or the namespace it belongs to.
  3. Response: Indicates that what follows is a response to an event.
  4. (<objectId>/<actionId>/): Optional details about the object affected by the response and the action performed on that object, similar to the event structure.
  5. <timestamp>: Timestamp indicating when the response occurred, providing temporal context.
  6. {"sta"}: Additional metadata, status, or payload associated with the response.