Page 40 - MSDN Magazine, September 2018

delivers messages to an Azure Service Bus endpoint, as well. You can raise events, for example, to notify users and systems of trans- actions or changes of state in a smart contract. Event notifications can be consumed directly in code or used with tools such as Logic Apps (bit.ly/2n4EgoP) to trigger flow of data to downstream systems.
Smart contracts often represent a business workflow that integrates with external systems and devices. As a result, transactions must be able to initiate on a distributed ledger that includes data from an external systemordevice.Youmayalsowanttohaveexternalsystemsreactto events originating from smart contracts on a distributed ledger. The REST API and messaging integration provide the ability to both send transactions from external systems to smart contracts included in an Azure Blockchain Workbench application, and send event notifica- tions to external systems based on changes that take place within an application. Let’s explore now the patterns identified for each of these types of integrations in your end-to-end solutions:
• One-way event delivery from a smart contract to an event consumer.
• One-way event delivery of a message from an external system to a smart contract.
Smart Contract to an Event Consumer
In the first scenario, an event occurs within a smart contract; for example, a state change or the execution of a specific type of trans- action. This event is broadcast via an Event Grid to downstream consumers, and those consumers then take appropriate actions. An example of this scenario is that when a transaction occurs, a consumer would be alerted and could take action, such as record- ing the information in a database. This is the same pattern that Azure Blockchain Workbench follows to populate its off-chain SQL database. Another would be if a smart contract transitions to a particular state; for example, when a contract goes into an “Out of Compliance” state. When this state change happens, it could trigger an alert to be sent to an administrator. This occurs using the process depicted in Figure 8, where:
1. The smart contract transitions to a new state and sends an event to the ledger.
2. The ledger receives and delivers the event to Azure Blockchain Workbench.
3. Azure Blockchain Workbench is subscribed to events from the ledger and receives the event.
4. Azure Blockchain Workbench publishes the event to subscribers on the Event Grid.
5. External systems are subscribed to the Event Grid, consume the message and take the appropriate action.
External System to a Smart Contract
There’s also a scenario that flows from the opposite direction. In this case, an event is generated by a sensor or an external system and the data from that event should be sent to a smart contract. A common example is the delivery of data from financial markets, such as prices of commodities, stocks or bonds, to a smart con- tract. This occurs using the process depicted in Figure 9, where:
1. An event occurs in an external system that triggers the cre- ation of a message for Azure Blockchain Workbench.
2. The external system has code written to create this message in a known format and sends this directly to the Service Bus. 3. Azure Blockchain Workbench is subscribed to events from
the Service Bus and retrieves the message.
4. Azure Blockchain Workbench initiates a call to the ledger,
sending data from the external system to a specific contract. 5. Upon receipt of the message, the contract transitions to a
possible new state.
The implementation of an end-to-end solution for either integra-
tion scenario is beyond the scope of this article. Good examples of integration in both directions can be found at bit.ly/2M8yflL.
In summary, similar integration patterns can be found in micro- service architectures and blockchain smart contracts. The distributed nature of both architectures encourages asynchronous messaging and the use of a message broker, in the form of an event grid or service
State Change
Contract
Raise
Event
External System
Handled By
bus, for conveying information among services and smart contracts. Design patterns like event sourcing, ultimately, match the immutable nature of a digital ledger and the event-driven approach to off-chain communication. n
Stefano tempeSta is a Microsoft Regional Director and double MVP on AI and Business Applica- tions, as well as chapter leader for the Microsoft Dynamics 365 community in Switzerland. Tempesta is an instructor of courses about Dynamics 365, blockchain and machine learning, and a regular speaker at international IT confer- ences, including Microsoft Ignite and Tech Summit. He founded Blogchain Space (blogchain.space), a blog about blockchain technologies, writes for MSDN Magazine and MS Dynamics World, and publishes machine learning experiments on the Azure AI Gallery (gallery.azure.ai).
thankS to the following technical expert: Jonathan Waldman
Microservices
Figure 8 Propagation of an Event Raised in a Smart Contract to an External System Picked
Azure Blockchain Workbench
Publish By Event Grid
Consumed
Azure Blockchain Workbench
External System Send
Message
Service Bus By
State Change
(Possible)
Execute
Contract
Figure 9 Propagation of an Event Raised by an External System to a Smart Contract 32 msdn magazine