Development Flashcards
(14 cards)
Workflow Creation
There are two steps for turning a Java interface and implementation into a Workflow Definition:
Annotate the interface with @WorkflowInterface
Annotate the method signature with @WorkflowMethod
Input Parameters and Return Values
Values Must Be Serializable - In order for Temporal to store the Workflow’s input and output, data used in input parameters and return values must be serializable.
Avoid Passing Large Amounts of Data
The worker
Workers execute your Workflow code. The Worker itself is provided by the Temporal SDK, but your application will include code to configure and run it. When that code executes, the Worker establishes a persistent connection to the Temporal Cluster and begins polling a Task Queue on the Cluster, seeking work to perform.
Initializng Worker
There are typically three things you need in order to configure a Worker:
A Temporal Client, which is used to communicate with the Temporal Cluster
The name of a Task Queue, which is maintained by the Temporal Server and polled by the Worker
The name of the Workflow Definition interface, used to register the Workflow implementation with the Worker
Workflow Initialization Explained
WorkflowServiceStubs service = WorkflowServiceStubs.newLocalServiceStubs();
The main method begins by creating a WorkflowServiceStubs instance, which represents a gRPC connection to a Temporal Cluster. The newLocalServiceStubs() method used to create this instance here is appropriate when the Temporal Cluster and Worker are running on the same machine, as is often the case during development. If the Temporal Cluster is running on a different machine or if you are using Temporal Cloud, you would instead call the newServiceStubs(WorkflowServiceStubsOptions options) method using options that include the hostname and port number used to reach its frontend service.
Workflow Client
WorkflowClient client = WorkflowClient.newInstance(service);
Next, the code uses the WorkflowServiceStubs instance to create a Temporal Client, which the Worker will use to communicate with the Temporal Cluster.
WorkerFactory
WorkerFactory factory = WorkerFactory.newInstance(client);
// Specify the name of the Task Queue that this Worker should poll
Worker worker = factory.newWorker(“greeting-tasks”);
WorkerFactory is used to create one or more worker instances
Worker and Workflow Implementation
worker.registerWorkflowImplementationTypes(GreetingImpl.class);
After creating the Worker, you must register the Workflow implementation class that you want this Worker to support. A single Worker can support multiple Workflows, so you can call this method multiple times, passing in a different Workflow implementation class each time.
Worker Start and Long Poll
Finally, it calls the factory’s start method, which starts the Worker instance(s) created by that factory, although only one Worker instance is created in this example. When the Worker starts, it will begin a “long poll” of the Task Queue and will execute code in the Workflow Definition in response to tasks created by the Cluster.
Lifetime of a worker
The lifetime of the Worker and the duration of a Workflow Execution are unrelated. The start function used to start this Worker is a blocking function that doesn’t stop unless it is terminated or encounters a fatal error. The Worker’s process may last for days, weeks, or longer. If the Workflows it handles are relatively short, then a single Worker might execute thousands or even millions of them during its lifetime. On the other hand, a Workflow can run for years, while the server where a Worker process is running might be rebooted after a few months by an administrator doing maintenance. If the Workflow Type was registered with other workers, one or more of them will automatically continue where the original Worker left off. If there are no other Workers available, then the Workflow Execution will continue where it left off as soon as the original Worker is restarted. In either case, the downtime will not cause the Workflow Execution to fail.
Starting a workflow
One way to start the Workflow is by using the temporal command-line tool to run a command similar to the one shown here:
temporal workflow start \
–type HelloWorkflowWorkflow \
–task-queue greeting-tasks \
–workflow-id my-first-workflow \
–input ‘“Mason”’
The command also specifies a Workflow ID, which is optional, but recommended. This is a user-defined identifier, which typically has some business meaning, so an expense reporting workflow might have a Workflow ID that identifies the expense report or the employee who submitted it. If omitted, a UUID will be automatically assigned as the Workflow ID
Since this Workflow requires input (a string containing a name used to customize the greeting), this command supplies that value, using –input
You can save the input to a file, in JSON format, and specify its path to the –input-file option, rather than using the –input option to specify the data inline, as shown here.
Running the command
When you run the command, it submits your execution request to the cluster, which responds with the Workflow ID, which will be the same as the one you provided, or assigned UUID if you omitted it. It also displays a Run ID, which uniquely identifies this specific execution of the Workflow. However, it does not display the result returned by the Workflow, since Workflows might run for months or years. You can use the temporal workflow show command to retrieve the result.
temporal workflow show –workflow-id my-first-workflow
Executing Workflow from Client- Synchronous response
WorkflowOptions options = WorkflowOptions.newBuilder()
.setWorkflowId(“my-first-workflow”)
.setTaskQueue(“greeting-tasks”)
.build();
HelloWorkflowWorkflow workflow = client.newWorkflowStub(HelloWorkflowWorkflow.class, options);
String greeting = workflow.greetSomeone(args[0]);
String workflowId = WorkflowStub.fromTyped(workflow).getExecution().getWorkflowId();
