[Question] Workflow DI about sdk-php HOT 6 CLOSED

Hello! We deliberately avoided the possibility of injecting any variables inside the Workflow, since changing these values can change the behavior of this Workflow, which will break absolutely the entire code.

For example:

#[WorkflowInterface]
class GreetingWorkflow
{
    public function __construct(private Some $service) {}
    
    public function greet(string $name): \Generator
    {
        if ($this->service->doSomething()) {
            yield $this->greetingActivity->composeGreeting('Hello', $name);
        }
        
        return yield $this->greetingActivity->composeGreeting('world', $name);
    }
}

In this case, the argument is a reference to an external service dependency that may have side effects that will break the workflow execution.

Moreover, when implementing the SDK, we focused on Java SDK, where there are no arguments for the workflow constructor.

However, the example with your code looks quite convincing. So we need to think about how to solve your problem.

from sdk-php.

@Zylius
as @SerafimArts mentioned, workflows must be deterministic, and you register the workflow type with the worker, not an instance.

You can achieve what you are looking for, I believe, with WorkflowClientInterface->startWithSignal (when you are starting your workflow execution, and not when you are registering your workflow with worker)

startWithSignal will start workflow execution (if no active ones is available) and send the signal on start. The data that you want to "inject" can be the signal data.

from sdk-php.

Hey, thanks guys! I wasn't aware of startWithSignal and Signal functionality. I'll try it out!

See what we're trying to do here, is generate temporal workflows (just like my past question about activities #110) from our legacy configuration. Now the example you gave @SerafimArts, kinda got me a little worried. What I've been trying to avoid is generating "stub" php classes for workflows from our YAML files. But if that's what we have to do, I'll be willing to do it.

Update concerning startWithSignal: lets say we have two services. ServiceA starts the workflow, and has its interface. ServiceB implements the workflow interface. ServiceA shouldn't be the one injecting configuration into ServiceB workflow, since ServiceB is the one responsible for it. So I don't think this will work in our case :/

from sdk-php.

FYI, with local activities, you will be able to "upload" the workflow config via calling the activity. It will be deterministic since it will freeze the workflow state in history.

Local Activities are planned in the 1.1 version of this SDK. In the meantime use classic activities.

This way workflow fully controls its config (i assume declarative DSL) and does not expose anything to the outside. This should solve your case without exposing anything.

@tsurdilo I believe the community can greatly benefit from a simple example of how to convert legacy DSL workflows into temporal workflows.

from sdk-php.

Something like that:

public function workflowMethod(string $type) 
{
     $yaml = yield $this->config->loadParsedConfig($type);

     // do something with yaml, the workflow is not detached from your config file and even if you changes it - it will remain deterministic
}

So, in simple words, do the data DI via deterministic markers:

1. Local Activity
2. Activity
3. Signal
4. Also you can use side-effect if the file located withing the current filesystem, but be careful as it's blocking call

from sdk-php.

Thank you very much! We've already done this and it works great. Kinda asked the question without fully understanding how temporal flow works. 🙇

from sdk-php.