The #1 Fastest Way to Scare a Business User

The #1 Fastest Way to Scare a Business User

Programmers, have you ever wondered what the fastest way to scare a business user is? It’s easy – just put a breakpoint in your code so that when someone uses it, the program stops and reverts back to code level.
This is a surefire way to freak out business users, SAP implementers and even SAP authorizations users. From our experience, there’s nothing scarier for a non-programmer than to think their software is “broken.”

Leaving Breakpoints in Code That Goes to a Production Environment is a Programming Sin

This is wrong from both a business perspective and a security point of view.

From a business perspective, putting raw code in front of a business user will usually result in extreme confusion. The user will ultimately wind up calling helpdesk and spend time going back and forth with tech support to get a solution, delaying his job and causing unnecessary frustration.

From a security point of view, accessing the Debugger (in other words, the “code”) in the middle of a program run allows the user to change values in the code and then continue the run. This can easily be used to commit fraud.

To lower the chance of fraud, make sure that no business users have the ability to access the Debugger in a production environment, and carefully control this authorization. Optimally, almost no users should have this authorization and debugging codes in production should only be performed using an “emergency access” process.

Adding Transporting Controls and Alerts

In addition to controlling your debugging authorizations, you should verify that any program entering the production system does not include breakpoints and keep an eye on points of any kind.

This can be done with the standard SAP Code Inspector (with limited alerting and workflow capabilities) or by implementing a dedicated tool for security and authorizations. Either way, this process should block statements such as “BREAK-POINT,” “BREAK JOHN” (for a developer named John) and similar types (see your SAP documentation for a complete list of commands).

What Should You Do If Your SAP Screen Suddenly Displays Code?

(You can print this section and hang it above your desk, so people don’t annoy you with this question)

If you’re working on something inside SAP and your screen suddenly displays code – don’t panic. Just do the following:

First, take a screenshot of your screen so you can show tech support where you were stopped. Just hit the PrntScr button (in Windows), compose an email to support and attach the screenshot you just captured.

Then, write a brief description of what you were doing when this occurred, with as many details you can remember. For example, “I created a purchase order from type ZHLR in company code 1000. When I tried to change the terms, the screen turned to code.”

Finally, locate the “Continue (F8)” button and click it. This should continue the program run and – if no other breakpoints are present – everything should continue normally.

SAP Debugger: continue program flow - no special SAP authorizations are required

Have a bad experience you’d like to share?

We always love to hear programming and user horror stories. Write us an email with a story, concern or question, and we’ll be glad to chat about it.

Yoav Michaeli

Yoav Michaeli joined Xpandion in 2008 as a team leader, and in 2010 Mr. Michaeli began managing the entire Research & Development group of the company. Prior to joining Xpandion, Mr. Michaeli served in an elite technological unit of the Israeli Defense Forces as a team leader for various key military projects. Among other achievements, he was instrumental in pioneering the use of advanced .NET technologies for large scale distributed systems. Mr. Michaeli is an expert in programming, agile development, application security and specialized programming techniques.