The new retail digital price tag solution is developed by Alibaba Cloud Message Queue for MQTTit is launched to realize the data update management of electronic tags and multimedia screens in shopping malls, supermarkets and public places through MQTT. This topic takes digital price tags as an example to describe the system architecture, data flow design, and other key components of the solution in detail. Other similar industries can refer to this solution, making modifications as necessary for implementation.

Terms

Message Queuing Telemetry Transport (MQTT protocol)
The MQTT protocol is an industry-standard protocol for the Internet of Things (IoT) and mobile Internet, which is suitable for data transmission between mobile devices. Message Queue for MQTTThe MQTT protocol is supported by default.
MQTT broker
Message Queue for MQTTAn MQTT broker is a broker node that interacts with the MQTT protocol and is used to receive and forward messages.
MQTT client
The MQTT client is the node used to interact with the MQTT broker. In this solution, it specifically indicates a smart access point for sending or receiving price change messages.
P2P message
Message Queue for MQTTA special type of message that is provided based on the standard MQTT protocol. This type of message can be directly sent to a specified target MQTT client without subscription matching. For more information, see P2P Messaging model (MQTT).
Smart access point (AP)
A common network device (such as a smart router) that supports application programming and can simultaneously handle Internet access and LAN device control functions.
Digital price tags
Electronic screens that are used in malls, supermarkets, and other places. They support networking based on wireless sensor network protocols (such as Bluetooth and ZigBee) as well as smart AP nodes for networking.
Digital price tag management service
The backend service of a digital price tag system. It is used to manage the content that is displayed on the electronic screens and to manage and query manual tasks, such as price changes.
ApsaraDB for RDS
A highly available and scalable online database service provided by Alibaba Cloud. It is used to make persistent the status changes of tasks (such as price changes) in a digital price tag system.
Log Service
The log storage service launched by Alibaba Cloud, which is used in a digital price tag system to persistently store all operation logs for auditing and tracing.

Solution architecture

In digital price tag solutions, Message Queue for MQTTit can be used in conjunction with multiple Alibaba Cloud products to implement update management for price tag data.Figure 1 shows details on how the solution architecture of the digital price tag system works.

Figure 1. Solution architecture
Architecture
Ru Figure 1as shown in the following figure, the digital price tag system mainly includes price tag nodes, smart AP nodes, Message Queue for MQTT, Message Queue for Apache RocketMQ, the backend control service for digital price tags, RDS, and SLS. Each of these components is described as follows:
  • The smart AP forwards the status data of the price tag and receives price change commands. The smart AP uses the MQTT SDK to access Alibaba Cloud Message Queue for MQTT over the public network based on the distribution of the stores or locations. This link uses SSL/TLS to encrypt transmissions, preventing data leaks.
  • One smart AP downlink and several price tag nodes can communicate with each other through a wireless sensor network such as Bluetooth or ZigBee.
  • The backend management service for digital price tags is deployed on the cloud based on ECS. Message Queue for Apache RocketMQThe SDK and Message Queue for Apache RocketMQinteraction. The MQTT broker and the RocketMQ broker are interconnected.
  • The backend management service for digital price tags can persistently change the status in the RDS databases when price changes and other tasks are performed. It can store price tag report data and operations logs to Log Service to facilitate tracing and auditing.

Highlights

The advantages of the new retail digital price tag solution are as follows:

  • Powerful service capabilities that can be scaled automatically.
    • Message Queue for MQTTThe message transmission capability is infinitely scalable, allowing you to increase the number of smart terminals without suffering from compromised system capabilities.
    • Message Queue for MQTTInformation pushing in milliseconds is supported for millions of devices, with an even smaller latency for display updates of digital price tags.
  • Extensive application range, versatile generability, and rapid duplication.
    • Based on the MQTT standard protocol, this solution is universally applicable. It can be replicated in similar scenarios by adapting the solution for different data content.
  • High Reliability
    • Message Queue for MQTTand smart AP nodes supports SSL/TLS encryption in data transmission, preventing media business data leakage.
    • All service nodes are highly available and stable.

Data interaction

