DSL workflow design

HI Team,

I’m looking for your suggestion on DSL workflow design. My challenge is how to pass data into a workflow. Considering there two cases,

  1. Manual activity which will wait for a user input.
    It’s not ideal to poll from activity.

  2. aws sqs message listener activity which will listen on a queue, filter message if condition matched then continue to next activity.
    Creating a listener in every running workflow to poll message will not work. It makes more sense to have a centralized listener to filter and dispatch message to corresponding workflow instance. Then this activity will basically just wait for a message trigger and consume the message

Since DSL is dynamic and signal is only on workflow level not inside activity, it’s difficult to define signal logic in workflow and send the signal. Can you please advise, thanks in advance.

Thanks
Gaoxin

Signal is the way to go in this case. No need to use an activity or queue. Just signal a workflow when user completes the action.

Since DSL is dynamic and signal is only on workflow level not inside activity, it’s difficult to define signal logic in workflow and send the signal. Can you please advise, thanks in advance.

I don’t understand your concern. You can always include some correlation id into the signal data and lookup a specific node in your DSL using it.

Thank you Maxim for your quick response. The DSL is generated flowchart by frontend drag & drop UI.Each activity is a draggable node in the UI. So currently manual step or others steps which need input data have to be activities for user to construct workflow and then send to temporal to execute. Also, as far as I understand, every workflow have different ID. I will need to filter all running workflow, find out the dsl and check if next activity needs signal and then send signal. Is there a better way to do this. Thank you very much.

Each activity is a draggable node in the UI. So currently manual step or other steps which need input data have to be activities for the user to construct workflow and then send to temporal to execute.

There is no need to map UI abstractions to Temporal abstractions directly. A single UI element can be implemented with any amount of code in Temporal. For example, a DSL step like “deploy my service to production” can be implemented with a pretty complex child workflow that talks to dozens of services.

I’m pretty sure that your users do not think in terms of Temporal activities. They think about business-level actions that should be performed.

So a manual step which is a single DSL workflow element can be mapped to an activity that initiates this step and a signal handling logic that completes the step. For implementation simplicity, you can always create higher-level coding abstractions (like OO classes) to encapsulate complex behaviors.

Why currently UI element is mapped to activities is when user execute a workflow, they can see state, input/output of each element. It’s straightforward to call GetWorkflowHistory to get activity detailed information and display real time data on UI.

And in our user cases, we provide fundamental functionalities as activities mapped to UI element node, different team can drag & drop element to create their own workflow based on their business requirement.

But you are right, there is no need to map UI abstractions to Temporal abstractions directly.Backend can handle the logic for two way bindings, how to execute and feed data back to the frontend.