Fault Message Types – A Demo (Part 1)

Before we start, recommended read – Fault Message Type from SAP Help document.

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.

8 Comments

You must be Logged on to comment or reply to a post.

November 2, 2006 at 7:43 am

Hello Shabarish,

Very well written blog. You mentioned in your blog about handling fault messages in synchronous interfaces. Please take a look at the following blog https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2759. [original link is broken] [original link is broken]

Keep up the good work.

Cheers,
Naveen

like (0)
1. Shabarish Vijayakumar Post authorNovember 2, 2006 at 11:22 pm
  
  Thnx Naveen 🙂
  
  Well, actually i did see your blog before but my personal thought was tht it was more on a high level thought. I was thinking of putting up one with specific details on the sync scenario!!!
  
  What do u think ?
  
  ~~ShaBZ~~
  
  like (0)
Former Member December 6, 2006 at 6:11 am

Hi,

I tried the scenario as it is in this article but the message always shows a checkered flag insted of the light bolt. Is there some thing else we need to do to get this ?

thanks,
Vj

like (0)
1. Shabarish Vijayakumar Post authorDecember 6, 2006 at 6:25 am
  
  did you inject an exception ? maybe you are trying it as a success ….
  
  like (0)
  1. Former Member December 6, 2006 at 7:15 am
    
    I did raise the exception. Here is the code I put in the server proxy:
    
    DATA: standard_data     TYPE zexchange_fault_data,
          detail_data       TYPE zexchange_log_data.
    
        standard_data-fault_text   = ‘An Exception has occured’.
        standard_data-fault_url   = ‘www.abcd.com’.
        detail_data-severity       = ‘High’.
        detail_data-text           = ‘Test of fault message type’.
        detail_data-id             = ’01’.
        detail_data-url            = ‘Usernull’.
    
        APPEND detail_data TO standard_data-fault_detail.
    
    RAISE EXCEPTION TYPE zcx_fmt_num
       EXPORTING
    *    TEXTID =
    *    PREVIOUS =
    *    AUTOMATIC_RETRY =
    *    CONTROLLER =
    *    NO_RETRY =
        STANDARD = standard_data
        .
    
    like (0)
  2. Former Member December 6, 2006 at 9:16 am
    
    Shabarish,
    
    I was looking in the XI system Moni and now I figure I have to look in the Moni of the R/3 receiving system. I think that solves my problem.
    
    Thanks,
    Vj
    
    like (0)
  3. Former Member December 6, 2006 at 9:17 am
    
    Shabarish,
    
    I was looking in the XI system Moni and now I figure I have to look in the Moni of the R/3 receiving system. I think that solves my problem.
    
    Thanks,
    Vj
    
    like (0)
Jorge Imoberdorff July 13, 2018 at 3:43 pm

Hi.

You have a similar post with Outbound WS? (Sync ECC->PI->Legacy)

I’m trying to catch in ECC ABAP a timeout or conection dump when I call the ws but I can’t doit yet.

Can you (or any) helpme with this?

Thanks.

like (0)