Existing Platform
A customer with an eCommerce site approached us with a frustrating situation: their shoppers were occasionally having issues during the checkout process. When this issue was reported to the hosting provider, shopping cart vendor and shopping cart plugin authors, all declared that the issue wasn’t due to their software and they were unable to provide further assistance. Ideas2Executables worked with the customer to cut through this blame game and diagnose and fix the underlying issue.
The first step in deriving a solution to this check-out bug was to determine a method for recreating the issue. Fortunately, the customer had already determined this and setup a product that we could purchase that triggered the issue. When there’s an issue with your software platform you may feel powerless to fix it. However, being able to reliably recreate the issue is an invaluable step you can assist with, regardless of who undertakes the final fix.
The second step in building out a solution was to decide where the problem should be debugged. Broadly, you have two choices: either on the production system itself or in a cloned-development environment. Working on the production system means less setup time and allows the developer fixing the issue to begin debugging immediately. However, working on a production system risks causing downtime or other issues that may impact real customers. If your software is in active use and time allows, setting up a cloned-development environment is a much lower risk option for setting up an environment to fix the issue.
A cloned development environment is just what it sounds like. An isolated series of servers and software in which to debug the issue that is created by cloning your production system. Your hosting provider may assist with setting this up, or the developer debugging the issue may opt to do this.
Working with a cloned environment allows a programmer to work without impacting production systems. If a programming mistake is made that causes orders to be deleted, for example, the production system isn’t damaged. However, setting up a new environment takes additional time and cost, which may not be in your budget. Also, it’s possible that when the production environment is cloned, the bug no longer shows up. If this is the case, then this fact alone serves as an important clue to help understand the bug.
The customer who contacted us to fix the issue with their eCommerce site opted to have us debug the issue in production. They made this decision because sales were so severely impacted by the bug that it was reasonable to prioritize quickly fixing the issue over negatively impacting shoppers.
Our customer was utilizing a robust shopping cart vendor with a number of additional plugins. The result was an overwhelming amount of code where the bug could be hiding. To narrow down where the issue could be, we developed an auditing facility that let us see precisely which areas of the code were in use during the checkout process. This allowed us to focus in on the relevant blocks of code, and ignore thousands of lines that weren’t relevant. This auditing facility served as sort of an x-ray vision: we could debug the behind the scenes processes, but to shoppers continuing to checkout on the site, nothing was visible.
It was gratifying when we finally understood the issue that was causing the problem. When a customer starts shopping, their session is tagged with an order-number. During checkout, the cart details are turned into an order record. This temporarily assigned order-number is discarded, and a persistent and permanent order number is assigned.
This process was complex, but working well. The issue was the customer’s use of a plugin that was not cooperating with this process. The plugin utilized the original order number, but wasn’t being properly reset when the permanent order number was assigned.
We fixed the issue for the customer, and reported the bug and fix to the relevant shopping cart plugin author.
It took a few debugging sessions to resolve this situation, but ultimately, the bug was slain and the customer’s website returned to its former working status. The auditing framework we developed is still available to us should future issues arise. Most importantly, the customer has learned they have an advocate they can turn to whenever their site encounters an issue.
If you have questions about this Case Study, or how Ideas2Executables can you help you address a challenge in your own application, Contact Us. Or give us a call at (703) 688-3084.