I’d like to put together a few notes on the subject of integration between systems (one system talks to another). This is a very well-trodden path in our field and I run the risk of saying some obvious things.
The team I work with at SECUTIX deals with integrations between our in-house applications and “the rest of the world”, for example ERPs, CRMs, accounting systems, resellers, institutional sites, data analysis systems, etc. There are two ways to build those integrations:
- By deploying public APIs that other systems can consume, essentially endpoints and webhooks, which are documented here: https://platform.secutix.com
- By (rarely) building connectors, deployed in the company’s applications, which call third-party public APIs.
Public APIs
What are we talking about when we say ‘public APIs’?
Of course, our applications are modular and expose all sorts of internal webservices that are called from one brick to another. These APIs are more or less standardised and bear the mark of the evolutionary history of our systems. (a jolly phrase to say that we have tons of technical debts)
In what follows, when we talk about public APIs, we mean that the API:
- is accessible from outside our systems
- has a documented contract, in whatever form, that is publicly accessible,
- has textual documentation describing use cases, authentication protocols, etc.
These public APIs can take various forms:
- Webservices
- Webhooks
- SSO integrations
- Widgets
- Exchanged flat files
- etc.
Connectors
Connectors are components deployed as part of our internal applications. They have access to the application’s internal resources (database, internal webservices) and can connect to the application’s external resources.
The development pattern for a connector is always the same and generally comprises three building blocks, whose names we try to standardise:
- the connector: a class that encapsulates all the plumbing for communicating with the external system. (Yes, I know, it’s the same name as the concept above – I don’t have so many names in my “names pool”). The connector, in Java, exposes an interface taking as parameters only the DTOs exposed by the remote system.
- the transformer: a class responsible for transforming our internal DTOs into external DTOs or vice versa
- the processor: this orchestrates the calls to the connector and the transformer, depending on the needs of the integration.
In IT, we generally read data from A, transform it and store it or send it to B. You wonder why some people think this job is complicated.
In one or more future posts, I’ll expand a little on the question of public APIs and connectors.