This topic was last updated on: December 5, 2007
This topic addresses how to troubleshoot Business Rule Engine (BRE) issues that are related to running BizTalk RFID. It provides a description of symptoms, possible causes, and solutions for identified issues. The topic also gives you information about the BRE tracking information that you can use to debug BRE-related issues.
If you set the logging level of a process to Verbose, the tracking information for all BRE policies that are executed as part of the process is written to the process log file. You can find the process log file (<ProcessName>.log) in Program Files\Microsoft BizTalk RFID\Processes\<ProcessName>.
This tracking information contains:
- Facts activity. You will see the facts (data) that were asserted into the BRE's working memory and the facts that were retracted.
- Condition evaluation. You will see the details about the conditions that were evaluated.
- Agenda updates. The agenda is an ordered list of rule actions that the BRE executes. You will see the rules whose conditions evaluate to true. The rules whose conditions evaluate to false are not added to the agenda.
- Rule firings. You will see which policy rules fired and which did not.
| Note |
|---|
| BRE logging can be very extensive, and it can affect the performance of BizTalk RFID. We recommend that the log level of an RFID Process with one or more BRE components should be set to Verbose only to troubleshoot any BRE related issues. |
Policy does not execute successfully
Symptom
The BRE policy invoked by a BizTalk RFID process does not execute successfully.
Possible Causes
-
The policy has a rule that refers to database facts, but the database bindings for the policy are not specified.
-
Database bindings for the policy are specified, but they point to an incorrect database server and/or an incorrect database.
-
The policy has a rule that refers to XML facts, but the XML bindings for the policy are not specified.
-
XML bindings for the policy are specified, but the schema for the fact does not match the schema that the policy expects.
Solution
-
Specify the database bindings for the process if the policy used by the process refers to database facts.
-
Verify that the database bindings for the process point to a correct database server and correct database.
-
Specify XML bindings for the process if the policy used by the process refers to XML facts.
-
Verify that the schema specified in the XML bindings matches the schema that the policy expects.
You receive a "Policy is not available" error at process startup
Symptom
You receive a BRE error indicating that a deployed version of the policy is not available.
Possible Causes
-
The policy name property is not bound.
-
The policy name refers to a nonexistent policy.
-
The policy is not deployed.
Solution
-
Verify whether you have specified a policy name for the policy parameter of the RuleEnginePolicyExecutor component.
-
Verify whether the policy name that you specified in the grid is the same as the name in the Business Rule Composer.
-
Verify whether the specified policy is deployed in the Business Rule Composer. When you right-click the policy name, the Deploy option appears dimmed.
You receive a "Cannot open database" error at process startup
Symptom
You receive an error message similar to the following error message when you start a process that uses a BRE policy that requires database facts.
"Cannot open database "<Database name>" requested by the login. The login failed. Login failed for user '<Machine name>\<Identity for RFID process>'"
Possible Causes
-
The identity under which the RFID process is running does not have access to the database referred to by the BRE policy invoked by the process.
Solution
BizTalk RFID supports only Integrated Security for database facts. The user account under which the RFID process runs needs to have access permission to any database the BRE policy refers to. On Windows XP computers, the RFID process runs in the RfidServices.exe process. The identity for this process is RfidSvcAcc by default. The identity can be configured during the configuration. On Windows Server 2003 computers, the RFID process runs in a worker process (w3wp.exe) hosted in IIS. The identity for worker processes and RfidServices.exe is RfidWorkerProcessAcc by default, and the identity can be configured during BizTalk RFID configuration. Give the user account access to the databases(s) referred to by the BRE policy with required permissions.
You receive errors related to policy number mismatch
Symptom
You receive errors in the Business Rule Composer that are related to policies and policy versions initialization.
Possible Causes
-
The latest policy version is not deployed properly.
-
There is a mismatch in policy versions between those that you specified in the Business Rule Composer and the RuleEnginePolicyExecutor parameters.
Solution
Verify that the version of the policy file that is specified as a parameter to the Rule EnginePolicyExecutor component exists in the BRE database by using the Business Rule Composer.
Process does not pick up the latest deployed version of the policy
Symptom
Although you configured the RuleEnginePolicyExecutor component to pick the latest deployed version of the policy, the BizTalk RFID process does not use the version until after it is deployed.
Possible Cause
The BRE uses the value of the HKEY_LOCAL_MACHINE\Software\Microsoft\BusinessRules\3.0\PollingInterval registry key as the interval at which it checks for updates to the policy.
The default value is 60 seconds, which is appropriate for production environments. You should set this registry key to a value that is less than 60 seconds for development, test, or demonstration computers, so that the engine checks for updates more frequently.
Solution
Change the value of the PollingInterval registry key to a value that is less than 60 seconds.
Invoking static methods from a rule does not work
Symptom
A policy with a rule that invokes a static method of a .NET class fails at run time.
Possible Cause
-
By default, you must assert an instance of the .NET class into the working memory of the BRE, even though the method is a static method. If an instance of the class is not asserted, the policy fails to execute at run time.
Solution
Either assert an instance of the class into the working memory of the BRE or enable invoking static methods without requiring an object instance by setting the value of the following registry key to 1 or 2:
HKLM\SOFTWARE\Microsoft\BusinessRules\3.0\StaticSupport (DWORD)
The following table lists the possible registry values that you can enter.
| Value | Description |
|---|---|
0 | The default value. The static method is called only when an instance of the .NET class is asserted. |
1 | An object instance is not required. The static method is called when the rule is evaluated or executed. |
2 | An object instance is not required. The static method is called at the policy translation time if all parameters are constant. This is a performance optimization because the static method is called only once, even though it is used in multiple rules in conditions. Static methods that are used as actions will not be executed at the translation time, but static methods used as parameters can be executed. |
"Unable to connect to the Rule Engine Update Service" error when a process is started
Symptom
An RFID process with a RuleEnginePolicyExecutor event handler fails to start with the following error message in the process log file:
"Unable to connect to the Rule Engine Update Service. Please verify that the service is started. No connection could be made because the target machine actively refused it"
Possible Causes
-
The Business Rule Engine (BRE) components are not installed on the computer.
-
The BRE components are installed, but not configured.
-
The BRE components are installed and configured, but the Rule Engine Update service is not started.
-
You uninstalled and reinstalled BizTalk RFID. The RFID service starts all the processes at the end of the BizTalk RFID reinstallation, but before the BRE installation. Hence, a process with the RuleEnginePolicyExecutor component fails to find the Rule Engine Update service on the computer.
Solution
Install BRE components on the computer and configure them before starting the process that uses the RuleEnginePolicyExecutor component. The BizTalk RFID installation brings up the BRE installation at the end. You can also launch the BRE installation manually by running the Configuration.exe file in the %RFIDINSTALLDIR%\BREConfiguration folder.
BRE configuration fails because BizTalkRuleEngineDb.mdf already exists
Symptom
You get the following error message when you try to configure the BRE on your computer:
"Configuration failed for some components and no settings were applied for those components."
The configuration log file contains the following error message:
"Message: Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\BizTalkRuleEngineDb.mdf' because it already exists. Change the file path or the file name, and retry the operation."
Possible Causes
The BizTalkRuleEngineDb database has been detached from SQL Server and the BizTalkRuleEngineDb.mdf file exists on the computer in the C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA folder.
| Note |
|---|
| You will receive a "Database already exists" error message if the BizTalkRuleEngineDb database exists on your computer, and the database is not detached from SQL Server. |
Solution
Delete the BizTalkRuleEngineDb.mdf and BizTalkRuleEngineDb_log.ldf files from the data location for SQL Server (for example: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\) and retry configuring BRE.
