May 15, 2020
How to integrate ServiceNow and Ethereum
I recently built a demonstration for an “Employee Reward Token” made with ServiceNow instance(s) and the Ethereum blockchain. I took the opportunity to think a bit more broadly about an integration framework for ServiceNow and Ethereum, that could cover multiple use cases. In this post, I want to share the architecture of this demo and what it can teach us on a reference architecture of a full ServiceNow-Ethereum integration. Feedbacks and proposals are welcome.
First of all, please see the video here (~20 mins) and leave a few claps if you can 👏👏👏.
In the recording, I show the following flow involving two fictitious companies XY Quest and ZeroG. In the demo, both companies reside on the same instance (only for demo purpose). The Token Admin is assumed to be the same for both companies, just for simplicity.
The demo involves two applications:
- Wallet application allows managing the wallets across potentially multiple ServiceNow instances. This application shoukd be able to support all Ethereum based ServiceNow applications, besides fungible tokens.
- Fungible Token application allows managing the creation and the lifecycle of fungible tokens on the NOW Platform. In that application, we’re creating our Employee Reward Token called “NOW-Token.”
These are the main steps of the flow:
❶ Deployment of the token contract “NOW-Token” by the Token Admin (based on the OpenZeppelin ERC777 standard) and minting of the initial token supply of 10 million NOWs. Before this step, the XY Quest custodial company wallet is created.
❷ Token Admin, on behalf of XY Quest, send 1 million NOWs to ZeroG, an XY Quest business partner. Before this step, the ZeroG custodial company wallet is created.
❸ Token Admin, on behalf of XY Quest, executes a manual distribution of NOW Tokens to communities’ top contributors, including Lisa. Before that, Lisa custodial user wallet is created.
❹ Based on the configuration by Token Admin, ZeroG automatically distributes NOW Tokens to ZeroG employees to incentivize the response to the Employee Voice Survey, with 100 NOW Tokens. Before that, Joe creates its wallet from the Service Portal. Joe, who works at ZeroG answers the Employee Voice Survey and gets its reward. Joe wants to get his favorite gadget, the Chilly’s Water Bottle, but 200 NOW Tokens are required.
❺ Joe asks his friend Lisa, working for a business partner XY Quest, to lend him 100 NOW Tokens, to reach the required balance of 200 NOW Token. Lisa sends Joe 100 Tokens.
❻ Joe redeems 200 NOW Tokens for the Chilly’s water bottle on the XY Quest Partner Portal.
To implement this flow, I’ve built the integration, as depicted in the figure below.
I’m not running an Ethereum node for this demo. ServiceNow talks with a public Ethereum node provided by Infura (infura.io). Also, we’re using the Ropsten testnet, to avoid spending real ether to execute transactions on the mainnet. I funded all the involved wallets with free Ropsten’s ethers from a personal Ethereum account.
These are some key features implemented for this scenario:
- The MID server is the integration layer between the ServiceNow instance and the public Ethereum network. For the demo, MID server runs Digital Ocean public cloud on Ubuntu Linux 16.04.6 (LTS) x64 server;
- The MID server works as a wallet server. We’re creating deterministic wallets through the ethreumjs-wallet API with a predetermined password known only to the Token Admin.;
- The MID server also acts as a command server, from which commands are sent to the Infura Ethereum node through the Infura API and the nodejs web3 library. Web3 is the main library to interact with Ethereum over either Https or Websockets.
- The MID server critically requires nodejs to install the modules needed for the integration to work (web3 & ethereumjs). These libraries cannot work on the ServiceNow instance as of today.
- The transactions are created on the MID Server with the ethereumjs-tx, signed with the private key of the wallets and passed to the Infura node as raw transactions.
- A command can involve both reads from and writes to the public Ethereum network. Read commands are answered by the target node, while write commands require consensus between the target node and all the mining nodes of the network and as such they take at least one block time (10–15 seconds on the Ethereum network)
- The instance sends commands to the MID server through the ECC queue and expects back the response event, bringing the Ethereum receipts. This behavior is coded in the ECCCommand script include that you can see in this gist. This script is synchronous.
- The integration uses remote tables to visualize blockchain data, like balances or events raised by smart contracts. You can see the script for the users’ balances table here and for the token minting events table here.
- An integration with etherscan, a blockchain explorer, and a key component of the Ethereum ecosystem, has been realized.
The full target architecture involves a consortium of companies, all using the NOW Platform as the user experience/workflow layer and a single underlying Ethereum blockchain. The “Wallet” and the “Fungible Tokens” applications are installed on all the instances, and one organization within the consortium will act as minter for each Token. The ServiceNow instances, through the Wallet application, manage custodial wallets — in the sense that the private keys of these wallets are owned by the instances, through the Token Admin(s).
Through the Wallet application, wallets can be managed by companies (companies’ wallets) or by individual users within those companies (users’ wallets). Token Admins manage companies’ wallets on behalf of the organizations. The wallets can be local to the instance, or remote, meaning local to another instance. On top of that, non-custodial wallets are possible, that are owned by blockchain’s user accounts. Of course, a token on the public network can circulate across all these wallets.
The integration described here is still quite rough and scenario specific, but it contains many elements required for the development of a general purpose spoke.
Stay tuned for more on that!
