In this blog – I will provide a collection of best practices and recommendations to ensure speedy resolutions to your SAP support incident. These best practices have formed over several years’ experience of processing support incidents in the BI Platform support team seeing a variety of examples of ‘What not to do’ as well as prime examples where minimal involvement from the engineer was required to start investigation.
Several sections will be covered:
- Self-Service (Your opportunity as a customer to avoid the need for an incident entirely)
- Utilizing Expert Chat / Schedule an Expert
- Minimizing component transfers by picking the right component for your problem
- Ensuring reporter details are up-to-date
- Avoiding unnecessary ‘Ping-pong’ – Tackling the nitty gritty of problem description and environment details
- Fool proofing the steps to reproduce
- Attachments (Screenshots, logs and the BI Support Tool)
- Tool familiarization (Efficient information collection for the engineer)
WARNING: This blog is quite lengthy, as it contains examples and reasoning.
For the compact 'TLDR' version, see the below KBA for all the information that should be attached when creating an incident:
2557141 - Creating the perfect incident for SAP BusinessObjects Business Intelligence Platform
Self-Service
Before even beginning the topic of SAP Support incidents, it’s important to reinforce the importance of Self-Service. Our knowledge base is made available to our customers for a reason – to help our customers to help themselves.
Within BI – a lot of work has been done (and is still ongoing) to ensure our KBAs are easily find-able by our customers. If you get a clear error message, make sure you give it a proper search and look through a few KBAs
before creating the incident.
At best – you’ll solve your own problem before the need to create an incident
At worst – you’ll rule out a few possible causes for the issue, which allows us to focus on deeper investigation rather than known issues.
Did you know?
Our KBAs are now available for searching on Google! Why not give it a try?
SAP Community
An old favourite for customers that had lost some activity since it’s remodelling and migration, there is a big push on the SAP Community and making it once again a gold mine of knowledge, answers and community interaction.
In BI, we’ve created a guide on how to post BI related questions on the SAP Community to get answers, see it here:
2503236 - How to post SAP BI related questions on SAP Community (formerly SCN discussion)?
Search Engines
Search engines in general can provide a wealth of knowledge that may not be available using standard searches. For example, many of our customers utilize external forums in addition to the SAP Community to collaborate, and a solution for your problem may have been found on these external forums.
Product Documentation
Our Product Documentation in the BI area is also being improved, with new content being added and old content being improved regularly. Especially for configuration questions or issues, why not see if your question can be answered using the
product documentation?
Utilizing Expert Chat / Schedule an Expert
Recently at SAP Support we’ve begun utilizing Expert Chat, where you – as our customers – can initiate a live chat with the same SAP Support Engineer who would’ve processed your incident, allowing for all required information about the problem to be collected in real time.
As a Support engineer, chat allows us to speed up the ‘time to resolution’ by avoiding the initial ping-pong of an incident. What normally takes days in a traditional incident can be done in less than one hour on a chat.
Find out more regarding Expert Chat:
https://support.sap.com/en/my-support/incidents.html#section_1554503147
Schedule an expert (SAE) is another method of interacting with support that can offer benefits vs creating a standard incident. It offers a new way to connect with an SAP Support engineer in a live, one-on-one 30-minute call.
Find out more regarding SAE:
https://support.sap.com/en/my-support/incidents.html#section_1575600800
If neither of the above optional support interactions suit requirements, create a traditional incident using the below KBA:
1296527 - How to create a support incident (contact SAP Product Support) - SAP ONE Support Launchpad
Ensuring reporter details are up-to-date
If a call is asked for, or an engineer needs to call you to clarify certain aspects of the incident or to conduct a remote session, then the incident reporter details need to be valid.
Many times we'll find these are out of date, and the numbers are no longer in service, or for a contact that no longer works in that company.
Ensuring they are up to date means engineers can contact you in a timely manner to perform remote sessions or clarify statements, this can avoid unnecessary replies in the incident where we need to ask for emails or phone numbers to be provided.
Follow the below KBA to update S-User information:
1271545 - How to update S-User ID phone number, e-mail, or language settings - SAP ONE Support Launc...
If for any reason the steps in the above KBA cannot be performed, ensure the required contact information is included within the incident.
Minimizing component transfers
SAP has many products and teams that support those products, BI itself is a very complex product with many different components responsible for different aspects of the platform, with a different team to handle each of the different areas.
Component transfers can be an area of frustration and delays, but are sometimes a necessary evil to ensure the incident is being processed by the right engineer.
Minimizing the number of component transfers that happen during the initial stages of the incident involves familiarizing yourself with the BI components, and ensuring that the problem description is as detailed as possible (See above). Raising an incident with the correct team can ensure that your problem gets processed as quickly as possible.
To aid this, I’ve created the following KBA detailing our Components and the responsibilities of each component, which I recommend giving a once over each time an incident is created:
2554287 – Incident Components and Responsibilities for BI Platform [Which component to raise an inci...
Avoiding unnecessary ‘Ping-pong’
Problem description is the single most important section of a Support case, a detailed (and clear) problem description can make a significant difference to the amount of time a case takes to process by reducing the amount of ping-pong required to understand the problem.
The problem description should include:
- Full error messages (not truncated) including error codes (eg. FWM XXXXX)
- Where exactly the problem is being seen (eg. In Central Management Console -> Promotion Management I get error xxxxxxxxx)
- Full environment details (BI server version including patches + SP / OS versions / Webapp server versions / CMS DB version)
- Architecture details (clustered / distributed / any load balancers / third party authentication)
- Any KBAs which have already been looked at / resolutions tried without help
The
BI Platform Support Tool (BIPST) Landscape analysis report covers most of the above, and should be attached with every incident that is created. Read more about why in the section
Attachments (Screenshots, logs and the BI Support Tool).
Fool proofing the steps to reproduce
The steps to reproduce are another critical section of the incident, especially if you’ve encountered something you believe to be a bug in the product (eg. occurs across multiple environments)
They allow an engineer to quickly boot up an environment and test the same workflow, to verify if it’s a bug that can be escalated to development or whether it needs further investigation at Support level.
They should be explained such that someone with no context of BI should be able to look at them and reproduce the same problem.
The steps to reproduce should include:
- Full workflow including EVERY step required to reproduce the problem described as clearly and accurately as possible
Attachments (Screenshots, logs and the BI Support Tool)
There is never such a thing as ‘too much’ information, so long as it’s relevant to the problem. Anything that can be attached to further help the engineer understand the issue better is
always worth attaching to the incident.
I see many customers have adopted a practice of using Word Documents as a method of describing their issues, generally this word document will include a detailed description of there environment and problem – as well as a series of screenshots detailing the workflow they are performing to get to a problem. Personally as an engineer, I
love this approach, these documents allow me to quickly get a real understanding of exactly what the problem is, which I can either use to reproduce the problem, or if it can’t be reproduced – to direct my investigation right off the bat.
Logs – the bread and butter of support engineers. If you’re experiencing a problem which you can reproduce every time in any of our web applications (Central Management Console / BI Launch Pad), then the End-To-End trace tool is for you. This tool allows us to collect logs which correlate
only to the workflow being performed. This allows us to investigate only what’s relevant to the problem, and determine exactly where (ie, what server or service) the issue is happening. It enables us to quickly narrow down the scope of investigation, and takes minimal effort to perform.
You can find the process for E2E trace at the following KBA:
1861180 – Collecting an end to end trace in BI Platform 4.x – customer instructions and best practic...
Another common scenario which generally requires logs is a failed server startup, for which you can follow the below KBA to generate tracing:
2554558 – Tracing Failed / Running with Errors servers in BI 4.x [How-To]
Did you know?
The tool we use to examine our .glf server logs has been made publicly available.
Find the tool (and documentation on how to use it) at the following link:
https://wiki.scn.sap.com/wiki/display/BOBJ/Flexible+Log+Reader
Why not have a go at examining the logs yourself?
At best, you’ll find an error which will allow you to solve the issue yourself. At worst, you’ll be able to point out some errors to direct the investigation. Give it a try!
A special mention needs to be done for the
BI Platform Support Tool (BIPST), in particular the Landscape Analysis function.
This function automatically collects a complete overview of your entire BI Platform landscape. Using this, we/you can see versions of your platform, detailed configuration information for each of your servers, platform search details, scheduling information, how much content there is on the platform and
much more. All of this useful information to have when processing an incident.
Generate a landscape report as per the following KBA:
2138275 – How to generate a Landscape Analysis Report for SAP Support using SAP BI Platform Support ...
Personally, I find that there are
very rarely situations where the landscape analysis
isn’t useful, and I would recommend keeping an up to date copy of this for attachment to incidents. It acts as a reference point for engineers to have in case further configuration information is needed, and if attached, can
avoid ping-pong where we’re requesting for this information.
Tool familiarization (Efficient information collection for the engineer)
Just a very quick section to note some other tools that are occasionally used within our BI support teams to collect information which may be useful to familiarize yourself with:
- Process Explorer
- Process Monitor
- TCPView
- Fiddler
- Wireshark
- Browser Developer tools (F12)
- JVMTOP / JVMMON
- WinDbg
Summary
Try these best practices and see what effect it has on your time to resolution!
Post in the comments any other best practices that you have for working with SAP Support that you’ve found helps to speed up your time to resolution, I’d love to add any new best practices I’ve not seen to the list! Let me know any feedback you have on the methods I’ve including in this post!
I’ll try to answer any questions or comments ASAP.
