From Slack -- How to start workflow in a different service than executing the workflow? with or without a different SDK

[longquanzheng]

QA from Slack: https://iwfglobal.slack.com/archives/C048NCNLZB9/p1719045843641659

Hi ,
I checked the iwf repo and also java sample repos. In most of the example, workflow is started via API call to service. I can see same service starts the workflow by calling to iwf server and also execute the workflow.
Is there a way I can start workflow from different service (say A) and workflow get executed in different service (say B) and later from service A I can check the workflow update? If so please share the link which I can go through to understand more on this?
Example,
to start a workflow we do this,
client.startWorkflow(CustomerOrderOrchestrationWorkflow.class, workflowId, 3600, orderRequest);
here , CustomerOrderOrchestrationWorkflow.classis present in java repo so I think it is fine. Now If this class is implemented in python (CustomerOrderOrchestrationWorkflow.py) and defined in say in python repo, then How I can invoke that workflow from java repo ?

[longquanzheng]

The current possible approaches:

1. Let serviceB define the workflow and also exposes an API for serviceA to call, in order to start.
2. Re-define the workflow in serviceA as declaration. You only need to define the structure — mostly the workflow type, and the starting state’s input type & stateOptions. This is because iwf Client only needs them when starting the workflow. (in fact, it may also need search attribute definition, if it’s being used for initialSearchAttributes). You don’t really need to implement any state. Because start API won’t trigger any implementation.
3. Use unregisteredClient — this is a rawClient that doesn’t require workflow registry. In fact this is how Client works underneath.

The cons of each:

1. It adds a little more latency on starting workflow
2. It adds a little more duplicated code and may be confusing as “declaration”.
3. It requires some more detailed understanding of iwf Client

Currently my preference is 1 and that’s the preferred within Indeed. The extra latency is usually not a big deal. From arch’s point of view, it’s even cleaner and more “microservice” — serviceA doesn’t need to understand anything about iWF (eg the error handling of the start workflow API ) because serviceB is taking care all of this underneath