Reprocessing failed transactions

Overview

This tutorial walks you through reprocessing a failed transaction instance in Business Activity Monitoring (BAM) using the Custom Logging (Push Model) deployment type. You will locate a failed instance in the transaction instances view, inspect the failure, and use the dynamic reprocessing feature to resubmit the original message payload to your integration workflow.

Business value

Reprocessing lets your operations team recover from transient integration failures — network timeouts, temporary downstream unavailability, or throttling errors — without developer intervention. Instead of manually re-triggering the source system or filing a change request, operators can identify the failed instance in BAM and resubmit it directly from the Turbo360 interface. This reduces recovery time from minutes or hours to seconds.

Prerequisites

Before starting this tutorial, confirm the following:

A BAM environment is deployed with the Custom Logging type. Reprocessing is available only in the Custom Logging type.
The transaction has been configured with a reprocess configuration — a reprocess target URL and any required headers. See Configuring reprocess for transaction stages.
You have Contributor role or higher to perform the reprocess action.
At least one failed transaction instance exists that you want to reprocess.

Required permissions

Action	Minimum role
View transaction instances	Reader
Reprocess a transaction instance	Contributor
Assign users to instances	Contributor

Dependencies

The reprocess target endpoint must be accessible from the BAM Function App at the time of reprocessing. If the downstream system is still unavailable, reprocessing will fail again.
Message archival must be enabled for the transaction stage you are reprocessing. BAM uses the archived payload as the resubmit body. If archival is disabled, the reprocess action will not have a payload to send.

How it works

When BAM receives a tracking event for a transaction stage, it can optionally archive the message payload. When reprocessing is triggered on a failed instance, BAM retrieves the archived payload from the stage you designate as the reprocess point and submits it to the configured reprocess endpoint via HTTP POST.

Dynamic reprocessing extends this by allowing the reprocess endpoint to be resolved at runtime — BAM can substitute dynamic values from the transaction instance (such as the correlation ID or a property value extracted from the message) into the endpoint URL or headers before submitting. This allows a single reprocess configuration to handle instances whose routing differs based on their content.

The reprocessed instance creates a new transaction instance in BAM that is linked to the original as a reprocessed run. The original instance's status is updated to Reprocessed.

Steps

This tutorial covers three tasks: locating the failed instance, reviewing the failure details, and reprocessing. Navigate to Business Activity Monitoring in the Turbo360 tree view to get started.

Step 1: Locate the failed instance

Find the failed transaction instance that you want to reprocess.

In the tree view, expand Business Activity Monitoring > your business process group > your business process > your transaction.
Click the Context menu ( ⋮ ) next to the transaction and select View Instances.
In the transaction instances view, use the status filter to show only Failed instances.
Locate the instance you want to reprocess. Use the correlation ID column or timestamp to identify the correct run.
Click the instance row to expand it and review per-stage details.

Step 2: Review the failure details

Before reprocessing, confirm you understand why the instance failed and that the underlying issue has been resolved.

In the expanded instance view, identify the stage that shows a Failed status.
Click the failed stage to view the error details — this typically includes the HTTP status code returned by the downstream system, the error message, and the timestamp of the failed event.
If message archival is enabled, the archived payload for each stage is available here. Review the payload to confirm it contains the expected data.
Confirm that the downstream system that caused the failure is now available. If the failure was due to a transient error (for example, a 503 from a downstream API), verify that the endpoint is responding before proceeding.

Note:

If the failure was caused by a data error — for example, a malformed payload or a missing required field — reprocessing the same payload will produce the same failure. In that case, correct the data at the source and create a new run rather than reprocessing the failed instance.

Step 3: Reprocess the failed instance

Resubmit the archived payload to the configured reprocess endpoint.

In the transaction instances view, locate the failed instance row.
Click the Actions menu next to the instance.
Select Reprocess.
In the reprocess dialog, review the pre-populated reprocess configuration:
- Reprocess endpoint URL — the target URL where the payload will be submitted. If dynamic reprocessing is configured, confirm the substituted values are correct for this instance.
- Headers — any request headers configured for the reprocess endpoint.
- Payload — the archived message payload that will be resubmitted. This is read from the archived payload of the designated reprocess stage.
Click Reprocess to submit.

BAM submits the payload to the endpoint and creates a new transaction instance linked to the original. The original instance's status updates to Reprocessed.