Skip to main content

MQTT integration (UBC.mqtt)

UBC - Unified Backend Connector comes with a component for acting as a MQTT client (over websocket), usable from 750 onwards. It enables real-time, fail safe messaging without having to handling with middlewares and topics like system availability, buffering, firewalls... In contrast to SAP standard's implementation, UBC.mqtt can work with persistent sessions unlocking completely new capabilities of your SAP system, without the need to involve Middleware technology. This document describes the technology and how-to integrate a new use-case. There are already project-specific implementations which documentation can be found at its place.

Summary of the top most advantages using UBC.mqtt:

  • no firewall issues, connection is established "from" the SAP system via MQTT over websocket "inside out"
  • "clean session" configuration enables the use of persistent sessions, making the MQTT broker store the messages when disconnected.
  • available from 750 onwards
  • the only needed component is - of course - a MQTT broker where all the messages will be distributed to its clients

Overview from a SAP perspective:

Proxy implementation​

In your Proxy implementation (custom), redefine method create_mqtt_client_config by returning an object of type /UBC/IF_MQTT_CLIENT_CONFIG. This is needed for configuring, wether it has to be a persistent session, configuring the username/password (deriving from Proxy table), ... Example: /UBC/CL_S17_PROXY

MQTT client​

There are basically two options to set up UBC as a MQTT client:

  • Running the client in a periodically scheduled job: If the job is scheduled e.g. every minute, the client (SAP-UBC) connects to the broker, waits for messages for a predetermined number of seconds and then disconnects again. It is not reasonable to configure a “clean session” for this scenario thus it always have to be persistent. Template: /UBC/S17_MQTT_WS_CLIENT
  • Running client as ABAP Daemon: An MQTT daemon runs once per client and keeps the web socket connection to the MQTT broker alive. If there are any new messages, they get pushed immediately to your SAP system/MQTT client. It is needed to subclass /UBC/CL_MQTT_DAEMON_ABS and schedule the daemon. Daemons are available from S/4 HANA upwards. For ECC releases, daemons could not be used. Instead, job solution is to be used. Example: /UBC/CL_S17_MQTT_DAEMON for S1Seven use case`

General recomendation: Use Daemons, if available in your system. Nevertheless, you cannot ensure your daemon is running 24/7 (due to downtimes, ...) thus it is also recommended to configure a "persistent session".

Customizing​

Every proxy automatically registers to all topics specified in /UBC/CUSTOMIZING chapter MQTT handler configuration for its Proxy type: MQTT handler configuration Basically, you link a topic to its implementation and specify the QoS (quality of service). We recommend using "at least once" in order to ensure the message is received in SAP.

Handler​

As soon as a message is received, it is transmitted to the bgRFC destination /UBC/INBOUND. (The destination was created automatically on system setup for UBC, please see also transaction SBGRFCCONF) This mechanism makes use of parallelization depending on your scheduler and server group settings. The bgRFC then executes the handler class specified in chapter MQTT handler configuration. Depending on the Quality-of-Service setting, the messages will be directly acknowledged after transmitting to bgRFC runtime. If there are any technical errors, please see SAP standard monitoring transaction SBGRFCMON. Your handler implementation have to inherit from class /UBC/CL_MQTT_HDL_REC_ABS.