Resubmitting messages

The audit log stores the message body itself, not only the metadata about it. That means a message that failed can be sent again from the screen where you found it, without going back to whoever sent it in the first place and asking them to repeat it.

What can be resubmitted

Not everything. A resubmittable event is one where sending the payload again is a meaningful action:

Anything else - a response, a pub/sub delivery, a scheduler run, a config change - has no resubmit action, because there is nothing sensible to repeat.

Two further things stop an otherwise resubmittable event from being sent again: the event no longer exists because retention deleted it, or it has no payload because it was only ever a reconciliation record. An empty payload is not the same as no payload - a GET with no body resubmits perfectly well.

Resending against reprocessing

Both actions read Resubmit on screen. Which one happens depends on the direction of the message.

Resending applies to a message you sent. The stored payload goes out again through the same outgoing connection, to the same remote system. Use it when the failure was on the far side or in between - a timeout, a 503, a connection refused.

Reprocessing applies to a message you received. The stored payload is fed back into the machinery that handles incoming messages, so your own service runs again on it. Use it when the failure was on your side - a service that raised an exception, a downstream system that was down when the message first arrived.

The classification column on the listing helps with the choice. A failed event is classified as transient when its error looks like a timeout, a refused connection or an unavailable system - resubmitting the message as-is can work. It is classified as permanent when the error points at the message itself - validation, a malformed payload, an unknown identifier - so the payload needs to change before another attempt. A failure matching neither pattern stays unclassified.

Editing the payload first

The stored payload does not have to go out exactly as it was recorded. Both resends and reprocesses accept an edited payload in its place - for the message that failed because of its content, a malformed segment or a wrong identifier, fix the payload and resubmit the fixed version. The new attempt lands as its own audit event, linked to the original by the correlation ID, so the record shows both what arrived and what was actually sent again.

A reprocess can also be narrowed to named destinations - the message reaches those alone, so a receiver that missed it can be caught up without every other destination being sent it twice.

Resending one hop

Some messages fan out. One incoming HL7 message can be delivered to several destinations, and one of them can fail while the others succeed.

A hop resend deals with exactly that. It sends the stored payload to that one destination again, without re-running the service that produced it and without touching any other destination. Nobody who already has the message gets it twice.

Resubmit a message

1. Find the event, either on the audit log listing or by following the link in an alert notification.
2. Click Resubmit in the row's Actions column.
3. A confirmation appears, naming the connection and the message so you can see what is about to be sent before it goes.
4. Click Yes, resubmit.

The result appears in place - either Resubmitted with the new correlation ID, or the failure and its error. A message that has already been resubmitted says so instead of offering the action again, which is what stops the same message going out twice by accident.

Learn more