Troubleshooting

This sections describes how to troubleshoot issues with credentials. If you get an "403 Unauthorized" while accessing AWS resources, check the following steps to ensure you have the proper permissions.

Topics


Working with logs

There are 2 places where you can find relevant information regarding SAP SLT or CxLink Datalakes that can help you troubleshoot SLT load or replication issues.

Check SAP Logs

Follow these steps to check log information reported by SAP:

  1. Call Transaction LTRC

  2. Open the Mass Transfer ID that reports the errors.

  3. Jump into the Application Logs tab, click on Filter and select the period to be retrieved. Application Logs

  4. Check for errors in the listed output.

  5. If the error is caused by CxLink, you can find more details in the CxLink Log Viewer


CxLink Datalakes comes with a build-in tool for error reporting. You can find additional information about an error reported by CxLink by following next steps:

  1. Call transaction SE38

  2. Enter report /LNKAWS/AWS_LOG_VIEWER and Execute (F8)

  3. Enter the time period to be displayed and Execute (F8)Log Viewer

  4. Find detailed information about the error and search for it in the troubleshooting pages.


Replication errors

SAP Landscape Transformation Replication Server facilitates the transfer of data from one or more source systems to one or more target systems. This guide outlines what will happen if the source system, SAP LT Replication Server system, or target system goes down. In addition, this guide outlines any necessary steps that should be taken in order to resume the replication as smoothly as possible as soon as the affected system is up and running again.

SAP Help Page

This section reflects the SAP Unscheduled Downtime - Recovery Guideopen in new window official documentation with some additional information regarding CxLink Datalakes

Source is Down

If the source system goes down, recording of source system data changes is not affected since no data changes in the source system are missed while the source system is down. While the source system is down, the source system tables will have the status Failed on the Participating Objects tab in transaction LTRC in the SAP LT Replication Server system. However, the SAP LT Replication Server system will periodically try to replicate data from the source system, and once the connection to the source system can be established again, the replication will continue as usual.

To avoid error messages in the application log:

  • If an access plan calculation was in process for a table in the source system when the source system went down, stop and restart the relevant table; this will also restart the access plan calculation.
  • Deactivate all affected configurations to avoid errors in the application log.

SAP LT Replication Server system is Down

If the SAP LT Replication Server system goes down, no data will be replicated to the target system. While the SAP LT Replication Server system is down, data changes will continue to be recorded in the source system as usual. Once the SAP LT Replication Server system is up and running again, the replication of data to the target system will resume automatically.

If the SAP LT Replication Server system is down, the logging tables in the source system will increase in size since no data is being replicated to the target system. This can be avoided by deleting the trigger manually in the source system for the relevant tables. Once the SAP LT Replication Server system is up and running again you need to stop these tables and then perform an initial load for them (since deleting a trigger for a table means that no changes are recorded for that table)


AWS Services connectivity is Down

If the connectivity to AWS goes down or IAM Access permissions are missing, no data can be written to the target AWS Services. In the SAP LT Replication Server system, on the Participating Objects tab in transaction LTRC, the status of the tables will be Failed. Once the target system is up and running again, the transfer of data will continue automatically.

If the target system is down, the logging tables will grow in size, since no data is being replicated to the target system. This can be avoided by stopping the relevant table and repeating the initial load once the target system is up and running again. This should only be considered for tables where performing a new initial load is feasible from a timing perspective.

To avoid error messages in the application log, all configurations can be deactivated until the target system is available again (you can do this in transaction LTRC). For deactivated configurations the change recording in the source system will continue as usual.

To avoid increasing the size of the logging tables:

  • Deactivate all affected configurations to avoid errors in application log

  • To avoid increasing the size of the logging tables, stop the relevant tables and repeat the initial load once the target system is up and running again.

After activating the configuration again, once the communication is re-established or the issues are solved, all recorded changes will be replicated to the target system.


Avoiding Inconsistencies When Restoring the Source System from a Backup

If you need to restore your source system to a previous point in time, then some source system data may be lost. This data may already have been replicated to the target system. To avoid data inconsistencies between the target system and the source system, the target tables should be truncated and the initial load or replication process should be repeated by stopping and starting the affected tables.

