Configuring HANA Sidecar and SDI for Replication: A Case Study

Integrating Applications with RISE with SAP

Integrating non-SAP solutions into an SAP environment can be complex, especially in environments involving both cloud and on-prem systems.

This case study explores how apiphani successfully integrated an industry-specific non-SAP application for a client across three different environments: The client’s on-prem data center, RISE with SAP S/4 HANA on Azure Cloud, and the client’s existing AWS Cloud for Business Warehouse and Business Planning and Consolidation (BW/BPC).

Apiphani deployed and configured SAP HANA Smart Data Integration (SDI) with an SAP HANA sidecar to replicate data from a client S/4 HANA landscape to Powerplan, an industry-specific solution for utilities.

While this case study describes some of the specifics of the Powerplan set up, it is intended to describe the mechanics of the HANA sidecar and SDI elements of the solution and how it is applicable to any replication scenario.

Overview

Powerplan is software used by asset-intensive companies such as utilities that need to “stay ahead of accelerating tax and regulatory changes, and optimize compliance, strategic decision making and financial performance.”

Internally, the application contains Project, Asset, and Depreciation modules, each of which contain many master data attributes which are related to the General Ledger (GL).

The SAP SDI is used to replicate specific information from the S/4 HANA modules into a HANA sidecar database, where it can be converted by the Powerplan application and returned to SAP S/4 HANA as future state master data.

The process facilitates the outbound postings from Powerplan to SAP S/4 for capital asset-related activity as well as inbound integration for work breakdown structure (WBS) headers and transactions.

The master elements that need to be converted include:

• Company
• GL accounts
• Department

Powerplan supports either System Landscape Replication (SLT) or SDI to move the data between the S/4HANA systems and the Powerplan software. Since the client already had a functioning SDI environment working in conjunction with the BW/BPC environment, apiphani chose the SDI method.

The Solution as Architected

Apiphani deployed an SAP HANA SDI environment to allow data replication between RISE for SAP S/4 system on Azure Cloud and the Powerplan SAP HANA sidecars deployed in the client’s existing AWS Cloud. This involved configuring several HANA interfaces and replication tasks using the SDI agents and HANA sidecar virtual tables.

Apiphani created 32 replication tasks, one for each required table, filtering data by Company and Client.

Figure 1 – Solution Architecture

In Figure 1 we can see the integration of the three different locations: The customer’s on-premise VMware environment, RISE for SAP S/4 hosted in MS Azure, and the SAP HANA sidecars which apiphani deployed in the client’s existing BW/BPC AWS cloud environment.

The Solution as Implemented

Below are the steps we executed to make all this work:

• We installed two HANA sidecars. We created two tenants on the non-production sidecar, one for development and one for test, and created a single production tenant DB on the second sidecar.
• We increased the CPU and memory on the existing non-production SDI agent server to accommodate two more agents.
• We installed and configured the two new agents on the non-production SDI server and connected them to each tenant DB, DEV, and QAS.
• We installed and configured the production SDI agent and connected it to the PRD tenant DB.
• We created the Powerplan user on each of the S/4 HANA DBs, allowing access to the SAPHANADB schema containing the tables to be replicated while making sure to grant access to SELECT and TRIGGER on each.
• We used the CUSTOM_USER_ROLE_ADMIN user provided by the RISE team to create a second account. This second account had privileges to create custom roles; in this case we created a custom role that allowed the POWERPLAN user to select and trigger on tables under SAPHANADB schema.
• We then configured the Remote Data sources using the HANA Adapter type.
• Lastly, we created all the Replication Tasks, as shown below in Figure 2.

Figure 2 – Replication Tasks

Problems Encountered, and Solutions – Tips for You

Here are some issues that we encountered, along with the steps we took to resolve them. Both the issues and solutions are applicable to any replication scenario. We hope you find this information helpful.

Tip #1: Double-Check Roles and Permissions

