SOT
    • Introduction
    • Concepts
      • Operating principle
      • Machine interfaces
      • Supported protocols
    • Getting started
    • How-to
      • Send data
    • Operations manual
      • Overview
      • System architecture and interfaces
        • Technical context and deployment view
        • Machine interface
        • PPMP
        • OPP
        • Rexroth Tightening
        • Dynamic multi-tenancy
        • AMQP
        • Kafka
        • MQTT
        • Unknown Device handling
        • Watchdog handling
      • System requirements
        • connectivity/connectivity-service:1
        • connectivity/connectivity-webui-service:1
      • Migration from previous versions
        • Tenant ID migration guide
        • Migration to 2.0.0+
        • Migration to 2.1.0+
      • Setup and configuration
        • Logging
        • Helm configuration
        • Messaging (inbound)
      • Start and shutdown
      • Regular operations
      • Failure handling
        • Unknown device handling
      • Logging and monitoring
      • Known limitations
        • Rexroth Tightening
        • Unknown Device handling
        • Amqp
        • Kafka
    • Troubleshooting
    • API documentation
    • Glossary
Information Router
  • Smart Operations Toolkit
    • Deviation Processor
    • Multitenant Access Control
    • Notification Service
    • Ticket Management
    • Web Portal
  • Shopfloor Management
    • Andon Live
    • KPI Reporting
    • Operational Routines
    • Shift Book
    • Shopfloor Management Administration
  • Product & Quality
    • Process Quality
    • AI Services
  • Machine & Equipment
    • Condition Monitoring
    • Device Portal
  • Enterprise & Shopfloor Integration
    • Information Router
    • Master Data Management

SOT Learning Portal

  • Information Router
  • Operations manual
  • Known limitations
  • Kafka

Kafka

Rexroth Tightening

The RexrothTightening format is not yet supported via Kafka.

Forwarding

For the moment, the solution supports Kafka only as a southbound communication protocol.
Early implementations to have Kafka as a northbound protocol were already been made but not tested.

Topic regex pattern

In the current implementation, the solution uses one consumer per channel, and each consumer will use regex wildcard patterns to subscribe to different topics, which enables a consumer to read messages from different topics belonging to different tenants.

For example, a consumer subscribing with a topic pattern like "^.\\.ppmp\\.v3\\.message$" would be able to consume incoming messages from the following tenants: 7311ea8c-5d48-43fe-acf9-980eedf24b6c and baf04077-a3c0-454b-ac6f-9fec00b8e170

  • 7311ea8c-5d48-43fe-acf9-980eedf24b6c .ppmp.v3.message

  • baf04077-a3c0-454b-ac6f-9fec00b8e170 .ppmp.v3.message

Further improvements & suggestions

Config & initialization

  • In the current implementation, we are having one subscriber per channel. These are hard coded in the appsettings.json. One suggestion would be to have these subscribers get generated more dynamically at startup depending on the number of the channels.

  • If the topics are not already created in the broker, the Kafka broker will return a warning when subscribing to them. This warning will get intercepted by the used library (Foundation.Components.Messaging) and get logged as an error, which is noticeable at the startup logs.

Contents

© Robert Bosch Manufacturing Solutions GmbH 2023-2026, all rights reserved

Changelog Corporate information Legal notice Data protection notice Third party licenses