Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Exception handling for Inbound IDocs

Former Member
0 Kudos

Dear Forum Members!

We are implementing some additional functionality to work with Inbound IDocs in CRM 4.0. For some reason, we first collect IDocs in status 64 and then trigger its processing in Z-program sequentially by calling standard FM <b>IDOC_START_INBOUND</b>.

Most of the Inbound IDocs are CRMXIF_ORDER_SAVE (Business Transactions). Sometimes we receive erroneous IDocs with, for example, Appointment Start Date before End Date.

Such IDocs block inbound processing, because the called FM is aborted, and no status change is written to the problematic IDoc.

We tried to call FM <b>IDOC_START_INBOUND</b> specifying <b>EXCEPTIONS ERROR_MESSAGE = 10</b> with no avail. The results are the same - at FM execution Abort Message Box is shown, and then control is moved from the debugger to the main SAP GUI.

Could you give an advice or a recommendation on how to intercept such types of exceptions calling SAP FM's?

Thank you very much!

My best regards, Andrei Dirotchka

5 REPLIES 5

Former Member
0 Kudos

Hi Andrei,

I am not sure I eaxctly got your problem. Does it have to do something with the inbound processing function module? In case it has, I prefer to go with a Z-function module copying the original function and then handling the errors appropriately in the way I want to.Let me know it is not something you wanted to mean.

Former Member
0 Kudos

Your call must be like this


CALL FUNCTION 'IDOC_START_INBOUND'
* EXPORTING
*   PI_INBOUND_PROCESS_DATA             = ' '
*   PI_CALLED_ONLINE                    = ' '
*   PI_DO_COMMIT                        = 'X'
*   PI_START_EVENT_ENABLED              = 'X'
*   PI_ORG_UNIT                         = ' '
*   SUCC_SHOW_FLAG                      = ' '
  TABLES
    t_control_records                   =
    T_DATA_RECORDS                      =
 EXCEPTIONS
   INVALID_DOCUMENT_NUMBER             = 1
   ERROR_BEFORE_CALL_APPLICATION       = 2
   INBOUND_PROCESS_NOT_POSSIBLE        = 3
   OLD_WF_START_FAILED                 = 4
   WF_TASK_ERROR                       = 5
   SERIOUS_INBOUND_ERROR               = 6
   OTHERS                              = 7
          .
IF sy-subrc <> 0.
 MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

Note that I uncommented the EXCEPTIONS part of it. Is this how your call looks like?

0 Kudos

Dear Adavi!

Our call, to be precise, is given below:


CALL FUNCTION 'IDOC_START_INBOUND'
   EXPORTING
     pi_inbound_process_data             = s_tede2
     pi_called_online                    = ' '
     pi_do_commit                        = 'X'
     pi_start_event_enabled              = 'X'
*     pi_org_unit                         = ' '
     succ_show_flag                      = ' '
  TABLES
    t_control_records                   = control_rec
*     T_DATA_RECORDS                      =
   EXCEPTIONS
     invalid_document_number             = 1
     error_before_call_application       = 2
     inbound_process_not_possible        = 3
     old_wf_start_failed                 = 4
     wf_task_error                       = 5
     serious_inbound_error               = 6
     error_message                       = 10
     OTHERS                              = 11
          .
IF sy-subrc <> 0.
  MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
          WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.

This is the coding which causes the uncatchable exception.

I would appreciate if you give some ideas on how to intercept abort error message created in inner procedure call.

Thank you!

My best regards, Andrei Dirotchka

0 Kudos

Hi,

It might be the code inside this function module which might be causing the issues.

Test the IDOC using WE19 transaction in debug mode and place a break point at MESSAGE statement and once it stops at the place where its throws the errror trace it back and you should be able figure out the error.

Regards,

Ravi

Note : Please mark the helpful answers

0 Kudos

Dear Ravi!

Thank you for your remark!

We already performed the tracing and figured out the part of code which causes this ABORT message to be thrown.

It is the following:

call function 'TRANSACTION_END'
           exporting
                transaction_id = transaction_id
           exceptions
                others         = 1.

This is SAP code in Standard FM, IDOC_INPUT.

My question was - how to intercept these exceptions in general. Since we are dealing with 3rd party system , we cannot guarantee that all submitted data is correct. So, we would like to make our coding handle such errors without canceling further execution.

Suggestions to this question are appreciated!

My best regards, Andrei Dirotchka