Synchronous Workflow

[vamsi yeluri]

Hi,
I have this following requirement.

1. User sends some data
2. Trigger the workflow and send the workflow output to the user

The user will be waiting for the workflow output.

Someone already posted this and the solution they suggested was to wait until state=manual. 

Could someone please elaborate that or provide any alternate way of solving this?

[nflow-users]

Hi,

Some questions to clarify the case:

• Is the workflow instance created by a user event? Or is the workflow instance waiting for user data at some step in the middle of the workflow?
• Does the workflow end immediately after the output is sent to the user?

In case the workflow instance is created by a user event, "user sends data" can be implemented like "create new workflow instance (possibly with some state variables) when the user data is received". Then you could have one or more workflow states in that workflow where you do some processing, wait for other systems etc, and in the last state you can "send the workflow output to the user" (for example email or whatever).

If this is part of some bigger workflow, then you could just implement the same as above as a separate workflow and create a new instance of it as a child workflow in one of the steps of the parent workflow.

If the process ends when the user gets the output, then you don't need to "wait until state=manual". You only need that when the the process has a state where it needs to wait for user input before it can continue.

br, Edvard

[vamsi yeluri]

It is kind of similar to the first case. It is actually a spring rest API. When a user calls this API, a workflow instance will be created. I want to wait till the workflow's status is finished and then send the workflow output as response to that API call. 

[nflow-users]

Hi,

The normal way to wrap nFlow functionality to a REST API is to have two endpoints: submit work and poll for the result. The first one should be idempotent (meaning that it can be safely retried if needed) and should return the identifier to be used when polling the result.

If your workflow is usually very fast then you could do some waiting and polling inside the REST API implementation and return the result to the client in the response of the submit work call. But if the system is overloaded or some backend system is down and the request times out, the client has to fall back to polling the result of the work.

br, Edvard

[vamsi yeluri]

This sounds good. Thank you