Qlik Replicate using SAP Hana Log Base Source Endpoint processes cached changes row by row

[Bill_Steinagle]

This article aims to explain why a Qlik Replicate Full Load CDC task processes cached changes for tables row by row when the Source Endpoint is a SAP Hana Log Base Endpoint.

The behavior is normal for the Source Endpoint due to the use of the internal table hana_row_id. This table can change during the Full Load processing of any table(s) in the task. For any Full Load or CDC task, Qlik Replicate will cache the uncommitted changes for the given table(s) to be processed once the Full Load is complete.

Once the Full Load is complete, Qlik Replicate will process all the cached changes. Since hana_row_id can change, this causes the task to process the cached changes row by row, rather than using batch optimized processing.

Example:

The internal table created on the Target Endpoint, such as attrep_changesxxxxx (a temp table), captures changes for tables with the Primary Key to batch them up to be processed to the target.

But as the SAP Hana Log Base Endpoint uses hana_row_id as the Primary Key, which can change, the batch optimized process switches the processing mode to row by row, causing Task Latency on the Target.

Environment

• Qlik Replicate
• SAP Hana Log Base Source Endpoint