pfx-messaging Component | Pricefx Knowledge Base

Overview

The pfx-messaging component publishes messages to the Integration Manager internal RabbitMQ exchange with an embedded, bounded exponential retry. Use it wherever a route or kamelet must deliver a message reliably even when the broker is briefly unreachable — the retry logic lives inside the component, so the route stays a single declarative line instead of hand-rolled retry loops.

The message is delivered through the worker's standard event-publishing infrastructure (the same auto-reconnecting connection used for internal IM events), under the routing key you configure. The exchange body is sent as-is and must be a non-empty string (typically pre-serialized JSON).

URI pattern: pfx-messaging:method[?options]

Methods

Method	Description
`send`	Publish the exchange body under the configured routing key, retrying on failure

The component is producer-only — it cannot be used in from.

Parameters

Parameter	Type	Default	Description
`routingKey`	String	—	Required. Routing key the message is published under on the IM internal RabbitMQ exchange
`retries`	int	`3`	Maximum delivery attempts, including the first one. Must be at least 1
`retryDelayMs`	long	`5000`	Base delay in milliseconds between delivery attempts
`exponentialBackoff`	boolean	`true`	When `true`, the delay doubles after each failed attempt (capped by `maxRetryDelayMs`); when `false`, every delay is `retryDelayMs`
`maxRetryDelayMs`	long	`60000`	Upper bound in milliseconds for the exponential backoff delay

Retry behavior

With the defaults (retries=3, retryDelayMs=5000, exponentialBackoff=true), a failing publish is attempted at 0s, +5s, and +10s before giving up.
When all attempts are exhausted, the exchange fails with the last publish error — the calling route decides what happens next (error handler, doTry/doCatch, onCompletion).
Deterministic errors fail fast without consuming the retry budget: an empty or missing exchange body is rejected immediately, and an invalid endpoint configuration (routingKey missing, retries below 1) fails at route startup.

Examples

Publish a completion event with default retry

XML

<setBody>
    <groovy>groovy.json.JsonOutput.toJson([type: "integration-finished", integrationId: "abc"])</groovy>
</setBody>
<to uri="pfx-messaging:send?routingKey=im-internal.im-iaas.events.internal.IntegrationFinished"/>

Survive a longer broker outage

XML

<to uri="pfx-messaging:send?routingKey=im-internal.im-iaas.events.external.DataExportWorkloadExecutionResult&amp;retries=5"/>

Fixed delay between attempts

XML

<to uri="pfx-messaging:send?routingKey=a.b.c&amp;retries=4&amp;retryDelayMs=2000&amp;exponentialBackoff=false"/>

Common Pitfalls

The exchange body must be a non-empty string — serialize your payload (e.g. with JsonOutput.toJson) before calling send; an empty body fails immediately without any delivery attempt.
retries counts total attempts, not additional retries: retries=1 means a single attempt with no retry.
Retry delays block the calling route thread — keep retries/maxRetryDelayMs proportionate for routes with high concurrency.
Event publishing must be enabled (integration.event-driven.enabled=true, the default for IaaS workers); with messaging disabled the message is silently discarded by the no-op publisher (a warning is logged at startup).
The routing key is used verbatim — integration.event-driven.im-publisher.output-routing-key-prefix is intentionally not applied to pfx-messaging sends, so a prefix configured for platform events cannot reroute your message.