Integration Fixes and Enhancements – The Gas Company Principle.

25 Years ago I went up to my parents house, a contractor working on the house next door was digging a trench for a utility conduit and hit the gas line on my parents property.

The gas company showed up shortly after. They didn’t just fix the leak, they dug up the front yard and replaced the entire gas line from the street to the house – meter and all.

The gas line was probably 30 years old, the gas meter was inside the house and the new code was they needed to be placed outside the house. To the gas company it just made more sense to redo everything vs. plugging the leak only to have to keep coming back.

Integrations can become like an old gas line, last minute changes during an implementation to meet a go-live deadline, an acquisition of another company that results in new integrations or many changes to existing integrations. As time goes on many changes can lead to increased integration failures (or even issues that don’t cause failures that go unnoticed), then when the dust settles there’s an enhancement request, you open the integration in Studio and don’t even know where to start.

I’ve been coding for over 20 years and sometimes it’s more efficient to rebuild from scratch just like replacing the gas line. However, there are other things that can be gained. Maybe there is new functionality available, new versions of web services, processing improvements, etc.

But how do you know when to start over?

Do you feel that by making the change or fix it may break other functionality?

– Do you dread every time a change is requested for this particular integration?

– Are you spending a lot of time trying to follow the logic of the process and not sure why certain things are being done?

– Is the integration something that is failing often or generating a lot of support tickets?

– Have procedures been developed manually because changes couldn’t be made to the integration? i.e. manual spreadsheets sent to a 3rd party vendor because the integration isn’t sending it?

But why do it over? It’s just going to get that way again?

Not true.

This is where knowledge and experience come in. Keep things simple, comment where necessary and for Studio Integrations – they are a work of art. Neatness counts.

In The Real World
We saw a great example of this recently with an integration that looked very simple on the surface but contained layers of logic in calculated fields. A simple change would involve many changes to what essentially was a “House of Cards”.

Did this integration need to be rebuilt?
Let’s go over the checklist to find out.

– Do you feel that by making the change or fix it may break other functionality? YES

– Do you dread every time a change is requested for this particular integration? YES

– Is the integration something that is failing often or generating a lot of support tickets? YES

– Are you spending a lot of time trying to follow the logic of the process and not sure why certain things are being done? YES

– Have procedures been developed manually because changes couldn’t be made to the integration? i.e. manual spreadsheets sent to a 3rd party vendor because the integration isn’t sending it? YES

The final solution was to take the logic contained in one report field and break it out into what became a customizable “Engine”. A step was added to determine what type of record needed to be processed and sent it to a separate function to process.

Why was this the right solution?
– Any fixes for a specific record type or enhancement would only need to be done in that section.

– New logic could be added very easily.

– Each section had comments which defined the processing rules. Each record processed was also logged with details including all data fields of the record.

– Records that were bypassed were sent to a “No-Action” section and logged. Prior processing simply did not report on these records. In the case it should have been processed now the data and a log entry are available to aid in support.

– Added a validation mode that would log everything, just not update the employee. This was invaluable for testing.

Those integrations built at go-live aren’t getting any younger. They could use a tune up but where do you begin?

Sometimes a review of the integration and a few changes are all that’s needed. Other times maybe a complete rebuild is in order, but does it make sense to do so?