2 Setup and Configuration
The Setup and Configuration chapter provides parameters and steps for setting up a new Retail Analytics Platform cloud environment. While the platform comprises many application modules (some of which you may not use), there are certain common processes and settings that are shared across all of them. It is critical to check and update these core settings before moving on to later implementation steps, as they will define many system-wide behaviors that could be difficult to change once you've started loading data into the platform.
Configuration Overview
A high-level outline of the setup process is provided below to describe the activities to be performed in this chapter.
Table 2-1 RAP Configuration Overview
Activity | Description |
---|---|
Learn the configuration tools |
The Retail Analytics Platform has many tools available to support an implementation, such as Retail Home, POM, and APEX. Knowing how to use these tools is an important first step in the process. Review the Implementation Tools chapter for details. |
Verify Object Storage connectivity |
Generate access tokens for interacting with Object Storage and test the connection, as it is required for all file movement into and out of the Oracle cloud. Review the Implementation Tools chapter for details. |
Configure the system calendar |
Update the parameters that define the type and characteristics of your business calendar, such as the start and end dates RI will use to define calendar generation. |
Configure the system languages |
Update the master list of supported languages that need to be present in addition to your primary language, such as the need for seeing data in both English and French. |
Configure history retention policies |
Certain data tables in Retail Insights that are leveraged by other applications on the platform have a history retention period after which some data may be erased. |
Configure application-specific settings |
All applications in the Retail Analytics Platform have their own settings which must be reviewed before starting an implementation of those modules. |
Platform Configurations
This section provides a list of initial setup and configuration steps to be taken as soon as you are ready to start a new implementation of the Retail Analytics Platform and have the cloud environments provisioned and generally available.
Several configuration tables in the RAP database should be reviewed before processing any data. A list of these tables is below, along with an explanation of their primary uses. The way to apply changes to these tables is through the Control & Tactical Center, as described in the section on Control & Tactical Center.
Table 2-2 Platform Configuration Tables
Table | Usage |
---|---|
C_ODI_PARAM (C_ODI_PARAM_VW) |
Table used to configure all Oracle Data Integrator (ODI) batch programs
as well as many Retail Insights and AI Foundation load properties. |
W_LANGUAGES_G |
Table used to define all languages that need to be supported in the database for translatable data (primarily for Retail Insights and Science Platform). |
C_MODULE_ARTIFACT |
Table used for database table partitioning setup. Defines which functional areas within RI will be populated (and thus require partitioning). |
C_MODULE_EXACT_TABLE |
Table used to configure partition strategies for certain tables in RI, including the Plan fact used for loading plans and budgets to RI/RSP. |
C_HIST_LOAD_STATUS |
Table used to configure historical data loads, configure certain ad hoc batch processes, and monitor the results of those jobs after each run. |
C_SOURCE_CDC |
Table used to configure and monitor both historical and ongoing integration to Planning applications through the Retail Insights data warehouse. |
C_ODI_PARAM Initialization
The first table requiring updates is C_ODI_PARAM
because your system calendar is populated using the ODI
programs. This table is displayed as C_ODI_PARAM_VW
on the Manage System Configurations screen in the Control & Tactical Center. The following settings must be updated prior to using the platform.
Table 2-3 C_ODI_PARAM Initial Settings
Scenario Name | Param Name | Configuration Guidance |
---|---|---|
SIL_DAYDIMENSION |
START_DT |
Start date for generating the system calendar (this is different from the fiscal calendar). Set 12+ months before the start of the planned fiscal calendar to provide adequate space for adjustments to the fiscal calendar starting period. Example: If your Fiscal start period is currently February 2020, then it would be fine to start the system calendar on 20190101. Starting from the first day of a year ensures there are no incomplete months in the calendar. |
SIL_DAYDIMENSION |
END_DT |
End date for generating the system calendar (this is different from the fiscal calendar). Set 6-12 months beyond the expected end of the fiscal calendar to ensure the final year of that calendar does not extend beyond the available dates. Example: If your Fiscal end period is currently January 2025, then you could set the end date to 20251231. Ending on the last day of a year ensures there are no incomplete months in the calendar. |
SIL_DAYDIMENSION |
WEEK_START_DT_VAL |
Starting day of the week for the system calendar (1 = Sunday, 2 = Monday). The default calendar setup uses a Sunday-to-Saturday week. |
GLOBAL |
RI_OPTIONALLY_ENCLOSED_BY |
Note: This parameter is deprecated in the new RAP architecture and was replaced by CTX file parameters.Set a character to use for wrapping text strings in data files, such as a quotation mark ("), to allow column delimiters to occur within the strings without causing any failures in the load process. The recommended value is " |
GLOBAL |
CURRENCY_CODE |
Set the default currency code used when loading CSV-based fact data files if none are provided on the files themselves. Defaults to ‘USD’. |
GLOBAL |
LANGUAGE_CODE |
Default language code used by the system to load data. Do not change unless your source systems are using a non-English primary language in their database and datasets. Default=EN |
GLOBAL |
RI_PART_DDL_CNT_LIMIT |
The maximum number of partitions to create during the initial setup run. The average initial setup of the calendar may need 50k-150k partitions. The recommended value is 500000 (meaning max 500k partitions) |
GLOBAL |
RI_INV_HIST_DAYS |
The number of days to retain a zero-balance record on inventory positions. Excessive retention of zero balances can cause batch performance issues due to high data volumes. But dropping the records too soon may be detrimental to your business reporting or analytical processes if you make use of zero-balance information. Default=91 days. |
GLOBAL |
RI_CLOSED_PO_HIST_DAYS |
The number of days to retain closed purchase orders on the daily positional snapshots. Closed purchase orders may be important for reporting or analytical processes, but typically are not needed as they do not impact your open on-order calculations. Default=30 days. |
GLOBAL |
RI_GEN_PROD_RECLASS_IND |
Set to ‘Y’ to enable RI to automatically generate item-level reclass records. Can only be used in a non-RMS implementation. Requires that full product files are sent every day, to detect when an item moves between hierarchy positions even if no other change occurred. |
GLOBAL |
RI_INT_ORG_DS_MANDATORY_IND |
Set to ‘Y’ to require input data on the Organization hierarchy interface for the batch to run. This will prevent the batch from executing if the data files were not uploaded properly for a given day or the file was missing from the upload. |
GLOBAL |
RI_PROD_DS_MANDATORY_IND |
Set to ‘Y’ to require input data on the Product hierarchy interface for the batch to run. This will prevent the batch from executing if the data files were not uploaded properly for a given day or the file was missing from the upload. |
SIL_RETAIL_COHEADDIMENSION |
RI_MIS_COHEAD_REQ_IND |
Seed missing customer order (CO) head IDs from sales fact to CO Dimension. If you are providing customer order IDs on your sales history load, make sure to set this to ‘Y’. |
SIL_RETAILCOLINEDIMENSION |
RI_MIS_COLINE_REQ_IND |
Seed missing customer order (CO) line IDs from sales fact to CO Dimension. If you are providing customer order line IDs on your sales history load, make sure to set this to ‘Y’. |
SIL_EMPLOYEEDIMENSION |
RI_MIS_CASHIER_REQ_IND |
Seed missing Cashier IDs from sales fact to Employee dimension. If you are providing employee IDs on your sales history load, make sure to set this to ‘Y’. |
SIL_RETAILCUSTOMERDIMENSION |
RI_MIS_CUSTOMER_REQ_IND |
Seed missing customer IDs from sales fact to Customer dimension. If you are providing customer IDs on your sales history load, make sure to set this to ‘Y’. |
SIL_RETAILPROMODIMENSION |
RI_MIS_PROMO_REQ_IND |
Seed missing promotions from the sales promo fact to the Promotion dimension. If you are providing promotion IDs on your sales history load and not providing a Promotion file, make sure to set this to ‘Y’. |
Retail Insights contains many additional configurations in the C_ODI_PARAM table that are not necessary for platform initialization, but may be needed for your project. This includes Merchandise Financial Planning configurations for specifying custom planning levels to be used in the integration between MFP and RI. The default parameters align with MFP’s default plan outputs, but if you are customizing MFP to use a different base intersection, then you must also update those values in C_ODI_PARAM. Refer to the Retail Insights Implementation Guide for complete details on Planning Configurations.
W_LANGUAGES_G Initialization
The W_LANGUAGES_G
table controls all the languages supported in the translatable database data. This
applies to areas such as product names, location names, attribute values, season/phase descriptions, and other text-based
descriptors. This is important mainly to Retail Insights, which supports displaying data in multiple languages in reporting
and analytics. It is recommended to delete all languages from this table that will not be used because every language code
in this table will have records generated for it in some interfaces, creating unnecessary data that can impact system performance.
For example, product names will automatically have database records initialized for every supported language in this configuration
table, even if the data you are providing does not contain any of those languages. This creates significant amounts of
data in your product descriptions table, which may not serve any real purpose for your implementation. If you are only
using a single primary language, then you can safely delete all but one row from W_LANGUAGES_G
. The default
row to preserve is the one with a language code of US
which is used for American English.
C_MODULE_ARTIFACT Initialization
The C_MODULE_ARTIFACT
table is used by the database to configure table partitioning. Many tables
in Retail Insights are partitioned based on the business calendar (usually by calendar date or fiscal week) and this partitioning
must be performed immediately after the business calendar is loaded. You should perform this step regardless of which application
modules you are implementing, because all foundation data passes through this architecture.
Before running partitioning procedures, you must validate this table has all rows set to ACTIVE_FLG=Y
and PARTITION_FLG=Y
with the exception of W_RTL_PLANFC*
tables (PLANFC module), which should not be
partitioned at this time and must have a flag values of N
instead.
You also must choose whether you are planning to load the Planning facts (such as W_RTL_PLAN1_PROD1_LC1_T1_FS
) for plan/budget data in RI or RSP. If you are not using the table right away, you should also disable the PLAN modules,
like PLAN1. You can revisit this setup later to perform additional partitioning as needed.
C_MODULE_EXACT_TABLE Initialization
The C_MODULE_EXACT_TABLE
table is used for defining flexible partitioning strategies on certain tables.
Most data in this table can be left as-is, but you must update this table if you plan to load Planning or Budget information
into the W_RTL_PLAN1_PROD1_LC1_T1_FS
interface. The partition level must align with the data level of your
plan (typically day or week). To configure the plan partitions, you must update the table C_MODULE_EXACT_TABLE
where MODULE_CODE = PLAN1
. Modify the columns PARTITION_COLUMN_TYPE
and PARTITION_INTERVAL
to be one of the following values:
-
If your input data will be at Day level, set both columns to
DY
-
If your input data will be at Week level, set both columns to
WK
You must then enable the partitioning process in C_MODULE_ARTIFACT
by locating the row for MODULE_CODE=PLAN1
and setting ACTIVE_FLG=Y
and PARTITION_FLG=Y
. If your plan data will extend into the
future, you must also change PARTITION_FUTURE_PERIOD
to the number of future months that need partitions
built (for example, use a value of 6M
to partition 6 months into the future).
C_HIST_LOAD_STATUS
The C_HIST_LOAD_STATUS
table is used to track the progress of historical loads of data, primarily inventory
position and pricing facts. You may edit the following fields on this table based on your implementation needs:
-
HIST_LOAD_LAST_DATE
– Specifies the planned final date for the end of your historical loads (for example, the end of the 2-year period you plan to load into RAP). The history load programs will assume that you are providing each week of inventory in sequence from earliest to latest and process the data in that order. -
ENABLED_IND
– Turns on or off a specific table load for historical data. Most of the tables in these processes are only required for Retail Insights, and the rest can be disabled to improve performance. Set to a value of N to disable a table load. -
MAX_COMPLETED_DATE
– The load programs use this to keep track of the last loaded week of data. It does not allow you to reload this week or any prior week, so if you are trying to start over again after purging some history, you must also reset this field. -
HIST_LOAD_STATUS
– The load programs uses this to track the status of each step in the load process. If your program gets stuck on invalid records change this field back toINPROGRESS
before re-running the job. If you are restarting a load after erasing history data, then you need to clear this field of any values.
If you are implementing Retail Insights, then enable all INV and PRICE modules in the table (set ENABLED_IND
to Y
). If you are only implementing Science or Planning application modules, then the following history
tables should be enabled; all others should be disabled (set ENABLED_IND
to N
).
-
W_RTL_PRICE_IT_LC_DY_F
-
W_RTL_PRICE_IT_LC_DY_HIST_TMP
-
W_RTL_INV_IT_LC_DY_F
-
W_RTL_INV_IT_LC_WK_A
-
W_RTL_INV_IT_LC_DY_HIST_TMP
As you load data files for one or more weeks of history per run, the value of MAX_COMPLETED_DATE
and HIST_LOAD_STATUS
automatically update to reflect the progress you have made. If you need to restart the process
(for example, you have loaded test data and need to start over with production data) these two columns must first be cleared
of all data before beginning the history load again.
C_SOURCE_CDC
The C_SOURCE_CDC
table is used for changed data capture (CDC) parameters for the integrations between
the Retail Insights data warehouse and the Planning application schemas. In general, this table is updated automatically as
batches are run. However, it is important to know when you may need to modify these values.
For most interfaces, the table will initially have no records. The first time an integration batch program runs, it will
take all the data from the source table and move it to the export table. It will then create a C_SOURCE_CDC
record for the target table name, with a value for LAST_MIN_DATE
and LAST_MAX_DATE
matching
the timeframe extracted. On the next run, it will look at LAST_MAX_DATE
as the new minimum extract date and
pulls data greater than that date from the source table. If you are performing history loads for tables, such as Sales Transactions,
you may need to change these dates if you have to re-send data to Planning for past periods.
Specifically for positional data (at this time only Inventory Position), the usage is not quite the same. Positional data
will always send the current end-of-week values to Planning, it does not look at historical weeks as part of the normal batch
process. A separate historical inventory integration program is provided in an ad hoc process, which will allow you to send
a range of weeks where LAST_MIN_DATE
is the start of the history you wish to send, and LAST_MAX_DATE
is the final date of history before normal batches take it forward. It is common to load inventory from end to end in isolation
as it is a data-intensive and time-consuming process to gather, load, and validate inventory positions for multiple years
of history.
W_GLOBAL_CURR_G
The W_GLOBAL_CURR_G table is used by Retail Insights to support up to three additional currencies in reporting and aggregation (other fields above 3 are not used at this time). RI pre-populates global currency fields in all aggregation tables based on the specified currency codes. The desired codes are added to one row in this table and must align with the Exchange Rates data provided separately. This table is available from the Control & Tactical Center and is not a required configuration for any project unless you wish to report on additional currencies in Retail Insights.
Example data to be inserted to this table:
DATASOURCE_NUM_ID | TENANT_ID | GLOBAL1_CURR_CODE | GLOBAL2_CURR_CODE | GLOBAL3_CURR_CODE | GLOBAL1_RATE_TYPE | GLOBAL2_RATE_TYPE | GLOBAL3_RATE_TYPE | DEFAULT_LOC_RATE_TYPE |
---|---|---|---|---|---|---|---|---|
1 |
DEFAULT |
INR |
AED |
PEN |
Corporate |
Corporate |
Corporate |
Corporate |
Application Configurations
In addition to the platform configurations defined above, each application on the platform has its own system and runtime options that need to be reviewed and updated. The information below will guide you to the appropriate content for each application’s configuration options.
Retail Insights
Retail Insights has a significant number of configurations, primarily in the C_ODI_PARAM
table, which
controls batch processes and reporting behaviors throughout the application. If you are implementing Retail Insights as part
of your project, review the “Setup and Configuration” chapter of the Retail Insights Implementation Guide.
Science Platform and Forecasting
Each Science application has parameters that are specific to the batch processing, data movement, algorithms, and user interfaces of those modules. These configurations are stored in several database tables available through the Control & Tactical Center. If you are implementing any Science applications as part of your project, review the Retail Science Cloud Services Implementation Guide.
If you are implementing Merchandise Financial Planning, then you are required to configure and use the Forecasting module in the Science application interface. This requires initial configurations to select forecast parameters, as well as post-data load configurations to select forecast data levels and perform testing of the chosen algorithm. For basic information about Forecasting and what the Science application functionality can support, refer to the “Manage Forecast Configurations” section in the Science User Guide.
To configure the forecast process for MFP, use the Manage System Configurations screen in the Control Center to review and modify the configurations in RSE_CONFIG. These values can be set up now, but you cannot complete the rest of the forecasting process until your foundation data has been loaded into the Science platform.
Appl Code | Parameter Name | Description |
---|---|---|
RSE |
EXTENDED_HIERARCHY_SRC |
Data source providing extended hierarchy data using either |
RSE |
LOAD_EXTENDED_PROD_HIER |
|
PMO |
PMO_PROD_HIER_TYPE |
The hierarchy ID to use for the Offer Optimization product. Default
value is |
RSE |
PROD_HIER_SLSTXN_HIER_LEVEL_ID |
This parameter identifies the hierarchy level at which sales transactions
are provided (7-Style, 8-Style/color or 9 Style/color/Size). It MUST match the extended hierarchy leaf level. Default value
is |
PMO |
PMO_AGGR_INVENTORY_DATA_FLG |
Specifies whether inventory data is present and if it should be used when aggregating activities data. Set this value to |
Planning Platform
Planning Applications such as MFP (Merchandise Financial Planning) can be set up using the Planning Platform (RPAS CE). It allows customers to use a Standard GA template version or configurable planning solution versions. Refer to the Planning application-specific Implementation Guides for more details about these options.