Mapped Parameter Sets Using Bulk Loading System and Method

Information

  • Patent Application
  • 20070260705
  • Publication Number
    20070260705
  • Date Filed
    May 03, 2007
    18 years ago
  • Date Published
    November 08, 2007
    18 years ago
Abstract
A system and method are provided that allows users to define a set of parameters for Uniform Resource Locator (URL) mapping rules. A URL may be defined for each output parameter condition, input parameters inspected, and the output parameter value determined. Business logic is executed before and after URL mappings have been determined. Multiple exclusive groups of mapping rules are maintained and an incoming URL can be explicitly directed to a rule group. Rule handlers, new URLs within an existing link generator, as well as input and output parameters are created to act on parameters during processing. Input parameters and values are translated to output parameters and values, respectively. Output parameters and values are mapped to a destination URL. In addition, a customizable bulk loading tool is provided which sends the mapped sets directly to a client to add values to the sets and then returns the document.
Description

BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a flow chart of preferred embodiment process for building a mapped parameter set.



FIG. 2 shows a resulting page from an example URL in a preferred embodiment of mapped parameter sets.



FIG. 3 outlines a flow diagram for the bulk loading portion of mapped parameter sets system and method.



FIG. 4 describes a mapped parameter set list.



FIG. 5 illustrates an edit set page.



FIG. 6 illustrates an edit parameter page.



FIG. 7 illustrates a create set page.



FIG. 8 describes a create parameter page.



FIG. 9 illustrates a remap parameter screen.



FIG. 10 shows a page for choosing parameter mapping criteria.



FIG. 11 shows a map URL user interface screen.



FIG. 12 illustrates a user interface summary screen that outlines the operations performed in prior user interface screens.



FIG. 13 shows a history screen of date specific operations.



FIG. 14 shows a portion of a mapped parameter set list with a bulk loading tool highlighted.



FIG. 15 illustrates a class diagram for an embodiment of mapped parameter sets.



FIG. 16 shows a data model diagram for mapped parameter sets using bulk load upload tool.





DETAILED DESCRIPTION

Definitions in Table 1 are intended to clarify terms and concepts used within this document.









TABLE 1







Definitions








Term
Definition





Parameter
A property whose value determines - or contributes to the determination of - the



characteristics or behavior of an operation or action.


Input Parameter
A parameter that will be used to determine the value of a remapped parameter. An input



parameter's name must match an incoming request parameter name.


Remapped Parameter
A parameter whose value is set based on other parameter values. Remapped parameters are



typically also used as output parameters, but they may, instead, be added to final URL rather



than contributing to its determination.


Output Parameter
A parameter that is used in the final URL mapping table that contributes to the determination



of the final URL.


Rule
A string of parameters that, if the values correspond to those contained in an incoming URL,



remap to new parameter values and direct the browser to a product detail page; a single line



on the mapped parameter set spreadsheet.


Mapped Parameter Set
A collection of rules.


Template Spreadsheet
A spreadsheet that has been formatted, has defined columns representing parameters, and that



can be populated with values and uploaded to an ecommerce platform.


User
This role could be performed by an internal account manager or staff. This actor will manage



mapped parameter sets through the UI, download template spreadsheets, and upload



populated spreadsheets.









Set Up Flow


FIG. 1 shows a simplified setup flow chart 101 of building a mapped parameter set. “Create Group” 102 is the step where the user chooses a new parameter set or rules. “Define All Parameters (Input & Output)” 104 names parameters and identifies whether they are output or remapping parameters. It will be understood by one of ordinary skill in the art that output is mapping a parameter to a URL. Remapping is changing the value of one parameter based on another parameter. Next, “Remap Parameter?” 106 is a decision step. If “No,” then the user reaches “Final URL Mapping” 108 step. If “Yes,” then the user moves to “Select Parameter to Remap” 110 step where they select a particular parameter to remap. “Remap parameter” 112 is another step to confirm remapping. Finally, the user decides in step “More Remaps?” 114 to remap further parameters or move back to “Define All Parameters (Input & Output)” 104. It is important to note that FIG. 1 does not describe a bulk loading system (described infra) for sake of simplicity.


