| Oracle® Retail Advanced Science Engine Implementation Guide Release 14.1 E59126-02 |
|
 Previous |
 Next |
| Oracle® Retail Advanced Science Engine Implementation Guide Release 14.1 E59126-02 |
|
Previous |
Next |
This chapter addresses attribute preprocessing. It contains the following sections:
Attributes provide context about products and enhance the accuracy of DT and CDT models. Attributes are stored within RA and are derived from product descriptions and merchandise hierarchy.
RADM may or may not contain product attributes and any attributes found in RADM may have been created for BI reporting or other purposes and may need mining or preprocessing to make them suitable for ORASE.
Some steps in attribute preprocessing require manipulating attribute data. Oracle Enterprise Product Data Quality is a software package that facilitates some of the preprocessing data manipulation steps required to make attributes suitable for CDT and DT modeling.
Here is an example of product information for yogurt.
Product description: Dannon non-fat organix 6 oz.
Class description: Dairy product.
Sub-class description: Yogurt.
SKU/Store attributes determined by preprocessing:
Brand
Price
Size
Note that CDT and DT modeling work optimally when there are five or fewer possible values for any given SKU-store attribute. For example, many price points are available for yogurt. For CDT and DT, it is better to define between 3 and 5 prices bins (that is, budget, regular, premium, and elite).
The basic steps for attribute preprocessing are as follows:
Populating RADM with attribute data
Translating (optional)
Parsing
Cleansing and standardizing
Categorizing and labeling
Defining attributes
Binning and grouping
Populating RADM with Attribute Data
To make RADM attributes suitable for ORASE requires a few steps for the applications to use this data.
The first requirement is to ensure that the attribute values are populated in RADM. This is the source for ORASE's attribute data and must be loaded there in order to be available to ORASE.
Regarding RADM attributes: In RADM, an attribute can be defined in multiple ways. Flex attributes are typically stored in a column of the W_PRODUCT_ATTR_D table. RADM has a table W_RTL_METADATA_G that contains a list of defined attribute locations. Consult this list to see if there is already a defined place to store a particular attribute value.
RA also offers the ability to store Item Differentiators for products. These are essentially User Defined Attributes (UDAs), which consist of lookup code for the attribute and the attribute value. These lookup codes are then defined in RADM's standard translation table (W_DOMAIN_MEMBER_LKP_TL with domain codes of ITEM_UDA_HEAD and ITEM_UDA). The actual association of an item to one of the UDAs is performed in the W_RTL_ITEM_GRP 1_D table.
Once attributes are available in RADM, it is necessary to define these attributes in ORASE's RSE_BUSINESS_OBJECT_ATTR_MD table. This table must be set up with appropriate metadata to define the source of the attributes from RADM. The sample seed_data file for this table contains some standard attributes that would be defined in RADM, but the table needs to be adjusted to contain the complete list of attributes that should be available for ORASE modules to use. This needs to include Flex Attributes as well as User Defined Attributes.Once attributes are defined in ORASE's RSE_BUSINESS_OBJECT_ATTR_MD, the next step is to provide custom lists of attributes that should be used per product category. This can be done through the RSE_PROD_ATTR_GRP_VALUE_STG and RSE_PROD_ATTR_VALUE_XREF_STG interfaces. The first interface is used to define the output of the binning and grouping of attributes. For example, if Coffee needs a Brand Tier attribute, and it should have values of Premium, Value, and Mainstream, then this interface would define this Coffee Brand Tier attribute, along with the values of Premium, Value, and Mainstream, and it should specify what source attribute is to be used for this (the source would be in RSE_BUSINESS_OBJECT_ATTR_MD). The second table of the interface (RSE_PROD_ATTR_VALUE_XREF_STG), would enable the association of specific Brand attributes to the binned/grouped attribute values from the first interface (RSE_PROD_ATTR_GRP_VALUE_STG).One concept to consider for these attributes and attribute values, is that they must be unique across all product categories. This offers the ability to classify one Brand as Premium for one product category, while it could be Mainstream for another product category. Additionally, it enables a different selection of attribute values for each product category. For example, another product category might not have a Premium Brand Tier, and therefore the interface would not include this value in this interface for that product category.
Translating
This step is only needed when the product data is in a different language than the customer's primary language.
Parsing
This step identifies and extracts target key words, such as "Dannon", "small", "blue", and "non-fat". from the source data (such as product description). It is done through semantic recognition, usually by software such as Oracle Enterprise Product Data Quality.
Cleansing and Standardization
This step edits the text and corrects spelling and grammar. For example, "Addr." will be recognized and converted into "Address" and "St." into "Street". EPDQ can facilitate this step.
Categorizing and Labeling
This step classifies targeted key words into the pre-defined categories, such as "Dannon" for "Brand", "small" for "Size" and "blue" for "Color". The product record can thus be labeled by the category values. EPDQ can facilitate this step.
Defining Attributes
With the extracted categories from the product data, attributes are defined. They can be some or all of the categories identified based on contextual business knowledge and how populated are the categories.
Binning and Grouping
Binning and grouping is used to consolidate and reduce the number of possible values for an attribute into a manageable number.
Binning divides numerical attributes, such as 'price', 'discounts', and 'mileage.' into discrete sets of ranges, such as, '<=$10', '$10~$25', and '>$25'.
Grouping combines textual attributes that are too granular into a smaller set of attribute values. For example, 'tea weight' can have dozens of values; grouping merges the values into coarser ranges (like "small" or "large") and reduces the number of possible attribute values.
Enterprise Data Quality for Product is a pre-built solution that processes textual data through semantic recognition and cleanses, parses, and classifies data into well-formatted standardized text for functions like attribute extraction. It is made up of three core modules that work together to enforce category-specific standards on disparate product information:
Oracle DataLens Knowledge Studio
Oracle DataLens Application Studio
Oracle DataLens Governance Studio
Semantic model recognizes item category based on context.
Target information is identified and extracted.
Missing information is flagged.
Items are transformed and reassembled to meet target system standards.
For attribute preprocessing, the main application of EDQP is the Knowledge Studio. In Knowledge Studio, input data can be any textual data, structured or unstructured in various categories or formats. For more information on EDPQ, see Oracle Enterprise Data Quality for Product Data.
This section provides an example of adding an attribute for use by ORASE into all the relevant tables. In this example, a new attribute is added to represent Flavor within the Coffee product category.
The process flow for this involves:
Identify the need to add a new product attribute for a product category
Determine where the attribute data is found within RADM
Add attribute definition in ORASE tables, if it not already present
Run the process to load attribute data from RADM
Determine if the attribute data requires any special grouping or binning
Populate the RSE_PROD_ATTR_GRP_VALUE_STG staging table with attribute definition and values
Populate the RSE_PROD_ATTR_VALUE_XREF_STG staging table with data to associate raw RADM attribute values to the Attribute Groups defined above
Process the interface staging tables
Update CIS attribute data to reflect the new attribute (product attributes)
Update CIS attribute data to reflect the new attributes (non-product attributes)
The first step in the process is the catalyst that triggers the remaining steps. The catalyst is the new attribute that has been introduced and must be made available within ORASE.
The new attribute is loaded from RADM for each of the products that require this attribute. RADM has multiple ways of loading attributes, so the approach used varies, depending on where and how the data is stored in RADM. The process involves defining the source table and then defining the column (or column filter values) used to identify the attribute. Once the source is determined, the appropriate values are loaded into RSE_BUSINESS_OBJECT_ATTR_MD and possibly RSE_BUSINESS_OBJECT_DB_SRC.
RADM's W_PRODUCT_D table and W_PRODUCT_ATTR_D table can provide attributes from any of the available columns in these tables. The W_PRODUCT_D table contains named columns with data of a specific logical value, while the W_PRODUCT_ATTR_D table contains a more flexible set of Number, Text, and Date columns that can contain varying values, depending on the implementation. From an attribute point of view for the ORASE, these tables are effectively the same and require the same type of handling.
These tables each have similar entries in the RSE_BUSINESS_OBJECT_DB_SRC, and no change should be required here. However, a new row is required in RSE_BUSINESS_OBJECT_ATTR_MD that refers to the proper data source table. For rows added to RSE_BUSINESS_OBJECT_ATTR_MD, the values must be populated as follows:
Table 9-1 RSE_BUSINESS_OBJECT_ATTR_MD
| Column | Example | Description |
|---|---|---|
|
ID |
100 |
Unique ID for this entry. |
|
BUSINESS_OBJECT_MD_ID |
1 |
Foreign Key to RSE_BUSINESS_OBJECT_MD. For product attributes, this should be a 1. |
|
BUSINESS_OBJECT_DB_SRC_ID |
8 |
Foreign Key to RSE_BUSINESS_OBJECT_DB_SRC which relates to the table that contains the new attribute column. |
|
NAME |
Flavor |
A short descriptive name for the attribute. |
|
DESCR |
Flavor |
A more descriptive name for the attribute. |
|
SHORT_DB_NAME |
Flavor |
An alias for this database column name, which can be used as the column name for this attribute value when the attribute is later used in a cross tab query. |
|
SRC_COLUMN_NAME |
PRODUCT_ATTR25_NAME |
The name of the column that contains this attribute. |
|
EXCLUDE_FLG |
N |
A Y/N value to either exclude this attribute (Y) or not (N) from processing. |
The W_RTL_ITEM_GRP1_D and W_RTL_ITEM_GRP2_D tables in RADM are different than the other product attribute sources, in that these tables can have attributes implemented as unique rows and specific columns. These tables contain a PROD_GRP_TYPE column, which defines the type of data in the table. Values of ITEMUDA are used for User Defined Attributes. Rows in which the PROD_GRP_TYPE corresponds to the BRAND, COLOR, FLAVOR, SCENT, FABRIC, and STYLE WID columns (ex. BRAND_WID) are also possible.
For processing new attributes in this table, it may be necessary to add new rows to the RSE_BUSINESS_OBJECT_DB_SRC table if any special rules regarding WHERE clauses for filtering data for the attribute are required. If an attribute is defined with a PROD_GRP_TYPE of ITEMUDA, BRAND, COLOR, FLAVOR, SCENT, or SIZE, then no additional rows will be required, as these should already be present. If a new row is required because there is no predefined row with a suitable FILTER_CLAUSE, then add a row as necessary, adjusting the FILTER_CLAUSE appropriately, using one of the existing rows related to W_RTL_ITEM_GRP1_D as an example.
The next step is to define the attribute in the RSE_BUSINESS_OBJECT_ATTR_MD table. Examples for setting up data are:
Table 9-2 RSE_BUSINESS_OBJECT_ATTR_MD
| Column | Example | Description |
|---|---|---|
|
ID |
101 |
Unique ID for this entry. |
|
BUSINESS_OBJECT_MD_ID |
1 |
Foreign Key to RSE_BUSINESS_OBJECT_MD. For product attributes, this should be a 1. |
|
BUSINESS_OBJECT_DB_SRC_ID |
10 |
Foreign Key to RSE_BUSINESS_OBJECT_DB_SRC that relates to the table that contains the new attribute column. |
|
NAME |
Flavor |
A short descriptive name for the attribute. |
|
DESCR |
Flavor |
A more descriptive name for the attribute. |
|
SHORT_DB_NAME |
FLAVOR |
An alias for this database column name, which can be used as the column name for this attribute value when the attribute is later used in a cross tab query. |
|
SRC_COLUMN_NAME |
FLEX_ATTRIB_3_CHAR |
The name of the column that contains this attribute. For ITEMUDA, the actual attribute value is expected to be found in FLEX_ATTRIB_3_CHAR. Adjust if needed. |
|
PROD_GRP_TYPE |
ITEMUDA |
This column contains the value as found in the same column of W_RTL_ITEM_GRP1_D in RADM. |
|
ATTR_EXT_CODE |
FLAVOR |
This value is normally the same value as the one in FLEX_ATTRIB_1_CHAR and is used to define the external code for the attribute. |
|
TL_DOMAIN_CODE |
ITEM_UDA |
For ITEMUDA's, the attributes are normally lookup codes, which therefore can have translated values associated with the codes. This value defines how to locate such values from the W_DOMAIN_MEMBER_LKP_TL table in RADM. |
|
TL_JOIN_EXPR |
pa.attr_value_ext_code||'~' ||boam.attr_ext_code |
This expression defines how to join the W_DOMAIN_MEMBER_LKP_TL row to the W_RTL_ITEM_GRP1_D row. This value is joinable to the DOMAIN_MEMBER_CODE column, in W_DOMAIN_MEMBER_LKP_TL. |
|
EXCLUDE_FLG |
N |
A Y/N value to either exclude this attribute (Y) or not (N) from processing. |
The attribute loading can be performed by running a shell script in the common/scripts/bin directory of the RSE_HOME. Running rse_cda_etl_load.ksh PRODUCT executes the appropriate ETL routine to copy product attributes. This routine should not only be run during system startup, but should also be scheduled for routine execution as part of a maintenance batch.
Once the attribute data is in the ORASE tables, it is possible to review the attribute data (in table RSE_PROD_ATTR) to determine if the attribute requires any special grouping. The CDT application requires attribute values that are grouped in logical buckets of values. For example, when adding a Flavor attribute, many different flavors may be available for the product category. Too many distinct values can affect the ability to detect purchasing patterns for customers, so the data must be reduced to a manageable set of values (no more than 5 values). This process is known as attribute grouping or attribute binning.
Some attributes may also be used to arrive at different attributes. For example, with Flavor, it is possible to arrive at just two groups of Flavored and Non Flavored, but it might also be desired to further distinguish between the different types of Flavored values (such as Non Flavored, Fruit Flavored, Mild Flavored, and Specialty Flavored). This type of processing requires knowledge of the product attributes, so that the values can be correlated correctly. For this example, the single attribute that is added for Flavor is introduced as two separate groups of attributes, as just described.
Once the attribute data has been reviewed and groups have been defined, it is necessary to define the attribute group and process them into the database. The output of the prior step must be loaded into ORASE's staging table for Attribute Value Groups (RSE_PROD_ATTR_GRP_VALUE_STG). This interface defines two sets of data and is used to load two different tables.
Table 9-3 RSE_PROD_ATTR_GRP_VALUE_STG
| Column | Example | Description |
|---|---|---|
|
PROD_HIER_TYPE_NAME |
Product Hierarchy |
Must match the NAME from RSE_HIER_TYPE that has the ID equal to the RSE_CONFIG for CMGRP_HIER_TYPE. |
|
PROD_EXT_KEY |
CLS~1000~10000 |
The external key used to identify the product category (for example, Coffee Class). This value is the same as in RADM's INTEGRATION_ID of the W_PROD_CAT_DH, and also the PROD_EXT_KEY of the RSE_PROD_SRC_XREF table. |
|
ATTR_SHORT_DB_NAME |
FLAVOR |
This must match the SHORT_DB_NAME of the RSE_BUSINESS_OBJECT_ATTR_MD table for the newly added attribute. |
|
PROD_ATTR_GRP_EXT_KEY |
CLS~1000~10000~flavor_yn CLS~1000~10000~flavor_type |
This must be a unique value to describe the attribute to be used by ORASE modules. Since the source Flavor attribute is being defined as two different attributes for ORASE, two example values are shown here. |
|
PROD_ATTR_GRP_NAME |
FlavorYN FlavorType |
A name to be displayed in the UI for the new attribute. Two example values are shown here. |
|
PROD_ATTR_GRP_DESCR |
Flavor Y/N Indentifier Flavor Type |
An optional/additional descriptive value that can be displayed in the UI for the new attribute. |
|
PROD_ATTR_VALUE_KEY |
(See additional table below) |
A unique/external identifier for the new attribute values. |
|
PROD_ATTR_VALUE_NAME |
(See additional table below) |
A name displayed in the UI for the attribute value. |
|
PROD_ATTR_VALUE_DESCR |
(See additional table below) |
An optional/additional descriptive value that could be shown in the UI for the new attribute value. |
|
FUNC_ATTR_FLG |
N |
This is a Y/N flag to indicate whether this attribute is considered to be an attribute associated with a specific function or role (Y) or not (N). For example, a customer cannot choose a product with a different value for the auto wiper blade size because each car model has a specific size requirements. |
Here is a table showing the different values for adding the example Flavor Attribute Values.
Table 9-4 Flavor Attribute Values
| PROD_ATTR_ GRP_NAME | PROD_ATTR_VALUE_KEY | PROD_ATTR_VALUE_NAME | PROD_ATTR_VALUE_DESCR |
|---|---|---|---|
|
FlavorYN |
CLS~1000~10000~flavor_yn~y |
Y |
Yes |
|
FlavorYN |
CLS~1000~10000~flavor_yn~n |
N |
No |
|
FlavorType |
CLS~1000~10000~flavor_type~non |
Non Flavored |
Non Flavored |
|
FlavorType |
CLS~1000~10000~flavor_type~fruit |
Fruit Flavored |
Fruit Flavored |
|
FlavorType |
CLS~1000~10000~flavor_type~mild |
Mild Flavored |
Mild Flavored |
|
FlavorType |
CLS~1000~10000~flavor_type~special |
Specialty |
Specialty |
Once the RSE_PROD_ATTR_GRP_VALUE_STG interface has been loaded, it is possible to load the RSE_PROD_ATTR_VALUE_XREF_STG interface with a mapping of actual product attribute values (otherwise known as base attributes) to the attribute groups that were loaded via RSE_PROD_ATTR_GRP_VALUE_STG. The format of data to be loaded here depends on the format of the base attributes. Only one set of attribute value columns should be populated for this interface. These sets are MIN_ATTR_NUM_VALUE and MAX_ATTR_NUM_VALUE (for numeric attributes), ATTR_STRING_VALUE (for text attributes), MIN_ATTR_DATE_VALUE and MAX_ATTR_DATE_VALUE (for date attributes), ATTR_VALUE_EXT_CODE (for dimension based attributes). The sets are mutually exclusive of each other for this interface.
Table 9-5 RSE_PROD_ATTR_VALUE_XREF_STG
| Column | Example | Description |
|---|---|---|
|
PROD_ATTR_VALUE_KEY |
CLS~1000~10000~flavor_yn~y |
Must match a PROD_ATTR_VALUE_KEY that was loaded via the RSE_PROD_ATTR_GRP_VALUE_STG interface. |
|
MIN_ATTR_NUM_VALUE |
0 |
Minimum numeric value to associate with this attribute group value. Only applicable if this attribute uses the ATTR_NUM_VALUE column to store the base attribute value. |
|
MAX_ATTR_NUM_VALUE |
7 |
The maximum numeric value to associate with this range. Only applicable in conjunction with MIN_ATTR_NUM_VALUE. |
|
ATTR_STRING_VALUE |
Y |
A string value to associate with this attribute group value. Only applicable if this attribute uses the ATTR_STRING_VALUE column to store the base attribute value. |
|
MIN_ATTR_DATE_VALUE |
2010-01-01 |
The minimum date value to associate with this attribute group value. Default date format for provided control file is YYYY-MM-DD. Only applicable if this attribute uses the ATTR_DATE_VALUE column to store the base attribute value. |
|
MAX_ATTR_DATE_VALUE |
2010-01-31 |
The maximum date value to associate with this attribute group value. Default date format for provided control file is YYYY-MM-DD. Only applicable in conjunction with MIN_ATTR_DATE_VALUE. |
|
ATTR_VALUE_EXT_CODE |
32 |
For base attributes that are sourced from W_RTL_ITEM_GRP1_D, this column can be used to specify the key from the appropriate source column. This is applicable if this attribute uses ATTR_VALUE_EXT_CODE to store the attribute value. |
Here is a table of some examples for adding a new flavor attribute, using string based attributes.
Table 9-6 Adding a New Flavor Attribute
| PROD_ATTR_VALUE_KEY | ATTR_STRING_VALUE |
|---|---|
|
CLS~1000~10000~flavor_yn~y |
BLUEBERRY |
|
CLS~1000~10000~flavor_yn~y |
RASPBERRY |
|
CLS~1000~10000~flavor_yn~y |
VANILLA |
|
S~1000~10000~flavor_yn~y |
CARAMEL |
|
CLS~1000~10000~flavor_yn~y |
CINNAMON |
|
CLS~1000~10000~flavor_yn~y |
HAZELNUT |
|
CLS~1000~10000~flavor_yn~n |
PLAIN |
|
CLS~1000~10000~flavor_type~non |
PLAIN |
|
CLS~1000~10000~flavor_type~fruit |
BLUEBERRY |
|
CLS~1000~10000~flavor_type~fruit |
RASPBERRY |
|
CLS~1000~10000~flavor_type~mild |
HAZELNUT |
|
CLS~1000~10000~flavor_type~mild |
VANILLA |
|
CLS~1000~10000~flavor_type~special |
CINNAMON |
|
CLS~1000~10000~flavor_type~special |
CARAMEL |
Once the staging tables have been populated with data, it is time to process these interfaces and load them into the target tables.
The data for RSE_PROD_ATTR_GRP_VALUE_STG can either be directly populated into the database or it can be loaded into the database from a text file, using scripts provided by the application.
In $RSE_HOME/common/scripts/bin, a script called rse_prod_attr_grp_value_stg.ksh is available to load a data file located on the Linux server. A directory called $RSE_HOME/common/data/infile is available for storing these types of inbound data files. Once the file is available to be loaded from the Linux server, the rse_prod_attr_grp_value_stg.ksh script should be executed, passing it the full path name of the file to be loaded.
Regardless of whether the staging table was populated via the script referred to in the previous paragraph, or directly loaded, once it is loaded and ready for processing, the script rse_prod_attr_grp_value_load.ksh (located at $RSE_HOME/common/scripts/bin/) can be executed.
If there are any invalid data records, then the table RSE_PROD_ATTR_GRP_VALUE_BAD will be populated with the rows that failed to pass validation. These rows are populated with four standard columns for an interface populated via this method. These columns are ERROR_ROWID, ERROR_ID, ERROR_DESCR, and ERROR_DT. These columns provide insight into the problems with the interface data. Once the data is corrected and re-staged in the staging tables, it can be processed again.
The data for RSE_PROD_ATTR_VALUE_XREF_STG can either be directly populated into the database or it can be loaded into the database from a text file, using scripts provided by the application.
In $RSE_HOME/common/scripts/bin, a script called rse_prod_attr_value_xref_stg.ksh is available to load a data file located on the Linux server. A directory called $RSE_HOME/common/data/infile is available for storing these types of inbound data files. Once the file is available to be loaded from the Linux server, the rse_prod_attr_value_xref_stg.ksh script should be executed, passing it the full path name of the file to be loaded.
Regardless of whether the staging table was populated via the script referred to in the previous paragraph, or directly loaded, once it is loaded and ready for processing, the script rse_prod_attr_value_xref_load.ksh (located at $RSE_HOME/common/scripts/bin/) can be executed.
If there are any invalid data records, then the table RSE_PROD_ATTR_VALUE_XREF_BAD will be populated with the rows that failed to pass validation. These rows are populated with four standard columns for an interface populated via this method. These columns are ERROR_ROWID, ERROR_ID, ERROR_DESCR, and ERROR_DT. These columns provide insight into the problems with the interface data. Once the data is corrected and re-staged in the staging tables, it can be processed again.
After new product attributes and their attribute groups have been defined, there are some standard processes that should be executed, depending on the modules being used from ORASE.
Advanced Clustering (AC) can use product attributes as a clustering criteria. AC uses what is known as attribute share, and for this, it requires some aggregate data to be available, and it also requires attributes to be defined as criteria within the AC metadata tables.
AC has a configuration in RSE_CONFIG called PERF_CIS_APPROACH. This configuration can have a value of CDT if it should use the same types of attribute data as the CDT application uses (RSE_PROD_ATTR_VALUE_XREF_STG rows), or it can have a value of DT to match the attribute data that the DT application uses (base attribute data).
The first step required for AC is to execute the cis_prod_attr_maint.ksh script in $CIS_HOME/scripts/bin. This routine defines the attributes and their values in the appropriate AC metadata tables.
A batch process is provided in the common directory to calculate aggregate sales data for product attributes. In $RSE_HOME/common/scripts/bin, a script is available called rse_wkly_sls_ph_attr_aggr_setup.ksh that is responsible for performing an update of weekly product attribute sales aggregations. The script accepts three parameters that can be used for routine maintenance, required when performing large scale attribute definitions. The first optional parameter refers to the number of weeks of data that should be updated when the process runs. The second parameter is a Y/N flag to signify whether the process should force the updating of weeks that have previously been completed (Y) or not (N: the default). The last parameter is an ID that represents the maximum day for which the data should be updated. In most situations, this last parameter should not be required.
After the appropriate work has been queued for execution, the processes can be executed by running the script called rse_wkly_sls_process.ksh in the same directory.
The AC product attribute process uses store share metrics for its clustering algorithm. This process requires that store shares be calculated for the attributes used by AC. In the $RSE_HOME/cis/scripts/bin directory, there are two scripts that manage this processing. These routines are expected to be run as part of routine weekly maintenance, but can also be run to refresh prior weeks if significant attribute maintenance has been performed.
The first script to be executed is cis_prod_attr_loc_share_setup.ksh, and it accommodates three optional parameters. The first optional parameter refers to the number of weeks of data that should be updated when the process runs. The second parameter is a Y/N flag to signify whether the process should force the updating of weeks that have previously been completed (Y) or not (N: the default). The last parameter is an ID that represents the maximum day for which the data should be updated. In most situations, this last parameter should not be required.
The second script to be executed is cis_prod_attr_loc_share_process.ksh. This script performs the processing of the weeks that were queued for execution by the prior script.
