resubmit
Source processor that exposes a REST endpoint specifically for resubmitting archived payloads.
Properties
Name | Summary |
---|---|
|
Optional, descriptive name for the processor. |
|
Required identifier of the processor, unique across all processors within the flow. Must be between 3 and 30 characters long; contain only lower and uppercase alphabetical characters (a-z and A-Z), numbers, dashes ("-"), and underscores ("_"); and start with an alphabetical character. In other words, it adheres to the regex pattern |
|
Optional set of custom properties in a simple jdk-format, that are added to the message exchange properties before processing the incoming payload. Any existing properties with the same name will be replaced by properties defined here. |
|
Whether the incoming payload is available for error processing on failure. Defaults to |
Sub-builders
Name | Summary |
---|---|
Strategy for describing how a processor’s message is logged on the server. |
|
Strategy for archiving payloads. |
|
Strategy that customizes the conversion of an incoming payload by a processor (e.g., string to object). Should be used when the processor’s default conversion logic cannot be used. |
Details
Usage
The resubmit
processor creates a POST endpoint on the flow’s main path that expects the following request body:
{
"payloadArchivePaths": [
"/path/to/payload1",
"/path/to/payload2"
],
"destinationFlowId": "destination-flow-handoff"
}
This standardized REST endpoint helps automate the resubmission of payloads in Utilihive Heartbeat. However, a proper "resubmit" flow requires certain configurations to be in place, including a separate "archive" flow. See the Archiving and Resubmission documentation for more details.