When an integration produces hundreds or thousands of similar failures, opening every record in Message Reprocessing is a slow way to find the underlying pattern. A read-only query can give you the message ID, external system, interface and error text for the active failures in one result set.
Use this as a triage view. Resolve, edit, reprocess or delete messages through Maximo so the Integration Framework can maintain the error records correctly.
List the active errors
The query joins the error status and error message tables by MESSAGEID:
--Get all Errors from Message Reprocessing with their related Message ID, External System and Interface Name (Publish Channel or Enterprise Service)
SELECT
MAXINTERROR.MESSAGEID,
MAXINTERROR.EXTSYSNAME,
MAXINTERROR.IFACENAME,
MAXINTERRORMSG.ERROR
FROM
MAXINTERROR
INNER JOIN
MAXINTERRORMSG
ON MAXINTERRORMSG.MESSAGEID = MAXINTERROR.MESSAGEID
WHERE
MAXINTERROR.DELETEFLAG = 0;MAXINTERROR holds the status and routing details, while MAXINTERRORMSG supplies the stored error text. Filtering MAXINTERROR.DELETEFLAG to 0 limits the result to records that have not been marked as deleted.
The result is a detailed list rather than a unique set of error messages. If the same failure affects 1,000 messages, it can appear 1,000 times. That detail is useful when you need the individual message IDs, but less useful when you first need to see which interface is generating most of the work.
Count errors by interface
Group the active records to get a smaller operational summary:
SELECT
MAXINTERROR.EXTSYSNAME,
MAXINTERROR.IFACENAME,
COUNT(*) AS ERROR_COUNT
FROM
MAXINTERROR
INNER JOIN
MAXINTERRORMSG
ON MAXINTERRORMSG.MESSAGEID = MAXINTERROR.MESSAGEID
WHERE
MAXINTERROR.DELETEFLAG = 0
GROUP BY
MAXINTERROR.EXTSYSNAME,
MAXINTERROR.IFACENAME
ORDER BY
ERROR_COUNT DESC;This shows where errors are concentrated without grouping on the error-text column, whose database type and grouping support can vary between Maximo and database versions. After identifying the busiest interface, run the detailed query with an additional EXTSYSNAME or IFACENAME predicate and group or filter the error text in your SQL client.
Read the result in context
IBM describes Message Reprocessing as the place to manage asynchronous inbound and outbound queue messages that have failed. A continuous queue can accumulate multiple errors while it keeps processing later messages. A sequential queue stops at its first error until that message is resolved or removed. That distinction matters when interpreting the counts: one visible sequential-queue failure can be blocking a much larger backlog.
Successful reprocessing removes the stored error message and updates the error status record. The result set can therefore change while you are investigating it. Capture the query time, rerun the summary after remediation, and do not treat an exported result as a permanent audit record.
Read-only access to these tables is sufficient for diagnosis. Avoid correcting payloads, changing statuses or deleting rows directly in SQL; doing so can bypass the application behavior that keeps the two error tables and queue state consistent.
A practical triage flow
- Run the grouped query to find the external system and interface with the largest active count.
- Run the detailed query for that interface and look for repeated error text.
- Confirm whether the message belongs to a sequential or continuous queue.
- Correct the shared configuration, reference-data or endpoint problem before retrying a large batch.
- Use Message Reprocessing to retry a small sample.
- Rerun the summary and confirm that the count falls without creating a new error pattern.
This turns a large error queue into a short list of patterns while keeping the actual message lifecycle inside Maximo.