What is ABAP Database Connectivity (ADBC)?

In SAP, ADBC stands for ABAP Database Connectivity. It is a class-based API that allows ABAP programs to directly execute Native SQL statements on the underlying database.

🔎 What ADBC Is

• Definition: ABAP Database Connectivity (ADBC) is a modern interface in SAP that provides direct access from ABAP code to the database using SQL.
• Purpose: It bridges ABAP applications with databases like SAP HANA, enabling developers to run complex queries and leverage advanced database features.
• Type of API: Class-based, meaning it uses ABAP Objects (OO) rather than traditional procedural calls.

⚙️ Key Features

• Direct SQL Execution: Developers can run SQL statements (SELECT, INSERT, UPDATE, DELETE) directly from ABAP without going through Open SQL.
• Performance: Optimized for SAP HANA’s in-memory computing, allowing faster data retrieval and manipulation.
• Flexibility: Supports database-specific features that are not available in standard Open SQL.
• Integration: Useful when ABAP applications need to interact with external or advanced database functions.

📌 Example Usage

A typical ADBC workflow in ABAP involves:

1. Creating a connection to the database using CL_SQL_CONNECTION.
2. Preparing a statement with CL_SQL_STATEMENT.
3. Executing the query and fetching results with CL_SQL_RESULT_SET.

DATA: lo_con TYPE REF TO cl_sql_connection, lo_stmt TYPE REF TO cl_sql_statement, lo_res TYPE REF TO cl_sql_result_set. lo_con = cl_sql_connection=>get_connection( ). lo_stmt = lo_con->create_statement( ). lo_res = lo_stmt->execute_query( 'SELECT * FROM my_table' ).

🚀 Why It Matters

• For Developers: ADBC provides more control and efficiency when working with large datasets or advanced database features.
• For Businesses: It enables real-time analytics and faster application performance, especially critical in SAP HANA environments.

Outbound and Inbound Status when IDOC Created

The following are the status codes for an Idoc to be in,since its creation.

0-49 indicates an Outbound idoc and 50-75 as Inbound one.

The Outbound status as follows:

00     Not used, only R/2

01     IDoc generated

02     Error passing data to port

03     Data passed to port OK

04     Error within control information of EDI subsystem

05     Error during translation

06     Translation OK

07     Error during syntax check

08     Syntax check OK

09     Error during interchange handling

10     Interchange handling OK

11     Error during dispatch

12     Dispatch OK

13     Retransmission OK

14     Interchange Acknowledgement positive

15     Interchange Acknowledgement negative

16     Functional Acknowledgement positive

17     Functional Acknowledgement negative

18     Triggering EDI subsystem OK

19     Data transfer for test OK

20     Error triggering EDI subsystem

21     Error passing data for test

22     Dispatch OK, acknowledgement still due

23     Error during retransmission

24     Control information of EDI subsystem OK

25     Processing despite syntax error (outbound)

26     Error during syntax check of IDoc (outbound)

27     Error in dispatch level (ALE service)

28     Not used

29     Error in ALE service

30     IDoc ready for dispatch (ALE service)

31     Error - no further processing

32     IDoc was edited

33     Original of an IDoc which was edited

34     Error in control record of IDoc

35     IDoc reloaded from archive

36     Electronic signature not performed (timeout)

37     IDoc added incorrectly

38     IDoc archived

39     IDoc is in the target system (ALE service)

40     Application document not created in target system

41     Application document created in target system

42     IDoc was created by test transaction

Inbound status of an Idoc

50     IDoc added

51     Application document not posted

52     Application document not fully posted

53     Application document posted

54     Error during formal application check

55     Formal application check OK

56     IDoc with errors added

57     Test IDoc: Error during application check

58     IDoc copy from R/2 connection

59     Not used

60     Error during syntax check of IDoc (inbound)

61     Processing despite syntax error (inbound)

62     IDoc passed to application

63     Error passing IDoc to application

64     IDoc ready to be transferred to application

65     Error in ALE service

66     IDoc is waiting for predecessor IDoc (serialization)

67     Not used

68     Error - no further processing

69     IDoc was edited

70     Original of an IDoc which was edited

71     IDoc reloaded from archive

72     Not used, only R/2

73     IDoc archived

74     IDoc was created by test transaction

75     IDoc is in inbound queue.

An example code of using Function Module MASTER_IDOC_DISTRIBUTE

DATA:

Z_SEGNAME(7) TYPE C VALUE 'SEGMENT',

Z_MESTYPE(9) TYPE C VALUE 'MESSAGE',

