I want to save the identity of the user invoking a transaction in hyperledger composer. is there a way of getting the user identity inside a transaction without passsing it as a transaction parameter?
Depends on how your users are managed. Typically an organization has a couple of fabric users that invoke transactions on the blockchain. This user can be determined by the ledger. However if you authenticate users at the application level then invoke with the same fabric client there is no way of drilling down to know which user from within an organization invoked the transaction without passing the user as part of the transaction
Answering my question, Hyperledger composer has a global method getCurrentParticipant that can be called inside the transaction to get the participant invoking the transaction. Also it has getCurrentIdentity which can be used to get the identity of the current participant. for more information
Related
Every time that I restart my app (bot), conversation states are lost.
Is it possible to persist user state in a storage (like redis or a database) during conversations? How to do that?
This feature is currently in master branch now. There are 2 main classes: DictPersistance and PicklePersistance.
Of course, you can write your own implementation with Redis or Database using BasePersistance class.
See Gihub PR.
As I heard most of the time that in micro services architecture, for every single micro service we have to create individual database.
But if I have to maintain foreign key constraint across the different databases which is not possible. Like I have a user table in authentication micro service and I want to use it in my catalog service(userid column from user table)
So how can it be resolve.
Thanks in Advance
You can maintain a shadow copy (with only useful information for eg. just the userid column) of user table in catalog service via event sourcing(for e.g. you can use rabbit MQ or apache kafka for async messaging).
Catalog service will use the user information in read only mode. This solution is however effective only when user information doesn't change frequently. Otherwise async communication can be inefficient and costly.
In that case you can implement API calls from catalog service to user service for any validations to be done on user data.
Use the Saga Pattern to maintain data consistency across services.
A saga is a sequence of local transactions. Each local transaction
updates the database and publishes a message or event to trigger the
next local transaction in the saga. If a local transaction fails
because it violates a business rule then the saga executes a series of
compensating transactions that undo the changes that were made by the
preceding local transactions.
I have a business network with 2 Orgs, and each Org have one peer. According to my endorsement policy that I've used to start the network both Orgs must endorse transactions.
According to the Hyperledger Fabric docs here and FAQs here the client should connect to each endorsing peer and submit a transaction to both.
Composer has transaction submit command which allows to submit a transaction to the business network. But referring to docs here there is no parameters to specify the peers to which client should connect. Actually, when I submit the transaction this way using the admin card of one Org, I get ENDORSEMENT_POLICY_FAILURE error. The same situation happens when I submit transaction through the Composer REST server.
Is there any way to submit a transaction using composer to multiple peers for endorsing?
Thanks to Paul O'Mahony for helping to understand what composer transaction submit command does (see the comments below the question):
Composer will send the transaction to all the Peers in your connection.json document.
Initially I made a wrong assumption that the issue was with the endorsement policy. Actually, my problem was with access rules. A participant had no rights to create that transaction. Correcting the ACL file fixed the issue.
If I want to develop a node.js application for a Hyperledger Fabric Composer business network, it is necessary to define (in the model file) events that are emitted, whenever a transaction takes place. Otherwise, the node.js application is not "informed" about those transactions (see https://hyperledger.github.io/composer/latest/business-network/publishing-events.html).
Defining the events (in the model file ... and emitting them in the respective transaction processor functions) makes it possible for the node.js application to subscribe to those events (and therefore to be informed about transactions happening.)
So far I understand it.
My question is the following:
When I use the composer rest server (i.e. the automatically generated node.js application) instead of developing my "own" node.js application, do I still have to define the events for the transactions defined in the model file (.cto)?
Or is this not necessary because the composer rest server does not use those events anyway?
You would still need to define events in your model, then publish them in your transaction code (and subsequently consume them (subscribe) them from a client - whether composer-client or websockets etc. So regardless of whether you're using the REST APIs, Composer client APIs or even the CLI.
So if you POST a transaction from your REST client (eg. browser)- which sends it to the REST server - you must have defined an event (in your model) AND furthermore, your transaction logic would have to emit that event - for any listener to process it.
How can I prevent users from submitting a timestamp with their transaction?
When I create a transaction, the timestamp field is added to the transaction and can be inputted by the user.
While the timestamp on the transaction is populated if the client does not send it, the user can send in their own timestamp to back-date a transaction.
I think you would have to enforce this in the client tier (prior to submitting the transaction using the Node.js or REST API).
This is an interesting requirement however. Can you elaborate more on the use case and what you are worried about?