An example of a resulting page 100 from a redirect URL is shown in FIG. 2. A user is redirected to the appropriate up sell product detail page. The user may be a customer, a client, or an administrator. It will be understood by one of ordinary skill in the art that the user role is not limited to the names listed. An example URL may be: http://www.symantecstore.com/dr/v2/ec_routing derive?DeriveGroup=SymantecConsole&catid=4&requester=051122194438&osver=5.1.2.0&Locale=USA&Language=EN&spefsku=10433521&spskup=&spskum=10439590&v=1&VendorID=003&VendorServiceTag=0.


It will be understood by one of ordinary skill in the art that FIG. 2 shows an example of a page that results when the user clicks on a link to a redirected URL. Thus, the page could be virtually anything the user wishes the link to redirect towards. FIG. 2 is not part of the set up of mapped parameter sets; it is only an example output URL.



FIG. 3 outlines a flow diagram for the bulk loading system of mapped parameter sets system and method. It will be understood by one of ordinary skill in the art that this is an example of how a bulk loading system may be incorporated with a mapped parameter set system. Templates are listed in order of precedence, and may be moved up or down depending on how the order is defined in a user interface (UI). First, the user may navigate 116 to a mapped parameter set system. Next, the user may check 118 a box next to the desired mapped parameter set. The user may choose a download option at this point. The user may then download 120 and receives a template spreadsheet. The spreadsheet will contain previous values that have been entered. Next, the user populates 122 the spreadsheet and returns 124 to the original mapped parameter set system. Finally, the user uploads 126 the spreadsheet back onto the system.



FIG. 4 describes a mapped parameter set list 128. The user may reach this page from navigating 116 (See FIG. 3) to a mapped parameter set system. To edit an existing set 132, the user can click on the name of a set they wish to edit in the list 128. Or, the user may check a box 130 and then delete 134, download 136, or view history 138 of a set.


Referring now to FIG. 5, an edit set page 140 page is shown. This is a general page concerning a parameter set, not individual parameters or rules. Thus the fields on this page are specific to an entire set. In another preferred embodiment, the user can add parameters to a set by entering a name 142, description 144, rule handler pre process 146, rule handler post process 148, and a status 150. In the rule handler pre process 146 and post process 148, java code can be inserted in order to do specialized logic before and after the parameters are run. For example, there may be a pre—process rule that looks at several parameters and formulates one of the parameters as “sku.” Therefore the mappings just handle a parameter called “sku.” The post processing rule can add logic that takes the final derived output URL and appends all parameters that entered on an initial URL.


Still referring to FIG. 5, the user may check a box 162 to select an existing parameter. The move up 160 and move down 158 buttons are to configure weight based selections or scoring of parameters. A remap parameter 156 button will send the checked parameter to a remapping page (See infra). A delete 154 button will remove a checked parameter, and a new 152 button will send the user to a create parameter page (See infra). Conversely, clicking on a name of a parameter will also send the user to an edit parameter page. Once the user has entered information into the edit set page 140, they may click next 164 to go onto the next step of the process. Clicking cancel 166 will abandon all changes on this page.



FIG. 6 illustrates an edit parameter page 168. Here the user may enter a name 170, type 172, default value 174, and allowed values 176. Under type 172, the user may select the parameter to be an input parameter for use as criteria for remapping another parameter. Also, the user may select output to use the parameter as criteria for output URL mapping. It will be understood by one of ordinary skill in the art that a parameter may be both input and output. Furthermore, the user may select remap only under type 172 to base a parameter's value on the value of other parameters. Once the user is finished with editing a parameter on the edit parameter page 168, they may click save 178, or save and new 180 if they wish to edit another parameter. Clicking cancel 182 abandons editing a parameter.



FIG. 7 illustrates create a set page 184. In one preferred embodiment, the user may enter a name 186, a description 188, rule handler pre process 190, rule handler post process 192, and a status 194. The parameters as they are created are stored in a parameter list. As described in FIG. 5, the user may click move up 198 and move down 200 to change the weight based values of the parameters.