When creating the replication task for table CSKT, we got an error message that was not at all friendly. It turned out to be related to a lack of authorization on the RISE S/4 side, although this was not immediately apparent.

In this specific case we did not grant TRIGGER for SCHEMA SAPHANADB. In case you encounter anything similar, check the Data Provisioning (DP) agent error log file (framework_alert.trc) located in /&AGENT_HOME/log for all low-level error messages.

Example:

[ERROR] [af0655b3-9254-4ded-a552-e8ebb5a25eab28968] HanaAdapterDelegate | ExceptionUtil.newAdapterException [] – Failed to add the first subscription. Error: Required privileges and/or roles not granted to the database user [POWERPLAN]. Missing privileges and/or roles are [TRIGGER ON [“SAPHANADB”.”CSKT”]]. Required privileges and/or roles not granted to the database user [POWERPLAN]. Missing privileges and/or roles are [TRIGGER ON [“SAPHANADB”.”CSKT”]].

Tip #2: Reset the Subscription After Making Changes to Replication Task Properties

If you want to change a replication task, either changing the client or any other property, the subscription needs to be reset first.

We received an error while activating the replication task as follows:

/powerplan/ACDOCA.hdbreptask:[powerplan:ACDOCA.hdbreptask] transaction rolled back by an internal error: sql processing error: Remote subscription powerplan::ACDOCA.SUB_V_SAPHANADB_ACDOCA is Active. Reset the remote subscription and retry the operation.[:.] Rollback detected while activating objects of runtime “Replication task runtime”

Reset here: Mark the replication task and click reset, then save the replication task and execute in the editor.

Figure 3 – Subscription Reset

Tip #3: Watch Key Definitions

We generated duplicate records in the ACDOCA table, because when the target virtual table is created, the default behavior is to do so without a primary key.

This in turn prevented the selection of UPSERT as the remote subscription type. The fix is to create a Primary key matching the key that the source table has in the S/4 HANA system.

Figure 4 – Primary Key Definition

This allowed the selection of UPSERT and prevented having duplicate records in the target table.

A remote subscription of type UPSERT replicates data in real-time from a remote source object to a table on the local SAP HANA database.

Type UPSERT means that all types of data changes (inserts, updates, and deletions) are written to the target table with an UPSERT SQL command.

For keys that have been deleted from the remote source object, the statement writes the value D to column SDI_CHANGE_TYPE in the target table.

In other cases, the statement writes the value A to column SDI_CHANGE_TYPE. The commit timestamp of the transaction is written to column SDI_CHANGE_TIME.

More details about UPSERT can be found here.

Tip #4: Use the Truncate Table Upon Execution Option to Avoid Primary Key Violation Errors

If you see a primary key violation when running a replication task, we recommend that selecting option “truncate table on execution.” This will prevent primary key (PK) violation errors.

Conclusion

This process served as a good illustration of how the SDI can be used to handle interfaces between RISE with SAP S/4 landscapes and other supported ancillary applications that are required to run the business. While the Powerplan application was the end target in this case, the SDI replication scenario is broadly applicable.

Key Points Summary:

1. Extending the existing SDI environment – including the DP agent servers – to handle this particular replication scenario worked well. We had already stacked four non-production DP agents on the existing server, and we increased the available resources before adding two more.
2. Placing both the development and quality assurance HANA tenants on a single HANA sidecar database instance saved costs without adding undo administrative complexity.
3. If faced with an opaque error message during replication, it may well be related to database permissions. Check the DP agent error log for more detail/clarity.
4. Changing any replication task property requires a subscription reset.
5. Be careful to match your primary key definitions between the source S/4 system and the HANA sidecar database. Any changes in table structure on the source side must also be reflected in the sidecar database.
6. In the same vein, use the “truncate table upon execution” option to clean out the sidecar database after a structure change to avoid primary key violation errors.

We hope you find this illustration helpful – please feel free to contact us with any questions via our contact form.