It’s our finding that starting a Workflow from a Flowservice is pretty slow. It takes at least one second only to startup. Execution speed itself is ok.
To start a Workflow from a Flowservice we call the Workflow’s webhook with a HttpRequest.
To start a Flowservice from a Workflow we use option to drag one from the pallet into the flow.
Does someone else recognise this. And maybe has a solution or ideas for optimization?
Hello Bastiaan,
REST API could be one more option , where you can call workflow/flowservice inside API definition itself.
REST connectors is an another option to rest’‘ify’’ your workflow and call it inside flowservice.
HTH.
Bharath
Hi @bastiaanr ,
there are multiple factors that you not mention than influence this. Also you need to consider the overall architecture. WorkFlow and FlowServices are two different worlds and also engines to execute.
I can also see your question: What other factors? 
In your described case you would call the workflow as a “webhook”. This can have two ways to implement SYNC and ASYNC and depending on the same you have again different execution engines and behavior. In case of ASYNC your request to execute will be put into a queue and taken from there. This can take some time of 1 or more seconds in worst case. If would be good if you share some insights in what you try to do.
The other factor is data size and complexity. For sure when you would have some reasonable amount of data, to transfer the same to the workflow engines and start the respective instance for processing also takes some time. This include data parsing etc.
Last but not least your call needs to be authenticated. So part of the time you claim for as “latency” also goes to your related authentication. BasicAuth with login / password would be the slowest option. All of those components together easily explain the delay you mentioned.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.