4.4.1. Chaincode (Smart Contract) Development

In the Hyperledger Fabric network, the Chaincode can be written in one of the following programming languages: *Go, Java, TypeScript*, or *JavaScript* [92]. For this prototype, the *JavaScript* programming language was used to write the Chaincode (smart contract) to support the development of the system prototype for API applications. The Chaincode requires supply chain stakeholders to submit transactions using the invoke application to provide on-chain data. The query application assures the supply chain element's transaction history (amendment and revision) by using the Chaincode or smart contract. As illustrated in Figure 5, for the process sequence of a successful transaction, the query application return values provide ready access to the record of on-chain data delivery transactions. Given this, the primary methods used in the proposed Chaincode were defined below.

*initLedgedr(ctx):* The constraint *ctx* is a set of *ChaincodeStub* structures in JSON format. This function initializes on-chain data delivery based on the provided data model attributes (or the proposed business logic) in JSON format, and stringifies and stores all those data into *ctx* using <async> *putState* (key, value) [87]. Thus, to submit the on-chain CSC data transaction, *invokeProcess (ctx, myArgs[0]* **...** *. myArgs[20])* includes all the arguments (the data attributes of the business logic for the smart contract) that need to be entered by the CSC stakeholder passing through the Node.js console application. Suppose an argument (attribute) has been missed, or its value has been wrongly entered. In this case, the Node.js console application will display this message as a *console error* (*failed to submit transaction*). However, if it is run successfully, the Node.js console application will display this message as a *console log* (*transaction has been submitted*), as illustrated in Figure 6.


**Figure 6.** We invoked the application's arguments, as shown in the Git console.

*queryID (ctx, myArgs):* This method calls the return values for on-chain CSC data delivery attributes linked to a specific *invokeProcess* (submitted transaction) with the value of *myArgs* (a specific attribute) [75,87]. All values with that *queryValue* will be returned in stringified JSON format by calling <*async*> *putState*(key, value). To run this method, the *queryID* application needs to be passed through the Node.js console application. The return values are displayed on the Git console, as illustrated in Figure 7.

**Figure 7.** We successfully ran the queryID application and the return values for a specific argument, as shown in the Git console.

*queryAll (ctx)*: In this method, all values (all on-chain CSC data delivery for a project) inside this blockchain will be returned after calling this method. To run this method, the *queryAll* application needs to pass through the Node.js console application. Once a block is created after running the *invokeProcess* application, it cannot be modified. However, a block can have more than one transaction, and tracking its history of transactions can be detailed after running the *queryAll* application.

The prototype API supports two methods. The first method, GET, returns values for CSC data delivery (return values of query application). The second method, POST, provides access to add a new record to the ledger. The supply chain element's transaction history may be shown using the GET method again (amendment and revision). To connect the API server node to Revit Dynamo (the next step, Section 4.4.2.), a web server solution was implemented. To enable access from the Internet to the machine, a reverse proxy, Ngrok, was used.

Then, the URL link generated by the reverse proxy was used to access the server. The operation ran successfully and the result was the HTTP request–response from other machines. At this level, the system prototype was dealing only with the blockchain platform and exposing a web server on the local machine to the internet for its return values of query

applications. Given the physical system architecture, as explained in Section 4.4.2., the following sub-section demonstrates how the reverse proxy was linked to Revit DynaWeb to access the transaction (return values of query application) by the BIM user (external entity sink).
