Integration is always written by someone:

  • one side
  • the other one
  • both of them

If one of the parties does not want to write, then you need to provide API documentation and access to the test and work point.

Integrations are often written:

  • inside the app
  • as an external (separate) application
  • 2 external separate applications

Usually now they try to write as an external application. In this case, the external application relies on the universal API of integrated applications.

If the integrated applications do not have enough concepts for integrations, then the applications also need to be improved. In fact, this is the addition of new features. For example, one of the systems is missing some critical field.

The integration transport protocol can be distinguished:

  • HTTP
  • files via NFS
  • files via FTP
  • files via email
  • database connection
  • event exchange bus
  • …

And ways to serialize data:

  • HTTP form
  • JSON
  • XML
  • Tables and fields in the SQL database
  • …

The main thing when choosing is maximum typing for the serialization method and reliability for transport.

Separately, you need to discuss the volume and frequency of data updates in order to know about the non-functional requirements for the integration application.

Naturally, in integrations it is extremely important to understand what to do with erroneous data (to dismiss the entire block or individual records as separate records after manual correction, re-upload them to the integration) and set up good monitoring to find out about problems as quickly as possible.

The integration flow is the receipt (or sending) of records of a certain type with the return of information about successful or rejected records. Usually the entries are more or less specific. For example, an Address, but not an Address, then an Invoice (in this case, there may be an Invoice with an Address - this is normal). It is usually a unit of work and evaluation.

My preferences:

  • universal integration API in your application
  • a separate integration application for a specific integration
  • usually all or many integration threads within an integration application
  • the most stringent checks on the validity of the data
  • errors at the level of an individual record
  • if technically possible, it is better to integrate through the database, because there is good typing, transactions, etc., but then how lucky are they with the other side and what are they ready for
  • asynchronous approach: when the sending party does not immediately wait for a response about processing the sent packet, but how much is needed