|
|
|
|
|
|
Introducing the Rules Manager
Rules Management forms a key part of the personalization process by prescribing custom content to fit individual user profiles. The business logic encompassed by these rules allows robust delivery of personalized content marketed specifically to each end user type.
This topic includes the following sections:
What Is the Rules Manager?
WebLogic Personalization Server offers a robust personalization solution through a set of components that provide edit-time and run-time services for delivering personalized content to end users while browsing a Web site. These personalization components use business rules to match users and groups with appropriate content. The logic encompassed by the rules forms a critical piece of the personalization process.
The Rules Manager component of WebLogic Personalization Server provides editing, deploying, and run-time capabilities for providing personalized content based on externalized rules. This component includes two major parts: an edit-time tool with a graphical user interface (GUI) that allows Business Analysts to define classification and content selection rules, and a run-time service that matches users with content based on these rules.
Rules are created in the E-Business Control Center. This GUI tool is designed to allow Business Analysts to develop their own content selector rules and classifier rules. Because the Business Analysts are not exposed to the concept of rules, you will see content selector rules called simply "content selectors" and classifier rules referred to as "customer segments."
Well-known Objects
The Rules Management component uses several well-known objects:
Figure 1-2 The Rules Framework
How the Rules Engine Works
The Rules Engine functions with a set of rules operating on objects in working memory. This working memory is first populated with input from the calling objects, and contains the cached user profile bean, among other things. A representation of the user's profile exists in working memory before any rules are actually fired.
Rules can be executed only within a context. The context associates a rule set with working memory. The context provides an interface to the Rules Engine that controls the relationship between the rule part of the application and the working memory.
This working memory is operated on by the production rules, which are contained in rule sets. The left-hand sides (LHS) of these rules are evaluated against the objects in the working memory. If the patterns on the LHS are matched, then the actions contained in the right-hand side (RHS) of the rules are performed. Some of these actions may assert new objects into the working memory. For example, if our Classifier rule tests for USER.age > 45, then we might assert a new Classification object into working memory.
The production system is executed by performing the following operations:
Rules will continue to operate on the working memory until the conflict resolution set is zero (that is, no more rules can fire).
After the Rules Engine has halted, the rules manager component returns a list of objects remaining in working memory. A likely scenario will have an object remaining of the type "Classification" or "ContentQuery."
The Rules Manager will then iterate over these remaining objects and filter them using the optional Object Filter. The filter can selectively ignore objects or mutate them.
The resultant objects, if any, are then returned to the Advisor.
What Are Rule Sets?
The BEA WebLogic Personalization Server provides two rule sets that act as containers for the rules created in the E-Business Control Center: the global classifications rule set and the global content selectors rule set.
Rules within a rule set may refer to any properties. In general, you should not change or delete properties if a rule refers to it. Adding properties does not affect existing rules.
Classifier Rules
Classifier rules are created in the E-Business Control Center. For information and instruction on creating classifier rules (called "customer segments" in the E-Business Control Center), see the chapter "Using Customer Segments to Target High-Value Markets" inUsing the E-Business Control Center.
Classifier rules dynamically categorize users into groups (user segments) using Boolean logic. A classifier rule determines if a user profile meets a set of conditions and places the user in a category based upon the result. Essentially, if the user profile meets the conditions, it is classified according to the classifier rule; if it does not meet the classification conditions, the user profile is not included in the classification group.
The following examples illustrate the logic involved in processing a classifier rule (note the implicit and between the rule phrases):
Classifier MiddleAgeMan
If User has the following characteristics:
User.age > 35 AND User.age < 65
and User.gender == "M" OR "male"
Classifier HighEarner
If User has the following characteristics:
User.income > 100000
Classifier rules are the building blocks of more complicated rules. Content selector rules can use classifier rules as they select personalized content to match a user or group profile. (See Content Selector Rules below.)
Use the <pz:div> JSP tag to include a classifier rule in a JSP page. For a complete listing, see <pz:div> in the "JSP Tag Library Reference" chapter of this guide.
The AND and OR operators
Figure 1-3 shows an example of clauses ANDed and ORed together. By default, all clauses in a rule are ANDed together.The <or> operator is applied to nested (indented) child clauses below the <or> operator. In that case, the nested statements are ORed, and ANDed to clauses not nested around them.
Figure 1-3 AND and OR Example
Content Selector Rules Content selectors are created in the E-Business Control Center. For instructions on using the GUI tool to create content selectors, see the E-Business Control Center online help. A copy of the information presented in online help is available on the e-docs Web site-see the chapter "Retrieving Documents with Content Selectors" in Using the E-Business Control Center. Content selector rules construct queries on the fly and return content based on the user profile. This type of rule adds time and content components to the basic classifier rule and may use references to classifier rules to define it. It also produces dynamic queries at runtime to select content from a document collection. The power of producing dynamic queries that match content with user profiles allows content selectors to deliver highly customized content to end users. Since content selector rules can use queries to select content based on run-time parameters, they allow the system to match personalized content to user profiles. Note: Although a profile may meet the criteria of a content selector rule, the rule may not return any content objects. Why? If no content matches the query's criteria, the query cannot return a content object. You can use the <pz:contentSelector> JSP tag to include content selector rules in JSP pages. (See <pz:contentSelector> in the chapter "JSP Tag Library Reference" in this guide.) For an in-depth look at using content selectors, refer to Working with Content Selectors, in this guide. Debugging Rule Sets Note: The underlying structure of the Rules Engine has been greatly enhanced for WebLogic Personalization Server release 3.5. If you have created rules and rule sets in previous versions of this product, please refer to the Migration Guide for additional information. What Is the Relationship Between Property Sets and Rules? You might notice that a rule set you have used in the past begins functioning incorrectly. This behavior is probably due to a change in the property set with which the rule set has a relationship. Rules rely on property sets to provide the properties they use to evaluate user and group profiles. If a property is modified after a rule that uses it has been created, rules may contain dangling references to properties that no longer exist or that have been changed. As much as possible, you should avoid modifying properties after defining rules that rely upon them. Since the property set defines the schema for the properties the rules act upon, any change to the properties the rules use will affect the schema and may alter the validity of the rules. In general, be careful when modifying or deleting existing properties. Note: You can add properties without affecting existing rules. Content Type and Content Selector Rules Another problem can occur when you change a content's metadata types after creating a content selector rule based on that content type's metadata. Remember that the content selector rule relies upon metadata to locate content. If you change content metadata and a content selector rule references the previous metadata, the rule will not work correctly.
Configuring the Rules Framework
The set of components that use business rules to match users and groups with appropriate content are known collectively as the rules framework. Two files configure the properties of the rules framework:
The RulesManager Deployment Descriptor
Within the file $WL_COMMERCE_HOME/config/wlscDomain/applications/wlscApp/rules.jar is a file named ejb-jar.xml which specifies how WebLogic Personalization Server deploys the rules EJB.
The following <env-entry> element in the ejb-jar.xml deployment descriptor prevents differently deployed RulesManager beans from seeing each others' deployed rulesets.
<env-entry>
<env-entry-name>namespace</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>default</env-entry-value>
</env-entry>
Rulesets are stored in the RULESET database table. Table 1-1 illustrates the contents of the NAME and DOCUMENT columns in the RULESET database table.
|
NAME |
DOCUMENT |
|---|---|
|
default/MyRuleSetName |
XML data for the RuleSet (as a CLOB) |
|
default/MySecondRuleSet |
XML data |
By default, the namespace for Rule Sets is default, which is prepended to the RuleSet name. By modifying the value in the <env-entry-value> element that is described in this section, you can change the composite name that a RulesManager EJB stores in the database.
The rules-common.properties file
The rules-common.properties file is located in $WL_COMMERCE_HOME/classes. It configures the following properties:
Rules Framework Debugging
This property should normally be set to false.
# Rules framework debug flag:
#
# Set this property to true for rules framework debugging. Defaults
# to false.
##
rules.framework.debug=false
Rule Set TTL
This property determines the time-to-live (in milliseconds) of the cached rule sets. In a single node deployment, this parameter should be set to -1 (no timeout); however, if the rules manager is deployed in a clustered environment, this parameter will determine the maximum elapsed time between updates of a rule set (via the E-Business Control Center) and propagation of the changes throughout the cluster.
##
# Rule set expiration TTL (in milliseconds):
#
# Set this property to -1 for infinite TTL. Defaults to -1.
##
rule.set.expiration.ttl=-1
Rules Engine Listeners
This is an internal property, and should not be modified.
##
# Rules engine startup rule event listeners (list of class names).
##
#rules.engine.startup.listeners=com.bea.commerce.platform.rules.internal.engine.RulesEngineStatisticsListener
Rules Engine Expression Caching Optimizations
This is an internal property, and should not be modified.
##
# Rules engine expression optimizations:
#
# 0 => No expression optimizations.
# 1 => Local expression optimizations.
# 2 => Global expression optimizations.
#
# Defaults to 0.
##
rules.engine.expression.optimizations=2
Rules Engine Error Handling and Reporting
The following two properties determine the type of exceptions that will be propagated to the user during rules engine execution. If the rules.engine.throw.expression.exception parameter is set to false, no exceptions will be propagated, and any expression condition that generates an exception will evaluate to false. Otherwise, all exceptions, with the exception of those listed by the rules.engine.ignorable.exceptions parameter, will be propagated to the user.
# Rules engine pattern expression execution error handling:
#
# rules.engine.throw.expression.exceptions
#
# If this property is set to true, pattern expression
# execution exceptions will be thrown. Otherwise, a pattern
# expression exception will cause the pattern condition to
# evaluate to false.
#
# Defaults to true.
#
# rules.engine.throwable.exceptions (list of class names)
#
# If the previous property is set to true, expression exceptions
# with embedded exceptions of a type other than the listed classes
# will be thrown. If no class types are specified, all expression
# exceptions will be thrown.
#
# Defaults to all exception class types.
##
rules.engine.throw.expression.exceptions=true
rules.engine.ignorable.exceptions=java.lang.NullPointerException
JSP Tag Properties
These are internal properties, and should not be modified.
##
# JSP Tag settings
##
# Filter class for ContentSelectorTag
contentselector.filter.class=com.bea.commerce.platform.content.advislets.ContentQueryAdvice
# Filter class for DivTag
divtag.filter.class=com.bea.commerce.platform.user.Classification
Rules Manager Properties
These are internal properties, and should not be modified.
#
# RulesManager settings
#
# RulesManager JNDI name.
rules.manager.home.jndi=com.bea.commerce.platform.rules.manager.RulesManager
# RulesManager delegate class name.
#delegate.class.name=com.bea.commerce.qa.platform.rules.manager.internal.RulesEvaluationDelegateStubImpl
Expression Evaluation Settings
The rules.framework.comparator.nullcheck property determines if an implicit null check is added to all expression comparisons. It should remain true.
The rules.framework.comparator.epsilon property determines the epsilon value for numeric equality and inequality comparisons. The epsilon value is an absolute value (rather than a percentage, etc.) and may be adjusted in accordance to equality precision requirements.
The rules.framework.introspector.method.array.cache property and rules.framework.introspector.method.cache property are internal properties and should not be modified.
##
# Expression Comparator null handling
#
# If the following property is set to true the Expression
# Comparator will return false as the result of comparing
# any non-null value to a null, regardless of the
# comparison being performed.
#
# Defaults to true.
##
rules.framework.comparator.nullcheck=true
##
# Expression Comparator equality epsilon.
#
# The following property determines the epsilon value for
# numeric equality comparisons.
#
# Defaults to 0.
##
rules.framework.comparator.epsilon=0.00001
##
# Expression Introspector Method Array Caching
#
# If the following property is set to true the Expression
# Introspector will cache the array of Methods implemented by a
# Java Class.
#
# Defaults to true.
##
rules.framework.introspector.method.array.cache=true
##
# Expression Introspector Method Caching
#
# If the following property is set to true the Expression
# Introspector will cache Methods by signature.
#
# Defaults to true.
##
rules.framework.introspector.method.cache=true
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|