Message Packaging - BIT480 - PI

To understand how message packaging works, you need to know how message processing generally works in an SAP NetWeaver PI system.

1. If a message arrives at the Integration Engine, it is persisted in a message queue.

2. Then, the message enters the pipeline process.

3. After the process step is finished, it is stored in the message queue again.

4. The last two actions are repeated for each pipeline step until the message is eventually delivered to the receiver.

Every single message is treated in isolation. That means that every time a message is persisted in the message queue, it is also stored at database level. Additionally, every time the message resumes execution in a pipeline step, the required

113

programs have to be loaded into the ABAP memory (rolled-in) and also have to be removed from memory after execution. Having to repeat these steps over and over for every single message results in significant resource consumption.

Message processing is improved by using a packaging concept.

• Several messages are received at the message queue.

• The scheduler starts message processing and checks if there are any additional messages that can be processed as well.

• If so, they are grouped and processed together in the same package, loading the ABAP programs into memory. After the pipeline process is executed for all messages of the group, they are updated and committed to the database as a whole.

• This procedure is used for every pipeline step, until the messages can be delivered to the receiver.

This is a far more efficient way of message processing in comparison to the standard processing technique, since context switch operations and database access are reduced drastically.

Message Packaging brings several advantages.

• One call is able to process several messages, thus reducing overhead which leads to less context switch operations.

• All changes during a message processing step are committed at the same time in one single call.

• From the application perspective, there is no change at all, single messages are kept on an atomic level as before. This means there is no impact in any monitoring transaction. Furthermore, if a message inside the package generates an application error, the package is broken down into single messages and is executed in isolation.

Figure 81: Message Packaging Feature Overview

Packaging is based on the integration engine message queues. This means that steps that read and process messages from the queues are able to be packaged.

Therefore packaging supports asynchronous messages with qualities of service exactly once (EO) and exactly once in order (EOIO) in the following steps:

• Sender and receiver proxies

• Integration Engine internal steps (like receivers determination or mapping)

• Receiver IDocs

• Receiver Adapter-Engine-based adapters

Figure 82: Message Packaging Scope

To activate packaging, you have to start to Integration Engine administration transaction SXMB_ADM.

Then execute “Integration Engine Configuration”.

Select the category “RUNTIME” and execute “Configuration”.

Add a row for the parameter “PACKAGING” and set the current value to 1.

Save to activate changes.

115

Figure 83: Global Configuration - Activation

“Configuration Types” define the way packaging will be working for either general or specific service interfaces. Use transaction SXMS_BCM to access the

“Configuration Types”.

There are two built-in configurations. One is called “DEFAULT” and is the configuration delivered in the standard product to execute the different steps. You can create as many configurations as you want and configure their use for each filter as defined in transaction SXMSIF.

The other built-in configuration is called “NO” and should be used to avoid packaging. It might be used for particular scenarios where packaging makes no sense, even when packaging is globally switched on.

Each “Configuration Type” has three parameters:

The “Wait Time” parameter specifies how long a running process has to wait if it did not reach the maximum number of messages configured for this type.

The “Number” parameter specifies the maximum number of messages that should be collected prior to starting the message selection and size analysis.

It corresponds to the number of messages for each package.

The “Maximum package Size in KB” parameter describes the size of the package measured in KB.

Figure 84: Global Configuration – “Configuration Types” Customizing

“Configuration Types” have to be assigned to either global package configurations or specific package configurations. Run transaction SXMS_BCONF to carry out global and specific configuration:

For the global configuration, select “Global Package Configuration” in the tree on the left. Specify the desired “Configuration Type” for the applications:

“IS_IN” for inbound processing or “IS_OUT” for outbound processing. If you don’t perform any configuration, the “DEFAULT” configuration type will be automatically used. You will also use the other applications for acknowledgement handling, ccBPM packaging and sender proxy on application system level.

117

Figure 85: Global Configuration – “Configuration Types Usage” Customizing How are packages built and what is the relationship with the “configuration types”

parameters?

Assume that the package creation has two major blocks or procedures. The first procedure is used to read the queue. When a message from the queue starts to process the first function module, first of all, it checks if there are more messages in the queue, if so, they are also read considering the “Maximum Number” for the

“Configuration Type”.

Should the number of messages not reach the “Maximum Number” for the

“Configuration Type” in use, the process is set to sleep the number of seconds specified in the “Maximum queue Time” parameter.

Afterwards, this package will appear in the monitoring transaction as “Timeout”

since this process had to be set to sleep a certain amount of time, trying to enlarge the number of requested messages by checking the queue for additional messages.

