Pulkit's Technology Blog

TABLE OF CONTENTS 1. REQUIREMENTS 3 1.1 OVERVIEW 3 1.2 FUNCTIONALITY 3 1.3 NON FUNCTIONAL REQUIREMENTS 6 1.4 BUSINESS CONTEXTS 6 1.5 IMPLEMENTATIONS 6 1.6 REFERENCE ARTIFACTS 6 1.7 CREDITS 6 2. DESIGN 6 2.1 USE CASE 6 2.1.1 USE CASE DIAGRAM 6 2.1.2 USE CASE DETAILS 8 2.2 CLASS DIAGRAM 12 2.3 ACTIVITY DIAGRAM (LOGIC FLOW DIAGRAM) 14 2.4 SEQUENCE DIAGRAM 19 2.5 CLASS DESIGN SPECIFICATION 21 2.6 CONFIGURATION FILES 21 2.7 PROCESSING LOGIC 24 2.8 EXCEPTION HANDLING & ERROR MESSAGES 24 3 USAGE 25 3.1 USING THE ASSET 25 3.2 EXAMPLE 35 3.3 LIMITATIONS 40 3.4 OPEN SOURCE USAGE 40 RULES ENGINE 1. REQUIREMENTS 1.1 OVERVIEW A rule engine may be viewed as a sophisticated if/then statement interpreter. The if/then statements that are interpreted are called rules. The “if” portions of rules contain conditions such as shoppingCart.totalAmount > $100. The then portions of rules contain actions such as recommendDiscount (5%). The inputs to a rule engine are a rule execution set and some data objects. The outputs from a rule engine are determined by the inputs and may include the original input data objects with possible modifications, new data objects. The business rules/logics are defined in the rules engine and can be used by the client applications to execute them. This separation of business rules from the applications eases the overhead of defining and maintaining the business rules. The rule change can be done in the XML file (or database) and will have minimum effect on the other components of the application. 1.2 FUNCTIONALITY The Rule Engine to be implemented is a stateless rule engine. The basic functionality is as follows: a. The business rules are identified and kept in the rules.xml.the rule set will wrap these specific rules. b. The input to rules engine is a set of pojo objects, on which the business rules are applied. c. The output is a list of rulesetresultbean objects containing the results of actions. The result can contain the result of execution, failed objects, added objects, updated objects, etc. d. Client can use object filter to retrieve specific ruleresultset objects, depending on the business needs. Only the objects that pass the filter will be return after execution. e. The rule engine provides a few basic condition implementations, which include condition operations on string, integer, float, etc. However, more specific operations can be added and used. f. The rule engine can be configured to i. Stop execution even if one rule fails for a rule execution set ii. Execute all the rules of a rule set irrespective of failure g. The component should be able to load the rules and rule execution sets from Oracle database, along with XML (as supported in version 1.0). The queries for getting the rules and rule-sets from the Database are configurable in the Master Configuration file. Also, the input source type (XML or database) for reading the rules and rule execution sets has to be configured in the master configuration file. h. In case the rules and rule execution sets are configured in the XML files, the component should be able to load rules from multiple rules or rule execution set XML files. In case of configuration in database tables, the rules should be configured in one table and rule sets to be configured in another table. The names of the XML files or database tables should be configurable in the master configuration file i. The XML configuration parsing and reading has to be done using XML Pull parser. The current version (version 1.0) achieves this using DOM parser j. Communicate back the metadata of the rule that failed during the current execution k. Allow complex condition formation like , AND, and OR in the rules configuration. The current version (version 1.0) supports configuring condition classes in the rules. This will not suffice situations where the action has to be determined based on the combination of two or more condition expressions l. Allow passing parameters to the condition/action calls in the rules configuration. These parameters could be objects received as input to the rule or could be the constants defined in the rule. In the current version (version 1.0) the condition class receives input key and reference key attribute values as input. There could be situations where we need to pass more parameters/arguments to the condition class. Provision to pass multiple parameters to condition/action class through configuration will help address this issue For example: Condition expression currently supported is as below This can be changed to pass input parameters to the condition class as shown below: Also, the parameter value (value attribute of param element) expression could be an object from the input object list. This could be changed to accept an expression which gets an object from the list of input objects to the rule (RulesMediator. invokeRuleSet (final String strRuleSetUri, final List inpList, ObjectFilter objFilter)). It can be passed in an indexed manner as shown below. The parameter starting with “$” symbol will indicate that it has to be resolved from the list of input objects that are sent for rule execution. 1.3 NON FUNCTIONAL REQUIREMENTS None 1.4 BUSINESS CONTEXTS A rule engine is an independent self-contained piece of software that can read and interpret the rules defined for an application. The application logic resides in the form of rules and is not scattered across the application. The application decides what rule to use for a particular request sent by the user and thus dictates the further course of action. Rules Engines are the pluggable software components that separate the business rules from the application code. This allows the business users to modify the rules frequently without the need of IT intervention and hence allows the applications to be more adaptable with the dynamic rules. (Ex: Insurance and Banking sector the business rules will change frequently depending on the economic condition and the competition) Rules are written in terms of some conditions and the actions that need to be performed when these conditions are satisfied. 1.5 IMPLEMENTATIONS Rules Engine can be developed in line with JSR 94 Specification on the java platform. This will execute when a user or application invokes them, usually in a stateless manner. 1.6 REFERENCE ARTIFACTS i. JSR 94 specs: http://www.jcp.org/en/jsr/detail?id=94 ii. JSR 94 Reference Implementation: http://jcp.org/aboutJava/communityprocess/final/jsr094/index.html iii. Getting Started with Rules Engine: http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html 1.7 CREDITS ServCentrale Request No. 505 Requestor: Revanth_V IBU: IHLD 2. DESIGN 2.1 USE CASE 2.1.1 USE CASE DIAGRAM Rules Engine Administrator Rules Engine Client 2.1.2 USE CASE DETAILS USE CASE DETAILS: REGISTER RULE EXECUTION SETS Description The Rules Administrator can register the Rule Execution Sets in the Rules Engine. These rule executions sets will be registered against a given URI Special Requirements: NA Assumptions: NA . Pre-conditions: NA Post-conditions: NA Flow of Events/Requirements (Main Scenario): The Rules Engine registers the given rule execution set with the URI specified. Once the rule execution set is registered, it will be available for execution. Sub flows/ Alternate flows/ Scenarios: If a rule execution set was already registered with the URI specified, the old rule execution set will be replaced by the new one. Exceptions will be thrown in the following scenarios: If the registration URI specified is null or an empty string If the rule execution set given is null or invalid Screens NA Data Requirements NA Issues NA I. USE CASE DETAILS: UNREGISTER RULE EXECUTION SETS Description The Rules Administrator can deregister the Rule Execution Sets in the Rules Engine. Special Requirements: NA Assumptions: NA . Pre-conditions: NA Post-conditions: NA Flow of Events/Requirements (Main Scenario): The Rules Engine deregisters the given rule execution set with the URI specified. Once the rule execution set is unregistered, it will not be available for execution. Sub flows/ Alternate flows/ Scenarios: Exceptions will be thrown in the following scenarios: If the registration URI specified is null or an empty string Screens NA Data Requirements NA Issues NA II. USE CASE DETAILS: VIEW RULE EXECUTION SETS Description The Meta Data information of the Rule Execution Set can be retrieved for viewing/analyzing. The Rules Engine returns this meta data information about the specified rule execution set. Special Requirements: NA Assumptions: NA . Pre-conditions: The specified Rule Execution Set is already registered in the Rules Engine Post-conditions: NA Flow of Events/Requirements (Main Scenario): When the Meta Data information about the Rule Execution Set is queried, the Rules Engine compiles all the attributes and rules under it and returns them in the Meta Data object Sub flows/ Alternate flows/ Scenarios: Exception is thrown in the following scenarios: If the Rule Execution Set is not valid If the Rule Execution Set is no longer available Screens NA Data Requirements NA Issues NA III. USE CASE DETAILS: EXECUTE RULES Description The Client application can create a session for a particular rule execution set and execute the rules configured in it Special Requirements: NA Assumptions: NA . Pre-conditions: The requested rule execution set is registered and available for execution Post-conditions: NA Flow of Events/Requirements (Main Scenario): The client application calls the execute rules method of the Stateless Rule Session, which executes the rules that are configured in it. Sub flows/ Alternate flows/ Scenarios: Exceptions will be thrown in the following scenarios: If the session is invalid If the input list or object filter is invalid If the method calls, specified in the input key expressions in the rules configuration file, are not valid on the input object If the input objects could not be properly cast to the objects of the required input object. Screens NA Data Requirements NA Issues NA IV. USE CASE DETAILS: FILTER RESULTS Description The Client application can filter the result objects from the list of objects returned after executing the rules Special Requirements: NA Assumptions: NA . Pre-conditions: The filter object is given for filtering the results Post-conditions: NA Flow of Events/Requirements (Main Scenario): The client application calls the execute rules method of the rule session instance. The Rule session executes the rules in it and filters the results based on the filter object given. Sub flows/ Alternate flows/ Scenarios: Exceptions will be thrown in the following scenarios: Filter object is null or invalid If the rule execution was not successful Screens NA Data Requirements NA Issues NA V. USE CASE DETAILS: RETRIEVE RESULTS Description The Client application can retrieve results after executing the rules in the given rule execution set. Special Requirements: NA Assumptions: NA . Pre-conditions: The rule executions set successfully executed the rules configured in it Post-conditions: NA Flow of Events/Requirements (Main Scenario): After executing the rules configured in it, the rule session returns a list of result objects. Sub flows/ Alternate flows/ Scenarios: None Screens NA Data Requirements NA Issues NA 2.2 CLASS DIAGRAM 2.3 ACTIVITY DIAGRAM (LOGIC FLOW DIAGRAM) A. ACTIVITY DIAGRAM: REGISTER RULE EXECUTION SET B. ACTIVITY DIAGRAM: UNREGISTER RULE EXECUTION SET C. ACTIVITY DIAGRAM: VIEW RULE EXECUTION SET D. ACTIVITY DIAGRAM: EXECUTE RULES E. ACTIVITY DIAGRAM: FILTER RESULTS F. ACTIVITY DIAGRAM: RETRIEVE RESULTS 2.4 SEQUENCE DIAGRAM A. SEQUENCE DIAGRAM: UNREGISTER RULE EXECUTION SET B. SEQUENCE DIAGRAM: VIEW RULE EXECUTION SET C. SEQUENCE DIAGRAM: EXECUTE RULES D. SEQUENCE DIAGRAM: FILTER RESULTS E. SEQUENCE DIAGRAM: RETRIEVE RESULTS 2.5 CLASS DESIGN SPECIFICATION The following attached file contains the documentation of the java classes related to the component. 2.6 CONFIGURATION FILES Rules Engine uses the following configuration files: 1. Master Configuration File: It stores all the master configurations necessary for the rules engine. It specifies what rules and rule-sets are stored in which files along with the path of those files. It also specifies the source for the rules i.e. whether the rules for execution are stored in XML files or in Database. The database queries for getting rules and rule-sets are also configured here. Finally it has the Database Configuration details. It is explained in detail in the Usage Section. Below mentioned is an example configuration of this file rule1 rule2 membership-discount purchase-discount calculate-total-amount /checkOut2 uri2 /checkOut uri4 select rst.xml_column from RULESETTABLE rst where rst.URI=? select rt.xml_column from RULETABLE rt where rt.RULENAME =? jdbc:oracle:thin:@ oracle.jdbc.driver.OracleDriver Oracle blrkec96002d 1521 REUSE reuse reuse 2. Rules Configuration File: This configuration file is used to define the rules that should be used in the component. This XML file allows the user to mention different options and properties for rules. It is explained in detail in the Usage Section. Below mentioned is an example Rule that can be configured in Rules Configuration file.

