Less than a year ago, I managed the Compliance Calibrator implementation at a Fortune 200 company and submitted several messages a month to SAP GRC Support. The more issues I had, the more frustrated I became as GRC Support seemed to ask the same questions over and over again. Why couldn’t they just read my prior messages to get this information instead of using delay tactics?

Well, now I’m on the other side of the fence as a director of GRC Support at SAP and I’ve come to learn that there are certain best practices to creating messages that would have streamlined the support process for my issues. Here are some key points to help you in creating your messages in a way that will allow our support team to provide you the fastest support possible.

I’ll show you three key best practices to keep in mind for submitting support messages.

1. Provide the system landscape on which the error occurs
2. Show the exact process you followed that caused the error
3. Open a connection into the system having the problem

Provide the System Landscape on Which the Error Occurs

GRC Support requires key pieces of information to troubleshoot your issue. It may seem like a lot of information; however, if you create your message with all this information to start with, it allows the GRC Support team to focus on troubleshooting your issue on an exact replica of your type of installation to help in identifying the root cause. You should include at least the following five pieces of information in your message.

1. The GRC application that the problem relates to, such as Access Enforcer, Compliance Calibrator, Firefighter, or Role Expert
2. The version of the GRC application: 4.0, 5.0, 5.1, or 5.2
3. The Support Package level of the GRC application. In 5.x releases, there is a Support Package level for the Java (Web) front end and for the ABAP real-time agents. You should provide both Support Package levels. The easiest way to provide this information is to take screenprints of transaction SPAM in your ABAP back end showing the Virsa support packs. In the Java front end, you can take a screenprint of the About screen, which shows the build and version date.
4. The Basis level of the back-end ABAP system where the error occurs: 4.6C, 4.7/620, 640, 700
5. For 5.x releases, the SAP NetWeaver version that the Java application is on: SAP NetWeaver 2004 or SAP NetWeaver 7.0

In addition to including this information in every message, you can update your version of GRC directly in the Support Portal. SAP Note 1049638 (System Data Maintenance for GRC Applications) has the exact details on how to update this data. (Table 1 lists other helpful SAP Notes.) By maintaining this data in the Support Portal, the data is available to the GRC Support personnel for every message you open. It helps GRC Support, though, to also include this data in the body of your message.

This technical information sets the base for assisting the GRC Support person in determining the root cause of your issue. However, this is not the most important part of your support message. The most important part of the support message is the actual description of the issue and error encountered. This brings us to the second best practice.

Show the Exact Process You Followed That Caused the Error

I cannot stress enough: The more detailed documentation you provide, the faster we can identify the root cause of your problem. We sometimes receive messages that simply say, “Risk Analysis is not working.” There’s no documentation of the exact error, the process followed to get the error, or the data used when performing the task. As a result of doing this detailed documentation, you should be able to determine the proper priority rating for the message. Priority of the message is dependent on the business impact of the issue. SAP Note 67739 provides an overview of how to determine the proper rating of each message.

In GRC applications, documenting the issue details is especially critical for those users who are on 5.x versions. This is because these versions use both a Java front end and an ABAP back end. Therefore, identifying exactly where the issue occurs is critical to the GRC Support team in identifying the root cause. You should consider four items when documenting your issue:

1. Start with a screenprint of relevant configuration screens to help GRC Support understand how the application is configured
2. Attach a document that includes screenprints showing exactly what process you followed that created the error. Include a narrative with the screenprints to describe the steps performed.
3. Attach any logs that show the errors encountered. This is especially important for 5.x versions. You can find the logs by going to the Configuration tab. Then select Background Job > Search and click on the View Log button (Figure 1). The log files start with ccappcomp.x.log. The x goes up to 19 and the logs overwrite as time passes. Ensure that you attach the log that is relevant for the time period when the error occurred.
4. In addition to the screenprints showing the error, when the message is created, you can add a section called Steps to Recreate Problem. In this section, you can describe in text format the steps that you followed that caused the issue.

Figure 1

Attach logs that show errors

So you’ve spent the time documenting the exact issue and that should be the end of it, right? Wrong. There’s a final best practice step to help GRC Support.

Open a Connection into the System Having the Problem

You should work to have a connection opened immediately for the issue that you are reporting. Try as we might, Support may not be able to determine the root cause of your problem through the message information alone, which means we may ultimately have to log in to your system to complete our analysis.

Having the connection ready and waiting for our Support personnel alleviates a lot of the back and forth that is experienced. Those users who are familiar with how to open connections can skip this section. For those of you who aren’t, here are some tips and tricks on how to ensure your connection is ready for GRC Support.

1. Ensure that in the body of the message you specifically state the installation, system ID, and client for the connection being opened. This is very important as some customers have more than 200 different systems, which may cause delays when GRC Support has to send back the message asking for system details.
2. View SAP Note 35010 for an overview of how service connections work
3. For customers on 5.x versions, Support requires a connection both to the front-end system (via Windows Terminal Services [WTS] or HTTP) as well as a connection to the back-end ABAP system on which the error is occurring. You should see three SAP Notes for some technical details. SAP Note 812732 shows you how to open an ABAP system, SAP Note 605795 shows you how to open a WTS connection, and SAP Note 592085 shows you how to open an HTTP connection.
4. Update the Customer Secure Area with the ID and password for all connections opened. SAP Note 508140 provides a good overview of how the Customer Secure Area works. You should not include the ID and password in the body of the message, only in the secure area.
5. If you have issues with opening your connections, it is best to open a new message under component XX-SER-NET-HTL. This message routes to a team that can assist you in establishing the connection.

Following these best practices should be able to help GRC Support quickly analyze and correct issues you may encounter. For an example of a message that followed these best practices, see Figure 2.

Figure 2

Effective support message

Jayne Gibbon

Jayne Gibbon, CPA, has been implementing SAP applications since 1996 and is currently a director in the Chief Customer Office at SAP. Jayne’s focus is making customers successful with their SAP HANA deployments. She has helped more than 100 customers drive business value with SAP HANA. Prior to joining SAP in 2007, Jayne worked for two multinational manufacturing companies based in Wisconsin. While an SAP customer, Jayne led the very first implementation of Virsa’s Compliance Calibrator, which is now part of SAP Access Control. Jayne’s experience includes internal audit; computer security; governance, risk, and compliance; SAP HANA; and SAP analytics.

You may contact the author at jayne.gibbon@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.