There are two kinds of customer fields:
o Fields as part of the customer structure of the IS Migration Workbench o Fields as part of an enhancement of the standard structure or table
Customer fields are defined in the IS Migration Workbench and are visible and accessible only in the load program, whereas the fields of an enhancement of the solution can be processed not just in the IS Migration Workbench but in either dialog transactions and/or batch processes.
4.4.1 Additional Fields in the IS Migration Workbench
Figure 4-10 shows how to define an additional field in the customer structure of the ACCOUNT migration objects in the IS Migration Workbench. Each time you add a new field, the layout of the related structure in the import file changes accordingly. For more information about the Customer Field field rule, see chapter 2.4.7 Field Rule Customer Field.
1. Double-click the ACCOUNT migration object
2. Double-click the relevant structure to mark it, choose Field Create
3. Enter the name of the new field and choose Create
4. Mark the Generate field and enter the length of the new field. The Customer field field rule is selected automatically.
5. Choose Save and return to the main screen to display the added field.
6. Now you can use a field rule to access the newly created field.
Figure 4-10: Adding a Field to the Customer Structure
4.4.2 Enhancement Fields in the Solution
Fields are part of the solution and have been included in a customer-include. They become part of the ABAP dictionary (DD) and a part of the automation data. The IS Migration Workbench recognizes automatically a new field in the automation structure during a copy of a migration object. If you have added a field after the migration object has already been copied, the field has to be added manually using the Compare with DDIC function. Double-click the related structure to mark it and choose Auto structure Compare with DDIC.
Usually, it is not enough just to include the field in a customer-include. In most cases, it is mandatory implement either user-exits or events relevant for direct input in order to process the customer fields. This implementation is not part of the migration Customizing, it is part of the development of the solution.
The following chapters show examples of what is required when you are enhancing the solution with new fields.
4.4.3 Enhancement Fields for Technical Master Data (SAP for Utilities)
There are two relevant enhancements (transaction CMOD) to process a new field for a connection object:
o Enhancement ECIIFLOT to add the new fields in the customer-include CI_IFLOT
o Enhancement ES550001 (component EXIT_SAPLES55_008) to process the fields during direct input.
Both of the enhancements have to be implemented in order to save the contents of the new fields, for example, in the EHAU database table. Figure 4-11 shows a code snippet, that transfers the contents of the custom fields in user-exit 008 during direct input.
*& Include ZXES55U08
*&---*
DATA: lv_ci_iflot TYPE ci_iflot.
MOVE-CORRESPONDING x_ehaud TO lv_ci_iflot.
MOVE-CORRESPONDING lv_ci_iflot TO xy_sub_obj-ehau.
Figure 4-11: Example of an Implementation of Enhancement ES550001
You must apply a similar solution for many of the enhancements in SAP for Utilities.
Implement, for example, component EXIT_SAPLES65_007 in enhancement ES650001 to process custom fields for device locations and component EXIT_SAPLES60_007 in enhancement EMDP0001 to process custom fields in premises.
4.4.4 Enhancement Fields for a Point of Delivery (SAP for Utilities)
A deregulated point of delivery (PoD) is created automatically when creating an installation with the INSTLN migration object. The automation data structure of the INSTLN migration object does not include the customer-include CI_EUIHEAD in which you added the customer fields. Therefore, a direct migration of the customer field with the INSTLN migration object is not possible.
Execute the migration of customer fields for a PoD in the following way:
o Create the point of delivery (POD migration object) Transfer the customer fields in the HEADER structure
Transfer an external unique identification in the EXT_UI field of the UIEXT structure.
o Create the installation (INSTLN migration object) and link the created PoD to the installation in transferring external unique identification in the EXT_UI field of the POD structure, you assigned to the created PoD in the previous step.
Alternatively, you can create the installation with the INSTLN migration object leaving the customer fields initial, and then populate the customer fields in the existing PoD with the PODCHANGE migration object.
One more alternative is to taking advantage of the method CHANGE_AUTODATA of the BAdI (business add-in) ISU_EDM_POD_CUSTOMER. As explained above, you cannot pass the information for the customer fields directly through the automation data to the application due to the missing customer-include in the automation data structure of the INSTLN migration object. Nevertheless, you can implement the migration of the customer fields of a PoD also in the following way:
o Add the customer fields of the customer-include as customer defined fields with the Customer Field field rule to the DATA structure.
o Add per customer field the code of Figure 4-12 to the postprocessing code of the DATA structure.
call function ‘ISU_MIG_PARAMETER_SET’
exporting
x_element = ‘<name_of_customer_field>’
x_field = $C$-<name_of_customer_field>.
Figure 4-12 Postprocessing Code for DATA structure
o Implement the method CHANGE_AUTODATA of the BAdI ISU_EDM_POD_CUSTOMER based on the ABAP code as shown in Figure 4-13.
METHOD if_ex_isu_edm_pod_customer~change_autodata.
* local data definition DATA: lv_active TYPE c,
lv_object TYPE temob-object.
DATA: lv_ci_euihead TYPE ci_euihead.
* check whether data migration is active CALL FUNCTION 'ISU_MIG_STATUS'
CALL FUNCTION 'ISU_MIG_PARAMETER_GET' exporting
x_element = '<name_of_customer_field>' importing
x_field = lv_ci_euihead-<name_of_customer_field>.
* move customer field to auto data
MOVE-CORRESPONDING lv_ci_euihead TO ch_autodata.
ENDIF.
ENDMETHOD
Figure 4-13 MethodCHANGE_AUTODATA of BAdIISU_EDM_POD_CUSTOMER
In the postprocessing code of structure DATA, the field content of the customer field is moved to a container, picked up from the container in the method CHANGE_AUTODATA and moved finally to the auto data of the BAdI. The ISU_MIG_STATUS function module returns in the Y_ACTIVE parameter the information whether the application has been called from a load program of the IS Migration Workbench. The name of the migration object is returned in the Y_OBJECT parameter. However, deactivate the BAdI once the data migration finished because the BAdI is not required after the go-live.
The third alternative is not the best way to implement the migration of customer fields for a PoD, because the presented implementation is not following the standard programming guidelines. However, considering the aggravating circumstances not having the customer-include available in the automation data structure of the INSTLN migration object, this alternative still might be the most efficient way to migrate customer fields for a PoD.
4.4.5 Enhancement Fields for Business Partners
The Easy Enhancement Workbench (EEW) allows you to extend the data model of the Business Partner easily by adding new fields or tables, and to integrate them into the business process.
The Easy Enhancement Workbench is a development tool with which SAP applications for business partner, business partner relationship, and others, can be extended in a simple manner. The customer enhancements to a Business Object are defined via wizards. The
Workbench then does all development work for the user; databank tables, screens, and application logic are created automatically. Finally, the customer enhancement is included in the SAP standard. The type of extension is predefined. In most cases, the customer is offered the possibility to add user-defined databank tables or fields The Easy Enhancement Workbench (transaction EEWB) enables users without ABAP knowledge to extend the SAP standard.
The SAP notes 510095 and 119805 give directions for an implementation of enhancements with BDT if the Easy Enhancement Workbench is not used.
4.4.6 Enhancement Fields for Contract Accounts
Use the Business Data Toolset (BDT) to implement the required enhancements. Ensure that at least one event at the DINP2 generation point is implemented. For more information, see the developer handbook of the Business Data Toolset in the online documentation. The code snippet in Figure 9-2 can be used as a basis for an own implementation.
5 Migrating Custom Tables (z-Table)
5.1 Motivation
In almost any data migration, you must populate custom database tables with data from the legacy system. Often custom database tables are used to store historical data of the legacy system, which does not fit into the SAP data model. Sometimes it cannot even be cleansed sufficiently prior to going live to be passed through the SAP application. More often custom tables are part of the implementation and additional data is stored for one more business objects. In either case, these custom database tables have to be populated during data migration.
There are two ways to migrate data into the custom table efficiently using the IS Migration Workbench:
o Using an existing (standard) migration object o Using an own migration object
A custom program is an option but this not the best solution in most cases. This is because in many cases, fields of a custom database table contain a reference to existing business objects. Additional development would be required to ensure the replacement of the oldkey with the correct newkey. In addition, it is not only preferable using the same file format for all data to be migrated into the SAP system but also taking advantage of the functions of the IS Migration Workbench in error handling, statistics, and parallel load.