The Claim Check design pattern is a commonly practiced method through which integration products or messaging systems can efficiently transfer large payloads between systems. Typically, integration products like ACE operate most efficiently when the flowing messages are of a consistent similar size. Introducing occasional large messages into an architecture like this, can potentially risk exceeding hardware limits and in extreme cases can sometimes degrade the performance of the entire system. The Claim Check pattern avoids these problems and enables large pieces of data to be successfully transferred between endpoint systems whilst avoiding the need to parse the payloads within the intervening middleware product between the endpoint systems. A connector communicates with the application endpoint system where the data originates and generates a claim-check token for the payload. This claim check token can then be carried through the middleware and when required it can then be redeemed and the data directly streamed to the second application endpoint system.

A good analogy for this architectural approach is the process you follow when taking a flight from an airport: You carry your heavy luggage to the check-in desk and exchange it for a "token" (normally a sticky label carrying a unique identifier). Your suitcase is then transported to your destination on your behalf where you can retrieve it from the luggage carousel with your unique token safely avoiding any potential accidental mix-ups.

• Node 1: Represents an Input node which triggers the message flow. In this example, this could be a non-Discovery connector node, or it could be a Discovery connector node, but importantly this node itself is not directly involved in the claim check (ie it does not generate a claim check token at all). The Logical message tree which is propagated to Node 2 can be of any shape as it is not directly involved in the large data handling and it does not carry a claim check token.
• Node 2: Represents a Discovery Connector Request node, which notices that data is available in External System A, and generates a claim check token which is passed in the Logical tree for use by another Discovery Connector downstream
• Node 3: Represents a Discovery Connector Request node which receives an inbound Logical message tree containing the claim check token created by Node G. This pointer is used to take data directly from External System A and stream it into External System B, without having to spend CPU cycles on creating the Logical Message tree, and without having to spend memory for making the data available to other Toolkit message flow nodes.
• Node 4: Represents a Toolkit transformation node that converts an inbound Logical message tree into an outbound Logical message tree which may have a different shape in terms of both a different message domain (eg JSON/BLOB/XMLNSC/DFDL etc.) and also potentially a different shape with different fields with different values.
• Node 5: Represents a Toolkit Output node (non-Discovery connector) which serializes the inbound Logical tree and sends it to the External System C.

The following Discovery Connector Request nodes have been enabled to support the claim check pattern of operation in ACE 13.0.7.0:

• Amazon S3 Request
• Dropbox Request
• Freshservice Request
• Google Analytics Request
• Google Cloud Storage Request
• Microsoft Azure Blob storage Request
• Microsoft Azure DevOps Request
• Microsoft Azure OpenAI Request
• Microsoft SharePoint Request
• Microsoft Teams Request
• Salesforce Request
• SAP S4 Hana Request
• Slack Request

When the message flow developer adds a Discovery Connector Request node into a message flow, on the node you will find a new properties tab with Claim Check Options. The Binary Data Handling property offers two alternate values:

• Select Create claim check token to specify that a claim check is to be used. If you select this option, a claim check token will be created by the node and will be passed through the message flow. The data will be streamed directly using the connectors in communication with the endpoint applications, without it being necessary to parse the data into the message flow. The claim check token is what is passed down the flow to any subsequent wired message flow node. If a message tree containing a claim check token arrives at a traditional Toolkit output node, the claim check token is redeemed automatically by the node and the data will be streamed into the message flow and written out. If you were to add a downstream Trace node after the connector request node, the generated Trace will show that a claim check token was flowing.
• Select Stream data into message tree to specify that the data is to be streamed in the message flow. When data is requested by a discovery connector node in the flow, the data is downloaded into memory and is streamed in full through the flow in the message body. That data is then available to be accessed by subsequent nodes in the flow. You can see the data in full in a Trace node in the flow or in the flow debugger.

To learn more about this feature, check out this page in the documentation.