One option to do that is to declare the contract ABI on the beginning of the contract file, but just the parts required by your contract.
In our case it means:To point to the correct contract, we just need to pass the contract address when instantiating it, like this:pm = ProductManagement(prod_contract_add);Proceeding on the “ChangeOwnership” code review, we can also see that we define two events, TransferPartOwnership and TransferProductOwnership.
Events can be logged with transactions, so that will the core of our “tracking” functionality.
Whenever a part or product is successfully transferred to another account, we will emit an event.
Take the addOwnership function as an example: we verify that the item exists, check if it is still unregistered and that the manufacturer is the one asking ownership.
If we verify all that, we then store the manufacturer as the part owner and record that on Ethereum as an event.
Later, we can query events about that part from its hash and see all the transfers.
The only other point to note about this code is on the function “changeOwnership”: whenever a car changes the owner we also change the ownership of the parts that compose it.
But enough about code review, let’s check how to deploy it.
Contract DeploymentTo migrate our contracts to Ethereum we need to create a simple deployment file on the “deployments” folder.
We can base ourselves on the “1_initial_migration.
js” file created by Truffle, so our code becomes:We can finally deploy our code to our local Ethereum network by running:truffle migrate -network developmentWhen running that you will probably note that the ganache-cli terminal outputs a lot of messages, including some like:Transaction: 0x9fe6d2ece9cdca2f12b574ead7abb7bea7feab316f5cd6ebbd5b713e76850a1dContract created: 0xb6a3c3cf9d1e27e43e5fb12e505d79764748edbeThose represent our contract addresses, so save them to be able to communicate later.
We will need this address on our web interface!Web interface Hands OnOur system now has both smart contracts ready and all we need is the interface to use them.
We made a page for each role on our scenario, so we have a “Part Factory View”, a “Car Factory View” and a “Dealer View”.
We won’t get into the specifics of the methods implemented for the interactions, but let’s give an overview to instigate you to check the code!The part factory interactions, like part registration, ownership addition and ownership transfer, can be performed on the interface shown below.
It is interesting to note Metamask asking for permission for every single transaction we make.
Part Manufacturing InterfaceLooking at things from a car manufacturer’s perspective, we have the part list populated from the records on the blockchain, then the part selection to assemble the car, the car build, and finally we transfer the ownership to a dealer.
Just like a part factory, the car factory also has its own interface, shown below.
All interactions with Ethereum use the part/car hash created from their properties.
Car Manufacturing InterfaceThe final view is from dealers, and for our example that is the simplest: we can just check the cars and parts for the owner history.
Check the image below for details:Dealer View with Owner History for Cars and PartsUnder the hood, we use the web3 library to call our smart contracts’ methods.
The library provides us with objects representing our contracts and methods, and for that we only need to set:Network locationContract ABI (smart contract definition)Contract addressWallet to use for operationsBy default, ganache-cli runs the network on the 8545 port and the ABI is generated every time you compile and deploy your contracts (but only when we update the code, so we don’t need to change that).
If you ever need to, get the value stored on the “build” folder of the setup.
The contract address we must specify with the values saved before, so change the following lines to your values:Now that we have our page ready to interact with our smart contracts, we just need to prepare the functions that use the objects provided by web3 and our system is complete!The functions basically get the data from the input fields on the page and then call the functions with them as parameters.
The complete code is too big to fit this article, but let’s check just two parts that explain most of the interactions with the blockchain.
The first is:The “window.
co” object is our “ChangeOwnership” contract, and both currentPartOwner and addOwnership are methods provided by it.
The difference here is on the function used to call them: call vs send.
Web3 1.
0 requires you to specify the type of interaction that you want to do with the blockchain: reads or transactions.
So whenever you use a method with “call” you are just reading data from the blockchain, it costs you no ether and also does not change the chain state.
On the other hand, if you use “send” you have to send gas to perform the operation and it creates a transaction.
As we have said before, transactions are not mined immediately, so take that into account when developing real world Dapps.
Finally, the second part to be highlighted is:Remember when we said that Events would be our supply chain core?.This line is used to get all events from a specific type, filtering the results by the part hash.
It means that we can get everything that happened with a single part, and if we want we can also get the part details using the same hash and calling “parts” from “ProductManagement”.
Pretty cool, huh?Wrapping UpAnd we’re done!Every time a part manufacturer wants to notify a new part production, a car manufacturer wants to assemble that in a car, or we want to move the parts and cars from one owner to another, we can simply use the web interface to do it.
We have a transparent record that allows manufacturers, dealers and buyers to have the same information about the products.
If a problem is found about a certain serial number range in the factories, the factory can check where to tackle and solve the problem.
The same is true in the opposite direction: dealers and buyers can trace back their products’ parts to the factories in case they have problems or need replacements.
Implementing the system based on a blockchain also provides a distributed and consistent record that none of the participants can alter without traces, so we avoid foul play.
We have simplified the supply chain scenario a lot, but we hope that this demo has shown the power of using the blockchain in this context.
Now you can start your solution planning and consider it as an implementation alternative.
I hope you enjoyed it!.