3. Rules Execution Set Configuration File: A Rule Execution Set is a named set of executable Rule instances. Each Rule Execution Set will be bound to a unique URI and can be accessed by the clients using this URI. Rules Execution Set configuration file allows the users to define Rule Execution Sets and configure rules under them. It is explained in detail in the Usage Section. Below mentioned is an example of a Rule Execution Set. 4. Actions Configuration File: Actions Configuration file is a properties file which contains name-value pairs of Action Name and their corresponding Action classes. The Action elements defined in Rule XML file refer to this configuration to resolve the Action classes. Action classes can be configured as below: action.impl=com.infosys.qreuse.reuse.actions.impl.ActionImpl discount.computation=com.infosys.qreuse.reuse.actions.impl.DiscountComputationAction 5. Conditions Configuration File: Conditions Configuration File works the same way as Actions Configuration File. The condition classes to be used in Rules XML file should be declared in this configuration properties file. The Runtime classes of Rules Engine resolve the condition classes from this properties file. Condition classes can be configured as below: alphabets.only=com.infosys.qreuse.reuse.conditions.impl.AlphabetsOnlyCondition alpha.numeric=com.infosys.qreuse.reuse.conditions.impl.AlphaNumericCondition float.greaterThan=com.infosys.qreuse.reuse.conditions.impl.FltGreaterThanCondition 2.7 PROCESSING LOGIC The Processing logic of Rules Engine component is as explained below: 1. The Rules Mediator class registers the Rules Service Provider implementation class in the Rules Service Provider Manager class. This helps the client applications to get the Rules Service Provider implementation class and use the functionality of Rules Engine 2. When the client application tries to access the Rule Execution Sets, the Rules Engine checks if the Engine has been started and all the Rule Execution Sets are registered into the Repository. If the Engine is not started yet, it initiates the Startup activities. 3. The Startup utility reads the Rules XML and Rules Execution Set XML file and loads them into the Engine 4. The Rule Execution Sets read from these configuration files are then registered into the Repository of the Rules Engine. Once these activities are completed and the engine is started, the Rule Execution Sets will be available for execution 5. The Client applications can then get a Stateless session for a particular Rule Execution Set and execute the rules configured in it 6. The Rules Engine executes the Rules and returns the result to the client application 2.8 EXCEPTION HANDLING & ERROR MESSAGES Rules Engine uses a custom exception class “RulesEngineException” to communicate exceptional conditions to its classes. It uses the exception classes defined in JSR 94 specification to communicate exceptions to the client applications. For more information on exceptions of Rules Engine, please refer the API documentation of the JSR 94 specification. The component reads the error messages from a properties file, “ErrorMessages.properties”. All the messages to be displayed in case of exceptions are declared in this file. 3 USAGE 3.1 USING THE ASSET 1. Configuring the Master Details The elements that can be specified under the are as follows: • rules- It is used to specify the ruleNames and the files in which these rules are stored. This element has a sub-element ruleFile o ruleFile- This element specifies the XML files that store the Rule Elements. There can be any number of ruleFile elements , so we can store the rules in multiple XML files It has 2 attributes-  name- It is the name of the XML file containing the rules. For example, Rules.xml  path- It is the absolute path of the file on the system or on some other system on the LAN for which the application has access. It cannot be a FTP location  -The ruleFile element can have any number of ruleName elements  ruleName- These elements correspond to the names of the rules stored in the XML file specified by the above ruleFile element. Example- membership-discount purchase-discount calculate-total-amount • ruleSets- It is used to specify the ruleSetURI’s and the files in which the rule-Sets corresponding to these URIs are stored This element has a sub-element ruleFile o ruleSetFile- This element specifies the XML files that store the Rule Set details. There can be any number of ruleSetFile elements , so we can store the Rule Set Details in multiple XML files It has 2 attributes-  name- It is the name of the XML file containing the rule-sets. For example, ruleSet.xml  path- It is the absolute path of the file on the system or on some other system on the LAN for which the application has access. It cannot be a FTP location  -The ruleSetFile element can have any number of ruleSetUri elements  ruleSetUri- These elements correspond to the URIs of the rule-sets stored in the XML file specified by the above ruleSetFile element. Example- /checkOut uri4 • RuleSource- It is used to specify the source of the business rules and rulesets- i.e. XML files or Database. It has one attribute-  database- This is a boolean valued attribute to specify the source. o If its value is TRUE. the source of rules and rulesets is taken to be the Database o If its value is FALSE, the source of rules and rulesets is taken to be the XML files Example- • RuleSetQuery- It is used to specify the query for getting the rule-set from the database (when the rule source is database). The table-name and column-name for getting the Rule set is configurable here. An example for such a query is shown below- Example- select rst.XML_COLUMN from RULESETTABLE1 rst where rst.URI=? The Query contains the following- • Rule Set Table Name- It is the name of the table containing the rule-set. This name is configurable to any valid table name, as required by the application. In the example above, the name of the table is RULESETTABLE1. • Rule Set XML Column Name- It is the name of the column in the rule set table that contains the Rule-set XML element i.e. the XML element containing all the Rule-set details. This name can be configured to any valid column name, as required by the application. In the example above, the name of the Column is XML_COLUMN. • Rule Set URI column name- It is the name of the column in the rule set table that contains the Rule-set URI. This column is the primary key of the Rule Set Table and its name is also configurable. In the example above , the name of this column is URI • Rule Set table name alias- It is the alias name that we can give to the Rule Set Table Name and is also configurable here. In the example above, this alias name is ‘rst’. • ? for parameter setting in the query- The “?” in the query is replaced to the input Rule Set URI programmatically by the rules engine to get the Rule Set Details and the client application does not have to worry about it. • RuleQuery- It is used to specify the query for getting the rules from the database (when the rule source is database). The table-name and column-name for getting the Rule is configurable here. An example for such a query is shown below- Example- select rt.xml_column from RULETABLE1 rt where rt.RULENAME=? The Query contains the following- • Rule Table Name- It is the name of the table containing the rules. This name is configurable to any valid table name, as required by the application. In the example above, the name of the table is RULETABLE1. • Rule XML Column Name- It is the name of the column in the rule table that contains the Rule XML element i.e. the XML element containing all the details of the Rule .This name can be configured to any valid column name, as required by the application. In the example above, the name of the Column is XML_COLUMN. • Rule-Name column name- It is the name of the column in the rule table that contains the RuleName. This column is the primary key of the Rule Table and its name is also configurable. In the example above , the name of this column is RULENAME • Rule table name alias- It is the alias name that we can give to the Rule Table Name and is also configurable here. In the example above, this alias name is ‘rt’. • ? for parameter setting in the query- The “?” in the query is replaced to the input Rule name programmatically by the rules engine to get the Rule Details and the client application does not have to worry about it. • DBDetails- It is used to specify the Database Configuration Details. It has a configuration element that specifies the Database Configuration using the sub-elements  dbUrl- It gives the url format for connecting to the database  dbDriver- It specifies the JDBC driver for the database connection  dbType- It specifies the type of Database .Currently only Oracle is supported, but for future releases , this element can be changed to some other database type in order to connect to some other Database  dbHost- The Host name for database connection  dbPort- The port number for database connection  dbName- The database instance name  dbUserName- The username for connecting to the database  dbPassword- The password for connecting to the database Example- jdbc:oracle:thin:@ oracle.jdbc.driver.OracleDriver Oracle blrkec96002d 1521 REUSE reuse reuse - 2. Specifying the rule elements in the XML files or in the Database

