2 How to Replicate Data from Azure to SAP Azure pushes the content of the CSV file (ADLS gen.2 storage) to BW/4HANA, for data replication.

On SAP BW/4HANA side, we need to first create the corresponding structure to Azure CSV file. Once

data from Azure is loaded to this table, it is further incorporated into Composite Provider with ADSO.

From the technical point of view the following objects will take part in this scenario:

• Azure BLOB

• Azure Data Factory via Integration Runtime (ODBC)

• SAP HANA Table

• SAP Calculation View

• SAP BW Composite Provider (including SAP BW ADSO)

• SAP Analytics Cloud

2.1 System specification

SAP system:

• SAP BW/4HANA 2.0 SP0

• SAP HANA Platform Edition 2.0 SPS03 Rev36, Version 2.00.036, Linux x86_64

Sizing:

Location: West Europe

Azure:

• Virtual Machine (self-hosted Integration Runtime)

Location: West Europe

• Azure Data Factory (AutoResolve Integration Runtime)

Location: West Europe

• Azure Storage Account

2.2 Data Model The data model is as follows:

On SAP BW/4HANA side, EMEA/NALA Actuals data is available through the ADSO InfoProvider:

The row count of EMEA/NALA Actuals data stored in BW/4HANA is 10 million.

The APAC Actuals are stored in Azure, in the form of CSV file stored within ADLS gen.2 container.

The row count of the APAC Actuals data stored in Azure is 4 million.

2.3 Integration Runtime Azure Data Factory uses a dedicated runtime. However, in case of any need to install specific drivers we

need to apply such changes in a self-hosted runtime. Since integration between Azure and SAP requires

ODBC driver, we need to create new Virtual Machine and attach this separate runtime to the ADF.

Therefore, we created new Virtual Machine with Windows Server O/S.

Once it’s set up, we installed SAP HANA Client (hanaclient-2.5.105-windows-x64) on the machine, as SAP

HANA Client contains ODBC driver inside.

The Virtual Machine must be turned on whenever we want to transfer any data between the systems.

To assign this Integration Runtime to ADF we need to register its keys, as shown below:

There is also a need to open the Database port on the Virtual Machine. SAP HANA needs port 30241 to

be opened for the purpose of Database connection.

2.3.1 Manage Integration Runtime To control the Virtual Machine that provides Integration Runtime, Function App has been created. With

such a function we can turn on the Virtual Machine when it’s needed and turn it off after all data

between SAP and Azure is transferred. Both activities are available as Azure Data Factory steps.

Here are the details of Function App:

We need to enable system assigned managed identity to register the Function App with Azure Active

Directory.

Once done, we can provide Role-Based security by adding the Virtual Machine Contributor role to the

Function App.

Below function code has been implemented in Function App to switch on and off the indicated Virtual

Machine:

# Usage of the Function: <# $Body = @" { "subscriptionid": "<subID>", "vmname": "<virtualMachine>", "action": "<status/start/stop>" } "@ $URI = "https://hostname.azurewebsites.net/api/startVMs?code=FUNCTIONKEY" Invoke-RestMethod -Uri $URI -Method Post -body $body #> using namespace System.Net # Input bindings are passed in via param block. param($Request, $TriggerMetadata) # Input bindings are passed in via param block. param($Request, $TriggerMetadata) # Write to the Azure Functions log stream. #Write-Host "PowerShell HTTP trigger function processed a request." # Interact with query parameters or the body of the request. $subscriptionid = $Request.Query.subscriptionid if (-not $subscriptionid) {$subscriptionid = $Request.Body.subscriptionid} $vmname = $Request.Query.vmname if (-not $vmname) { $vmname = $Request.Body.vmname} $action = $Request.Query.action if (-not $action) {$action = $Request.Body.action} #Proceed if all request body parameters are found if ( $subscriptionid -and $vmname -and $action) { $status = [HttpStatusCode]::OK Select-AzSubscription -SubscriptionID $subscriptionid if ($action -ceq "status") { $body = Get-AzVM -Name $vmname -status | select-object Name, PowerState } if ($action -ceq "start") { $body = $action $body = Get-AzVM -Name $vmname | Start-AzVM } if ($action -ceq "stop") { $body = $action $body = Get-AzVM -Name $vmname | Stop-AzVM -AsJob -Force } } else { $status = [HttpStatusCode]::BadRequest $body = "Please pass a name on the query string or in the request body." }

# Associate values to output bindings by calling 'Push-OutputBinding'. Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{ StatusCode = $status Body = $body })

Lastly, we must prepare Function key to provide the ADF access to this Function App.

2.4 SAP BW/4HANA Connection

To set up the connection to SAP BW/4HANA we need to create linked service. We indicate the newly

created Integration Runtime, IP address of SAP BW/4HANA server and port. It takes advantage of

generic ODBC connector with SAP HANA driver to write data into SAP HANA. We used SAPHANADB user

for data transfer.

2.5 ADF Pipeline The pipeline consists of few steps: preparation of Integration Runtime, copying data from Azure to SAP

HANA and finally stopping the Integration Runtime.

2.5.1 Start/Stop Integration Runtime To transfer any data between SAP and Azure, ODBC connector installed on the self-hosted Integration

Runtime is required. Therefore, the Virtual Machine should be switched on before the “Copy data” step

execution. Once data is transferred, the Integration Runtme can be turned off.

To have a control on the Vritual Machine state, we use our custom Function App, where we need to

apply the URL as well as Function Key defined for this purpose.

Once done, we can provide the parameters in the “Body” section to specify whether we want to start or

stop the Virtual Machine.

2.5.2 ADF Copy data On the Source side, the CSV file stored in ADLS gen.2 is the source dataset of the ADF “Copy data” step:

On the Target system - SAP BW/4HANA, the corresponding table has been created to be populated by

Azure data:

On the Azure side we create the dataset, as follows:

The dataset can be now assigned to the “Sink” tab of “Copy data” step:

Pre-copy script is useful when we want to remotely clean-up the target table before inserting data. CSV

file stored on Azure BLOB is mapped to the HANA table structure.

2.5.3 ADF Execution and Performance We can track the progress and performance of data copy between the systems.

As shown above, the transfer of 4 million records from Azure to SAP BW/4HANA took 2 minutes

2.6 BW/4HANA data flow The entire dataflow looks like the following:

Once the Azure Data Factory pushes the data to the SAP HANA table, it is automatically available in the

reporting layer.

2.7 Results Having the Composite Provider joining data from both sources, enabled the creation of a report that

shows the Sales data from across all regions. The BEX Query data can be visualized in the SAP Analytics

Cloud dashboard and provides actionable insights.

In this scenario we were able to verify the integration option of the Azure data into the SAP systems. It

has been tested and confirmed that extraction of Azure data and combining it with the data from the

ERP system within the SAP BW/4HANA is possible in a reasonable time.

This solution is recommended for consolidation scenarios, where the Azure system is responsible for

pushing data to the Data Warehouse. Once the data coming from Azure is populated in the SAP HANA

system via the generic ODBC connector, the SAP BW/4HANA system can easily consume and expose it in

the common layer for presentation, for example in the SAP Analytics Cloud.