FAQ: SAP HANA LT Replication Server (SLT)

SAP HANA, SLT, LT Replication Server, Landscape Transformation, FAQ, Data Provisioning 

1. What is the basic concept of SAP LT Replication Server (SLT)?

2. Where do I find central information about SAP LT Replication Server (SLT)?

3. How much load will be additionally generated by using SLT?

4. Where do I find more information about SAP LT Replication Server configuration?

5. Where do I find more information regarding SLT Monitoring setup on SAP Solution Manager 7.1 and BI Monitoring?

6. What happens if there are structural changes on tables with active DB trigger?

7. Can tables with more than 2 billion records be replicated via SLT into a HANA table?

8. How can the consistency between the source and target system be checked?

9. How can I find the proxy table for a source table?

10. How can I find the source table for a logging table?

11. How can typical SLT performance issues be optimized?

12. Can SLT tables be partitioned?

1. What is the basic concept of SAP LT Replication Server (SLT)?

The SAP Landscape Transformation (SAP LT) Replication Server is the SAP technology that allows you to load and replicate data in real-time from ABAP source systems and non- ABAP source systems to an SAP HANA environment. The SAP LT Replication Server uses a trigger-based replication approach to pass data from the source system to the target system. If not all data records of a table should be transferred, you can create transformation rules to selectively filter the data (selective data replication) or to enable other transformations during the data replication process.

2. Where do I find central information about SAP LT Replication Server (SLT)?

This SLT community page provides even more than current released SLT presentations, official roadmap information and all official SLT documents like installation and operation guides.

The SLT help page - https://help.sap.com/sapslt

The following important SAP Notes for SLT exists. Check regularly for updates available in the Operations Guide.

SAP Note

Title

1605140 Central Note - SAP LT Replication Server

1691975

HANA LTR - Clarification on DMIS releases

1768805 SAP LT Replication Server: Collective Note - Non-SAP Sources

1733714 Guide for Advanced Replication Settings

1963522 Limitation for SAP LT Replication Server on MaxDB

3. How much load will be additionally generated by using SLT?

It depends how many transfer jobs you have configured in your SLT system. Each transfer job will need a dialog job in source (RFC). When you are doing initial load (which should only happen once) and you are using collective Access plan you will need additional background jobs in the source. It should be avoided to configure  too many transfer jobs (called Data Load Jobs) for the number of replicated tables and the troughput of changes.

4. Where do I find more information about SAP LT Replication Server configuration?

For each SAP LT Replication Server configuration, the parameter Data Transfer Jobs restricts the maximum number of data load jobs which can be started for one mass transfer ID (MT_ID).

In total, one mass transfer ID requires that the following background work processes are available in the SAP LT Replication Server:

1 monitoring job (IUUC_MONITOR_<MT_ID>)

1 master controller job (IUUC_REPLIC_CNTR_<MT_ID>)

1 job for either defining the migration objects (IUUC_DEF_MIG_OBJ_<2digits>), calculating the access plan (ACC_PLAN_CALC_<MT_ID>_<2digits>), or for changing configuration settings.

N data transfer jobs (DTL_MT_DATA_LOAD_<MT_ID>_<2digits>)

In the source system, the number of available dialog work processes which are reserved for the replication should be equal to the number of data transfer jobs running in the SAP LT Replication Server system.

5. Where do I find more information regarding SLT Monitoring setup on SAP Solution Manager 7.1 and BI Monitoring?

SAP Note

Title

1743562 ST-A/PI 01P: SLT Monitoring requires manual corrections

1558756 Solution Manager 7.1 - BI Monitoring for SLT Systems

 1666278 Solution Manager 7.1 - BI Monitoring: Prerequisites

6. What happens if there are structural changes on tables with active DB triggers?

When a table is registered for replication, a corresponding logging table and a database trigger are created in the source system to record any INSERT, UPDATE, or DELETE statements.

The question is now how the SLT system and the source system behave regarding any structural changes to a table for which a DB trigger is active.

As the behavior depends on the SAP Basis release on the source system the behavior is described for the respective Basis version in the LT Replication Operations Guide.

For the SLT System we strongly recommend to use DMIS 2011 SP12 or higher. If you use an older SLT version you have to stop and restart the replication for the affected tables in any case. As the behavior is the same no matter if the structural change is done directly in the system or executed within a transport, we do not have to distinguish between both use cases.

7. Can tables with more than 2 billion records be replicated via SLT into a HANA table?

Yes, tables with more than 2 billion records can be replicated and partitioned within SLT. For more information check 2528241 - Partitioning of tables replicated by SLT to SAP HANA database.

For best practices for partitioning tables see SAP note 2044468 (Section 13).

8. How can the consistency between the source and target system be checked?

The consistency between source and target system in an SLT scenario can be checked using the cross-database comparison (CDC) feature. See SAP Note 2602264 for more details.

9. How can I find the proxy table for a source table?

SAP Note 2738066 describes how to find the proxy table for a source table using transaction LTRC or table IUUC_TAB_ID.

10. How can I find the source table for a logging table?

You can find the source table for a logging table in the following ways:

Logging table system, table DD02V: TABNAME -> source table, DDTEXT -> logging table

Source table system, table IUUC_TABLES: TABNAME -> source table, SHADOWTAB_NAME -> logging table

