Query Conditions

ILOG JRules User Guide > Querying and Reporting > Concepts > Queries > Query Conditions

Query Conditions

When you write a query condition, you start by selecting a project element type, then refine the search by filtering on its properties, its definition, or its semantic content.

By default, queries are run on business rules, but you can also search on other project elements:

specific types of business rule: action rules, decision tables, decision trees, or on your own rule class if you extend the rule model
rule packages, rule artifacts, technical rules, ruleflows, templates, functions, variables, or variable sets.

Once you have selected the project element you want to query, you can refine the query by adding a filter in the form of a such that statement, followed by an appropriate condition statement, or statements. The statements available for you to select depend on the type of project element you have chosen and the elements defined in the BOM.

Examples

Find all ruleflows
   such that each ruleflow is in package "accounts"

Or:

Find all business rules
   such that the effective date of each business rule is after 31/7/2007

You can further refine queries by specifying more than one statement. For example:

Find all business rules
   such that the effective date of each business rule is after 31/7/2007
   and the effective date of each business rule is before 31/8/2007

You can refine queries using a such that statement to filter:

Project Element Properties

You can refine a query by filtering on one of the properties of the project elements being queried, such as name, status or effective date. Note that name is a standard rule property. Status and effective date are extended properties, provided by the default extension model.

You can run this type of query against any type of project element. This type of query is useful for carrying out a rule audit.

Examples

The following query returns all business rules in your workspace with a status of new:

Find all business rules
   such that the status of each business rule is new

The following query returns all variables in any package in your workspace called accounts:

Find all variables
    such that each variable is in package "accounts"

Project Element Definitions

You can refine a query by filtering on project element definitions. This type of query finds rules that use or modify the value of a member or invoke a method.

You can run this type of query against any type of rule. It is useful for identifying rules impacted by policy change.

You can use the following query predicates:

uses the value of (an attribute, a ruleset parameter or variable) - returns rules that use the values of certain members
uses the phrase (a method verbalization) - returns rules that call a given method
modifies the value of (an attribute, a ruleset parameter or variable) - returns rules that modify certain members
is using BOM class - returns rules that use a certain BOM class (Rule Studio only)
is using BOM member - returns rules that use a certain BOM member (Rule Studio only)

You can also use negations of each of these predicates.

Note

Queries with the is using BOM class or the is using BOM member predicate will work only if the workspace has been rebuilt since the last modification. If not, the results may not be accurate.

You would normally run the is using BOM class and is using BOM member queries against technical rules, although you can use these predicates for any type of rule.

Examples

The following query returns all business rules that use loan grade values:

Find all business rules
   such that each business rule uses the value of the loan grade in 'a report'

The following query returns all action rules that invoke the method that adds a number to the corporate score in a report:

Find all business rules
   such that each action rule uses the phrase [ add 'a number' to the corporate
   score in 'a report' ]

The following query returns all decision tables that modify the value of the insurance rate ruleset parameter:

Find all decision tables
   such that each decision table modifies the value of 'the insurance rate'

The following query returns all business rules that read or modify the amount attribute of the Loan class:

Find all business rules
   such that each business rule is using the BOM Member "loan.Loan.amount"

The following query returns all business rules that use the class Borrower:

Find all business rules
   such that each business rule is using the BOM class "loan.Borrower"

Semantic Content

You can refine a query by filtering on the semantic content of a rule, which denotes rule behavior. This type of query uses the phrases of the vocabulary that refer to members. It finds rules that could be applicable when certain conditions are or become applicable. It is useful for testing the conditions under which rules would be fired to make sure that they behave as expected.

You can run this type of query against the following project elements:

action rules: a type of business rule whose purpose is to perform an action
business rules: rules written using the Business Action Language (BAL)
decision tables: business rules written in table format, where each row corresponds to a single rule
decision trees: business rules written in the form of a tree
technical rules: rules written using the ILOG Rule Language (IRL)
all rules: any type of rule, including decision tables or decision trees

You can use the following query predicates:

may apply when (a condition) - returns all rules whose condition part could meet the query condition, or where there is nothing in the rule condition that would contradict the query condition. This query can thus include rules with conditions that are not specifically relevant to the query condition.
may become applicable when (a condition) - a more specific query that returns only those rules whose condition part could meet the query condition. It does not return rules with conditions that are not specifically relevant to the query condition.
may lead to a state where (a condition) - returns rules that, when executed, could show a result that meets the query condition. This query takes into account both the condition and action parts of a rule. It filters rules based on their effect. It does not, therefore, return rules that have no influence on the query condition.

You can run a query only on all rules of the current project, or all rules of the current project and its dependent projects.

Example: may apply when

Rule 1: If the score of the borrower is at least 10 then...

Rule 2: If the age of the borrower is at least 21 then...

Rule 3: If the score of the borrower is less than 10 and the age of the borrower is more than 35 then...

Query 1:

Find all business rules
   such that each business rule may apply when the score of the borrower is 20

Query 2:

Find all business rules
   such that each business rule may apply when the score of the borrower is 5

Query 1 returns Rule 1 and Rule 2. It returns Rule 1 because if the borrower's score is at least 10, then it could be 20. It returns Rule 2 because there is nothing in Rule 2 that specifically says that the condition could not hold: that is, that the borrower's score could not be 20. It does not return Rule 3 because it contains a condition (score less than 10) that specifically indicates that the rule could not apply.

Query 2 returns Rule 2 and Rule 3. Rule 1 cannot apply since the query condition sets the score to below 10. In Rule 2 there is nothing that specifically stops the rule from being applicable when the score is 5. In Rule 3 at least one of the conditions could apply, and there is nothing in the other one that negates the fact that the score could be 5.

Example: may become applicable when

Rule 3: If the category of the customer is Platinum then...

Rule 4: If the category of the customer is not Platinum then...

Rule 5: If the age of the customer is at most 65 then...

Rule 6: If the age of the customer is at most 65 and the category of the customer is not Platinum...

Query:

Find all business rules
   such that each business rule may become applicable when the category of
   'a customer' is Gold

This query returns Rule 4 and Rule 6. It returns Rule 4 because if the category of the customer is not Platinum, it could be Gold. It returns Rule 6 for the same reason. The additional condition relating to the customer's age does not contradict the condition in which the category may be Gold.

The query does not return Rule 3 because a rule that applies when the customer category is Platinum will not apply when the category is Gold. It does not return Rule 5 because we are looking for rules that could become applicable when the customer category is Gold, and the age of the customer is not relevant to this query. In other words, the condition of the rule cannot be impacted by the fact that the customer's category is Gold.

Example: may lead to a state where

Rule 7: If the age of the borrower is at least 25 then set the credit score of the borrower to 60

Rule 8: If the age of the borrower more than 18 and less than 25 then set the credit score of the borrower to 20

Query:

Find all business rules
   such that each business rule may lead to a state where the credit score of
   the borrower is more than 50

This query returns Rule 7 but not Rule 8 since, once the age of the borrower has been checked and the credit score set, only Rule 7 shows a result of over 50.