| Oracle® Communications Service Broker Policy Controller Implementation Guide Release 6.0 Part Number E23528-02 |
|
|
View PDF |
| Oracle® Communications Service Broker Policy Controller Implementation Guide Release 6.0 Part Number E23528-02 |
|
|
View PDF |
This chapter describes how to create rules and rulesets using the Rule Editor tab of the Policy Designer.
The rules engine used by Policy Controller is built on the rules engine for Oracle Business Rules, an Oracle Fusion Middleware product. For general information about Oracle Business Rules, see Oracle Fusion Middleware User's Guide for Oracle Business Rules at:
http://docs.oracle.com/cd/E17904_01/integration.1111/e10228/toc.htm
Policy Controller uses rules to select policy profiles to apply to subscribers.
You create rules by using the Rule Editor tab of the Policy Controller Policy Designer interface. A knowledge of programming with a third-generation programming language is very helpful for understanding the Rule Editor tools and creating rules.
A rule has two parts: an IF section and a THEN section. The IF section contains a condition based on evaluation of data from various sources. The THEN section contains actions that can be performed. If the condition in the IF section evaluates to true, the rule performs the actions in the THEN section. The actions usually involve dynamically applying a Policy Profile to a subscriber or removing a Policy Profile from a subscriber, but they may involve other actions as well.
You can create collections of rules to work together with one another.
You can set up the rules to select a single Policy Profile for the entire service flow. Policy Controller also allows you to reinterpret the rules as the service flow continues and the input data, such as the approach of a resource limit, changes.
Rules can be added, modified, and deleted whenever required and can also be activated and deactivated individually.
The following components, which are related to rules, appear in the rule editor:
Rules are based on facts. A fact represents a piece of data. In the context of the rules engine, a fact is an asserted instance of a class. It has a type and a value.
A ruleset provides a unit of execution for a collection of rules. You can prioritize the rules within a ruleset.
A bucketset defines a set of values for a particular fact or a property of a fact.
A decision function provides a contract for invoking rules. Policy Controller uses a single predefined decision function: PCRF_DF.
A dictionary is a container for any number of rulesets, and their supporting bucketset and set of decision functions. They can be saved as is xml files with a .rules extension. You can import a dictionary into the rule editor to modify it, and then export it from the rule editor to a file.
The general workflow for implementing rules is:
Create a ruleset.
Create the rules in the ruleset.
Create the bucketset and decision functions as needed to support the rules.
Validate the ruleset.
Deploy the ruleset and supporting bucketset and functions as a dictionary. Once deployed, the rules are applied to your Policy Controller subscribers.
You perform these procedures in the Rule Editor tab of the Policy Designer. The Deployments tab displays the rulesets for individual dictionaries, but does not show details for the bucketset and functions.
When you click the Rule Editor tab, a default dictionary of currently deployed rules is loaded into the rule editor. This dictionary contains facts on which you can base your rules. You can also create a custom fact for use in your local rules.
To save an incomplete set of rulesets, with their bucketset, and decision functions to work on later, export the dictionary that contain them to an external .rules file. When you are ready to resume work, import the .rules file containing the dictionary back into the rule editor. When you are ready to resume work, import the .rules file containing the dictionary back into the rule editor.
A rule is dynamically associated with a policy when an Assert New action asserts the Out_InstallPolicy fact. A rule is dynamically disassociated from a policy when an Assert New action asserts the Out_RemovePolicy fact. See "Defining an Assert New Action" for more information.
You can create a policy profile from the Policy Profiles menu of the rule editor, as well as from the profile editor. See "Creating Policy Profiles" for information on how to do this.
In the rule editor, you have the option of showing or hiding advanced settings for rules and rulesets by toggling these advanced settings icons:
When advanced settings are hidden, you see options that are used by most users. When advanced settings are shown, you are offered additional options to configure.
A ruleset name must start with a letter and can contain only the letters (a to z and A to Z), numbers (0 to 9), the following characters: ".", "-", "_","", ":", "/", and single spaces.
A dictionary name can contain only letters (a to z and A to Z), numbers (0 to 9), and the underscore (_) character. Special characters are not permitted in a dictionary name.
Other names and aliases, used for rules, facts, bucketsets and so on, must begin with a letter and contain only letters, numbers, ".", "-", "_","", ":", "/", and single spaces.
Note that a type name defined by the specification as containing a hyphen (-) may need to have its hyphen changed to an underscore (_) to accommodate the Java-based rules engine. For example, the specification defines the IP-CAN_CHANGE event trigger AVP, but this value does not validate and must be changed to IP_CAN_CHANGE when used in a rule. The Expression Builder automatically enters this value as IP_CAN_CHANGE. See "Using the Expression Builder" for information about the Expression Builder.
Dictionaries are created when you deploy a ruleset. The ruleset is saved along with its supporting bucketset and decision functions to a dictionary, and displayed in the Deployments tab of the Policy Designer interface.
You view deployed dictionaries from the Policy Designer Deployments tab. The rulesets are listed in the Version History column on the left. Select one and it is displayed in the Decision Rulesets tab, along with it's Start Date, End Date, a checkbox indicating whether it is active, and the number of rules it contains. The bucketset and functions details are not displayed here; select the Rules Editor tab to view or edit them.
To make changes to a dictionary, select it and Click the Load into Rule Editor button and it appears in the Rule Editor tab. See "Creating and Deleting Rules" and "Creating, Editing, and Deleting Bucketsets" for details on changing the details of a dictionary.
To export a dictionary to a file:
In the Rulesets list, select the ruleset you want to export.
Click Export.
A dialog appears in which you can specify the location to save the dictionary file.
Choose Save File.
To restore the dictionary, import it back into the editor.
To import a dictionary:
Click the Import button.
Using the Import a Rule Dictionary File browser, select the .rules dictionary file to import.
Click Open.
In the Import a Rule Dictionary File dialog box, click OK.
The dictionary is imported into the editor.
A ruleset is a unit of execution for rules, which are fired in the order of the priorities assigned to them.
You create and delete a ruleset from the Rulesets menu in the upper left section of the rule editor. Figure 4-1 shows the Rule Editor subtab with the Ruleset dropdown menu displayed.
Figure 4-1 Rule Editor with DecisonRuleset2 Selected
To create a new ruleset:
Select Create New from the Rulesets menu.
The new ruleset appears in the list of rulesets.
Select the ruleset in the Rulesets list if it is not already selected.
Assign a name to the ruleset by overwriting the default name in the editor.
If you want to configure advanced settings, toggle the advanced settings icon to the left of the ruleset name field.
The advanced settings fields appear. Configuration of these fields is optional.
In the Description field, you can enter an option textual description of the ruleset. [Advanced Setting]
From the Effective Date menu, select a configuration for the effective date of the ruleset. See "Setting the Effective Date for a Rule or Ruleset" for details. The default is Always. [Advanced Setting]
Check the Active checkbox to activate the ruleset or clear the checkbox to deactivate it. The default is Active. [Advanced Setting]
To save your work you have these options:
Deploy the ruleset to a dictionary. See "Deploying Rulesets to a Dictionary" for details.
Save the ruleset to a file. See "Exporting a Dictionary" for details.
WARNING:
If you do not export or deploy the ruleset, your work is not saved.
To delete a ruleset:
From the Rulesets list, select the ruleset that you want to delete.
Select Delete from the Rulesets menu.
The selected ruleset is deleted.
Deleting a ruleset does not affect a dictionary that has already been exported or deployed. To make the deletion permanent, you must export or re-deploy the dictionary.
The Effective Date menu is displayed only when advanced settings are shown.
To set the effective date of a rule or ruleset:
From the Effective Date menu, select one of the options described in Table 4-1:
Table 4-1 Effective Date Settings
| Value | Description |
|---|---|
|
Always |
The rule or ruleset is always in effect. |
|
Range |
The rule or ruleset if in effect from the specified start date to the specified end date. |
|
From |
The rule or ruleset if in effect from the specified start date with no end date. |
|
To |
The rule or ruleset if in effect from the deployment of the ruleset to the specified end date. |
If you specified a value other than Always, select from the date-time menu whether you want to specify a date, a time or both a date and a time for the start date and end date values. This setting applies to both the start and end dates. You cannot assign different configurations to the start and end dates.
If you are specifying a start date, click the date-time icon to the right of the Start Date field.
An editable calendar appears.
In the calendar, set the date and / or the time and time zone, depending on whether you are setting a date, a time or both.
If you are specifying a range or an end date, click the date-time icon next to the End Date field and repeat steps 4 and 5.
The order in which rulesets are applied is set in the predefined PCRF_DF decision function. A decision function provides a contract for executing rulesets.
You can change the order in which the rulesets are applied by editing the PCRF_DF decision function.
To change the order of execution for rulesets:
On the left side of the rule editor, click Decision Functions.
The Decision Functions list, containing a single entry for the PCRF_DF decision function, appears.
Select the row for the PCRF_DF decision function.
Click the pencil icon above the list.
The Decision Function Editor appears.
To change the order of a ruleset, use the arrow to move it from the Available to the Selected list if it is not there already. The double arrow moves all the rulesets.
In the Selected list, select the ruleset that you want to move.
Do one of the following:
Click this icon to move the ruleset one position up:
or
Click this icon to move the ruleset one position down:
or
Click this icon to move the ruleset to the top of the list:
or
Click this icon to move the ruleset to the bottom of the list:
When you have finished reordering the rulesets, click OK.
A rule expresses a PCC policy decision in an IF - THEN format. The IF section of the rule defines a boolean condition, which may be composed of multiple conditions called tests, associated with each other by logical operators. The THEN section describes one or more actions. If the IF condition evaluates to true, the actions in the THEN section of the rule are performed.
You can create rules using the fields in the rule editor or you can import a previously created dictionary. See "Importing a Rule Dictionary" for information about importing a dictionary.
In the rule editor, you create rules inside a ruleset. You can change the order in which the rules are displayed in the ruleset; see "Changing the Display Order of Rules in a Ruleset". You can page through the rules in a ruleset using the arrows to the right of the ruleset name.
To create a rule:
With the containing ruleset selected, click the new rule icon.
The rule is created.
Overwrite the default rule name with the name of your choice in the rule name field.
If you want to configure advanced settings, toggle the advanced settings icon to the left of the rule name field to display the advanced settings fields.
The advanced settings fields appear.
Configuration of the advanced settings fields is optional.
In the Description field, you can enter an option textual description of the rule. [Advanced Setting]
From the Priority menu, select the priority of this rule relative to the priority of the other rules in the ruleset. [Advanced Setting]
Higher priority rules are fired before lower priority rules. The default priority is medium.
From the Effective Date menu, select a configuration for the effective date of the rule. See "Setting the Effective Date for a Rule or Ruleset" for details. The default is Always. [Advanced Setting]
Check the Rule Active checkbox to activate the rule or clear the checkbox to deactivate it. The default is Rule Active. [Advanced Setting]
To enable advanced mode, check the Advanced Mode check box. Advanced mode allows additional pattern-matching options for creating conditions and actions. Advanced mode also allows you to test the rule with specific data values. See the discussion of advanced mode rules in Oracle Fusion Middleware User's Guide for Oracle Business Rules for information about advanced mode. [Advanced Setting]
To enable tree mode, check the Tree Mode check box. Tree mode is used for master detail rule hierarchies. See the discussion of tree mode rules in Oracle Fusion Middleware User's Guide for Oracle Business Rules for information about tree mode. [Advanced Setting]
In the IF section of the rule editor, define the rule's condition. See "Defining the Condition of a Rule" for details.
In the THEN section of the rule editor, define the rule's actions. See "Defining the Actions of a Rule" for details.
To save your work you have these options:
Deploy the ruleset to a dictionary. See "Deploying Rulesets to a Dictionary" for details.
Save the ruleset to a file. See "Exporting a Dictionary" for details.
To delete a rule:
Click the delete icon next to the rule that you want to delete.
A condition is composed of one or more tests, connected by and or or logical operators. Each test evaluates to true or false. A single row of fields in the IF section of the rule editor represents a single test. If the entire condition defined in the IF section of the rule evaluates to true, the actions defined in the THEN section of the rule are performed. If the condition does not evaluate to true, none of the actions are performed.
Defining the condition of a rule involves constructing one or more tests and combining them with the correct logical operators to create the condition.
You create a test by editing a row of fields in the editor in the IF section of the rule editor. A test consists of three components:
Left operand
Comparison operator
Right operand
See the "Example Rules" section to examine sample rules that you can use as models for your own rules.
Note:
For ease of use Policy Controller allows you to enter UTF-8 values for the AVPs that the 3GPP specifications specify in octet format, such as GxUser-Equipment-Info-Value.To create a test:
Do one of the following:
If a blank test row is displayed in the IF section of the rule, continue to step 2.
or
To add a new test row, in the IF section of the rule click the insert test button to the right of the existing test row.
You may have to scroll horizontally to see the end of the row.
A new test row appears.
Define the left operand of the test by doing one of the following:
Click the search icon to the right of the left operand field.
The Condition Browser appears.
In the Condition Browser, select the value to use for the left operand.
See "Using the Condition Browser" for information about the Condition Browser.
or
Enter a literal value by typing the value directly into the left operand field.
Repeat step 2 for the right operand, using the search icon to the right of the right operand field to display the Condition Browser.
From the menu of comparison functions between the two operand fields, select the function to use to compare left and right operands.
The menu is context sensitive, so its items vary depending on the contents of the left and right operands.
To delete a test from a rule:
Click the delete test button to the right of the test that you want to delete.
To create a condition that contains multiple tests:
Create a test as described in "Creating a Test".
Click the insert test button at the end of the test row to add another test.
Toggle the logical operator at the end of the first test to be and or or depending on the logic of the condition you are creating.
Create another test.
Continue to add tests and connect them with logical operators until you have constructed the entire condition.
If you want to enclose multiple tests in a parentheses to create nested tests, check the checkboxes to the left of the rows that you want to enclose and click the add parentheses icon above the condition.
The tests being enclosed in a single set of parentheses must be contiguous in the rule editor. If necessary, change the order of the tests before applying the parentheses. See "Changing the Order of Tests"for information on how to do this.
To remove the parentheses:
Check the checkboxes to the left of the tests around which you want to remove parentheses.
Click the remove parentheses icon above the condition.
The tests are evaluated in the order in which they appear in the rule.
To change the order in which the tests are evaluated:
Check the checkbox to the left of the test for which you want to change the position.
Click the up or down arrow at the top of the IF section to change the position of the test in the rule. Every click moves the test up or down one row.
In the THEN section of the rule, you define the actions to be performed if the condition evaluates to true. Each row of fields in the THEN section of a rule defines a single action.
To define an action:
Do one of the following:
If there are no action rows displayed, click Insert Action.
or
If action rows are displayed, click the insert action button at the end of an existing row to create a new action row.
A new action row appears.
From the left menu, select the action to perform from the options described in Table 4-2:
| Action | Description |
|---|---|
|
Assert New |
Asserts a new fact. An assert action adds a fact instance to Policy Controller memory. |
|
Modify |
Modifies a data value associated with a matched fact. |
|
Retract |
Retracts a fact. A retract action removes a fact instance from Policy Controller memory. |
Note:
If you are working in advanced mode, a variety of additional actions are available to you. See the discussion of how to use advanced mode actions in Oracle Fusion Middleware User's Guide for Oracle Business Rules for information about advanced mode actions. Only the three basic actions are covered here.Do one of the following:
If the action is Assert new, follow the instructions in the "Defining an Assert New Action" section.
If the action is Modify, follow the instructions in the "Defining a Modify Action"section.
If the action is Retract, follow the instructions in the "Defining a Retract Action" section.
You can assert the following facts. These facts are all outputs of the rules engine.
If you select one of the Out_ facts, and then select the Edit Properties (pencilXYZ) icon, the Edit Properties form appears. You can type an entry in the Value field, or select the search icon to choose from a list of all acceptable values. The acceptable values list is automatically populated with all possible values for the new action you chose.
Associates the rule with the specified policy profile. The value property contains the policy profile name.
Disassociates the rule from the specified policy profile. The value property contains the policy profile name to disassociate.
Adds the specified event trigger to the Gx session. The value property contains the event trigger to add. You can specify any event trigger from the Policy and charging control over Gx reference point (3GPP TS 29.212 Release 9) specification. See "About Event Triggers" for more information.
Removes the specified event trigger from the Gx session. The value property contains the event trigger to remove. You can specify any event trigger from the Policy and charging control over Gx reference point (3GPP TS 29.212 Release 9) specification. See "About Event Triggers" for more information.
Removes all existing event triggers from the Gx session set, including all the system-level event triggers and adds the NO_EVENT_TRIGGERS (14) event trigger to the Gx session.
Sets a deadline, before which the PCEF should re-request an update of the PCC rules. The timer is set to an absolute date/time; for example: 2011-12-30 14-55-30 PST.
Sets a deadline, before which the PCEF should re-request an update of the PCC rules. The timer is set as the number of seconds from the time that the rule was invoked; for example: 3600.
Creates a custom fact. See the discussion of LocalFact in "Using the Condition Browser" for more information.
To define an assert new action:
In the THEN section of the rule editor, select Assert New in the left menu.
Select the fact to assert from the right menu.
Click the pencilXYZ icon.
A properties form appears in which you set the value of the fact.
If the value is a constant, check the Constant checkbox.
To set the value of the fact do one of the following:
Click the search icon to the right of the Value field.
The Condition Browser appears.
In the Condition Browser, select the value.
See "Using the Condition Browser" for information.
or
Enter a literal value by typing the value directly into the Value field.
Click OK.
To define a modify action:
In the THEN section of the rule editor, select Modify in the left menu.
Select the fact to modify from the right menu.
Click the pencil icon.
A properties form appears in which you modify the value of the fact.
If the value is a constant, check the Constant checkbox.
To modify the value of the fact, do one of the following:
Click the search icon to the right of the Value field.
The Condition Browser appears.
In the Condition Browser, select the value.
See "Using the Condition Browser" for information.
or
Enter a literal value by typing the value directly into the Value field.
Click OK.
To define a Retract action:
In the THEN section of the rule editor, select Retract in the left menu.
Select the fact to retract from the right menu.
The actions are performed in the order in which they appear in the rule.
To change the order in which the actions are performed:
Check the checkbox to the left of the action for which you want to change the position.
Click the up or down arrow at the top of the THEN section to change the position of the action in the rule. Every click moves the action up or down one row.
To delete an action from a rule:
Click the delete action button to the right of the action that you want to delete.
The Policy Controller uses event triggers to inform the PCEF that it should trigger a new request for rules when any of the subscribed events, such as an IP-CAN change, occurs at the gateway.
In the Condition Browser under the In node there are entries for two types of Gx triggers:
In.GxEventTriggerList
These are incoming triggers from the PCEF. The PCEF sends a list of triggers that occur in the gateway. These triggers are made available to the rules engine in the In.GxEventTriggerList.
In.GxEventTriggerList contains facts based on Event-Trigger attribute-value pairs (AVP) received in a credit control request (CCR) from the PCEF. The following functions operate on these triggers: FindGxEventTrigger and ContainsGxEventTrigger.
In.GxInstalledEventTriggerSet
These are session triggers.
The In.GxInstalledEventTriggerSet fact contains values based on event triggers installed by an Assert New (Out_AddEventTrigger) action or uninstalled by Assert New (Out_RemoveEventTrigger) action in a rule created with the rule editor. The following functions operate on these triggers: FindGxInstalledEventTrigger and ContainsGxInstalledEventTrigger.
In addition to the Gx session-level triggers, there are four system-level triggers that are installed by default:
OUT_OF_CREDIT (15)
REALLOCATION_OF_CREDIT (16)
REVALIDATION_TIMEOUT (17)
SUCCESSFUL_RESOURCE_ALLOCATION(22)
You can remove these system-level triggers with Out_RemoveEventTrigger and re-install them with Out_AddEventTrigger actions.
The Condition Browser contains a field, a hierarchical tree view of the rules metadata, and an embedded Expression Builder. You use it to browse for values to use in the operands of a test in the IF section of a rule, and values used for the properties of facts in the THEN section of a rule.
There are three ways to enter a value this browser:
You can select a leaf item from the tree.
You can type values directly in the browser field.
You can use the Expression Builder embedded in the browser to create an expression. See "Using the Expression Builder" for more information.
After you enter value into the field in the browser by one or a combination of these methods and click OK, the value appears in the operand field that you are editing in the rule editor.
The nodes displayed in the browser tree reference the data listed in Table 4-3.
Table 4-3 Condition Browser Node Data
| Node | Description |
|---|---|
|
CurrentDate |
The CurrentDate node accesses the current date and time and includes functions for referencing the following components of the current date:
|
|
In |
The In node contains data facts that are generated outside the rules engine and used as input to the rules engine. The In node contains many leaves and some child nodes. Facts with names having gx prefixes are defined in the Policy and charging control over Gx reference point (3GPP TS 29.212 Release 9) specification. Facts with names having rx prefixes are defined in the Policy and charging control over Rx reference point (3GPP TS 29.214 Release 9) specification. Facts pertaining to applicationType refer to whether the application is APP_GX or APP_RX Facts in the subscriberProfile child node represent subscriber data defined in the Service Broker subscriber store. See the discussion of the subscriber store data model in Oracle Communications Service Broker Subscriber Data and Lifecycle User's Guide for information about these values. Facts in the CalendarMsTimeZone child node are used for date and time data. CalendarMsTimezone provides the same extraction functions as CurrentDate. |
|
LocalFact |
LocalFact is used for custom values that can be used in actions and tests. LocalFact supports integerValue, name, booleanValue, and doubleValue values. You can assert a LocalFact: assert new LocalFact (integerValue:42) then create a test based a LocalFact value: IF LocalFact.integerValue isn't 42 and then modify LocalFact in another action: modify LocalFact (name:"strange value") |
|
Out_* |
Facts with names having OUT_ prefixes are output of the rules engine that result from rule actions. As well as being the basis for actions, these OUT facts are sometimes used as input to the rules engine to change behavior: For example, you might want to test the Out_InstallPolicy fact to get a subscriber's current policy profile so that you can upgrade it to a a higher level of service on the subscriber's birthday: IF month(In.subscriber profile.dateOfBirth.time.month is CurrentDate.date.time.month) and In.subscriberProfile.dateOfBirth.time.date is CurrentDate.date.time.date) and Out_InstallPolicy.name is "GOLD" THEN ASSERT NEW Out_InstallPolicy(name: "PLATINUM") See "Defining an Assert New Action" for information about individual OUT facts. |
Expression Builder is used to build expressions used in tests. You access the Expression Builder from the Condition Browser by clicking the Expression Builder icon.
You can directly type an expression in the Expression field in the Expression Builder. You can also insert values from the rules metadata using the four tabs: Variables, Functions, Operators, and Constants. Each tab displays the rules metadata in a tree structure.
To build an expression, select an item in the tree and click the Insert Into Expression button to insert the selected item at the cursor position into the Expression text field. You can switch among the tabs for the different items needed to build the expression. You can also type directly in the field.
After you have created the expression and clicked OK, the expression appears in the field in the Condition Browser.
The Functions tab of Expression Builder is especially useful for providing functions that can be used in tests. For example, to retrieve the data instance of a SubscriptionID that has the type "END_USER_SIP_URI" and the data "sip:john.doe@oracle.com", you could use the following test, in which:
In is the In parameter in the Condition Browser
SubscriptionIDType.END_USER_SIP_URI is the SubscriptionIDType of the entry
sip:john.doe@oracle.com is the SubscriptionIDData of the entry
IF In.gxSubscriptionIdList.size() more than 0 and ((SubscriptionID)In.gxSubscriptionIdList.get(0)).idType is SubscriptionIDType.END_USER_SIP_URI and ((SubscriptionID)In.gxSubscriptionIdList.get(0)).idData is "sip:john.doe@oracle.com"
but it would be simpler to use the FindGxSubscriptionId function to construct an equivalent test as follows:
IF FindGxSubscriptionId(In, SubscriptionIDType.END_USER_SIP_URI, "sip:john.doe@oracle.com") isn't null
Similarly, to check the existence of a specific SubscriptionID, you can use the following test, which checks for a SubscriptionID of type END_USER_SIP_URI and the data sip:john.doe@oracle.com:
IF In.gxSubscriptionIdList.size() more than 0 and ((SubscriptionID)In.gxSubscriptionIdList.get(0)).idType is SubscriptionIDType.END_USER_SIP_URI and ((SubscriptionID)In.gxSubscriptionIdList.get(0)).idData is "sip:john.doe@oracle.com"
or you could construct an equivalent test the ContainsGxSubscriptionId function:
IF ContainsGxSubscriptionId(In, SubscriptionIDType.END_USER_SIP_URI, "sip:john.doe@oracle.com") is true
Expression Builder provides several of these types of find and contains functions to simplify rule creation.
To change the order in which the rules are displayed in the rule editor, use the up and down arrows to the right of the rule name field to move the rule. Each click moves the rule one position up or down in the ruleset.
The display order of rules in the rule editor has no effect on the order in which the rules are fired.
A bucketset is a list of values or a list of value ranges used to define a group of constant values used in rules.
WARNING:
The default dictionary includes bucketsets for PCCProfiles and for GeographicLocationTypes. Do not delete or modify these bucketsets directly as this could cause undefined behavior in the rules engine. Instead, allow these bucketsets to be populated automatically by the Policy Controller interface.
For example, suppose you have a set of account types that have long names. You could create an accountValues bucketset with a String data type in which the real values are the value properties and the aliases are something shorter:
| Value | Alias |
|---|---|
| acct1234567890462_A | acctA |
| acct7777770000443_B | acctB |
Then you could create a rule that references the alias instead of the long name:
IF In.subscriberProfile.accountType is accountValues.acctA
See the discussion of working with bucketsets in Oracle Fusion Middleware User's Guide for Oracle Business Rules for more information.
To create a bucketset:
In the left panel, click Bucketsets.
The Bucketsets list appears.
Click the Add Bucketset menu and select whether the bucketset will define a range or a list of values (LOV).
The new bucketset appears in the list with a default name.
In the bucketset list, select the bucketset that you just created.
Click the pencil icon.
The Bucketsets Editor appears.
In the Name field, overwrite the default name with the name you want to assign to the bucketset. Do not use the same name for the bucketset as the alias of a fact, as this will cause a validation error.
In the Description field, optionally enter a textual description of the bucketset.
From the Data Type menu, select the data type of the values in the bucketset.
All the values in a bucketset must be of the same type.
If you want to allow invalid values in tests, check the Include Disallowed Buckets in Tests checkbox. This allows you to test for invalid values.
Do one of the following:
If the bucketset defines a list of values:
Click the add bucket icon above the Bucket Values list to add a value to check.
In the Value field enter the name of the value to check.
In the Alias field enter an alias for the value. This can provide a more meaningful name than the real value name.
If the value is allowed in actions, check the Allowed in Actions box. Otherwise clear it.
For more information, see the discussion of the bucketsets allowed in actions option in Oracle Fusion Middleware User's Guide for Oracle Business Rules.
Optionally add a description of the value in the Description field.
Repeat steps a through e for every value that you want to add to the bucketset.
Click OK.
If the bucketset defines a range of values:
Click the add bucket icon above the Range Bucket Values list to add a range to check.
In the End Point field, enter the highest value in the range.
Check the Included Endpoint checkbox if the endpoint is included in the acceptable range. Clear it if the endpoint is outside the range.
In the Range field, enter the range of valid values.
If the range is allowed in actions, check the Allowed in Actions box. Otherwise clear it.
For more information, see the discussion of the bucketsets allowed in actions option in Oracle Fusion Middleware User's Guide for Oracle Business Rules.
In the Alias field enter an alias for the value. This can provide a more meaningful name than the real value name, which is in the Range field. The range field is read-only.
Optionally add a description of the value in the Description field.
Repeat steps a through g for every range that you want to add to the bucketset.
Click OK.
To edit a bucketset:
In the left panel, click Bucketsets.
The Bucketsets list appears.
Select the bucketset that you want to edit.
Click the pencil icon.
The Bucketset Editor appears.
Make your changes in the Bucketset Editor following the guidance for creating a new bucketset.
Click OK.
To delete an item in a bucketset:
In the Bucketsets Editor, select the item in the list that you want to delete.
Click the delete icon above the Bucket Values list.
To delete a bucketset:
In the Bucketsets list, select the bucketset that you want to delete.
Click the delete icon above the Bucketsets list.
Deploying a rules dictionary activates the rulesets (using its supporting bucketsets and decision functions) in your Policy Controller implementation. To check whether a rules dictionary has been be deployed, click the Deployments tab at the top of the Policy Designer interface to see whether it appears in the list of Decision Rulesets tab.
To deploy a rules dictionary:
Click the Deploy button at the top of the rule editor.
A dialog box appears containing a Note text field.
Optionally add a note about the deployed dictionary in the Note text field.
The text that you enter appears near the top of the screen in the Deployments tab of the Policy Designer when the dictionary is loaded.
Click Deploy in the dialog box to deploy the dictionary.
Future updates to the dictionary do not affect a deployed dictionary. To include updates in the release, you must re-deploy the dictionary.
Because of the flexibility and extensibility of the PCRF rules engine, the possibilities for creating rules are infinite. Following are examples of a few of the most common scenarios.
A common rule task is to install a policy profile based on a change in subscriber data.
For example, the Policy Controller can regularly compare the current date to the month and date of the subscriber's birthday and install a special policy profile on the subscriber's birthday:
IF In.subscriberProfile.dateOfBirth.time.month is CurrentDate.date.time.month AND In.subscriberProfile.dateOfBirth.time.date is CurrentDate.date.time.date THEN ASSERT NEW Out_InstallPolicy(name: "BIRTHDAY")
This rule specifies that subscribers using Prepaid Policy Profile services from a 69.63.189.* IP address also receive the Prepaid_SocialVoice_Plan Policy Profile:
IF In.subscriberProfile.accountType is AccountType.Prepaid AND MatchToAddress(In.gxTftPacketFilterInformationList, "69.63.189.*") is true AND In.applicationType is ApplicationType.APP_GX THEN Assert New Out_InstallPolicy(name: "Prepaid_SocialVoice_Plan")
Receipt of a trigger from the PCEF can be used to initiate a change in a policy profile.
For example, upon receiving the OUT_OF_CREDIT trigger, Policy Controller can remove a subscriber's installed policy profile and install another one:
IF FindGxEventTrigger(In, EventTrigger.OUT_OF_CREDIT) is true AND In.subscriberProfile.subscriberCategory is "GOLD" OR In.subscriberProfile.subscriberCategory is "SILVER" OR In.subscriberProfile.subscriberCategory is "BRONZE" THEN ASSERT NEW Out_InstallPolicy(name: "LEAD")
This example shows two rules that would work to throttle back service for a subscriber that has run out of credit. These rules specify that when the Policy Controller receives a Gx-based OUT_OF_CREDIT event, a NoCredit_Plan Policy Profile is applied which contains throttled back service.
This rule applies a NoCredit_Plan Policy Profile when an OUT_OF_CREDIT event is received:
IF In.gxEventTriggerList isn't null AND In.gxEeventTriggerList contains (EventTrigger.OUT_OF_CREDIT ) AND In.getRATType() is RATType.EVOLUTION THEN Assert New Out_InstallPolicy(name: "NoCredit_Plan") Assert New Out_AddEventTriger(EventTrigger.REALLOCATION_OF_CREDIT )
This rule removes the NoCredit_Plan Policy Profile when a REALLOCATION_OF_CREDIT event is received indicating that the subscriber has.
In.gxEeventTriggerList contains(In, EvetnTrigger.REALLOCATION_OF_CREDIT AND IN.gxRatType is RATType.EVOLUTION THEN Assert New Out_RemovePolicy(name:"NoCreditPlan") Assert New Out_AddEventTrigger(EventTrigger:EventTrigger.OUT_OF_CREDIT)
You can create a local fact for special custom values.
Local facts are especially useful for complex scenarios involving multiple rules. For example, suppose there are three different rules:
RULE_1 applies to subscribers over age 25.
RULE_2 applies to members of the SILVER subscriber category.
RULE_3 applies to subscribers using WIFI.
You want to install a particular policy named SPECIAL_RULE if any two of these three rules apply.
You could create a local fact named numberOfRules with an integer value initialized to 0 and increment that value every time a rule is added. When the local fact's value reaches 2, the SPECIAL_RULE Policy Profile is applied. The following rules accommodate this scenario:
IF In != null THEN assert new LocalFact(integerValue:0, name: "numberOfRules") IF In.subscriberProfile.birthdate.get(Calendar.YEAR) > (CurrentDate.get(Calendar.YEAR - 25) AND LocalFact.name == "numberOfRules" assert new InstallPolicy(name: "RULE_1") modify( LocalFact (integerValue: LocalFact.integerValue + 1) IF In.subscriberProfile.subscriberCategory == "SILVER" AND LocalFact.name == "numberOfRules" assert new InstallPolicy(name: "RULE_2") modify( LocalFact (integerValue: LocalFact.integerValue + 1) IF In.ipcantype == "WIFI" AND LocalFact.name == "numberOfRules" assert new InstallPolicy(name: "RULE_3") modify( LocalFact ( integerValue: LocalFact.integerValue + 1) IF LocalFact.integerValue == 2 assert new InstallPolicy(name: "SPECIAL_RULE")
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