11. How can typical SLT performance issues be optimized?

The SLT Performance Guide contains comprehensive information for optimizing the SLT performance.

SAP Note 2000002 ("How can SLT specific performance issues be tuned?") describes tuning approaches for common SLT performance issues.

12. Can SLT tables be partitioned?

See KBA 2209687 - SLT HANA target table Source Table Has More Than 2 Billion Records for table partitioning.

Reactively you can manually repartition SLT logging tables with HASH on column IUUC_SEQUENCE. See SAP Note 2044468 for more information about SAP HANA partitioning.

SAP SLT triggers inconsistency issue troubleshooting ?

 #Check the configuration settings of SAP SLT to ensure they are correctly set up.

#Review the error logs in SAP SLT for any reported inconsistencies or issues.

#Identify common triggers for inconsistency issues in SAP SLT based on documentation and user reports.

#Compile a list of recommended troubleshooting steps based on the findings from the previous subtasks.

1. Common Causes of Trigger Inconsistencies

Trigger inconsistencies in the SAP SLT system can arise from several factors. One common cause is the modification of triggers associated with SLT configurations, which can disrupt continuous data replication. Additionally, the accidental or intentional removal of triggers from the source system can prevent SLT from accessing necessary data, leading to failures in trigger checks and further inconsistencies10. Network issues with the source system are also significant; these interruptions can block the replication process and cause triggers to become inactive10.

2. Steps to Check Trigger State

To address potential inconsistencies, it is crucial to check the state of the triggers within the SLT environment. This can be done from both the source system and the SLT server. On the source system, you can check trigger states by accessing transaction SE11 and displaying the database table to see if the triggers are present and active. On the SLT server, you can log into LTRC and use the Expert Function tab to confirm the trigger status10. Recognizing the states of SLT triggers will help diagnose whether they are missing or in a blocked state.

3. Resetting Trigger Status

If triggers are found to be inconsistent or inactive, a series of steps must be followed to reset their status. Start by logging into LTRC, entering the Mass Transfer ID, and selecting Administration Data to deactivate the configuration. Next, reset the status for the triggers and logging tables by checking the appropriate boxes and executing the command. Upon completion, create a new database trigger and reactivate the configuration to ensure proper functionality10.

4. Check Network and Source System Status

It is important to verify that there are no network connectivity issues that might affect data replication. Ensuring a stable connection between SLT and the source system is essential for uninterrupted operations. Investigate whether there are any ongoing issues with the source system that might contribute to load status being blocked or cause triggers to become inactive after a restart10.

5. Monitoring and Analysis Tools

To facilitate troubleshooting, utilize available monitoring tools. The LT Replication Server Cockpit (LTRC) and Monitoring functions within SLT allow you to manage configurations effectively, identify errors, and analyze replication processes8. Additionally, consider leveraging third-party monitoring solutions that permit more detailed observations and independent thresholds for alerts, which can enhance the troubleshooting workflow8.

6. Reviewing and Adjusting Configuration Settings

It’s advisable to routinely review configuration settings to ensure they are optimized for data replication. Monitoring configurations for the number of jobs and their statuses can assist in pinpointing any settings that may contribute to inconsistencies4. Analyzing these settings in coordination with trigger states can provide insight into the overall health of the replication environment.

By systematically following these steps and utilizing the appropriate tools, you can effectively troubleshoot and address inconsistencies related to SLT triggers, thereby ensuring a smoother data replication process.

 

How can we retrieve the Record Count for Multiple Tables in the single execution of a statement in the Microsoft SQL database? #SAP Basis #DBA MSSQL Server

As SAP Basis administrators managing SAP SLT, it's important to compare table record counts between the source and target. To save time, it's better to use a statement instead of checking records from SE16 one by one.

The following statement can be used to get the record counts for multiple tables in row format, you can utilize a SQL query that combines the UNION ALL operator. Below is an example statement to retrieve counts for one or more tables:

SELECT 'Table1' AS TableName, COUNT(*) AS RecordCount FROM SystemSID.schemaname.table name  UNION ALL

SELECT 'Table2' AS TableName, COUNT(*) AS RecordCount FROM SystemSID.schemaname.table name UNION ALL

 

Each SELECT statement retrieves the count of records for a specific table by using COUNT(*). The first column contains the name of the table, and the second column contains the respective record count. The UNION ALL operator is used to combine the results from all specified tables into a single result set.

• Ensure that you replace Table1, Table2, ..., etc with the actual names of your tables.

• This method assumes you have access to all the tables and that they all exist in the schema you are querying.

This query structure can easily be adapted to other sets of tables by modifying the UNION ALL sequences to fit the desired number of tables.

 

How analysis HANA database slowness issue ?

The following are a few IMPORTANT points to consider while working on the slowness of the HANA database. 

1. Understanding the Slowness Issue

To effectively analyze slowness issues in an HANA database, it is crucial to first understand the nature of the problem. Slowness can stem from various sources, including poor SQL query performance, inadequate memory allocation, or inefficiencies in data processing mechanisms. Pinpointing these causes involves examining system performance metrics, such as CPU usage, memory consumption, and I/O wait times.

2. Monitoring Key Performance Indicators (KPIs)

​Monitoring key performance indicators is essential for diagnosing slowness. Performance KPIs in HANA databases might include response time, query execution time, transaction throughput, and system resource utilization. Establishing benchmarks for these metrics allows administrators to pinpoint periods or actions that result in performance degradation17.

3. Analyzing Query Performance

Query performance is a frequent cause of slowness in HANA databases. Analyzing the execution plans of slow queries can reveal inefficiencies, such as missing indexes or suboptimal join operations. Tools available within SAP HANA can provide insights into how queries interact with the database and highlight potential inefficiencies8.

4. Tuning Database Configurations

Database configurations play a pivotal role in performance. Tuning various settings, such as memory allocation and workload management, can significantly enhance database responsiveness. For instance, adjusting the memory distribution among different workloads can help optimize performance under varying usage scenarios17.

5. Utilizing Performance Analysis Tools

SAP HANA provides several built-in performance analysis tools that assist in identifying and resolving performance issues. These tools can aid in monitoring system health and analyzing workloads, allowing administrators to take targeted actions to improve performance. For example, performance traces can help isolate specific queries or sessions that may be contributing to overall slowness19.

6. Implementing Best Practices

Adhering to best practices for managing data and queries in HANA can also mitigate slowness issues. This includes strategies like optimizing data models, reducing data redundancy, and ensuring efficient data access patterns. Employing efficient ETL processes that minimize load times can also contribute to enhanced performance20.

7. Continuous Evaluation and Adjustment

Finally, continuous evaluation and adjustment are necessary to maintain optimal performance in a dynamic environment. Regularly reassessing configurations and performance metrics, along with adapting to changing workloads, can help mitigate potential slowness in the future. Establishing a proactive monitoring regime can ensure that any performance degradation is detected and addressed promptl

 

what is latency in the SAP SLT and How to check Latency?

 Latency in SAP SLT (SAP Landscape Transformation Replication Server) refers to the time delay between the creation or modification of data in the source system and the point when this data is replicated and available in the target system. Several factors can influence latency in SAP SLT, including:

1. Network Bandwidth and Latency: The speed and quality of the network connection between the source and target systems can significantly impact replication times.

2. Source System Load: The performance of the source system, including how busy it is with other processes, can affect the speed at which data can be extracted.

3. SLT Server Configuration: The configuration and capacity of the SLT server, including hardware resources and tuning parameters, play a critical role in determining replication speed.

4. Data Volume: The amount of data being replicated can influence latency. Larger data volumes typically take longer to process and replicate.

5. Transformation Rules: If data transformations are applied during replication, the complexity and number of these rules can add to the processing time.

6. Target System Performance: The speed and efficiency of the target system in receiving and processing the incoming data also affect overall latency.

Managing and optimizing these factors can help reduce latency and ensure more timely data replication in SAP SLT environments.

3236399 - FAQ - Technical Job Repository (SJOBREPO) #S4HANA

1: What does the Technical Job Repository do?

The Technical Job Repository in SAP S/4HANA was initially developed to support automatic (technical) background job scheduling in cloud-based SAP S/4HANA systems. SAP needed a mechanism to run certain recurring (=periodic)

background jobs automatically in every S/4HANA system, without the need for external intervention or monitoring.

2. What parameters are involved in the Technical Job Repository?

The parameter rdisp/job_repo_activate_time specifies the time cycle for the job repository activation. The job R_JR_BTCJOBS_GENERATOR runs based on the value specified in this parameter.

• 60M (60 minutes)
• 2H (2 hours)
• 0 (No activation)

This parameter works likewise as rdisp/btctime. If the aforementioned profile parameter rdisp/btctime has the value 0, the scheduler is never started.

3. How do you assign the step user for starting technical jobs with releases lower than 7.51 SP03?

There is only the option to create the stepuser manually in SU01 and assign it to the current client via report R_JR_UTIL_1. The relevant SAP Note is 2339022.

4. How do you assign the step user for starting technical jobs with releases higher than 7.51 SP03?

Note that from NW 7.51 onwards (i.e. with SAP S/4HANA On-Premise 1610), there exists a new transaction SJOBREPO_STEPUSER which allows in a user-friendly way to create and assign Default Step Users for Technical Job Repository (note 2449125).

5. How do you assign different stepuser for single job definitions in transaction SJOBREPO?

With release SAP_BASIS 7.56 and higher, it is possible to locally assign different stepusers for single Job Definitions in transaction SJOBREPO in addition to the default stepuser for all other Job Definitions.

6. How do you deactivate a job to not be started by the Technical Job Repository anymore?

Start transaction SJOBREPO and select the job that you want to deactivate. 

e.g.:

SAP_REORG_APPLJOBS -> F7 (Deactivate technical job definition locally). The system prompts a message 'Do you really want to deactivate the Technical Job Definition(s) and unschedule the Background Job(s) in this client?'. By pressing 'Yes', the system prompts another message 'Do you want to record this change in a transport?'. The answer is based on the customer's internal process, if you don't want to record the change in transport, click 'No'.

Afterward, the column Custom./Deactiv. will be updated with a magic wand icon. The table STJR_JOBD_CUST will be updated with the client, technical job name, who has disabled the job, and column IS_DISABLED = X means if the technical job has been disabled. 

If you would like to revert the technical job deactivation, follow the instructions below.

e.g.:

Select the job in SJOBREPO -> SAP_REORG_APPLLOG -> Shift + F4 (Revert changes to standard). The system promps a message 'Do you really want to reactivate the Technical Job Definition(s) and schedule the Background Job(s) in this client?' By pressing 'Yes', the system prompts another message 'Do you want to record this change in a transport?'. The answer is based on the customer's internal process, if you don't want to record the change in transport, click 'No'. 

The entry in the table STJR_JOBD_CUST will be removed and the technical job will be triggered at the next scheduled time.

7. How do you use a different report variant for job scheduling in the Technical Job Repository?

Please follow the instructions as per SAP Note 2744380 - Technical Job Repository: Using a different report variant for job scheduling

8. What does the job status reason 'Not Relevant' mean?

In the transaction SJOBREPO whenever a job status is 'Not Relevant', double-click on the job name and check the tab Execution Terms.

Administration Client – Indicates if the job should run in administration client 000.

Business Client – Indicates if the job should run in business client 100 for customer-like systems, all clients <> 000 for internal systems.

If both checkboxes are checked, it means the job is relevant to be executed in all the clients in the system.

Programs that perform cross-client tasks usually run only in the Administration client, whereas programs that work exclusively on (application or customizing) data defined in the current client, run only in the Business

client. Some Job Definitions are designed to run in every client, for example some of the SAP_WORKFLOW* Job Definitions.

9. What does the job status reason 'Not In Scope' mean? 

Job is scope-dependent: A job for a scope-dependent Job Definition will only be scheduled if an entry in table STJR_JOBD_SCOPE exists (containing the name of the current Job Definition) in the current client. This entry can be set in IMG (transaction S_YI3_39000188).

As of release SAP_BASIS 7.56, the Job Definition name and the scope state (on/off) must be set in table STJR_JOBD_SCOPE. In addition, a scope callback class can be defined by the responsible application. This class can define additional conditions which must be fulfilled for the job to be executed, for example, a certain number of entries in a specific table must be exceeded.

For further details, please check KBA 3085988 if you would to adjust the scope dependency. 

10. What does the job status reason 'Inconsistency' mean?

Job Definition has a syntax error (check in SE80). There are notes that can be implemented in order to adjust the syntax, or the job definition has become obsolete on higher releases and should not be scheduled anymore.

11. What does the job status reason 'BTC User Error' mean?

In a few cases, a Job Definition is delivered with an explicit user set in field User Name in SE80 instead of (DEFAULT) and the user does not exist in the current client.

12.How do you analyze errors with regard to the Job Repository activation and report them to SAP?

You can use the transaction SLG1 and display the application logs generated by the program R_JR_BTCJOBS_GENERATOR, if there are errors recorded in the System Log attach them to the ticket.

Prior to S/4HANA 1909 FPSP02, the Technical Job Repository is active after an upgrade or update although it has been deactivated manually in the source release. How is it possible?

If you deactivate the Technical Job Repository manually with R_JR_UTIL_1, it will be activated by BTCTRNS2. As of S/4HANA 1909 FPSP02 this behavior has changed, you need to reactivate it manually after you have executed BTCTRNS2. Otherwise, the technical jobs will not be executed. More details in SAP Note 3152943.

13. How do you activate the Technical Job Repository deactivation history?

In your S/4H systems technical jobs are not executed or have not been executed for a period of time. This results in jobs not getting executed. To get an overview on where and for how long this has happened, you can check the content of the Technical Job Repository deactivation history table STJR_HISTORY. The Technical Job Repository deactivation history is available with SAP_BASIS 7.55 SP02 and SAP_BASIS 7.54 SP04. 

For lower support packages, please perform the pre-implementation steps first and then implement the relevant correction instruction delivered in SAP Note 3013075.

14. How do you deactivate or reactivate a job definition in the Technical Job Repository in all clients?

The solution has been delivered as of SAP Basis 7.54 SP04 and 7.55 SP01 with SAP Note 3031444.

15. Where do I check the list of technical jobs delivered by SAP based on the S/4 HANA release?

The list of technical jobs delivered based on the S/4HANA release can be checked in the following SAP Notes:

3389524 - Jobs in the Technical Job Repository (SJOBREPO) in SAP S/4HANA 2023

3195909 - Jobs in the Technical Job Repository (SJOBREPO) in SAP S/4HANA 2022

2849364 - Jobs in the Technical Job Repository (SJOBREPO) in SAP S/4HANA 2021

2992214 - Jobs in the Technical Job Repository (SJOBREPO) in SAP S/4HANA 2020

2849402 - Jobs in the Technical Job Repository (SJOBREPO) in SAP S/4HANA 1909

2849337 - Jobs in the Technical Job Repository (SJOBREPO) in SAP S/4HANA 1809

S/4HANA 1709, S4/HANA 1610, and S4/HANA 1511 are available in the SAP Note:

2581518 - Jobs in the Technical Job Repository (SJOBREPO)

What is Technical Job Repository (SJOBREPO) in SAP S/4HANA ?

 In SAP, SJOBREPO refers to the Job Repository. It is a transaction code used in SAP systems to manage background jobs. The Job Repository allows users to monitor, schedule, and manage background jobs within the SAP environment. This tool is essential for ensuring that various automated tasks and processes are executed efficiently and on time.