Remap parameters 202 sends a selected parameter for remapping, and delete 204 removes a parameter from the list. Clicking new 196 allows the user to create a new parameter, shown in FIG. 8 (infra). Also, clicking cancel 210 abandons create a set, clicking previous 208 returns the user to the previous screen, and clicking next 206 sends the user to the next step in the process.


Moreover, FIG. 8 describes a create parameter page 212. As with the edit parameter page 168, the user may enter a name 214, type 216, default value 218, and allowed value 220. It will be understood by one of ordinary skill in the art that default value 218 is delineated by line. Once the user is finished with creating a parameter, they may click save 226, or save and new 224 if they wish to create another parameter. Clicking cancel 222 abandons creating a parameter.


Referring to FIG. 9, a remap parameter screen 228 is shown. A user may reach this page by clicking on remap parameters 202 shown in FIGS. 5 and 7. The user may enter the appropriate parameters for a link in this page. Under available incoming parameters 230, the user may select all parameters that are to be included as conditions in the rule that is being created. Any parameters that are defined as input or input/output will appear in this list. The user may choose an e-commerce platform 233 and then save 234 the page. Delete 236 removes a particular remapped parameter from the page and done 238 finishes the remapping process and sends the user back to a previous page. Furthermore, by clicking on an ID 237 of a rule, the user can edit existing rules. By clicking on add parameters 232, the page 228 shown in FIG. 10 appears. Here the user may choose parameter mapping criteria 240.



FIG. 11 shows a map URL user interface screen 242. In a preferred embodiment, the user may create or edit rules that map the values of selected parameters to a URL which an end web request will be redirected to. The user may select a store ID 244 from a dropdown menu and enter a corresponding destination URL 246. The store ID 244 specifies output parameters, and thus may change depending on what conditions the user chooses (in a previous page). However, the destination URL 246 always remains as a field in this page since that is the ultimate goal of this system (to redirect the user to the destination URL).


Clicking save 248 adds the mapped URL to the list shown in FIG. 11. It will be understood by one of ordinary skill in the art that this screen does not show all possible conditions, and that additional conditions may be added. Clicking delete 256 will remove a mapped URL. Clicking cancel 250 will abandon the action, clicking previous 252 will revert to the previous page, and clicking next 245 will proceed to the next screen.



FIG. 12 illustrates a user interface summary screen 258 that outlines the operations performed in the prior user interface screens. New URL 260 is the link on a website that would redirect a customer through a rule set. A default column identifies which item will be redirected if no matches are found. Again as in FIG. 11, clicking cancel 266 will abandon the action, clicking previous 264 will revert to the previous page, and clicking finish 262 will complete the action.


In another preferred embodiment of mapped parameter sets using bulk load tool, the user may view a history 268 of the rules. As shown in FIG. 13, a history screen provides a user with a date range of set history. The user may input search filters 270, and then click search 272. Clicking done 274 finishes viewing the history 268.



FIG. 14 shows a portion 273 for the mapped parameter set list with a bulk loading tool highlighted. Here a client or customer may import a parameter set for editing and then may upload the set back to the system. Table 2 describes a sample customizable matrix of the spreadsheet imported from FIG. 14. Here the user may add parameter values to the conditions specified. For example, the conditions may be store type, default value, ID, etc. Furthermore, the matrix may include instructions for the customer or client, such as “Enter values below each column heading. ID column should be left blank for new rules. Enter True in one line of the Default column to set the overriding rule in case multiple rules apply to an incoming URL. If more than one rule is set to TRUE in the Default column, the system will recognize the rule with the highest number as the default rule. Enter “DELETE” in the Delete column to remove a rule from the mapped parameter set.” It will be understood by one of ordinary skill in the art that this instruction may be modified. Also, the customizable matrix may include an identifier, such as company information, URL ID, name of the matrix, and time and date of download. A customer or client may enter values below each column heading, such as identification number (ID), store value, destination URL, default type, and delete. There may be more than just one “page” in the customizable matrix, such as a page for remapping a platform. The customer or client may enter values for this varying platform as well. Once the customer or client is finished adding values to the spreadsheet, they may upload the document back to the system.









TABLE 2







Sample customizable matrix for client










ID
Store
Destination URL
Is Default?





