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 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 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.
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.
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.
Look-Ahead: Unreferenced queues without messages will be deleted automatically in future. The blog will be updated with details as soon as this feature is active. Unreferenced queues tat still contain messages will not be deleted automatically, however, as it would mean data loss.
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.
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.
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.
As already mentioned, the JMS instance only provides limited resources for queues, connections, and capacity. The capacity used in the JMS instance can be monitored in the Manage Message Queue monitor. The used and available capacity are shown at the top of the monitor.
In the master view of the monitor, you can see how this capacity is distributed between the queues. The Size column displays the size of all messages in this queue.
If the used capacity reaches 80% of the available capacity an orange warning message is displayed; if 100% is reached a red error message is displayed.
You need to make sure that this limit is not reached, as this prevents any further messages from being processed. Make sure that no messages are stuck in the queues.
Look-Ahead: It is planned to include details of additional limited resources in the monitor (for example: connections, transactions). The blog will be updated with details as soon as this feature is active.