Building Integrations with Components
- Paul Le
- Aryn Wiebe
As we learned earlier, there are three parts that make up an integration. Generally, when building integrations in IguanaX, each component should correspond to one piece of the integration - either act as a source, processor, or destination component.
Each component applies separation of concerns and has a dedicated function:
A source should act as the trigger and should not perform any message transformation, just listen or poll for the message and push it to the next component.
It should be designed to work with the specific protocols and formats required to ingest the data.
Depending on the type of integration workflow, you may have one or more source components.
Avoid changing the data in Source or Destination to improve supportability and maintenance!
This is where any kind of message manipulation should be done.
All message manipulation (filtering, mapping, transformations, etc.) can be done in a single component, or can be broken out into multiple components if there are many stages or more complex processing required.
For example:
You can have more than one source component gathering data and push to a common Processor component if it is the same message type; or
With the Canonical Data Model you can have an additional Processor (“Normalizer“) component to convert all inbound messages to a common message format before pushing to the common Processor.
You are not restricted to use a certain number of components. You can have one or more source, processor, and destination component to meet your workflow needs.
By separating the responsibilities of each component, you create a clear data flow that’s easier to modify and scale, while maintaining flexibility to adjust or replace components as needed.