In SAP S/4HANA environment, there are background jobs which are scheduled automatically after the system has been started. The jobs are not delivered like the former SAP Standard Jobs in transaction SM36 - instead, they are workbench objects of type JOBD (job definition). A job definition is created in the same package as the report which shall be scheduled periodically by the job definition. The result is a background job that has the same name as the job definition and which can be monitored in transaction SM37. To stop such a job you need to deactivate the job definition in transaction SJOBREPO, because if you delete the job from SM37 it will be scheduled again by the Job Repository infrastructure. You can deactivate a job definition in the current client or in all clients. It is also possible to change the recurrence of a time-based job in SJOBREPO. You can also change the report variant of a job definition and add a specific target server. Note: Most modifications only work in the current client.

To get detailed information about a job definition, doubleclick on the job definition name in SJOBREPO to navigate to ABAP Workbench. In the following screen, doubleclick on the report name to navigate to the report source code. In the menu, select Goto -> Documentation. Report documentation is available for (almost) all job definitions.

Here are some key functions associated with SJOBREPO:

1. Job Monitoring: Track the status of background jobs to ensure they are running as expected.

1. Job Scheduling: Schedule new jobs or modify the schedules of existing jobs.

1. Job Management: Start, stop, and manage the execution of jobs.

1. Job Analysis: Analyze job logs and performance to troubleshoot any issues.

This transaction is part of SAP's broader job management framework, which helps in maintaining the smooth operation of various business processes.

How to fix SLT trigger(s) in an inconsistent state in SAP SLT / SAP Landscape Transformation Replication Server ?

  Error: 

• CNV_IUUC_REPLICATION057
• System Landscape Transformation (SLT) triggers are in an inconsistent state. 
• The missing trigger for table XXXXX for MT_ID XXX. Replication Suspended.”
• You recently upgraded the HANA DB of the source system.
• There was a change to the triggers.
• Missing entry in IUUC_LOGTAB_ID 
• The trigger(s) have been removed on the source system.
• The trigger check failed when SLT tried to or did access the source system. 
• Network issues with the source system cause the replication to be blocked and triggers become inconsistent, this is because SLT performs a trigger check to confirm the trigger exists.

Resolution

Check Trigger State: 

       Option A: on Source System:

1. Log in to the Source system of SLT configuration.
2. Go to Transaction SE11
3. In the Database table section type in the table name
4. Click Display
5. Click Utilities (M) in the ribbon at the top.
6. Click on Database Object
7. Click Display
8. Scroll to the bottom and triggers are there.
9. Note that SLT triggers follow the notion: /1LT/<IDENT><OP> where <IDENT> is a 8 digit number Identifier and <OP>  represents the operations INS, DEL, UPD1 or UPD2

      Option B on the SLT Server

Log into LTRC

Type in Mass Transfer ID or click on MT_ID

Click on the Expert Function Tab

Click on ‘View Trigger Source Code’ (This works for both SAP & Non-SAP data source)

Confirm the 'Mass Transfer ID', type in the 'Table Name in Database' and click on the 'Active Code' radial button, and click execute (green check mark)

Note that SLT triggers follow the notion: /1LT/<IDENT><OP> where <IDENT> is a 8 digit number Identifier and <OP>  represents the operations INS, DEL, UPD1 or UPD2

One of these two things will occur:

A: If the trigger is missing on the source system, the table will need to be reloaded to ensure record consistency between the source and target system.

B: If triggers are still in the source system

1. Go to transaction LTRC on the SLT system
2. Type in MT_ID ( Like 002 or 001 etc)
3. Select Administration Data
4. Select Deactivate
5. Click on the Expert Function tab
6. Click on 'Reset Status for Triggers and Logging Tables'
7. Type in 'Mass Transfer ID', 'Table Name in Database', check the box next to 'Reset "Trigger Created" Flag' and 'Reset "Failed" Flag', and click execute (green check mark)
8. This will reset the trigger status
9. Click on Processing Steps
10. Create Database Trigger
11. Enter the table and execute
12. Select Administration Data
13. Select Activate.

I observed that we need to follow the below steps those are related to "SLT tables are in status 'Load /Replication blocked'

1. Log into the SLT system
2. Go to transaction LTRC | Expert Functions | 'Reset Load and Replication Status'
3. Fill in the MT_ID
4. Put in the table name
5. Uncheck the boxes under the 'Reset Status'
6. Check the box next to the 'Reset "Blocked Data Trans." flag'

How to check SAP SLT - Trigger State in SLT System or Source system ?

 Error: 

• CNV_IUUC_REPLICATION057
• System Landscape Transformation (SLT) triggers are in an inconsistent state. 
• The missing trigger for table XXXXX for MT_ID XXX. Replication Suspended.”
• You recently upgraded the HANA DB of the source system.

Upon encountering the above error. The first step is to check the Trogger State. We have two options to check triggers.

Option A: On Source System
Option B: On the SLT Server

A: Source System

1. Log in to the Source system of SLT configuration.
2. Go to Transaction SE11
3. In the Database table section type in the table name
4. Click Display
5. Click Utilities (M) in the ribbon at the top.
6. Click on Database Object
7. Click Display
8. Scroll to the bottom and triggers are there.

