If you are upgrading from Oracle GoldenGate Classic Architecture to Microservices Architecture and rely on complex filtering or transformation logic in your Classic data pumps, you may have to reposition that logic within components that are fully supported in the Microservices Architecture.

While Microservices does not implement every legacy pump side filtering capability in exactly the same way, you can typically achieve the same functional outcome by adjusting where that logic is applied within the replication flow. In Microservices, some basic filtering and routing capabilities are still available within Distribution Paths, but more advanced transformation logic is typically implemented elsewhere in the pipeline.

The most common and recommended approaches include:

1) Move the filtering to the source Extract (preferred when possible)

If the filter is row-based (e.g., WHERE, FILTER, TABLEEXCLUDE, COLSEXCEPT, COLS, TOKENS, etc.), push it upstream into the Extract so only the desired operations ever leave the source trail.

Why it’s best: less network + less downstream work + simplest operationally.

Tradeoff: if you used the pump to create multiple “views” of the same source trail for different targets, you may need multiple extracts or a different splitting strategy (e.g. multiple trails from same extract, Option #3).

Example:

Goal: only generate the rows each target needs as early as possible.

Extract writes two different trails (one per destination)

EXTRACT E_ORDERS
USERIDALIAS srcdb
-- US stream
EXTTRAIL ./dirdat/u1
TABLE SALES.ORDERS, FILTER ( REGION = 'US' );
-- EU stream
EXTTRAIL ./dirdat/e1
TABLE SALES.ORDERS, FILTER ( REGION = 'EU' );

Microservices transport (Distribution Paths)

• Path_US ships ./dirdat/u1 → Target A
• Path_EU ships ./dirdat/e1 → Target B

Replicats (simple apply)

Target A Replicat reads the US trail:

REPLICAT R_US
USERIDALIAS tgta
MAP SALES.ORDERS, TARGET SALES.ORDERS;

Target B Replicat reads the EU trail:

REPLICAT R_EU
USERIDALIAS tgtb
MAP SALES.ORDERS, TARGET SALES.ORDERS;

Why you’d choose this: best for bandwidth/scale because you never ship rows that won’t be used.

2) Keep the Extract “wide,” and do filtering in Replicat (very common)

If the goal is “only apply subset X to target Y”, do it in Replicat using Replicat-side mapping/filtering.

Best when:

• Same captured trail needs to feed multiple targets
• You want to keep capture simple and decide “what applies” per target

Tradeoff: you ship more data than you apply, pressuring network capacity and additional storage.

Example:

Goal: capture once; let each target decide what to apply.

Extract (single trail, no split)

EXTRACT E_ORDERS
USERIDALIAS srcdb
EXTTRAIL ./dirdat/oa
TABLE SALES.ORDERS;

Transport (Distribution Path)

• One path ships ./dirdat/oa to both targets (fan-out)

Replicat A (US)

REPLICAT R_US
USERIDALIAS tgta
MAP SALES.ORDERS, TARGET SALES.ORDERS,
  FILTER ( REGION = 'US' );

Replicat B (EU)

REPLICAT R_EU
USERIDALIAS tgtb
MAP SALES.ORDERS, TARGET SALES.ORDERS,
  FILTER ( REGION = 'EU' );

Why you’d choose this: simplest operationally (single capture), and best when filters change per target or you want “capture once, decide later.”

3) Split/route by using multiple trails + Distribution Paths (Microservices-style “pump”)

If the Classic pump was effectively being used to:

• Split one trail into multiple trails
• Route specific tables/ops to different destinations
• Fan-out to multiple targets

…then do that with multiple trails and Distribution Paths, and attach the right Replicats to the right incoming trail(s).

Example:

Goal: keep one capture trail, but separate the delivery streams so each target receives its own inbound trail.

Extract (single trail)

EXTRACT E_ORDERS
USERIDALIAS srcdb
EXTTRAIL ./dirdat/oa
TABLE SALES.ORDERS;

Distribution Service (two paths from the same source trail)

• Path_US → Target A Receiver trail (e.g., ./dirdat/ru)
• Path_EU → Target B Receiver trail (e.g., ./dirdat/re)

If your Distribution Path supports the level of selection you need, you can route there.
If the split is truly row-level and the path selection is “basic”, keep the row filter in Replicat (below).

Receiver + Replicat on each target

Target A Replicat (still applies US filter if needed):

REPLICAT R_US
USERIDALIAS tgta
MAP SALES.ORDERS, TARGET SALES.ORDERS,
  FILTER ( REGION = 'US' );

Target B Replicat:

REPLICAT R_EU
USERIDALIAS tgtb
MAP SALES.ORDERS, TARGET SALES.ORDERS,
  FILTER ( REGION = 'EU' );

Why you’d choose this: you get clean stream separation (different paths, different trails, different monitoring/SLA), while still capturing once.

Important nuance: Distribution Paths are mainly transport/routing; don’t expect them to replicate every Classic pump’s transformation features. But as a “pump replacement” for movement + fan-out, they’re the right tool.

My Field Guidance:

When you begin planning a Classic to Microservices upgrade, take time to inventory exactly what your data pumps are doing today.

In many environments, pumps have gradually accumulated years of filtering, routing, and transformation logic. While this worked well in Classic, Microservices encourages a cleaner separation of responsibilities across Extract, Distribution, and Replicat.

You may find that some of this logic must be repositioned either upstream in Extract to reduce data movement, downstream in Replicat for target-specific behavior, or implemented through multiple trails and Distribution Paths for routing.

Treat the migration as an opportunity to simplify the architecture. Designs that minimize transformation in the transport layer are typically easier to operate, scale, secure, and troubleshoot over time.