2639800
GB_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27685&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855585&p_name=PN&p_val=1&p_name=V1&p_val=855585


2639700
EU_HHO
http://shop.symantecstore.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=
TRUE




ProductDetailsPage&SiteID=symnahho&productID=64438000


2639900
MEA_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27684&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855585&p_name=PN&p_val=1&p_name=V1&p_val=855585


2640000
DE_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27686&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855585&p_name=PN&p_val=1&p_name=V1&p_val=855585


2640100
FR_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27679&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855586&p_name=PN&p_val=1&p_name=V1&p_val=855586


2640200
IT_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27681&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855597&p_name=PN&p_val=1&p_name=V1&p_val=855597


2640300
NL_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27682&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855587&p_name=PN&p_val=1&p_name=V1&p_val=855587


2640500
PL_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=41185&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855589&p_name=PN&p_val=1&p_name=V1&p_val=855589


2640600
NO_HHO
http://www.symantecstore.com/dr/v2/ec_Main.Master?p_name=SID&p_val=27684&p_name=SP&p_val=
FALSE




10023&p_name=PID&p_val=855590&p_name=PN&p_val=1&p_name=V1&p_val=855590









Moving on to FIG. 15, a class diagram is illustrated. Box 278 is a package or framework of items that are listed in code. RuleInfo.java 282 describes a map parameter set or group in general. Moreover, Parameter.java 280 describes basic information about each parameter. Remap.java 286 is an example of one remapping rule. Also, ParameterValue.java 284 describes a value of a parameter as a condition in a specific rule. RemapParameterValue 288 and URLParameterValue 290 are two examples of condition rules. RemapParameterValue 288 is the value of a parameter as a condition of a remap rule, and URLParameterValue 290 is the value of a parameter as a condition of an output URL rule.


Finally, FIG. 16 shows a data model diagram for mapped parameter sets using bulk load upload tool. ECM_PROMOTION_URL 294 shows a framework of mapped parameter sets. These are existing promo servlet applet that the mapped parameter set system may be connected to. ECM_URL_INFO 296 contains URL information. ECM_DERIVE_RULE_INFO 304 contains general information about a set. ECM_DERIVE_PARAMETER 306 contains parameter descriptions. ECM_DERIVE_URL_PARAMETER 298 contains URL parameter values. ECM_DERIVE_REMAP 302 shows remap java rules. ECM_DERIVE_REMAP_PARAMETER 300 shows remapping parameter values.


Use Cases

Tables 3-7 outline use cases for mapped parameter sets using bulk load tool system and method related functions.









TABLE 3







Setup Rule Group








Information
Details





Use case name
Setup Rule Group


Summary
User sets up a Rule Group and mapping.


Primary actor
User, System


Preconditions
The User has the proper User Role to access system



functionality and a company is selected.


Success
The User is able to successfully setup a Rule Group and


guarantees
mappings.


Trigger
The User selects to “Create Link” under a Link Manager.









Basic course of
1.
System prompts the User to select a Link Type.


events
2.
User selects “Derive a resulting URL from




incoming




parameters” and clicks “Next”.



3.
System displays the Parameter List page with no




Parameters listed.



4.
User enters the Group Name and optional




Description, Pre-Process Rule Handler, and Post-




Process Rule Handler, and clicks “New” at




the top of the Parameter List.



5.
Proceed to next Use Case








Extensions
4.a.1. User enters the Group Name and optional



Description, Pre-Process Rule Handler, and Post-



Process Rule Handler, and clicks “Next”.



4.a.2. System displays an error message stating that one



or more Parameters need to be defined for the Rule



Group.
















TABLE 4







Add Parameters to Rule Group








Information
Details





Use case name
Add Parameters to Rule Group


Summary
User adds Parameters to the Rule Group, defines them as



Input, Output, or Both, and optionally defines Allowed



Values.


Primary actor
User, System


Preconditions
A Rule Group has been setup in the system.


Success
The User is able to successfully add Parameters, define


guarantees
them as Input, Output, or Both, and optionally



define Allowed Values.


Trigger
User Clicks “New” in the



Parameter List on the Create Link - Parameter List page.









Basic course of
1.
System displays the Create Parameter page.


