In Software Engineering, System Integration “is the process of linking together different software applications, that can be spread across multiple computing system, to act as a coordinated whole”. (Definition found in Wikipedia [http://en.wikipedia.org/wiki/System_integration]). In its most basic form a System Integration is a software program that allows two or more disparate non-intercommunicating systems to communicate. A simple System Integration program is not a complicated task to complete. What is not so simple is designing and building a System Integration program to overcome all those worst case scenarios we encounter every day. Following are five tips to building a better System Integration program that can handle unexpected events.
Sounds simple enough, but the majority of system integrations I have seen during my career fail to do this simple important initial step. When you first read an incoming message from a System Integration, perform a certification routine on the message. You want to make sure the incoming message is exactly what is expected. Failing to perform this simple step may cause your System Integration to fail unexpectedly.
Retry … Retry … Retry
In real life things fail, so code accordingly. A normal developer codes to handle expected scenarios. A great developer codes to handle unexpected scenarios. The easiest way and least complicated routine to handle unexpected events are to retry your logic when it fails. That is, if your database connection is down, retry connecting before exiting your code. If you fail to obtain a network connection, retry before quitting. Word of advice … retry more than once, in a majority of cases this simple step solves a lot of problems.
If Failing … Alert
Every developer has the tools to know when their code fails (hint: try/catch). So, if your code is failing or behaves unexpectedly alert the administrator or yourself. By taking a proactive approach to system failures, problems can be diagnosed and fixed faster.
Yes, log everything. When a message was received. How the message was processed. What was the outcome of the transaction? Etc. Storage is so cheap and reusable these days that the costs to store log files for a couple of months are minuscule next to the cost of not fixing a bug in a timely manner because there is no sufficient data to find the cause of the bug.
Do Something with the Logs!
Mine your logs. Logs have so much useful information, transactions processed, processing time, incorrect messages, etc. Prepare weekly reports from the logs to find out peak processing times, number of incorrect messages, most used processes, etc. Then, use these data to enhance your System Integrations.
If you implement these five tips in your system integrations you will have developed software that can better handle unexpected events. Additionally, when the system integration fails you will know immediately what happened and will have sufficient data to fix the bug in no time.