SLT Replication - Table Enhancement in R/3 System

[aluri_hemanth]

Hello Experts,

I have a question regarding enhancing the source tables during replication. What are the steps to be consider before enhancing the Table in R/3 System which is already in replication.

We have come across a scenario like enhanced the table in R/3 System and when the transport moved to the next environment the transport ended with errors.

Could you please share me your inputs or thoughts if you would have faced this Scenario and what are the steps to followed.

Thanks,

HA.

[tobias_koebler · Accepted solution]

Hi HA,

Source System on SAP Netweaver Basis 6.40 or lower / non SAP Source system

There is no check for active trigger in the ABAP dictionary. I.e. any structural change can be executed on a table no matter if a trigger is active for that table. If SLT is installed on DMIS 2011 SP2 or higher / DMIS 2010 SP7 or higher, SLT will recognize structural changes and will adapt the table on the HANA side accordingly. As the logging table stores the key of the original table, the trigger and logging table have to be dropped and recreated in case of changes of key definition. Please ensure that the trigger is dropped before the key definition is changed as the trigger will fail once the key definition is changed. Therefore in case of key changes you have to stop the replication for the affected table and start the replication (including a new load) after the
applying the change to the table.

Source System on SAP Netweaver Basis 7.00 - 7.30

There is a check in the ABAP dictionary which prevents any strucutural change on a table where a database trigger is active. There are two notes available which downport the adaption which is part of the standard installation starting with SAP Netweaver 7.31 SP5 and higher releases (EhPs). Please be aware that both notes handle SLT triggers only. I.e. in case customer own triggers are
active on a table also, any structural change will still be prevented.

SAP Note 1655725 - Check for DB trigger made less strict
By implementing this note on the SAP source system, simple table structure changes (adding a non key field) are possible with active SLT triggers. The trigger will remain active and and
delta recording continues without any interruption. SLT checks before every replication if the activation timestamp of the source table changed to detect any structural change. When the table is changed on the source system, SLT pauses the replication of that table, calculates the ALTER statement for the HANA DB and does the same adjustemnt (including DEFAULT VALUE statements) on the HANA side. Afterwards the replication object is adjusted to the new structure
and replication continues without the need of a new initial load. In this case the table is paused for a few minutes, therefore Latency might go up for the first portions after the table adjustment was processed automatically. For the automatic adaption by SLT, DMIS 2011 SP2 or higher / DMIS 2010 SP7 or higher is required on the SLT System.

SAP Note 1749824 - Treatment of SLT triggers during transport
In case of complex table structure changes (change data type or length, add or delete key fields) the trigger and logging table have to be dropped and recreated. Also the table on HANA side has to be dropped and recreated to ensure data consistency. Therefore you normally have to stop the replication for the affected tables upfront before applying a complex structural change. By implementing this note, the data dictionary checks in case of complex structural changes if the active triggers are SLT triggers and will drop the SLT trigger to ensure that the structural
change can be applied. SLT permanently checks if the created triggers still exist in the source system. In case a trigger is dropped manually or by the data dictionary, SLT suspends the replication for that table and sets it to error state with an according error message in the application log (that the trigger was deleted). So this note does not prevent that you have to reload the table
after a complex structural change but you can apply complex structural changes with stopping the replication of the affected table upfront.

Source System on SAP Netweaver Basis 7.31 SP5 or higher

Simple Table Structure Changes
Simple table structure changes (adding a non key field) are possible with active SLT triggers. The trigger will remain active and delta recording continues without any interruption. SLT checks before every replication if the activation timestamp of the source table changed to detect any structural change. If the table is changed on the source system, SLT will pause the replication of that table, calculate the ALTER statment for the HANA DB and do the same adjustemnt (including DEFAULT VALUE statements) on the HANA side. Afterwards the replication object is adjusted to the new structure and replication continues without the need of a new initial load. In this case the table is paused for a few minutes, therefore Latency might go up for the first portions after the table adjustment was processed automatically. For the automatic adaption by SLT, DMIS 2011 SP2 or higher / DMIS 2010 SP7 or higher is required on the SLT System.

Complex Table Structure Changes
In case of complex table structure changes (change data type or length, add or delete key fields) the trigger and logging table have to be dropped and recreated. Also the table on HANA side has
to be dropped and recreated to ensure data consistency. Therefore you normally have to stop the replication for the affected tables upfront before applying a complex structural change. The data dictionary checks in case of complex structural changes if the active triggers are SLT triggers and will drop the SLT trigger to ensure that the structural change can be applied. SLT permanently
checks if the created triggers still exist in the source system. In case a trigger is dropped manually or by the data dictionary, SLT suspends the replication for that table and sets it to error state with an according error message in the application log (that the trigger was deleted). So the table
has to be reloaded again after a complex structural change but you can apply complex structural changes with stopping the replication of the affected table upfront.

