Hello All,

I am sure many of you who use SLT (SAP Landscape Transformation) would have encountered a need to add additional fields to their table structure or to modify existing field types. This could be for various reasons. To process certain data, to add additional parameters for the destination system, support data, etc. This is quite common and can be easily achieved using Table and Rule settings on LTRS transaction. One specific need we had was two fold. First, every record replicated should have its timestamp (of replication) and a flag that indicates what operation was performed (Insert, Update or Delete). Some of you I am sure would have probably worked and solved this same scenario or something similar.

I hope the below post is useful for people looking at this scenario or similar where the solution may be applicable.

The Need

• Add a Specific Field Timestamp that holds the Data and Time of Replication
• Add a Specific Field Flag that indicates what Operation was performed – Insert, Update or Delete
• When a record is deleted in Source System it should not be deleted in the target as the need was to have this information in the Target System but with the flag as “D” to indicate it was deleted in the source system.

The Solution

The solution for the all 3 of our needs was in fact interlinked with a single piece of reusable code that we had to insert within the Rule Settings of any table that is set up for Replication. Briefly this information is below. We will consider VBRK table as an example here. But, we have used this solution for more than 100 tables so far and counting. It remains the same.

Step 1: Add 2 Custom Fields on Table Settings at the End of the Table

Figure 1 – Adding Timestamp and Operation Flag Fields

Step 2: Add a Field-Related Rule with a Custom Include to Populate said Fields

Figure 2 – Field-Related Rule with Custom Include

Step 3: Reusable Custom Include Development

This is a one-time action as the code is table independent. Can be reused for all future tables. The only setting to change is the “Input Parameter 1″ in the Field-Related rule. Here, we use “<wa_r_vbrk>”. It needs to be changed according to table. See Figure 2. The code is fairly simple and available below. Please Note, where we modify the operation flag to “U” when it is “D” to meet the third part of our need.

*&---------------------------------------------------------------------*
*&  Include  ZINALC_TIMESTAMP_FLAG
*&---------------------------------------------------------------------*

FIELD-SYMBOLS: <ls_data>      TYPE any,
               <lv_operation> TYPE any,
               <lv_delete>    TYPE any,
               <lv_timestamp> TYPE any.

ASSIGN (i_p1) TO <ls_data>.

DATA tstamp TYPE tzntstmpl.       " Timestamp Long - UTC Timestamp

* Assign the Time Stamp to ZZSLTTIMESTAMP field
ASSIGN COMPONENT 'ZZSLTTIMESTAMP' OF STRUCTURE <ls_data> TO <lv_timestamp>.
GET TIME STAMP FIELD tstamp.      " Get Current Timestamp Long
IF sy-subrc = 0.
  <lv_timestamp> = tstamp.
ENDIF.

* Assign the Operation to Operation field
ASSIGN COMPONENT 'IUUC_OPERAT_FLAG' OF STRUCTURE <ls_data> TO <lv_operation>.

* For Delete Operation
IF sy-subrc = 0 AND <lv_operation>  = 'D'.
* Change this to a update operation – so the record will not be deleted and a flag is added
  <lv_operation>  = 'U'.

* Update the ZZSLTFLAG to store D (for Delete)
  ASSIGN COMPONENT 'ZZSLTFLAG' OF STRUCTURE <ls_data> TO <lv_delete>.
  IF sy-subrc = 0.
    <lv_delete> = 'D'.
  ENDIF.

* For all other operation, Update the ZZSLTFLAG to store appropriate record type
ELSEIF sy-subrc = 0.
  ASSIGN COMPONENT 'ZZSLTFLAG' OF STRUCTURE <ls_data> TO <lv_delete>.
  IF sy-subrc = 0.
    <lv_delete> = <lv_operation>.
  ENDIF.
ENDIF.

Now, we are ready to start replication/initial load and the two new fields will be updated as per the above needs.

Thanks for taking your time to read this blog. I hope it was helpful. Kindly share your comments and your ideas in case you have a different approach to this problem and also on similar scenarios that we may encounter when using SLT. As we just started using SLT, I think we will encounter more complex scenarios as we replicate more and more tables.