cancel
Showing results for 
Search instead for 
Did you mean: 

Proxy SOAP Fault

Former Member
0 Kudos

Hi,

I have PROXY to SOAP Sync scenario where ECC calls the proxy via PI. On the other side Web Service ( WS) responds to request & ECC saves that response.

As per the WS standard followed by Client, the Web Service ( WS) has request, response & fault messaged.

If the operation is success it is in Response else it is in fault message.

I have WSDL imported from the Client & created the Data type & message type for ECC Proxy. Since there is fault message to be mapped for WS, Ii have created fault message for ECC side also. This fault is mapped to WS fault & assumption is ECC would get all the errors via this fault.

When the proxy gets generated, i see 3 messages on ECC. However when PI tries to send the fault, in ECC it goes to Standard fault message cx_ai_application_fault instead of custom fault. Due to whcih ECC is not able to get error data.

My question is How to pass the fault data to ECC considering this case does not work. Any other suggestion are also welcome to re design this interface.

PS: We have done the reverse of this ( SOAP to PROXY) and then we did that by passing

Thanks..!!

Accepted Solutions (0)

Answers (3)

Answers (3)

dave_komzak
Explorer
0 Kudos

Hello Harry,

I read this post with much interest because I am having the same issue and I was wondering, if and how you were able to obtain your custom fault error message?

Regards,

Dave

vikas2
Active Participant
0 Kudos

Hi,

Try couple of steps:

1) In sproxy .. for your SI , for the exception give the fault message to have:

ABAP Type Exception, class and in ABAP name Ref, put the ABAP exception class.

2) Then, in your application logic you need to raise the exception :

      CALL METHOD cl_proxy_fault=>raise

      EXPORTING

        exception_class_name = '<ABAP exception class name>'

        bapireturn_tab = lt_bapiret.

lt_bapiret has type  bapirettab .

Thanks

Vikas

dave_komzak
Explorer
0 Kudos

Hi Vikas,

Thank you for the suggestion and the code samples.  I tried the suggestion and unfortunately

our error message is not present in lt_bapiret.  In fact the table structure is empty.

The only error message we are getting so far is 'Application Error' which is returned from CX_AI_APPLICATION_FAULT.   I raise my Z exception class after the system catches

CX_AI_APPLICATION_FAULT.   I am assuming my custom error message should be

available because I can see it in the XI response payload.  At thjs point I dont know

if my issue is on the XI side or ABAP.  Any developers have actual success with this?

Regards,

Dave

vikas2
Active Participant
0 Kudos

It's difficult for me to try this without trying to create an example but if you want to update your return table from the ( custom ) exception object, the following code could be used.

IM_RF_EXCEPTION is the reference to exception object

and rt_msgtab will be your return table.

data: ls_bapi_message type bapiret2,
         lv_messag_var type string.

   field-symbols: <fs_attr_val> type any.

   ls_bapi_message-type = 'E'.
   ls_bapi_message-id = im_rf_exception->t100key-msgid.
   ls_bapi_message-number = im_rf_exception->t100key-msgno.
   ls_bapi_message-message = im_rf_exception->get_text( ).
* Assign the value of message variables
   lv_messag_var = im_rf_exception->t100key-attr1.
   concatenate 'im_rf_exception->' lv_messag_var into lv_messag_var.
   assign  (lv_messag_var) to <fs_attr_val>.
   if <fs_attr_val> is assigned.
     ls_bapi_message-message_v1 = <fs_attr_val>.
   endif.

   lv_messag_var = im_rf_exception->t100key-attr2.
   concatenate 'im_rf_exception->' lv_messag_var into lv_messag_var.
   assign  (lv_messag_var) to <fs_attr_val>.
   if <fs_attr_val> is assigned.
     ls_bapi_message-message_v2 = <fs_attr_val>.
   endif.

   lv_messag_var = im_rf_exception->t100key-attr3.
   concatenate 'im_rf_exception->' lv_messag_var into lv_messag_var.
   assign  (lv_messag_var) to <fs_attr_val>.
   if <fs_attr_val> is assigned.
     ls_bapi_message-message_v3 = <fs_attr_val>.
   endif.

   lv_messag_var = im_rf_exception->t100key-attr4.
   concatenate 'im_rf_exception->' lv_messag_var into lv_messag_var.
   assign  (lv_messag_var) to <fs_attr_val>.
   if <fs_attr_val> is assigned.
     ls_bapi_message-message_v4 = <fs_attr_val>.
   endif.

   append ls_bapi_message to rt_msgtab[].

Thanks,

Vikas


former_member184681
Active Contributor
0 Kudos

Hi Harry,

I haven't actually developed a scenario like yours, but from your description I can deduct that this cx_ai_application_fault standard exception class might be a superclass for your own one. In such case, try catching the exception of that type first, and then downcasting the exception object to an object of your particular exception type. Give it a try, from the ABAP point of view it should be fine. Example code:

TRY.
    [call proxy method]
  CATCH cx_ai_application_fault INTO lo_exception.
    lo_yourexception ?= lo_exception.
    [further processing, as required]
ENDTRY.

Hope this helps,

Greg

Former Member
0 Kudos

Thanks for reply. We tried this but looks like lo_exception has std messages.

OBJECT

CX_ROOT

CX_ROOT

TEXTID

PREVIOUS

KERNEL_ERRID

INTERNAL_SOURCE_POS

CX_DYNAMIC_CHECK

CX_AI_APPLICATION_FAULT

CX_AI_APPLICATION_FAULT

Also lo_yourexception ?= lo_exception. is giving syntax error as both the structure are not comparable.

Regards

Edited by: harry101_SAP on Feb 13, 2012 11:02 PM

former_member181962
Active Contributor
0 Kudos

Hi ,

Can you check if this helps you?

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/6568

It talks about RFC-SOAP but you can get an idea and port it to Proxy scenario.

Best Regards,

Ravi

baskar_gopalakrishnan2
Active Contributor
0 Kudos

Are you raising exceptions referencing the fault message of proxy regenerated message? This is purely problem at the proxy coding side.

Former Member
0 Kudos

Well yes & No. I pass the fault message of WS to ECC. I can see that message is going to ECC>

But once it comes to ECC, it become Std Fault, so wondering how to pass my own message.