Show TOC

Procedure documentationHandling Large Messages Using Claim Check Pattern Locate this document in the navigation structure

 

Messaging is a reliable and fast way to transmit information, however, the large amount of data in messages decreases the efficiency of a system. Claim Check pattern reduces data volume by filtering the message content. It stores the complete message information in a persistent store, from where it can be retrieved later using a unique key. Claim Check pattern solves the problem of moving large amounts of data across the systems.

When a message with large data arrives, the Claim Check component, generates a unique Claim Check key for the information. The data required for processing in BPM is extracted from the original large message to create a smaller message. The Claim Check key is added to the smaller message. The Claim Check component then stores the large message in a persistent store and associates it with a unique key. The BPM processing is done efficiently using a smaller message and when the complete message is required, Claim Check key is used to retrieve the data from the store.

In Process Orchestration systems, the unused data of large messages in the memory reduces their efficiency. The efficiency improves if the process contains a smaller message as most of the BPM processes require only a limited content of the individual PI messages. Using the Claim Check pattern, you can replace the message content with a Claim Check key, which is used to retrieve the entire message content later. The original message is put into some storage temporarily while intermediate steps are provided with smaller message along with some key, which is used to retrieve the original message later for processing.

You use the NW PI Message Store, which gives you control on the life cycle of the messages stored in Claim Check scenario. You retrieve messages and change the status of the message. The PI’s standard delete job automatically deletes those messages, which are scheduled for deletion.

Prerequisites

You have ensured that you have a PI-CP system.

Procedure

  1. Defining the Interfaces

    The original large message has all fields, however, you have to define the lean and aggregated message to implement the Claim Check pattern. The smaller lean message has basic fields from the large message that are required for processing and one additional field to establish the link between the large and lean message during retrieval. The Aggregated message has the collection of related smaller messages with the same correlation key. You use the SAP NetWeaver PI Enterprise Services Repository to model the interface.

    For more information on how to create a new smaller interface with fields required by BPM from your existing large interface, see also Working with Process Component Architecture Models.

    Note Note

    The new smaller interface should have the minimum required fields from large message. You must also keep a field in the new interface, which can be used as a link between smaller interface and original large message, for example PI Message ID

    End of the note.

  2. Creating the PI Operations Mapping

    You create two mappings to execute the Claim Check pattern. The first mapping extracts a few fields from the large PI message to small message. The second mapping merges several individual messages into one large aggregated message.

    For more information, see also Mapping Messages to Each Other Using Mapping Objects.

  3. Configuring Integration Flows and an Adapter Module

    You must configure the integration flows to use smaller message as the receiver channel for integration flow. The integration flows must be enhanced using the SCPMappingBean adapter module at the receiver channel. Adapter modules are stateless EJB, which are used to enhance adapters for special data handlings. You can define the generic modules in the module processor with each adapter. The module forwards the message to the adapter, which transfers the message to the connected system. The adapter addresses the module processor in the form of a bean for transferring the message object as a PI message or its own format. The SCPMappingBean adapter module has the following module parameters:

    • MappingID: It is the object ID of the PI operation mapping in the ESR, which is used for the transformation of larger message to smaller message.

    • Persistuntil: It has the estimated time period in days for which the large message is to be stored in the message store.

      Note Note

      Persist until value does not guarantee that the message will be deleted immediately after the specified time is elapsed.

      End of the note.

    • xpath: It is the field of the lean interface in which the message ID will be placed by the bean. It contains the link (an ID), identified to connect the large and small message for retrieval of original message later, for example xpath of PI Message ID.

    For more information, see also Configuring Integration Flows and Adapter Module.

  4. Configuring BPM Processes using Web Services

    The SAP NetWeaver BPM process uses the smaller message for processing, however at the end you will need the original large message for further processing. You retrieve payload using two Web services.

    The first Web service calls the OriginalMessageAccessorBean at the end of the BPM process to retrieve those messages from the message store, for which the messageID has been handed over as a parameter. You can configure it via input and output mapping:

    1. Input mapping:

      • MESSAGE_ID_LIST: List of Message IDs to be read from the message store.

      • PROCESS_INSTANCE_ID: Process Instance ID of the process calling the bean. It is used for tracing and logging for supportability.

      • OPERATION_MAPPING_GUID and SWCV_GUID: GUIDs of the associated operation mapping in the ESR, created from the list of large messages to the aggregated message.

    2. Output mapping:

      • Cast the result XML-string to the target data object.

    The second Web service calls the MessageStatusUpdaterBean after the step for the retrieval of all messages. You can configure it via input mapping.

    1. Input mapping:

      • MESSAGE_ID_LIST: List of Message IDs to be read from the message store

      • PROCESS_INSTANCE_ID: Process Instance ID of the process calling the bean. It is used for tracing and logging for supportability.

    For more information, see also Configuring BPM Processes Using Web Services.