How Can I Guard Against Duplicate Responses Being Processed by My Domain?
By default, the external domain port that the domain provides comes bundled with configurable retry support. To ensure that retries are not interpreted as independent responses from the external domain, the port will leverage the inputId and physicalMessageId tuple to:
-
enforce idempotency
-
differentiate between message reprocessing (i.e., the same message is consumed twice) and duplicate submissions (i.e., two different messages are consumed that both have the same
inputId).
The inputId represents a unique business identifier (from the perspective of the flow) for an external domain’s response, and functions as the primary reference for idempotency checks. If not specified, it is set as a random UUID by the port.
The physicalMessageId represents a unique transport identifier of an external domain’s response, and enables the system to distinguish between message reprocessing and duplicate submissions. If not specified, it is set as a random UUID by the port.
When using the IPF connector framework, messages from all supported broker-based receive connector transports will contain a suitable physicalMessageId within their ReceivingContext object, which can then be used to populate the input.
If the flow receives two inputs with the same inputId, the second input will always skip execution and either result in a Done.Result.EXECUTED or a Done.Result.DUPLICATE outcome, depending on the physicalMessageId. If the physicalMessageId is also the same on both inputs, the second input is treated as a reprocessed message and a Done.Result.EXECUTED is returned. Otherwise, the input is treated as a duplicate submission, and a Done.Result.DUPLICATE is returned.
Although port-assigned default values for the inputId and physicalMessageId provide adequate idempotency protection for most scenarios, there are some edge cases, such as when your flow handles the same input type from multiple non-exclusive states, that will require you to specify at least an inputId to prevent message reprocessing or duplicate submissions incorrectly triggering a flow transition. An example of how to do this is provided below:
XYZDomain.externalDomainPort().handle(new ExternalDomainResponseInput
.Builder(id, ExternalDomainResponseCodes.OK)
.withInputId(someInputIdFromResponseMessage)
.build());