Central Finance Tips and Tricks #5 – SLT

The SLT system is a critical component of central finance and is responsible to transfer real time replication data from source systems to the central system for both SAP and non-SAP systems. It also has the role of completing the initial load for cost object and controlling interfaces.

Where do you get started?

Great information and pre-defined templates are delivered by SAP to help accelerate and get you off to a solid start, refer to SAP notes:

• 2154420 – SAP LT Replication Server for SAP Central Finance
• 2462424 & 2481900 – SAP LT Replication Server for SAP Central Finance – Third-Party System Integration
• 2223621 – Central Finance: Interface for Business Integration. This is for non-SAP systems with only a runtime database license

Note 2154420 has the prerequisite SLT components needed for each release. The DMIS add on is required on source systems and SLT itself, for the S/4 system the S4CORE component must be installed. To avoid issues the highest available version of DMIS is recommended to be installed.

Setup

The basic setup involves the use of transaction LTRC, this provides a wizard to create the connection between source and target systems. Before performing the initial setup some key points need to be considered.

• RFC destinations need to be configured on source and SLT systems
• Security access to the technical users assign to the RFC destinations needs to be setup correctly
• Read from single client flag in most cases should be activated to limit data selection to the RFC client specified in the RFC connection. If you have multiple clients in a single instance then this can be set off and the client is determined from the setting of the RFC destination.
• Allow multiple Usage flag should be selected. This allows multiple SLT configurations to access the same tables e.g. for table based replication to operate in parallel to Central Finance. For some customers with existing SLT replications (for example FICO accelerators in a HANA sidecar scenario) it may be required to convert the existing configurations first prior to using Central Finance. Note 2082199 – How to switch between 1:1 and 1:N replication in a SLT system explains the process involved to convert existing configurations.
• In SLT runtime objects are created in the $TMP package, this means they are not transportable. I recommend the transport management system is disconnected for the migration workbench objects. You do this by setting the value ‘X’ in table DMC_RT_PARAMS for parameter NO_CTS_CONNECTION.
• When using reading type 4 or 5 for the initial load this fills an index table on the source system during access plan calculation. The table space (example APPL1) must be entered in the setup of the configuration or you may face issues later.

Setup Example

In the SLT server, start transaction LTRC, choose the new pushbutton to create a new configuration. In the step Specify General Data, enter a configuration name (without any spaces).   In addition, you can specify a description.

In the step Specify Source System, you specify the connection data to the source system. In this case, specify an existing RFC connection to the source system.

In the step Specify Target System, the connection data to the target system must be defined. Select the RFC Connection radio button, and enter the existing RFC connection to the target system. In the field Scenario for RFC Communication, choose RFC scenario

In the step Specify Transfer Settings, you can define the initial load mode. I recommend using the option Performance Optimized but you will need approximately 10 % additional storage in the source system during the initial load. In the No. of Data Transfer Jobs field, enter the appropriate value e.g. 6. Note that you can increase this value later if required. Set data class of table space e.g. APPL1. Set the replication frequency as Real time.

In the step Review and Create, you can review your settings. Ensure that all settings are correct and choose the push button Create Configuration.

The mass transfer ID (MTID) is an internal number. You need this information to activate the pre-delivered objects in MWB. The MTID is also visible in transaction LTRC. Communication between source > SLT > Central Finance is now established.

Mapping

When SLT is performing the initial load and replicating data, for both phases a migration workbench (MWB) object is created for every trigger table. A MWB objects stores the information of the source structure, the target structure and how the mapping should be executed. In other words, the MWB object holds the rules that transform the data from the table based structures on the source system into the remote function module interface of the central finance system. This is different from a table based standard scenario, like HANA replication, where the table is moved as an exact copy from source to the target.

For S/4 HANA 1511 to 1610 releases Central Finance is working with three trigger tables AUFK, CFIN_ACCHD, and COBK.  From 1709 onwards SAP have added other tables to support tax, withholding tax, commitments, accounting view of logistics data and EC-PCA postings.

An initial load object and a replication object must be created for each table. All of the MWB objects are stored for each configuration in LTRC and can be adjusted accordingly. SAP have done a great job and done most of the work, where templates can be download and installed using the notes mentioned in the getting started section above.

Before you start the replication, you must create the initial load and replication objects. To define the initial load and replication objects start program DMC_UPLOAD_OBJECT in transaction SE38 and upload the relevant files from SAP note 2154420. It is possible for customer specific adjustments can be made to the mapping rules.

Once the template rules are available, they are applied to each mass transfer ID on the SLT server. This is completed after the setup of the mass transfer ID is completed for each source system.

