Click to learn more about author Brendan Peterson.

The fictional power to quickly recover and regenerate from an otherwise fatal injury never ceases to fascinate. Look no further than the success of movie franchises like X-Men and the Terminator as proof.

In integration development, the concept of ‘self-healing’ is no less appealing. If integrations between systems like CRM to ERP to marketing automation could sense potential failures, recover easily from errors and adapt on the fly to avoid mistakes altogether, everyone would win. Information would not only flow more freely through a company, but developers would also reduce the flow of menial tasks. The latter is precisely what technologies like Machine Learning and Artificial Intelligence hold up as their largest value to integration.

Interestingly, the idea of hardened integration that can recognize when it is not working correctly and make the necessary changes to restore itself to normal is not the stuff of science fiction. With proper inputs from the developers who build them, and the community that runs them, integrations that seemingly heal themselves are not difficult to achieve, if you keep a few basic rules in mind.

Let Data Know What’s Happening Around It

Every integration consists of multiple data flows, with one stream often contingent on information from another or vice versa. As a best practice, code the integration so that every stream of data knows about all others that are feeding into the integration.

For example, in an eCommerce processing there are always customers who create a new account during the same session in which they place an order. Create a rule ahead of time that tells the integration if it processes order information before a customer’s account information, in knows it needs to locate the parent account data. The path to self-healing starts with fixing errors as they are encountered, right then and there, and telling the integration what to do next time.

Rely on Try-Catch

The issue of ‘orphaned data,’ or data that has no parent, is real. Let’s say an eCommerce customer orders multiple products at once, but one of the products is either out of stock or the fulfillment system rejects the item for some other reason. For customer service purposes, the system should already be designed to process a shipment containing the products that are available, rather than holding it up because a single item is missing. Left to its own devices, the integration may leave that data stranded such that, when the product becomes available the system thinks it owes the customer two of it, or it believes the item had already shipped even though it didn’t.

With try-catch statements, developers can harden integrations to spot rejected data in real time, and clean it out of the system. Try-catch is not typically a pre-packaged part of an integration build; the integration won’t inherently know what to do, and you have to tell it explicitly to look out for anticipated failures.

Teach the Integration to Pause for Errors

Every data flow is likely to carry its own set of unique inaccuracies, so integrations need to be kept from going on to the next step when such errors occur. This equates to adding logic that informs the integration about baseline pieces of data that must be present before it moves on to the next step. In effect, you teach it a) to monitor processes that are most likely to have missing data, and b) where to go find that data when it isn’t there.

A classic example of this situation plays out within inventory control systems, typically whenever a new stock keeping unit (SKU) code gets added. New SKUs are notorious for entering the system with missing data fields such as item location, warehouse, default currency, etc., and this interrupts the integration. Simply design the integration to first review every SKU, determine whether it is a new SKU, double-check for all the necessary data, and go find any missing data.

Anyone who creates integrations for a living understands the frustration that comes from one missing record producing a cascade of painful downstream effects. Indeed, this probably explains why we’re seeing so much hype for ‘AI-infused’ integration. Anything to cut down on the endless flow of error messages is a welcome change.

The good news is, you really don’t have to place your bets with machine learning systems that may still be ironing out the wrinkles. If you capture guidance from every mistake, and leverage lessons that are published every day in the integration development community, not only can you can be your own AI, but in an IT environment that’s becoming more and more shaped by DevOps efficiency, it adds a certain release valve.