User Tools

Site Tools


System Overview

The SIB framework consists of serveral listeners and callers communicating in a standardized way over a central MQTT transport.

As of version 1.3 the message flow can be configured and controlled by sequences, see sib_sequence.


A listener is a service that on activation will trigger a data flow through the SIB platform. There are a number of different listeners implemented as part of the standard SIB package and what differs between the different listeners is which mechanism is used to trigger the data flow. The REST listener for example publishes a REST Service and when that service is called the payload of the request is used as the message payload for the data flow, and the CRON Listener will trigger a data flow in the SIB with an empty message according to one or more schedules.


A caller is a service that will listen for messages on the internal MQTT transport and perform some action depending on the data that arrives. Examples of actions to perform:

  • Predefined data reformatting
  • Calling an external service via REST/SOAP or other transports
  • Storing or fetching information to/from a database
  • Sending alerts via email


A sequence is a service that contains a map of components to execute. It stitches several callers/listeners together using a simple to read configuration allowing for data manipulation and flow control between each step.

.custom configuration

Implementing a caller or listener in SIB is done by installing the NPM-package for the caller or listener to implement and specifying a .custom configuration for that module. There are examples in the SIB git repository for each caller and listener on how to implement that specific service but generally the .js file for the service looks something like this:

require( "mqttlistener" ).start(require( "./custom/custom.js" ) );

The mqttlistener package handles all MQTT setup and teardown and all the internal mechanics needed by the SIB. It handles all logging, archiving and request/response dataflows and error handling. All customization of the service is done in the custom/custom.js file which may look like this:

var MQTTServiceCustom = {
	_id: "mqttSample:1",
	_name: "SIB MQTT Listener Sample",
	inputFormat: (msg)=>{
		msg.fmtData = "Data has been formatted and modified";
		return msg;
	loggerCfg: {
		dest: {
			file: false,
			console: true,
			mqtt: true
	outputFormat: (msg)=>{
		msg.outData = "output sent";
		return msg;
	mqtt: "mqtt://localhost",
	src: {
		mqtt: "mqtt://localhost",
		topic: "SIB/G2I.001/CRON/+"
	topic: "SIB/Samples/MQTTListener"
module.exports = MQTTServiceCustom;

For more details on the specific configration options for each caller and listener see their respective documentation. There are however some configurations that are valid for all modules:

  • _id: [REQUIRED] The ID of this instance of the service
  • _name: [REQUIRED] A descriptive name of the service
  • inputFormat: a method that receives the message on activation (after the SIBHeader is applied) and returns the reformatted data to publish on the MQTT transport. If this method returns null the messageFlow is aborted.
  • loggerCfg: Logger configuration for this service
  • outputFormat: a method that receives the response message from the MQTT transport if a request/response message flow is run. Returns the reformatted message data that will be returned to the activator of the data flow
  • mqtt: The server where the internal SIB MQTT transport is hosted

NOTE For all SIB components the string [ENV] is substituted with the NODE_ENV environment variable value in all configured topics. This is done even when useenv is set to false where that applies.

NOTE As of version 1.3.0 of all SIB modules the Listeners and Callers are implemented using JavaScript classes. This means that invoking the caller/listener looks like this instead:

let MQTTListener = require("mqttlistener" );
let mqttlistener = new MQTTListener( require( "./custom/custom.js" ) );

Other than that the configuration is the same for version 1.3.x+.

Data flow patterns


When initialized the SIB listener will subscribe to the topic or topics that it may publish data to with /RESPONSE/# and /REQUEUE appended. The /REQUEUE topic will accept messages archived by the input archiver and will trigger the dataflow again for that message.

When a data flow is triggered from a listener the listener will add the SIBHeader to the message and reformat the message to a SIB-format suitable for the MQTT transport whereafter the message is published on the MQTT transport.

If this is part of a request-only dataflow nothing more happens in the listener.

If however a response is published to the /RESPONSE/[msgId] topic the listener will validate the response, run the custom.outputFormat method and, depending on the type of listener, return the response to the activator of the service.


When initialized the SIB caller will subscribe to the topic in custom.topic. When a message arrives it run the custom.inputFormat method whereafter the dedicated action for the caller is performed on the message.

If data is returned by the dedicated action this caller is part of a request/response dataflow and the custom.outputFormat method will be run on the returned data. When this is done the SIBHeader is copied to the new data (if not done so by the formatter) and the resulting message is published to the topic found in _sibheader.responseTopic of the message.


See sib_sequence for an in depth explanation of the SIB sequences.

sib/overview.txt · Last modified: 2019/05/23 10:45 by hubbe