Code Effects Data Filtering
The Data Filtering feature of Code Effects extends rule evaluation beyond single decisions. It lets you use any evaluation type rule as a filter over a collection of objects, so that the rules your users write and maintain decide which items to keep.
The same rule definition serves both purposes: it evaluates one object, and it filters many.
Concept Overview
In typical decision automation systems, rules are executed only as boolean evaluators: a given object either meets the defined conditions or not. Code Effects goes further by letting those same conditions select data.
When a rule evaluates to true for an object, that object satisfies the rule's logic and is kept in the result. The Filter(..) extension method takes the XML definition of a rule and applies it to every item of a collection.
To understand the concept intuitively, consider this simple rule:
Check if First Name is John
That same logic can be applied to a collection as:
Get records where First Name is John
This is the core idea behind Data Filtering in Code Effects: a single rule definition serves both as a decision condition and as a collection filter, with no manual translation or expression building. The second wording is what the Rule Editor shows in its Filter mode.
How It Works
When you filter a collection, Code Effects compiles the rule into the same predicate it uses to evaluate a single object, and applies it to each item. For example, consider a rule defined as:
Check if Customer Age is greater than or equal to 18 and Customer Active is equal to True
That rule can be applied to any IEnumerable<T> collection:
using CodeEffects.Rule.Engine;
// 'customers' is an IEnumerable<Customer>
// 'ruleXml' is the Rule XML string of an evaluation type rule
var adults = customers.Filter(ruleXml);
The result is the same as this LINQ query:
customers.Where(c => c.Age >= 18 && c.IsActive);
This allows a business rule, written and maintained by non-developers, to act as a live filter on your data.
What a Filter Can Use
Because a filter is the compiled rule itself, it can use everything an evaluation type rule can, including the conditions added in version 7:
- In and Not In lists, and Between and Is Not Between ranges.
- The Collections... menu: exists, does not exist, all, first, last, count and count with.
- Concatenate..., calculations and date shifts, such as Order Date + 30 days.
- Date-only, time-only and offset-aware date values, and durations.
- In-rule methods, which run for each item.
- Reusable rules. Include the rules a filter calls in the ruleset, or pass a
getRule delegate that returns them.
The Filter(..) method works only with evaluation type rules. Execution type rules set field values and invoke actions, so they cannot serve as a filter.
Usage Scenarios
Data Filtering can be used in a wide range of applications. Typical use cases include:
- Search forms — Let users define advanced search conditions in the Rule Editor instead of hard-coded query builders.
- Analytics and reporting filters — Filter the data behind reports and dashboards without redeploying code.
- Administrative panels — Let rules decide which records or users appear in management interfaces.
- Workflow automation — Use rules to select which entities or transactions move to a given process stage.
- AI and decision support — Narrow a dataset before a model or a business decision runs on it.
Essentially, any scenario that requires a user-defined selection of items can benefit from Code Effects Data Filtering.
Supported Collections
You can apply the Filter(..) method to any collection that implements IEnumerable<T>: lists, arrays, sets, the results of other LINQ operators, and your own collection types. The data may come from anywhere, such as a database query you have already run, an API, a file or a cache.
A non-generic IEnumerable can be filtered too: pass the type of its items to the Filter(IEnumerable, Type, ..) overload. For more control, such as evaluation parameters, create an Evaluator<TSource> and call its Filter(..) method. See LINQ to Object Support for examples.
If a ruleset holds several rules, pass the ruleId of the rule to filter with. Without it, the first rule of the ruleset is used.
Each call of the Filter(..) extension method compiles its rule before it filters. To filter many collections with the same rule, create one Evaluator<TSource> and call its Filter(..) method each time: the evaluator holds the compiled rule. See Evaluation Performance Tips.
Rules from the Rule Repository
Evaluation type rules stored in the Rule Repository filter collections the same way. If your application records evaluations with Audit, filter through an Evaluator<TSource> created with the parameters you attached to the recorder: each item is then recorded as an evaluation of its own as the result is enumerated. See Recording Evaluations.
Summary
Data Filtering turns business rules into reusable filters. By bridging decision logic and data selection, Code Effects enables developers to:
- Centralize business logic in readable XML rules
- Reuse rules for both object evaluation and collection filtering
- Allow non-technical users to define live filters through a web interface
- Keep business policy separate from application code
Production Example
