UI based workflow generation

[sibabrata-getfareye]

Hello, Currently I have been exploring Temporal as workflow engine to run our BPM workflow. Since Temporal doesn't provide any DSL/UI for defining any workflow, I am exploring the same and came to know about serverlessworkflow effort. I have few clarifications -

1. Whether the current specification supports all temporal constructs like async task execution, Long running task, Workflow signal and querying etc.

2. Does serverlessworkflow provide any UI tool to create BPM workflow by drag/drop and automatic json/yml generation from the UI based flow?

[cdavernas]

@sibabrata-getfareye Not yet, but that's a WIP my company's working on. Won't make it to release any time soon, though, as we have conflicting priorities on both the spec and the runtime.

[tsurdilo]

1. Yes, SW supports async activity invocation (will be released with v0.8 shortly, and is already in main spec branch). It also supports long-running tasks and our Temporal integration will support heart beating as well (its currently being worked on). Yes, it supports signals (in our dsl called events). The DSL does not support currently queries, like what Temporal has, however in our integration efforts we use the Temporal Java SDK dynamic workflow interface where we can dynamically register queries, given some configuration for example (metadata).

2. Serverless Workflow is a markup-based DSL, not a flowchart-based one, like BPM. We provide tooling support for both web and IDEs. Given that our spec is based on a Json Schema definition, any IDE with schema support can help with auto-completion, validation etc of workflow defs in json or yaml.

Currently we provide diagram generation that creates a static SVG/PNG from your workflow def, as you can see here: https://serverlessworkflow.io/editor . Both our Java and TypeScript SDKs have this currently. As Charles mentioned, there are also some more things under way that might be coming in the future that will enhance that experience.

[sibabrata-getfareye]

Thanks @tsurdilo for detailed reply.

[tsurdilo]

@sibabrata-getfareye let us know if you would like to help us with our Temporal integration efforts, and I can add you to the repo. It's private atm as the work is still in early stages but we should have something for public hopefully soon.

[gedw99]

I would like to help on this if it’s ok @tsurdilo

[Kshitiz1403]

@tsurdilo I would love to contribute too.

[edfus]

Happy to jump in and help, @tsurdilo.

[JBBianchi]

From our understanding, Temporal doesn't support Serverless Workflow atm. See serverlessworkflow/serverlessworkflow.github.io#207

[tsurdilo]

@sibabrata-getfareye Also just to add:

Serverless Workflow us much closer aligned with Temporal runtime than BPM. This is IMO a very important thing to mention especially in your case. Here are some points why:

Serverless Workflow DSL:

1. Closely aligns with Temporal timeouts (WorkflowOptions, ActivityOptions, RetryOptions, etc)
2. Has ability to specify automatic retries, as its also possible in Temporal. With BPM you have to define retries in your model which for large models is a complete pita.
3. Defines Error handling that is much more aligned with what Temporal has, especially with retries, as serverless workflow dsl can similarly define both retryable and non-retryable error types.
4. Supports Cron (periodic execution) out of box
5. Has Simpler states that define clear control-flow logic. This is a big benefit imo compared to BPM which is much more granular. With serverless workflow, mapping workflow states to code is much simpler.
6. Has clear action (Temporal activities) types, meaning that it is clear from the SW DSL def alone how to invoke a specific function. With BPM you pretty much rely on Service Tasks, and have to provide this info via custom mappings (as well as have to provide in most cases custom tasks for invoking functions via rest, openapi, asyncapi, graphql, grpc, etc etc...that you most likely have to write by yourself, or rely on your bpmn runtime capabilities to provide to you, most likely in a proprietary way).
7. and many more points that we can discuss if you want :)

I say all this because I have as a side-project also looked into implementing BPM ontop of Temporal, and in my experience using SW will cut your integration time in more than half in my opinion without really any loss in functionality/ability.
Hope this helps.