IBM An unexpected ruleset version is executed - United States  TECHNOTE (FAQ)

QUESTION
 Why is Rule Execution Server (RES) not executing the expected version of a ruleset ?
What are the possible causes after a hot deployment for Rule Execution Server not to use the updated ruleset ? 

CAUSE
Possible causes for unexpected versions to be executed are: 
- the RES client requesting execution may be passing a wrong ruleset path
- a hot deploy notification was not sent by the RES console, or not received by all the Execution Units (XU)
- the ruleset parsing policy may be delaying the use of a ruleset version until its parsing is complete
- the updated ruleset cannot be parsed successfully and RES falls back on an earlier active version that parses


ANSWER
First validate that the RES components (the Execution Unit, the Management Console and the Client Application bundling the RES client library, which may be HTDS, MTDS, the SSP or a custom application) have been installed properly as per the documentation, see Configuring Rule Execution Server [http://pic.dhe.ibm.com/infocenter/dmanager/v8r0/topic/com.ibm.wodm.dserver.rules.config/config_ds_res/tpc_res_config.html]. 

The ruleset version that is executed depends first on the ruleset path that is requested. Specifying a ruleset path with no version ( such as /MyRuleApp/MyRuleset/ ) is interpreted as a request to execute the highest version of the ruleset, as opposed to a version specific ruleset path ( such as /MyRuleApp/2.0/MyRuleset/1.0 ). Validate that the executed ruleset path is indeed unexpected considering the requested ruleset path. 

 

A common situation for an unexpected ruleset version to be executed is that of a hot deployment that is not successfully completed. The more frequent causes for the hot deployment not to happen as expected are: 

 * Permission issue: the user publishing the ruleset update must have sufficient administrative rights ( Monitor role in WebSphere Application Server ) in order for the deployment to notify all the Execution Units of the ruleset update through JMX. For example on WebSphere Application Server see Mapping the resAdministrators group to the Monitor role [http://pic.dhe.ibm.com/infocenter/dmanager/v8r0/topic/com.ibm.wodm.dserver.rules.config/config_ds_res_was8/tsk_was_map_admin_group.html] 
 * Version mismatch between the Execution Unit(s) and the Management Console: in order for the Management Console to detect the presence of execution units the versions of these components must match down to the fix level. For example 7.1.1.4 Management Console would not interact properly with a 7.1.1.3 Execution Unit. The version of the RES console is displayed in the "About" link (top right corner). The version of the Execution Unit can be seen in the resource adapter ra.xml file where a resourceadapter-version tag shows the version. For example with the WebSphere Application Server this can seen through: Resources > Resource adapters > XU > Deployment Descriptor 
 * Asynchronous ruleset parsing is used : in this mode, while an updated ruleset is being parsed, an earlier version of the ruleset can be used for executions that are requested at that time. Note that there is no guarantee of which specific earlier version of the ruleset may be used since it is a factor of which versions are available in the deprecated ruleset cache and whether garbage collection has occurred. In order to remove any uncertainty on the version that can be executed, it is possible to either turn off the asynchronous mode [http://pic.dhe.ibm.com/infocenter/dmanager/v8r0/topic/com.ibm.wodm.dserver.rules.res.managing/topics/tsk_res_config_asynchron_turnoff.html], or force synchronous parsing in asynchronous mode [http://pic.dhe.ibm.com/infocenter/dmanager/v8r0/topic/com.ibm.wodm.dserver.rules.res.managing/topics/tsk_res_config_forcing_sync_pars.html]. 
 * Notification scope is limited to one cell : by design the RES notification mechanism only works within one WebSphere Application Server Cell ( or one JBoss domain, or one Weblogic domain ), so a Management Console may only notify Execution Units that are running on servers in the same cell as the RES Console. See XU notification in a cluster over multiple cells [http://www-01.ibm.com/support/docview.wss?uid=swg21458245]. If you need to implement notifications to several cells at once, the document Ruleset updates and programmatic notification of RES eXecution Unit [http://www-01.ibm.com/support/docview.wss?uid=swg21418646] can be useful. 
 * Parsing failure of an updated ruleset : leading the XU to fall back on an earlier active version that parses successfully 
 * Ruleset update was only written to persistence: writing directly to RES persistence with the ant tasks res-write-db or res-write-file [http://pic.dhe.ibm.com/infocenter/dmanager/v8r0/topic/com.ibm.wodm.dserver.rules.res.managing/topics/tsk_res_deploy_rlapp_ant.html] does not trigger a notification, so the update may only been seen after server restart. 
 * XU MBean is not activated in Java SE mode : See Activating the XU MBean in Java SE [http://pic.dhe.ibm.com/infocenter/dmanager/v8r0/topic/com.ibm.wodm.dserver.rules.res.managing/topics/tsk_res_config_xu_mbean_jse.html] 
 * Multiple Java SE Execution Units are deployed in the same JVM: See Rule Execution Server J2SE mode hot deployment does not seem to work [http://www-01.ibm.com/support/docview.wss?uid=swg21585251] 

 


Cross reference information Segment Product Component Platform Version Edition Business Integration WebSphere ILOG JRules Modules:Execution Server (BRES / RES) Platform Independent 7.1.1, 7.1, 7.0.3, 7.0.2, 7.0.1, 7.0
Latest deployed ruleset not executing in clustered environment 

We are using ODM 8.7.0.1 and are running into an issue in our clustered environment. After deploying an updated to the ruleapp, using "Replace RuleApp Version" versioning policy, the that the decision service is still executing the previous version of the business rules.

Possible causes for unexpected versions to be executed are: 
- the RES client requesting execution may be passing a wrong ruleset path
- a hot deploy notification was not sent by the RES console, or not received by all the Execution Units (XU)
- the ruleset parsing policy may be delaying the use of a ruleset version until its parsing is complete
- the updated ruleset cannot be parsed successfully and RES falls back on an earlier active version that parses