Symptom
The purpose of this Knowledge Base Article is to explain how to use the BAdI for Selection to apply additional logic for the data selection in the SAP S/4HANA migration cockpit – Migrate Data Directly from SAP System (Direct Transfer).
"Image/data in this KBA are from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental."
Environment
- SAP S/4HANA
- "Migrate Your Data – Migration Cockpit" app
- Migrate Data Directly from SAP System
- "Migrate Your Data – Migration Cockpit" app
Note: This functionality is available from SAP S/4HANA Cloud Public Edition seit 2402 verfügbar and therefore, this KBA is valid from this release.
Resolution
The BAdI for Selection allows you to apply additional logic for the data selection in the SAP S/4HANA migration cockpit. If the filtering logic or the simple selection criteria offered in the Migration Object Modeler (transaction: LTMOM) are not sufficient to support your data selection requirements, you can implement ABAP code on the source system in the BAdI for selection.
Overview
Technical use cases
- You have a list of data instances in the source system which you do not want to transfer, and which cannot easily be filtered out using the standard filter options in the migration object modeler (transaction: LTMOM)
- You have a list of instances in the source system which you only want to transfer, and all other instances shall not be transferred
- Your data selection logic depends on cross-reference checking in the source system which can only be done in coding
How it works
During the selection process, the migration cockpit´s selection logic determines in the source system which data instances of a migration object must be transferred to the SAP S/4 HANA system. The key information of those instances is temporarily stored in the source system (in so-called preselection tables). Later the following processing step takes care of transferring the data based on the stored key information.
Your implementation of the BAdI for Selection controls for each SAP ERP source data table which key information is stored or possibly rejected or altered of the data instances which shall be transferred to the SAP S/4 HANA system.
You can activate the BAdI for selection per project and per the SAP ERP data table of the source system in the migration object modeler.
Use of BAdI versus use of skip rules
Using the BAdI you can influence the data selection on the source system. You can control if data will leave the system at all. The options to influence the selection are ample as you can add, remove, or alter data in the preselection tables.
Skip rules will be called on the SAP S/4HANA target system to skip certain instances from being created on the target system. You can only restrict the data set that has been chosen for transfer to the SAP S/4HANA system.
Technical Implementation
STEPS:
- Create a new BAdI implementation for enhancement spot CNV_OR_OBT using the standard transaction SE19 in your source system:
.
- Provide the name and description for your enhancement implementation on the creation popup:
.
- Choose CNV_OR_OBT_PRESEL_BADI in a dropdown list for BAdI definition:
- Provide a name for your BAdI implementation and the name for your new implementation class:
Your BAdI enhancement implementation will be created when you confirm the popup.
- After that, you select tab Enh. Implementation Elements and double-click node Filter Val. and create a new filter combination:
- Double-click your new combination and provide filter value with comparator '=':
- Save your changes and activate your enhancement implementation using the corresponding button in the application toolbar.
Now you can go to your new class and implement the required logic for data selection.
- Double-click node Implementing Class, then double-click the class method (there is only one method IF_CNV_OR_OBT_PRESEL_BADI~PROCESS_DATA):
The method PROCESS_DATA has several importing parameters that contain different technical information and one changing parameter that contains data of the current table. These parameters are filled by the system during the call. The only relevant importing parameter, in this case, is IV_DATAMODEL_COMMENT that contains names of your migration object and the current table concatenated in one string: '<migration object name>-<current table name>':
Your coding could look as follows. Note that you need to use the technical object name in your coding:
In this project example, there is only one migration object Bank. The root source table is BNKA. Thus, one can filter data to select instances with German country/region key (field BANKS = 'DE') or with bank number starting with '03':
Control system
- Activate the BAdI exit on project level using transaction LTMOM in your control system.
- Choose BAdI Selection Exit is Active and provide filter value that you have created in your source system:
With this setting, your BAdI exit becomes active for all migration objects that belong to your project. Note that you cannot create a separate BAdI exit or deactivate BAdI exit for one specific object. As soon as you activate the BAdI exit on project level, it is automatically activated for the following source tables of all your migration objects:
- root tables;
- source tables that have some selection criteria assigned to them (filtering logic or additional selection criteria for at least one field);
- source tables that have child tables with selection criteria assigned to them and selection scope that includes parent tables.
It means that your method implemented in the source system will be called during selection for each of the tables above. However, it is up to your implementation, if the selected data is changed or not.
In case your table does not satisfy the criteria above, the BAdI exit remains inactive for it. You need to activate it manually on the Selection Settings popup:
Note that if you activate BAdI exit for a table with a selection scope including parent tables, BAdI exit becomes automatically active for all its parent tables. In the example above we have manually activated the BAdI exit for table ADR2. Since its selection criteria scope includes parent tables, BAdI exit is activated automatically for table ADRC:
If you start a selection after all these settings, the method will be called for tables BNKA, ADRC, and ADR2. Since you have implemented some logic only for table BNKA, data of ADRC and ADR2 tables remain unchanged. The result in the SAP S/4HANA Migration Cockpit is:
Note that all other selection criteria (filtering logic and additional selection criteria) are applied to data before BAdI exit. It means that table CT_DATA in the method IF_CNV_OR_OBT_PRESEL_BADI~PROCESS_DATA does not contain at runtime all table entries existing in your source system, but only those entries that satisfy filtering logic and additional selection criteria if any of them exist. For example, you add the following additional selection criteria for country key (field BNKA-BANKS):
In this case table CT_DATA at runtime will not have any table entries with country key AU. The result in the SAP S/4HANA Migration Cockpit is:
See Also
- 2747566 - SAP S/4HANA Migration Cockpit: Composite Note for Transfer Data Directly from SAP System
- Key knowledge points and materials for users about the Migration Object Modeler (transaction: LTMOM) available in KBA 2576565
Keywords
Migration Cockpit, BAdI, Direct Transfer, BAdI for Selection, additional logic for the data selection, ABAP code, Migrate Data Directly from SAP System, Migrate your data - migration cockpit, SAP S/4HANA Migration Cockpit, Migrate your data , KBA , CA-LT-MC , S/4HANA Migration Cockpit , How To