...
2.4.2 Messages collection
How to collect all messages and keep the sequence:
The actual messages have to be collected via individual API calls against the different "retrive" APIs. In order to streamline that process a "master"-retrieve API (/api/v2/availableMessages) is provided that returns a list of individual "retrieve" APIs that contain waiting messages for the retrieving registry. The availableMessages API will list per "retrive" API the sequence numbers number(s) of the waiting messages message(s) in an array.
....
Options:
to allow external registries to access those messages there are several options:
A)
"the current suggested situation":
- 1) call /availableMessages endpoint and then collect the messages from the endpoints with waiting messages
- 2) or collect messages from all endpoints and accept that some are empty
To keep the ordering (aside from timestamp) the above suggested sequence per receiving registry should be introduced.
The registries has to separate collecting from processing in order to keep the sequence of processing right.
B)
"meta-queue":
- 1) introduce the sequence per receiving registry to /availableMessages endpoint and list all messages per specific queue, not only give the sum
- 2) collect those messages based on the sequence number by going round the specific endpoints
This would allow a registry to collect and process messages in the right order without storing them locally and sort them there
C)
Each "retrive" API will have the optional parameter "sequenceNumber", that allows for an indivual collection of that soecific message. If that parameter is left emty all available messages are retrieved.
It is left for the retrieving registry to choose how to collect the messages:
A) collect an overview via the availableMessages and then collect the messages one by one in the order given by the sequence number or
B) collect an overview via the availableMessages and then collect all waiting messages and ensure the correct order of processing of the messages in the local system
C) pull all "retrieve" APIs without checking first the availableMessages APIs and ensure the correct order of processing of the messages in the local system
An additional "All-in-One Queue" is under discussion:
Such a queue would provide all waiting messages in the order of the sequence number directly as return value of the call not only the information which (sequence number) and what (retrive API) kind of messages are waiting for retrieval.
Technicaly this could be realized by"All-in-One Queue":
- provide a new endpoint that makes use of the "oneOf" tag and provides all messages for external registries
- Note: here the sequence number is not needed for ordering anymore but still needed to realize missing messages
This would allow a registry to call just one endpoint to collect all messages.
Limitations:
Option C) This option doesn't work for all applications/tooling, like defining custom API connectors in the 365 PowerPlatform. In those cases the same static structure for all call responses on a specific endpoint is not only IBP but also required.
As on WMDA side (propably) all messages are stored in one queue/store anyhow (check with Mark) options A-C) both options will only effect the exposure of the messages to the registries and not the internal workings on WMDA side.
So implementing the options next to each other might give the registries the choice to pick there prefered solution and might still be fine for WMDA?!?
Recommendation:
implement B and C
As a consequence of implementing B) all individual endpoint will have an optional parameter "sequenceNumber" that will function as a filter so that you only get the message with that sequence from the endpoint, without that parameter the endpoints will function as is.