Mapping Example

Before you start the replication in each SLT system, you must create the initial load and replication objects.  To define the initial load and replication objects use LTRC for the mass transfer ID, tab processing steps and the step Create Predefined Load and Replication Objects

Choose the Copy Predefined Object pushbutton, and enter the REPL_CFIN template in the Project field. Depending on whether you are integrating SAP or Non SAP system choose the relevant Subproject, in this case I am selecting REPL_CFIN.  In the Predefined Object field, you specify the predefined initial load object. Use the F4 help to view all available objects. For every table, there is a load object and a replication object. The load object contains the suffix L and replication object _R.

Under Target Object, you have to specify the table name. Use the same table that you specified for the predefined replication object. For example, if your predefined replication object is CFI_COBK_L, your table name is COBK. Repeat for the replication object with the predefined object with suffix _R and select the replication radio button.

Repeat the process for the other tables that require replication e.g. CFIN_ACCHD and AUFK.

Navigate back to the overview of the predefined objects and set the status of the initial load and replication objects to Active.

Once the replication objects are defined it is critical to perform a DDIC synch. This ensures that the MWB objects are consistent between source and target systems so runtime objects are created correctly.

From LTRC for the mass transfer ID, tab processing steps and the step Create Predefined Load and Replication drill down into the “ _TEMPLATE” MWB subproject.

When you start the replication from LTRC, SLT should automatically synchronize the data dictionary (DDIC) structures between the source and target systems. In some exceptional cases this does not occur and can lead to multiple short dumps due to DDIC inconsistencies. In this case it is possible to OPTIONALLY force the generation of runtime objects using the steps below:

• For the runtime object causing inconsistencies, drill down and navigate to “Generate Runtime Object”, select the perform DDIC synch. Repeat for every MWB load and replication object.
• This needs to be done once before you start initial load and replication.

Filters

Filters ensure that only the relevant data is transferred to Central Finance. Two types of filters can be defined:

• Trigger filter – this implements a filter on the trigger of the source system, meaning that only the filtered data is transferred to SLT.
• Runtime filter – this implements logic in the runtime objects on the SLT system to filter out irrelevant records. Using this method data is transferred from source to SLT and is filtered out at SLT runtime.

For the controlling interface, I recommend that a trigger filter is applied to table COBK and aligns with the initial load starting date set in view VCFIN_SOURCE_SET on source systems. For large installations that have lots of history, this will speed up the initial load process and only select relevant data. In some cases, it may be necessary to implement a runtime filter, for example where different initial load start dates are required for different company codes, or you need to filter out company codes on the Controlling interface.

Example Trigger Filter

You define trigger filters in transaction LTRS with respect to a configuration and table in the performance options folder. The reading type must be set to 4 or 5 for trigger filters to be defined. The example below shows a filter on table COBK with posting date >= 01 August 2018.

You can also disable update and delete triggers if desired using the Tables folder in LTRS.

Example Run time Filter

Run time filters are defined in the MWB content. Using transaction MWB navigate to the TEMPLATE subproject for the mass transfer ID where rules are to be defined and select the conversion logic icon. Here the template rules will be shown and can be adapted.

The example below shows a run time filter on COBK for event related rule SKIP_COBK to filter the record out of the posting date is less than 01 August 2018.

Execution

The Central Finance initial load process consists of two different parts.

• Initial load via Central Finance customizing

For the Accounting interface, it transfers via RFC the FI documents, the balances and open items to the central system in CFIN* staging tables on the central finance system (not via SLT!)

For the Controlling interface, the CFINIMG activity Prepare for and Monitor the Initial Load of CO Postings must be executed before the table COBK initial load is started from the SLT system. This prerequisite step stores the CO-PA characteristics in a source system database table CFIN_COPA for the initial load of the CO documents.

• Initial load and replication via SAP LT Replication Server

The initial load and replication for the tables AUFK, CFIN_ACCHD, COBK is executed via transaction LTRC on the SLT systems. In the context of Central Finance, the SLT initial load of CFIN_ACCHD refers to the loading of documents posted on source system since the start of the RFC initial load performed from the Central Finance system.

Execution Example

When the MWB objects are activated you can use SAP LT Replication Server to control your load and replication. In the SAP LT Replication Server Cockpit (transaction LTRC) enter your mass transfer ID. In the Table Overview tab page, you can stop or start a table by choosing the Data Provisioning pushbutton.