There a serveral notes that are relevant for transports. You find them in the Note list marked as elevant Notes from other Components: http://scn.sap.com/community/replication-server/blog/2013/02/27/list-of-all-slt-notes

Best,

Tobias

[aluri_hemanth · Accepted solution]

Hi Tobias,

Thanks for your reply.

Could you please confirm was the below context is given by SAP in any OSS note ?

Source System on SAP Netweaver Basis 7.31 SP5 or higher

Simple Table Structure Changes
Simple table structure changes (adding a non key field) are possible with active SLT triggers. The trigger will remain active and delta recording continues without any interruption. SLT checks before every replication if the activation timestamp of the source table changed to detect any structural change. If the table is changed on the source system, SLT will pause the replication of that table, calculate the ALTER statment for the HANA DB and do the same adjustemnt (including DEFAULT VALUE statements) on the HANA side. Afterwards the replication object is adjusted to the new structure and replication continues without the need of a new initial load. In this case the table is paused for a few minutes, therefore Latency might go up for the first portions after the table adjustment was processed automatically. For the automatic adaption by SLT, DMIS 2011 SP2 or higher / DMIS 2010 SP7 or higher is required on the SLT System.

Complex Table Structure Changes
In case of complex table structure changes (change data type or length, add or delete key fields) the trigger and logging table have to be dropped and recreated. Also the table on HANA side has
to be dropped and recreated to ensure data consistency. Therefore you normally have to stop the replication for the affected tables upfront before applying a complex structural change. The data dictionary checks in case of complex structural changes if the active triggers are SLT triggers and will drop the SLT trigger to ensure that the structural change can be applied. SLT permanently
checks if the created triggers still exist in the source system. In case a trigger is dropped manually or by the data dictionary, SLT suspends the replication for that table and sets it to error state with an according error message in the application log (that the trigger was deleted). So the table
has to be reloaded again after a complex structural change but you can apply complex structural changes with stopping the replication of the affected table upfront.

Thanks,

HA

[tobias_koebler · Accepted solution]

HI,

correct - I will work on a blog an post it the next days with some more details - how to handle the structure changes with some manual effort.

Best,

Tobias

[aluri_hemanth · Accepted solution]

Hello Tobias,

I would like to share the Issues that we have faced during DATATYPES Conversion from SLT System to HANA system and please provide me your
valuable inputs if you have any solution in this scenario.

What we have done and what issues we have faced are mentioned below:

Issues & Solutions that we have implemented

• We have applied the settings in the table - IUUC_REPL_CONTENT to covert the data type DATS to DATE and TIMS to TIME.
• During replication for one of the table – BNKA, replication is being executed for long time, which is more than 3 days. We could not get enough information to debug the errors.
• We have raised an OSS message to SAP and they have replied with the root cause of the failure and feasible solution for fix.
• Root cause for the Replication being run for long run time is due to the DATS Values in the source system that are having blank values and Invalid values since the replication is being done from Development system. As we are deriving the DATE as data type in HANA, the format of the date value from source system should be 00000000.
• SAP have given a proposal of Maintaining the replication settings in T-Code - IUUC_REPL_CONTENT to ensure that the DATS values which are coming from source system would be handled with the code by applying to convert the blank values to 00000000.
• We have acted as per SAP Proposal and we have implemented the code for the tables that are having Blank values in DATS Data type fields.
• Our replication went smoothly for all the tables that we have replicated in Development environment.
• When we started our replication in Q environment, again the Replication has failed for other table LFA1 that was running for long time and ended with error. We could track the errors longs in SM21 and we realized that it says some Invalid DATE value.
• During this analysis, we have replied to SAP that we  disagree with their proposal that DATS Blank values cannot be loaded to HANA if the data type is DATE. We have noticed that DATA Blank values have got loaded successfully to HANA.

Questions

• If SAP is suggesting us to proceed with code as a  solution to handle the Invalid or Blank Date values, we should write the  code and implement the programs for each table which will fail for this reason. More ever if there is any enhancement in the table with new data
  type as DATS again we have to enhance the entire code in the program which is not a good practice.

Proposal Ideas

• Please share me your thoughts here..

If you have already come across this situation and if you have other proposal to fix this scenario please reply, so we can share with the other customers whomever facing these sorts of issues.

Regards,

HA

[former_member182537 · Accepted solution]

HI,

we have same issue the table in ecc structure had changed.....now replication is failing ,our target is oracle so any idea how to handle this other thaN reloading table again.

pls advice.

thanks