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;
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.
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
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~~
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
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
.
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
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
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.