Hi Rafael,

InterApp calls work by sending data from an element to another element or from a script to an element. They use an element’s parameter behind the scenes to achieve this.

Then the Processing QAction reads it and deserializes the data (you can read more about that in InterApp classes | DataMiner Docs)

A queued QAction will be executed asynchronously, i.e. the QAction is triggered and set in the background.

When using this together with reading parameters, we must be careful to ensure data consistency as an asynchronous QAction will not wait for the logic to finish before the next QAction can run.

With this said you should ensure that you implement the relevant locking and you read the parameter for the incoming request as soon as possible (possibly leveraging the inputParameters option.

For the response side of things locking should be less of a concern since subscriptions are used together with the response’s Guid by the listening side so it should not be an issue.

In essence, there should not be an issue as long as you take the necessary precautions with locking and reading the data as soon as possible to keep data consistent.