This blog post is an in depth look into the area of operability when designing and building end-to-end integrations and APIs. For those who wish to gain more knowledge about this and other areas of best-practises for integrations, please visit www.certifiedintegrator.com.
When designing and building an integration solution, a key factor is to address operability in a structured manner, not only to deliver a viable service - but to also deliver an efficient and easily operated service. The term operability in this circumstance refers to the ability for support and operations staff to handle unexpected or unwanted execution of the integration at hand. No matter how much effort goes into design and coding, there will always be scenarios giving unexpected results that needs handling.
A quality delivery of an integration service will encompass a solution which addresses all requested functions, in effect giving the system owners a service that fulfills all business needs. However, true excellence in a delivery of an integration service can only be achieved when there is also a viable solution for an easy, fast and intuitive handling of unexpected executions - either as automated responses, but most often also as manual possibilities to handle a set of actions to make the integration service deliver the desired results and remedy any faulty results.
In order to be able to achieve these integration services of excellence, some prerequisites needs to be in place. I will only briefly mention them here as this blog post has its focus on operability, but I will probably return to these other areas in later posts, if there’s a interest.
Starting from the top, a unique identifier for all end-to-end integrations or APIs is essential, giving the means to build a proper monitoring, with full traceability and logging of events and non-events. It might seem simple and self-evident, but the unique identifiers value cannot be overestimated in this perspective. For those going to work on a solution where only one integration will “ever be needed”, thus making a unique identifier seem to be obsolete, I ask one thing - when have you ever received a set requirements from the business side that were not subject to alteration before the final deploy?
Be on watch
With the unique identifier in place, ability to build a monitoring of all events in the integration is achievable. The next step is to secure that this monitoring is robust and also it’s imperative that this monitoring is accessible through external channels, enabling logging and traceability regardless of the health of the integration services or the server where the deployables are located.
The logging should be built to catch both various activities as well as certain key inactivities. Here it’s important to really get close to the business side of the concerned systems, to really understand the various reasons WHY certain functionality of the integration service is requested by the business. By achieving this more intimate understanding of the business process that the integration service shall uphold and support, it’s easier for the developer of the integration services to deduce potential error scenarios and - with a healthy dose of imagination - better foresee what the key issues that will occur on a frequent basis will be.
Be friends with Ops
After briefly covering these prerequisites for operability, let’s dig in to the subject proper. While the requirements for a new integration normally comes from the business side, like a system owner or a system administrator, the requirements for operability has an alternate source. The place to go is first Operations and second Support. Talking with Operations will already have occurred to cover the above prerequisites - if not, you’re in trouble - but return here to have a chat about the existing integration landscape, or if that’s a blank, the landscape you just started to build…
You can be sure that Operations staff will have a list for you with need-to-haves and some nice-to-haves when it comes to various basic functionality they wish to have in place for give them a decent situation at work those days when nothing seems to be working properly.
The same goes for Support, this is the first line of defence - when those alarms goes off and it’s only a matter of minutes until The Manager calls - they really want to have some good tools at hand.
Naturally these lists are intimately connected to the business requirements for the actual functions of the integration itself, even if a few will be more generic in nature. If you feel like a parrot, discovering that you pretty much repeat what you’ve heard in that Important Meeting at the very beginning of the whole project where Everybody was invited - learn your lesson! Always demand that Operations and Support are present at this first Important Meeting, since these all-important gals and guys always seems to be forgotten when the Everybody-list is made, first you don’t need to feel like parrot, second it’s suddenly not your responsibility anymore to make sure that Operations and Support really understand what Business require, it stays with Business - where it belongs!
So after this little tip, let’s look at some common operability items that you will be sure to encounter:
Have a retry policy
The Retry - basically this is a trigger of the actual integration. It’s manual, giving Support a tool to execute the integration, if nothing has happened when it was supposed to do so, or to run the integration ahead of the scheduled time for some particular reason. It’s also an excellent tool for Operations or Second Line(often the same)to use when working with more advanced troubleshooting to get fresh log data of the issue at hand by triggering the integration and thereby recreating the issue.
Often the Retry is also built-in as an automated response for failures to execute the integration for various reasons, inability to reach a specified source, not receiving confirmation on execution etc.
Get rid of problems
The De-Queueing - the means to clear a queue of actions being stacked awaiting execution. Many integrations are designed to stack executions in a queue, for example as a means to handle temporary high loads as a crude scaling of the integration, to handle intermittent connectivity etc. Being able to manually clear this queue is a powerful yet simple tool to use when something has gone amiss.
One reason to De-Queue would be to remove stacked triggers that will be executed when not wished. Another would be to erase actual data that for some reason is faulty and would cause damage if executed. When a target source for data has become unavailable for a prolonged period, business often has a fallback, exporting the data to a file and manually load it to the target system. Being able to clear that queue will suddenly be an absolute necessity to avoid duplicate data.
A complete list of operability tools is impossible to give, but I’ll mention a few more to point you in the general direction.
Call up the last sent message content
Call up the date/time of the last successful execution
List performed executions for given time period
List all sent messages for given time period
Call up number of stacked messages in a queue
Send test shot for whole or partial integration, without actual data content
To summarise this blog post, achieving proper operability for an integration is really imperative if you wish to go from delivering good to delivering excellent. By making sure that Support and Operations are included in the delivery project from day one, you make good friends with the pillars of the IT department in charge of operating your integration and also increase your chances to deliver a truly excellent service to the business. For those who wish to gain more knowledge about this and other areas of best-practises for integrations, please visit www.certifiedintegrator.com or register to our upcoming webinar or register for an upcoming one-day-course with the opportunity to be certified. https://www.certifiedintegrator.com/events.