Fault Message Types – A Demo (Part 1)

In this blog we will see how to configure a fault message for an asynchronous scenario and how it can be used in monitoring of the message flow.

Note : An Extract from the online help says “The fault message of the application for an asynchronous ABAP server proxy is persisted for monitoring. In the case asynchronous of Java server proxies, the fault message is part of a negative application acknowledgement.”

Lets take the scenario of a File -> XI -> ABAP Proxy. The scenario is so designed that the file will contain a SAP user name and this will be passed to the ABAP proxy via XI. Inside the ABAP proxy, we do two types of checks and trigger the fault message.

1. If there is no entry for the user in the file.
2. If the user specified in the file does not exist in the USR01 table.

The Development:

The Data Type:

DT_UserName

The Message type:

1. MT_UserNameFromFile
2. MT_UserName

Use DT_UserName for these message types.

The Fault Message type

The Message Interface:

1. MI_UserNameFile

2. MI_UserNameAndException

Make the message mapping between MT_UserNameFromFile & MT_UserName and also the corresponding Interface mapping.

In the configuration go ahead as you configure any File to Proxy scenario.

In your R3, generate the proxy for the inbound interface, MI_UserNameAndException.

The screenshot below shows that the fault message type that was used in the inbound interface is reflected in the exceptions tab under Methods in your Class generated for the inbound proxy.

ZEXCHANGE_FAULT_DATA inside ZCX_DT_FAULT

ZEXCHANGE_FAULT_DATA structure inside the proxy

In our proxy we will be sending the user to a custom ‘Z’ table after a check in the USR01 table. Else we need to handle two exceptions as mentioned earlier ie;

1. If there is no entry for the user (blank user) in the incoming file.
2. If the user specified in the file does not exist in the USR01 table.

The following code will illustrate how the above is acheived;

METHOD zii_mi_user_name_and_exception~execute_asynchronous. *** **** INSERT IMPLEMENTATION HERE **** ***    DATA: user TYPE zmt_user_name-mt_user_name-data-name,         it_usr01 TYPE TABLE OF usr01,         wa_usr01 LIKE LINE OF it_usr01,         cust_table TYPE z12emp.    DATA: standard_data     TYPE  zexchange_fault_data,       detail_data       TYPE  zexchange_log_data.     user = input-mt_user_name-data-name.     IF user IS INITIAL.      standard_data-fault_text   = ‘An Exception has occured’.     standard_data-fault_url   = ‘www.t-systems.com’.     detail_data-severity       = ‘High’.     detail_data-text           = ‘No user found in the incoming File’.     detail_data-id             = ’01’.     detail_data-url            = ‘Usernull’.      APPEND detail_data TO standard_data-fault_detail.      RAISE EXCEPTION TYPE zcx_dt_fault       EXPORTING *      TEXTID = *      PREVIOUS = *      AUTOMATIC_RETRY = *      CONTROLLER = *      NO_RETRY =         standard = standard_data         .     ELSE.      SELECT SINGLE * FROM usr01 INTO wa_usr01 WHERE bname = user.      IF sy-subrc EQ 0.        cust_table-empid = ‘555’.       cust_table-firstname = wa_usr01-bname.       MODIFY z12emp FROM cust_table.      ELSE.        standard_data-fault_text   = ‘An Exception has occured’.       standard_data-fault_url   = ‘www.t-systems.com’.       detail_data-severity       = ‘Medium’.       detail_data-text           = ‘This user does not exist’.       detail_data-id             = ’02’.       detail_data-url            = ‘User Not exist’.        APPEND detail_data TO standard_data-fault_detail.        RAISE EXCEPTION TYPE zcx_dt_fault         EXPORTING *      TEXTID = *      PREVIOUS = *      AUTOMATIC_RETRY = *      CONTROLLER = *      NO_RETRY =           standard = standard_data.      ENDIF.    ENDIF.  ENDMETHOD.

Testing:

Now let us test the scenario and see how the system reacts.

1. File contains a user entry that exists in USR01 table.

So as we expect in R3 -> SXMB_MONI, we have the Success Flag 🙂

2. No user specified in the file (blank entry)

Ok … now here pops up the icon for “Application Error (Restart Possible)”.

Navigate and inside you find the error message;

And if you open the MainDocument for the payload you will find the descriptive error caught by the exception.

3. User specified in the file does not exist in USR01

Everything happens as described above. Only thing that changes is the MainDocument message content.

So that would have given you a grasp on fault message types and its usage. You could now explore more and put them to your use.
In the next part let us use the fault messages in Synchronous scenarios and see how they behave.

A Special thanks to good friend and my guide in profession, Jayakrishnan Nair who helped me in bringing out this blog.