getEventsByContractKey

Hello, I have 3 questions on EventQueryServiceGrpc.getEventsByContractKey -

  1. What is the purpose of the index field in EventQueryServiceOuterClass.GetEventsByContractKeyRequest.Builder.setRequestingParties? I don’t understand how to use this index field. I tried using setRequestingParties but it kept throwing an index-out-of-bounds exception so had to use addRequestingParties instead. The javadoc description for index describes the purpose as “The index to set the value at” - that is not specific and does not describe the purpose of the field. Could it be made clearer on the javadoc?

  2. I understand this is currently an experimental endpoint, but assuming DA were to make this GA at some point, would it be added to the higher level com.daml.bindings-rxjava as well? Currently it is only available in the lower level gRPC bindings (com.daml.bindings-java) which is quite cumbersome and verbose to use.

  3. Any plans to support multiple templates in (setTemplateId) in the future?

  1. Suppose you have used the builder to add three parties. You can then use the setRequestinParties with index (0-2) to change them. If you want to assemble a set of parties, the addRequestingParties is the right function to use.
  2. Yes, we’ll add the endpoint to bindings as it matures.
  3. There are currently no such plans. What would be the advantage of this over calling the endpoint once per tempalteId?
1 Like

Re #3, let me explain what I’m trying to achieve with an example. Let’s say I have the following templates & workflows:
OrderProposal → RejectedOrder
OrderProposal → Order → DeliveredOrder | CancelledOrder

Let’s say I have a non-Daml REST API that exposes an OrderEnquiryService that takes an orderId and returns the latest business state for that orderId, so depending on where that order is in its lifecycle, returns either a OrderProposal or a RejectedOrder or an Order or a DeliveredOrder or a CancelledOrder.

To do this, my Java app that handles the REST api call would need to call getEventsByContractKey upto 5 times, once per template, to return the latest business state to the caller, which would mean 5 hops between the Java app layer and the participant node’s ledger API. If it instead allowed me to pass in multiple template IDs, similar to the way the Template filter behaves on the Transaction Service, then I’d need only 1 hop.

As an alternative, I’ve been looking at the following 2 approaches to reduce the number of hops:

  1. Have only one single template of type Order with a status field on it to indicate it’s status in the lifecycle. This is not currently preferred.
  2. When my Java app handles the order enquiry call, call getEventsByContractKey in parallel over 5 threads (still using the blocking stub version) and make the parent thread sleep until all 4 child threads have responded.

Any thoughts/suggestions?

I would call the endpoint in parallel up to some fixed parallelism limit (e.g. the number of threads you have).

1 Like