Skip to Content

This blog describes the checks available in Queue Monitor, which will be available for customers with the 15-October-2017 release. It describes the where-used feature and the consistency checks, when to use them and what to do in case inconsistencies are detected. It also gives some guidance on the resources used in the JMS broker and the monitoring options for them. The Queue Monitor and it’s features are available for SAP Cloud Platform Integration customers with an Enterprise Edition license.

Checks in JMS Queue Monitor

To be able to operate your JMS scenarios (as described in the Blog ‘Configure asynchronous Messaging with retry using JMS Adapter’)  and the JMS queues used within, it may be necessary to know which queues belong to which scenarios/integration flows, which queues are not used anymore and how much of the capacity in the JMS instance is used. It may also be required to check if there are integration flows using JMS or AS2 adapter deployed, but the queue configured is not available (anymore) on the cluster.

To help you analyzing the queues available on your cluster and cleaning up unused ones, some checks were introduced.

(Consistency) Checks

The checks can be found in the ‘Manage Message Queues’ monitor in the actions area in the master view. Select ‘Check‘ to trigger the execution of the consistency checks.

There are two areas analyzed within the check execution:

  • Queues that are not used by any of the deployed integration flows
  • Queues that are referenced by deployed integration flows, but do not exist

In case no consistency issues are found you will get an information that no unused or missing queues exist. This would be the result you should target for:

Queues not used anymore

As described in blog ‘JMS Resources and Size Limits’ there are limited resources on the connected JMS messaging instance, which is used in asynchronous messaging scenarios using JMS. The Enterprise License allows you to use only a certain limit of queues, storage and connections on the messaging instance. The limits are described in more detail in blog ‘JMS Resource and Size Limits in CPI Enterprise Edition’. If the queue limit is reached you cannot deploy any new integration flows using JMS or AS2 anymore. So, you need to manually delete queues that are not needed anymore, meaning queues, where the integrations flows were undeployed already.

The check helps you to identify such queues. In the results screen, under ‘Queues that are not used by any of the deployed integration flows’, all queues, that are not used in any of the deployed integration flows are listed. In addition, the number of messages within this queue is shown.

Selecting the queue opens the respective queue in the Message Queues monitor. There you can check the messages, maybe download them, if required, and delete the queue.

Important: If there are still messages available in the queue, carefully check with the scenario owners if the queue with all the messages is still needed or can be deleted. Maybe the consuming flow was just undeployed and is expected to be deployed again to process the messages.

Look-Ahead: Unreferenced queues without messages will be deleted automatically with one of the next updates. The blog will be updated with details as soon as this gets active. Deletion of unreferenced queues still containing messages will not be done automatically, as it would mean data loss.

Not Existing Queues

The second category, ‘Queues that are referenced by deployed integration flows, but do not exist’, lists the integration flows using JMS or AS2 adapter deployed on the tenant, where the configured queue is missing. This can happen, for example, if someone manually deleted the queue in the Message Queues monitor.

The result screen shows the queues that are missing together with the link to the respective integration flow using this queue.

Selecting the link to the integration flow opens the integration flow in read only mode, to enable you to check the scenario using the queue.

In the runtime these integration flows will end with an error accessing the queue, as it does not exist. So, it is urgently required to get the queue back. This has to be done by redeploying the respective integration flow.

Where-Used

During operation of your scenarios it may happen that messages pile up in one queue, and you want to get more details about the scenario, and want to analyze, why the messages are not fetched. For this specific use case, you can use the Where-Used check. It can be found in the ‘Manage Message Queues’ monitor in the actions area in the master view. Select the queue you want to execute the check for and select ‘Where-Used‘ to trigger the evaluation.

The result screen lists all integration flows, which use this queue. Selecting the link to the integration flow opens the integration flow in read only mode to enable you to check the scenario using the queue.

Used Capacity

As already mentioned before, the JMS instance only provides restricted resources for queues, connections and capacity. The capacity used in the JMS instance can be monitored in the ‘Manage Message Queue’ monitor. At the top of the monitor the used and available capacity are shown.

In the master view of the monitor you see how this capacity is distributed between the queues. The Size column provides the size of all messages in this queue.

In case the capacity reaches 80% of the available capacity the message will appear as orange warning message, if 100% are reached it will appear as red error message.

You need to make sure not to hit the limit as otherwise no message can be processed anymore. Make sure no messages are stuck in the queues.

Look-Ahead: It is planned to add details of additional limited resources in the monitor (e.g. connections, transactions). The blog will be updated with details as soon as this gets active.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply