skip to main content
Corticon Studio: Rule Modeling Guide : Filters and preconditions : What is a filter? : Limiting filters
 

Try Corticon Now
Limiting filters
There are occasions, however, when the all-or-nothing behavior of a full Filter is unwanted because it is too strong. In these cases, we want to apply a Filter to specified elements of a collection but still keep the selected entities even if none of the children survive the Filter.
To turn a Filter expression into a limiting Filter, right-click on a Filter in the scope section and select Disable from the menu, as shown:
Figure 172. Selecting to limit a filter
This causes that specific filter position to no longer apply, indicated in gray:
Notice that the filter is still enabled, and that it will still be applied at the Driver level. We have limited the filter.
Use case for limiting filters
The preceding example was basic. Let's explore a some more complex example of limited filters.
Consider the case where there is a rule component designed to process customers and orders.
A Customer has a 1 to many relationship with an Order.
The rule component has 2 objectives, one to process customers and the second to process orders.
If we define a filer that tests for a GOLD status on an order we can have four logical iterations of how the filter could be applied to the ruleset.

Case 1: filter is not applied at all.
Case 2: filter is applied to all customers and all orders.
Case 3: filter is only applied to customers.
Case 4: filter is only applied to orders.
A business statement for these cases could be as follows:

Case 1: Process all customers and all orders.
Case 2: Process only GOLD status orders and only customers that have a GOLD status order.
Case 3: Process only customers that have a GOLD status order and all orders of a processed customer.
Case 4: Process all customers and only GOLD status orders.
For filter modeling, the filter expression could be written as Customer.order.status = ‘GOLD’ The modeling consideration for the cases are:

Case 1: Filter is not entered (or filter disabled, or filter disabled at both Customer and Customer.order levels in the scope).
Case 2: Filter is entered with no scope modifications (enabled at both Customer and Customer.order levels in the scope).
Case 3: Filter is entered and then disabled at the Customer.order level in the scope.
Case 4: Filter is entered and then disabled at the Customer level in the scope.
You see how one filter can apply limits to the full filter to achieve the preferred profile of what survives the filter and what gets filtered out.
Next, let's look at more complex set of limiting filters.
Example of limiting filters
Consider the following Rulesheet Scope of a Vocabulary:
Figure 174. Scope in a Rulesheet that will be filtered
Consider the filter to be applied to data:
Customer.order.item.bid >= Category.product.price
This is shown in the Rulesheet's Filters section as:
Figure 175. Definition of a filter
The resulting filter application applies at several levels, as shown:
Figure 176. Application of the filter to the Scope's tree structure
A Ruletest Testsheet might be created as follows:
This data tree contains five entity types (Customer, Order, Item, Category, Product).
This filter is evaluated as follows:

Customer[1],Order[1],Item[1],Category[1],Product[1] false
Customer[1],Order[1],Item[1],Category[1],Product[2] true
Customer[1],Order[1],Item[1],Category[2],Product[2] true
Customer[1],Order[1],Item[1],Category[2],Product[3] true
Customer[1],Order[1],Item[1],Category[3],Product[1] false
Customer[1],Order[1],Item[2],Category[1],Product[1] false
Customer[1],Order[1],Item[2],Category[1],Product[2] false
Customer[1],Order[1],Item[2],Category[2],Product[2] false
Customer[1],Order[1],Item[2],Category[2],Product[3] false
Customer[1],Order[1],Item[2],Category[3],Product[1] false
Customer[1],Order[2],Item[3],Category[1],Product[1] false
Customer[1],Order[2],Item[3],Category[1],Product[2] false
Customer[1],Order[2],Item[3],Category[2],Product[2] false
Customer[1],Order[2],Item[3],Category[2],Product[3] true
Customer[1],Order[2],Item[3],Category[3],Product[1] false
Customer[2],Order[3],Item[5],Category[1],Product[1] false
Customer[2],Order[3],Item[5],Category[1],Product[2] false
Customer[2],Order[3],Item[5],Category[2],Product[2] false
Customer[2],Order[3],Item[5],Category[2],Product[3] false
Customer[2],Order[3],Item[5],Category[3],Product[1] false
The tuples that evaluate to true are:

Customer[1],Order[1],Item[1],Category[1],Product[2]
Customer[1],Order[1],Item[1],Category[2],Product[2]
Customer[1],Order[1],Item[1],Category[2],Product[3]
Customer[1],Order[2],Item[3],Category[2],Product[3]
The entities that survive the filter are:

Customer[1]
Customer[1],Order[1]
Customer[1],Order[2]
Customer[1],Order[1],Item[1]
Customer[1],Order[2],Item[3]
Category[1]
Category[2]
Category[1],Product[2]
Category[2],Product[2]
Category[2],Product[3]
The Scope section of the Rulesheet expands as follows:
Notice how the filter is applied towards each discrete entity referenced in the expression:
*When the filter is applied to Customer, then the survivor of the filter is Customer[1], if not applied then {Customer[1], Customer[2]} survive the filter.
*When the filter is applied to Customer.order then the surviving tuples are {Customer[1], Order[1]} and {Customer[1],Order[2]}. When not applied then it is the same (because there was no Order child of Customer[1] that did not survive the filter).
*When the filter is not applied at the Customer level as well as the Customer.order level, then all Customer.order tuples survive the filter with result {Customer[1],Order[1]}, { Customer[1],Order[2]}, {Customer[2],Order[3]}
*When the filter is applied to Customer.order.item then the surviving tuples are {Customer[1],Order[1],Item[1]} and {Customer[1],Order[2],Item[3]}. When not applied (at this level but at higher levels) then the surviving tuples will be {Customer[1],Order[1],Item[1]}, {Customer[1],Order[1],Item[2]}, {Customer[1],Order[2],Item[3]}
*When the filter is applied to Category then the surviving entities are Category[1], Category[2]. When not applied then Category[1], Category[2], Category[3].
*When the filter is applied to the Category.product level then the surviving tuples will be {Category[1], Product[2]}, {Category[2], Product[2]}, {Category[2], Product[3]}
You see how a filter applied (at each level) determines which entities are processed when a rule references a subset of the filter’s entities. With the limiting filters feature, the filter may or may not be applied to each entity referenced by the filter.