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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/jobs/) for details. ## Complete a message operation Start from selected search results or [message detail](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/messages/). Confirm the environment, VPN, source queue and selected references before submitting; access to a page does not grant access to every queue or destination.
Complete a message operation
ActionWhat it doesFields to review
ResubmitPublishes a new copy; leaves the original message on its source queueTarget type, Target destination, header/property preservation and resubmission metadata; maximum rate is ignored in v1.7.1
MovePublishes to the target first, then deletes the source only after publishing succeedsTarget type, Target destination, Reason and Change reference (required in production)
DeletePermanently removes the selected source messagesReason, Change reference (required in production) and the destructive-operation acknowledgement
**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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/schedules/). 4. Follow the returned [job](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/jobs/) 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/troubleshooting/). ## 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/jobs/). ### 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.