Message Handling in Table Modules 

 Contexts are obsolete and should not be used. Contexts were introduced for 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 output a message for a table module where none is defined, but will simply reset the corresponding dependent values.

When you query dependent data from context instances using the DEMANDstatement, you can decide whether the system should handle 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 DEMANDstatement:

MESSAGE ID 'Message Id' TYPE 'T' NUMBER 'Number'
        WITH 'Variable 1' .... 'Variable 4'.

The system takes the arguments for the MESSAGEstatement from the corresponding entries in the Modules table. Note that the system reaction to the various message types depends on the current user dialog (dialog screen, 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 DEMANDstatement. Whilst it is processing the context, the system does not output or react to any messages, but writes their ID to itab. If there are messages in the table following the DEMANDstatement, the system sets the return code sy-subrc to a value unequal to 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 screen 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.

DATA itab 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 outputs 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.