The option Start Load will execute an initial load of the data that is currently in the system. But there will be no delta replication. Using this function is generally not required. It could come in use for recovery scenarios where you need to load some data and not activate real time replication.

The option Start Replication will execute an initial load of the data and activates delta recording. After the initial load, the replication of delta data will start, no manual interaction is required

Enter the table (e.g. AUFK, CFIN_ACCHD, COBK) for which you have defined your predefined objects and choose Start Replication.

Monitoring

You can monitor the load and the replication using transaction LTRC.  On the tab page Data Transfer Monitor, you can view the table name once the initial load or replication object is created and view the status of the replication and objects. The tab Load Statistics is useful during the initial load phase to give you an overview of progress. The Application Log can be used to help troubleshoot and analyse issues, the log contains details about any issues regarding the replication process, and information if data cannot be replicated to the target system because of incorrect settings.

In many cases it is hard in SLT to detect the exact problem and you will need to use LTRC, ST22 and SM21 to trouble shoot.

To monitor more than one configuration at a time transaction LTRO can be used.

Alerts

Setting up automatic alerts to send out notifications in case of issues in SLT is recommended. This helps avoid permanent monitoring of SLT. Notifications can be activated for a dedicated configuration. If activated, the system uses a background job to check the configuration periodically:

• Whether the connections to the source system and target system are working correctly
• Whether the master job is running
• Whether the data load jobs are running
• Whether acceptable latency times have been exceeded
• Whether any errors occurred during the load or replication

The frequency and thresholds can be set up on a table basis per configuration. This is done in LTRC in the Expert Functions tab.

Reset Transfer Status / Repeated Testing

Central finance uses function modules to transfer data. Using this technique SLT stores the key references during initial load and replication into table DMC_FM_RESTART to ensure that the same data cannot be replicated to the target system again.

For testing it is likely that reloading of SLT data to Central Finance is required, due to configuration changes, defects etc. To reuse an existing mass transfer ID and load the same documents again you must first remove the entries in table DMC_FM_RESTART, otherwise none or not all data will be transferred to Central Finance.

To remove the entries, use transaction SE38 and enter the report DMC_FM_RESTART_COPY_DELETE enter the table name e.g. CFIN_ACCHD and choose Reset Transfer Status.

Managing Outages

As part of operations it is necessary to suspend the SLT replication from time to time to accommodate events such as upgrades and patching. When deactivating replication, the source systems will accumulate entries in the logging tables and these will be cleared down and processed to the central finance system once the SLT configuration is reactivated. However, for the AC_DOC Accounting interface for SAP source systems, sequencing is enabled with interface version 2 and there is no guarantee that SLT will processes the postings in the correct sequence. Read SAP note 2679070 – Central Finance: Resuming SLT replication that provide the steps to avoid sequencing issues:

1. In SLT LTRC deactivate the mass transfer ID of the respective source systems
2. In Central Finance deactivate the AIF runtime configuration group that is used for the replication by removing the indicator “Runtime Cfg Active” and save the change. This is done in transaction /AIF/PERS_CGR – Runtime Configuration Group.
3. When ready to resume the replication, on SLT LTRC activate the mass transfer ID of the respective source systems. On Central Finance new messages will collect with the status “
   In Process” in the AIF monitor.
4. On SLT, in LTRC for a mass transfer ID, on the Expert Functions Tab select the “View Unprocessed Logging Table Records” check the logging tables are empty, that signifies the backlog of postings have caught up
5. In Central Finance, when the backlog of postings has been transferred, activate the AIF runtime configuration group again in transaction /AIF/PERS_CGR – Runtime Configuration Group.
6. In the Central Finance system, execute in SE38 report /AIF/PERS_RUN_EXECUTE. On the start screen of the report, set the option “Include runs in status New”.

Structural Changes

From time to time data models may change on source or target central finance systems as a result of upgrades, configuration changes such as adding a new field to COPA or extending a field in the general ledger, also known as a coding block extension.

In all cases the SLT configuration must be deactivated before the structural changes are imported into the source or target system. When the replication is restarted SLT will normally automatically detect the changes and regenerate the run time objects. In some cases this could go wrong, for example the sequence was not strictly followed. In this case the run time objects will need to be synchronized and regenerated (Refer note 2531470).

Good to Know

My most frequently used SLT transactions

• LTRC  – Detailed overview on a configuration
• LTRO   – Monitoring of several configurations at a glance
• LTRS  – Advanced replication settings
• SM37  – Status system jobs
• SM21  – System log
• SM50  – Work Process Monitor
• SM51  – Work Process Monitor including Application Server
• MWB  – Migration Workbench