More about creating effective incidents (choose the right component!)
I just read an interesting blog called “Creating Effective Customer Messages (OSS Notes)”:
Now, from my experience in SAP Support I would like to add something that is essential and yet not everyone realizes it: Choosing the right application component will speed up the message processing. Or the other way round: choosing the wrong component will delay the message delivery to the relevant team at SAP Support.
Why is the application component important?
– I will reply with another question: If one writes a letter (Let’s say a traditional one), why should one write the correct address. The answer is obvious: “So that the letter reaches its destination”. Application component would be like the ZIP code.
Ok, but how do I know which is the right application component for my message?
It seems that choosing the right component is often a difficult task. Here are some hints:
As a rule, if the issue occurs with transaction “X” or program “Y”, ABAP program RSSTATUS will tell the correct component to post the customer message:
Program RSSTATUS checks the package that is linked to the object (Program, transaction, table. Let’s find out the component of transaction PCP0 from SE80:
Of course sometimes the component is not so clear or the may be changed during the message “life” because:
- Some transactions from an application component, call transactions from a different component. E.g. program RPCIPE00 / RPCIPE01 (Posting payroll to accounting) belongs to component PY-XX-DT but an issue with RPCIPE* might be due to:
- Issues with the connection. The message would be forwarded temporarily to XX-SER-NET-HTL.
- The component of the program “X” or transaction “Y” is not accurately maintained at SAP side.
Another way to find out the right component for a message, as opposed to the RSSTATUS way is to perform a note search for the transaction or program where the problem is occurring. The right component will most likely be the one for which you get most of the notes.
Application components are useful when searching for notes too (As a filter)
By the way, this does not only apply to message creation but may also help in note search. Filtering by component(s) may be necessary to avoid getting irrelevant notes.
Right now I am participating in a project that consists of a technical note search as described in the blog:
The tool is based on a technical search based on objects as described in the blog “Finding SAP notes using ABAP coding as keywords”
During the design of the first prototype of our “Automated Note Search and Customer code detection tool” we noticed:
1. There were objects from several different components (e.g. BC* is always involved) in a single transaction, which means many heterogenous notes from different components were found and mixed up.
===> This was solved by collecting all the objects found in the trace in components, then the user who is searching for notes will decide for which of the suitable components the note search has to be done.
2. When a component X is selected for note searching, it may happen that you get notes from component Y. The reason is that the component assigned to the note does not correspond to the component of the objects in the correction instructions attached to the note.
We really wanted to get rid of the component (I mean, to make it transparent to our users) but in the end it was not possible. The idea of using as a default component the application component of the program / transaction entered in the tool selection-screen turned out to be unfeasable for the reasons explained above.
I would also highlight the “connection” issue. Sometimes an example in the customer’s system is requested by the support consultant. To enable SAP accessing those examples I recommend.
- Make sure the user account has the necessary authorizations to debug: Profile S_A.DEVELOP as opposed to SAP_ALL is recommended.
- Create variants whenever possible.
- When the message is created, chose the right customer number / installation / system. If the issue is reproduced in the development DHR system but the message was created for PHR and nothing else is said, we’ll always try to connect to PHR. Therefore, if the issue is reproduced in system DHR, state DHR when creating the message will save time and effort.
- Opening the system for short periods, leads to “message ping-pong”: (I ask you open the system and you open it for let’s say 1 hour, unfortunately I was busy when the connection was opened and when I try to connect, the connection is closed again). This can be an endless loop… Take into account that sometimes SAP needs to connect more than once if the issue is complex. Moreover, if the ticket is forwarded to development, the developers may want take a look too.
=====> Solution (Line opener program).
Have you heard about the – Line Opener Program (LOP)?
Installation of the LOP (Line Opener Program) and Service Connector is highly recommended, because it enables the members of SAP Support and Development to access a system whenever it becomes necessary.
More Information you can find in note 797124.