Message Types and Error Groups
The messages in the R/3 System can be classified according to different types. The message type determines where the message is issued and how the system responds.
Messages which refer to errors, so-called error messages, can be grouped in terms of their contents on the basis of the events triggering them or the objects affected. Error messages are to state the problem and, if space permits, should offer suggestions for removing the error. In this way the user can proceed without outside help. Examples illustrate the individual error groups.
Note: The message types have been defined by the programmers, not the Ergonomics Group.
S Message (Success)
S-type messages are displayed in the Status Bar on the same or next screen. The message has no influence on the user’s work. It only confirms the successful execution of system functions.
I Message (Information)
This message has a modal character — that is, the user must acknowledge the message. I messages are therefore displayed in a modal dialog box. The processing can be continued by pressing the ENTER key.
W Message (Warning)
So-called W messages interrupt the processing and allow the user to make corrections. For this reason, fields are enabled for input. W messages are displayed in the Status Bar if the messages have been issued by a primary window. If a dialog box issues the message, the system displays the message in a separate dialog box.
With regard to the system response, warnings are similar to E messages. E messages, however, force the user to change the entry.
E Message (Error)
When the system detects an error, E messages should be used. Incorrectly completed fields must be ready for input. If consequential errors occur, we recommend to make not only the incorrectly filled field ready for input but also those fields whose entries have contributed to the error.
Depending on whether the E message was issued by a primary window or a dialog box, it is either displayed in the Status Bar of the primary window or in a separate dialog box.
A Message (Abend)
A messages are intrinsically of a modal character, that is, a separate dialog is inserted into the current task. Therefore, they are displayed in modal dialog boxes
A messages do not allow the user to make any further entries. The user can only acknowledge the message. The task is abruptly terminated and the system returns to a higher-level menu.
A messages should only be issued in extraordinary circumstances, for example, when a system-related error occurs or if the error can no longer be handled by the task. In all error situations handled by the task, however, it should be possible for the user to remain in his work environment. A messages should therefore be avoided, if possible.
Icons in Messages
If standard error messages from the Basis system are displayed in a dilaog box, the system auotmatically displays the appropriate icon for the particluar message type (E, W, I, or A). Since S messages always appear in the status bar, there is no icon for S messages.
Figure 1: Icons to be used in messages
Note: In general, application developers do not have to take action in this respect.
Errors in Tables
Generally, the user is not authorized to make changes in a table. Therefore, the short text of the error messages which refer to tables should not contain a reference to a table. This information is contained in the long text, possibly together with the recommendation to contact the system administrator.
If the display of the message was initiated because a system table does not include an entry which it was expected to contain, the short text should not contain a reference to the table but at most a note on the entry:
- Good : E: Order type & is not valid (Please check entry)
If the error is related to tables, which are only of importance for the SAP System itself or if the cause for the error cannot explicitly be assigned to a particular entry, the message should refer the user to the system administrator:
- Good : A: No further processing possible (Please contact your system administrator)
The long text should always contain a detailed error diagnosis which can also be of a more technical nature (which, however, is indicated as such).
If special reference is made to lines which are not contained in a table and if the table is important for the user, that is, if he has maintenance authorization for the table, use the following message pattern:
- Good : A: Please enter country in country table & first
Input Values are not within the Valid Value Range
The user has entered an entry which was not within the valid, usually numeric value range.
- Good : E: Please enter posting period in allowed value range
If the value range is known or predefined, the error message should ask the user to enter a value within a specified range:
- Good : E: Please enter a posting period between 1 and 12
In some situations, the user attempts to carry out an action which is meaningless from a business point of view (the system should be able to prevented these actions).
- Good : E: Please create bill of material first
- Good : E: Order type of outline agreement cannot be selected for &
- Good : E: Balance & is in the revaluation document of company code &
System Error, System Limits are Exceeded
If a non-user error occurs in the system, the message should explain that a system-related problem has caused the error. It should also point out how the user can respond. Technical descriptions should be avoided.
For temporary problems, the following «good» example can be used:
- Bad : I: Global lock table is full. Locking is currently notpossible
- Good : I: At present, the function cannot be carried out
A detailed explanation of this message must be given in the long text.
If a more severe system error interrupts the user’s interaction with the system, the following message can be displayed:
- Good : A: No further processing is possible (Please contact your system administrator)
A detailed explanation of this message must be given in the long text.
No Entry Made in a Certain Field
If particular entries are required to continue processing, the required specifications are, however, missing or incorrect:
- Good : E: Please enter material or reservation in case of a single entry
- Good : E: Please enter the batch number for material &
- Good : E: Please enter required-entry field material
If an operating error occurs, for example, the user chooses a function which requires a previous selection to have been made, the message should specify the initiated action and the error diagnosis, if possible:
- Good : W: You have chosen Copy (Please select an order first)
- Good : W: You have chosen Delete (Please delete all items individually)
Resource Conflicts Due to System Conditions
If records are locked, the user is missing the required authorization, etc.:
- Good : I: You are not authorized for printer & (printer destination)
- Good : I: Vendor master record & is currently locked
Invalid Result of an Action
If a calculation would lead to a meaningless or invalid result, not only the diagnosis should be given but also help in eliminating the error.
- Good : E: The specified quantity is smaller than the delivered quantity (Please enter again)
- Good : W: Today’s purchase order & cannot be printed
The system sends success messages to the user when it has performed certain tasks (e.g. particular important tasks).
- Good : S: Differences to physical inventory document & have been posted with document &
- Good : S: New record with field & was added to list X
- Good : S: Physical inventory document with the generated number & has been posted
The system, for early recognition of substantive errors, should check entries for their plausibility, if possible.
In the flow logic of the screen, the required fields for E messages must be enabled for input by the FIELD statement in front of the module in question. After the user has corrected the entry, the module is processed again automatically from the beginning.
Messages within modules are generally triggered at the event PROCESS AFTER INPUT. Only I messages and S messages are useful at the event PROCESS BEFORE OUTPUT.
If several fields/modules are chained on the screen (CHAIN), the entire chain and therefore all modules are processed again.
If a field is contained in several chains and an error occurs, all chains which are in front of the module reporting the error are checked for this field and processed again, if found.
How To Display Error Messages In SAP ABAP?
An overview of error message types, error and pop-up messages, and how to show messages to the end user.
Published Jun 16, 2021
Message Types In ABAP
In total, ABAP has 6 types of messages.
|A||Abend (abnormal end of task)||Displays a message in a dialog pop-up window. The entire transaction is canceled after confirming the message.|
|E||Error||Displays an error message in the status line. After confirming the message, the current event block is aborted.|
|I||Information||Displays a message in a dialog pop-up window. After confirming the message, the report processing is resumed.|
|S||Success / Status||Displays a success message in the status line of the current report.|
|W||Warning||Displays a warning message in the status line. After confirming the message, the report processing is resumed.|
|X||Exit||Triggers a runtime error and creates a short dump.|
DISPLAY LIKE Addition
As you can see from the previous table the message type can also influence the report execution after the message was confirmed. In case you want to take care of the error handling yourself or simply change the appearance of a message you can use the addition DISPLAY LIKE :
This example prints the message Message text to display in the status line with the red error icon. Since the type itself is S report execution continues normally.
Remember: The addition DISPLAY LIKE only changes the appearance, not the behavior of the message type.
Following some examples of how to output a message in ABAP.
Saving Messages In A Variable
The below examples show how to create and store a message in a variable. This can be useful when working with system variables or a message class.
I’m Dan, a software engineer and consultant passionate about SAP, web and mobile app development.
Message types in ABAP
Message types in ABAP as in every programming language are used to give information to the user or programmer about the status of the programming code execution. In ABAP there are 6 types of messages, which are available:
Type A (abend – abnormal end of task )
Type A (abend – abnormal end of task ) means termination of the program. The message appears in a dialog box and the program terminates. The user is not able to make any further entries. The task is terminated and the system returns to a high-level menu. Messages of type A should be issued only in extraordinary circumstances, such as serious system errors. A-messages should be avoided, if possible.
Type E (error)
Type E is for error messages. An error message appears and the program stops. These messages are wide used. They can prevent the user from creating inconsistent records. They can point to a prerequisite to be fulfilled.
Type I (information)
Messages from type I are information only. The program is executed and information is displayed. After the user confirms the message, the program continues.
Type S (success, status)
Type S (success, status) messages only give information about the execution of the program. The only display the status of the program.
Type W (warning)
Waring messages are with type W. They are used to display information for the user, which warns the user for possible problems, but they don’t stop the program. The user can than perform corrections.
Type X (exit)
Messages from type X (exit) are the popular ABAP short dumps. The program terminates and the detailed information can be found in transaction ST22, searching by the user and the time of the error.
The syntax for message is MESSAGE TYPE .
For example if we want to display a warning message:
MESSAGE ‘This is a warning message.’ TYPE ‘W’.
The usage of messages can vary in the different programs and functional requirements. The programmer should carry for the proper and good professional usage of messaging.
Error Code Reference
- Development consultant
- Technology consultant
- Support specialist (level 3)
This SAP product documentation is a nonexhaustive list of the errors that can be returned to a client application sending messages (operation requests) to SAP CC Core Server. Your application sends these service operation requests by using the different technical interfaces of SAP Convergent Charging 4.1:
- Web Services
- HTTP Communication Interface (HCI)
- Message TCP
This user assistance is intended for troubleshooting purposes and for understanding why an operation was not executed or has failed in the SAP CC system.
View the information topic that relates to your situation and continue your investigations.
Working With Error Causes and Codes
During the implementation project, you use this documentation when integrating the business services provided by the Web Services technical of SAP Convergent Charging. Refer to the error handling information provided with its SOAP API specifications for each service operation that you can implement in your SAP system landscape. You can view some errors translated from the HCI technical interface.
Note that you can partially use this documentation when developing your applications with the Java APIs of SAP CC for troubleshooting certain operations requested via the Message TCP technical interface.
During the implementation phase or the operation phase, the errors detailed in this documentation may be visible in logs or traces of the applications and systems that connect to the SAP CC systems.
SAP Convergent Charging manages different types of errors replied in the operation responses. An error may include:
- A failure category such as already exists, does not exist, invalid, prerequisite missing, incompatible configuration, illegal state, or temporary illegal state; the definitions of these categories depend on the technical interfaces and their specification. See the corresponding documentation.
- A comprehensive message
- An error cause
- A stack of ’caused-by’ information items
SAP CC handles several error patterns that are specialized to the requested service operations. The failure categories are defined in the corresponding SAP CC API specifications.
Each error cause includes:
- A unique identifier composed with:
- a technical module name
- and a numerical cause code
- An intelligent message completed dynamically
- Suggested actions and steps for troubleshooting the issue
- Errors can be deprecated at any time
- Before you start the troubleshooting, make sure that you have the latest version of this document. It is available in the Software Development Kit (SDK) of SAP CC.
See the technical details that specify the responses of the ‘Find Subscriber Accounts’ operation provided in the Web Services technical interface and its SOAP API specification.
Errors are listed and grouped by technical modules. The code of an error is unique; It is composed of the name of the module followed by a number identifying the error inside the module.
SAP CC provides you with a comprehensive message that explains why the processing has failed in the SAP CC system or why the SAP CC system did not trigger the execution of the process
Optionally, some information such as the identifier, the name, or the code of an object managed in the SAP CC system or in its back-end database.
The meaning of this error message depends on the software layers and on the internal architecture of the SAP CC systems. The error message is the internal vision of the SAP CC system.
You may have to translate the terminology to the concepts and data models of the technical interface that has transported the error. Refer to the appropriate specifications:
- SAP CC Web Services Documentation
- SAP CC Java/XML API References
Next Actions and Steps (Troubleshooting)
Use this information to troubleshoot your issue with a cause analysis and a solution.
Quick Access by Modules
Select the module signaled in the error replied in the operation response by the SAP CC system: