Monitoring Message Packaging

The aim of monitoring the processing of message packages is to use the data collected to take measures, for example to improve performance. To monitor message packaging you use the package statistics, which you must first configure.

You can log the errors that occur for the purposes of troubleshooting and then start messages with errors again.

You use transaction XMSPKSTATCNF to configure package statistics.

1. Call transaction XMSPKSTATCNF and turn on the package statistics.
   Note

   Only activate package statistics in a productive system when you need to analyze an error situation.

2. Select the level at which you want to collect statistics data.
   • If you set the level to low, data is collected for each package that is created.
   • If you set the level to high, data is collected for each individual message in a package.
     Note

     For performance reasons you are recommended to set the level to low.

3. Specify the length of the name of each queue.

   All queues that can be configured to create message packages are taken into account.

   • If you select Full, the full queue name is taken into account when data is collected. This means that it is clear exactly which packages are processed in which queues.
   • If you select User-Defined, only abbreviated queue names are used when data is collected. It is then not possible to distinguish between individual queues.
     Note

     To receive the largest amount of information you must use the full queue name.

4. To check the status of data aggregation and of the aggregation job, choose the Aggregation tab page.

   The statistics data shows whether individual or aggregated data is available for a particular time period. You can refresh the display and you can delete all existing data.

   The aggregation job aggregates the available individual data. It is preconfigured and can be deleted and created again as required. The date and time of the last and next execution of the job are displayed.

   The current status of data aggregation is only green when the status of both the statistics data and the aggregation job are also both green, that is, when aggregated data is available and the aggregation job has been created.

   If individual data is available that has not yet been aggregated, the status is yellow and a corresponding message is displayed.

5. To execute the aggregation job on demand, irrespective of when it is scheduled, choose Execute Aggregation.
6. To check the status of data reorganization and of the reorganization job, choose the Reorganization tab page.

   The statistics data shows whether there is any aggregated or individual data from a particular period of time that can be deleted during the next reorganization run. You can refresh the display and you can delete all existing data irrespective of any reorganization job that is scheduled.

   The reorganization job deletes all data that can be deleted. It is preconfigured and can be deleted and created again as required. The date and time of the last and next execution of the job are displayed.

   The current status of data reorganization is only green when the status of both the statistics data and the reorganization job are also both green, that is, when there is no data that needs to be deleted and the reorganization job has been created.

   If data to be deleted exists that has not yet been deleted, the status is yellow and a corresponding message is displayed.

7. To execute the reorganization job on demand, irrespective of when it is scheduled, choose Execute Reorganization.

You use transaction XMSPKSTATMON to monitor package statistics.

1. Call transaction XMSPKSTATMON and enter the required selection criteria to restrict the monitoring period and the queues to be monitored.
2. Choose Execute.

   The first view displays a list of aggregates for each time interval and queue during the specified time period. The following information is displayed for each aggregate:

   • Configuration type used
   • Number of processed packages
   • Average number of messages per package
   • Average package size
   • Number of packages created due to a timeout, that is, packages created without the maximum number of messages having been reached.
   • Number of packages with errors

   The total number of packages and messages is also displayed.

3. To display details about a particular aggregate, select the relevant entry and choose Display Events.

   This displays, among other things, events (checks) that result in messages being excluded from package creation, as well as the number of messages removed from package creation as a result of these checks.

4. To display detailed information for a particular aggregate, select the corresponding entry by double-clicking it.

   The second view lists data for each package. Here you can identify packages with errors (status red), for example.

   Furthermore, the number of messages in the package, the package size, and the ID of the leading message is displayed.

5. To display details about a particular package, select the relevant entry and choose Display Events.
6. To display information about the individual messages in a particular package, select the corresponding entry by double-clicking it.

   The third view lists the IDs of the messages involved in the order in which they occur in the selected package.

   Note

   This third view is displayed only when the level in the package statistics is set to high.

7. For more information about a particular message, select the corresponding entry by double-clicking it.

   The system navigates to the monitor for processed messages , which gives you more information about this message.

You can log errors that occur when packages are being processed.

1. Choose Configuration → Configure Integration Engine.
2. Under Parameter Categories select the RUNTIME category.
3. Add an entry for the RUNTIME category with the parameter LOGGING_AMF_ERR. Set the current value to 1 (logging activated), and the default to 0 (no logging).

   When the configuration parameter LOGGING_AMF_ERR is active and the processing of a message in a package fails, an error message is created with the package ID as the message ID.

   Note

   You must only use this parameter in a development system or for the purpose of analyzing an error situation because it is possible that any errors that occur will be reported more than once.

If an error occurs that can be corrected automatically, the system determines which is the message causing the error and processes it individually. The package is then processed again during the next processing run.

If an error occurs that cannot be corrected automatically, the package is split up and the first message in the package is processed again.

It is still possible to manually restart individual messages.