Debugging and analyze Tasks with Exclude and Reduction Rules

Using Exclude Rules And Reduction Rules For Testing

When developing or analyze a task, it is often useful to run it with a reduced scope instead of processing the full production workload. XDM provides two complementary mechanisms for this purpose:

Exclude rules reduce the number of objects that are processed. Reduction rules reduce the amount of data processed inside the selected objects. Both can be applied temporarily, for example during test runs, performance tuning, or error analysis, without changing the overall task configuration.

Reducing The Number Of Objects With Exclude Rules

Exclude rules remove complete objects from the selection set, such as

tables
views
grants
columns

Objects that match an exclude rule are not compared or copied, even if they are selected by one or more selection rules.

From a testing perspective, exclude rules are useful if you want to:

run a very large task only on a subset of schemas or tables
skip particularly large or slow objects during performance tests
temporarily ignore objects that are known to be problematic while you analyze other parts of the task

For example, if a table production.salaries is known to contain a large amount of data and regularly slows down the task, you can define an exclude rule with schema pattern production and name pattern salaries. The table will still match the selection rules, but it is then removed from the selection set by the exclude rule and will not be compared or copied in this run.

Because exclude rules are evaluated after all selection rules,

you can add such rules on the task level for testing and remove them again afterward, without touching the main selection logic in the template.

For more details refer to the Exclude rules description in the reference.

Reducing The Amount Of Data With Reduction Rules

Reduction rules limit the data that is processed inside a table. Instead of removing the table from the task, they restrict which rows or columns are taken into account during data extraction. If no reduction rule is defined for a table, XDM processes all rows; if a reduction rule is present, only data matching this rule is copied.

This is useful when you want to:

run the full task logic (mappings, modifications, workflow) but only on a small set of representative data
reproduce a specific data constellation for debugging
reduce runtime and load on source and target while keeping the set of tables unchanged

For example, you might want to test a table copy task only with departments Customer Service and Development from the table production.departments. In that case a reduction rule can restrict the data to rows where the column dept_name matches one of these two values, for instance by using a reduction expression such as:

WHERE dept_name IN ('Customer Service', 'Development')

The task still processes the table production.departments, but copies only the matching rows. All other rows are ignored. Other tables in the task remain unaffected and continue to use their normal behaviour.

For more details refer to the reduction rules description in the reference.

When To Use Which Rule Type For Testing

In practice, both mechanisms can be combined:

Use exclude rules when you want to remove whole objects from the run, for example to:

focus on a small group of tables during the initial development of a task
temporarily skip very large or non‑critical schemas in a performance test.

Use reduction rules when you want to keep the table structure in the task, but limit the data volume, for example to:

test complex modifications or mappings on a few business cases
reproduce an error with a minimal set of rows
run a quick “smoke test” without copying complete production volumes. By adding and later removing these rules on task level, you can safely experiment with smaller and faster task runs while keeping the main configuration in the template stable.

Limitations And Pitfalls

Exclude rules and reduction rules are powerful tools for testing, but they are not suitable in every situation:

They do not replace full test runs: Runs with excluded objects or reduced data cannot fully prove that the task will behave correctly under production conditions. Before going live, at least one run with the full selection set and realistic data volumes is required.
Logical dependencies between tables: Excluding tables or heavily reducing the data for a table can break implicit business relationships, even if no foreign key exists in the database. Test results may then no longer be representative for the real application behaviour.
Tasks that depend on complete data sets: Some processing steps, for example aggregation, reconciliation, or data quality checks, only make sense on complete or near-complete data sets. Using reduction rules in such tasks can hide issues instead of revealing them.
Global rules on connections: Exclude rules and reduction rules that are defined on a connection apply to all tasks using this connection. They should therefore be used with great care for testing purposes. For temporary experiments it is usually safer to define rules on the task level only.
Overlapping rules and unexpected empty results: A combination of very restrictive selection rules, exclude rules and reduction rules can lead to empty selection sets or tables without rows. This may cause a task to appear „successful“ while in fact no relevant data was processed. Always verify the effective selection in the task reports.