Following are the attributes of a Rule and their corresponding functionalities: o Enabled: The Rule is enabled only if this attribute is set to true. Also, as this attribute is supported at the Rule Execution Set level, the value specified at the Execution Set level takes precedence over the value specified at the Rule level (for the given execution set). The table below shows how the rule is considered to be enabled based on the values specified in the two XML files: Enabled attribute in Rule XML file Enabled attribute in Rule Execution Set XML file Rule Enabled for the Rule Execution Set? True False False True True True False False False False True True o Date Effective: Date from which the Rule should be active. The date specified should follow the format, YYYY-MM-DD, where YYYY indicates year, MM indicates month and DD indicates date o Date Expires: Date on which the Rule expires or becomes inactive. The date specified should follow the format, YYYY-MM-DD, where YYYY indicates year, MM indicates month and DD indicates date o Priority: This attribute is used to order the execution of rules in the rule execution set. The rules are first ordered by their priorities (highest priority first), before executing them o Rule Implementation class: The implementation class of the rule. If you want to have your own implementation class of the Rule, you could change this value. But, the class that is specified in this attribute should extend the Abstract Rule class com.infosys.qreuse.reuse.rules.admin.AbstractRule.The class that is specified will be instantiated and invoked during runtime o Rule Name: Unique name given to the Rule o Rule Description: Description for the Rule o Role: Roles that can execute this rule. Current version does not provide implementation for this functionality o Stop on Fail: This attribute specifies if the execution of the Rule Execution set be stopped in case this rule fails. The value specified at the Rule Execution Set takes precedence over the value specified at the Rule level Stop On Fail attribute in Rule XML file Stop On Fail attribute in Rule Execution Set XML file Stop On Fail for Rule True False False True True True False False False False True True The elements that can be specified under a Rule element are as follows: o Reference Data: This element is used to define constant values that could be used by the rule. Reference data can be specified in two ways, and corresponding to it we have two sub-elements.  Single valued - Single valued data can have only one value  Multi valued - Multi valued data can have many values. When defining a data value for a constant it is necessary that you specify the data type of the value. The data types that are supported by the Rules Engine are: string, integer, boolean, byte, short, long, float, double and character. Example:

