Choice name filter in getTransactionTrees

I have the below Java code that currently filters by party and its working great. I want to take it a step further and make it only fire when the specific choice I care about is triggered instead of handling that in the “processTransactionTree”. All the examples seem to only filter by party and I can’t seem to get syntax right for anything I have tried.

Bonus question - If I have the contractID that the choice was triggered on, is there a way to easily pull the data for that contract? Thanks for any help as always.

Flowable<com.daml.ledger.javaapi.data.TransactionTree> choices = serviceClient.getTransactionsTrees(
LedgerOffset.LedgerEnd.getInstance(),
new FiltersByParty(Collections.singletonMap(damlProperties.getListenerParty(), NoFilter.instance)), true);
choices.forEach(this::processTransactionTree);

That’s not possible at the moment. Transaction trees don’t allow choice filters or even template filters. You have to filter on the client side.

As for your second question, you cannot directly query a contract by its contract id on the gRPC API so you might want to keep an index on the client side or use the JSON API which does that for you.

Thanks, I have switched this part to use the JSON API and was able to pull the contract with ease.

I am having some issues with handling the response though. First had some issues with gson being able to handle Optional fields but I found some code to help with that. Next issue was that using the “Contract” object it had the payload as “data” in the java created classes instead of “payload” simple rename fixes it but of course this is generated code so that will just get overwritten each time so not a good solution. Is there something I’m missing in all this to use the java generated class? Thanks for answering all my newby questions.

edit
I see now that the JSON API is to be used with the JavaScript libriaries so that’s probably why I’m having so much trouble. I will have to figure out how to get the data I need from the gRPC.

Indeed, the Java bindings and codegen are currently tailored for the gRPC API; trying to use them with the JSON API is not going to work out very well.