events
2.
User enters the Parameter Name, Type, optional




Default Value, and optional Allowed Values, and




clicks “Save”.



3.
System returns the User to the Parameter List page




with the newly created Parameter displayed in the




Parameter List.








Extensions
2.a.1. User enters the Parameter Name, Type, optional



Default Value, and optional Allowed Values, and clicks



“Save & New”.



2.a.2. Repeat steps 1 & 2.
















TABLE 5







Define Order of Precedence of Parameters








Information
Details





Use case name
Define Order of Precedence of Parameters


Summary
User defines the order of precedence of defined



parameters by changing their order in the Parameter List.


Primary actor
User, System


Preconditions
A Rule Group and Parameters have been defined.


Success
The User is able to successfully change the order of


guarantees
precedence of the Parameters in the Parameter List


Trigger
User reaches the Parameter List page.









Basic course of
4.
User selects the checkbox next to the Parameter


events

they wish to reorder and clicks “Move Up” or




“Move Down”.



5.
System refreshes the page with the




selected Parameter adjusted by one row (either up




or down).
















TABLE 6







Remap Parameter








Information
Details





Use case name
Remap Parameter


Summary
User remaps one or more parameters


Primary actor
User, System


Preconditions
A Rule Group and Parameters have been defined. The



selected Parameter is of the “Output” or “Both” Type.


Success
System displays the Create Link - Parameter List page


guarantees
with a “Yes” in the Remapped Column.


Trigger
User navigates to the Parameter List page.









Basic course of
6.
they wish10 User selects the checkbox next to the


events

Output Parameter to remap and clicks “Remap




Parameters”.



7.
System displays the Remap Parameter page with




a list of all Input Parameters defined for the




Rule Group and the Output Parameter selected on




the previous screen.



8.
User selects the Input Parameters to remap by




selecting their checkboxes and clicks “Add




Parameters”.



9.
System adds the selected Input Parameters to the




Parameter Mapping Criteria section.



10.
User selects the appropriate operand and enters




the appropriate Value for each Input Parameter and




clicks “Save”.



11.
System refreshes the page with the remapped




parameters added to the list at the bottom of the




page.



12.
User clicks “Done”.



13.
System displays the Create Link - Parameter List




page with a “Yes” in the Remapped Column.








Extensions
1.a.1. User selects more than one Parameter and clicks



“Remap”.



1.a.2. System displays an error message stating that



only one Parameter can be remapped at a time.
















TABLE 7







Map URL








Information
Details





Use case name
Map URL


Summary
User defines the final URL mapping and completes the



setup for a specific Rule Group.


Primary actor
User, System


Preconditions
The Rule Group and Parameters have been setup and any



required remapping has been defined.


Success
The User is able to successfully setup the final URL


guarantees
mapping matrix.


Trigger
User clicks “Next” on the Create Link - Parameter



List page.









Basic course of
14.
System displays the Map URL page with all of the


events

Output Parameters listed at the top of the page.



15.
User selects appropriate operand and enters or




selects the appropriate Value for each Output




parameter, enters the Destination URL, optionally




selects “Set as Default”, and clicks “Save”.



16.
System refreshes the screen with the




Parameter Values and Destination URL in the List.



17.
User repeats step 2–3 until all Parameter and Value




combinations are complete and clicks “Next”.



18.
System displays the Summary page. User reviews




the Summary and clicks “Finish”.



19.
System saves the final mapping of the Derive Rule




Group.









A further example of a use case may be as follows: The parameter “catID” represents which upsell category the user selected. This, in turn, tells the user which product to upsell. Parameters “spskup” and “spskum” both represent the installed product stock keeping unit (sku). The user uses spskup unless it is null. If it is null, the user would then use spskum. If spskup is null, then the product has not been activated (i.e., it is operating in a trial ware mode). The user will put the value used into a parameter named sku, and base any sku-specific mapping off that parameter.


The upsell product that the client directs the user to is based on the catID that they have selected, but that product (category) could change based on whether the user's product has been activated and also what the existing product on their machine actually is (represented by spefsku).


Given the rules listed above, a rule group would be setup as shown in Table 8.