o Input Key: This element is used to specify the classes of the input objects that the Rule should be receiving. It has two attributes-  className – It is the name of the Java class whose object instance is being received as input by the rule.  keyName- It is like an alias name which provides a way of giving a name to the input object and referencing them in the “when” or “param” elements. Example: o When Element: A when element is used to evaluate a condition. If that condition evaluates to true, the “action” elements defined in it are executed. The when element has 3 attributes  testClass- It specifies the condition class that has to be executed to test a condition. This value of the “testClass” attribute is a key to the class name that should be executed. The mapping between this key and its corresponding condition class is to be mentioned in the Conditions configuration file.  inpKey- The input value to be used for condition evaluation is provided to when class using the “inpKey” attribute. The “inpKey” makes use of the key name defined in the Input Key element. The user can also call getter methods on the input object and evaluate the value to be passed to when class. For example inpKey=”cart.getPurchaseAmount()”.This will give the value returned by the method getPurchaseAmount() invoked on the object that is referenced by the key name “cart” Note: The methods that are called should not be expecting any input values  refDataKey- The reference value to be used for condition evaluation is provided to when class using the “refDataKey” attribute. For example refDataKey=”minimum-purchase-amount” .This will take the date value from the reference data whose name is “minimum-purchase-amount” The sub-elements of when element are  param- The inpKey and refDataKey attributes of the when element are optional. We can also pass parameters to the when element using the “param” element. Params are passed as name-value pairs. The param element has 2 attributes o name- It is the name of the parameter passed o value- It is the value of the param. There are 3 kinds of expressions supported for param values-  Method call on input object- In this the value of the param is obtained as the value returned by the method invoked on the object that is referenced by some key name. Example- value=”cart.getFltPurchaseAmount()”  Reference Data- In this, the param value is obtained as some data value from the reference data Example- value=”minimum-purchase-amount”  Object from input Object List- In this, the value of the param is obtained as an object from the input object list to the rule. This list is passed to the rule using the method RulesMediator. invokeRuleSet (final String strRuleSetUri, final List inpList, ObjectFilter objFilter)). It can be passed in an indexed manner. Example-value=”$inpObjList[0]”  action - Action element is used to execute an action class. The key of the action class to be executed will be specified here. The corresponding action class should be mentioned in the Actions Configuration file. If the condition in the “when” evaluates to true, the “action” elements defined in it are executed. There can be any number of action elements in the “when” element Example: o Choose Element: This element is similar to the switch-case statement of programming languages. It can have any number of when elements. It is used to execute the “action” elements of a “when” element whose condition evaluates to true. In case, none of the “when” element’s condition evaluates to true, we can have a default “action” for the “choose” element which would be executed then. Example: In the above example, if the first “when” condition evaluates to true, actionClass1 is executed. If the second “when” condition evaluates to true, actionClass2 is executed. If none of the “when” condition evaluates to true, the actionClass3 is executed. o Conditional Element: It is a logical extension of when. Using when element ,we can check only one condition for executing an action. By using a Conditional element, we can check multiple conditions before executing the associated actions and the result of these conditions can be joined using Logical operators(and/or) to get the final result of the Conditional Element. If the result is true, the actions specified in the actionslist are executed, otherwise not. The conditional element has 2 attributes-  Id – It is an identifier for this conditional element and is useful while using this element in the complex-conditional element  Operator- It is the logical operator (and/or) that is applied between the results of the conditions contained in this conditional element to get the final result of this conditional element. If the final result is true, the actions specified in the actionsList are executed, otherwise not. The sub-elements of conditional element are-  Condition- There can be any number of condition elements inside a condition element. It is similar to when element and has exactly same attributes as ”when” i.e. inpKey, refDataKey and testClass Also, params can be passed to the conditions in exactly the same way as in the “when” elements. But the difference from “when” is that condition element does not have actions. The results of all the conditions in a Conditional element are evaluated and combined using one logical operator (and/or). If the final result is true, the actions specified in the actionsList are executed, otherwise not.  actionsList- It is an optional element. There can be any number of action elements contained in it. Action element is used to execute an action class. The key of the action class to be executed will be specified here. The corresponding action class should be mentioned in the Actions Configuration file. If the final result of the conditional element is true, the actions specified in the actionsList are executed, otherwise not Example: In the above example, a conditional element is specified. The id for this conditional element is “con1”. The operator specified is “and” which means that the result of the conditions specified inside the conditional element are ANDed to get the final result for this. Two conditions are specified. The testClass for the first condition is “class1” and for the second is “class2”. Using the refDataKey, inpKey and the params passed, both the conditions are evaluated. So we get two Boolean results. Now these Boolean results are combined using AND operator. If the final result is “true” , the actions specified in the actionsList are executed, otherwise not. o Complex-Conditional Element: It is a logical extension of Conditional element. Using conditional element , we can check multiple conditions but we can combine them using only one of the operators. For further complex conditions, we can use Complex-condition elements which combines the result of multiple conditional elements using logical operators(and/or) to check before executing an action. If the final result of the Complex-conditional is true, the actions specified in the actionslist are executed, otherwise not. It can refer to conditional elements using the ref-conditional element whose ref-id attribute points to the id of an already specified conditional element. The complex-conditional element has one attribute-  operator- It is the logical operator (and/or) that is applied between the results of the conditional-elements contained in this complex- conditional element to get the final result of this complex-conditional element. If the final result is true, the actions specified in the actionsList are executed, otherwise not. The sub-elements of conditional element are-  ref-Conditional – It is used to refer to an already defined conditional element. There can be any number of ref-conditional elements inside a complex-conditional element which means that we can combine the results of any number of Conditional elements before executing the actions. The ref-conditional has one attribute  refid- It actually helps in referring to an already defined conditional element. The refid value here is the id value of an already defined conditional element The results of all the Conditional elements specified by the ref-conditional element in a Complex-conditional element are evaluated and combined using one logical operator (and/or). If the final result is true, the actions specified in the actionsList are executed, otherwise not.  actionsList - There can be any number of action elements contained in it. Action element is used to execute an action class. The key of the action class to be executed will be specified here. The corresponding action class should be mentioned in the Actions Configuration file. If the final result of the complex-conditional element is true, the actions specified in the actionsList are executed, otherwise not Example:

