This week we’ll study the pattern known as Claim Check.
When do I use this pattern?
Content Filter pattern filters out unnecessary elements or items from the payload. What if this filtered out information is required in later steps? Claim Check pattern can be used to extract the filtered out information. In Claim Check pattern, payload is stored in a persistent location before filtering out. The unique key to retrieve such stored payload is attached to the message so that any future steps requiring the filtered information may retrieve the information.
Claim Check in CPI
In CPI, Claim Check can be implemented with use of Data Store or Multicast components.
Method 1: Data Store
Claim Check using Data Store
The Integration flow is similar to one used in Content Filter pattern with the addition of Claim Check steps.
Here, the integration flow starts immediately using Timer Start Event, gets the order number 10248 from OMS (Northwind) using Command Message pattern, writes the Order to Data Store, applies Content Filter, maps the payload to IDoc format using Message Translator pattern, sends the IDoc to ECC. Now, the payload contains response from the ECC. However, reporting system wants full payload containing Order Information. So, we retrieve the full Order using Get operation stored previously and send it to Reporting system using HTTP Receiver Adapter.
Here’s the configuration of Write operation:
Here’s the configuration of Get operation:
Here, the OrderID, the unique key for order, acts as unique key in Data Store. Using the OrderID alone, entire Order information can be retrieved from Data Store.
Method 2: Sequential Multicast
Claim Check using Multicast
Here, Integration Flow starts immediately using Timer Event and gets the Orders using Command Message pattern. The Claim Check implementation is done in Multicast alone. The Sequential Multicast causes steps on ERP branch to happen before it switches to the Reporting branch. When it switches to Reporting branch the payload before ERP branch started is restored.
In the figure Claim Check using Multicast, numbers show the steps and colours represent the content of the message; the same colour means exactly the same content. As we can see in the figure, step 6 (dark green message) happens after step 5 (light blue message), however, step 6 has the same message as step 1 (dark green message).
This behaviour of Sequential Multicast is similar to how the Claim Check works when the entire payload is stored and retrieved.
Data Store vs Multicast
So, when should I use what?
From the above table, it does looks like Data Store is winning the battle. Here’s my guideline:
Check Multicast implementation first based on the points above. Remember that the multicast implementation works well when the message stays in single flow and entire payload is required by all branches. In all other cases, use Data Store implementation.
Please let me know what you think in the comments below. Would you weigh these two approaches on any other criteria?
Hope this helps,
About the Author
More Content by Bhalchandra Wadekar