Integrating An SAP ABAP System With The Ethereum Mainnet [A Step-by-Step Guide]

You’ve likely heard of Ethereum in the context of cryptocurrency, but perhaps not so much in the context of enterprise software.

In this blog you will learn what Ethereum and Ethereum mainnet are. You will learn how easy it is to connect an SAP ABAP-based system to Ethereum mainnet, try out a demo, and see all the related source code.

The Ethereum Network

Firstly then, a whirlwind tour of Ethereum and its uses. Ethereum is some software you can run on a network of computers referred to as nodes. Each node can be thought of as being identical to all the others.

Nodes can run simple programs called smart contracts inside a virtual machine called the Ethereum Virtual Machine (EVM). These smart contracts have access to limited compute and storage resources.

Ethereum deals with transactions that can be triggered by an external user or process, can run a smart contract program and change the state of data held on the Ethereum network.

Transactions can be posted every 15 seconds or so and are atomic, they either succeed or fail. If they fail then all changes they made are undone. Similar to SAP business process transactions, an Ethereum transaction is intended to perform some limited business logic and storage.

Ethereum is not designed for compute-heavy, storage-heavy or very low-latency operations.

You can think of the Ethereum network like this, many different nodes each with an EVM running inside them:

Ethereum stores smart contracts and the data associated with them in a data structure called a blockchain, sometimes referred to as just a chain. New transactions get grouped into blocks and validated by all the nodes on the network.

Transactions are then added to the end of the chain, together with a “fingerprint” (a hash) representing all the previous blocks. This fingerprint feature makes it intentionally very difficult to retrospectively adjust data. The idea is that once a transaction is posted it has been validated by every node and is permanent.

So far so good, if a little unexciting. What is interesting is that when this Ethereum software is run on a network of nodes, a special feature emerges.

The special feature is that even if individual nodes are operated by strangers that you cannot necessarily trust, the overall network itself can be trusted to process transactions as the transaction originator intended.

This network is very resilient. The overall network can be trusted even if many node operators start colluding together to fiddle with data they are processing.

This special feature can be referred to as “the trustless network”. There is no central authority, middle-man or 3rd party that must be trusted to check that the network is processing transactions honestly. The network of strangers “polices itself”.

Ethereum is one example of Distributed Ledger Technology (DLT). The collection of transactions in blocks can be thought of as a ledger, and the network of nodes is the distributed part, hence it forms a DLT.

There is much more to how Ethereum works. The above summary omits a lot of detail that is not relevant to this article. For example, Ethereum is closely associated with cryptocurrency but that aspect is not of interest here.

If you want to read more, the book Mastering Ethereum by Andreas Antonopolous is highly recommended. It is free and open-source.

Ethereum is young, it turned 5 years old in July 2020 and is an ongoing project. Ethereum 2.0 development is underway which will, among other things, improve scalability. This article relates to the Ethereum 1.0 software that is available today.

Ethereum Mainnet

As you’ve just learned, Ethereum is software that you can run on a bunch of networked computers.

How big is a bunch?

Well, you could run it on a private network inside your enterprise (a private blockchain), or you could open it up a bit and allow known parties to have access and run nodes too, perhaps other enterprises you do business with.

When all the parties operating nodes are known, the network is called a permissioned blockchain. People can only join the network if they receive permission from those already running it.

An advantage of permissioned chains is that the entire network, all its data and logic, can be hidden from those that are not part of it. This is particularly desirable when dealing with sensitive information.

There are many use-cases where permissioned blockchains might make a good choice.

Software like IBM’s Hyperledger Fabric, JP Morgan’s Quorum and many others can be used for these cases. SAP offer Blockchain-as-a-Service options for chains like these and have some excellent documentation on the use-cases.

If you fast forward a few years you can imagine lots of permissioned chains with each organisation belonging to many.

Therefore the potential long term downside of permissioned chains is that logic and data ends up in multiple, partially overlapping silos.

Anyway, the focus of this article is not permissioned chains, rather it is the public, un-permissioned Ethereum network that is of interest: the Ethereum mainnet.

It is public, because anyone, including you, can run a node in the mainnet. All you need is some commodity hardware, some Ethereum software and an internet connection.

In fact something around 7,000 nodes are operating on mainnet at any one time, each dutifully validating every transaction. This is worth emphasising: every node executes the same transactions. This is not distributed processing with the goal of increasing throughput.

This is distributed processing with the goal of ensuring the network can be trusted. It would require over half of these nodes to collude to start successfully tampering with data. This is the strength of such a large distributed system.

You don’t need to run a node yourself to use mainnet. You can send transactions to any node you have rights to and the transaction will get processed.

A popular option is to use an Infura node, but bear in mind you’re then placing trust in Infura to operate their nodes fairly.

The mainnet can be thought of as some always-on cloud infrastructure that you don’t have to pay for up front.

A small fee is incurred per transaction which gets paid to node operators, typically a few USD cents but for transactions that use more compute and storage this can run to several USD. The fee is paid in the network’s own internal currency called Ether.

You can imagine mainnet as a global, single-instance computing environment, controlled by no central authority, where simple programs can execute and store small amounts of data without risk of interference or corruption.

Take this idea further and imagine lots of enterprises connected to mainnet. You can imagine mainnet acting like a single, global, enterprise service bus. In this context, mainnet is sometimes called the “magic bus”.

Demo Time

Now you will see how easy it is to connect an ABAP-based system to mainnet.

