I would like to describe a really special case of a transformation that is questioned within this community – how to split a record during the load/replication process on the SLT system in two records.
First of all I would like to note, that this is a special case and not implemented as a E2E solution – everything you have to specify to split a record is via ABAP coding. Also this is an expert example – so I will not explain each available transaction in details. Please get trained beforehand with the available documentation.
For the example I used the following scenario – table SFLIGHT is available and should be splitted and appear as two records on the HANA system.
- Create a new configuration or use an existing configuration.
- Table adjustment
Would you just create a second record – this would be a duplicate and cannot be processed (you will get an error msg in the application log). So the only way is to modify an existing key field – but much better for the transparancy is to introduce an additional key field for the target structure on the HANA system.
Very easy to achieve via SLT. Just navigate to transaction IUUC_REPL_CONTENT and enhance the target table structure for your table with a new key field (tab IUUC_TABSTG).
Save your settings.
3. Create an ABAP include + transformation rule
Navigate to transaction SE38 and create a new ABAP include where you define your rule.
When you run a replication, SLT will automatically generate specifiy code, such as internal tables, objects for each table in replication. With the option to define a transformation rule, SLT gives you the option to integrate custom transformation code into the standard process flow.You can look at it like a customer exit. When you define a transformation rule within an ABAP include or via the UI – SLT merge this ABAP coding into the specific flow.
Several interntal tables, structures and counters exist. To add a new field, you have to increse the internal counter and fill the a record manually into the internal table. The second record will be automatically inserted into the internal table – execute by the usual process flow.
First of all we have to increase the internal counter by 1.
R_SFLIGHT_NO = R_SFLIGHT_NO + 1.
//SLT uses an internal counter for processing with the convention R_<table>_NO
_WA_R_SFLIGHT–_RECNO = R_SFLIGHT_NO.
//in the corresponding internal workarea, you have to fill _WA_R_<table>-_RECNO
Afterwards you fill the new key field with the entry for the first record.
_WA_R_SFLIGHT–key = ‘0001’.
// This is the part where you are flexible with the input value
– e.g. you could also think about a scenario where you concatenate the
new key field based on existing other values of the record
– you can do what ABAP allows you 😉 .
To access a value just follow this convention: _WA_R_<table>-<field>
In the next step you insert the changed record into the internal table (convention: _ITB_R_<table>) manually.
INSERT _WA_R_SFLIGHT INTO TABLE _ITB_R_SFLIGHT.
The last step is to override the key field with a new value. This lead to a new uniquie record.
_WA_R_SFLIGHT–key = ‘0002’.
The SLT coding automatically inserted the record which ahs now a new key filed into the internal table.
In the internal table you would find now two records, only differs by the key ‘0001’ and ‘0002’.
Save and activate your include. Please note, that no syntax check can be executed for includes.
When you change the existing coding during a replication – errors can occur during the activation.
You can ignore them.
Find below the complete coding.
4. Activate the transformation rule for table SFLIGHT
Navigate to transaction IUUC_REPL_CONTENT.
And add a new record into section IUUC_A S S_RUL_MAP as in the following screenshot.
Save your settings afterwards.
5. Start the load/replication of the table SFLIGHT from the Data Provisioning UI of the HANA Modeler
6. You find the result on the following screenshot
You see now that two records exist which differ by a newly introduced key field.
This is the end of this HowTo Guide.
Additional information (THX to Udo):
If you perform the split in timestep BOR – begin of record – that means you append the new record before the field-related transformations are applied.
So BOR is okay, if you have no further field related transformations. But if you have some field-related transformations, you usually want to append the transformed records. Then you must use the timestep EOR – end of record.