Conversation
| public interface NexusRemoteGreetingService { | ||
|
|
||
| class RunFromRemoteInput { | ||
| private final String workflowId; |
There was a problem hiding this comment.
So part of the reason to wrap a Workflow in a Nexus service is to hide the workflow from the caller, so I wouldn't call this ID workflowId the service doesn't need to expose that it using workflows to the caller.
| .newWorkflowStub( | ||
| GreetingWorkflow.class, | ||
| WorkflowOptions.newBuilder() | ||
| .setWorkflowId(input.getWorkflowId()) |
There was a problem hiding this comment.
Even though it make make the sample a bit more complex, I wonder if we should show here the workflow ID doesn't have to directly map to the nexus operation input. The workflow ID can just be derived/computed liked .setWorkflowId("NexusRemoteGreetingServiceWorkflow-" + input.getId())
| operations. The caller interacts only with the Nexus service; the workflow is a private | ||
| implementation detail. | ||
|
|
||
| There are **two caller patterns** that share the same handler workflow (`GreetingWorkflow`): |
There was a problem hiding this comment.
I think I would split these up into two separate samples since the amount of code here could be overwhelming and make it harder to follow
core/src/main/java/io/temporal/samples/nexus_messaging/handler/GreetingWorkflowImpl.java
Outdated
Show resolved
Hide resolved
...rc/main/java/io/temporal/samples/nexus_messaging/caller_remote/CallerRemoteWorkflowImpl.java
Outdated
Show resolved
Hide resolved
| public class CallerStarter { | ||
|
|
||
| public static void main(String[] args) { | ||
| WorkflowServiceStubs service = WorkflowServiceStubs.newLocalServiceStubs(); |
There was a problem hiding this comment.
All samples should support env config. You can look at other samples to see how to create the client and follow the pattern there https://github.com/temporalio/samples-java/blob/main/core/src/main/java/io/temporal/samples/asyncchild/Starter.java#L22
This shows two ways to send messages through Nexus.