Camunda 8 deep dive: message correlation, timers and compensation

For an illustrative order process, define message name PaymentConfirmed and correlate by a stable orderId. Include a distinct eventId, schema version and payment reference in the sender contract. The message name identifies the event type; the correlation key identifies the waiting business context. Neither should contain credentials.

A message start event creates a new instance while an intermediate message catch event resumes waiting work. Keep correlation keys available before the catch event becomes active, and verify how your connector maps the sender payload into the message variables.

A message can arrive before the process establishes its subscription. Supported message publication APIs can buffer messages using a time-to-live; a zero time-to-live does not provide a waiting window. Choose a bounded window based on the business contract and check the publication or correlation behaviour of the specific API and connector you use.

After a timeout or cancellation, a late event may have no intended waiting receiver. Record unmatched outcomes and define whether the sender retries, an operator reconciles or a separate exception process handles the reply. An HTTP acknowledgement is not proof that the intended process consumed the business event.

Where supported, a message ID can prevent certain duplicate publications within the documented message lifetime and scope. It is not an unlimited global exactly-once guarantee, nor does it automatically deduplicate all webhook connectors. Read the specific connector semantics and preserve a durable business event ID.

Repeat the same event while waiting, after successful correlation and after the message expires. Verify the external payment is not applied twice and that new instances are not accidentally created. Use durable application-level uniqueness where a duplicate has financial or operational consequences.

For a payment wait, a duration such as PT15M illustrates a fifteen-minute timer, not a KaribuTech service promise. An interrupting boundary timer cancels the attached activity and takes a timeout route. A non-interrupting timer leaves the activity active and creates an additional path, suitable for a reminder when that behaviour is intended.

Due dates on human tasks are metadata, not an automatic substitute for a BPMN escalation timer. Timers become due according to the model but execution can be delayed by load; do not use them as a precision real-time scheduler. Test time zones when using date expressions and recurrence when using repeating timers.

Cancelling an activity or process does not undo an external reservation or payment. Design a release or refund operation with its own authorisation, idempotency key and reconciliation. Compensation is a business undo action, not a rollback of an external database transaction.

Use BPMN compensation only for activities and patterns supported by the installed Camunda version. If the required pattern is unsupported or a undo action itself fails, use an explicit recovery process with an accountable operator. Avoid assuming compensation can reconstruct state that was never recorded.

Test payment before the subscription, payment while waiting, duplicate payment, timeout without payment and payment arriving immediately after timeout. Inspect which path ran, the message contract and the resulting external state.

Agree who owns each ambiguous outcome and retain enough identifiers to reconcile it. Use a controlled sandbox clock or supported time-control testing facilities rather than changing production time. This exercise should produce evidence for both success and exception paths.