Implementation Overview

2 Implementation Overview

This chapter provides an overview of the implementation of Oracle Retail AI Foundation Cloud Services.

Implementation Process

This section provides details about the implementation process. It assumes that the underlying platforms have been properly implemented. This includes servers, Oracle database, RADM, and WebLogic application servers.

Note:

Data interfaces are required by the application to support the various supported modules. For details about the data interface, see the following:

Oracle Retail Analytics and Planning Cloud Services Data Interfaces

Implementation Steps

The order of steps provided here is designed to simplify the process. The advanced user may be able to change the process order or skip some steps; however, that is not recommended and not documented here.

Note:

See Configuration for details about application configurations that can be modified as part of a deployment.

Configure the Application Roles and Users

Before any user can log into any application, you must set up application roles, add users, and assign users to the correct roles. To do this, complete the steps described in Configuration.

Data Load Overview

During an implementation of any applications, several steps are required. This section provides some details about this process.

There is a script called RSE Config and RSE Master for the common data. There are similar scripts for each application (for example, there is a CIS Config and CIS Master script). All the *Config and *Master scripts are similar in nature, so this section focuses on the common one. However, the concepts apply equally to the application-specific scripts.

Edit and Load Common Seed Data

All the applications share a set of configurable parameters that must be loaded into the RSE_CONFIG table. All have default values and are configurable and editable by the administrator. This section explains how to load and, if desired, edit these parameters.

The .ctl files for common configuration data must be edited and loaded into the staging tables. This data is common to all the applications. The application-specific .ctl files are located in their own application seed_data folders (for example, orase\installer\orase16\so\db\seed_data).

Review the .ctl files in that directory and adjust any configurations needed for the environment. Some configurations cannot be changed after the application has been used; therefore, you must carefully consider the parameters listed in Table 2-1. The remainder are optional and default to reasonable valuables.

The following configuration parameters must be initialized during setup. The values for hierarchy level and type are recommended for any installation that integrates with the CMPO installation and must match for all installed applications.

Table 2-1 Mandatory Common RSE Database Configuration Parameters

Application	Parameter	Description	Value
RSE	CAL_PERIOD_LEVEL	This is the calendar hierarchy level that is used to drive RSE processing.	4
RSE	CHAIN_LEVEL_DESC	The description to use for any top level hierarchy element, when one must be manually created.	CHAIN
RSE	CMGRP_HIER_TYPE	The hierarchy ID to use for the CMPO. Recommendation is for a normal installation with CMPO.	1
RSE	CMGRP_LEVEL_ID	The hierarchy level ID that contains the level of the product hierarchy where the CMPO level exists (installation configuration). Recommendation is for a normal installation with CMPO.	5
RSE	MT_TZ	The time zone that is used by application server(s), that is, by the middle-tier. It must match SELECT tzname FROM V$TIMEZONE_NAMES.	America/New_York
RSE	PRIMARY_LANGUAGE_CODE	The name of the language code to use for all RSE data sourced from the AIF data warehouse tables.	EN
RSE	RA_FISCAL_CAL_ID	The ID of the calendar to use from the AIF data warehouse (since it supports multiple calendars).	1240
RSE	TRADE_AREA_HIER_TYPE	The hierarchy ID to use for the Trade Area (installation configuration).	6
RSE	UI_TZ	The time zone for display. It must match SELECT tzname FROM V$TIMEZONE_NAMES.	America/New_York

Perform Attribute Preprocessing for CDT and DT, as Appropriate

Product attributes are required by CDT and DT and are stored in the RADM. Attribute preprocessing is independent of the AIF applications database and happens in AIF data warehouse tables or flat files generated by the user. Once these tables and files are correct, you can load the resulting attributes in the AIFApps schema as part of the data load process.

Here are the basic attribute pre-processing steps:

Populate AIF data warehouse with raw attribute data using AIF DATA batch jobs.
Optionally, perform translation.
Parse.
Cleanse and standardize.
Categorize and label.
Define the attributes.
Bin and group.

For details on these steps, see Attribute Processing.

Mandatory Configuration Parameters

Table 2-2 contains the mandatory configuration parameters for CDT.

Table 2-2 Mandatory CDT Configuration Parameters

Application	Parameter	Description	Value
CDT	CDT_CAL_HIER_TYPE	The hierarchy ID to use for the fiscal calendar (installation configuration).	11
CDT	CDT_CAL_LEVEL_ID	The hierarchy level ID that contains the level of the calendar hierarchy that CDT operates on. (This should equate to the Week - Installation configuration).	4
CDT	CDT_CMGRP_LEVEL_ID	The hierarchy level ID that contains the level of the product hierarchy that CDTs are created for (installation configuration).	5
CDT	CDT_CUSTSEG_HIER_TYPE	The hierarchy ID to use for customer segment (installation configuration).	4
CDT	CDT_CUSTSEG_LEVEL_ID	The hierarchy level ID that contains the level of the customer segment hierarchy that CDTs are created for (installation configuration).	2
CDT	CDT_LOC_HIER_TYPE	The hierarchy ID to use for location (installation configuration).	2
CDT	CDT_LOC_LEVEL_ID	The hierarchy level ID that contains the level of the location hierarchy that CDTs are created for (installation configuration).	Best equivalent for trade area level
CDT	CDT_PROD_HIER_TYPE	The hierarchy ID to use for the CMPO (installation configuration). The recommendation is for a normal installation with CMPO.	1
CDT	DEF_NUM_WEEKS_FOR_SIMILARITY	The default number of weeks of sales transaction data to be used by the similarity process. This is used when the user does not specify time intervals.	15

Table 2-3 contains the mandatory configuration parameters for DT.

Table 2-3 Mandatory DT Configuration Parameters

Application	Parameter	Description	Value
DT	AE_CALC_INT_LENGTH	The number of weeks to group together for in an interval for the AE calculation.	4
DT	CDT_SIMILARITY_AVAILABLE	Whether the CDT similarity has been made available to DT.	Y
DT	DT_CAL_HIER_TYPE	The hierarchy ID to use for the fiscal calendar.	11
DT	DT_CAL_LEVEL_ID	The hierarchy level ID that contains the level of the calendar hierarchy that DT operates on. (It should equate to week.)	4
DT	DT_CMGRP_LEVEL_ID	The hierarchy level ID that contains the level of the product hierarchy that DTs are created for.	5
DT	DT_LOC_HIER_TYPE	The hierarchy ID to use for location.	5
DT	DT_LOC_LEVEL_ID	The hierarchy level ID that contains the level of the location hierarchy that DTs are created for.	Best equivalent for trade area level
DT	DT_PROD_HIER_TYPE	The hierarchy ID to use for the CMPO.	1
DT	PR_LOC_STATUS_LAST_COMPLETED_WK	The last completed week for the SKU/Store ranging data copying.	Week ID from RSE_CAL_HIER
DT	WGT_CALC_INTERVAL_LENGTH	The number of weeks to group into an interval that is then used to perform weight calculations.	4

Table 2-4 contains the mandatory configuration parameters for AC.

Table 2-4 Mandatory AC Configuration Parameters

Application	Parameter	Description	Value
CIS	CIS_DFLT_CALENDAR_HIER_TYPE_ID	the default calendar hierarchy for clustering.	11
CIS	CIS_DFLT_LOCATION_HIER_TYPE_ID	The default location hierarchy for clustering.	2
CIS	CIS_DFLT_PRODUCT_HIER_TYPE_ID	The default product hierarchy for clustering.	1
CIS	PERF_CIS_APPROACH	The approach to use for performance based clustering. The available options are CDT and DT.	CDT

Note:

There are no mandatory configuration parameters for MBA.

Table 2-5 Mandatory ASO Configuration Parameters

Application	Parameter	Description	Value
SO	SO_CAL_HIER_TYPE	The hierarchy ID to use for the calendar (installation configuration).	10
SO	SO_FISCAL_CAL_HIER_TYPE	The hierarchy ID to use for the fiscal calendar (installation configuration).	11
SO	SO_LOC_HIER_TYPE	The hierarchy ID to use for location (installation configuration).	2
SO	SO_PROD_HIER_LEVEL_FOR_LEAF_NODE	The product hierarchy level number for leaf node.	7
SO	SO_PROD_HIER_TYPE	The hierarchy ID to use for the product (installation configuration).	1

Data Validations

AI Foundation is composed of AIF data and AIF applications. AIF applications derive information from AIF data. You can use this analysis of this data to make determine business strategies and decisions.

The following validations are performed on the AIF data.

Table 2-6 Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_prod_src_xref_load.ksh	W_PRODUCT_ATTR_D W_PRODUCT_D	Record must be current (i.e. CURRENT_FLG is Y) The extended hierarchy source is validated: If the extended hierarchy source is RMS, UPC records are excluded from Merch data. If the extended hierarchy source is different, the integration ID should be stored in either the PRODUCT_ATTR15_NAME, PRODUCT_ATTR14_NAME OR PRODUCT_ATTR13_NAME column. Basic non-fashion and single-level fashion items, multi-level fashion items or level transaction items are extracted.
rse_prod_hier_load.ksh	W_PROD_CAT_DH W_DOMAIN_MEMBER_LKUP_TL W_PRODUCT_D_TL W_PRODUCT_D	Record must be current (i.e. CURRENT_FLG is Y) Records should exist in RSE_PROD_SRC_XREF (i.e. prod_ext_key of this table must match the integration id). Language or source language code should be the PRIMARY_LANGUAGE_CODE in AIF Apps, or language and source language code are the same as the domain code (MCAT). Language or source language code should be the PRIMARY_LANGUAGE_CODE of AIF Apps configuration, or language and source language code are the same. Product category hierarchy 5 should be equal to the row ID of W_PRODUCT_CAT_DH table. The extended hierarchy source is validated If extended hierarchy source is RMS, retrieve records with child level 9 with differentiator linked to the dummy parent level8. All levels (child level 9) linked to parent level 8 and parent level8 (all levels) linked to the grandparent level 7 If extended hierarchy source is not RMS, integration ID and Product Attribute 15 should be in RSE_PROD_SRC_XREF (prod_ext_key) table
rse_load_prod_group.ksh	W_RTL_ITEM_GRP1_D	Record must be current (i.e. CURRENT_FLG is Y) Record must not be marked for deletion (i.e. DELETE_FLG is N) The product group type must be ITEMLIST
rse_cm_grp_xref_load.ksh	W_RTL_CMG_PRODUCT_MTX_D W_PROD_CAT_DH	Data's record name is in RSE_HIER_LEVEL(DESCR) and product number is in RSE_PROD_SRC_XREF(PROD_EXT_CODE) W_RTLCMD_PRODUCT_MTX_D product number is the same as W_PROD_CAT_DH’s level 1 product hierarchy code or level 5 to 8 category code depending on RSE_HIER_LEVEL(ID). Also, the data’s ROWID should be in RSE_PROD_SRC_XRED (prod_ext_id).
rse_cm_grp_hier_load.ksh	W_RTL_CMG_PRODUCT_MTX_D W_PROD_CAT_DH	Data's level name should be in RSE_HIER_LEVEL(DESCR) table. Data's product number and hierarchy level should be in RSE_PROD_SRC_XREF (PROD_EXT_CODE) table W_RTL_CMD_PRODUCT_MTX_D product number is the same as W_PROD_CAT_DH’s level 1 product hierarchy code or level 5 or level 8 category code depending on RSE_HIER_LEVEL.ID. Also, data’s row ID should be in RSE_PROD_SRC_XREF.PROD_EXT_ID.
rse_loc_src_xref_load.ksh	W_INT_ORG_DH W_INT_ORG_ATTR_D	Record must be current (i.e. CURRENT_FLG is Y) and not marked for deletion (i.e. DELETE_FLG is N). Level name should be in RSE_HIER_LEVEL(DESCR) If RSE_LOC_HIER_EXCL_FRANCHISE value is F, w_int_org_attr current flag is enabled and deleet flag is disabled, and that Organization Attribute Name 23 is F
rse_loc_hier_load.ksh	W_DOMAIN_MEMBER_LKUP_TL W_INT_ORG_DH W_INT_ORG_D	Data's domain code is RTL_ORG and the domain member code is like the descr from RSE_HIER_LEVEL If RSE_HIER_LEVEL.leaf_node is enabled, retrieve data from w_int_org_dh where scd1_wid is in w_int_org_d(scd1_wid) Record is current (i.e. w_into_org_d.current_flg is enabled) The w_int_org_d integration code is in the rse_loc_xec_xref (loc_ext) table The language or source language code should be the PRIMARY_LANGUAGE_CODE of RSE config or language and source language code are the same and w_int_org_dh(integtration id record should be in w_int_org_d (integration id) If RSE_HIER_LEVEL.leaf_node is disabled. w_int_org_dh(integration_id) must be in rse_loc_src_xref(loc_ext_key) w_domain_member_lkb_tl source language or language is the same as the RSE Config PRIMARY_LANGUAGE CODE or language and source code are the same The w_int_org_dg level name is in rse_hier_level(descr) The integration id is in rse_loc_src_xref.loc_ext_key
rse_trade_area_src_xref_load.ksh	W_RTL_TRADE_AREA_D W_RTL_TRADE_AREA_LOC_MTX_D	Record must be current in both tables (i.e. CURRENT_FLG is Y). Trade area ID of the matrix table is in or equal to the rowid of w_rtl_trade_area_d table.
rse_trade_area_hier_load.ksh	W_RTL_TRADE_AREA_D W_DOMAIN_MEMBER_LKP_TL W_RTL_TRADE_AREA_LOC_MTX_D	Data of w_rtl_trade_area (integration_id) is in rse_loc_src_xref(loc_ext_key) and w_domain_member_lp_tl(domain_member_code); and the delete flag is disabled w_domain_member_lkp_tl.domain_code is 'RTL_TRD_AREA and the language code is the PRIMARY_LANGUAGE_CODE in RSE_CONFIG. Matrix data record (org_scd1_wid) should be in rse_loc_src_Xref(loc_ext_id) and trade_area_wid matches w_rtl_trade_area_d(row_id) and record is current (i.e. current flag is enabled) w_rtl_trade_area(integration_id) is in rse_loc_srcx_xref(loc_ext_id) and the record is current (i.e current flag is enabled) and is not marked for delete (i.e.delete flag is disabled)
rse_fiscal_main_load.ksh	W_MCAL_YEAR_D_YEAR W_MCAL_QTR_D_QTR W_MCAL_PERIOD_D_PERIOD W_MCAL_WEEK_D_WEEK W_MCAL_DAY_D_DAY W_MCAL_YEAR_D W_MCAL_QTR_D W_MCAL_PERIOD_D	Values are retrieved based on the RA_FISCAL_CAL_ID defined in RSE_CONFIG.
rse_promo_src_xref_load.ksh	W_RTL_PROMO_D	Records with promo levels E, P or C are extracted.
rse_promo_hier_load.ksh	W_RTL_PROMO_D	Record exists in rse_hier_lvl(descr) and promo_level is either an Event (‘E’), Promotion (‘P’) or Component (‘C’).
rse_custseg_src_xref_load.ksh	W_RTL_CUSTSEG_D	Retrieves records from AIF data warehouse tables that have records in RSE_CUSTSEG_SRC_XREF. It also retrieves all with a new custseg_hier_id (i.e. cusetseg_ext-key is NULL) Record must be current (i.e. current flag is enabled) and not marked for delete (i.e. delete flag is disabled)
rse_custseg_hier_load.ksh	W_RTL_CUSTSEG_D	Data's rowid should exist in rse_custseg_src_xref(custseg_ext_id), row_wid = -1. Record must be current (i.e.current flag is enabled) and not marked for delete (i.e. delete flag is disabled).
rse_custseg_alloc_load.ksh	W_RTL_CUSTSEG_ALLOC_D W_INT_ORG_DH	Customer segment allocation data (prod_dh_wid), and org_dh_wid should exist in w_int_org_dh (row_id) Customer segment id should exist in rse_custseg_hier(custsetg_ext_code) table Allocation type must be CUSTOMER Record must be current (i.e. the current flag is enabled)
rse_price_zone_grp_load.ksh	W_RTL_CLSTR_HDR_D W_RTL_CLSTR_GRP_D W_DOMAIN_MEMBER_LKP_TL	Record must be current (i.e. CURRENT_FLG is Y) and record must not be marked for delete (i.e. DELETE_FLG is N). Cluster group type must be Zone. Cluster group code exists in W_DOMAIN_MEMBER_LKP_TL via DOMAIN_MEMBER_CODE. For domain member record, language or source language code should be the PRIMARY_LANGUAGE_CODE of RSE Config or, language and source language code are the same. The domain code is RETAIL_CLUSTER_GRP.
rse_price_zone_load.ksh	W_RTL_CLSTR_HDR_D W_RTL_CLSTR_GRP_HDR_LC_D W_RTL_CLSTR_HDR_D_CH	Record must be current (i.e.current flag is enabled) Cluster group wid should exist in rse_price_zone_grp(ext_id) Cluster header wid should exist in w_rtl_clstr_hdr_d(row_wid) Record is not marked for delete (i.e. delete flag is disabled) Record must be current (i.e. current flag is enabled) Cluster header wid should exist in rse_price_zone(ext_id) table For domain member record, language or source language code should be the PRIMARY_LANGUAGE_CODE of RSE config or language and source language code are the same Domain code is RETAIL_CLUSTER_GRP
rse_conseg_load.ksh	W_RTL_CONSUMERSEG_D	Record must be current (i.e. CURRENT_FLG is Y)
rse_fcst_sales_plan_load.ksh	W_PROD_CAT_DH_WPCD W_PRODUCT_D W_INRT_ORG_DH	For records with rse_hier_level_id less than 7: The level_name should exist in rsE_hier_level(descr) The integration id should exist in rse_prod_Src_xref(prod_ext_key) The datasource id must be 1 For records with rse_hier_level_id greater tan or equal to 7: Integration id should exist in rse_prod_src_xref(prod_ext_key) The datasource id must be 1 The w_int_org_dh(scdq_wir) record should exist in rse_loc_src_xref(loc_ext_id) and the level_name should exist in rse_hier_level(descr).
rse_season_phase_item_load.ksh	W_RTL_SEASON_PHASE_IT_D	Record must be current (i.e. current flag is enabled) Data season wid should exists in rse_season(season_ext_id); Phase wid should exist in rse_season_phase(phase_exts_id); The prod_scd1_wid should exist in rse_prod_src_xref.prod_ext_id.
rse_rul_eng_pro_load.ksh	W_RTL_CLSTR_GRP_IT_D	Data (i.e. prod_scd1_wid) should exist in rse_prod_src_xref (prod_ext_id) The product number should exist in rsE_prod_src_Xref(prod_ext_code) The cluster group type is 'ZONE' Record is current (i.e.the current flag is enabled) Record is not marked for delete (i.e. delete flag is disabled) The ID exists in the pro_optimization_rules(price_zone_grp_id) table.

Retail Home Integration

In a Next Gen implementation, you can view usage metric values. In order to use this feature, you must ensure that the RSE_UPDATE_USAGE_METRIC process in the Process Orchestration and Monitoring application is set up as an enabled job as part of your batch schedule. This is the process that gathers the usage metric values and saves them to the subscribed modules during onboarding. See "Process Orchestration and Monitoring" for additional details on how to set up and enable the process.