Note : SLT triggers follow the notion: /1LT/<IDENT><OP> where <IDENT> is a 8 digit number Identifier and <OP>  represents the operations INS, DEL, UPD1 or UPD2

B: the SLT Server

• Log into LTRC
• Type in Mass Transfer ID or click on MT_ID
• Click on the Expert Function Tab
• Click on ‘View Trigger Source Code’ (This works for both SAP & Non-SAP data source)
• Confirm the 'Mass Transfer ID', type in the 'Table Name in Database' and click on the 'Active Code' radial button, and click execute (green check mark)

Note : SLT triggers follow the notion: /1LT/<IDENT><OP> where <IDENT> is a 8 digit number Identifier and <OP>  represents the operations INS, DEL, UPD1 or UPD2

SAP Case/ticket Escalation Procedure when need a response on high Priority or there is no response on the ticket raised.

Reason and Prerequisites

The following note applies to all SAP customers.
It is designed to inform you of the formal case escalation process to follow when your problem/issue is not a production-down situation (“Very High” priority); but there is a significant enough business impact to justify an increased focus on case processing.

Solution

To escalate your case please ensure that it has already been raised from “Low” or “Medium” priority to “High” priority. 

For “High” priority cases please be sure you have provided the following information regarding the business impact:

Production Systems

1. Is there an acceptable workaround?
2. Is core business functionality severely affected?
3. What is the anticipated financial loss to the business due to the issue in question?
4. How many users are affected?
5. How does this issue affect the GoLive date?

 

Pre-Production (Dev/Test/UAT) Systems:

1. Is there an acceptable workaround?
2. What is the anticipated date of release to the user community?
3. Will this issue delay the scheduled release date to the user community?
4. What is the anticipated financial loss to the business due to the issue in question?
5. How many users are affected?

When escalating more than one case please prioritize starting with the most critical.
Please include all forms of contact for the person who will work the case (work/mobile phone, email) along with hours of availability.

After updating the case notes please call the CIC hotline to request an escalation of your case.  

CIC hotline phone numbers are found in SAP Note 560499.

How SAP consultant can speed Up the Processing of a Case/ticket raised with the SAP Support team?

When contacting your Local Customer Interaction Center (CIC) please have the following information prepared. With this information, the CIC/Sap Support team will be able to evaluate the priority of the case and will also be able to accelerate the processing of your case.

Please note: In case of a production down situation or a system outage please submit a case with Very High priority.

In answers, we need to provide detailed information giving as many facts and figures as possible.

Production System

• Is the production system down?
• Which SAP product is affected?
• Which business processes are affected, e.g. Payroll, Reporting?
• Are users affected?
• If yes, how many are affected, and how are they affected in their daily tasks?
• Is there a workaround in place?
• If yes, how effective is the workaround?
• Are there upcoming deadlines that could be affected by the issue?
• If yes, please state the details of those deadlines and the consequences if they are not met.
• How long has the customer been affected by this problem?
• Is the situation deteriorating?
• Are suppliers and/ or your customers affected by this issue?
• Is there a financial loss due to this issue?
• If yes, please quantify.
• Any other details of the impact this issue is having on your business?

Test/ Development/ QA System

           Does the problem affect a project?

        if the answer is YES

• What is the planned go-live date for production?
• What are you going live with (SAP Product Version, Support Package, Patches)?
• Is this issue a showstopper?
• Which stage of the project are you working on?
• Please detail the milestone dates of the project.
• What are the consequences if any of those dates are missed? Please detail.
• Is the entire project at a standstill or can you continue to work on other sections?
• How many members of the project team are affected? To what extent?
• How many consultants are affected? To what extent?
• Please quantify any financial loss you are experiencing.
• Any other details of the impact this issue is having on your business?

          If its NO

• What are the consequences of this issue?
• Is there a workaround in place?
• If yes, how effective is the workaround?
• Any other details of the impact this issue is having on your business?

What the customer/SAP Consultant must do to ensure prompt processing of cases with the priority "very high":

1. Remote access to the relevant system must be ensured.
2. A contact person must be designated for opening the system who must be available and can provide the required logon data.
3. A contact person must be available to provide information about the problem.
4. The contact person should be reachable under the provided phone number.
5. The problem should be described in as much detail as possible: The case should contain instructions about how to simulate the problem.
6. To ensure 24/7 processing, the case must be written in English.

 

Different Priorities of problem cases/tickets raised with the SAP Support team.

It is very important to know which ticket should be created based on the criticality of the issue/error in SAP Systems. SAP has defined the following priorities for problem cases:

1. Very high:

           A case should be categorized with the priority "very high" if the problem has very serious consequences for normal business processes or IT processes related to core business processes. Urgent work cannot be performed. 

This is generally caused by the following circumstances:

 - A productive system is completely down.
 - The imminent system go-live of a production system or upgrade of a production system can't be completed.
 - The customer's core business processes are seriously affected.
 - And for each circumstance, a workaround is not available.

           The case requires immediate processing because the malfunction may cause serious losses.
 
           In case of a go-live or upgrade, the reason to delay the go-live or upgrade must be one that would cause serious losses if not resolved before the go-live.

           A case can be classified with priority ‘very high’ in case of severe security vulnerability or cyber attack or in case of an event relevant for a data notification breach event.

