Synchronous/Asynchronous

0
please help me to understand the microflow execution behaviour with the below option in the Microflow settings.To find out the difference between the Sync and Asyn features of the Microflow execution, calling a local API which gets the response after 5 seconds using express (nodejs) app code. In both situations (Sync and Asyn) the Microflow is waiting at the REST API call response.const express = require("express");const app = express();const PORT = 3000;app.get("/slow-endpoint", async (req, res) => { console.log("Received request, waiting 10 seconds..."); await new Promise((resolve) => setTimeout(resolve, 10000)); res.json({ message: "Sorry for the delay!" }); console.log("Response sent.");});app.listen(PORT, () => { console.log(`Server running locally at http://localhost:${PORT}`);});I understand the Taskqueues (asynchronous/parallel threads) well, but would like to know why these options are provided in the Microflow settings when a micrflow call is happened from a button in order to execute the action.Please help to understand it clearly, appreciate your patience and help.
asked
2 answers
1

Hi Boda,
The behaviour you are seeing is expected. The synchronous/asynchronous option on a button does not make the microflow itself run in the background.

With both options, the microflow still executes sequentially, so if it reaches a REST call that takes 10 seconds, the microflow waits for that response before continuing.

The difference is mainly in how the Mendix client waits for the microflow to finish. With synchronous execution, the client keeps the request open until the microflow completes. With asynchronous execution, the client does not keep the same long-running request open and instead checks whether the execution has finished.

So in your example, the REST call will take 10 seconds in both cases. The asynchronous option does not behave like a Task Queue.

If you really want the work to run independently in the background, then Task Queue is the appropriate mechanism.

A simple way to think about it is:

  • Synchronous/Asynchronous button setting = how the client waits
  • Task Queue = how the work is executed in the background

That is why your logging shows the same delay in both tests.
I hope this helps.

answered
1

Hi Santhosh,


In Mendix, Synchronous/Asynchronous, Show Progress Bar, and Task Queue are different concepts. They control how a microflow call is handled, what the user sees, and whether the work runs as a background task.


1. Synchronous vs Asynchronous

Synchronous (default)

  • The client waits until the microflow finishes executing.
  • The user may need to wait while the microflow calls an external API or processes data.
  • The next interaction depends on the microflow call completing.

Asynchronous

  • The client does not wait for the microflow's result in the same request.
  • Mendix checks the server every 10 seconds to determine whether execution has finished.
  • This can help when long-running requests encounter proxy timeouts that might cause the request to be sent again.

Important: Asynchronous does not automatically mean the microflow runs in a Task Queue or executes faster. It changes how the client handles the call.


2. Show Progress Bar

This setting controls the user experience while the microflow executes.

Option

Behavior

None

No progress indicator is displayed.

Non-blocking

Displays progress while allowing the user to continue working.

Blocking

Displays progress and prevents the user from continuing until execution finishes.

This setting does not change the microflow's business logic or make the execution faster.


3. What about Task Queue?

A Task Queue is different from the Asynchronous call type.

If your requirement is to execute a long-running operation in the background without making the user wait for the actual processing to finish, consider using a Task Queue.

For example:

User clicks button
       |
       v
Start background processing
       |
       v
Task Queue executes microflow
       |
       v
Process external API / business logic
       |
       v
Save result and update status
       |
       v
User checks the result

You can configure a microflow call to execute in a Task Queue. The application should store the processing status and provide a way for the user to retrieve the result when it is ready.


4. Which option should you use for your REST API example?

Since your example calls a REST API that takes around 10 seconds:

  • Synchronous: Use it when the user needs the API response immediately to continue the flow.
  • Asynchronous call type: Consider it when long-running requests are causing client/proxy timeout issues.
  • Task Queue: Use it when the user should be able to continue working while the API processing happens in the background.

One important point: changing the call type to asynchronous does not resolve a timeout occurring inside the external API itself. You still need to configure and troubleshoot the REST request timeout separately.


My recommendation: If the REST API response is required immediately, start with a synchronous call and configure an appropriate timeout. If the operation can finish in the background, use a Task Queue and store its result/status.


Hope this clarifies the difference.

answered