Yes - that is what the durable subscription option of a message intermediate event (BPM 8.6 / BAW) is for. Without it, an event message delivered by the UCA is matched only against instances that are currently waiting at the event; if none matches, the message is discarded. With Durable subscription enabled on the event:
- The engine registers the instance's interest in the message when the instance is created (or when the enclosing scope starts), not when the token reaches the event.
- A message that arrives early is stored (durable event table) and delivered as soon as the token reaches the event - no race between the request and the reply.
- Correlation still decides which instance gets it (the correlation key must be computable at subscription time, so it should be an input variable or set before the send).
BPD "Partner request"
[Prepare request] -> [Send to partner (REST)] -> ( IME "Partner reply", UCA PartnerReplyUCA, correlation tw.local.requestId, Durable subscription = true ) -> [Process reply]
// tw.local.requestId is set in [Prepare request] - before the send - so the subscription exists when the reply comes back within milliseconds
Cost and rules: durable subscriptions keep rows per waiting instance (housekeeping deletes them when the instance ends); use them only for events that can genuinely arrive early; the option is per event; a start-event UCA does not need it (messages start new instances). Alternative for older releases (8.5.x, no durable option): send the request after the token reached the event - model the send inside a parallel branch or as the last step before the event with a very small window, or let the UCA store early replies in a table that a second UCA replays (the "message parking" pattern).
References