TABLE 8





Create Parameters (input/output/both)


















CatID
input



locale
both



language
both



sku
both



spefsku
input



state
input



upsellProduct
output










Note however, both state and sku are not actual parameters that are passed in the URL. This is an example when a pre-process rule script is used. This rule script populates the sku and state the parameter based on an examination of spskum and spskup parameters.


The next step is to create the remapping for the upsell Product, which is re-named catID. First, the catID is converted to user friendly strings that describe the upsell product. This is useful to pare down the number of rows needed to create the URL mapping table. The name of the catID is changed to “upsell Product”. Specified input parameters for upsell Product remapping are: catID, spefsku, and state.


The first mapping rule is that catID 0-2 will point to NIS (internet security upsell) and 3-4 will point to NSW (system works upsell). Five categories have now been condensed into two categories. Having two categories reduces the amount of mapping in the final URL mapping table since the cat_id 0-2 will always point to the same URL.


Further, if the state=inactive, the category will need to be switched to another one. For example, a person who was going to get NSW will now get iNSW, which is system works basic. When a user comes in on a specific spefsku and selects category 3 (NIS), the spefsku indicates that the user already has an NIS product. For example, when this occurs, the category is changed to NSW.


Table 9 is a sample of what that table could look like:









TABLE 9







Sample for specific spefsku












CatID
State
SpefSku
Output: UpsellProduct







0


NIS



1


NIS



2


NIS



3


NSW



4


NSW



0
Inactive

iNIS



1
Inactive

iNIS



2
Inactive

iNIS



3
Inactive

iNSW



4
Inactive

iNSW



3

12345
NSWE










The catID has now been remapped into an upsell Product value. A final URL mappings now is able to be created based on the remapped upsell product. A sample of the URL mapping is provided in Table 10. The output parameters have been listed in order of precedence.









TABLE 10







Sample of URL Mapping













Upsell




Locale
Language
Product
Sku
Output: URL





HKG
IN
NIS

Internet Security Detail URL-English


HKG
IN
iNIS

URL for trial ware upsell of internet security-English


HKG
IN
NSW

System works upsell detail URL-English


HKG
IN
iNSWE

URL for trial ware upsell of system works-English


HKG
IN
NSWE

System works essentials upsell detail URL-English


HKG
CH
NIS

Internet Security Detail URL-Chinese


HKG
CH
iNIS

URL for trial ware upsell of internet security-Chinese


HKG
CH
NSW

System works upsell detail URL-Chinese


HKG
CH
iNSWE

URL for trial ware upsell of system works-Chinese


HKG
CH
NSWE

System works essentials upsell detail URL-Chinese


HKG
CH
NSWE
4567895
Sku level override page for System works essentials






upsell detail URL-Chinese









Technical Solution

Rule processing occurs within a RuleContext; this stores all the parameters of the request, and will also contain the final URL. Once the RuleContext has been populated with the request parameters, the preprocessor rule script is executed, if it has been defined. RuleScript is a proprietary scripting language that is able to parse and execute limited java. A typical use of a pre-processing RuleScript is to validate existence of URL parameters, or do preliminary work to set the value of a parameter in the RuleContext that requires complicated logic or database lookups.


After the preprocessor has completed, parameter remapping is executed. Any parameter that has defined remapping rules will have those rules evaluated. Based on the outcome of that evaluation the parameter's value will be set into the RuleContext. After all necessary parameters have been remapped evaluation of the output URL mappings begins. This operation will result in one URL rule being selected, and that URL will be paced into the RuleContext as the RedirectURL. The application then executes the post-processor rule script if it has been defined. Typical use of this script would be to modify the resulting RedirectURL to append additional parameters discovered at runtime.


Detail of Rule Mapping Evaluations

It will be understood by one of ordinary skill in the art that the logic for evaluating output URL rules and parameter remap rules is essentially the same, comparing a parameter's incoming value (or value in the RuleContext) with the value it requires as a condition of a rule. The logic begins by assuming all rules are applicable candidates for selection. It then selects the parameter that was set as the highest ranking and weight and eliminates all rules that have specified value for that parameter that is not equal to that parameters incoming value.


