How to display additional information about IDoc processing in the Application Log - Developer Guideline

[andrea_olivieri]

Summary

This document describes how to to write down the messages issued by the IDoc inbound processing in the application log, improving the level of monitoring .

It contains information about customizing settings as well code snippets that might be integrated in your custom  IDoc inbound applications.

Prerequisites

The status record with the message long text  should be sufficiently explanatory to describe the processing results of an IDoc, but whenever this is not possible,

Figure 1 – Two error messages for the same inbound processing in EDIDS table

for example when the IDoc module generates several error messages in a single inbound processing, it could be useful to populate the application log instead of creating a single status record for each message issued as shown below (Fig. 2).

Figure 2 – How the IDoc statuses appear

1. How SAP works

1.1 Instantiation

The SAP standard already implements this feature; the developers need only to insert the log object number (generated programmatically within the IDoc inbound ABAP module) in the field APPL_LOG of the EDIDS - IDoc status table (Fig. 3).

Figure 3 - The APPL_LOG field in the EDIDS

1.2 Navigation

The IDoc monitoring tool is designed to allow the navigation from the IDoc to the application log. As soon as the tool detects that the field APPL_LOG of the

Figure 5 – Navigation pushbutton in the status record

EDIDS table is filled, it activates a specific bar button (Fig. 5) which allows the direct navigation from the detail screen of the status record to the Application Log (Fig. 6).

Figure 6 – Application Log evaluation accessed by IDoc monitoring

2. Required Customizing settings

Every log entry is linked with an object and possibly one of its subobjects. In the transaction SLG0 you can define entries for your applications in the application log.

2.1 Define the application log object

In this example a new entry "ZEDI" was created.

Figure 7 – object ZEDI – "EDI Integration" created

2.2 Define the corresponding sub object

Sub objects are simply further classifications of the application log object; in this case the inbound specific sub-object ZSD_945_IDOC was created.

Figure 8 – Sub object ZSD_945_IDOC – EDI 945 Inbound

Y* and Z* are reserved for customer names.

3. Inbound function module processing logic review

Depending on the result of the business object update phase, the inbound processing Function Module fills the IDoc status record (type BDIDOCSTAT)  appending it to the corresponding internal table IDOC_STATUS as shown in the below example. (Fig. 9)

Figure 9 – Filling the IDOC_STATUS internal table

If the inbound application generates more than one error message, then you might have more than one record in the internal table IDOC_STATUS.

So taking this in mind, in order to write the application log, the developer has to implement the following steps:

• Remove the existing IDOC_STATUS internal table entries and store them in the application log
• Refresh the internal table IDOC_STATUS
• Create a new single status record message containing the pointer to the instance of the application log created

4. Code Snippet

4.1 Defining constants for log entry creation

The log object and the corresponding subobject should be declared as constants in your IDoc inbound ABAP application (see above “Required customizing settings”).

constants:  edi_object         type balhdri-object    VALUE 'ZEDI',
            945_subobject_idoc LIKE balhdri-subobject VALUE 'ZSD_945_IDOC'.

4.2 Calling the application log writing routine

Your IDOC_STATUS internal table contains a lot of messages, so it’s time to feed the application log; place the call to the routine that creates the application log at the end of the inbound processing Function Module

"Write Status records with Application Log
PERFORM _idoc_status_prepare
           TABLES    idoc_status           "Changing
           USING     idoc_contrl
                     error_subrc.          "OK = 0 ; KO <> 0

ERROR_SUBRC is a local variable that indicates that at least one error occured

4.3 Application log  creation routine

The source code inside the above abap routine has been taken from the inbound processing Function Module IDOC_INPUT_INVOIC_MRM to post Inbound Vendor EDI Invoices.

*&---------------------------------------------------------------------*
*&      Form  _IDOC_STATUS_PREPARE
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->T_IDOC_STATUS  text
*      -->I_IDOC_CONTRL  text
*      -->I_SUBRC        text
*----------------------------------------------------------------------*
FORM _idoc_status_prepare TABLES       t_idoc_status    STRUCTURE bdidocstat
                           USING        i_idoc_contrl    LIKE edidc
                                        i_subrc          LIKE sy-subrc.


  DATA: lt_balmi TYPE TABLE OF balmi,
       ls_balmi LIKE LINE OF lt_balmi,
       lt_balnri TYPE TABLE OF balnri,
       ls_balnri LIKE LINE OF lt_balnri.

  DATA: f_appl_log  TYPE bdidocstat-appl_log.

  CHECK  LINES( t_idoc_status ) > 1.

  CALL FUNCTION 'APPL_LOG_INIT'
      EXPORTING
           object    = edi_object
           subobject = 945_subobject_idoc.

  LOOP AT t_idoc_status.
      CLEAR ls_balmi.
      MOVE-CORRESPONDING t_idoc_status TO ls_balmi.
      APPEND ls_balmi TO lt_balmi.
  ENDLOOP.

  SORT lt_balmi .
  DELETE ADJACENT DUPLICATES FROM lt_balmi COMPARING ALL FIELDS.

  CALL FUNCTION 'APPL_LOG_WRITE_MESSAGES'
      EXPORTING
           object           = edi_object
           subobject        = 945_subobject_idoc
           update_or_insert = 'I'
      TABLES
           messages         = lt_balmi.

  CALL FUNCTION 'APPL_LOG_WRITE_DB'
      EXPORTING
           object                = edi_object
           subobject             = 945_subobject_idoc
      TABLES
           object_with_lognumber = lt_balnri.

  READ TABLE lt_balnri INTO ls_balnri INDEX 1.
  CHECK sy-subrc = 0.

  CLEAR t_idoc_status.
  REFRESH t_idoc_status.

  IF i_subrc = 0.
      t_idoc_status-status   = '53'.
      t_idoc_status-msgty    = 'S'.
  ELSE.
      t_idoc_status-status   = '51'.
      t_idoc_status-msgty    = 'E'.
  ENDIF.

  t_idoc_status-docnum   = i_idoc_contrl-docnum.
  t_idoc_status-msgid    = 'EA'.
  t_idoc_status-msgno    = '066'. “Messages from IDoc processing can be found in application log
  t_idoc_status-msgv1    = ' '.
  t_idoc_status-msgv2    = ' '.
  t_idoc_status-msgv3    = ' '.
  t_idoc_status-msgv4    = ' '.
  t_idoc_status-segfld   = ' '.
  t_idoc_status-uname    = sy-uname.
  t_idoc_status-repid    = sy-repid.
  t_idoc_status-routid   = 'ZSDN_IDOC_INPUT_XXX_945'. "My inbound processing FM!
  t_idoc_status-appl_log = ls_balnri-lognumber.       "Newly created LOG Instance!
  APPEND t_idoc_status.

ENDFORM.                               " _IDOC_STATUS_PREPARE

(...)

5. Authorization Objects

The user should be able to diplay the application logs entries by the S_APPL_LOG authorization

6. Related content

Application Logging

Create and view LOG using SLG0 and SLG1 transaction

Conclusions

The IDoc inbound processing application writes a log for your objects; as IDocs can be linked to application objects, the corresponding log can be Displayed from the IDoc.

Hope I have shed some light onto “IDoc application log”.