HI AM using DAML-On-Fabric project, currenlt am able to launch and deploy e2e application successfully with daml verion 1.11.0 and daml-on-fabric project version 1.10.0, fabric 2.x
But have a requirement in my project as i need to map parties dynamically instead of allocating parties through command "daml deploy --host localhost --port 6865"which allocating parties present in daml.yaml file.
When i hit my api through post man getting an error saying “Null” no parties match found i fabric-ledger.
Any one please help me how can i pass parties dynamically through api.
The Ledger API exposes a service to manage parties registered on a participant. The PartyManagementService#AllocateParty RPC is used to allocate a party (it’s the same API used by the daml assistant). You can read more about it here on the documentation.
Plain daml application working fine with any party if i pass through postman request payload, but after integration with daml-on-fabric unable to map parties dynamically
Below is the error message i found when i pass party name which is not allocated in daml.yaml
23:34:54.550 [qtp1764086935-22] ERROR spark.http.matching.GeneralError [ : - ] -
java.lang.NullPointerException: null
at com.daml.hunter.HunterMain.lambda$7(HunterMain.java:124)
at spark.ResponseTransformerRouteImpl$1.handle(ResponseTransformerRouteImpl.java:47)
at spark.http.matching.Routes.execute(Routes.java:61)
at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:130)
at spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1568)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:530)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.base/java.lang.Thread.run(Thread.java:829)
When using daml-on-fabric, the party allocation is not done from daml.yaml (unlike Sandbox and PostgresDB). We need to explicitly allocate parties using
daml ledger allocate-parties --host localhost --port 6865 Alice Bob Charlie
Hi, Really not… Let me simplify my question.
I don’t want to allocate parties explicitly through “daml ledger allocate-parties --host localhost --port 6865 Alice Bob Charlie” command as same parties efined in daml.yaml file.
In real time all parties should go dynamically when we pass through api, it makes sense?
all the times i cannot define parties in daml.yaml and allocate explicitly right!!
Like how we pass dynamic parties in java/nodejs bindings of daml DAPP
I have used JSON-API after bringing up the daml-on-fabric. Then I can use URI /v1/parties/allocate and pass the parties. You can refer to the JSON-API here, by searching “Allocate a new party”.
This is how it looks like that I allocate party through JSON-API and then check the parties allocated.
HI Tam, Good to see you over here, am keen follower of your articles and Linkedin too…
Here again we are allocating parties either JSON_API or daml command, But my requirement is lets assume creating a contract between seller and buyer and developed templates and also using java bindings, when i give party name with through api, any name can be taking as input payload and creating contract but after integration with daml-on-fabric project it’s not taking dynamic party instead saying error as given party name is not found on fabric ledger allocated parties…
Please help me how to pass dynamic party names instead allocating before them
Thank you
I see, what you call dynamic party allocation is usually called implicit party allocation, i.e. any party referred in a contract will be allocated whenever it’s encountered for the first time in evaluating. Is that what you want?
If that’s the case, this is a feature that is supported by the sandbox to make it easier to play around with the model when developing and testing things out. I’m not entirely sure there is a mode for daml-on-fabric to work like this, but please consider it’s unlikely to be something you want to happen on a production system, as you could accidentally allocate the wrong party and assign it the control of contracts and choices due to a simple typo.
I’ll let people closer to the inner workings of daml-on-fabric chime in regarding the availability of implicit party allocation.
Expanding a bit on what @stefanobaghino-da said, implicit party allocation is a sandbox feature where the Daml ledger (served by sandbox in this case) blindly accepts any string as a Party. This is fine for development, but it is definitely not something you’d want in production.
In production, and especially in distributed context, the Daml ledger needs to create parties explicitly. While it may seem very tedious to have to create partie manually by running the daml ledger allocate-parties or by providing a comprehensive list of parties in daml.yaml, this is not how you should think about it. Let’s take a step back.
The Daml ledger accepts (requires) a JWT token to identify which party is currently sending a command. The JWT token is an authorization mechanism: a given token carries with it a number of rights that allows whoever carries it to perform actions on the ledger. Crucially, the token itself does not prove who is performing an action, it simply asserts that the carrier has a given set of rights.
This should raise the question of how those tokens get distributed, and who is responsible for ensuring that the right person gets the right (set of) token(s). This is not covered by Daml components and needs to happen externally. Authenticating a user and deciding which token they should get is something that has to be managed by a system external to your Daml ledger. As that system needs to create tokens for your users, it also needs to know which external identity (say, an email address) corresponds to which Daml party (or set of parties) so it can generate the proper tokens.
That external system should be in charge of allocating parties; it should, as part of its login flow, check if it already knows the party name for a user, and if not, call the /v1/parties/allocate endpoint and record the user ID <-> party name mapping.
With that setup, you can still get dynamic party allocation, with no manual intervention.
