Page 38 - MSDN Magazine, March 2019

Send Message Service Bus Message Picked Figure 5 Sending a Message to a Smart Contract
I define these parameters as variables in the Logic App flow, by using the Initialize variable action from the Variables connector. The requestId variable can be set to guid, which is an expression that generates a unique GUID. The processedDateTime variable can be set to utcNow, which represents the current coordinated universal time. For userChainIdentifier, you can enter the address of a user in Blockchain Workbench that’s authorized to run the smart contract, whereas applicationName and workflowName are defined as per name and workflow of the smart contract that processes this transaction.
The next section describes the smart contract for processing these messages sent by the Logic App flow. Figure 6 summarizes the message body, in JSON format, to send to Service Bus. The expressions in <acute angle brackets> have to be replaced with the corresponding value.
Smart Contract for Processing Digital Assets
First of all, let me reinforce the message that digital assets aren’t stored on the blockchain. Hash values of the file metadata and content are. In this article, I describe the storage of documents on SharePoint, which is a centralized service. In a “pure” blockchain deployment, you may want to obtain decentralization also of the storage service. The Interplanetary File System (IPFS) is a peer-to-peer hypermedia protocol (which I mentioned earlier) that provides decentralized file storage. Integration with IPFS is beyond the scope of this article, but if you’re interested in knowing how this technology can help remove centralization of storage that isn’t part of a block in a blockchain, you can refer to the “IPFS in Azure” video on Channel 9 (bit.ly/2CURRq0).
As I’m using Azure Blockchain Workbench for running my smart contract, I need two files:
• FileContract.sol to describe the smart contract itself, in Solidity programming language.
• FileContract.json to configure the workflow that’s loaded in Azure Blockchain Workbench as an application.
The FileContract smart contract describes a file through its meta- data, based on the values passed in the message sent by Logic App to Blockchain Workbench via Azure Service Bus. Here’s a snippet of the source code of the smart contract that defines these parameters:
contract FileContract {
// File metadata
string public FileId; // File identifier
string public Location; // File path
string public FileHash; // File content hash
string public FileMetadataHash; // File Metadata Hash string public ContentType; // File content type string public Etag; // File entity tag
string public ProcessedDateTime; // Timestamp address public User; // User address
To store the file metadata on a blockchain, I need a file struc- ture defined, as follows:
struct File {
string FileId;
address FileContractAddress;
}
Generate Transaction
A file entity is identified by its file ID and the address on block- chain of the FileContract smart contract that contains the meta- data. This structure is saved in a private collection defined as a dic-
Logic App Action
Blockchain Workbench
tionary, whose key is the FileId string. The mapping keyword in Solidity defines a dictionary and its key and value types as follows:
mapping(string => File) private Registry;
To save a file entity (its ID and metadata), I simply add the con- stituent values to the Registry dictionary in the Save method. For simplicity, I’ve omitted any necessary control on validity of file ID and contract address, and whether the file already exists in the registry. Here’s the code:
function Save(string fileId, address fileContractAddress) public {
Registry[fileId].FileId = fileId;
Registry[fileId].FileContractAddress = fileContractAddress; }
The Verification Process
Users who need to verify their certificates with a third party do so by sharing the authenticity token (that is, the file contract address), which contains all the necessary information to verify that the document exists and is authentic and not counterfeited. Figure 7 describes the parties and actions involved in the verification
Figure 6 Structure of the Message Sent to Azure Service Bus
{
"requestId": "<The requestId variable>",
"userChainIdentifier": "<User address in Azure Blockchain Workbench>", "applicationName": "<Smart contract name>",
"workflowName": "<Smart contract workflow name>",
"parameters": [
{
"name": "registryAddress",
"value": "<Contract address in Azure Blockchain Workbench>"
}, {
"name": "fileId",
"value": "<File identifier>" },
{
"name": "location", "value": "<File path>"
}, {
"name": "fileHash",
"value": "<File content hash>" },
{
"name": "fileMetadataHash", "value": "<File metadata hash>"
}, {
"name": "contentType",
"value": "<File content type>" },
{
"name": "etag",
"value": <File entity tag>
}, {
"name": "processedDateTime",
"value": "<The processedDateTime variable>" }
],
"connectionId": 1, "messageSchemaVersion": "1.0.0", "messageName": "CreateContractRequest"
}
32 msdn magazine
Blockchain