As CxLink Datalakes uses RFC Connection to establish connectivity with the proper AWS Services, SAP states that the following steps must be performed:

  • Delete data manually.

    • If the table only contains data that has been transferred from the affected source system, truncate the table.
    • If the target table contains also data coming from different sources, delete only data that has been transferred from the source system affected by the outage.
  • Stop and start the initial load or replication process for all tables to avoid data inconsistencies between the source system and the target system


Avoiding Inconsistencies When Restoring the SAP LT Replication Server System from a Backup

If you need to restore your SAP LT Replication Server system to a previous point in time, then the SAP LT Replication Server system may not have up to date information about tables that are replicated to the target system.For example, even though the replication of a table was triggered in the SAP LT Replication Server system, the SAP LT Replication Server system may no longer have information about this.

In this case logging tables, target tables, database triggers, and synonyms might already have been created in source and target systems, but there is no record of these objects in the SAP LT Replication Server system. This means that the following objects need to be deleted manually in the source system:

  • Logging tables
  • Database triggers
  • 1:N Registration tables:
    • IUUC_1N_CONS_REG
    • IUUC_POOL_REGIST
    • IUUC_LOG_APPLTAB

In the target system, the target table synonyms need to be deleted. For the target tables, you need to decide whether the data in the table should be deleted or not. For example, if you do not delete the data, and repeat the initial load, duplicate key errors could occur. Note that due to the system reset the replication statistics might not be accurate anymore.

  • In the source and target systems, delete the relevant objects as described above.
  • Restart the initial load or replication process for the affected tables

Avoiding Inconsistencies When Restoring the Target System from a Backup

If you need to restore your target system to a previous point in time, then some data that has been transferred to the target system may have been lost.

For small tables, the best solution is to stop and restart the initial load or replication process such that the initial load will be repeated and data between the source and the target is consistent again. To avoid duplicate key errors during the initial load, we recommend truncating the target tables before starting the initial load of the table.

Depending on the connection to the target system, the process for truncating the target tables can be different:

Replication Logging Not Supported

Replication logging is a feature available in SAP SLT that can help you recover big tables to a specific state without having to perform full initial loads after a target system restore but it is only supported for target systems that are connected to the SAP LT Replication Server system by means of a database connection. As CxLink Datalakes uses RFC Connections, It is therefore not possible to use this feature.

Follow these steps to restart replication after a system restore:

  • Delete data manually.

    • If the table only contains data that has been transferred from the affected source system, truncate the table.
    • If the target table contains also data coming from different sources, delete only data that has been transferred from the source system affected by the outage.
  • Stop and start the initial load or replication process for all tables to avoid data inconsistencies between the source system and the target system.


Access errors

User validation failed: The security token included in the request is invalid

You test IAM user in the Credentials tab or you get this error in the application logs

Ensure that you have set the needed information in the proper format:

  • IAM User described has have the same format as in AWS IAM. Name is case sensitive for SAP, so ensure to respect upper and lower case letters and that you have the iam:GetUser in your AIM Policy

    {
          "Action": "iam:GetUser",
          "Effect": "Allow",
          "Resource": "arn:aws:iam::<your_aws_account>:user/<iam_user_name>"
    },
    
  • Ensure that the AWS Account defined is where the IAM User has been created.

  • Re-enter again AWS Access Key and Secret Key to ensure they are correct.

  • If you are using IAM User for credentials management, ensure you have the iam:GetUser permission in you IAM Policy:


Amazon S3: "403 Forbidden" or "403 Access Denied"

If you are using Amazon S3 as the data destination, ensure that you have the proper permissions to access the destination bucket:

   {
         "Sid": "Store objects to S3 bucket",
         "Effect": "Allow",
         "Action": "s3:PutObject",
         "Resource": [
            "arn:aws:s3:::<bucket_name>",
            "arn:aws:s3:::<bucket_name>/*",
         ]
   },

Amazon Kinesis: "403 Forbidden" or "403 Access Denied"

If you are using Amazon Kinesis as the data destination, ensure that you have the permission for kinesis:PutRecord and kinesis:PutRecords to access the destination data stream:

   {
      "Sid": "Put object/s to Amazon Kinesis Data Stream",
      "Effect": "Allow",
      "Action": [
         "kinesis:PutRecord",
         "kinesis:PutRecords",
      ],
      "Resource": [
         "arn:aws:kinesis:<aws_region>:<aws_account_id>:stream/<kinesis_data_stream_name>"
      ]
   },