2. High:

           A case should be categorized with the priority "high" if normal business processes are seriously affected. Necessary tasks cannot be performed. This is caused by incorrect or inoperable functions in the SAP system that are required immediately. For example; users cannot access the system, a go-live cannot be completed, users complete data is not accessible, etc. 

           The case is to be processed as quickly as possible because a continuing malfunction can seriously disrupt the entire productive business flow.

3. Medium:

           A case should be categorized with the priority "medium" if normal business processes are affected. The problem is caused by incorrect or inoperable functions in the SAP system.

4. Low:

           A case should be categorized with the priority "low" if the problem has little or no effect on normal business processes. The problem is caused by incorrect or inoperable functions in the SAP system that are not required daily or are rarely used.

Maintenance schedule for SAP Support Systems like SAP Support Portal, SAP Service Marketplace, ONE Support launchpad etc.

 Reason and Prerequisites

Downtime and Workaround

Solution

The SAP support systems are available 24 hours, 7 days a week. The only exceptions are the maintenance dates.

Emergencies or critical problems may result in unplanned unavailability or maintenance work. SAP can offer you limited support during that time.

For Hotline phone numbers, see SAP Notes for more details  560499 and 16481.

To request support for technical issues or to report an error, please choose from one of the following options:

• Create a customer case via SAP for Me > Get Support
• Chat with a Product Support Expert via SAP for Me > Get Support  
• Book an appointment with a Product Support Expert via SAP for Me > Get Support 

Please note: A valid S-user ID and password are required to use this service.

For more information about any of these services, please visit https://support.sap.com/en/my-support/product-support.html

We therefore recommend that you refrain from planning an upgrade or other critical conversion projects on these maintenance dates.

SAP maintenance dates 2024

=====================

Wave1 Thursday, January 18, 2024

Wave2/Q1 Saturday, February 24, 2024

Wave3 Thursday, April 11, 2024

Wave4/Q2 Saturday, May 25, 2024

Wave5 Thursday, July 11, 2024

Wave6/Q3 Saturday, August 24, 2024

Wave7 Thursday, October 10, 2024

Wave8/Q4 Saturday, November 16, 2024

Removal of SAP Fiori Client From Public App Stores #SAP #2992772

 2992772

Reason and Prerequisites

The SAP Fiori Client app was initially developed to help users run SAP Fiori web applications using their mobile devices. With the considerable improvement of device browser capabilities, the need for the SAP Fiori Client app has been significantly reduced. In addition, due to the increasing limitations [1 2] of the WebView component, applications such as the SAP Fiori Client that are built on top of it can no longer provide an optimal user experience.

For these reasons, SAP will be removing the SAP Fiori Client app from the public app stores, with the recommendation that end-users use their native browsers instead.

Solution

Recommended Approaches:

• Option 1: Transition to SAP Mobile Start

SAP Mobile Start can serve as an option for customers interested in a native launch experience for their users. It enables the end-users to immediately react to critical business situations by providing SAP S/4HANA notifications as well as approval workflows delivered by the SAP Task Center.  

