When someone using your mobile cloud app begins a transaction and communications is unexpectedly lost, what happens on both the device and server sides when that break is detected? And what actions follow when communications is restored, likely in a completely new session? These are important questions whether your app is operating in the financial, retail, or services industries.
This boils down to well-crafted specifications from a competent business systems analyst coded by an experienced developer in a clear, understandable way that holds up to extensive QA scenario testing and subsequent audit scrutiny. No one said it would be easy — that’s why up to 80% of the code in a typical application may be solely for exception handling.
It’s akin to a multiple-choice question with no right or wrong answer: cancel, complete, or suspend.
When a cloud session is interrupted, do you cancel an in-progress transaction? If yes, and that’s happening on the server side, you’ve got to do store-and-forward, eventually getting that cancellation to the mobile app to maintain end-to-end synchronization. Maybe your server side also needs to generate an e-mail or text message so the user knows what happened and what action ensued. Of course, no communications means the message might also be subject to delay. And, your app is logging all of this, right?
Perhaps, instead, the transaction gets processed and posted. If that’s the case, it might be happening without immediate confirmation to the user. Maybe that’s ok for a 99-cent music download, but, if the transaction is an application for a mortgage, for scheduling medical tests, purchasing airline tickets, or, to think more industrially, something that impacts a factory-floor production line, there’s much more at stake.
The third alternative is to suspend the transaction and wait for the user to re-appear under a new session ID, whereupon the transaction can presumably resume. This state that lies somewhere between cancel and complete may be the most complicated of all. Was the product deducted from the available inventory database? Was the payment portion transmitted to the third-party credit card processor? Was a pick ticket generated? There’s the issue of databases that may not know the correct record-locking states. And what if the user doesn’t re-appear within a specified time frame? It can get very messy very quickly.
Journaling and logging are essential components of any transaction-based system, but their true value may be more in post-mortem by a team of auditors than in dissecting the complexities and permutations of an interrupted event in real time. That was fine decades ago for nightly batch processing, but in today’s cloud age of expected instant results, users can’t — or won’t — wait.
Finally, there’s perception. Does the user blame the communications carrier or your app for the snafu? It takes only a moment for an angry customer to blast your app and company on social media, even though neither may be at fault.
What’s your philosophy when it comes to transactionus interruptus? What happens on your mobile app and on the server side? And how do you get the two sides back in sync? Tell us, we’d like to hear from you.