Communication
Open REST APIs
Every module of the Nexeed Industrial Application System provides its main features and key data as public interfaces for easy interoperability. We see this as crucial in our journey towards building an open but integrated Industry 4.0 platform. Our product teams decide, based on use-cases and customer requests, which operations or data should be public, and which we will keep private. The public APIs are documented in the running system as well as here in the integration guide in the spaces of the respective modules.
There are several reasons why we have chosen to use open REST APIs and encourage anyone writing Modules for Nexeed to do the same:
-
Reusability: Open REST APIs provide a way to reuse existing software components, reducing development time and costs.
-
Scalability: REST APIs can be scaled easily to handle large amounts of traffic, making them ideal for building web applications that need to handle high volumes of data.
-
Interoperability: REST APIs are based on open standards, which means they can be easily integrated with other software systems and platforms.
-
Flexibility: REST APIs can be used with a wide range of programming languages and frameworks, making them a flexible and adaptable option for developers.
Message Broker & Queueing
While REST APIs are great for synchronous communication via request-response, some use-cases require a different approach. For high volume of non-time-critical data, the publish-subscribe methodology has established over the last decade or so. In Nexeed Industrial Application System, we of-course also use such an approach. Our architectural set-up allows us to use the benefits of this approach both internally and externally. Our Information Router can subscribe to topics in an existing messaging system (like Solace, Kafka, …) to allow for high reliability and throughput. When, on the other hand, external systems require data from NEXEED, our Data Publisher can be used to publish to such messaging environments. Internally, we also use a messaging backbone to relay messages between modules asynchronously.
Integration Events
One aspect of self-contained systems is loose coupling. To enable this in our inter-module communication, each module propagates noteworthy changes to its data. This way, other modules can asynchronously synchronize and do not need to poll data from 30+ modules repeatedly
Example:
-
A user changes the name of a facility in Master Data Management
-
Master Data Management publishes an integration event "facility with ID Z changed"
-
All modules, that use facilities (Condition Monitoring, Shopfloor Management, …) subscribe to the event exchange
-
Upon receiving this event, they call the Master Data Management equipment API with ID Z to read the now-changed facility details
-
The modules change the name of this facility in their facility cache