Service Bus Claim Check API App for Logic Apps

This blog posts explains how you can use this pattern within Logic Apps to send/receive large messages to/from Azure Service Bus queues.

Claim Check Pattern

The claim check pattern is described over here. The pattern aims to reduce the size of the message being exchanged, without sacrificing information content. In a nutshell, this is how it works:

1. The sender uploads the payload in an external data store, to which the receiver has also access.
2. The sender sends a message, that includes a reference to the uploaded payload, to the receiver.
3. The receiver downloads the payload, using the reference extracted from the exchanged message.

A real-life example of this pattern is the way WeTransfer is used to email large data.

1. The sender uploads the large data to the WeTransfer data store
2. An email, including a download link, is sent to the receiver
3. The receiver clicks the download link and receives the large data

Claim Check API App

Logic Apps and Azure Service Bus work perfectly together. If we can overcome the message size limit of 256kB, a whole bunch of new scenarios reveals. Azure Blob Storage can perfectly take the role of external data store and we can leverage its SAS tokens to give read access to the receiver.

As a proof of concept, I created a custom API app that provides this functionality. You can view and download the code here. This page also includes instructions on how the deploy and configure this API App. Are you new to creating API Apps for Logic Apps? Definitely check out this post that explains how to create a custom polling trigger and how you can leverage the cool TRex library.

This is how the API App implements the claim check pattern:

1. The sending Logic App uploads the payload to blob storage and assigns a read-only SAS policy
2. The sending Logic App sends a message to a service bus queue, containing the blob URI (including SAS token) in the ‘claimcheck-uri’ header.
3. The receiving Logic App receives the message from the queue and retrieves the blob via the URI provided in the ‘claimcheck-uri’ header.

The custom API App contains several actions and triggers. The ones relevant for this post are Send Message to Queue and Receive Message from Queue.

Send Message to Queue

The user experience of this action is very similar to the default Service Bus action. However, under the hood, the claim check pattern is applied. The following parameters are available:

• Content: Content of the message.
• Content Type: Content type of the message content.
• Queue Name: Name of the queue.
• Properties: Message properties in JSON format (optional).
• Scheduled Enqueue Time: UTC time in MM/dd/yyyy HH:mm:ss format (optional).

Receive Message from Queue

This polling trigger is used to receive messages from the queue. When there are still messages available in the queue, the trigger will fire continuously, until the queue is empty.

As an output, this trigger provides the message content (retrieved from blob storage), the content type and the message properties. The lock token must be used to explicitly complete the message in the Logic App, as this is required to ensure at-least-once delivery.

The API App provides also a variant on this trigger to retrieve multiple messages from the queue within one batch.

Conclusion

API Apps are very powerful extension points to Logic Apps. In this scenario, it helped us to overcome the Service Bus message size limitation of 256kB. By implementing the claim check pattern with Azure Blob Storage, we are now capable of exchanging payloads up to 50 MB, which is the current Logic Apps message size limit!

Hope you enjoyed this one!
Toon