How to poll from external api in response to webhook

I have the following use case in a temporal workflow implemented in JAVA. How do I implement it ?

  1. Send email to customer to provide some information
  2. Wait for customer to provide this information. In this case, we are asking the customer to transfer $20K funds in total. The customer can transfer $20K in multiple transactions. i.e first transfer 5K and then transfer remaining $15K
  3. There is an event(Kafka event) that gets published when the funds arrive to the system. I want to check if the total is $20K each time the event is received. If not, I want to wait for the next event and want to check again if $20K is reached.

I do see some suggestions to not trigger activities in signal handlers. If that’s the case, how to implement this in JAVA. Since it is not known the number of times the activity needs to be invoked to check if the total transfer amount is > $20K, I can’t implement this in workflow as discrete set of steps.

How do I model this in temporal ? If temporal isn’t a great fit for modeling such use case, please let know as well

A part that can be confusing about Termporal’s Java SDK for Java programmers is that Temporal implements the equivalent of a coroutine or JavaScript await style execution model (which you don’t usually see in Java because it’s not implemented natively). The workflow execution is single-threaded (like, for example, how JavaScript is single threaded); but when the workflow reaches a point where it’s waiting for something (activity completion, sleep, etc) execution can be parked at that point and other events can be responded to (which again is like JavaScript’s await, but is not like Java’s normal single-threaded execution).

Which is to say, there’s nothing wrong with starting activities from signal handlers, but it does help to understand the execution model.

Look into Temporal’s asynchronous methods (see for example “Calling Activities Asynchronously” in io.temporal.workflow package summary - temporal-sdk 1.29.0 javadoc) to deal with the possibility of multiple signals arriving while activities triggered from previous signals are still running.