Import BAdI explained

You can use the import BAdI to check values during data import from CSV/Excel-files or copy from clipboard. The check can be executed before the values are expected to be data type compatible in the update BAdI.

For example, you can autocorrect imported values like “Yes”, “YES”, “yes” to binary “1”. Another typical scenario would be to execute data checks, which cannot be done in the Validate step of the update BAdI for some reason. However, it is recommended to do all validations in the Validate step of the update BAdI, since the import BAdI is triggered only during the import for clipboard, CSV- or Excel-files.

Filter

As you have learned, the BAdI is not started until the filter criteria are met. In the Filter Values section of BAdI implementation you can define specific selections to ensure the class is executed only for a specific field name, table name and table type.

Filter values for Import BAdI

Although you could leave the FIELDNAME empty and implement the respective logic for different fields inside the BAdI, it is not recommended to do so. This approach will negatively impact the performance, since the BAdI will be executed for every field.

Overview of Executed Steps

The BAdI is executed at different times, so called I_STEPS. In step 1, you have access to data before it is converted to data type compatible format, so you can implement a logic to change values to make them data type compatible. For example, you can translate string values like “Yes” to binary “1”.

Then, import validation is called to do data type check and autocorrections, like adding currency to key figures. Furthermore, a message with validation results is generated.

In the step 2, you can access the generated messages and adjust them if necessary. Afterwards, the imported data is updated on the database level and the update BAdI is called.

Import Steps

Parameters

In the table below you can find the explanation of parameters utilized by the Import BAdI.

Property

Type

Description

Possible Values

I_TECHNAME

CHAR 30

Technical name of the table (e.g. /BIC/AZOMACOST2)

 

I_TABNAME

CHAR 30

Table name (e.g. ZOMACOST)

 

I_TTYPE

CHAR 10

Table Type

DDIC    Table of Data Dictionary

DSO    DSO (Advanced or Classic)

CUSTOM    Custom (can be used for Views, etc.)

IOBJ_ATT    InfoObject Attributes

IOBJ_TXT    InfoObject Texts

IS_FIELDS_INFO

Structure

Field information, you can find detailed explanation of respective fields here

 

I_STEP

CHAR 1

Step

1    Before auto correction and data type validity check - import

2    After auto correction and data type validity check - import

I_VALUE

STRING

Field Value before conversion/validation

 

I_TABIX

INT4

Row

 

E_SKIP

BOOLEAN

Skip further processing

X skip further processing

E_VALUE

ANY

Field Value after conversion/validation

 

CT_VALIDATION

Table

Table for validation messages, see next table for details

 

 

CT_VALIDATION Explained

The table below explains CT_VALIDATION parameters

Property

Type

Description

Possible Values

ROWIDX

INT4

Row number

 

COLUMN

CHAR 30

Field name

 

TYPE

CHAR 30

Message type

WARNING    Warning

ERROR    Error

INFO    Info

SUCCESS    Success

HDR

STRING

Message header

 

MSG

STRING

Message

 

 

Code Snippet

When implementing your own BAdI logic, you can use the snippet below as an example. Here, we change the cost area “Test Company CA” automatically to 9999 and pass a message to the user.

DATA:  ls_validation TYPE /nly/ts_validation.
IF I_STEP = 1.
IF i_value = 'Test Company CA'.
e_value = '9999'.
ls_validation = VALUE #( rowidx = i_tabix
column = is_fields_info-fname
hdr = 'Value was mapped. '
msg = 'The Cost Area "Test Company CA" was changed to value "9999" in a custom BADI Exit. This showcases the ability to import and map values that are not even data type compatible at source. cost area CHAR4 '
type = /nly/cl_table_rest_v3=>co_msg_type_warning
).
APPEND ls_validation TO ct_validation.
ENDIF.
ENDIF.

NextTables BAdI Reference