The word integration is thrown around so often that it can seem meaningless. Wave a magic wand, and integration happens. If only it were so easy.
Getting applications to talk to each other can start simple, but as the volume and rate of data increases, integration techniques are stress tested. At this stage, selecting the right approach is critical. The Integrator’s Playbook works to highlight ways that integration can be accomplished.
In this installment, we dive into user emulation and adaptors. Both have features that can make integrations possible where other technologies and tactics fail. Yet, they also have pitfalls that require careful thought before selecting them as the integration method of choice.
User Emulation is a broad catch-all category for any system that will interface with a system as stand-in for a user. Some common user emulation technologies include:
Terminal emulation that will interact directly with older terminal interface systems
Screen scraping that is commonly used to retrieve data from web pages
Robotic process automation (RPA) systems that will interface directly with an application’s graphical user interface
These platforms can be costly to implement and run the risk of failure each time a source system is updated. They are also problematic when working with larger volumes of data. User emulation systems are better suited to transactional interactions with source systems, akin to what a web application programming interface (API) will provide.
User emulation systems are best when an ongoing automated interface to a system is needed, and when existing integrations are either limited or non-existent. Given the choice between user emulation and an API, choose an API.
(See our first Integrator’s Playbook post to learn more about APIs).
An adaptor is an installed application that resides next to the source application. It uses a system software development kit (SDK) and extends an integration point. This integration point can be either web-based or a data access location. An adaptor is effectively an add-on integration to an existing platform.
To develop an adaptor, the source application would need to be extendable by design (which is often not the case on legacy systems) and you would need to be able to install the application where it can access the source system, potentially on the same physical device.
With so many variables in play to develop an adaptor, it is probably not the first integration choice. Limit this option to systems that explicitly provide the ability to use an SDK and when better integration options are not available.
Adapters and user emulation are functional integration methods but best used when other options have been considered first. In our next installment of the Integrator’s Playbook, we will review ways to migrate data when more sophisticated approaches are not feasible.