If at this point only one candidate rule remains, then that rule is selected. If evaluating parameter remapping rules, this means that the parameter is given the value defined by the rule. For example, if param A=1 and param B=2, then param C=3. Furthermore, if evaluating output URL rules, then the result is the redirect URL. For example, if param C=3 and param D=4 then URL=www.testredirect.net.


If no candidate rules remain after the parameter is evaluated then the default value is returned. If evaluating parameter remapping rules, this means that the parameter is given the default value set in the parameter definition. It is possible that the user does not define a default value for a parameter, in which case the parameter is added to the RuleContext with no value.


Moreover, if evaluating output URL rules the application looks to see if the user has marked one rule as the default rule. If they have, that URL is returned as the result. If no default URL has been defined an exception occurs. If more than one candidate rule remains after the parameter evaluation, then the application moves onto the next parameter with the highest remaining rank and weight and evaluates that parameter against the remaining candidates. Again the same rules apply after evaluation. It will be understood by one of ordinary skill in the art that if all parameters have been evaluated, and two or more candidate rules still remain, then tie-breaker policies are put in place.


Some rules can specify no value for a parameter, meaning that parameter can have any value, and the rule will still apply. In an exact match policy, the application examines the remaining candidate rules to determine if any rules have defined a specific value for ALL parameters. This is considered an exact match. Additionally, in rules that contain some wildcard values (no value given meaning any value matches) the application will seek rules that specified a value for the highest weighted parameter. This is considered a best match policy. For example, given the rule context [A=1, B=2, C=3], two candidate rules apply: 1. [A=?(anything) and 2. B=2 and C=3] and [A=1 and B=2 and C=?(anything)]. Both candidates had exact matches with 2 parameters, #1 A/B, #2 B/C. However rule #2 is selected because it had exact matches for higher weighted parameters (A/B) vs. rule #1 which had exact matches with B and C. If rule #2 had a wildcard value for parameter B, thus only having an exact match on A, it would still win, because it matched one higher weighted parameter, although rule #1 matched two lower weighted parameters. Table 11 shows a rule handler example.









TABLE 11





Rule handler example

















<start rule handler>



// enter any pre-processing scripting here



com.digitalriver.system.derive.determineNewUrl;



// enter any post-processing scripting here



<end rule handler>



Given that template, here is an example



<start rule handler>



// enter any pre-processing scripting here



String state = “ACTIVE”;



String sku = request.getParameter(“spskuP”);



if (StringUtils.isEmpty(sku)){



 sku = request.getParameter(“spskuM”);



 state = “INACTIVE”;



}



// now add new values for input parameters, before processing



request.setAttribute(“sku”,sku);



request.setAttribute(“state”, state);



com.digitalriver.system.derive.determineNewUrl;



// enter any post-processing scripting here



//an example



logger.finer(“derive is redirecting to...” +



request.getAttribute(“deriveUrl”));



<end rule handler>










A request attribute named “deriveUrl” will be made available to post handler. Tables 12-16 show a few examples of data in mapped parameter sets, also described in FIG. 16.









TABLE 12







Sample data for ECM_DERIVE_RULE_INFO











RULE_INFO_ID
PROMOTION_URL_ID
PRE_HANDLER
POST_HANDLER
ACTIVE





5000
87990
Null
null
1
















TABLE 13







Sample Data for ECM DERIVE PARAMETER














PARAMETER_ID
RULE_INFO_ID
NAME
DEFAULT_VALUE
ALLOWED_VALUES
TYPE
REMAPPED
RANK





5000
5000
catid
null
null
0
0
1


5001
5000
locale
null
null
2
0
2


5002
5000
language
null
null
2
0
3


5003
5000
sku
null
null
2
0
4


5004
5000
spefsku
null
null
0
0
5


5005
5000
state
null
null
0
0
6


5006
5000
upsellProduct
null
null
1
1
7
















TABLE 14







Sample Data for ECM_DERIVE_REMAP









REMAP_ID
PARAMETER_ID
VALUE





5000
5006
NIS


5001
5006
NSW


5002
5006
iNIS


5003
5006
iNSW


5004
5006
NSWE
















