Skip to Content
Technical Articles

SAP Integration with Ethereum Mainnet

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 which 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:


The Ethereum Network

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.


Demo Architecture Overview

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.


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 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:


ABAP Displays Buy Offers

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:


ABAP Creates New Offer

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.


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, has a dedicated section on enterprise usage.

Versions of this blog are also published on Medium and LinkedIn.

You must be Logged on to comment or reply to a post.
  • Is great to the new step SAP to blockchain, now about the blog on ethereum and smartcontracts I have three question:

    1.- I've read the points, and the transactions to create smart Contract, what will be the crypto cost to make it?,

    2.- The cost will depend on way to send transactions to network blockchain, kind of node offchain to after launch packet of smartContracts?.

    3.- What will be the way to execute if the smart contract has not been accomplished?, or just will necesary to wait up to SC have been expired?

    Thanks ...

    • Hi Ramses,

      1. If above were live on mainnet, the transaction cost would be small, a few cents or so, although if mainnet is congested the cost rises. Costs are being addressed with Ethereum 2.0 so in general it should not be a concern.
      2. Yes there are techniques to minimise cost, by doing things like batching up transactions.
      3. If a transaction fails, it rolls back, and the cost incurred remains spent. This happens every 15 seconds or so, not long to wait.
  • Hi Kevin,

    Thanks for your wonderful blog.

    We tried the Demo and created a new Buy Offer from our SAP system. We recieved the success message and the Buy offer is created. But, we are unable to find our transaction in

    Are we missing any step to see our transaction in the above Url.

    Thanks & Regards,

    Nagalakshmi Katuri

      • In fact, here is the direct link, listing all transactions against the smart contract from the demo;


        • Hi Kevin,

          I have some questions about example was executed:

          1.- Executing the ABI, is there any way to check on SAP the number of transactions?, I mean follow the example @Nagalakshmi ran.


          2.- If you run SmartContract using rinkeby testnet, where can I check my Public key associated to SmartContract example?.


          3.- Is there per Platform or User SAP differents private and public key?, I' m asking you that that'cos will necesary to have ETH on any wallet ...




          • Hi Ramses,

            1.- Is there any way to check on SAP the number of transactions?

            Yes there is. See in the above article there is a screenshot labelled "ABAP Displays Buy Offers". If you go to that screen and tick the checkbox saying "Show all System Ids" you will see all data, including Nagalakshmi's data.

            2.- If you run SmartContract using rinkeby testnet, where can I check my Public key associated to SmartContract example?

            I am not sure what you mean here, can you explain more? Do you mean what is the address of the SmartContract?

            3.- Is there per Platform or User SAP differents private and public key?, I’ m asking you that that’cos will necesary to have ETH on any wallet …

            A great question! Since ownership of a private key also gives ownership to all its Ether, these keys really do not belong in SAP. In the above article, the private key of the account that is sending the transaction is hidden in the Azure service. See the diagram above with the label "Demo Architecture Overview", you can see the Web API box also manages the keys. There are many ways to manage keys, including something called Gas Station Network where the sender does not have to spend any Ether at all, and newer services (including some coming from Microsoft I have heard) that will let Ether be centrally managed by an enterprise's treasury.