This guest blog post is by Ben Chevallereau (@benchevallereau), a Senior Architect at Certara. Prior to joining Certara, Ben spent a decade in IT working for large organisations in the U.K., France and the United States. For the last 2 years he has been working with blockchain, hashgraph, and decentralized applications.

At Certara we’re focused on improving communication in healthcare. My team is working on the OpenPharma initiative, an industry first Open API software platform for pharma and life sciences. As part of this effort, we view distributed ledgers like Hedera and blockchain as a way to improve the transparency and efficiency of healthcare communication.

I first stumbled across hashgraph over a year ago while working at the Centers for Disease Control and Prevention (CDC). At the time, my job was to design an application for editing excel documents online; the goal being to replicate the capabilities of Google Docs on top of hashgraph. I was impressed by the simplicity of integration and the speed of consensus. Soon after, Hedera was announced and took my sole focus. Hedera brought me a higher level of integration of hashgraph and support for Solidity smart contracts (which I was anxiously awaiting).

Moving to Certara, and looking to leverage Hedera for OpenPharma, we knew new technologies like blockchain and Hedera can appear complicated to a developer with little knowledge of the system. As such, we need a way to easily expose Hedera to developers without complexity.

To do so, we looked to follow the same architecture design principles we have successfully used: dockerized microservices. The idea being to expose RESTful APIs to our team of UI developers by embedding the Hedera Java SDK.

This new internal microservice was easy to use for simple transactions, like querying an account balance. However, it became quite complicated when we started to use it for smart contracts. Asking our UI developers to write application binary interface (ABI) code was too long of a process. Instead, we decided to create a dedicated microservice for each of our applications. The goal being to hide the complexity of the smart contract, by assigning the responsibility of specifying the ABI call to the developer who created the smart contract itself.

By following Hedera’s API structure, our generic microservice is divided into three controllers:

• Accounts Controller: To get account information or balance, to create a new account, to transfer HBAR cryptocurrency between accounts or to get records.
• Files Controller: To create, append or update files in the Hedera network, to get information or download stored files or to delete files.
• Contracts Controller: To create a Solidity contract, to get contract information or to call (remotely or locally) a smart contract.

As explained above, we then packaged our microservice as a Docker container. What followed was discussion on how to handle authenticating to Hedera. Providing public and private keys at each call is not safe – so we decided to use environment variables to allow for three different scenarios:

• Nothing required: The microservice is not aware of anything (Hedera network or paying account information) and this information needs to be provided at each call.
• Network required: The microservice is aware only of the basic information such as the Hedera network but for each action public/private keys are required to sign transactions.
• Network and accounts required: The microservice contains all details, the Hedera Network and paying account to sign transactions.

Each option should enable us to cover different use cases, but let’s keep in mind that the goal of this microservice is not to be exposed publicly over the internet but used internally by other microservices.

A lot of decentralized applications are generating new wallets for their users and it’s what we do at Certara, as well. The main reason is that the learning curve is too high for most of our users to understand not only the concepts of blockchain and a wallet, but also understand how they work together.

Micro Service REST API for Hedera

If you’d like to try out our microservice yourself, we’ve open sourced it and provided a Docker Hub image, which I run through in this video:

Once you’ve downloaded the image from Docker Hub, to create your Docker container, you can execute the following command:

docker run -d \
-p 8000:8000 \
--name=op_hedera_main \ -e SERVER_PORT=8000 \ -e HEDERA_NODE_ADDRESS=testnet.hedera.com \
-e HEDERA_NODE_PORT=50130 \
-e HEDERA_NODE_ACCOUNT_SHARD=0 \
-e HEDERA_NODE_ACCOUNT_REALM=0 \
-e HEDERA_NODE_ACCOUNT_NUM=3 \
-e HEDERA_PAYING_ACCOUNT_SHARD=0 \
-e HEDERA_PAYING_ACCOUNT_REALM=0 \
-e HEDERA_PAYING_ACCOUNT_NUM=xxx \ -e HEDERA_PAYING_ACCOUNT_PUBLIC_KEY=xxx \
-e HEDERA_PAYING_ACCOUNT_PRIVATE_KEY=xxx \ openpharma/op-java-ms-hedera

When the Docker container is started, you can access to:

• http://localhost:8000/ to access a simple documentation page;
• http://localhost:8000/swagger-ui.html to access a Swagger interactive documentation.

Then, you can check your balance, or anyone else’s other balance on this test net. You can use Swagger UI for that:

I hope that you’ll found this Docker container useful. Don’t hesitate to contact me if you have any questions.

This microservice is part of the OpenPharma initiative. OpenPharma is an industry first Open API software platform for pharma and life sciences. OpenPharma’s APIs are built for versatility. API Endpoints include: proprietary format conversion, dataset anonymization, risk scorecards, and more.