The second block analyzes the set of messages previously retrieved. It checks the message attributes for every message if a message should be assigned to the package, it is assigned. Afterwards, the process makes sure not to exceed the

“Maximum package size” configured, if not it keeps on reading the following message from the set. After reaching the limit or retrieving all the messages, the package is set to execution.

Also, special conditions apply if the parameters are configured to 0. If there is no “Maximum Queue Time”, there will be no further aggregation if the package sizes are smaller than desired (from the number of messages point of view). If

“Maximum Number” or “Maximum Package Size” are set to 0, the corresponding limit is not checked and everything is processed.

Figure 86: “Configuration Type” Influence in Package Creation Process

• Max. Queue Time = 0:

No additional accumulation.

• Maximum Number = 0:

The whole queue content is processed.

• Max Package Size = 0:

No size limit.

If you want to create a new “Configuration Type” either for a general or interface specific reason (as simulated here), access transaction SXMS_BCM and switch to Edit Mode.

119

Figure 87: Creating Component or Interface-Specific Configurations Types I Hit “New Entries” and create a meaningful name for your purpose. The figure above and the one below show a configuration example. Here, it is assumed there is no need for aggregation, since each time a message is processed, there are a lot of messages already waiting in the queue, so the “Wait Time” is set to 0 seconds.

Another assumption for the example was that the number of average messages required to create the desired message size will contain about 1,000 sales orders in it, thus the “Number” parameter is set to 1,000. Finally, the default package size is kept to 1MB.

Figure 88: Creating Component or Interface-Specific Configurations Types II The last step in the interface-specific “Configuration Type” creation is to

configure the package creation. Start transaction SXMS_BCONF again. Now, mark the “Inbound Processing from Request Packages in IS” row. Double-click on “Specific Package Configuration”. Create a new entry (not shown here) and specify the “Inbound Processing from Request Packages in IS” application and the

“Portal_SalesOrder” Sender ID. The “SLS_ORD” configuration type has to be used. Repeat the configuration for the “IS_OUT” application to package also the outbound processing. Save to activate the interface-specific configuration type.

From now on, every time a sales order appears in the integration engine, it will be packaged according to the previously defined rules.

121

Figure 89: Creating Component or Interface-Specific Configurations Types III When a message goes to a business system through a proxy, the system will automatically control if packaging is supported by the target system by taking a look at the software component versions for the Business System described in the SLD (System Landscape Directory); since release 7.0 SPS 12 packaging is supported.

In contrast, if the Communication Component is a Business Component (what we used to call “Business Service” in XI and PI), there is no information at SLD level.

For that reason, table SXMS_LCR_VERS was created. Using transaction SM30 (the typical customizing table maintenance transaction), you can create an entry for the Business Component and specify the current version.

Figure 90: Incoming and Outgoing Proxy Configuration for Business Component

Regarding the IDoc packaging functionality, we can briefly say that it has become obsolete, since message packaging generates the same benefits and has a broader scope.

The recommendation is to deactivate the IDoc packaging when you switch on message packaging. You will not loose any functionality and you can also monitor the message packages using the normal IDX5 transaction.

• If you are currently using IDoc packaging, replace it by message packaging:

– Remove the IDocs packaging configuration (use transaction SXMSFILTER)

– Turn on message packaging

The system will package the IDocs as before.

• Use transaction IDX5 to monitor the packaged IDocs.

123

Figure 91: IDocs: Message Packaging Versus IDoc Packaging

How will we monitor the packages or how will the packages affect current message monitoring?

Packaging has no impact on monitoring; furthermore, if an error occurs inside the package, the messages will be treated as before, losing the packaging benefits but without impact at processing or monitoring level. Obviously, if the quality of service is Exactly Once in Order, the queue will have to be stopped as before.

For development system or error analysis, you can switch on the Integration Engine parameter “RUNTIME-> LOGGING_AMF_ERR” in transaction SXMB_ADM→ Integration Engine Configuration, to receive some packaging information in transaction SXMB_MONI.

In the runtime properties of each particular message, the field

“EOReferenceOutbound” will have the package ID used for that message.

To configure packaging monitoring, use transaction XMSPKSTATCNF, which corresponds to report SXMS_BLK_STAT_CNF and allows you to configure how statistical information will be collected, the level of aggregation desired, and the reorganization information.

Figure 92: Message Packaging Monitoring – Configuration

Message Packaging ...

... Increases throughput for asynchronous messages on Integration Server ... Is switched on globally, but can be configured specific to a scenario ... Provides detailed Monitors

... Requires virtually no visible changes in monitoring and error handling.

In document BIT480 - PI – Operations(Col74) (Page 121-133)