The LDQ allows applications to record data that can be read by a receiving application (the pull principle) You should ensure when reading the data that it can only be called once and in the order of its creation (exactly once in order). The LDG is accessed in accordance with the FIFO principle (first in, first out).
The LDQ is particularly useful, for example, if you use mobile clients to be able to call data as and when needed from the relevant server.
The LDQ organizes the different receivers using queues. Administration and monitoring are based on these queues. You can create one or more queues for a client, but different clients cannot use the same queue.
The LDQ provides the developers with an API, which is used to allow the data to be recorded by the caller and then later to be read by the called application or the framework layer for a generic solution (for example, Mobile Infrastructure).
The API can only be used locally. The data to be recorded is transferred in the form of a string (character or binary).
Since recorded data can also be defined for multiple clients, the LDQ ensures that the data is stored only once and the correct references are made to this data in the queues.
The queues are independent from one another. This means that the data can be read exactly once in the order in which they are recorded, based on one queue. There are no implicit data dependencies between various queues.
The LDQ replaces the functionality previously provided by the qRFC No Send scenario. The qRFC No Send scenario continues to be supported, but we recommend that you use the LDQ because it is based on a more efficient data model.
For more information on the LDQ, see: