Skip to main content

Message Filter

Use the Message Filter pattern to evaluate each incoming message and continue the flow only for messages that satisfy the selected condition.

The pattern is implemented by placing a filtering construct at the point where the integration has enough context to decide whether a message should continue. Use flow-level constructs when the decision depends on data the integration reads or derives. Use boundary or source-level constructs when the decision can be made from metadata or delivery rules before the main processing path starts.

Predicate-based filtering

Use predicate-based filtering with if/else statements when each message carries the fields needed for a single boolean decision, such as priority, source, header, or status. The accepted path contains the forwarding or processing action. The rejected path does nothing or handles the rejection separately.

  1. Open the flow and add a step.
  2. Add an If node at the point where the message has enough data for the decision.
  3. Set the condition to message.priority == HIGH_PRIORITY.
  4. Add the accepted action inside the matching branch.
  5. Leave the other branch empty when unmatched messages should be discarded.
Message Filter flow

Collection-level filtering

Use collection-level filtering with query expressions when the flow already has a group of messages or records and only a subset should continue. Keep the predicate in the where clause so the result is the accepted collection.

  1. Open the flow and add a step.
  2. Add a Map Data or Declare Variable step.
  3. Set the output type to the accepted collection type, such as Message[].
  4. Enter a query expression with a where clause for the filter predicate.
  5. Use the resulting collection in the next processing or forwarding step.
Collection-level Message Filter flow

Boundary-level filtering

Use boundary-level filtering when the input artifact can reject or route messages before custom flow logic runs. For HTTP-facing inputs, use a request interceptor when the decision can be made from request metadata before the resource executes. Other inputs can use their own handler, listener, or subscription selection points.

  1. Add the source artifact, such as an HTTP service.
  2. Add a request interceptor for the service boundary.
  3. Read the request metadata needed for the filter, such as a priority header.
  4. Return a response for messages that should stop at the boundary.
  5. Call the next service only for messages that should enter the resource flow.

Broker-side delivery filtering

Use broker-side delivery filtering when RabbitMQ can reduce what reaches the flow before consumption. Route matching messages into a dedicated queue with a direct exchange and binding key, then configure the RabbitMQ trigger to consume only that queue. Use RabbitMQ exchange bindings to bind the accepted-message queue to the exchange with the accepted routing key.

  1. Add the RabbitMQ event integration.
  2. Configure the RabbitMQ trigger connection with the broker host and port.
  3. Set Queue Name to the queue that receives accepted messages, such as high-priority-orders.
  4. Create the RabbitMQ broker resources with connector actions or broker administration: declare a direct exchange, declare the accepted-message queue, and bind the queue to the exchange with the accepted routing key.
  5. Publish messages to that exchange with the routing key that matches the accepted binding key, such as orders.priority.high.
  6. Add processing steps only for messages delivered to the accepted-message queue.