How to check EOS contract Responses

Hello, this is Kwon Dongjune of ITAM. Today, we’ll be taking a look at how to check responses of contracts on EOS.

Response check?

After calling forth a EOS contract, it’s possible to receive a response right away to see if the contract was applied correctly. By “response,” I don’t mean the results of the transactions that were executed on the contract.

First, let’s assume that a user purchases a random box item on the ITAM website.

1. The customer clicks the purchase random box button.
2. The customer checks the result value (item) of the random box.

If the above scenario were to take place on a centralized service, it’s quite simple.

1. Call forth /buy/random and show that result value to the customer.

If a EOS contract were to be used?

1. Call forth a random box purchase contract.
2. Show the results of the contract call to the customer(?)

Is this correct? As you may have guessed, no. The result value after a transaction isn’t the result value of the item, but the results of the appropriate transaction. The “response” in this post refers to not the results of the transaction, but the info of the item as mentioned above.

How to check responses

Then what ways are there to check the responses of the above scenario??

01. Use Transaction ID

If you call forth a smart contract, the results of that smart contract are given in return. In this, there is an ID value, and the first method in checking the response is using that ID.

With this method, there are things that must be done within the smart contract.

1. Leave a history by issuing a receipt.
2. Leave a history by running inner action.

Choose one of the above 2 choices. Thus, with get_action, you can get the info of the receipt or inner action of the history left.

*get_block only shows the actions that the user directly signed him/herself. Because receipts and inner action doesn’t show it, get_transaction is used.

There are a couple things to be aware of with this method.

1. It’s common to not be able to get the value of get_transaction right away when running a contract.
2. Polling must be done until received.

02. Use Table

Inside EOS smart contracts, tables can be used similarly to the feature of database. The second way to check responses is to save the result value of the contract that was run onto table, and taking and using this. The sequence is as follows.

1. Run the contract.
2. Save the return info of the contract onto table.
3. Bring the return info by using get_table_rows.

The above is another way to get the result value. With this, there also are a few things to be aware of.

1. Because anyone can run contracts using the same account at the same time, a unique value like uuid is necessary. (distinguishes which client called it forward)
2. In order to bring forth the result value, there is a need for table search polling.
3. Because the use of tables is related to EOS RAM, you must design accordingly. (ex. use delay action to automatically delete after 3 seconds, etc.)

03. Get the Value by Operating a Full Node

With the method of operating a Full Node to check the response, there are things that must be done within the smart contract.

1. Issue a receipt to leave a history, or run inner action to leave a history.
2. Use mongodb plugin, or develop and use your own plugin.

If you are going to use the mongodb plugin, you must set the mongodb’s replica set. Afterwards, using the method of triggering oplog, you can get the result value. Otherwise, there is the method of developing your own plugin as well. For example, after filtering the data that I want, you can use queue. (ex. using redis’ queue.)

There are things to be aware for this method as well.

1. Because anyone can run contracts using the same account at the same time, a unique value like uuid is necessary. (distinguishes which client called it forward)
2. Cost of operating a Full Node

Conclusion

There may be methods other than the 3 mentioned above that I do not know of. I’ve tried all 3 methods of the above. The 1st and 2nd methods requires reliance on the BPs. (if the BP’s api dies, our service also dies.) Also, the method of polling may even by left behind. I personally don’t think they are good methods.

The method I recommend to use is the 3rd one. If possible, developing and using a plugin that’s fit for your service is optimal. I also recommend operating a backup Full Node, just in case the Full Node used dies.

ITAM Games is a blockchain platform for a transparent gaming ecosystem

Subscribe to ITAM Games and receive the latest info.

Visit the ITAM Games Telegram to communicate regarding ITAM Games and Blockchain. Join by clicking the link below! 👫

Website: https://itam.games
Telegram: https://t.me/itamgames