Basis Engineers’ Ultimate Guide for SAP Debugging

I think that every Basis engineer and SAP developer will agree with me when I say:

It can be REALLY painful to find the root cause of an issue in a complex SAP system.

Troubleshooting or debugging is a cyclic continuous process typically applied to something that was working and suddenly stopped, its performance has degraded, or suddenly it provides the wrong data.

In this post, we’ll provide some tips and tricks on how to improve your SAP troubleshooting.

Identifying an SAP issue

The first problem, especially in SAP systems, is to know that you have a problem. Sure, you can wait for that frantic call when production stopped, or when the company can’t issue checks.

But the smart way is to be proactive and identify the problem before it spirals and become a major failure that affects critical aspects of the business.

In fact, in many cases, the biggest problem is even to know that there is a problem. Automating your daily monitors is a first step to help you free up time to focus on preventing issues and not wasting your time just to make sure things are working well.

Gather info on the problem and try to understand its source

Gathering info and trying to understand where is it coming from is typically the first step in troubleshooting SAP system issue. The initial focus is often on recent changes to the system or to the environment in which it exists. Some issues are fairly easy to find and having the Xandria’s Automated Change Detection and Change Tracking will give you a good first thread to start investigating.

Comparing the faulty system to one that doesn’t present these issues is another step. Xandria compares components, versions, and profiles)ensuring consistency between your systems.. This is something that will not be found with other tools, and is often held within spreadsheets that never get updated.

In fact, having complete visibility of the SAP system landscape inventory information at hand ( including Kernel version, Basis release version, component versions) is a great deal of help when it comes to searching SAP Notes (which is likely part of every troubleshooting process).

In this example you can see that there is a discrepancy between the development and production ABAP components versions. Which may cause some things that work in development, not to work properly in the production environment.

Reproducing an SAP issue

Basic best-practice of troubleshooting is that only reproducible problems can be reliably identified and resolved. Often a considerable amount of effort of the troubleshooting effort is placed on the ability to reproduce the problem.

Even in simple systems, the troubleshooter must always consider the possibility that there is more than one fault. Many problems only occur as a result of multiple failures or errors. This is particularly true of fault tolerant systems, or those with redundancies and standby. Adding redundancy, fault detection and failover is important to SAP overall system availability, but may also be subject to failure. Adding these complexities creates a troubleshooting nightmare.

More often than none a problem is more complicated to find, identifying and reproducing those pesky performance problems that only appear once in awhile becomes very hard. In order to help the detective work required to find the source of the problem, you can use a more focused monitor that will run together and more often, which will allow you to get better visibility on the behavior of a specific element.

Here is an example, finance asked why their accounting jobs run so long on Sundays. Using Xandria the Basis engineer easily identified this high batch activity at regular intervals and identify the source of the problem.

The Financial accounting jobs(FI jobs) were scheduled on the same time the database backup was running. Once this was discovered, resolving the issue was very simple and the accounting jobs have been scheduled to start 2 hours earlier.. The jobs are running much faster and the reports are ready for the team in the  morning.

Once located, obviously the next will be to create a fix or repair the problem, while this is a very important stage it is a subject for a separate blog post.

Test, Test, Test

There are many good tools for test automation as well as SAP built-in tools. In the testing process, you’ll need to make sure that:

◉ The fix you’ve created does what it suppose to do

◉ The fix you’ve created does what it suppose to do – in all relevant environments

◉ The fix you’ve created does what it suppose to do – and didn’t break anything else

◉ The fix you’ve created does what it suppose to do – for many users. The fact that it worked in the development environment for you, doesn’t guarantee that it will work for hundreds of users.

◉ The fix you’ve created does what it suppose to do – for every user. “No user would ever do that..” right, every user scenario even the least likely can happen in reality. Make sure your fix can withstand the most abusive users

Post-deployment SAP monitoring

More often than none problems that got fixed return and appear again. It happens either because the solution was not good enough or because people make changes in the system and forget to keep the fix.

Once you deploy a bug fix, create a monitor that will monitor both the

◉ Initial problem – to make sure it is fixed and it is not coming back

◉ If possible monitor the fix to make sure no one is making changes that may cause problems

Using Xandria when an issue is fixed, you create a monitor to track that specific performance indicator so that if that issue ever back you could find it before it spirals and even have a link to the relevant fix that that monitor is related to.

Future proof and long term maintenance

When John F. Kennedy said that “the time to repair the roof is while the sun is shining” in his State of the Union address, fixing SAP systems was probably the last thing on his mind. Yet his notion of preparing in advance to pre-empt tough times is something that can certainly be applied to the world of SAP management and monitoring.

As SAP systems grow and become more and more complex and critical to the organization, the need for fixing issues before the organization is experiencing a complete meltdown is crucial. A major failure in today’s extensive SAP use has a direct impact on internal and external customers, user satisfaction, trust, and loyalty.

Early indications also allow the Basis team and the developers to save costs, as it will not only prevent failures, it will allow the team to take care of issue during working hours – preventing after hour notifications and work.. When comparing the use of Xandria for automated daily and real-time monitoring vs. Solution Manager (SolMan) teams can expect a 25% saved hours and  shorten time to resolution.

How do I setup proactive SAP monitors?

It is very easy to drown in the sea of monitors and notifications. You need to know your important KPIs and create smart monitors that will provide you an early indication you’ll be able to be proactive.

The good news are that Xandria comes with over 95% of what you’ll most likely need out-of-the-box with best practice auto checks and thresholds.

One efficient way is to combine multiple monitors to one ‘smart’ monitor. This way a notification will not be sent only because one parameter spiked, but instead you can combine variety of indicators (hardware resources, jobs performance, results of SQL query etc) as well as frequency of occurrence, or length of time it happens and only then be notified.

Below you can see an example of a dashboard which provides an outline of  the overall status and capacity growth of the systems while showing real-time view of the system performance.