Skip to content

Reprocessing Sequence

Certain durable use cases are designed to allow reprocessing when operational errors4 are encountered. This article details how use cases (sequences) queue messages for retry upon failure.

Tracking

A ReprocessingMessageStore record is added upon encountering an operational error against an endpoint. The table's purpose is to:

  • Provide a source for the reprocessing scheduler.
  • Track the endpoint source of failure.
  • Track the current attempt count for the endpoint.
  • Store the payload of the original message.

Once a record is consumed by the scheduler, a sequence is triggered once. If another retry is needed, a new ReprocessingMessageStore is inserted:

  • If the source of the failure is the same endpoint (TrnAdd, etc), Attempts is set to the prior record + 1.
  • If the source of the failure is a different endpoint (GetPayments, etc), Attempts starts over at 1.
  • The MessagePayload is carried over.
  • The Status = Pending.

ReprocessingMessageStore Fields

Field Name Type Desc
ReprocessingMessageStoreId int
TransactionIdFK uniqueidentifier Workflow correlation id1
RequestId uniqueidentifier RequestId provided to the endpoint that failed. See correlation ids
CorrelationId nvarchar Provided by caller or generated by UC. See correlation ids
OperationId tinyint Sequence name
EndpointType varchar Category of endpoint2
EndpointName varchar Endpoint that failed
Attempts int Current attempts for this endpoint
StatusId tinyint See section
LastAttemptStartAt datetime2 Start UTC of the attempt that triggered
the creation of this record.
LastAttemptStartAt datetime2 End UTC of the attempt that triggered
the creation of this record.
CreatedAt datetime2
ModifiedAt datetime2
MessagePayload nvarchar Payload of the operation. 3

Reprocessing Statuses

Status Desc
Pending Retry is pending
InProgress Retry flow in in progress
Completed Retry completed successfully
AttemptsExceeded Configured attempts
Failed Business logic error

Sequence Template

The following pattern is used for uses cases that support reprocessing:

file

  1. wiki ↩

  2. CoreServices, PCS, PaymentServices, EWS ↩

  3. The payload is carried over into subsequent retries of the operation. ↩

  4. Includes timeouts and server errors ↩