Please find introductory blogs as well as deep-dive how-to blogs on the SAP Mobile Start community page (https://community.sap.com/topics/mobile-experience/start).

Note: SAP Mobile Start is certified to be integrated into SAP S/4HANA and SAP S/4HANA Cloud but not for SAP ECC.

Pre-requisites: SAP Work Zone, standard edition

• Option 2: Build custom mobile applications using SAP Mobile Services

SAP Mobile Services provides a seamless way for customers to accelerate their mobile application development to mobilize their data (SAP or 3rd Party) with a great degree of flexibility for customization.

Customers can choose from multiple modes of development: SAP Mobile Development Kit to build cross-platform applications; SAP BTP SDK for iOS & SAP BTP SDK for Android for fast native application development.

Please check the official documentation (https://developers.sap.com/mobile) and roadmap (https://roadmaps.sap.com/board?range=FIRST-LAST&PRODUCT=000D3A47875C1EDB98A89A88E176C229) for further details.

• Option 3: Use the device browser

To access SAP Fiori launchpad, we recommend using your default device browser. Please note that using a browser means that certain device-native functionality will not be available, including barcode scanning and voice recording (see FAQ below for alternatives to barcode scanning APIs for the browser).

For customers who have Mobile Device Management (MDM) capability, a link to SAP Fiori launchpad can be added to the users’ home screens using the "Add to Home Screen" functionality provided by the MDM [3].

What is SAP Mobile Start ? #SAP FIORI #SAP S4HANA

 SAP Mobile Start is a mobile application designed by SAP to give users access to various SAP solutions and business processes on their mobile devices. It aims to enhance productivity by allowing users to perform essential business tasks, access real-time data, and receive notifications on the go. The app integrates with SAP's backend systems, enabling users to manage their workflows, approve tasks, monitor key performance indicators, and stay connected with their business operations from anywhere.

SAP Mobile Start is a native app that serves as the mobile entry point to your business processes and content. It is a native mobile version of the SAP Build Work Zone, a standard edition that allows access to native or web-responsive (such as SAPUI5) business apps, data, and information. SAP Mobile Start runs on iOS, iPadOS, and Android devices, on watchOS and Wear OS devices, and on Apple Vision Pro.

Key features of SAP Mobile Start include:

• Unified Access: A single entry point to various SAP applications and services.

• Task Management: Ability to view and complete tasks, approve workflows, and manage approvals.
• Notifications: Real-time alerts and notifications to keep users informed about critical business events.
• Analytics and Insights: Access to reports and dashboards to monitor business performance.
• Customizable Interface: Personalized views and settings to match individual user needs and preferences.
• Integration: Seamless integration with SAP's enterprise systems like SAP S/4HANA, SAP SuccessFactors, SAP Concur, etc.

SAP Mobile Start is designed to support modern business needs, providing a flexible and efficient way to manage work from mobile devices.

What are the periodic tasks that must be completed for SAP Transactional Banking for SAP S/4HANA ?

Periodic tasks include reports on the daily processing of accounts and business transactions. The sequence in which you run these reports and their interdependencies depend on the configuration of your system. You define the order in which the system runs the reports, and how the reports interrelate, according to your business needs.

The periodic tasks listed here help to keep your SAP system stable.

General Checks in the ABAP Environment

ABAP transactions that should be checked regularly are listed in the following table. The most important transactions are listed.

Periodic Tasks for SAP Transactional Banking

Program Name / Task	Recommended Frequency	Description
Archiving (ILM)		For more information about the archiving processes in SAP Transactional Banking, see Data Archiving, Data Destruction, Data Deletion.
Report RBANK_DELETE_RUNS		Deletes RBANK_PP_MONITOR process data.
Report R_BCA_PRI_PP_PACKAGE_CN	At least once per week (if product price list function is used)	Adopts product pricing list to related contracts report.
Report RBCA_PAYMITEM_PROCESS_ENQ	Multiple times a day	Resets the lock table for payment items.
/SAPPO/RESUBMIT_ORDERS_2	Multiple times a day	Processes PPO orders after errors have been solved or unlocks have been performed.
RSCOLL00	Hourly	Collects statistical records automatically.
System log	At least once a day	Evaluates system messages for each instance.
CCMS / RZ20	At least once a day	Monitors the technical status of the system.
SRT_MONI	At least once a day	Checks for PI error messages.
/SAPPO/DELETE_ORDERS	Daily	Deletes closed PPO orders.
RBCA_PAYMITEM_CLEARING_LIST	Daily	Checks for open items not cleared.
Posting Control Office	Daily	Checks and processes payment items with errors.
MassMan Monitoring	Daily	Used for daily monitoring and performance testing.
Postprocessing Office	Daily, after EoD	Postprocesses errors during end-of-day processing using PPO orders.
Transactional RFC	Daily	Checks for RFC communication errors.
BCA_BL_DD_PP_RUN (SEPA Direct Debit Mass Run)	Daily	Processes the SEPA direct debits (SDD) and direct debits based on the billing items in the system.

Periodic Tasks for FS Business Partner

Program Name / Task	Recommended Frequency	Description
Program OAFR_PP_RUN_AGENTS (Execute Agent)	As required, presumably hourly or daily (scheduled execution)	Collects open change pointers for the specified agent IDs and sends the corresponding information messages. For more information about this program, its parameters, and scheduling its execution, see the program documentation in the system. Note Make sure you send the information messages in the following recommended order: Business Partner Business Partner Relationship Business Partner Blocking Business Partner Unblocking
Transaction OAFT_PP_RUN_AGT_LOG (Execute Agent Application Log)	As required	Can be used to monitor the agent runs.

Manual Periodic Tasks

This section describes all manual tasks that need to be run periodically to keep the application running smoothly over time. Unlike the scheduled tasks listed above, which you can automate using a task scheduler program, you need to execute manual tasks yourself. It is important that you monitor the execution of these tasks on a regular basis.

Periodic Tasks for Transactional Banking

Program Name / Task	Recommended Frequency	Description
Transaction BCA_PPOx (2,3)	At least once a day	Postprocessing Office Display/Change for Account Management
Transaction MCM_PPOx (2,3)	At least once a day	Postprocessing Change/Display for Master Contract Management
Transaction PLM_PPOx (2,3)	At least once a day	Postprocessing Change/Display for Posting Log Management
Report RFBDELSIM		Deletion report for account settlement simulation data in table BKK92_SIM

The following manual tasks are only required if data is inconsistent between the sender and target system and requires reconciliation.

Periodic Tasks for FS Business Partner

Program Name / Task	Recommended Frequency	Description
Transaction FSBP_SEND_INFO(Select Business Partner and Info About BP Relationship To Be Sent)	As required	Creates change pointers for the specified business partners and business partner relationships for reconciliation purposes.
Transaction FSBP_CREATE_RC_CP (Select Business Partner and Info About BP Relationship for Sending)	As required	Creates change pointers for the specified business partners and business partner relationships for reconciliation purposes.
Transaction FSBP_CREATE_RC_CP_DP (Select Business Partner Lock Information for Sending)	As required	Creates change pointers for blocking/unblocking information for the specified business partners for reconciliation purposes.
Transaction OAFT_PP_RUN_AGENTS (Execute Agent)	As required (online execution)	Collects open change pointers for the specified service operations and sends the corresponding reconciliation messages using program OAFR_PP_RUN_AGENTS.
Transaction OAFT_PP_RUN_AGT_LOG (Execute Agent Application Log)	As required	Can be used to monitor the agent runs.