BRE State XML

 

When an application or the Rules Designer Test screen executes the RuleLab.Net BRE, it returns an updated application XML document along with the BRE State XML document. The BRE State document contains results of the last BRE pass. If your application requires a multi-pass BRE processing, it will have to supply the BRE State document on input for each subsequent pass.

 

The BRE State contains the following information:

  • fired rule identifiers that instruct the BRE not to execute these rules in the subsequent passes
  • list of fields/data assigned by the rule (your application can use it as needed)
  • list of “missing” data fields that prevented the rule condition from evaluation (reason the rule was not satisfied)
  • list of rule conflicts that your application can use to overwrite the default conflict resolution
  • system data assigned by the BRE that must be carried over into the subsequent passes

 

The following XML documents contain the full specification of the BRE State:

BRE State XML Schema

BRE State XML document template

 

BRE State Format

 

Fired Rules Count

 

<countOfRulesFiredThisPass> tag contains the number of rules that fired during the most recent pass. The count of zero means that no new rules were satisfied during the last pass therefore an application should terminate the BRE session unless it has new data to supply. If the application initiates multiple BRE passes while collecting additional data in between, then it should always be checking this count. If setting new data does not satisfy any new rules then there is no point in continuing the current BRE session by initiating the next BRE pass.

 

 

Evaluated Rules Count

 

<countOfRulesEvaluatedThisPass> tag shows how many rules were processed. This number is provided for information purposes only. You can use it for statistical purposes.

 

BRE Processing Time

 

<msBREProcessingTime> tag contains the number of milliseconds it took the BRE to run all cycles of its pass.

 

Total Processing Time

 

<msTotalProcessingTime> tag contains the number of milliseconds it took to load all RuleLab.Net’s applicable objects, validate application data and execute the BRE. In a web service method, this number represents Server execution time which could be affected by other processes running on the server. It does not include transmission time to and from the client application.

 

Fired Rules

 

<firedRules> tag contains a list of <r> tags with the Rule Identifiers. This list informs the BRE of all the rules that fired during the preceding passes of the current session. This list should be passes back to the BRE as is if you would like to continue the BRE session.

 

Evaluated Rules

 

<evaluatedRules> tag is only filled when enableRuleEvaluationDetails  flag is set. The Web Service allows setting it through the SOAP Header while the BRE component has a corresponding method. This flag must be enabled if you are using the Reasoning method of the BRE.

 

<evaluatedRules> tag contains the <rule> tags each corresponding to a rule evaluated by the BRE. Every <rule> tag has 3 attributes:

§         id – an identifier of the rule that appears in the Rule Browser screen

§         fired – indicates whether the rule has fired (true/false)

§         result – if fired, whether the rule evaluated to true or false

 

The following child tags can appear under the <rule> tag:

§         <failedData> - if a rule evaluated to false, this tag will list variables (XML Reference Aliases) that caused the condition to fail

§         <missingData> - if a condition or a precondition could not have been executed due to missing data in your application XML document, the unresolved References will be listed here as variables. A rule is not satisfied until all of its atoms are related to data. An application may have to obtain the missing data by prompting the user, querying the database etc etc. Note that missing loop items are not considered “missing data”.

§         <assignedData> - if a rule action has been executed, this section will list your application XML fields assigned to by the Action clause. Each data item is listed as a variable along with your XML path and data value.

 

The variable <var> contained in the above sections contain 2 or 3 tags depending on the context:

 

Rule Conflicts

 

<conflicts> tag is only filled when the  enableRuleConflictDetails  flag is set. The Web Service allows setting it through the  SOAP Header while the BRE component has a corresponding method.

 

<conflicts> tag – the BRE State contains a “conflicts” section listing application data fields that several rules attempted to change. Each will contain a list of rules and their attributes. All rules that attempted to change this field during the BRE pass are listed along with the value they tried to assign. The conflict between these rules is being resolved per the specification in the “Rule Conflicts” section of the RuleLab.Net Architecture. The winning rule is indicated by the “changedByRule” tag.

 

Your application can overwrite the default resolution using the information in this section. To overwrite, copy Value from the desired conflicting rule section into your application field data. This will overwrite the value assigned by the “changedByRule” rule.

 

Rule Conflict format

 

If any rule conflicts have been detected, then the <assignmentConflict> tags will appear under the <conflicts> tag. Each <assignmentConflict> corresponds to a single variable assignment and contains the following tags:

 

<targetVar> - the variable that a number of rules are conflicting over to assign values. It contains

§         <alias> - Reference alias

§         <xpath> - XML path in your application XML document

 

<assignedByRule> - an ID of the rule that assigned the updated value to “targetVar”.

 

<conflictRuleSet> - lists all the rules that attempted to change the “targetVar”, including the “assignedByRule”. Each rule is described by a <conflictRule> tag listed under the <conflictRuleSet>. Each <conflictRule> tag contains:

§         <ruleID> - an ID of the rule that attempted to change the “targetVar”

§         <value> – data value that this rule wanted to assign to the “targetVar”.

 

Assigned System Data

 

System variables are the ones that are listed in your XML References screen with no XML path. You can assign to them and use them in the rule conditions upon assignment. Since there is no room for them in your application XML, they live in the BRE State document. Each assigned system variable is represented by a <var> tag placed under the <assignedSystemData> tag. Each tag will contain the <alias> and <value> tags but no <xpath> tag.

 

Note that you can modify system variables under the “assignedSystemData” section prior to executing a subsequent BRE pass.

 

Changing State Fields

 

BRE reads the following fields to determine its current state:

 

You can alter these values between passes to fit your application needs. 

 

Related topics

 

System architecture

BRE Web Service