Z_IDOC_TYPE(8) TYPE C VALUE 'IDOC'.

DATA:

IDOC_CONTROL LIKE EDIDC,

T_COMM_CONTROL LIKE EDIDC OCCURS 0 WITH HEADER LINE,

IDOC_DATA LIKE EDIDD OCCURS 0 WITH HEADER LINE.

*Reads data from Z table

SELECT *

FROM ZTABLE

INTO TABLE L_ZTABLE.

*Set the control data info required for the distribution

IDOC_CONTROL-MESTYP = Z_MESTYPE.

IDOC_CONTROL-DOCTYP = Z_IDOC_TYPE.

*Populate the IDoc

LOOP AT L_ZTABLE.

  CLEAR IDOC_DATA.

  IDOC_DATA-SEGNAM = Z_SEGNAME.

  IDOC_DATA-SDATA = ZTABLE. 

  APPEND IDOC_DATA.

ENDLOOP.

*Deliver the IDOC as defined in distribution model/partner profile

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' IN UPDATE TASK

  EXPORTING

    MASTER_IDOC_CONTROL = IDOC_CONTROL

  TABLES

    COMMUNICATION_IDOC_CONTROL = T_COMM_CONTROL  

    MASTER_IDOC_DATA = IDOC_DATA

  EXCEPTIONS

    ERROR_IN_IDOC_CONTROL = 1

    ERROR_WRITING_IDOC_STATUS = 2

    ERROR_IN_IDOC_DATA = 3

    SENDING_LOGICAL_SYSTEM_UNKNOWN = 4

    OTHERS = 5.

IF sy-subrc = 0.

COMMIT WORK.

ENDIF.

How to display additional information about IDoc processing in the Application Log

Summary

This document describes how to to write down the messages issued by the IDoc inbound processing in the application log, improving the level of monitoring .

It contains information about customizing settings as well code snippets that might be integrated in your custom  IDoc inbound applications.

Prerequisites

The status record with the message long text  should be sufficiently explanatory to describe the processing results of an IDoc, but whenever this is not possible,

Figure 1 – Two error messages for the same inbound processing in EDIDS table

for example when the IDoc module generates several error messages in a single inbound processing, it could be useful to populate the application log instead of creating a single status record for each message issued as shown below (Fig. 2).

Figure 2 – How the IDoc statuses appear

1. How SAP works

1.1 Instantiation

The SAP standard already implements this feature; the developers need only to insert the log object number (generated programmatically within the IDoc inbound ABAP module) in the field APPL_LOG of the EDIDS - IDoc status table (Fig. 3).

Figure 3 - The APPL_LOG field in the EDIDS

1.2 Navigation

The IDoc monitoring tool is designed to allow the navigation from the IDoc to the application log. As soon as the tool detects that the field APPL_LOG of the

Figure 5 – Navigation pushbutton in the status record

EDIDS table is filled, it activates a specific bar button (Fig. 5) which allows the direct navigation from the detail screen of the status record to the Application Log (Fig. 6).

Figure 6 – Application Log evaluation accessed by IDoc monitoring

2. Required Customizing settings

Every log entry is linked with an object and possibly one of its subobjects. In the transaction SLG0 you can define entries for your applications in the application log.

2.1 Define the application log object

In this example a new entry "ZEDI" was created.

Figure 7 – object ZEDI – "EDI Integration" created

2.2 Define the corresponding sub object

Sub objects are simply further classifications of the application log object; in this case the inbound specific sub-object ZSD_945_IDOC was created.

Figure 8 – Sub object ZSD_945_IDOC – EDI 945 Inbound

 Y* and Z* are reserved for customer names.

3. Inbound function module processing logic review

Depending on the result of the business object update phase, the inbound processing Function Module fills the IDoc status record (type BDIDOCSTAT)  appending it to the corresponding internal table IDOC_STATUS as shown in the below example. (Fig. 9)

Figure 9 – Filling the IDOC_STATUS internal table

If the inbound application generates more than one error message, then you might have more than one record in the internal table IDOC_STATUS.

So taking this in mind, in order to write the application log, the developer has to implement the following steps:

• Remove the existing IDOC_STATUS internal table entries and store them in the application log
• Refresh the internal table IDOC_STATUS
• Create a new single status record message containing the pointer to the instance of the application log created

4. Code Snippet

4.1 Defining constants for log entry creation

The log object and the corresponding subobject should be declared as constants in your IDoc inbound ABAP application (see above “Required customizing settings”).

