Message Handling in Table Modules
Contexts are obsolete and should not be used. Contexts were introduced in Release 4.0 for high-performance access to frequently required data. Since the introduction of ABAP Objects for Release 4.5, contexts have not been developed further. Since Release 6.40, contexts can be replaced by shared objects .
If you want to send user messages from table modules, you must first have defined messages for the individual modules in the Modules table. The system cannot display a message for a table module where none is defined, but simply resets the corresponding dependent values.
When you query dependent data from context instances using the DEMAND statement, you can decide whether the system handles the user message or whether you want to handle it yourself in the program.
Message Handling - System
If you want the system to handle the message, use the basic form of the DEMAND statement without the MESSAGES option. The system will then behave as though the following statement occurred after the DEMAND statement:
MESSAGE ID 'Message ID' TYPE 'T' NUMBER 'Number' WITH 'Variable 1' .... 'Variable 4'.
The system takes the arguments for the MESSAGE statement from the corresponding entries in the Modules table. Note that the system response to the various message types depends on the current user dialog (dynpro, selection screen, or list).
Message Handling - Program
If you want to catch the message in your program, use the DEMANDstatement with the option MESSAGES INTO itab. To do this, you need to define an internal table itab with the structure SYMSG. The system deletes the contents of the itab table at the beginning of the DEMAND statement. While it is processing the context, the system does not display or respond to any messages, but writes their ID to itab. If there are messages in the table following the DEMAND statement, the system sets the return code sy-subrc to a value not zero.
This enables you to prevent automatic message handling with contexts and allows you to program your own using the entries in <itab>. This is important, for example, if you want to make particular fields on an entry screen ready for input again. In this case, you must base your message handling on these fields (using the FIELDS statement in the dynpro flow logic, or the ABAP statement AT SELECTION-SCREEN for selection screens), and not on fields in the context.
Suppose the Modules table in context DOCU_TEST1 (see Using Tables as Modules ) contained the following entries for module SPFLI:
To demonstrate system message handling, execute the following program:
REPORT demo_context_message_1.
DATA: c_from TYPE spfli-cityfrom, c_to TYPE spfli-cityto.
CONTEXTS docu_test1.
DATA: context_inst TYPE context_docu_test1.
SUPPLY carrid = 'XX' connid = '400' TO CONTEXT context_inst.
DEMAND cityfrom = c_from cityto = c_to FROM CONTEXT context_inst.
WRITE: / c_from, c_to.
The program terminates with the following error message:
No entries found for key XX 0400
To demonstrate program message handling, execute the following program:
REPORT demo_context_message_2.
DATA: c_from TYPE spfli-cityfrom, c_to TYPE spfli-cityto.
DATAitab TYPE TABLE OF symsg WITH HEADER LINE.
CONTEXTS docu_test1.
DATA: context_inst TYPE context_docu_test1.
SUPPLY carrid = 'XX' connid = '400' TO CONTEXT context_inst.
DEMAND cityfrom = c_from cityto = c_to FROM CONTEXT context_inst MESSAGES INTO itab.
WRITE: / c_from, c_to.
IF sy-subrc NE 0. LOOP AT itab. WRITE: / itab-msgty, / itab-msgid, / itab-msgno, / itab-msgv1, / itab-msgv2. ENDLOOP.ENDIF.
The program displays the following:
E AT 107 XX 0400
Instead of terminating with an error message, the program stores the message in the internal table itab, where it is available for you to process further.