TABLE 15







Sample Data for ECM_DERIVE_REMAP_PARAMETER












REMAP_ID
PARAMETER_ID
VALUE
OPERAND







5000
5000
2
<=



5001
5000
3
>=



5002
5000
2
<=



5002
5005
Inactive
=



5003
5000
3
>=



5003
5005
Inactive
=



5004
5000
3
=



5004
5004
12345
=

















TABLE 16







Sample Data for ECM_DERIVE_URL_PARAMETER










URL_INFO_ID
PARAMETER_ID
VALUE
OPERAND





157490
5001
zh_HK
=


157490
5002
en
=


157490
5006
NIS
=









It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and function of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail, especially in matters of structure and arrangement of parts within the principles of the present invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed. For example, the particular elements may vary depending on the particular application for the web interface such that different dialog boxes are presented to a user that are organized or designed differently while maintaining substantially the same functionality without departing from the scope and spirit of the present invention.

Claims
  • 1. A system for establishing Uniform Resource Locator (URL) mapping rules over a network, comprising: a parameter module for storing conditions;a bulk loading module operatively configured to allow a user to input parameter values and rules for the conditions; anda URL map generator that creates a URL mapping rule from parameter values received by the bulk loading module based on conditions stored in the parameter module.
  • 2. A system for generating links by utilizing the URL mapping rule system of claim 1 and a link generator that transforms an incoming URL based on URL mapping rules to determine a destination URL.
  • 3. A system for redirecting the incoming URL in a hypertext transfer protocol (HTTP) request message by utilizing the link generator system of claim 2 to redirect an HTTP request to the destination URL based on the URL mapping rules.
  • 4. The system of claim 1 wherein the bulk loading module is operatively configured to generate a customizable matrix of a mapped parameter set from the stored conditions and user input parameter values and rules.
  • 5. The system of claim 1 wherein the bulk loading module is operatively configured to allow users to execute business logic prior to a URL mapping.
  • 6. The system of claim 1 wherein the bulk loading module translates an input parameter and value to an output parameter and value to redirect a hypertext transfer protocol (HTTP) request to a destination URL.
  • 7. The system of claim 6 wherein the bulk loading module is operatively configured to maintain exclusive multiple groups of mapping rules to redirect the HTTP request to the destination URL.
  • 8. The system of claim 1 wherein the bulk loading module is operatively configured to create a rule handler to modify one of a parameter and a rule.
  • 9. The system of claim 1 further comprising a web based graphic user interface to the bulk loading module.
  • 10. A method for establishing a Uniform Resource Locator (URL) mapping rules implemented by a server operable in a network, comprising: storing conditions in a parameter library in the server;bulk loading, into the server, parameter values and rules for the conditions; andcreating a URL mapping rule from parameter values based on stored conditions.
  • 11. The method of claim 10 further comprising a step of generating links by transforming an incoming URL from the network based on URL mapping rules to determine a destination URL in the network.
  • 12. The method of claim 11 further comprising a step of redirecting the incoming URL in a hypertext transfer protocol (HTTP) request message by utilizing the generated link.
  • 13. The method of claim 10 wherein the bulk loading step includes generating a customizable matrix of a mapped parameter set from the stored conditions and user input parameter values and rules.
  • 14. The method of claim 10 wherein the bulk loading step includes executing business logic prior to a URL mapping.
  • 15. The method of claim 10 wherein the bulk loading step includes translating an input parameter and value to an output parameter and value to redirect a hypertext transfer protocol (HTTP) request to a destination URL.
  • 16. The method of claim 15 wherein the bulk loading step includes maintaining exclusive multiple groups of mapping rules to redirect the HTTP request to the destination URL.
  • 17. The method of claim 10 wherein the bulk loading step includes creating a rule handler to modify one of a parameter and rule.
  • 18. The method of claim 10 further comprising a step of providing a web based graphic user interface to enable the bulk loading step.
Parent Case Info

This application claims the benefit of U.S. Provisional Application No. 60/797,542 filed 4 May 2006, entitled “Derive Logic,” which is incorporated herein by reference.

Provisional Applications (1)
Number Date Country
60797542 May 2006 US