Skip to Content

Welcome to the second part of my blog series on SAP HANA blockchain. My last blog already gave an impression on how SAP HANA blockchain works and which components are involved in getting blockchain data into a SAP HANA database. With this blog, I’d like to provide some more details on these components and their interplay, as well as the features that they enable. This is then concluded by a brief overview on how to get started with the SAP HANA integration service.

Part 1: SAP HANA Blockchain: An Introduction

Part 2: SAP HANA Blockchain: Technical Overview

Part 3: SAP HANA Blockchain: Setup SAP HANA, express edition for HANA blockchain

How SAP HANA blockchain works

My last blog already gave an impression on how SAP HANA blockchain works and which components are involved in getting blockchain data into a SAP HANA database. With this blog, I’d like to provide some more details on these components and their interplay, as well as the features that they enable.

An important fact – and common source of misunderstandings – is that SAP HANA is not acting as a node in a blockchain network all by itself. It is instead leveraging the SCP Blockchain Service as a gateway. The interaction with the network is managed by the SCP blockchain service. The blockchain network itself consists of different nodes that can be hosted on SAP Cloud Platform, any other cloud service provider or even on-premise. Additional services like the HANA integration and other application enablement services are only available if the blockchain node is hosted on SCP.

The SAP HANA Integration Service connects the SCP Blockchain service to SAP HANA. It is also used to configure the connection properties on SCP side. This includes the mapping of blockchain messages to the columns of a database table, read/write or read-only access and table types. There are three types of tables.

  • Raw data: Information about blocks and transactions.
  • Ledger: Individual messages; allow access to the whole history of transactions that were committed to the blockchain.
  • Worldstate: Only the latest valid tuples that are known to the blockchain. A worldstate table looks and behaves in many ways just like a regular database table.

Ledger and worldstate tables contain transaction-specific information as well, like the timestamp and block number.

The connection between SAP HANA and the integration service is established via Smart Data Integration (SDI). The result is a remote source in SAP HANA that can be mapped into a database schema via virtual tables.

Synchronizing SAP HANA and SCP Blockchain service

SAP HANA uses Smart Data Integration (SDI) to retrieve data from and send data to the SCP Blockchain service. Three components are involved in this.

  • The data provisioning server is part of SAP HANA.
  • Data provisioning adapters are specific to each type of data source. SDI is delivered with a set of predefined adapters for various remote sources, but also provides an SDK for custom built adapters.
  • Data provisioning agents host data provisioning adapters. Agents can be deployed on any server that has a network connection to SAP HANA and the remote source – in this case your Blockchain in SCP. Deploying it on the same server as SAP HANA is possible as well, although it is recommended to deploy it as close to the data source as possible.

Accessing data from the blockchain

Mapping the remote source into a database schema via virtual tables is already the first step to enable SAP HANA to access data on the blockchain. Virtual tables provide a symbolic link to the data on the blockchain. This means that data is retrieved on-demand with every single query. Especially for large blockchains or performance-critical applications, this is most likely not an ideal solution.

The big benefit of SAP HANA blockchain is its ability to persist blockchain data locally in the database. This is done via a remote subscription, which reads the data from the blockchain, writes it to a physical database table in SAP HANAs column store and keeps this table and the blockchain in sync by regularly polling the blockchain. Once this is set up, you can leverage the full feature set of SAP HANAs column store with your blockchain data. This includes SAP HANAs advanced analytic engines for graph and geospatial data, as well as machine learning algorithms and text search. Plus, of course, data modelling options with calculation views, etc.

Writing data to the blockchain

The virtual worldstate table supports DML statements like INSERT, UPDATE, and DELETE and feels very much like a regular database table in that regard. The statement will, of course, not actually update or delete anything that was written to the blockchain. This would violate one of the most fundamental blockchain paradigms: The immutability of transactions. Instead, it inserts a new record to the ledger that effectively invalidates the previous one from an application perspective. The big benefit is that an application developer doesn’t need to be aware of this process at all. It is completely transparent, just as if it was a regular database table, while the blockchain magic happens in the background. The only noticeable difference is that the transaction is not committed until a new block has been created that contains the transaction.

Configuring the SAP HANA Integration Service

Before you can work with SAP HANA blockchain, you will need to perform a few configuration steps on SAP Cloud Platform (SCP) side. Let’s assume you already have an account on SCP with an instance of Hyperledger fabric. This account has a subaccount with one Hyperledger fabric channel and an instance of the SAP HANA integration service. The SAP HANA integration service is part of the Application Enablement Services. Refer to the official documentation for more information on how to create the integration service.

At this stage, I assume that Hyperledger fabric was already setup. More information on how to do that, on how to work with and deploy chaincode, etc. is available in the official documentation.

The channel provides an isolated communication line on the blockchain for you and other authorized parties, but with safe isolation from everyone that is not authorized. The SAP HANA integration service connects your channel to a SAP HANA database and is used to configure this connection. The configuration screen is displayed in the screenshot above. As mentioned earlier, you can define whether to have a connection read-only or read/write, you can configure the table types that will be available in the remote source on SAP HANA and – finally – set the mapping of messages on the blockchain to a two-dimensional database table.

The example in the screenshot above defines a very simple table layout to track personal information via a blockchain. On SAP HANA, this will then look and behave very much like a normal relational database table.

The connection details that are displayed above are required later when configuring the remote source on SAP HANA. As we remember, SAP HANA doesn’t connect directly to the SCP Blockchain service, but to the HANA integration service. The following details must be extracted from the service key of your SAP HANA integration service:

Parameter Example
Service URL e.g., “https://blockchain-service.cfapps.eu10.hana.ondemand.com/blockchain”
Authentication URL e.g., “https://hanabccuv.authentication.eu10.hana.ondemand.com”
Client ID e.g., “sb-7d165a60-…-420adfc9-f96e-4090-a650-0386988b67e0!b1836“
Secret e.g., “TJmM…Wsg=”

Once the SAP HANA integration service was configured and you’ve noted down the service key, you can proceed and create the remote source in SAP HANA. An example on how to do that with SAP HANA, express edition, is shown in the next part of this blog series.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Sitakant Tripathy

     

    Hi Andreas,

    thanks for throwing light on this. Could you please help me with the following:

    • I think productive applications will be a combination of on and off chain data sets. Is the service configurable to only pick and choose a subset of actual HANA db table elements to the blockchain.
    • what would be the approach for managing successful internal HANA DB updates but failed transaction proposal validations on blockchain.

    Regards,

    Sitakant.

     

    (0) 
    1. Andreas Schuster
      Post author

      Hi Sitakant,

      data resides primarily on the blockchain and is only replicated to HANA. Regular HANA tables are not affected by this and can remain purely local.

      This is the approach we see for most applications – there will always be data that you do not want to share on the blockchain. Especially if blockchain is used as an enhancement to an existing application that didn’t use blockchain before.

      Transactions get submitted to the blockchain asynchronously. This means there’s no notification whether a transaction was accepted or not. An application will have to verify that manually. This applies to transactions on blockchain in general and is not specific to SAP HANA blockchain.

      Best regards,

      Andreas

      (0) 
  2. Luanna Passos

     

    Hello Andreas,

    Thanks for share this post with us. I would like to ask if have ideia what skills of a team to implement project ? Normally in ECC, we have process consultant, abap, basis etc… For on blockchain project what we need ? how do I structure a Blockchain  project ?Thanks in advance

    (0) 

Leave a Reply