Message Ops

These pages are the main operator surface for finding queues and identifying messages before taking action.

Queue explorer

The queue explorer shows queues for the selected environment and VPN, including:

• queue name
• message count
• spool usage in MB
• consumer count
• access flags for browse, payload view, resubmit, move, and delete

The queue explorer also supports:

• refresh
• pagination
• opening a scoped message search from a queue

Access flags matter because the UI only enables actions that the queue policy permits.

Unavailable queue statistics

Queue Explorer keeps permitted queues visible when individual broker statistics requests fail. Unavailable metrics display as —; healthy queues keep their current statistics. Use Refresh to retry. A queue confirmed missing by the broker remains visible temporarily while the worker refreshes inventory. Automatic reconciliation is coalesced per environment and limited to one request per minute after an attempted refresh, with no duplicate request while a sync is in progress. Administrators can still request a manual inventory refresh. Platform failures (such as a database, licence, environment access, or primary queue-list failure) continue to fail the overall request.

Message search

Message search is asynchronous. When you submit a search the API accepts it (HTTP 202) and a background worker browses the queue. The page automatically polls the search status and shows progress in the results area:

• Search accepted — waiting for a worker… (accepted/queued)
• Search running — scanning the queue… (running)

When the search reaches a terminal state (completed or failed) the results load automatically — no manual refresh is needed. A failed search shows the error message returned by the worker.

Message search runs against the selected environment, VPN, and queue. Enter a term in the primary Search messages field to search all supported fields without first deciding which broker field contains the value. Use Search in to limit the term to one or more of:

• message ID (including broker and replication-group message IDs)
• correlation ID
• destination
• message property values
• payload text

Term matching is case-insensitive and searches for the value within each selected field. The search runs in the worker and keeps the existing scan and result limits; payload results continue to use the platform’s content-read and masking controls.

Open Advanced filters to combine the term with exact filters for:

• destination
• time window
• message ID
• correlation ID
• one message property key/value pair
• payload text

Searching payload text or property values requires messages:content:read on the source queue. Without it, choose only message ID, correlation ID or destination. The API may reject a content filter even when a UI control is visible.

The primary term matches any selected search field. Advanced filters are combined with it and with each other, so every advanced filter must match. The active-criteria summary above the results shows what the worker searched. Clear Filters restores all searchable fields and removes the term and advanced filters without changing the selected queue scope. The current draft is kept only in tab memory for your user, environment, VPN and queue. Returning from message detail restores it; changing scope/user, clearing filters or reloading discards it. Links contain scope identifiers, not search predicates. Old search links do not restore or execute their embedded predicates.

The results table shows:

• message reference
• message ID
• broker message ID
• correlation ID
• destination
• timestamp

Selection and bulk actions

You can select individual results or all results on the current page (Select All Results; Clear Selection to start over), then launch one of the following workflows when the queue access policy permits it:

• resubmit
• move
• delete

These workflows are asynchronous. Submitting a wizard creates a job (the API responds 202) and navigates you to the job detail page, where the job runs on a background worker. The job detail page polls until the job reaches a terminal state and lets you cancel (Cancel Job) a job that is still accepted, queued, or running. See the Jobs guide for details.

Complete a message operation

Start from selected search results or message detail. Confirm the environment, VPN, source queue and selected references before submitting; access to a page does not grant access to every queue or destination.

Max rate (per second) is not enforced in v1.7.1, for immediate or scheduled resubmissions. Do not rely on it to protect downstream systems from a replay burst or guarantee messages per second. Plan bounded, approved selections and verify downstream capacity before execution.

1. Enter the destination when required and a useful reason/change reference. Check that downstream consumers are prepared to receive resubmitted or moved messages.
2. Use Dry run (resubmit) or Dry run only (move/delete) for an initial check. A dry-run job does not perform the broker mutation and cannot guarantee that a later real operation will succeed against unchanged messages or permissions.
3. Choose Create Resubmission Job, Create Move Job, or Create Delete Job. To defer the operation, select Schedule this job for later and follow Schedules.
4. Follow the returned job until it reaches a final status, then read its item report. A submitted request or completed dry run is not a completed real message operation.
5. For a failed/partial result, inspect each item and reconcile source/destination state before retrying. A move can publish successfully but fail to remove the source; repeating it blindly can publish another copy. Cancellation does not undo items already processed.

If references have expired or the source message has been consumed, run a new bounded search and review the selection again. For denied operations, request the appropriate scoped access from an administrator; see common problems.

Message detail from search

Selecting a message reference opens the message detail page, which is the best place to inspect the record before taking an operational action.

Inspect a message

The message detail page shows the full metadata available for a selected message.

What you can inspect

The page includes:

• message and broker identifiers
• correlation and destination fields
• timestamps and expiration metadata
• delivery count and content type
• raw metadata
• headers
• properties
• payload preview

The page can also load the full payload when the caller is authorized to read it, via the View Full Payload action.

Actions

From message detail you can start:

• resubmission
• move
• deletion

The page passes the current message reference and scope into the relevant wizard so the operator does not have to re-enter the source context. These operations are asynchronous: submitting the wizard creates a job (the API responds 202) and takes you to the job detail page, which polls to a terminal status and offers a Cancel Job action. See the Jobs guide.

Show all data

The Show all data toggle reveals fields that would normally be hidden when they are empty or set to Not set.

Search limits and reference lifetime

A search browses a bounded, changing queue; it is not a broker snapshot or an archive. By default it scans up to 100,000 messages. The API permits at most 500,000 scanned messages, 10,000 results and 65,536 preview bytes per message. A 256 MiB aggregate payload-buffer limit can end browsing earlier. An empty result does not establish that no matching message exists beyond those limits.

A message reference is a temporary handle, normally valid for 3,600 seconds. It does not reserve the message: consumers may remove it before an operation runs. Refresh your search if a reference expires or cannot be resolved. Application-supplied message IDs are searchable labels; they are not guaranteed unique broker identities.

Browsing does not grant payload access. Previews and full payload retrieval require messages:payload:read; unmasked full content additionally requires messages:content:read. Stored previews remain pattern-masked even for content readers. Headers, properties, metadata and business keys are masked on read without content permission. Pattern masking cannot identify every sensitive value.

The default bulk-operation maximum is 500 messages. Direct move and delete require a reason and always require a change reference in production. Scheduled operations also require a change reference in production, including resubmission. Read-only/disabled environments, deployment containment controls, current roles, queue policies and license limits can prevent execution even after submission. Permission changes are checked again during worker execution; an already running broker request can finish.