cancel
Showing results for 
Search instead for 
Did you mean: 

Catch validation error in proxy

former_member260907
Participant
0 Kudos

Hi Expert,

I have a proxy to file scenario. I chose "Validation by Integration Engine" in my sender agreement to validate the data. I know I can check the error detail in SXMB_MONI. But how I can catch the error in my ABAP program which calls the outbound proxy?I see this blog: said I can set alert and catch it in ABAP program. I tried to use ALRTCATDEF in ECC side in which proxy exists. But I am told I don't have authorization. I tried it in PI. I see I can do it. Does this Alert Configuration can be done in ECC side as well? I want to make sure before I ask for authorization. Once I set up Alert configuration in ECC side, how I can catch the validation error in my ABAP program after calling the proxy?

Thanks a lot!

Charles

Accepted Solutions (1)

Accepted Solutions (1)

former_member184681
Active Contributor
0 Kudos

Hi,

I remember being surprised with that, too, back when I used Proxy acks for the first time. The solution is simple - you need a commit after sending your message, and before evaluating acks (because they are being read from DB by standard ack processing classes). Or alternatively, you can evaluate acks in a separate report scheduled as a background job, if this is acceptable.

Hope this answers your doubts,

Greg

former_member260907
Participant
0 Kudos

Hi Greg,

Thanks for response. However I did "Commit work"(see below coding).

TRY.
      CREATE OBJECT lo_proxy.
      lo_async_messaging ?=
      lo_proxy->get_protocol( if_wsprotocol=>async_messaging ).
      lo_async_messaging->set_serialization_context('TS0000731_ORDER').
      l_ack_request =  if_wsprotocol_async_messaging=>co_transport_acknowledgment.
     lo_async_messaging->set_acknowledgment_requested( l_ack_request ).

      CALL METHOD lo_proxy->si_ob_dmplanningsalesorder(
        output = ls_msgtype
        ).

     lo_msg_id_protocol ?= lo_proxy->get_protocol( if_wsprotocol=>message_id ).
      l_msg_id = lo_msg_id_protocol->get_message_id( ).

      COMMIT WORK.
* read ack
      lo_ack = cl_proxy_access=>get_acknowledgment( l_msg_id ).
     l_ack_status_simple = lo_ack->get_status( ).

    CATCH cx_ai_system_fault INTO lo_fault.
      CALL METHOD lo_fault->if_message~get_text
        RECEIVING
          result = lv_error.
      IF lv_error IS NOT INITIAL.
        MOVE lv_error TO e_error_message.
      ENDIF.

  ENDTRY.

I don't know if that is because I set_serialization_context. The message was not sent out automatically. It was waiting in the queue. Then I registered the QUEUE. But still can't sent automatically. It even stopped all my queue even registered ones. Now everything stopped sending out automatically, no matter registered or not.

Do you know what caused this issue?

Thanks a lot!

Charles

former_member184681
Active Contributor
0 Kudos

Dear Charles,

Bear in mind that the acknowledgement says whether whole processing in PI, including delivering the message to receiver system, was successful or not. What I mean is that it takes time to process the message. So you will also have to add a WAIT statement after sending a message, but before commit and evaluating acks. Most preferably this would be placed in a loop, repeated several times over a given time period (for instance: wait 10 times, 10 seconds each time, and exit the loop if the ack already came).

One more thing that you might want to consider is acks being final or not (meaning: if delivering a message to receiver failed, but a retry is scheduled by PI, then the error ack is NOT final). You can check this with your variable l_ack_status_simple and its component called is_final (equal 'X' for a final ack).

About those queue problems that you have - I'm pretty sure they are caused by serialization. Unfortunately I cannot help you on that particular topic.

Hope this helps,

Greg

former_member260907
Participant
0 Kudos

Thanks, Greg!

Answers (2)

Answers (2)

former_member184681
Active Contributor
0 Kudos

Hi Charles,

Actually it all depends on the type of the error you want to catch and respond to:

1. Communication error when calling the proxy: your proxy class's method that executes the proxy can throw an exception CX_AI_SYSTEM_FAULT that you need to catch and handle properly in your sender system's code that executes the proxy.

2. Business data validation: should be performed before sending the data, just like Baskar has described. If your data is incomplete from business point of view, you should prevent it from being sent, instead of catching the error in PI.

3. Invalid XML structure: this is precisely what this option "Validation by Integration Engine" is doing. However, all your ABAP structures for calling a proxy are generated automatically, and if you are using them then such error should never occur.

4. Processing error in PI: you can only catch it in PI, unless you either use synchronous communication (which is quite pointless for proxy to file scenario); or you can request sending an acknowledgement from PI to your sender system to be notified about if the message has been processed successfully. For more details on exact coding for such acknowledgements, refer to SAP Help:

http://help.sap.com/saphelp_nwpi71/helpdata/EN/f4/8620c6b58c422c960c53f3ed71b432/content.htm

All in all, I think acknowledgements might be the best option for you to use. Try investigating on them and let us know if you had further questions.

Hope this helps,

Greg

former_member260907
Participant
0 Kudos

Hi Greg,

Yes. That is a very good strategy. I will go for the acknowledgements. Thanks a lot!

Charles.

former_member260907
Participant
0 Kudos

Hi Greg,

The acknowledge method seems not work. When I followed your link and added codes :

l_ack_request = if_wsprotocol_async_messaging=>co_transport_acknowledgment.      lo_async_messaging->set_acknowledgment_requested( l_ack_request ).
....
    lo_ack = cl_proxy_access=>get_acknowledgment( l_msg_id ).
     l_ack_status_simple = lo_ack->get_status( ).

I never got acknowledgement back. Did I miss any codes?

Thanks,

Charles

baskar_gopalakrishnan2
Active Contributor
0 Kudos

You can do validation logic in the outbound proxy and if the error exists, don't send message to PI. This way you stop the message processing if the error occurs at the source end itself. Alert configuration triggers/occurs if the message processing failed due to mapping errors or something went wrong during message processing in between. Your case is at the outbound proxy itself.

former_member260907
Participant
0 Kudos

Thanks, Baskar for quick response. Yes. This makes sense. In the case like the blog mentioned to catch "Alerts for Queue Errors". Do I configure Alert in Ecc or in PI, or both?

Thanks,

Charles

rajasekhar_reddy14
Active Contributor
0 Kudos

When ever you work with Proxy scenarios there is a possibility to get queue errors in both sides ECC / PI .

If you are writing any validation logic then better to write in Proxy program , you can write a program to deal with errors and to send an email in ECC but standard Alert frame work will not work in ECC.

PI side you can deal with using ALERTS but it will not cover Queues errors.

Regards,

Raj

former_member260907
Participant
0 Kudos

Then how do you catch the queue errors? I think this happens very often.

Thanks.