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.
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.
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.
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.
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 |
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 |
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.
Which License is needed for this feature Professional ✘ | Enterprise ✔