When you’re designing and implementing a solution don’t forget there’s more to it than the “happy path.”
It’s going to break.
It’s a certainty that at some point something will break. You’ll get a call from users asking why they’re not getting output, or not getting the output they expect. How will you resolve this?
Leave yourself a trail of breadcrumbs.
Have you saved logs and archives of inputs and outputs? These can be invaluable in investigation and recovery, but don’t forget to secure any sensitive data! Ideally they should be on a separate write only system. Should the main system be compromised you can trust the logs to help determine the impact.
Since BizTalk uses XML and not JSON don’t forget you can embed comments in your messages. Comments are ignored by automated processes, but a comment in an archived output explaining the choices it made can be a life saver. Don’t forget to include the inputs. If data is changed after a process runs it may be nearly impossible to understand what happened after the fact.
What you didn’t check can kill you
At one employer a dev lead I worked for never considered this. He was updating a query that added a year to a customer’s subscription ending date if they met the right qualifications during the month end processing.
He commented out the SQL WHERE clause during his testing and forgot to restore it when producing the production version. Net result was tens of thousands of subscribers received an additional year of service they weren’t qualified for.
He caught it immediately when the monthly process ran and tried to restore to the latest backup. He found out there were no backups. The database team that handled backups informed us we had the level of service that included backups, but we did NOT have the level of service that ensure the backups actually succeeded. The SQL server agent running the backup code wasn’t running for weeks so the backups we did have were significantly out of date.
How did this happen? We had processes in place.
He tested his code to ensure those who deserved another year got another year. He did NOT test the inverse. That those who did NOT deserve another year did NOT get it. He could have saved his career with that one test.
The QA department checking his work failed in the same way. They created a database of deserving clients and all of them got their addition year of service. There were no records for clients that didn’t meet the criteria. QA PASS.
Test for failures too!
Create tests for more code paths. Ideally keep these tests so other developers can run them and have better assurance they didn’t accidentally break code they didn’t change.
Hopefully now you’re forewarned you’ll not fall prey to this kind of mistake.
Happy coding!
Jay
Non maskable interrupt 