Analysing Temporal for project requirement

Hi All,

I have been analyzing various workflows that will suit project requirement.

The requirement is ,

This is entirely event based application where we are using Kafka to read events and then as per client chain of services are called.

We support multiple clients and multiple services say A,B,C [ may be here we can invoke a workflow]
Client X can go for services A- >B
Client Y can go for services A- >B → C
Client Z can go for services A- > C

Does Temporal fits in this architecture Please suggest.
If yes , how the workflows will be designed. for each tenant we’ll have a new workflow ?

Sorry, from the description of your application it is very hard to make any specific recommendations.

It is a pretty common architecture when a workflow listens on external events and takes action based on its state.

Basically my question is : all these services[A,B,C] are in same microservice and we need to pipeline these services as per clients.

is Temporal fits in here ? Also due to kafka and huge customer base every sec we’ll be getting thousands of events

second question : can we externalize the states transition like BPMN files?

Can you provide more info on this? You could pass configuration information as workflow inputs for example and based on that data use programming-language concepts for control-flow logic.

Thanks tihomir , How can I pass the configuration inputs ? Is there a sample I can refer?
To clarify more on this ,
my workflow steps may defer for each clients.
with dsl based workflows I can deploy different bpmn files without any code change.
how to get the same with Temporal ?

@Nitz since it seems you are familiar with bpmn, i will try to relate answers to that :slight_smile:

with dsl based workflows I can deploy different bpmn files without any code change

I assume in this case you have a bpmn file for each possible client, and can deploy new ones as new client comes up that requires different control flow logic.
With Temporal you can do the exact same if you wanted, have a different workflow for each client and deploy new ones when the need comes up.

This is an option but with bpmn you can have multiple execution paths based on data (using gateways for example). With Temporal you can use all the control logic aspects of the programming language you chose so in that way it provides much a more powerful way to define control flow logic.
So you can with bpmn as well as Temporal create a single workflow definition and define execution paths given your data inputs.
For this case Temporal has some huge benefits over other workflow runtimes, especially around changes (versioning). You can see this video to get an idea: Move Fast WITHOUT Breaking Anything - Workflow Versioning with Temporal - YouTube

Another thing I wanted to bring up with bpmn solutions, especially for service invocations, you are bound to the implementation of the service tasks as far as what you can / cannot do and how you have to invoke your services. Sometimes bpmn solutions provide some “out of the box custom tasks” but still you depend on the runtime impl for that and it might not suit your specific needs long term. With Temporal you can define the interactions with your 3rd party services you want to invoke yourself (in activities) and maintain/update them as you wish, not having to depend on proprietary solutions.

There are other important aspects that Temporal provides that you should also consider. Things like fault-tolerance, for example activity retries, which with temporal come “out of the box” and you would have to model yourself in your bpmn solutions, same with error handling which is not only much more powerful in Temporal, but also works across different Temporal SDKs. Ability to define rate limiting for invoked services, powerful workflow and activities timeouts, all which many bpmn runtimes do not provide.

Don’t also forget async and parallel invocation of your activities which you can do using the Temporal SDKs.

How can I pass the configuration inputs

It’s really similar to the ways you would with bpmn as well. Bpmn runtimes allow you to pass some data when you start your workflow instance, which gets mapped to your process variables.
With Temporal you can define as many arguments to your workflow (workflow method)
and pass those in when you start your workflow. With Java SDK for example you can do:

   WorkflowClient.start(myWorkflow::execute, arg1, arg2);

where “execute” is your workflow method and arg1, arg2 are your arguments you pass to it (could be your configuration for example)

Another way you may be thinking of doing in bpmn is via a message start event where idk you send a signal to trigger workflow execution passing in your data (configuration). You can do the same thing with Temporal using for example:

 workflow.signalWithStart("myWorkflowSignalName", arg1 arg2);

which starts your workflow execution and then signals the workflow passing in your arguments.

If you wanted to get “fancy” and use like a bpmn intermediate message event (so you start your workflow and then send a signal with data to it), you can again do the same with Temporal, for example start your workflow and then inside your workflow code just have (again Java sample):

  Workflow.await(Duration.ofMinutes(5), () -> myConfig != null);

Note that this also in 1 line of code also handles the max time you are willing to wait (optional) which in case of bpmn you have to model yourself (i assume a parallel gateway going to a conditional event and timer event and then parallel merge + finally conditional checks).

Is there a sample I can refer?

We have lots of samples you can take a look at depending on the programming language you want to use:
Java: GitHub - temporalio/samples-java: Temporal Java SDK samples
Go: GitHub - temporalio/samples-go: Temporal Go SDK samples
PHP: GitHub - temporalio/samples-php: Temporal PHP SDK samples
NoteJs: GitHub - temporalio/samples-node

1 Like