2 Implementation Overview

Mirror of Oracle documentation

Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.

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 Interface s

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

Applicatio n	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_COD E	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:

1. Populate AIF data warehouse with raw attribute data using AIF DATA batch jobs.

2. Optionally, perform translation.

3. Parse.

4. Cleanse and standardize.

5. Categorize and label.

6. Define the attributes.

7. 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

Applicatio n	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_TYP E	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

Table 2-2 (Cont.) Mandatory CDT Configuration Parameters

Applicatio n	Parameter	Description	Value
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 Table 2-3c Table 2-3	DEF_NUM_WEEKS_FOR_SI MILARITY ontains the mandatory config Mandatory DT Configurati	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. uration parameters for DT. on Parameters	15
Applicatio n	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_AVAILABL E	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_CO MPLETED_WK	The last completed week for the SKU/Store ranging data copying.	Week ID from RSE_CAL_HIER
DT	WGT_CALC_INTERVAL_LEN GTH	The number of weeks to group into an interval that is then used to perform weight calculations.	4

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

Table 2-3 Mandatory DT Configuration Parameters

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

Table 2-4 Mandatory AC Configuration Parameters

Applicatio n	Parameter	Description	Value
CIS	CIS_DFLT_CALENDAR_HIE R_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.

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-5 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_N AME, PRODUCT_ATTR14_N AME OR PRODUCT_ATTR13_N AME column.
		• Basic non-fashion and single-level fashion items, multi-level fashion items or level transaction items are extracted.

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_prod_hier_load.ksh	• W_PROD_CAT_DH • W_DOMAIN_MEMBER_LKU P_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_CO DE 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_CO DE 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

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
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(P ROD_EXT_CODE) • W_RTLCMD_PRODUCT_M TX_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.PR OD_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_FR ANCHISE value is F, w_int_org_attr current flag is enabled and deleet flag is disabled, and that Organization Attribute Name 23 is F

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_loc_hier_load.ksh	• W_DOMAIN_MEMBER_LKU P_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_nod e 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_CO DE 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_nod e 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.ks h	• W_RTL_TRADE_AREA_D • W_RTL_TRADE_AREA_LO C_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.

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_trade_area_hier_load.ksh	• W_RTL_TRADE_AREA_D • W_DOMAIN_MEMBER_LKP _TL • W_RTL_TRADE_AREA_LO C_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(do main_member_code); and the delete flag is disabled • w_domain_member_lkp_tl.d omain_code is ’RTL_TRD_AREA and the language code is the PRIMARY_LANGUAGE_CO DE 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_PERI OD	Values are retrieved based on the RA_FISCAL_CAL_ID defined in RSE_CONFIG.
	• W_MCAL_WEEK_D_WEEK • W_MCAL_DAY_D_DAY • W_MCAL_YEAR_D • W_MCAL_QTR_D
	• W_MCAL_PERIOD_D
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’).

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_custseg_src_xref_load.ksh	W_RTL_CUSTSEG_D	• Retrieves records from AIF data warehouse tables that have records in RSE_CUSTSEG_SRC_XRE F. • 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(custse g_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_e xt_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_CO DE of RSE Config or, language and source language code are the same. The domain code is RETAIL_CLUSTER_GRP.

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_price_zone_load.ksh	• W_RTL_CLSTR_HDR_D	• Record must be current
	• W_RTL_CLSTR_GRP_HDR _LC_D • W_RTL_CLSTR_HDR_D_C H	(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_CO DE 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 levelname should
		_ exist in rse_hier_level(descr).

Table 2-5 (Cont.) Data Validations

AIF Application Program	AIF Data Table Referenced	Validation
rse_season_phase_item_load.ks h	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_e xts_id); • The prod_scd1_wid should exist in rse_prod_src_xref.prod_ext_i d.
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.

---

In this guide

• Guide: AI Foundation Implementation Guide
• Previous: 19 AI Foundation Web Services
• Next: 20 Batch Processing

Related chapters

• 17 Configuration — AI Foundation Implementation Guide · shares AE_CALC_INT_LENGTH, CAL_PERIOD_LEVEL, CDT_CAL_LEVEL_ID, CDT_CMGRP_LEVEL_ID
• 18 Attribute Processing — AI Foundation Implementation Guide · shares CMGRP_HIER_TYPE, RSE_PROD_SRC_XREF, W_DOMAIN_MEMBER_LKP_TL, W_PRODUCT_ATTR_D
• 2 AI Foundation Data Standalone Processes — AI Foundation Operations Guide · shares W_DOMAIN_MEMBER_LKP_TL, W_INT_ORG_ATTR_D, W_INT_ORG_D, W_INT_ORG_DH
• 6 Data Validation Framework — AI Foundation Operations Guide · shares W_DOMAIN_MEMBER_LKP_TL, W_INT_ORG_DH, W_PRODUCT_ATTR_D, W_PRODUCT_D