Non SAP Target system: trigger configuration

[Former Member]

Hi all,

I am trying to find a relevant documentation on the trigger options explanation in t-code LTRS and I can't (almost like always) find any good explanation on how this can be configured.

My landscapte/Architecture:

SAP SLT Server replicating a SAP ECC System to a SQL Server Database system.

My need: replicate CDPOS on a very restricted dataset

I know how to initialize the replication with the filter I need, but I want then to create a trigger with some options.

Can someone explain how the "Trigger options" for a given table can be configured? I cannot find anything on this topic in any document...

Thanks.

Cyril.

[Former Member]

Seriously nobody???

I am really doubting about SLT Efficiency and flexibility... we encounter so many troubles with it ! And there is almost nothing about this ...

[tobias_koebler]

Have you checked the system docu and application help? This is the I button on top.

This is the text, formating is not working. Pls check it in the system. It includes examples.

Trigger Options Under Trigger Options, you can customize the code for the database triggers. A database trigger is procedural code that is automatically executed in response to certain events to a particular database table or view. SAP LT Replication Server creates database triggers in the source system in order to capture changes to certain tables. Under Trigger Options, you can filter the data that is captured in the source system. This can be advantageous, for example, if only a small percentage of the changes to the tables are relevant for the replication. Note that this option is intended for expert users only. We strongly recommend that you contact SAP for support before using this feature, as incorrect use can result in serious data inconsistencies. Any filters that you define here are only applicable for the replication process, they do not affect the initial load. To filter the initial load and replication, additional filter rules have to be defined. You specify the database type of your source system, for example MAXDB or DB2, and then enter the WHERE clause that should be used as filter for the database trigger in the Statements field. Note that the statements will differ depending on the database type. The following table provide some sample statements for the supported database types: Database Type Syntax Example SAP ASE, Microsoft SQL Field names must be placed in double quotation marks. "BUKRS" = 1000 Max DB, IBM DB2, IBM DB4, IBM DB6 Field names must be placed in double quotation marks, and be prefixed with the string "___." (three underscores and a period). ___."BUKRS" = 1000 SAP HANA, Oracle Field names must be placed in double quotation marks, and be prefixed with the string ":___." (a colon, three underscores, and a period). :___."BUKRS" = 1000 You can also create more complex filters by using the available syntax for a WHERE clause of a SELECT statement (for example AND, OR, LIKE). Additional Information about Creating Triggers Note: You cannot customize trigger code for database triggers for pool tables. When creating a database trigger for a source table, the following situations are possible: 1. No replication of data has been requested so far for the source table.You enter the code for the database trigger in the Statements field, and the system implements the code as part of the generated trigger creation code as soon as the data replication is requested for this table. That is, the trigger statements directly affect the replication process.2. The source table already has the status In Replication.In this situation, the following possibilities exist:◦The table is being replicated only for one target table. You can then enter the code for the database trigger in the Statements field, stop and restart the replication. The system implements the code as part of the generated code. That is, the trigger statements directly affect the replication process. ◦In addition to your target table, the table is being replicated to other targets  as well (when defining the configuration, you activated the "allow multiple usage" option, and at least one more configuration exists using the same source table). In this case, the trigger coding will not change. That is, even if you enter the code for the database trigger in the Statements field, and then stop and restart the replication, the system will not implement the code as part of the generated code. Note: For 1:N replication scenarios, triggers are shared between all configurations. This means that the trigger options are not only used for the configuration that created the trigger, but will also be used for all other active configurations. Note: If you need to redefine an existing trigger, see SAP Note 1898479. Options for Archiving Archiving activities can occur in the source system at any time. If data is being replicated from a source system, it is important to understand the impact that any archiving activities can have on the target system. When SAP LT Replication Server replicates a table to the target system, it creates a database trigger that records any changes in a logging table. If a table is being replicated, and a record in the table is archived, the database trigger interprets the archiving operation as a DELETE statement, and SAP LT Replication Server deletes the corresponding record from the target table. However, you may want to prevent the record from being deleted in the target system. If a user archives data from any table in the source system, you can prevent the data from being deleted from the corresponding table in the target system. In order to do this, select the option Do Not Delete Corresponding Target Table Record, and specify the relevant user (or users). Note that due to security considerations, the system does not check whether the user you specify actually exists in the system. You must therefore ensure that you enter a valid user.