Status reporting

  1. The digital price tag node uses a periodic polling mechanism to exchange data with the smart AP node, reporting its current display status, power capacity, and other information.
  2. The smart AP node organizes data and sends MQTT messages to the MQTT broker.
  3. The MQTT broker writes the reported message to the Message Queue for Apache RocketMQtopic.
  4. The digital price tag management service receives Message Queue for Apache RocketMQto process and analyze the status of online price tag nodes in the current system, and record the data to log service.

Update displays

  1. The digital price tag management service sends a price change Message Queue for Apache RocketMQmessage, triggering the price change operation.
  2. The MQTT Server routes the Message Queue for Apache RocketMQto push messages to the target smart AP node by using the MQTT protocol.
  3. The smart AP node receives the price change notification and temporarily saves the task.
  4. The digital price tag node uses the polling mechanism to exchange data with the smart AP node and receives the new content to be displayed.
  5. After the target digital price tag node changes the price, the smart AP node returns an MQTT message to notify the digital price tag management service that the current task has been completed.
  6. The digital price tag management service writes the execution log of the current task to Service Log, facilitating subsequent tracing queries.

Precautions

The preceding process briefly describes how to use Message Queue for MQTTand Message Queue for Apache RocketMQto build the digital price tag system, please refer to Message Queue for MQTTand Message Queue for Apache RocketMQdocument.

Where use Message Queue for MQTTand Message Queue for Apache RocketMQwhen designing messages and parameters for transmitting commands, follow these principles:

  • SDK and protocol selection

    In the digital price tag scenario, one application may be used by hundreds of offline stores. Generally, each store is equipped with several smart AP nodes. The number of smart AP nodes can be increased as the business scales out. This makes smart AP nodes suitable for access by using the MQTT Protocol. The digital price tag management service is deployed on the cloud, Message Queue for Apache RocketMQaccess.

  • MQTT client ID mapping
    The MQTT protocol requires that each client have a globally unique client ID. A client ID consists of two parts concatenated with the @@@ separator. The final client ID must be unique and its total length cannot exceed 64 characters. The following describes the two parts of a client ID:
    • Prefix Group ID: The Group ID must be Message Queue for MQTTapply for the console. Group IDs can be roughly classified by platform vendor or channel to facilitate troubleshooting. For example, different industries or batches can be divided into different group IDs, or clients of different versions can use different group IDs.
    • Device ID that is the suffix in a client ID: A device ID is generated by an application. Device IDs can be encoded by using the unique information, such as the MAC address of the smart AP node.

    For more information about client IDs, see Terms.

  • Topic name mapping

    Use Message Queue for MQTTto send and receive messages, you must understand the publish /subscribe pattern of the MQTT Protocol. For more information, see agreement document and official documentation.

    The MQTT protocol is a message protocol based on the publish/subscribe pattern. The subscriptions and topics follow the directory tree format. Topics can be divided into parent topics and subtopics. The total length of a topic including the parent topic and subtopics cannot exceed 64 characters. The following describes the types of topics:
    • Parent topic: The topic at the first level of the directory tree is a parent topic. The parent Topic must be Message Queue for MQTTcan be used only after applying for permissions in the console. A Namespace is equivalent to a Namespace.
    • Subtopic: A topic under a level-1 topic in the directory tree in MQTT is a subtopic. You can specify subtopics as needed without having to apply for them.

    For more information about topics, see Terms.

    When designing a topic for sending and receiving messages, you must comply with the following principles:

    • Different types of tasks use different parent topics. For example, in this scenario, the price change tasks and the terminal status reporting tasks use different parent topics.
    • In the digital price tag system, we recommend that you use Message Queue for MQTTP2P messages do not need to be subscribed, and the sender can directly specify the peer end to receive them. For more information, see P2P Messaging model (MQTT).
  • Parameter design for message sending and receiving
    Generally, price change tasks in the digital price tag scenario require real-time pushing. Therefore, we recommend that you configure the smart AP as follows during the interactions between the smart AP and the MQTT broker to ensure that the smart AP does not need to process the tasks that were pushed when it was disconnected:
    • cleanSession set the parameter to true.
    • Set QoS to 1.
    The smart AP should perform deduplication and timeliness verification on received messages.

    For more information about CleanSession and QoS, see Terms.