There were a few months where we really struggled to design our applications for the Hyperledger Fabric protocol. We found difficulty scripting transactional state changes though we managed to create the infrastructure layer using a Linux VM and docker containers for the different network nodes. We thought now we have this network running; we can begin to build out different vertical applications. However, we didn’t realize we were to low level into the protocol layer when designing the UX for Salesforce users. There needed to be an abstraction level, we needed to understand and stand up the infrastructure; but ultimately the application development layer was we wanted to build upon.
Hyperledger Fabric is a distributed consensus transactional state machine. It is robust, modular blockchain infrastructure. It is a peer-to-peer permissioned transactional database; it takes an ordered series of messages that are deemed valid and invalid and distributes state changes to the nodes on the network. The Hyperledger Infrastructure runs in a Virtual Machine that is operated by Dapps.ai. We have the latest fabric v1.0 docker images running in a private virtual machine with 16GB of Memory. We use a C3 Large on AWS equivalent on Azure or IBM. Hyperledger Business Networks can be thought of as two layers; the application layer and the infrastructure layer. The application layer tool set we leveraged:
How can we build a product that completely integrates the Hyperledger Fabric blockchain data and the Salesforce data using a multitenant node server and ordering service in a VM? It will be an entire new ecosystem based on event driven applications and the infrastructure will be run by users of the many different technology stacks.
Hyperledger Fabric and Composer enables enterprise to build applications that are permissioned and scalable. Dapps.ai enables companies that run their business on the Salesforce platform to leverage this blockchain infrastructure, abstraction layer; and combine it with their existing customer data, event driven workflows, and other third party applications.
Again, the goal is to build an object model to persist the data and an interface that enables Salesforce Customers to quickly build and deploy Business Networks that are tightly integrated with their existing customer data, third party applications and other proprietary business processes. When deploying state changes to the network these changes are updated across every peers state. The data is also persisted in Salesforce as well in the Dapps.ai objects.
Salesforce Event Driven Architecture
The discovery we made was that by building the application layer on the Salesforce platform, we could leverage the event driven architecture that Salesforce and Hyperledger Fabric blockchain share.
Hyperledger Fabric Composer Network Events and the Salesforce Enterprise Messaging Platform Event is a powerful combination for creating distributed applications networks.
We can now connect the Fabric distributed ledger to various business processes in the Salesforce platform. Ideally we can build a type of Asset transformation in that we take the asset as it stands today, a record in a database, simply allowing a system to see which as assets are owned by which accounts; and we can now unlock/transfer/control/distribute/return/upgrade/provision the asset. By enabling an asset to be digitized and used on a Business Network the state changes that happen for the asset on the ledger are propagated to other participants on the network and to the Salesforce platform using the event system.
We are simply building out Enterprise Transaction Networks to digitally transfer value assets.
We have a fault tolerant consensus driven transaction ledger that multiple parties can operate on. We want companies to be able to use their existing customer and machine data when leveraging these networks. We want it to create a business graph. Similar to google but specifically between parties that are all operating against the same data. We want to create a permissioned business transactional system that enables companies to model and integrated business applications. The state updates that are made on the network need to be reflected in Salesforce as well, this is where users are. The users don’t need to know about the infrastructure level. They care about assets, they care about the participants in the network that are now in a market.
Blockchains turn networks into markets
There is a distributed consensus to all of this. A distributed state machine ledger that can be used in conjunction with existing customer data in addition to other third party applications. How do we connect and update state from salesforce to a Hyperledger network? How do we ensure that all of the parties that are using the network have the same data? How can we ensure that the assets being exchanged the global state of the assets have been agreed upon?
We need an asynchronous event system.
We need to create Platform Events that are subscribed to state changes at the emit event transactional level of the Fabric Composer REST service.
The Hyperledger Blockchain Application Management Suite addresses these questions: We are developing an application suite that enables a developer to model and create assets, participants and script logic leveraging Fabric Composer. The application development process is built into the Salesforce Lightning Experience. Testing and deploying these types of assets on the ledger (therefore emitting events) are also then created in corresponding objects in the Dapps.ai managed package. Any state changes (CRUD) that happen are registered as Business Network Events and these events can be used in other business processes and applications.
Event Processing and Distributed Event Systems.
Salesforce provides the platform event that we can link to the blockchain network. We call these Business Network Events and the object is Business_Network_Event__e. We use this type of object as a asynchronous messaging system from the blockchain network to Salesforce clients. This becomes a message broker and it comes with many advantages when distributing state or network status update. One message from the network can be sent to several recipients because it logically decouples the sender from the recipient (the send just published messages and doesn’t care who consumes them). This message broker can automatically delivered messages to a process that has crashed as well and thus prevent messages from being lost is a recipient is unavailable or overloaded.
This essentially means that the various participants in the business network can listen to the same event and carry out actions knowing that endorse and verifies by the peers in the network. This is different then Ethereum which takes a distributed actor framework approach.
The advantage to having a Business Network event driven architecture is that multiple participants that are on the network can subscribe from various clients and receive asynchronous messages with regards to the current state of the permissioned and trusted transaction network.
How could I better serve my customers if there was a tangible layer of cryptographic trust we operated on? What types of value added services can I bring to my customers with this technology? What if this cryptographic trust transaction layer existed across all of my lines of business?
We can then subscribe to these notifications inside of Salesforce and use the Platform Events Framework as an asynchronous processing system that can leverage distributed verifiable committed transactions and state changes from the shared ledger. Salesforce is the platform and Dapps.ai is the application provider of trusted, distributed application specific networks.
The model the we will create is working with companies to define a minimum viable network. Node.js applications can subscribe to events from a business network by using the composer client. BusinessNetworkConnection.on API call. Events are defined in the business network model file and are emitted by specified transactions in the transaction processor function file.
Before an application can subscribe to events, you must have defined some events and the transactions which will emit them. Salesforce is the subscriber. Fabric-Composer is Publisher; to the Event Bus where Salesforce gets pinged. The application will now receive all of the events emitted by the business network, and it’s up to the application to choose to what extent those events are integrated.
We can then write after insert triggers or business processes on the Salesforce Platform that listen for events that are being published by Hyperledger. By connecting these two event systems we can enable companies to quickly develop applications that are powered by the Salesforce platform and directly integrated with a distributed blockchain network.