Integration possibilities

Design

Vertex is an modular application that has integration between the modules and is open for integration by design.

Custom module

We want to build and deliver software that is easy to maintain since this is better for all parties involved. However sometimes there are certain parts of the software where very specific behavior is requested by a customer that makes perfect sense for the business case / implementation that the customer is creating / running. Because we acknowledge that not everything can be captured in generic software we have opened our design to include a custom module.
A custom module is a module that runs along all the generic Vertex modules but implements customer specific logic. Most of the time this logic is created to integrate with other applications of the customer.
Examples of what could be build in custom module is a Pricing Value Provider that runs with every pricing and sends a specific subset of the pricing request, over a Kafka integration, to a service that is running in the customer landscape to get a risk index for that particular customer/pricing and continue the pricing calculation, with the risk index, one a response for this request is posted on another Kafka topic.

Plugin system

Plugins in the Vertex system are specific points in the application where we expect other services to add their own extensions to the basic functionalities. Examples of plugin systems within Vertex are: Pricing Value Providers, Document Types, Document Actions, Job Types. With these places for extensions other services can add their own specific logic to generic piece of logic. For example the TenneT module can implement a specific document type for the Nomination Message, this document type adds the feature to the Document Store module to identify TenneT nomination messages and once imported this same document type can extract metadata from that message so fields like the Sender, Receiver and MessageId can be extracted from the message and stored in the document metadata.

REST

Everything that is done through the front-end of Vertex is done through an API call. This API is further documented in a Swagger documentation. This means that most things can be automated through the API right away. Next to the API methods we have to support the front-end we also have API methods specifically for integration with other applications.
There is also the option to add specific REST methods to the custom module so the customer can have a specific API that is more static over versions of the software. We will design an API that meets the needs of the customer and will transform / map this into our internal API calls we need to make to implemented the contract that has been agreed. This means that this specific API is more decoupled when the Vertex software evolves and not every change in every API needs to be followed by an integration team of the customer, making the integration more stable and pleasant to work with from both sides.

Apache NiFi

We lever the power of Apache Nifi for integration with all possible ETL flows. With NiFi we don’t need to code up a specific integration with all the different technology used by the parties we integrate with. This means that for Vertex we can standardize on a Kafka and REST interface. Interfacing with other types of applications like RabitMQ, Azure Storage Queues, Azure Blob Store, S3 buckets etc can all be implemented in a NiFi flow and mapped back to the standardized interfaces of Vertex.
In the very rare case that we need to integrate with a technology that is not supported by NiFi, the open-source character of Apache Nifi enables us to implement this data source ourselves.
This means that sending and retrieving data in an event-driven way is possible from almost every technique imaginable. Because the implementation of that technique is isolated to a specific processor in a NiFi flow our codebase is isolated from all these different techniques and we do not need to implement a lot of client software in the generic parts of Vertex.