Schedule API

Temporal Schedules are a replacement for traditional cron jobs for task scheduling because the Schedules provide a more durable way to execute tasks, allow insight into their progress, enable observability of schedules and workflow runs, and let you start, stop, and pause them.

Starting with this release, the Temporal PHP SDK begins to provide new primitives for Schedule CRUD operations.

Workflow Start Delay

Use the Workflow Start Delay functionality if you need to delay the execution of the Workflow without the need for regular launches. Here you simply specify the time to wait before dispatching the first Workflow task. If the Workflow gets a Signal before the delay, a Workflow task will be dispatched and the rest of the delay will be ignored. A Signal from WorkflowClientInterface::startWithSignal() won't trigger a workflow task. Cannot be set the same time as a WorkflowOptions::withCronSchedule().

/** @var \Temporal\Client\WorkflowClientInterface $client */

$workflow = $client->newWorkflowStub( GreeterWorkflowInterface::class, \Temporal\Client\WorkflowOptions::new() ->withWorkflowStartDelay(\DateInterval::createFromDateString('1 minute')) );

$client->start($workflow, 'Hello world!');

Interceptors

Temporal Interceptors are a mechanism for modifying inbound and outbound SDK calls. They are commonly used to add tracing and authorization to the scheduling and execution of Workflows and Activities. You can compare these to "middleware" in other frameworks.

The following types of Interceptors have been implemented:

• WorkflowClientCallsInterceptor

  : Intercepts methods of the WorkflowClient, such as starting or signaling a Workflow.

• WorkflowInboundCallsInterceptor

  : Intercepts inbound Workflow calls, including execution, Signals, and Queries.

• WorkflowOutboundCallsInterceptor

  : Intercepts outbound Workflow calls to Temporal APIs, such as scheduling Activities and starting Timers.

• ActivityInboundCallsInterceptor

  : Intercepts inbound calls to an Activity, such as execute.

• GrpcClientInterceptor

  : Intercepts all service client gRPC calls (see ServiceClientInterface).

• WorkflowOutboundRequestInterceptor

  : Intercepts all commands sent to the RoadRunner server (see RequestInterface implementations).

Please note that some interceptor interfaces will be expanded in the future. To avoid compatibility issues, always use the corresponding traits in your implementations. The traits will prevent implementations from breaking when new methods are added to the interfaces. A reminder of this and a link to the corresponding trait are placed in the comments of the interceptor interfaces.

In this release, we have also added support for headers, which are an integral part of interceptors. Headers, being metadata, are intended for sharing context and auxiliary information. Headers sent at the start of a workflow will be propagated to all subsequent calls from the Workflow and can only be modified in interceptors.

You can find examples of how to use interceptors in the samples repository (PR)

Release notes