Improved Alerts in the Corevist App

“Our clients should never ask us for status on a task/deliverable that we own.”

–From the Core of Corevist

Being proactive is an expected behavior for members of the Corevist team. That’s the driver behind our new Corevist Quarterly Release Cycle, as well as the Alerts and Notifications enhancement to the upcoming Q2 2017 release of Corevist’s eCommerce suite.

The problem: You can’t anticipate all problems

Let’s face it, websites aren’t omniscient.  Despite rigorous testing by our clients, the 150+ automated test scripts, and the 100 regression testing scenarios which we run on each and every client, unexpected problems arise during the daily use of our software.

Some issues are rather innocuous, such as a user trying to access a page after being logged out over the weekend. Other issues should immediately become support tickets in our support portal–such as when a user submits an order with an invalid email address in his user profile.

The solution: Intelligent alerts in our Q2 2017 release

Corevist is dedicated to being the first to know about any problems that arise on our clients’ websites. Our goal is to notify our clients that a problem has occurred and been fixed before they even know about it.

To that end, we recently added enhancements to our core application which capture and route alerts when exceptions occur. The primary outlet for alerts is the automatic creation of a ticket in the Corevist Support Portal. We believe that ticketing is the best way to track problems and their resolutions while bringing the client into the process if necessary.

In addition, as a form of redundancy, we can also route notifications to the following locations:

• The Exceptions channel in Slack–this automation sends us an alert in our internal messaging app. It helps us jump on a problem fast.
• Airbrake, an exception reporting service which provides metrics and analytics
• Good old-fashioned email

Alerts are great… but what happens after they’re generated?

It’s one thing to notify people. It’s another thing to provide the critical information that helps our engineers understand the issue more quickly. One of the best tools we’ve implemented is Fullstory. Fullstory virtually records every user’s action on the Corevist website. This allows our support team to travel back in time and watch each click of the user’s mouse. With the new release, each notification will include a direct link to the user’s session in Fullstory so our support engineers can instantly “replay the videotape” of what went wrong.

The next bit of critical information included in the notifications is a direct link to the web server logs of the user’s session. This will include important details such as the inputs and outputs of the SAP function calls. Rather than searching or scanning, support engineers now have a direct link to the start of a user’s session with all of the glorious data passed back and forth.

What kinds of problems will generate an alert?

The list is pretty substantial. Corevist’s investment in this enhancement will help our engineers spend less time researching issues and more time improving our product. It will also place helpful information into the hands of our clients as soon as any customer is having trouble on the website.

Here are examples of the kinds of problems that will generate an alert. Not all of these items are directly visible to our clients, but each one of them is important to us:

• An exception thrown by SAP during a remote function call due to something like a syntax error or lacking server resources.
• The “We’re sorry, something went wrong” page, typically caused by unexpected data such as a material that was setup with an incorrect item category group. Or, a user may have performed an unexpected action such as pasting odd characters, such as line breaks or tabs, into an input field.
• “Invalid token”: This can be a user simply trying to access a page after having been logged out by the server. It can also be an exception during a request from Magento. For example, a buyer might go home for the weekend and come back to his computer to continue shopping on the website. For security reasons, users are normally locked out after 24 hours. Our application would receive the token in the user’s request and see that it is no longer valid.
• SMTP connection issue when our client’s mail server is unavailable or credentials changed. The root cause of the alert is either a user error or a change in the environment.
• An invalid email address was entered into the shopping cart or a user’s email address was incorrectly maintained.
• SAP timeout during any RFC that updates SAP data: customer master, order create, order change, pay invoices.
• SAP timeout for non-update transactions.
• Exceptions that occur during a background job task such as our B2C connector which pushes SAP order status back to Magento
  

The Takeaway

If there’s one thing we’ve learned in 300,000 hours of SAP eCommerce experience, it’s that no two SAP companies are alike. Everyone needs alerts, but no one needs quite the same mix. We’re putting the foundations in place for alerts that are tailored to each client’s particular needs. We’re thrilled to provide this value to our clients, and we look forward to working with you on the particulars.