Blockchain applications are a hot topic at the moment and although the technology is in its infancy, more and more companies are investing resources into it.
Primarily organizations are asking themselves what role and value this emerging technology can play in their business. In this blog post, I'd like to demonstrate how a blockchain application can be effectively connected to, and automated with the CA Automic One Automation Platform.
Blockchain in a Nutshell
Figuratively speaking a blockchain can be viewed as an account ledger. Transactions (debits and credits) that take place are recorded on the ledger as data blocks. Blocks are appended each time a new transaction takes place, linking a former block with a new one, creating a chain-like structure - hence the term "blockchain". Debit and credit transactions that take place on the ledger are recorded and there is a clear chain of these transactions, making the entire process transparent. No individual, group or organization controls this ledger. Transactions are transparent and safe because each blockchain party holds a copy of the blockchain ledger.
Blockchain applications allow you to model the ownership and exchange of virtual assets in a business network. An asset could be for example, a virtual coin, a registration of a license plate, or a property. Compared to classical database applications, there is no single owner of the data nor a single application that works with the data. Every party in the network has its own copy of the data and can change it at will. A change is done in the form of a transaction; e.g. "Buy Property". These transactions trigger customer code that changes the state of the assets accordingly (e.g. sets a new owner). This is often referred to as "smart contract". Transactions are shared with all parties in the network, but in order for a transaction to become effective, they have to agree on its validity. There are different methods to do that, but in principal, multiple participants run the same code and if they all come to the same conclusion, the transaction will be accepted. The math around blockchain guarantees that once a transaction is accepted it cannot be changed anymore. The Middle-earth Hyperledger.
To demonstrate the integration with CA Automic One Automation Platform, we built a very simplified blockchain application using the Hyperledger Composer that gets executed on the Hyperledger Fabric platform. With Hyperledger Fabric you can build and operate your own blockchain networks, and it's features are specifically designed for business applications.
In the following sections we will demonstrate:
- How the blockchain application is modeled and how it processes transactions
- How we use CA Automic One Automation to listen for important transactions and trigger automation workflows
- How we use CA Automic One Automation to place transactions on the blockchain from within an automation workflow
The full application along with the integration to the CA Automic One Automation Platform is available on the CA Automation Marketplace.
The Blockchain Application
Our scenario is based on the fictional Middle-earth: The conflict between good and evil has been settled. Frodo destroyed the ring, the Elves are leaving to the West, and reconstruction work in Rivendell has just started. The lease market is hyperactive and various parties sell and buy property all over Middle-earth. To ensure transparency on who owns what, all nations have agreed to model real estate ownership via a blockchain application.
Figure 1 - Model of the Middle-earth application (property.cto)
Figure 1 shows how the network is modeled: We identify the asset Property by an id, a name, and a location. In addition, it also indicates if the property is for sale and the asking price. Each Property also has a reference to a user that indicates who owns it.
In a Hyperledger network, only registered parties can participate in the network. These are modeled as participants. In the model, we defined the participant User that gets identified via a unique id, a title, and name.
All changes to assets and participants are done via transactions: we modeled a Sell transaction pointing to the property that should be sold and the price the current owner asks for. There is also a Buy transaction that points to the property that should be purchased, identifying the new owner and the price offered. Finally, there is a setup transaction that puts some example data into the network. The Hyperledger fabric can automatically create a REST API for transactions so they can be executed very easily from other applications.
Whenever a property is for sale, the network will emit a propertyForSale event summarizing what can be purchased, for the seller price, and the name of the seller.
In the security configuration of the network (see permissions.acl in the source code), we can restrict who is allowed to place which transactions, so for example, only the property owners are allowed to list their property for sale.
All participants in the network run their own instance of the blockchain network, and place transactions on their local copy of the ledger. These transactions are processed by code, which changes the ledger accordingly. The Hyperledger platform ensures that changes are validated and synchronized between all participants.
Let's demonstrate this with a quick example:
Figure 2 - State of the network after three transactions
Step 1: The setup transaction gets executed. It will create the property Barad Dur and set its owner to the user Aragorn. Saruman is a second user in the network.
Step 2: Aragon puts Barad Dur for sale by executing the Sell transaction. The following JavaScript Code will be executed by both Aragorn and Saruman in their local instances of the Hyperledger application: It first updates the price and for the property of Barad Dur and then emits an event summarizing the sales intent. If the code execution by Saruman and Aragorn lead to the same changes in the ledger, they become effective for everyone.
Figure 3 - Code that executes on Sell transactions
Step 3: Saruman decides to purchase Barad Dur and issues a Buy transaction. As shown in the following code snipped, this first checks if the property is really for sale and if the price is higher than the than what was asked for. After that it assigns the property to the new owner, makes sure it is not for sale anymore and updates the price.
Figure 4 - Code that executes on Buy transactions
In summary, the middle-earth example application demonstrates how to model simple asset ownership and asset transfer in a Hyperledger Fabric blockchain application. The source code on the CA Automation Marketplace demonstrates the concept of queries, providing easy query capabilities of the ledger state.
Integration With CA Automic One Automation
Let's continue with our middle-earth scenario by introducing a new "No Property for Evil" party. They want to ensure that property does not fall back into the hands of Sauron's former allies. Originally, they asked to change the blockchain code of the application, but given that consensus is needed for code changes their request was ultimately turned down.
As alternative strategy, they put a number of people on a ledger watch: they would constantly query the ledger for properties that are for sale. If there is a property that is for sale in a region of formerly Sauron controlled land, they would check their own funds in their SAP application and buy the property if possible.
By leveraging the CA Automic One Automation event engine and their already existing SAP integrations, we are able to turn this manual process in a fully automated one:
Step 1: First we create an Event Definition object in CA Automic One Automation that matches the event that gets emitted by the Middle-earth Hyperledger application:
Figure 5 - Definition of the expected events (VARA.LEDGER.1)
Step 2: We specifically create an API key that will be used to ingest the event. We recommend you do this for every application that ingests events, so that the permissions can be easily revoked later on if required.
Figure 6 - curl command to create a new ape key
Step 3: For the actual event ingestion, we built a separate collector application that connects to the hyperledger application, listens to events, and forwards them to the event ingestion API.
Figure 7 - Listening for Events (PropertiesCollector/bizNetEventsListener.js)
Figure 7 shows how to subscribe to events from a Hyperledger network. The collector then calls the method listed in the snippet below. In order to ingest the event, it first maps the event structure coming from the Hyperledger to the event structure we defined in CA Automic One Automation Events.
Figure 8 - Sending Events to One Automation (PropertiesCollector/eventEngine.js)
Step 4: Once the plumbing is in place, we observe the incoming events via an Event Rule object as shown in Figure 9. The rule listens for all incoming transactions and only triggers if a property in Mordor with a price less than 1000000 is for sale. In this case we start the BUY.WORKFLOW workflow and pass to it the information from the event as promptset values.
Figure 9 - Listening to sales events
Step 5: The process that gets called is a standard One Automation workflow. We use it to automatically check the account balance. If the check is OK, we use a REST Job to execute a Buy transaction on the network as shown in Figure 10.
Figure 10 - REST Job Buy a property
Once the rule is activated, the "No Property for Evil" party can ensure with the help of the CA Automic One Automation Platform that Sauron's allies won't ever get the chance again to settle in Middle-earth.
Summary
The ecosystem to develop blockchain applications is a relatively new one. Developing on this ecosystem brings a lot of challenges. Only the right combination of O/S, Docker, JavaScript frameworks, automation, and Hyperledger Composer applications will make it successful. Putting the setup issues aside, developing an actual working blockchain application is relatively simple. However, given the nature of a blockchain application, once the code is put in place, fixing bugs becomes way more difficult. Therefore, we recommend a thorough design and quality process for real world applications.
Almost all blockchain applications in a business context will need to interact with 3rd party applications and LOB applications. The event system of the Hyperledger Fabric platform makes it very easy to integrate with the Event Engine in the CA Automic One Automation Platform 12.1. Leveraging this combination can greatly accelerate the development of real world use cases with blockchain networks.
We invite you to try it out and share your feedback and ideas with us!
