Connector Framework
IPF’s Connector Framework provides an abstraction around communication transports which aims to simplify integration. This page introduces the core concepts used in the Connector Framework, which provides system connectivity.
What is a Connector?
A connector is simply a set of common interfaces, which provides a means to communicate with external systems, synchronously or asynchronously. Implementation details specific to the configured transport mechanism are hidden behind the interface. This improves understanding and allows teams to standardise integration rather than creating separate implementations for each new system.
The main benefit of using connectors is that they reduce the amount of boilerplate code required for integrating with systems which use common data interchange formats (such as XML or JSON) and transports (such as HTTP, JMS or Kafka).
Connector Features
Connectors implement a number of features out of the box which are commonly required when integrating with external systems.
Types of Connector
Connectors can be used for either sending or receiving messages.
Detailed documentation specific to each type can be found in the following pages:
Connector Stages
Each connector is a composition of stages that a message flows through. The stages provide different capabilities, many of which are optional and can be tailored to specific requirements dependent on the situation.
Receive
The purpose of a receiving connector is to take a message from the configured transport and map it into a known format that can then be handled. Received messages must be associated (correlated or identified) so that they can be linked to past or future messages.
The following stages that can be configured for receiving:
-
Payload Decryption (optional)
-
Conversion to Target Type
-
Message Association
-
Message Validation (optional)
-
Message Logging (optional)
-
Message Handling
Refer to the Receive Stages section in the Receiving Connector documentation for further details of each stage.
Send
The purpose of a sending connector is to take a message and send it over the configured transport. the sending of messages can be configured to use multiple transports (with load balancing or fallback strategies) and can employ circuit breaking and retries to overcome transient networking issues.
The stages that can be configured for sending are.
-
Message Validation (optional)
-
Message Correlation (optional)
-
Message Logging (optional)
-
Payload Encryption (optional)
-
Resilient Send
Refer to the Send Stages section in the Sending Connector documentation for further details of each stage.
Akka
The Connector implementation uses Akka Streams. When a connector is built, the individual stages (known in Akka Streams nomenclature as operators) are joined into a single stream.
The provided transport implementations use Alpakka, the Akka Streams subproject dedicated to integration. It is similar to Apache Camel in its goals; though is implemented with the actor model, that allows for highly scalable, concurrent processing.
The Alpakka project has implemented integrations with a large number of common technologies. For more information on what Alpakka supports, visit the following documentation.