In the above example, a complex-conditional element is specified. The operator specified is “and” which means that the result of the conditional-elements specified inside the complex-conditional element are ANDed to get the final result for this. Two conditional elements are referenced using the ref-conditional. The conditionals that are referenced have their id as “con1” and “con2”. Both the conditional elements are evaluated and we get two Boolean results. Now these Boolean results are combined using AND operator. If the final result is “true”, the actions specified in the actionsList are executed, otherwise not. o Action Element: Action element is used to execute an action class. The key of the action class to be executed will be specified here. The corresponding action class should be mentioned in the Actions Configuration file. 3. Specifying the rule sets in the XML files or in the Database Following are the attributes of a Rule Execution Set and their corresponding functionalities: o Rule Set Name: The name of the Rule Execution Set o Rule Set Description: The description of the Rule Execution Set o Rule Set URI: This is the URI with which this Rule Execution Set has to be registered in the Rules Engine The rules that should be included in the rule execution set are configured in this element. 4. Specifying the mapping between action names and corresponding java classes in the Actions Configuration File Actions Configuration file is a properties file which contains name-value pairs of Action Name and their corresponding Action classes. The Action elements defined in Rule XML file refer to this configuration to resolve the Action classes. Action classes can be configured as below:- action.impl=com.infosys.qreuse.reuse.actions.impl.ActionImpl purchase.Discount.computation=com.infosys.qreuse.reuse.rulesengine.demo.PurchaseDiscountComputationAction membership.Discount.computation=com.infosys.qreuse.reuse.rulesengine.demo.MemberDiscountComputationAction calculate.total.amount=com.infosys.qreuse.reuse.rulesengine.demo.TotalCalculationAction 5. Specifying the mapping between condition class names and corresponding java classes in the Conditions Configuration File Conditions Configuration File works the same way as Actions Configuration File. The condition classes to be used in Rules XML file should be declared in this configuration properties file. The Runtime classes of Rules Engine resolve the condition classes from this properties file. Condition classes can be configured as below: alphabets.only=com.infosys.qreuse.reuse.conditions.impl.AlphabetsOnlyCondition alpha.numeric=com.infosys.qreuse.reuse.conditions.impl.AlphaNumericCondition float.greaterThan=com.infosys.qreuse.reuse.conditions.impl.FltGreaterThanCondition Once all the configurations and specifications are done , we can use the rules engine through the Rules Mediator NOTE: 1. The client should declare all the data that it intends to use in the reference-data in the input XMLs (single-valued or multi-valued reference data) .If it uses data without specifying it in the XMLs, the client application is bound to fail with some exception such as NullPointerException. The Rules Engine cannot have control over that. 2. The client application should give proper values for the reference data and for params in the input XMLs. The data type of the values expected in the client application and the values specified in the XMLs should be same, otherwise exceptions such as NumberFormatException will come up. 3.2 EXAMPLE Following are the details of a sample application of Rules Engine: Master Config File.xml Rules.xml Rules2.xml RuleSet.xml Rules Engine Demo Index Page Rules Engine Demo Show Total Amount Page 3.3 LIMITATIONS Following are the limitations of the current release of the Rules Engine component: 1. J2EE implementation is not supported in this release. The implementation for the component to be used, using JNDI is not provided in the current release 2. Implementation for Role validation of the Rule is not provided 3. Constant values cannot be specified in the Reference value of the When element. They have to be first specified in the Single Value Reference variable and then referred to in the When element 4. The Keys can be used to call the getter methods of the input objects. The values returned by these methods will be used as inputs to the condition classes. However, this feature cannot be used to call the instance variables or methods with input arguments 5. Both single valued and multi valued elements use the same "data" sub-element. The client has to specify the name for the multi-valued data elements in the input XMLs. Otherwise the client application is bound to fail with a NullPointerException. 3.4 OPEN SOURCE USAGE Note: Asset can be used only when there is provision in MSA for usage of open source. Open Source Used License type With or Without Modification Remarks ant.jar ant-launcher.jar ant-trax.jar commons-beanutils.jar commons-collections.jar commons-digester-1.8.jar commons-lang-2.4.jar commons-logging-1.1.1.jar log4j-1.2.14.jar serializer.jar servlet-api.jar struts.jar xalan.jar xercesImpl.jar xml-apis.jar Apache Without modification Necessary credits/details mentioned in source code Licensing details in PRIME needs to be mentioned as “Infosys IP with Open Source” to ensure end user will be aware of open source used for respective component.