constants:  edi_object         type balhdri-object    VALUE 'ZEDI',
            945_subobject_idoc LIKE balhdri-subobject VALUE 'ZSD_945_IDOC'.

4.2 Calling the application log writing routine

Your IDOC_STATUS internal table contains a lot of messages, so it’s time to feed the application log; place the call to the routine that creates the application log at the end of the inbound processing Function Module

"Write Status records with Application Log
PERFORM _idoc_status_prepare
           TABLES    idoc_status           "Changing
           USING     idoc_contrl
                     error_subrc.          "OK = 0 ; KO <> 0

 ERROR_SUBRC is a local variable that indicates that at least one error occured

4.3 Application log  creation routine

The source code inside the above abap routine has been taken from the inbound processing Function Module IDOC_INPUT_INVOIC_MRM to post Inbound Vendor EDI Invoices.

*&---------------------------------------------------------------------*
*&      Form  _IDOC_STATUS_PREPARE
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->T_IDOC_STATUS  text
*      -->I_IDOC_CONTRL  text
*      -->I_SUBRC        text
*----------------------------------------------------------------------*
FORM _idoc_status_prepare TABLES       t_idoc_status    STRUCTURE bdidocstat
                           USING        i_idoc_contrl    LIKE edidc
                                        i_subrc          LIKE sy-subrc.


  DATA: lt_balmi TYPE TABLE OF balmi,
       ls_balmi LIKE LINE OF lt_balmi,
       lt_balnri TYPE TABLE OF balnri,
       ls_balnri LIKE LINE OF lt_balnri.

  DATA: f_appl_log  TYPE bdidocstat-appl_log.

  CHECK  LINES( t_idoc_status ) > 1. 

  CALL FUNCTION 'APPL_LOG_INIT'
      EXPORTING
           object    = edi_object
           subobject = 945_subobject_idoc.

  LOOP AT t_idoc_status.
      CLEAR ls_balmi.
      MOVE-CORRESPONDING t_idoc_status TO ls_balmi.
      APPEND ls_balmi TO lt_balmi.
  ENDLOOP.

  SORT lt_balmi .
  DELETE ADJACENT DUPLICATES FROM lt_balmi COMPARING ALL FIELDS.

  CALL FUNCTION 'APPL_LOG_WRITE_MESSAGES'
      EXPORTING
           object           = edi_object
           subobject        = 945_subobject_idoc
           update_or_insert = 'I'
      TABLES
           messages         = lt_balmi.

  CALL FUNCTION 'APPL_LOG_WRITE_DB'
      EXPORTING
           object                = edi_object
           subobject             = 945_subobject_idoc
      TABLES
           object_with_lognumber = lt_balnri.

  READ TABLE lt_balnri INTO ls_balnri INDEX 1.
  CHECK sy-subrc = 0.

  CLEAR t_idoc_status.
  REFRESH t_idoc_status.

  IF i_subrc = 0.
      t_idoc_status-status   = '53'.
      t_idoc_status-msgty    = 'S'.
  ELSE.
      t_idoc_status-status   = '51'.
      t_idoc_status-msgty    = 'E'.
  ENDIF.

  t_idoc_status-docnum   = i_idoc_contrl-docnum.
  t_idoc_status-msgid    = 'EA'.
  t_idoc_status-msgno    = '066'. “Messages from IDoc processing can be found in application log
  t_idoc_status-msgv1    = ' '.
  t_idoc_status-msgv2    = ' '.
  t_idoc_status-msgv3    = ' '.
  t_idoc_status-msgv4    = ' '.
  t_idoc_status-segfld   = ' '.
  t_idoc_status-uname    = sy-uname.
  t_idoc_status-repid    = sy-repid.
  t_idoc_status-routid   = 'ZSDN_IDOC_INPUT_XXX_945'. "My inbound processing FM!
  t_idoc_status-appl_log = ls_balnri-lognumber.       "Newly created LOG Instance!
  APPEND t_idoc_status.

ENDFORM.                               " _IDOC_STATUS_PREPARE

(...) 

5. Authorization Objects

The user should be able to diplay the application logs entries by the S_APPL_LOG authorization

6. Related content

Application Logging

Create and view LOG using SLG0 and SLG1 transaction

Conclusions

The IDoc inbound processing application writes a log for your objects; as IDocs can be linked to application objects, the corresponding log can be Displayed from the IDoc.

Hope I have shed some light onto “IDoc application log”.


Ref: http://scn.sap.com/docs/DOC-35102