Translate JSON workflow

Community Support
1

What is the preferred way to translate JSON workflow definitions(created by a web app) as a Temporal workflow? In all the examples given, the workflow logic is wired within Java code.

1 Like
3

The gist of the idea is that you write an interpreter workflow for your JSON definitions.

There are multiple ways to structure such a workflow. Here is the approach that we recommend:

  1. Implement an activity that accepts your DSL workflow ID and the current state of the workflow. And returns the new state which includes the list of operations (like activity invocations or timers) to execute.
  2. When requested, the activity loads (or gets from a cache) the specific object graph generated from JSON by its ID and applies the current state to it to get the new state.
  3. A workflow is implemented as a loop that invokes that interpreter activity to get the updated state with operations to execute.
  4. The requested operations are executed. For example, activities are invoked or timers are created.
  5. Upon completion of any of the operations, the state is updated and the interpreter activity is invoked again.

We have plans to write a sample to demonstrate this approach.

1 Like
4

I have not completely understood the approach, an example would help.

As I understand, when writing a java workflow, the developer does not worry about managing state himself. Isn’t managing states different from that?

  • Is it possible to have a builder API part of Temporal SDK that could compose a dynamic workflow?
  • What are your thoughts on dynamic code generation? I know its not straightforward to load the compiled classes in Java, may be using a byte-code generation library?
5

As I understand, when writing a java workflow, the developer does not worry about managing state himself. Isn’t managing states different from that?

Developer has to manage state in the form of variables of the program he is writing. The Temporal takes care of preserving the state of variables and threads. So the state of the dynamic workflow execution has to be managed by your code.

  • Is it possible to have a builder API part of Temporal SDK that could compose a dynamic workflow?

We have plans to add DSL SDK for simplifying the creation of your own dynamic workflows. But at this point, you have to write it yourself.

  • What are your thoughts on dynamic code generation? I know it’s not straightforward to load the compiled classes in Java, maybe using a byte-code generation library?

I’m not sure about the value of this. Writing a JSON interpreter is 100 times simpler IMHO.

1 Like
7

I am also interested in this, it seems being able to “design” workflows via a UI is a pretty common ask, especially to allow end users to customise workflows to suit there requirements.

As I understand the above, the recommended approach is to have your UI / “designer” coupled to its own DSL for building and presenting a workflow - for example as json thats meaningful for your use case.

You’d then create a temporal workflow activity that can take that workflows “state” as input, which would include an ID to load the current JSON definition of that workflow as designed in the UI. This activity would load this definition and “apply” that state - essentially it needs to evaluate the workflow logic at this point by looking at the JSON definition and looking at the current state and evaluating what are the next temporal actions that should occur. For example the state might track which step in the json workflow has currently been reached. This activity would then return some structured output data back to the calling workflow for it to intepret as the next “actions” it should take. This might be pretty complicated- for example this could be a delay, or executing another temporal activity or something else.Then lastly the final piece is the calling temporal workflow that runs as a loop and executes this activity (passing any state), gets back the resulting actions it should intepret and executes those actions.

Couple of points:-

  1. You are essentially building your own control flow engine which is invoked by temporal and you return data for what temporal should do next
  2. Ideally the “what to do next” would be a very simple instruction such as a delay, or executing a particular activity with parameters. Building this layer is probably the hardest part to get right and probably where temporal could make this easier somehow… there is no standard data structure that can be interpreted by a temporal workflow that tells it what to do next so it needs implementing. Im guessing this implementation would also be different per sdk.
8

I think you overcomplicate this. See the DSL sample for reference.

1 Like