The demo scenario imagines using a smart contract on mainnet that matches buyers and sellers of raw materials. Imagine a SAP ECC system needs to procure some cobalt for manufacturing processes. An ABAP program sends a buy offer to a web service saying you would like to buy 1000 kilos of cobalt for 30 USD per kilo.

Sellers of cobalt could post similar sell-side transactions to the smart contract saying they want to sell cobalt for a specified price. When a match is made, the buyer and seller can obtain details of their counterparty, and the rest of the business process can happen as usual.

Doing this in smart contracts on mainnet means that no central party needs to be in control of the process, and no central party needs to have the power to shut the smart contract down.

The smart contracts can be deployed and left to run autonomously. This differs from a centralised web portal-based solution, where some organisation builds and runs the marketplace and can shut it down whenever it wants.

In practice, of course some ability to upgrade smart contract code and fix bugs is desirable. There are decentralised governance options to manage this which are beyond the scope of this article. The point remains that no single party needs to be in control.

The components shown in the above diagram are as follows:

SAP ECC Program

This simple ABAP report acts as the UI for the process. The report title you choose will act as the unique identifier for your system in the smart contract, you will see this shortly when running the demo.

This report does not know anything about Ethereum or smart contracts, it just interacts with a web API.

To install: copy the report source code from the main GitHub repo into a new ABAP report and activate it.

Web API

This simple API allows you to create new buy offers and list existing buy offers and see their status. The API is written using .NET Core and so is very portable, it is trivial to install it on Linux or Windows servers.

The source code is available in the main GitHub repo, see project SapEthereumIntegration.Api.csproj under solution SapEthereumIntegration.sln. There is a Postman collection for experimenting with the API.

Internally the API connects to an Infura node using the excellent Nethereum library (which has a very friendly team). The API knows all the configuration necessary to connect to Ethereum, the details of the smart contract to call and some test Ether to pay the fees for new transactions posted.

To install: This API is already installed on Azure and is freely usable without installing anything. To see it working, put https://sapethapiver01.azurewebsites.net/api/market into your browser to see a list of all current buy offers.

Smart Contract

The smart contract is written in Solidity, a scripting language for writing the business logic and storage parts of our process. The contract accepts new buy offers, validates them, and matches them with a seller.

For the purposes of the demo, all offers are instantly matched with a seller.

There is a popular Ethereum data browser called Etherscan that allows you to examine contracts and transactions. The contract source code is visible on Etherscan as well as in the main GitHub repo.

To install: The contract is already installed on a mainnet-like test Ethereum network called Rinkeby and is usable without installing anything.

Demo Execution

Run the ABAP you installed earlier and on the Display Offers tab, click the Display Offers button:

The list of current buy offers is shown, retrieved from smart contract storage. The System Id shown above comes from your ABAP report description, and is intended to be a unique-ish identifier for your data held in the smart contract.

Tick the checkbox “Show All System Ids” to see buy orders for every user of the smart contract.

Now you can create a new buy offer. Click the “Create Buy Offer” tab:

Enter a raw material free text, a quantity in kilos and a price. Press “Create Buy Offer” and a new transaction is sent to the smart contract. After 10 to 15 seconds whilst the Ethereum network processes this new transaction, you should see a message at the bottom saying “Buy Offer created”.

If you return to the “Display Offers” tab and refresh, you will see your new order has been placed, and matched with the seller with email cob@lt. Ethercan will also show the new transaction, albeit the information it shows is a bit cryptic. Congratulations, you’ve just interacted with the Ethereum mainnet from ABAP. Easy peasy!

Before you implement anything productive relating to mainnet, you need to understand the final section: privacy.

Mainnet Use-Cases and Privacy

Mainnet has lots of potential overlap with the permissioned chain use-cases, but without the side effect of generating silos. The limitation of mainnet in this context is privacy.

Mainnet is public by design. All the smart contract code is public. All the related data it stores is public. All transactions are public. You get the idea, and this doesn’t often suit enterprises. In the demo example above, you likely don’t want anyone to know what deal you got on cobalt.

Encryption is an option. If you trust your encryption enough to make the encrypted data public to the internet forever then this might be viable. This may suit some use cases, but it is clearly not perfect.

Another option is to not store sensitive information on mainnet at all. Instead it is possible to store evidence that sensitive information is known, and not the sensitive information itself.

Whilst this may sound like Gandalf the Wizard has started running IT projects, it is possible using technology called Zero Knowledge Proofs (ZKP). The principle behind ZKPs is that, if I know a secret, I can convince someone else that I know the secret, without revealing anything at all about the secret itself.

There is an open source project that seeks to allow enterprises to collaborate over mainnet without revealing sensitive information. It is called the Baseline Protocol.

Founding members include Microsoft, AMD and Ernst & Young (who are behind the Nightfall project also working with ZKP). The baseline protocol is a specification and an open source reference implementation. The project community is friendly.

Conclusion

You’ve seen how easy it is to connect to Ethereum mainnet, and should have a better idea of what it is.

This example used .NET Core as the middle layer between SAP and Ethereum, but many languages could be used. For example, to connect to Ethereum from a SAPUI5-based UI, you could use the web3.js library.

To continue learning about Ethereum and mainnet, Ethereum.org has a dedicated section on enterprise usage.

Previously published at https://blogs.sap.com/2020/08/21/sap-integration-with-ethereum-mainnet/