Exception Handling and Application Logs

There are numerous situations where an MDR program is required to take some action. This action can range from simply outputting informational messages to extreme cases where the program is required to abend. A number of framework components exist in MDR so that your program can indicate to the framework the current processing status and the manner in which your program is reacting to a particular situation.
The interval processing subroutine is given a range of objects to process (the interval itself). During the processing of these objects, a situation may occur where a particular object in the range is invalid. An example of this may be that there is a problem with the database integrity of that particular object (e.g. an invalid enumeration or configuration is missing). The MDR program has the option to either:

1. Output a message to the application log
2. Skip the current object and move on to the next
3. Abend the program
   Alternatively, the program may be required to do a combination of the above. MDR provides the developer with a number of statements to log exceptions:
   

The sample code below shows how to code messages raised inside MDR to be read via the application log.

FORM mdr_interval_processing 
  USING x_interval TYPE /btr/st_interval_values.  
  ... 

  IF lv_error EQ gc_true. 
     mdr_msg_put 1 'E' '100' 'MSGCLASS' space space space space.  
  ENDIF.  
  ... 

ENDFORM. 

The statement mdr_msg_put will output a message to the application log. It expects to be provided with the following parameters:

1. Priority – The log level represents the importance of the message. This allows the person running the program to determine what messages are outputted to the application log. The five categories that can be used are:
   Critical (1) – Used to represent that the message is critical
   Important (2) – Used to represent that the message is important
   Normal (3) – Used to represent that the message is of normal importance
   Information (4) – Used to represent that the message is an informational message
   Debugging (5) – Used to represent that the message is for debugging purposes
2. Message Type – The message type is the standard SAP message type and represents the type of message. It must be one of the following five options:
   Error (E) – Error message
   Success (S) – Success message
   Information (I) – Informational message
   Warning (W) – Warning message
   Abend (A) – Abend message – stops the program
3. Message Number – The message number is the standard SAP message number as defined in the message class.
4. Message Class – The message class represents the standard SAP collection of messages.
5. Message variables – When you define a message in the standard SAP message class, placeholders for variables may be defined. These placeholder variables can be passed in here. There may be up to four message variables. If the message has no variables or there are less than four, then you should use the “space” keyword – i.e. you must provide all four variables even if you simply use the space keyword four times.