This blog describes the checks available in the Queue Monitor, which is available for customers with Enterprise Edition. It describes the where-used feature and the consistency checks, when to use them, and what to do if inconsistencies are detected. It also gives some guidance on the resources used in the JMS broker and the options for monitoring them. The Queue Monitor and it’s features are available for SAP Cloud 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 them, you might need to know which queues belong to which scenarios/integration flows, which queues are no longer used and how much of the capacity of the JMS instance is used. It may also be necessary to check whether any integration flows using JMS or AS2 adapter are deployed, but the queue configured is not available (or no longer available) on the cluster.

To help you analyze the queues available on your cluster and clean up any unused queues, some checks have been 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 execute the consistency checks.

With the 30-September-2018 release the UI experience in the Message Queues monitor was improved. Now the Check action can be found in the upper right corner of the monitor:

Two areas are analyzed by these checks:

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

If no consistency issues are found you get an information message that no unused or missing queues exist. This is the desired result:

Queues No Longer Used

As described in the blog JMS Resources and Size Limits there are limited resources on the connected JMS messaging instance, that is used in asynchronous messaging scenarios using JMS. The Enterprise License allows you to use only up to a certain limit of queues, storage and connections on the messaging instance. The limits are described in more detail in the 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 no longer needed, that is queues, where the integrations flows have already been undeployed.

The check helps you to identify such queues. On 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, download them, if required, and delete the queue.

Important: If there are still messages available in the queue, be sure toy check with the scenario owners whether the queue (and all its messages) is still needed or whether it can be deleted. It could be that the consuming flow has just been undeployed and will be deployed again to process the messages.

Nonexistent Queues

The second category, Queues that are referenced by deployed integration flows, but do not exist, lists the integration flows using the JMS or AS2 adapter deployed on the tenant, for which the configured queue is missing. This can happen, for example, if someone has 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 that uses 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.

At runtime, these integration flows will produce an error when they attempt to access a queue, that does not exist. Therefore, it is crucial that you restore the queue. You do this by redeploying the respective integration flow.

Where-Used

During operation of your scenarios, you might find that messages are piling up in one queue, and you want to get more details about the scenario so that you can analyze, why the messages are not being 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 check and select Where-Used to trigger the evaluation.

With the 30-September-2018 release the UI experience in the Message Queues monitor was improved. Now the Where-Used action can be found as single line action for the queue you want to trigger the where-used search:

The result screen lists all integration flows, that 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 that use the queue.

With the 30-September-2018 release, it is also shown if the integration flow is writing to the queue (for example by the JMS receiver adapter), consuming from the queue (for example by the JMS sender adapter) or both, writing to and consuming from the queue in the same integration flow (for example by the XI or AS2 adapter or if JMS receiver and JMS sender adapter are in the same integration flow).

Used JMS Resources

As already mentioned, the JMS instance only provides limited resources for queues, connections, and capacity. The used JMS resources in the JMS instance can be monitored in the Manage Message Queue monitor.

At the top of the screen you see the status of the JMS resources:

Selecting Details shows the details of queues, capacity, transactions, providers and consumers:

The JMS resources and required actions in case they get critical are described in detail in blog ‘JMS Resource and Size Limits’.