Essentially integrations are pieces of software. Depending on the integration technology you’re using, your integrations may look different from a traditional software program, but that’s what they still are, even if there’s some abstraction layer in between. Some integrations are more complex than others, and as with all software, complexity tends to create error situations that are difficult to analyze and resolve, or debug and bugfix.
Mappings
The first thing that comes to mind when you talk about complex B2B integrations, is mappings. I don’t know a single integration architect who likes to do mapping, but it’s something that you just must do. Quite often there is not a standard ready-made mapping that you can use, and even if there is, one system or the other may be using a standardized message format, but applying some of their own processing logic. And then you need to do mapping manually. Too often this process involves educated guesses because documentation is poor and you have only a few samples to work on. This causes errors in and after testing, which you need to be able to solve quickly.
Different formats and different protocols
It would be so easy if everyone used at least the same file formats and transfer protocols to do integrations. But no, you need to receive EDIFACT over FTP and send out XML via AS2. Or you get some enrichment data periodically from an Excel file in a file system on some server, then receive an XML file over HTTP and need to combine data from both to a JSON payload that’s then encrypted using a proprietary combination of the algorithm. Sometimes you even need to split multiple levels of data into separate entities, for example when you get a shipment containing multiple containers containing multiple cargo items in one EDIFACT file and then you need to push these entities to some REST API separately and in the correct sequence, linking the created objects together.
B2B integrations are nasty projects
And I’m not even exaggerating, in real life B2B integrations are often nasty projects. Sure, there are easy cases too, but the most time you spend with these monsters. In many cases neither of the parties that you’re integrating fully understands what their system is doing, or just don’t have the resources to support you, so you need to do some development by trial and error.
That’s why you need an iPaaS system that’s designed to support the development work you’re doing for the integration, as well as it’s designed to help to monitor and manage the integrations you have already in production. Every time you make a change, you want to be able to easily test the changes without having to jump through too many loops.
Developing integrations with iPaaS is simple
Open your VPN to the customer, start a deployment, get a cup of coffee, test, wait, realize it didn’t work, and start over trying to figure what went wrong in the integration black hole? No, just use the iPaaS UI in your web browser, start the process, monitor how it progresses, see what went wrong, fix it, repeat. You want a system that allows you to stay focused on the task at hand, not in orchestrating the whole testing process around it each time you want to try how it works.
And the same applies to monitoring production processes too. Errors will happen in production every now and then, and if your integration platform can provide the same debugging experience for every production error as you got in the development phase too, solving these problems is a lot easier. You don’t need to search for the payloads, download them to your computer while getting the project running in your IDE. Just use the same tools as you did before, it’s all there in the cloud just waiting for you.
Complex integrations are just more complex pieces of software, than the straight-forward integrations. They need more work, that’s all. And when you need to work more, you need tools that handle the simple things, so you can focus on solving the more difficult issues.
For specs on our iPaaS, download the product sheet:
