Dispatcher Service

Introduction

The Dispatcher Service is responsible for routing messages between individual connector flows. This allows for the exchange of data in a centralized fashion via the Hub & Spoke model.

API Reference Implementation

Technologies used

MongoDB: MongoDB is used as the Dispatcher Service’s storage solution.

How it works

Dispatch Configurations.

The Dispatcher Service works on the basis of Configurations. Each configuration contains a list of connected applications, each of which may have one or several outbound (application-to-OIH) and inbound (OIH-to-application) connections. These connections are distinguished based on the data schema and operation (i.e. create/update/delete) they use.

Once such a configuration has been saved, the Dispatcher Service independently monitors incoming data from the listed outbound connections. Whenever a piece of data from one of these connections is successfully processed by the Data Hub, the Dispatcher Service then checks the configuration for any apps with matching inbound connections. To qualify, both the operation and data schema of the inbound connection must match that of the new data. For example, a piece of data in the “Organization” schema will not be routed to a connection configured to use the “Person” schema.

Technological Background

The Dispatcher Service functions on the basis of flows. However, instead of direct app-to-app connector flows, it uses app-to-OIH and OIH-to-app integration flows.

Whenever a dispatch configuration is created or updated, the Dispatcher Service automatically creates a number of integration flows, one each for connection of each connected app. These flows connect to and from the Smart Data Framework using the SDF-Adapter. The Dispatcher Service automatically keeps stock and maintains these flows. If an inbound flow is inactive when data for it comes in, it will automatically be started. If a configuration is deleted or an app removed, all associated flows are automatically deleted.

Data handled in this manner is routed through the Message Oriented Middleware (MOM). Any time a new piece of data coming in from an outbound flow was successfully processed by the Data Hub, a message is published on the MOM containing both the actual data that was fetched from the app (the payload) as well as certain metadata denoting its source, schema, and so on.

These messages are then received by the Dispatcher Service. Based on their metadata, the Dispatcher Service is able to identify the source of the data and find all appropriate consumers based on saved dispatch configurations. Each consumer has an associated integration flow, and the Dispatcher Service then sends a message with custom-tailored metadata (such as the recordUid that the target app can use to identify the data) to each of these flows using the MOM.

Finally, these messages are received by instances of the SDF Adapter, which is the first node in each consuming integration flow. The SDF Adapter then passes on the payload of the message to the next node in line, at which point the data is treated just as in a regular connector flow, passing through a transformer and adapter and finally being passed on to the target application.

Dispatcher Service API

The Dispatcher Service offers a REST API through which dispatch configurations can be created, modified, and deleted. To interact with this API, the user must supply a valid bearer token generated by the Identity Management.

List of supported Methods and Routes

endpoint	method	description	comments
/dispatches	GET	Returns a list of all dispatch configurations available to the user	Currently, all configurations are shared by tenant
/dispatches	POST	Stores a new dispatch configuration	Automatically creates all integration flows for this configuration
/dispatches/{id}	GET	Returns one particular dispatch configuration by its ID
/dispatches/{id}	DELETE	Deletes a dispatch configuration	Automatically deletes all associated flows
/dispatches/{id}/app	PUT	Adds a new application to a dispatch configuration	Automatically creates all integration flows for the app
/dispatches/{id}/app/{appId}	DELETE	Deletes one application from the dispatch configuration	Automatically deletes the app’s associated integration flows

For further details and examples, please refer to the API Reference

Interaction with other Services and Components

The Dispatcher Service interacts with these Services:

Identity Management: The Dispatcher Service relies on a bearer token supplied by the Identity Management to determine which dispatch configurations the current user may see.
Message Oriented Middleware: The Dispatcher Service receives and routes all incoming data through the Message Oriented Middleware.
Flow Repository: The Dispatcher Service communicates with the Flow Repository to create, delete, and start all integration flows necessary for a dispatch configuration.