Introduction to the XQTING Integration engine

A world of APIs

In today’s world, it’s all about digitizing the workplace. For every aspect of the business, there is a piece of software that can improve and automate the old process that typically used more paper, more people and more time than the digital version (if not, there is no point in using software). By using the software, it does not only get faster, but paper and location becomes less important, which means we can execute the task anywhere and at any time when we connect to the office.

It is however also a fact that there is no single piece of software that completely covers your entire business. For every aspect of the business, we have a specific application that does the job best: accounting software, telephony/communication software, CAD software, planning, office documents… all of them have there own application, and for each of them many vendors exist, each having the unique features that make them the best option for your specific business. This is normal; there is also not “one car that does everything” or “one bike that fits all purposes”.

So as an organization, we often end up with many software applications that most of the time do not cooperate and exchange information automatically. This is no surprise, after all, there are so many applications it is practically impossible for a software vendor to integrate all other software.

Different systems hold similar information that require separate updates

To overcome these software islands, and offer the customer the option to automate processes by connecting different applications, the (only maintainable/profitable) solution offered by the different software vendors is an API (Application Programming Interface): it allows another application to programmatically retrieve and store information.

So in today’s world, more or less all applications, on-premise, hosted, or in the cloud deliver an API that allows integration with other software… and thus the problem is solved? No.

Each application has it’s own idea on what an employee is

In reality, the availability of an API alone doesn’t solve the problem of integrating different applications, because each of the APIs has their own idea of how the world should look like, and, the data one application exposes cannot be imported by another application. Sure, a couple of the world’s biggest platforms have a direct connection to each other, but, for most of the applications, a certain transformation is to be done on the data structure, or maybe even on the protocol both applications use to exchange data. Not all applications are written with today’s new standards like REST and OData. Some line of business applications were even written before the internet and the cloud was everywhere, but still serve their purpose very well, but, also have very old ways for integrating it. As such, to integrate all of these APIs… we need software again. The software needed here is typically an application delivered by a “system integrator”, and this software is most of the time very specific for one particular company that has a (almost unique) combination of applications.

System integration module mapping both models to automate employee creation

Since we have different applications, often more than two, the system integration software will not only “transform” the data or protocol, but also implement some type of “workflow”. This workflow corresponds with the business process it is automating.

Transforming, and conditionally updating another system as part of the workflow

Traditional API integration solutions

System integration solutions usually come in two flavors:

  • Tailor made from scratch. A new application or series of applications (often called services) is created for the situation at hand. A software development team is brought in place to develop the integration. This is a very code intensive solution. Pro and contra are obvious: it’s tailor made and the customer can literally ask for anything, but, software development is expensive and takes time. In some scenario’s, enterprise service buses are used as foundation, and though these save time for development, they are reasonably complex and have a license cost as well.
  • Using a higher level workflow solution like Microsoft Power Automate, Zapier, IFTTT, and tools alike, which are often hosted in the cloud. These are low code (or no code) solutions which can often be implemented by more business oriented people. As such, they are less costly, and faster to set up. On the downside, they usually only support very simple scenarios and provide less connectivity (usually only connections with well known cloud platforms are available out of the box). So if you need to support on-premise LoB applications, with potentially older interfaces, or integrations via file system or direct database access, these platforms cannot provide a solution. Also, if you need to implement a small part of “logic”, maybe only ten lines of code, these platforms can no longer help you.

Note: it is not our intention here to have an in-depth discussion about the pro and cons of each of the above methods.

The XQTING Integration Engine

The XQTING Integration Engine (or XQi Engine) is build as a golden mean between these two solutions:

  • It avoids tedious and time consuming (and thus costly for the customer) code that is needed to start a solution from scratch. It offers a series of basic modules out of the box that can be used for most common situations where APIs have to be bound together in a workflow.
Get a head start and avoid start from scratch
  • The code needed to build a workflow is minimal and very easy to learn. It is based on Javascript, simple and well known by most people who have some experience in computing. This makes it simple to create a flow, but, never limits the user if a little bit, or more, code is needed for a certain part of the flow.
  • It is a product that can be installed and deployed in minutes, and, can be installed on-premise, in a hosted or in a cloud environment, or a combination of these. It runs directly on a Windows or Linux server, or, can run as a docker container.
  • Solutions based on the XQi Engine can integrate your older on-premise LoB application on-premise, potentially using old interfaces such a files dumped into directory, direct DB access, FTP, … and combine them with modern REST interfaces, just to give an example. And all of this is done using a simple piece of javascript that expresses the connections between the different modules and transforms the data.
The engine supports “old” systems, where files and direct DB connections are needed
  • It has simple licensing scheme, and pricing is very attractive compared to other on-premise enterprise service bus solutions, so it brings in a lot value which results in an extremely low ROI.
  • It is continuously maintained and extended by our development team for specific applications so that in the future it can simplify integrations even more. All our experience with integrating complex applications is brought into the engine’s power.
  • At all times it has some standard basic REST, SQL, file and other modules, that provide a solution to your problem no matter the application you like to integrate.

Though the work of the engine is most of the time done in on the server back-end, where you cannot see it, the engine comes with a user friendly web interface that allows you to quickly manage, monitor and adjust the process(es) executed by the engine.

An easy web interface enables complete management of the engine, including script editing

One thought on “Introduction to the XQTING Integration engine

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.