4 Replies Latest reply: Aug 29, 2006 8:48 AM by Vishal Tyagi RSS

Handling errors in BDC?

Vijay Shenoy
Currently Being Moderated



How do handle errors in Session and call Transaction method?



  • Re: Handling errors in BDC?
    Sailatha Nagasamudram
    Currently Being Moderated



      In Session method, error log will be generated by the system with the details of the error & the description, In call transaction this needs to be done handled explicitely using the structure BDCMSGCOLL, you can declare an internal table to trap the messages with the type BDCMSGCOLL and use fm FORMAT_MESSAGE to get it in to an internal table,


    Refer the following statment,

    Call transaction 'TCode'

    using IT_BDCDATA

    mode A/N/E

    update S/A

    messages into IT_BDCMSGCOLL.


    Hope this helps,



  • Re: Handling errors in BDC?
    Mrutyunjaya Tripathy
    Currently Being Moderated




    Session method.

    1) synchronous processing.

    2) can tranfer large amount of data.

    3) processing is slower.

    4) error log is created

    5) data is not updated until session is processed.


    Call transaction.

    1) asynchronous processing

    2) can transfer small amount of data

    3) processing is faster.

    4) errors need to be handled explicitly

    5) data is updated automatically

    Batch Data Communication (BDC) is the oldest batch interfacing technique that SAP provided since the early versions of R/3.   BDC is not a typical integration tool, in the sense that, it can be only be used for uploading data into R/3 and so it is

    not bi-directional. 


    BDC works on the principle of simulating user input for transactional screen, via an ABAP program.


    Typically the input comes in the form of a flat file. The ABAP program reads this file and formats the input data screen by screen into an internal table (BDCDATA). The transaction is then started using this internal table as the input and executed in the background. 


    In ‘Call Transaction’, the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling.  It can also be used for real-time interfaces and custom error handling & logging features. Whereas in

    Batch Input Sessions, the ABAP program creates a session with all the transactional data, and this session can be viewed, scheduled and processed (using Transaction SM35) at a later time. The latter technique has a built-in error processing mechanism too. 


    Batch Input (BI) programs still use the classical BDC approach but doesn’t require an ABAP program to be written to format the BDCDATA. The user has to format the data using predefined structures and store it in a flat file. The BI program then reads this and invokes the transaction mentioned in the header record of the file. 


    Direct Input (DI) programs work exactly similar to BI programs. But the only difference is, instead of processing screens they validate fields and directly load the data into tables using standard function modules. For this reason, DI programs are much faster (RMDATIND - Material Master DI program works at least 5 times faster) than the BDC counterpart and so ideally suited for loading large volume data. DI programs are not available for all application areas. 



    The BDCMSGCOLL does not have the messages text. It has only the message type, number and message parameters.

    You have to read the message text.  (recall that the database table T100 stores all the messages.)

    There are more than one method of doing this.


    Following is the psuedocode for one of the methods.


    LOOP for the internal table IT1 which has data value from flat file.


    call transcation using....

    if SY-SUBRC <> 0.


    Read the dictionary table T100 FOR ALL ENTRIES in BDCMSGCOLL.

    (also use the condition T100-SPRAS  =  SY-LANGU (the log on language. This is because you need only the message texts in English if the user is logged in English language)


    IF message type is E , then, transfer the contents of this particular error record to file x. (TRANSFER......)

    ( Ignore all other messages. Only consider type 'E' messages. Ignore other types of messages.)


    (You can also store the message text from T100 and the error record in another internal table IT2)









  • Re: Handling errors in BDC?
    sree_msh msh
    Currently Being Moderated

    in session method..

    system maintains implicit error log..u need not to main tain any thing for this

    if u want to see forst

    execute ur bdc with session name any in SM35.

    after that select session name and click on error log on application bar.u can fid out all error relevent to ur seseion name.


    in call transaction..

    u have to maintain explicit error..for this

    define a internal table with include structure BDCMSGCOLL...

    mention this internal table in ur call transaction command like this


    call transaction 'xk01' using '<BDCDATA table name>' messages into <BDCMSGCOLL table name> \


    i think tshis will help u

  • Re: Handling errors in BDC?
    Vishal Tyagi
    Currently Being Moderated

    Session Method: No need to write any code for error handling.

    1. Program Creates a session with the uploaded DATA.

    2. Process Session using SM35

    3. Error/status log created by System

    4. Session can be reprocessed for error records

    5. Successful records will not be recreated during re-processing


    CALL Transaction method:

    Need to write error handling. Not very difficult Check SY-SUBRC after CALL TRANSACTION 'TCODE', if SY-SUBRC <> 0, error and capture the same from table BDCMSGCOLL.


    Hope this make some sense.