SAP Router and Filter Steps

Not every message needs the same processing path. A high-value purchase order might require manager approval. An order in US dollars needs different tax logic than one in euros. A message from a VIP customer goes to a priority queue. Routing steps make these decisions automatically based on message content, without human intervention.

Filtering reduces unwanted data. A message arrives with 50 fields, but the receiver only needs 10 of them. A filter removes the other 40 before delivery, keeping the payload clean and the receiver's processing simple.

The Router Step

The Router step evaluates conditions and sends the message down one of several branches. Each branch has a condition. The message flows to the first branch whose condition evaluates to true. If no condition matches, the message goes down the default branch (if configured).

Router Visual Structure

                    ┌──→ [Branch 1: Order Value > 10,000] ──→ [Approval Receiver]
                    │
[Incoming Message] ─┤──→ [Branch 2: Order Value 1,000-9,999] ──→ [Auto Receiver]
        │           │
        │           └──→ [Default Branch] ──→ [Standard Receiver]
        │
  Router evaluates
  conditions in order

Router Condition Types

Conditions in the Router use the Simple language or XPath:

Simple Expression: ${header.OrderType} = 'RUSH'
XPath Expression: /Order/TotalValue > 10000
Non-XML: Compare property or header values directly

Router Configuration Example

iFlow processes incoming customer orders. Routing decision by order type:

BRANCH 1 Condition: ${property.OrderType} = 'EMERGENCY'
  Route to: Emergency Processing iFlow (via Process Call)

BRANCH 2 Condition: ${property.OrderType} = 'STANDARD'
  Route to: Standard SAP SD Receiver

DEFAULT Branch (no condition):
  Route to: Error Handler (unknown order type)

Router vs Content-Based Routing

CPI Router steps evaluate one message and send it to one branch. If a message needs to go to multiple receivers, use a Multicast step instead. Multicast sends the same message to multiple parallel paths simultaneously.

ROUTER (one path chosen):          MULTICAST (all paths executed):
Message → [Router] → Path A        Message → [Multicast] → Path A
                       OR                   └──────────→ Path B
                     Path B                 └──────────→ Path C
                       OR
                     Path C

The Filter Step

The Filter step removes parts of an XML message that match a specified condition. It uses an XPath expression to identify elements. Elements that match the XPath are kept. Elements that do not match are removed.

Filter Example: Keep Only High-Value Items

Input XML:
<OrderItems>
  <Item><SKU>A001</SKU><Price>500</Price></Item>
  <Item><SKU>B002</SKU><Price>15000</Price></Item>
  <Item><SKU>C003</SKU><Price>200</Price></Item>
</OrderItems>

Filter XPath: /OrderItems/Item[Price > 1000]

Output XML:
<OrderItems>
  <Item><SKU>B002</SKU><Price>15000</Price></Item>
</OrderItems>

Only the item with Price 15000 survives the filter.
A001 (500) and C003 (200) are removed.

Practical Use Cases for Routing

System Routing

One iFlow receives messages from multiple sources. The Router reads the source identifier from the message header and sends each message to the correct SAP company code.

Header: SAP_Sender = "CompanyA" → Route to SAP client 100
Header: SAP_Sender = "CompanyB" → Route to SAP client 200
Header: SAP_Sender = "CompanyC" → Route to SAP client 300

Priority Routing

Orders flagged as urgent go to a direct-call path with error alerts. Normal orders go through the standard async queue.

Country-Based Routing

An invoice message routes to different tax calculation services depending on the country code in the payload.

Error vs Success Routing

After a call to an external system, a Router checks the response code. Status 200 goes to the success path. Status 400 or 500 goes to the error handling path.

[Call External API]
        ↓
[Router]
  Condition: ${header.CamelHttpResponseCode} = '200' → [Success Path]
  Default: → [Error Path: Log + Alert]

Practical Use Cases for Filtering

Field Restriction

An HR system sends a full employee record with 80 fields, including sensitive personal data like salary and bank account numbers. The filter removes all sensitive fields before the record is forwarded to a third-party benefits platform.

Record Selection

A database query returns all invoices from the last 30 days. The filter keeps only invoices with status "Unpaid" for further processing. Paid invoices are removed before the message reaches the receiver.

Namespace Cleanup

A source XML contains elements from multiple namespaces. A filter (combined with XSLT) strips namespace declarations from elements that the receiver does not understand, preventing parsing errors.

Combining Router and Filter in One iFlow

[Incoming Order Message]
        ↓
[Filter: Remove internal fields not for external use]
        ↓
[Router: Check order region]
  ├──→ [US Orders] → [US SAP Receiver]
  ├──→ [EU Orders] → [Filter: Apply EU tax fields] → [EU SAP Receiver]
  └──→ [APAC Orders] → [APAC SAP Receiver]

Placing a Filter before the Router reduces the payload before routing decisions are made. Placing a Filter inside a specific branch applies field removal only for that branch — useful when different receivers need different field sets from the same source message.

Default Route and Dead Letter Handling

Always configure a default route in your Router. Without a default, a message that matches no condition throws an exception and fails processing. The default route should at minimum write the message to a Data Store (CPI's persistence layer) and send an alert to the operations team. This pattern — called a dead letter handler — ensures no message is silently discarded when routing logic does not cover a case.

Previous lesson

Back to course

Next lesson