This guide shows SAP LT Replication Server administrators, SAP data engineers, or others how to perform operational tasks, such as performance tuning and version updates, for versions 2.0 and 2.1 of the BigQuery Connector for SAP.
Tuning replication performance
Replication performance can be affected by multiple factors. The specific factors that apply can be different from installation to installation and can change over time.
The following sections provide guidance on how to tune some of the more common factors that can impact performance.
For more information about replication performance with the BigQuery Connector for SAP, see Performance planning.
Set performance options for tables
In SAP LT Replication Server you can specify replication options for each table that affect performance.
In particular, the replication performance for large tables, which require more time and resources to replicate, can benefit from specifying ranges and increasing the maximum number of parallel replication jobs that can be used for the table.
Examples of tables that commonly grow large are MSEG
, ACDOCA
, and MATDOC
,
among others.
When you specify parallel replication jobs for large tables, you need to balance the number of parallel jobs that you allow for any given table against the total number of parallel jobs that are allowed in the mass transfer configuration. Your organization might also limit the number of parallel replication jobs that you can specify for a given server.
To set performance options for a table:
In the SAP GUI, enter SAP transaction
LTRS
.On the Advanced Replication Settings screen, specify the ID of the mass transfer settings for the table.
In the Advanced Replication Settings folder hierarchy, click on the Performance Options folder to display the tables that have performance options defined.
If the table you need isn't listed, right-click the Performance Options folder, and then select Add Table.
Specify a name for the Table.
Specify the following options as needed:
- Under General Performance Options:
- No. of Parallel Jobs, to set the maximum number of parallel replication jobs that can be used for the table.
- Sequence Number, to prioritize the replication of this table relative to other table replications.
- Under Initial Load Options:
- For Reading Type, select Reading Type 1 Range Calculation, if your table is not too large. For more information, see Performance and the LTRS Advanced Replication Settings.
- For Package Size, specify the size in bytes of the portions of records that are sent to SAP LT Replication Server.
- If you select a Reading Type that uses ranges, then define appropriate ranges.
- Under Replication Option:
- For Ranges for Logging Table, specify No Ranges for the most reliable option.
- If you select Specify Ranges for Manually, then define appropriate ranges.
- Under General Performance Options:
Click Save.
Baseline performance benchmark
To help you evaluate your replication performance, this section contains baseline performance numbers that were observed in Google Cloud test systems.
Due to the many different factors that affect performance, your performance numbers are likely to vary.
For example, if your SAP systems are not running on Google Cloud, your load and replication rates might be slower than the baseline rates due to things like network latency and the overhead associated with for access tokens. If your source table has fewer columns or you install SAP LT Replication Server on its own server in a standalone architecture, your rates might be faster because SAP LT Replication Server doesn't have to compete with the source system for resources.
Observed baseline performance numbers
The following performance numbers represent the baseline performance that was observed by Google Cloud for each source system type during testing. In each test system, SAP LT Replication Server was installed on the SAP source system in an embedded architecture on Compute Engine VMs. The SAP source system was running in the same Google Cloud region as the target BigQuery dataset.
For information about the configuration of the test systems, see Baseline performance test system configuration.
To see the performance numbers, click your source system type:
S/4HANA
- Table: ACDOCA
- 343 million records
- 477 columns
- Initial load
- Load rate: 350 million records per hour on average
- Load duration: 59 minutes on average
- Replication
- Source table change rate: 50 million records per hour on average
- Maximum replication rate: 50 million records per hour on average
ECC
- Table: MSEG
- 203 million records
- 188 columns
- Initial load
- Load rate: 385 million records per hour on average
- Load duration: 32 minutes on average
- Replication
- Source table change rate: 50 million records per hour on average
- Maximum replication rate: 69 million records per hour on average
The preceding performance numbers are the baselines that the Google Cloud testers observed.
The observed performance was better in test systems that had the following attributes:
- SAP LT Replication Server was installed on its own VM in a standalone
architecture.
- For S/4HANA systems, a standalone architecture was observed to have an initial load rate approximately 42% faster than an embedded architecture due to the independent scaling of the SAP LT Replication Server processes.
- For ECC systems, a standalone architecture was observed to have an initial load rate approximately 10% faster than an embedded architecture due to the independent scaling of the SAP LT Replication Server processes.
- The source table had fewer columns.
- The overall byte size of the records was smaller.
For information about the system attributes that you can modify to improve performance, see:
Baseline performance test system configuration
The test systems described in this section produced the baseline performance numbers that are listed in the preceding section, Observed baseline performance numbers.
The tests systems, including the SAP source system, the SAP LT Replication Server, and the BigQuery data set, were all running on Compute Engine VMs in the same Google Cloud region.
In each system, the servers and the workload were designed to simulate a heavier workload and higher replication volume that you are likely to find in many real-world installations.
To see the test system attributes, click your source system type:
S/4HANA
- SAP LT Replication Server installation architecture:
- Embedded architecture
- Source system servers:
- Two application servers, each on an N2-based Compute Engine
custom machine type with the following specifications:
- vCPUs: 60
- Memory: 324 GB
- CPU platform: Intel Cascade Lake
- One SAP HANA server on an
m1-ultramem-80
Compute Engine VM with the following specifications:- vCPUs: 80
- Memory: 1,900 GB
- CPU platform: Intel Broadwell
- Two application servers, each on an N2-based Compute Engine
custom machine type with the following specifications:
- Software versions:
- S/4HANA 1909
- SAP LT Replication Server: S/4CORE 104 SP00
- Table size:
- Table name: ACDOCA, general ledger journal entry line item data
- Number of records: 343 million
- Number of columns: 477
- Work processes on each application server:
- 60 Dialog processes
- 220 Background processes
- Load settings in SAP LT Replication Server:
- Jobs: 99
- Reading type: 1 Range
- Calculation: Auto-ranges
- Replication settings:
- Jobs: 99
- Use Key fields to calculate ranges for logging table
- 128 ranges
ECC
- SAP LT Replication Server installation architecture:
- Embedded architecture
- Source system servers:
- Two application servers, each on an
n2-highmem-48
Compute Engine VM with the following specifications:- vCPUs: 60
- Memory: 348 GB
- CPU platform: Intel Cascade Lake
- Two application servers, each on an
- Software versions:
- SAP NetWeaver: 7.0 EHP2
- SAP LT Replication Server: DMIS 2011_1_700 SP17
- Table size:
- Table: MSEG, materials inventory management documents
- Number of records: 203 million
- Number of columns: 188
- Work processes on each application server:
- 60 Dialog processes
- 100 Background processes
- Load settings in SAP LT Replication Server:
- Jobs: 99
- Reading type: 5 Sender
- Queue: Manual ranges
- Replication settings:
- Jobs: 99
- Ranges for Logging Table: Use Key fields to calculate ranges
- Number of ranges: 128
Transport mass transfer settings to production
To transport mass transfer settings to production, you first export the settings from a development system, and then import them into the production system.
You can, optionally, import three separate parts of the settings of a mass transfer into production:
- The advanced replication settings, which can be accessed by using the
LTRS
transaction. - The client key settings from the
/GOOG/CLIENT_KEY
table, which can be accessed by using theSM30
transaction. - The BigQuery Connector for SAP the mass transfer settings, which can be
accessed by using the
/GOOG/SLT_SETTINGS
transaction.
Export mass transfer settings from a development system
In the SAP LT Replication Server development system, export each part of the mass transfer settings:
Export the advanced replication settings:
- Run the
LTRS
transaction. - Select the mass transfer records that you are transporting to production.
- From the File drop-down menu, select Export All Settings.
- In the Export Settings dialog, select a destination and click Save. The settings are saved in a compressed file in CSV format on your local workstation.
- Run the
Export the BigQuery Connector for SAP mass transfer settings:
Run the
/GOOG/SLT_SETTINGS
transaction:/n/GOOG/SLT_SETTINGS
In the Settings Table field, select Mass Transfer.
Select the mass transfer records that you are transporting to production.
Click Transport Mass Transfer.
In the Prompt for Workbench request, enter the transport request number and click the Continue icon. For each selected mass transfer record, the settings from the following custom configuration tables are included in the transport:
/GOOG/BQ_MASTR
/GOOG/BQ_TABLE
/GOOG/BQ_FIELD
The mass transfer settings are saved to a transport request.
Export the client key settings by manually including the contents of the
/GOOG/CLIENT_KEY
table in the transport request.Save the files to your local workstation.
Import mass transfer settings into a production system
In the SAP LT Replication Server production system, import each part of the mass transfer settings:
Create an SAP LT Replication Server replication configuration for the mass transfer settings.
Import the advanced replication settings:
- Run the
LTRS
transaction. - Select the mass transfer that you created in the first step.
- From the File drop-down menu, select Import All Settings.
- In the Choose File dialog, select the compressed file from your local workstation and click Open. The settings are imported as settings for the mass transfer.
- Run the
Import the transport request that contains the mass transfer settings.
Run the
SM30
transaction.Update the client key settings as necessary for the production environment.
Run the
/GOOG/SLT_SETTINGS
transaction:/n/GOOG/SLT_SETTINGS
Verify that the correct mass transfers are displayed in the Mass Transfers screen.
In the Mass Transfer ID column, replace the mass transfer ID from the development system with the mass transfer ID from the replication configuration that you created in the first step.
In the subsequent Tables and Fields settings screens, update other values for the table and field mapping as necessary for the production environment.
Test the configuration by starting an initial load or replication. For information about starting an initial load or replication, see:
- If SAP LT Replication Server is running on a Compute Engine VM, Test replication.
- If SAP LT Replication Server is running on a host that is external to Google Cloud, Test replication.
Update BigQuery Connector for SAP
Google Cloud delivers new releases of the BigQuery Connector for SAP as SAP transports.
SAP administrators can update BigQuery Connector for SAP by following these steps:
- Deactivate the configuration in SAP LT Replication Server.
- Import the new SAP transport request.
- After validating the successful import and object activation, activate the configuration in SAP LT Replication Server.
Update the gcloud CLI
You need to keep the Google Cloud CLI updated on the SAP LT Replication Server host.
For more information about managing the gcloud CLI, see Managing gcloud CLI components.
Monitoring
You can monitor several different points along the data path from the SAP data source to the target BigQuery table, including:
- Infrastructure - network, hardware and operating system
- The SAP database layer
- The SAP application layer
- BigQuery Connector for SAP
- BigQuery
Your options for monitoring at each of these points are presented in the following subsections.
Monitoring the infrastructure
On Google Cloud, you can install the Ops Agent on your host VMs for advanced monitoring and logging. The Ops Agent sends the data to Cloud Monitoring in the Google Cloud console.
For more information, see:
For systems that are not running on Google Cloud, you can also get
server information by running SAP transactions, such as
transaction ST06
.
Monitoring the database layer
Use standard SAP transaction codes to monitor the health of the database.
The transaction code DBACOCKPIT
is the most common transaction for
monitoring the database. This transaction also provides detailed
logs that you can use for troubleshooting errors.
For SAP HANA, you can use SAP HANA Studio for SAP HANA operations. You can install SAP HANA Studio on any front-end machine.
When troubleshooting performance or other issues, check the following things in the source database:
- Expensive SQL Statements
- Locks
- Load history
- Indexes
- Processes
Monitoring the application layer
You can use SAP application monitoring and troubleshooting tools to monitor and troubleshoot BigQuery Connector for SAP, because it runs in the application layer.
SAP application monitoring and troubleshooting can be further classified into the following:
- Standard SAP monitoring and troubleshooting
- BigQuery Connector for SAP monitoring and troubleshooting
For larger landscapes, you can use the SAP Solution Manager as a central monitoring tool.
You can use the SAP transaction codes in the following list to monitor and diagnose issues on individual SAP application systems:
- SLT configuration status:
LTRC
- SLT errors and logs:
LTRO
andSLG1
- Internet Communication Manager (HTTP and HTTPS Calls):
SMICM
- Security and certificates:
STRUST
- SAP transports:
STMS
- RFC connections:
SM59
- OS command:
SM69
- Package check:
SE80
- Authorization checks:
SU53
- Background jobs:
SM37
- System logs:
SM21
Monitoring BigQuery
Use Cloud Monitoring to view BigQuery metrics and
create charts and alerts. Each metric has a resource type, either
bigquery_dataset
, bigquery_project
, or global
, as well as a set of
labels.
Use the resource types and labels to build queries in the Monitoring Query Language (MQL).
You can group or filter each metric by using the labels.
For more information about Monitoring, see the Cloud Monitoring documentation.
Replication validation
If you select the Extra Fields Flag when you create the target
BigQuery table with transaction /GOOG/SLT_SETTINGS
,
columns are added to the table schema
for storing the type of change to each record that triggered replication
and for a timestamp that reflects the time at which SAP LT Replication Server received the portion that contained the record.
You can use the change types and the timestamp to query the following types of record counts:
- The number of records that are loaded into a BigQuery table during an initial load.
- The number of records replicated on a specified day into a BigQuery table.
- The total number of unique records in a BigQuery table.
To get these counts, you can query the BigQuery table directly by submitting SQL queries in the Google Cloud console, or you can run the Replication Validation tool, which generates reports that compare the BigQuery record counts with SAP LT Replication Server statistics or record counts from the source table.
For an overview the Extra Fields Flag, see Extra fields for record changes and count queries.
For information about how to specify the Extra Fields Flag, see:
- If SAP LT Replication Server is running on a Compute Engine VM, see Specify table creation and other general attributes.
- If SAP LT Replication Server is running on a host that is external to Google Cloud, see Specify table creation and other general attributes.
SQL queries for record counts
On the BigQuery SQL Editor page in the Google Cloud console, you can run SQL queries to check the record counts in your BigQuery tables.
You can then compare the BigQuery record counts with the counts in the source table or in the SAP LT Replication Server statistics.
Query the count of records inserted in initial load mode
When a BigQuery table schema includes the optional
operation_flag
column, records that are inserted into the table
in initial load mode include the L
operation flag.
To get the count of records that were received by BigQuery during an initial load, execute the following query:
SELECT COUNT(*) FROM `PROJECT.DATASET.TABLE` WHERE operation_flag = 'L'
Query the number of records inserted in replication mode
When a BigQuery table schema includes the optional
operation_flag
column, records that are inserted into the table
in replication mode include one of the following operation flags:
I
: the record was inserted into the source table.D
: the record was deleted from the source table.U
: the record was updated in the source table.
To get the count of records that were received by BigQuery in replication mode, run the following query:
SELECT COUNT(*) FROM `PROJECT.DATASET.TABLE` WHERE operation_flag = 'I' | 'D' | 'U'
Query the total count of records in a BigQuery table
When a BigQuery table schema includes the optional
recordstamp
column, the corresponding recordstamp
field of each record
that is inserted into the table contains a timestamp that indicates when
the record was sent by SAP LT Replication Server to BigQuery.
To get a total count of the records in a BigQuery table
that you can compare with the total count of records in a source table,
you can use the recordstamp
and is_deleted
fields to count the unique
records in the BigQuery table that have not been deleted
from the source table.
If the source table is being actively updated or replication is active when you query the records, the count of records in the source and target tables might not match exactly.
To get the current count of unique records in the BigQuery target table, run the following query:
SELECT COUNT(*) FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY KEY_FIELD_1, ..., KEY_FIELD_N ORDER BY recordstamp DESC) row_num FROM `PROJECT.DATASET.TABLE` ) WHERE row_num = 1 AND is_deleted = false
Replication Validation tool
This section provides an overview of the Replication Validation tool and what you can do with it.
The Replication Validation tool generates reports that compare the record counts in the BigQuery table with SAP LT Replication Server statistics and the record counts in the source table. If the counts don't match exactly, the tool flags the report with a red circle.
To count the records in BigQuery, the tool uses the SQL queries that are shown in the preceding section, SQL queries for record counts.
Run the Replication Validation tool periodically to validate that SAP LT Replication Server and the BigQuery Connector for SAP are replicating records to BigQuery as expected.
To run the Replication Validation tool, enter the custom transaction
/GOOG/REPLIC_VALID
preceded by /n
in the SAP GUI. For
step-by-step instructions, see:
- If SAP LT Replication Server is running on a Compute Engine VM, Run the Replication Validation tool.
- If SAP LT Replication Server is running on a host that is external to Google Cloud, Run the Replication Validation tool.
Replication validation reports
You can generate the following validation reports with the Replication Validation tool:
- Initial Load Counts: A comparison of the number of records that were sent by SAP LT Replication Server in load mode and the number of records that were loaded into BigQuery.
- Replication Counts: A comparison of the number of records that were sent by SAP LT Replication Server in replication mode and the number of records that were inserted into BigQuery on a specified day.
- Current Counts: A point in time comparison of the number of records that are in the source table and the number of unique records in BigQuery.
You can generate each report individually or, by selecting All Checks when you run the tool, you can generate all three reports in a single execution.
Displaying Replication Validation reports
After you generate a report, you can display the report by selecting the Display Report radio button in the Processing Options section of the Replication Validation tool interface.
The information that the Replication Validation tool displays in each report differs slightly depending on the type of report.
All of the reports include the following types of information:
- Source record counts from SAP LT Replication Server statistics and the source table.
- Target record counts from the target BigQuery table.
- Any difference between the two counts. The difference is calculated by subtracting the BigQuery counts from the source record counts. A positive value indicates a likely problem, because it suggests that not all source records are making it into BigQuery.
- The difference in the counts displayed as a percentage of source record count.
- A visual indicator of whether the source and target counts are equal or different.
Unequal record counts
The Replication Validation tool includes a status field with each report it displays.
A green square in the status field means that the source record count is equal to the target record count in BigQuery.
A red circle in the status field means that the record counts are not equal.
An unequal record count does not always indicate a problem. The following indicators suggest a possible problem:
- For a Current Counts report, an unequal value always indicates a problem.
For an Initial Load Counts or Replication Counts report, a positive value indicates a likely problem.
A relatively low negative value is not a problem. The count in a target BigQuery table can sometimes be a little higher than the source record count due to events such as momentary connectivity disruptions that cause SAP LT Replication Server to resend data.
If you see an unequal count, rerun the report to make sure it was not caused by a transitory issue. An unequal record count can occur due to replication processing at the time the tool generated the report.
For a very large source table or a table that has filters set in SAP LT Replication Server for initial load or replication, the Replication Validation tool might not be able to count all of the records that are required for an equal count.
Scheduling validation checks
You can schedule the Replication Validation tool to run automatically at intervals by using the SAP background job functionality.
Edit the BigQuery field map in a CSV file
The following sections describe how to export the default field mapping so that data engineers or BigQuery administrators can edit the target field values without requiring access to SAP LT Replication Server.
Create a spreadsheet or text file of the default field mappings
To create a CSV file for editing outside of SAP LT Replication Server:
Run the
/GOOG/SLT_SETTINGS
transaction.In the SLT Settings Maintenance screen, specify the following values:
- In the Settings Table field, specify Fields.
- In the Mass Transfer Key field, specify the ID of the mass transfer that you are updating.
- In the Table Name field, either leave the field blank to work with all fields from all tables or specify a table name to work with a specific table.
- Leave all other fields blank.
Click the Execute icon. The BigQuery Settings Maintenance - Fields screen displays.
On the BigQuery Settings Maintenance - Fields screen, hide all columns except for those in the following list by right-clicking on the column headings and selecting Hide from the drop-down menu:
- SAP Table Name
- SAP Field Name
- External Data Element
- External Field Name
- Field Description
With the five remaining columns displayed, click the Export icon.
From the Export menu, select one of the following options:
- Spreadsheet
- Local file. For ease of converting the file contents to CSV format, we recommend saving the file in the Text with tabs format.
Save the default field mappings by clicking the Checkmark icon.
Convert the spreadsheet or text file to CSV format
To upload edited field mappings by using the custom transaction
/GOOG/SLT_SETTINGS
, the field mappings
must be in CSV format.
If you are using a spreadsheet, save the spreadsheet as a CSV file before you upload the file.
If you are using a local file in a tab-separated format or any other format, you need to modify the file to conform to CSV format.
For example:
SAP Table,SAP Field Name,External Data Element,External Field Name,Field Description SAP_TABLE_NAME,SAP_FIELD_NAME1,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME1,BIGQUERY_FIELD_DESCRIPTION1 SAP_TABLE_NAME,SAP_FIELD_NAME2,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME2,BIGQUERY_FIELD_DESCRIPTION2 SAP_TABLE_NAME,SAP_FIELD_NAME3,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME3,BIGQUERY_FIELD_DESCRIPTION3
Upload the CSV file
To upload an edited CSV file:
Run the
/GOOG/SLT_SETTINGS
transaction.In the SLT Settings Maintenance screen, specify the following values:
- In the Settings Table field, specify Fields.
- In the Mass Transfer Key field, specify the ID of the mass transfer that you are updating.
- Select the Upload from file checkbox.
Click the Execute icon. The Select File to Upload dialog opens.
In the Select File to Upload dialog, select the CSV file that contains the edited field values.
Click Open.
If you receive a security warning, click Allow. The file loads and the modified values in the file appear on the applicable rows in the BigQuery Settings Maintenance - Fields screen.
Click the Save icon.
To confirm the values are applied, compare the values in the CSV file with the values that are displayed by SAP LT Replication Server.
Handling errors in the source data
Upon receiving a chunk of records from BigQuery Connector for SAP, the BigQuery streaming API checks for data errors before inserting any records into the BigQuery table.
You can control how the BigQuery API and the BigQuery Connector for SAP respond when data errors are found by specifying the following flags in mass transfer settings:
- The
Skip Invalid Records
(SKIP
) flag - The
Break at First Error Flag
(BREAK
) flag
The SKIP
flag
If you specify the SKIP
flag, when
the BigQuery API receives a chunk of records and finds a
record with a data error, then the BigQuery API discards,
or skips, the record with the error and continues inserting all other
records from the chunk into the BigQuery table.
If you do not specify the SKIP
flag, when BigQuery
finds a record with a data error, BigQuery discards the entire
chunk without inserting any records from it into the BigQuery
table. This is the default behavior.
Specifying the SKIP
flag is best for development and QA environments,
and is not recommended for production environments.
You can specify SKIP
flag in the /GOOG/SLT_SETTINGS
transaction when
you are configuring replication. The specification is stored in the
/GOOG/BQ_MASTR
configuration table.
To see how SKIP
specifications interact with BREAK
specifications,
see Matrix table for SKIP
and BREAK
interactions.
The BREAK
flag
If you specify the BREAK
flag, when
BigQuery Connector for SAP is notified by the BigQuery API that
a data error was found in a record, BigQuery Connector for SAP stops
sending records to BigQuery and terminates the
replication job.
If you do not specify the BREAK
flag, when
BigQuery Connector for SAP is notified by BigQuery that
a data error was found in a record, BigQuery Connector for SAP continues
sending records to BigQuery by sending the next chunk
and the replication job continues. This is the default behavior.
Specifying the BREAK
flag is recommended in production environments.
You can specify BREAK
flag
in the //GOOG/SLT_SETTINGS
transaction when you are configuring replication.
The specification is stored in the /GOOG/BQ_MASTR
configuration table.
To see how BREAK
specifications interact with SKIP
specifications,
see Matrix table for SKIP
and BREAK
interactions.
Matrix table for SKIP
and BREAK
interactions
You can configure BigQuery Connector for SAP to handle data errors in the following ways:
SKIP flag |
BREAK flag |
Behavior |
---|---|---|
FALSE | TRUE |
BigQuery discards the current chunk of records without inserting any records from the current chunk into the BigQuery table. BigQuery Connector for SAP sends no more chunks of records from the current portion and tells SAP LT Replication Server to terminate the replication job. This is the recommended setting. |
FALSE | FALSE |
BigQuery discards the current chunk of records without inserting any records from the current chunk into the BigQuery table. BigQuery Connector for SAP sends any remaining chunks of records from the current portion of records and then tells SAP LT Replication Server to terminate the replication job. This is the default. |
TRUE | TRUE |
BigQuery discards only the record that contains the error and inserts the rest of the records in the current chunk into the BigQuery table. BigQuery Connector for SAP sends no more chunks of records from the current portion and retrieves the next portion. BigQuery Connector for SAP does not tell SAP LT Replication Server to terminate the replication job. |
TRUE | FALSE |
BigQuery discards only the record that contains the error and inserts the rest of the records in the current chunk into the BigQuery table. BigQuery Connector for SAP sends any remaining chunks of records from the current portion and retrieves the next portion. BigQuery Connector for SAP does not tell SAP LT Replication Server to terminate the replication job. |
Table structure changes
This section explains how to modify the SAP source table structure, for which
an existing LTRC
replication is in progress.
Add a column to a source table
To add a new column to a source table, follow these steps:
Add a new column to the source table. As a result of this step, the replication status changes to
Load/Replication blocked
.In your SLT system, reset the replication status using transaction
LTRC
. For more information from SAP about how to reset the replication status, see SAP Note 2204955 - SLT tables are in status 'Load /Replication blocked'.Add, update, or delete an entry in the source table.
Validate the replication result in BigQuery.
Delete a column from a source table
To delete an existing column from a source table, follow these steps:
In your SLT system, suspend the replication using transaction
LTRC
.Delete a column from the source table. As a result of this step, the existing SLT triggers are either deleted or changed to an inconsistent state.
In BigQuery, delete the column from the target BigQuery table. For more information about the steps to delete a column from an existing table, see the BigQuery documentation.
In your SLT system, resume the replication using transaction
LTRC
.In your SLT system, recreate the SLT triggers. For more information from SAP about how to recreate SLT triggers, see SAP Note 2254376 - SLT trigger(s) in an inconsistent state.
If the replication status is
Load /Replication blocked
, then reset the replication status using transactionLTRC
. For more information from SAP about how to reset the replication status, see SAP Note 2204955 - SLT tables are in status 'Load /Replication blocked'.Clear the old logs, if any.
Add, update, or delete an entry in the source table.
Validate the replication result in BigQuery.
Change the data type of an existing column
When you change the data type of an existing column in SAP source table, you need to follow specific steps depending on whether you are changing the data type to a compatible or non-compatible data type with the target BigQuery table.
A data type is compatible with the data type in the target
BigQuery table when the existing data type
and new data type of an existing column map to the same data type in the target
BigQuery table. For example, if the data type
of a column is changed from INT1
to INT2
in a source table, then both the
data types are compatible with the data type INTEGER
in the target
BigQuery table.
For more information about data type mapping in BigQuery Connector for SAP, see Data type mapping.
Change the data type to a compatible data type
To change the data type of an existing column to a compatible data type, follow these steps:
Change the data type to a compatible data type in the source system. As a result of this step, the existing SLT triggers are either deleted or changed to an inconsistent state.
In your SLT system, recreate the SLT triggers. For more information from SAP about how to recreate SLT triggers, see SAP Note 2254376 - SLT trigger(s) in an inconsistent state.
If the replication status is
Load /Replication blocked
, then reset the replication status using transactionLTRC
. For more information from SAP about how to reset the replication status, see SAP Note 2204955 - SLT tables are in status 'Load /Replication blocked'.Clear the old logs, if any.
Add, update, or delete an entry in the source table.
Validate the replication result in BigQuery.
Change the data type to a non-compatible data type
To change the data type of an existing column to a non-compatible data type, follow these steps:
- In your SLT system, stop the replication using transaction
LTRC
. - In BigQuery, delete the target table.
- Change the data type in the source system.
- In your SLT system, start the replication using transaction
LTRC
.
Enhancement exits
BigQuery Connector for SAP provides several enhancement points in its code where an ABAP developer can insert code to add custom functionality.
The following table lists the functions that the enhancement points support, the methods, and the class that contains the enhancement point.
Function | Class | Method | Spot | Option |
---|---|---|---|---|
Update the mapping for a field, such as the external field name, the data type, and so on. | /GOOG/CL_IUUC_REPL_RUNTIME |
CREATE_FLD_MAPPINGS |
/GOOG/ES_IUUC_REPL_RUNTIME |
/GOOG/UPDATE_FIELD_MAPPING |
Update the mapping for the field table by adding or removing fields. | /GOOG/CL_IUUC_REPL_RUNTIME |
CREATE_FLD_MAPPINGS |
/GOOG/ES_IUUC_REPL_RUNTIME |
/GOOG/UPDATE_FIELD_MAPPINGS |
Change the value of a source field before the field is converted to a target field. | /GOOG/CL_IUUC_REPL_RUNTIME_BQ |
FILL_TARGET_RECORDS |
/GOOG/ES_IUUC_REPL_RUNTIME_BQ |
/GOOG/CHANGE_SOURCE_FIELD |
After a source field is converted to a target field in the target table, change the value of the target field. | /GOOG/CL_IUUC_REPL_RUNTIME_BQ |
FILL_TARGET_RECORDS |
/GOOG/ES_IUUC_REPL_RUNTIME_BQ |
/GOOG/FILL_TARGET_FIELD |
Add a field to the target table that does not exist in the source table during the source-to-target table conversion. | /GOOG/CL_IUUC_REPL_RUNTIME_BQ |
FILL_TARGET_RECORDS |
/GOOG/ES_IUUC_REPL_RUNTIME_BQ |
/GOOG/FILL_EXTRA_FIELD |
Prepare a BigQuery schema field before the BigQuery table is created. | /GOOG/CL_GCP_CLIENT_BQ |
PREP_BQ_TABLE_SCHEMA |
/GOOG/ES_GCP_CLIENT_BQ |
/GOOG/PREPARE_SCHEMA_FIELD |