Thanks to my colleague Eldert Grootenboer, I have written this post on how to combine singleton and concurrent processing in a queuing solution. The trick is to use servicebus sessions. When sending messages to the servicebus, you can set SessionId equal to the unique Id of the client. On receiving messages from the servicebus, SessionId is set to Next Available. This way, different clients are processed concurrently and mulitple updates for the same client are processed one by one. You want to process different client concurrently for reasons of performance. You want to process client updates one by one, because you want to keep the ordering of client updates, so that more recent client updates are not overwritten by older client updates.
Sending messages to the ServiceBus:
When sending messages to the servicebus, don’t forget to base64 encode the messages:
“SessionId”: “@variables(‘RelatieNummer’)” }
Receiving messages from the ServiceBus:
To get values from the servicebus message received, you can use the following syntax, with [xpath] being equal to the xpath statement: @xpath(xml(base64ToBinary(triggerBody()?[‘ContentData’])), [xpath])
And then the final step. Messages are not actually removed from the servicebus after reading because of the peek-lock construct. After successful processing always call ServiceBus Complete.
Lock token en SessionId are taken from the trigger (see: receiving messages from the servicebus).