|
|
|
|
|
|
Introducing the Rules Framework
Rules Management forms a key part of the personalization process by prescribing a flexible and powerful mechanism for expressing business rules. 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.
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."
Business rules can by dynamically loaded or modified from the E-Business Control Center into a running server. This allows the Business Analyst to modify the site's flow and logic, and reduces their reliance on programmers.
Well-known Objects
The Rules Management component uses several well-known objects during the rule evaluation process:
Figure 3-1 The Rules Framework
How the Rules Engine Works
The Rules Engine functions by applying a set of rules to objects in working memory. This working memory is first populated with input from the calling objects, such as the user profile request session, among other things. In this way, 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 add new objects into the working memory. For example, if our Classifier rule tests for USER.age > 45, then we might add 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 an optional Object filter. The filter can selectively ignore objects or mutate them.
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.
Deploying Rule Sets
Rules sets are represented as XML files that can be read and edited by the E-Business Control Center. In order to propagate Rule Set changes that have been made in the E-Business Control Center, the corresponding Rule Set XML documents must be synchronized with the target application. In order to do so, the Rules Framework takes advantage of the WebLogic Personalization Server's Data Synchronization Framework. For more information about the data synchronization frameset, see the topic "Synchronizing Application Data" in theDeployment Guide.
When a user decides to deploy Rule Set changes from the E-Business Control Center to an application, the Data Synchronization Framework propagates Rule Set XML document updates to a Rules Manager instance within the target application. The Rules Manager parses the new Rule Set XML document into a binary representation understood by the BEA Rules Engine, and thereafter, application calls to the Rules Manager will use the new Rule Sets during rule execution.
It is important to note that the Rules Set XML documents that are managed by a particular instance of the Rules Manager are scoped to that application. That is, changes to Rule Sets are only seen by the target application and not by any other applications.
It is also important to note that changes to Rule Sets are immediate, and unlike previous WebLogic Personalization Server release, the Rules Manager no longer relies upon a time-to-live in order to propagate Rule Set changes throughout a cluster.
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 topic "Using Customer Segments to Target High-Value Markets" in the Guide to Using the E-Business Control Center.
Classifier rules dynamically categorize users into groups (user segments). 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 use pseudo-code to illustrate the logic involved in processing a classifier rule. Note the implicit and between the rule phrases.
This rule classifies a user who is male and is accessing the site between December 1 and December 26:
Classifier MaleChristmasShopper
If User has the following characteristics:
User.gender == "male" or "M"
and Date > 12/1 AND Date < 12/26
This rule classifies a user whose annual income is over one hundred thousand dollars:
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 execute a classifier rule in a JSP page. For a complete listing, see <pz:div> in the "JSP Tag Library Reference" topic of this guide.
The AND and OR operators
Figure 3-2 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. This simple illustration uses pseudo-code, and does not represent the actual XML used to represent these rules.
Figure 3-2 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 topic "Retrieving Documents with Content Selectors" in the Guide to Using the E-Business Control Center. Content selector rules invoke rule-based content queries that return content based on the user profile. This type of rule 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 invoke content selector rules in JSP pages. (For a complete listing, see <pz:contentSelector> in the topic "JSP Tag Library Reference" in this guide.) For an in-depth look at using content selectors, see Working with Content Selectors, in this guide. Debugging Rule Sets Note: The underlying structure of the Rules Engine has been enhanced for WebLogic Personalization Server release 4.0. If you have created rules and rule sets in previous versions of this product, please see 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 to function 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 various components of the Rules Framework are configured with an external configuration file called rules.properties. This file resides in the p13n_util.jar JAR file (within the com/bea/p13n/rules directory) that can be found in the root directory of any WebLogic Personalization Server application. This section explains each of the configuration properties that can be set in this file.
Note: Changes to the rules.properties file are only seen by the application in which the file resides. That is, this configuration file is scoped to the application. This makes it possible to configure the Rules Framework differently for different applications.
Rules Engine Expression Validation
If this property is set to true, the BEA Rules Engine will validate all Rules expressions (both conditions and actions) exactly one time. This property may be set to true during development and testing for additional expression validation.
##
# Rules engine expression validation:
#
# If this property is set to true, the rules engine
# will validate expressions the first time they are
# executed.
##
rules.engine.expression.validation=false
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.exceptions parameter is set to false, no exceptions will be propagated, and any condition expression that generates an exception will evaluate to false. Otherwise, all exceptions, except those listed with 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
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=
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 Parser
The following are internal properties and should not be modified.
##
# Rule Set Parser Node Support Classes
#
# This property supports a comma-delimited list of classes
# extending the base AST NodeSupport class. Such classes
# provide node creation support for rules-schema namespaces
# required for constructing the intermediate AST representing a
# given RuleSet instance.
#
# All NodeSupport subclasses must co-exist peacefully with the
# required CoreNodeSupport instance.
##
parser.node.support.list=\
com.bea.p13n.expression.internal.parser.expression.
ExpressionNodeSupport,\
com.bea.p13n.rules.internal.parser.wlcs.WlcsNodeSupport,\
com.bea.p13n.content.query.ContentQueryNodeSupport
##
# Rule Set Parser Transform Visitor Class
#
# This property specifies the ExpressionTranformVisitor or
# subclass to be used for intermediate AST-to-RuleSet
# transformations.
#
##
parser.transform=\
com.bea.p13n.rules.internal.parser.wlcs.WlcsTransformVisitor
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|