Integration with Merchandising

Architecture Overview

In release versions 21 and earlier, the integration between MFCS and RI/AIF used a tool named the Retail Data Extractor (RDE) to generate data files for RI/AIF to consume. From version 23, these programs have been fully integrated to the RAP batch flow and directly insert the data from MFCS to RAP. The integration uses an instance of Oracle Golden Gate to copy MFCS tables to the local database, where the Data Extractor jobs can source all required data and transform it for use in RAP.

If you are familiar with the prior RDE architecture, then you need to be aware of the following major changes:

RDE_DM01 database objects are now located in the RADM01 schema. RDE_RMS01 database objects are now in the RABE01USER schema. The RABE01USER now has access to extract records from MFCS through the Golden Gate replicated schema.
The C_ODI_PARAM configuration tables have been merged and all RDE configurations are accessed from the Control & Tactical Center.
File-based integration has been removed. All data is moved directly between database source and target tables with no option to produce flat files.
RDE’s batch schedule has been merged with RI’s schedule in POM. Jobs have been renamed and assigned modules such that it is easy to identify and disable/enable RDE jobs as needed.
Customer Engagement (CE) integration jobs have been included in RDE for when CE is set up to replicate data to RAP. File-based integration is no longer required.
All jobs relating to file extraction, ZIP file creation, or data cleanup in RMS have been removed.

Because RDE jobs are now a part of the RAP nightly batch cycle, they have been assigned modules in the Customer Modules framework (accessed using Retail Home) and can be enabled or disabled in bulk depending on your use-cases.

RDE_RMS – These are the RDE components in relation to RMS
RDE_CE – These are the RDE components in relation to CE

If you are not integrating data from MFCS or CE then you will need to disable these modules to prevent them from running in your nightly batch cycles. RI and AIF jobs are programmed to start automatically after the RDE jobs complete, but if the RDE jobs are disabled then the dependencies will be ignored.

Merchandising Foundation Cloud Service Data Mapping

After Golden Gate makes the copy of all data residing in the source Merchandising Foundation Cloud Service (MFCS) environment, there is a mapping layer that connects the replicated database schema to Retail Data Extractor (RDE) programs. This mapping layer consists of two parts:

The replicated schema contains wrapper view (WV) objects on top of the cloned tables to provide a layer of abstraction between the source and destination. If the underlying table changes in the source it does not necessarily have to impact the target systems, since the view could remain unchanged. For example, the source table ITEM_MASTER has a wrapper view RDS_WV_ITEM_MASTER on top of it.
Within the target RAP database, synonyms are created to map each wrapper view back to its source system name. The synonyms are what are granted to RDE and Innovation Workbench. For example, there is a synonym named ITEM_MASTER which is used by RDE to extract data from the RDS_WV_ITEM_MASTER view. The ITEM_MASTER synonym can also be directly queried from Innovation Workbench instead of trying to query the original wrapper view object. The synonyms reside in the RABE01USER user in the database.

This architecture is used for almost all objects from MFCS, with the following exceptions:

The synonym for ITEM_LOC_SOH points to the MFCS table ITEM_LOC_SOH_EOD, which is the end-of-day inventory snapshot. This is required for RAP to ensure it receives the same end-of-day inventory positions that MFCS and other applications will show. The ITEM_LOC_SOH table itself is not used in RAP integrations at this time due to the constantly changing data from 24/7 inventory program activity.
The synonym for MV_CURRENCY_CONVERSION_RATES refers to V_CURRENCY_CONVERSION_RATES. This is because MV_CURRENCY_CONVERSION_RATES cannot be replicated to a Golden Gate schema, so MFCS created the V_CURRENCY_CONVERSION_RATES view as a replacement.
RAP uses the RMS_CALENDAR synonym to refer to the CALENDAR table. This is because RI also has a CALENDAR table in its schema and the object names would have conflicted within RDE.

Merchandising Foundation Cloud Service Configurations

Retail Data Extractor (RDE) jobs require certain tables and configurations in Merchandising Foundation Cloud Service (MFCS) to be set up with data before you run any batch programs in the AIF DATA schedule. Perform all of the setup activities below in your MFCS environments before starting any batch runs of the AIF DATA schedule that includes RDE jobs.

Table and Batch Job Requirements

The MFCS end-of-day inventory snapshot table, ITEM_LOC_SOH_EOD, must be populated with data. This requires that the REFEODINVENTORY_JOB is running as part of MFCS nightly batch, so enable and run it regularly to maintain accurate inventory positions for RDE jobs to extract.
The MFCS end-of-day transaction snapshot table, IF_TRAN_DATA, must be populated with data. This requires that the SALSTAGE_JOB is running as part of the MFCS nightly batch, so enable and run it regularly to maintain accurate transaction data for RDE to extract.
The MFCS order revision tables (ORDHEAD_REV and ORDLOC_REV) must be maintained using hourly POM cycles in addition to the nightly batch, otherwise the nightly RDE extract for purchase orders may not get the latest revisions for the specific VDATE they are applicable to. Enable and run the standalone or recurring process for ORDER_REVISION_CYCLE at least 1-2 times prior to the nightly batch cycle.
The MFCS history (HIST) tables are required to retain snapshots of key MFCS datasets beyond the current calendar day if the RDE extracts run late. You must run RDE frequently enough to extract data from these tables before MFCS purges them. Specific MFCS nightly batch jobs are required to maintain those tables, as documented in the MFCS Implementation Guide.
The MFCS status table RMS_RDE_BATCH_STATUS is only updated with records for the current VDATE used by nightly batch processing, which may not align with your AIF environment prior to starting batches. You must align the VDATE between systems such that MFCS is one day ahead of AIF prior to running a complete end-to-end batch, otherwise the records inserted into RMS_RDE_BATCH_STATUS will not match the data RDE extracts are looking for. The VDATE is maintained on the PERIOD table in MFCS and is updated in batch by the DTESYS_JOB.

For example, if your current business date in AIF is 8/1/2025, then you must have MFCS set to a VDATE of 8/2/2025 before running batches. When batch runs, MFCS will insert records into RMS_RDE_BATCH_STATUS for VDATE=8/2/2025, which will then signal RDE programs to extract the relevant data for that VDATE. In general, MFCS is always one day ahead of AIF, because MFCS operates on the current calendar day while AIF is only using data through end-of-day yesterday.
The RDE sales integration requires that specific Sales Audit programs are running in the nightly batch. Enable and run the Sales Audit programs SAEXPDW_EXPORT_JOB, SAEXPDW_EXPORT_POST_JOB, and SAEXPDW_EXPORT_PURGE_JOB as part of the nightly batch. These programs will maintain the tables SA_EXPDW_RDWT_HEAD, SA_EXPDW_RDWT_DETAIL, and SA_EXPDW_RDWF_DETAIL which is how RDE receives the daily sales transactions.
Sales Audit also requires configuration to enable the export of transaction data if you are doing it for the first time. Update the field SA_STORE_DATA.SYSTEM_CODE to have a value of RA for all locations if it is not already set.
Sales Audit will only export the current day’s sales postings (inclusive of backposted sales) as part of nightly batch. If you need to export data from a prior date because you are just turning on the jobs now, it requires manual intervention. You will need to update SA_EXPORT_LOG.STATUS to R for the RA system code and delete any related entries in SA_EXPORTED, only for the store/dates you need to export.

Configuration Requirements

The system parameter EDI_REV_DAYS must be updated such that there is no chance of purging old order revisions while they might still receive updates that RDE needs to extract. Change this value to be at least 30 days (or longer, if you have any processes that might update an order more than 30 days after closing it). The associated purchase order purge setting, ORDER_HISTORY_MONTHS, must also be greater than one month. Failure to update these settings could result in data loss due to improper extraction from MFCS tables.
No table in MFCS should be set to purge data immediately (purge days <= 1). All purge-related MFCS settings must be greater than 1 day, and ideally between 7 and 14 days, to avoid data loss before RDE jobs have a chance to extract the data. Refer to the MFCS Implementation Guide section on Data Retention parameters for specific configuration guidance.
RAP applications require that the business calendar from MFCS contain full years only, which is not the default configuration seeded into a new MFCS environment. You must add or remove periods from the MFCS calendar such that the first year of data starts from the first fiscal month of your business calendar (which will usually not be January). For the steps to update the MFCS calendar, refer to the MFCS Implementation Guide section on Calendar Maintenance.
RDE leverages the MFCS financial and stock ledger settings in determining tax handling logic in some programs (mainly DEFAULT_TAX_TYPE and STKLDGR_VAT_INCL_RETL_IND). RDE will use these parameters to calculate tax amounts and automatically include or exclude them from retail values in your inventory and PO facts. These settings are updated during initial provisioning so they should already be configured prior to using RDE extracts. Refer to the MFCS Implementation Guide section on System Options.

Batch Synchronization and Data Recovery

Retail Data Extractor (RDE) jobs are expected to run every day in parallel with the Merchandising Foundation Cloud Service (MFCS) nightly batch cycles. This ensures that the current end-of-day information is extracted in a timely manner from MFCS and loaded to the data warehouse. If this does not happen for any reason, such as when server maintenance for AI Foundation is ongoing or an unplanned outage occurs, then MFCS may move into the next business day before RDE programs can execute, resulting in a gap of 1 or more days between the date expected by the data warehouse and the date in MFCS. When this occurs, the RDE portion of the AIF batch schedule will follow a different execution flow to extract the historical data for the business date it is looking for, even if MFCS is already processing future dates. This alternate execution flow will be referred to as a “data recovery batch” because it represents the RDE programs attempting to recover and extract historical data from MFCS when it is not running on the current business date.

Note:

Data recovery batches are only supported with MFCS version 25.1.301.0 and AIF version 25.2.401.0 or later. If either application is on an older version, the functionality described here will not be available.

MFCS maintains special historical data capture tables to retain critical data elements that would otherwise be lost by user updates made in the next business date. Not all tables have historical versions, only those deemed necessary for RDE to extract date-based historical information that downstream applications require to produce accurate results. These tables will maintain data for a number of days based on MFCS data retention parameters, after which point a data recovery batch will not be possible (as there is no history data available to extract beyond that point). The current list of history tables in MFCS are:

IF_TRAN_DATA_HIST
IF_FUTURE_TRAN_DATA_HIST
ITEM_LOC_SOH_EOD_HIST
ITEM_SUPP_COUNTRY_HIST
ITEM_SUPP_COUNTRY_LOC_HIST

There is also an operational table named RMS_RDE_BATCH_STATUS, which maintains job-level indicators for MFCS batch progress, and this table retains history for past batch executions so that RDE programs know whether data is available for a given VDATE or not. It is required that RMS_RDE_BATCH_STATUS have updates made to it for every date MFCS has run for, without any gaps or missing job executions, because a missing value on this table signals to RDE programs that critical data is missing.

When an AIF DATA nightly cycle runs in POM, the RDE programs will use the following behavior to determine the batch execution flow:

RDE_BUSINESS_DATE_VAL_JOB runs at the start of the batch to detect whether MFCS data has advanced beyond what the data warehouse has already extracted and will fail if it has not. This program prevents the batch from starting when MFCS is still on a date in the past, which can happen if data replication is lagging or MFCS is undergoing server maintenance or an unplanned outage.
RDE_SETUP_DRB_RUN_JOB runs at the start of the batch to detect whether a data recovery batch is needed or normal execution may continue. If MFCS is more than 1 day ahead of the data warehouse, then the RDE_DRB_FLG parameter in the C_ODI_PARAM table will be enabled and all downstream RDE programs will perform data recovery batch steps (if required). The RDE_DRB_NUM_DAYS parameter will capture the number of days back in time that can be extracted. If MFCS is exactly 1 day ahead of the data warehouse, or MFCS is beyond the maximum number of days that history is retained for, then batch will resume using standard nightly extract logic.
When the RDE_DRB_FLG is enabled, the RDE programs perform these actions in addition to (or instead of) their normal steps:
- RA_SRC_CURR_PARAM_G.VDATE will be updated to use the historical date being extracted instead of the current date from MFCS (sourced from parameter RDE_LAST_VDATE_RUN + 1).
- RMS_RDE_BATCH_STATUS table is checked for the historical VDATE instead of the current date, and if any entries are missing for that date, then the interschedule checks will fail.
- All RDE extract programs that use a non-historical table like IF_TRAN_DATA or ITEM_LOC_SOH_EOD will instead source their data from the HIST variant of that table. Tables such as IF_TRAN_DATA are transient in nature, retaining data only for the current business date. This is why historical data capture for these areas is necessary. The data extracted from the HIST tables will be for the specific date (stored in the HIST_WRITTEN_DATE field) that the data warehouse is currently expecting to receive next in batch.
- Other RDE programs that use date-based filtering, such as those using the PRICE_HIST table or those performing incremental extracts, will adjust their filters to get the required historical date instead of the current date. Filters with a dynamic range such as “sysdate – 2” will be offset to include the historical dates being extracted based on RDE_DRB_NUM_DAYS parameter.
  
  Note:
  That this may result in the same records being extracted over multiple batches, which is expected and is done to avoid missing any records due to dynamic sysdate-based filters.
At the end of the RDE portion of the batch, the following jobs are run to set or reset parameters:
- The job RDE_BATCHFINAL_SETLASTDATERUN_JOB will update the parameter RDE_LAST_VDATE_RUN to capture the last successful business date extracted by RDE programs.
- The job RDE_BATCHFINAL_RESET_DRB_SETUP_JOB will reset the RDE_DRB_FLG and RDE_DRB_NUM_DAYS parameters so that jobs executed outside the nightly batch are not affected by any of the functionality described above.

If MFCS is multiple days ahead of the AIF data warehouse, then it may be necessary to run multiple AIF batch cycles within the same calendar day. Each time it runs, the data recovery batch logic should advance the business date by 1 to extract each missing day of data until the system is caught up to MFCS. MFCS is allowed to skip or disable batch dependencies on AIF DATA for the duration of the recovery period to avoid causing any operational issues within the business. Review the following scenarios for additional details.

Synchronization Status	Expected Behavior	Additional Actions Required
MFCS is on VDATE and RDE is on VDATE-1 at start of batch	Normal nightly batch execution will occur to extract data for VDATE to the data warehouse.	None
MFCS is on VDATE and RDE is on VDATE (or later) at start of batch	`RDE_BUSINESS_DATE_VAL_JOB` will fail because RDE has already extracted the current date from MFCS.	Determine the root cause of the date misalignment and take corrective action if needed. If MFCS data replication is lagged, wait until the lag has resolved before resuming batch. If either MFCS or the AIF data warehouse is not supposed to be on the specified VDATE, adjust them as needed to align the dates.
MFCS is on VDATE and RDE is on VDATE-2 at start of batch	`RDE_SETUP_DRB_RUN_JOB` will enable the `RDE_DRB_FLG` and a data recovery batch will run using `RDE_LAST_VDATE_RUN`+1 as the current business date.	Restart and run the AIF DATA batch from the beginning (if it was in progress and stopped midway) so the recovery batch run is triggered. Disable intraday loads until the batch is caught up. If the RDE extraction is only running behind MFCS by less than a day, no further actions needed. Ensure that, from the next batch onwards, the AIF DATA schedule starts in parallel with MFCS to avoid triggering another data recovery batch run.
MFCS is on VDATE and RDE is on VDATE-3 (or earlier) at start of batch	`RDE_SETUP_DRB_RUN_JOB` will enable the `RDE_DRB_FLG` and a data recovery batch will run using `RDE_LAST_VDATE_RUN` + 1 as the current business date.	Restart and run the AIF DATA batch from the beginning (if it was in progress and stopped midway) so the recovery batch run is triggered. Disable intraday loads until batch is caught up. When MFCS is multiple days ahead of the data warehouse, it will be necessary to manually trigger multiple sequential batch runs of AIF DATA (and all downstream application schedules) until the dates are back in alignment. If POM is configured to only allow one batch run per day, that setting should be disabled until batches are caught up.
MFCS is on VDATE and RDE is on VDATE-15 at start of batch	RDE_SETUP_DRB_RUN_JOB will detect that the dates are too far apart to attempt a data recovery batch and will allow normal execution to continue.	Although the data recovery batch will not be triggered, other date-based validations will fail when the dates are this far apart. You will need to align the business dates between MFCS and the AIF data warehouse when these failures occur, and only after that can you resume the batch. The data warehouse must be 1 day prior to the current MFCS VDATE at the start of batch.

Outside of the nightly batch, there are also standalone processes available to perform some of these operations. The RDE_SETUP_DRB_RUN_ADHOC process can be used to update the RDE_DRB_FLG and RDE_DRB_NUM_DAYS parameters relative to the current state of MFCS and AIF data. The RDE_BATCHFINAL_RESET_DRB_SETUP_ADHOC process can be used to reset those parameters back to default values. The RDE_CHECK_GGH_STATUS_ADHOC process can be used to verify the data replication status from MFCS to AIF if you believe data issues are a result of failed/disabled Golden Gate replication.

Batch Schedule Definitions

The RDE jobs have been labeled and categorized by their primary purpose, so you can easily identify jobs you may want to enable or disable for your implementation. The bulk of the RDE jobs are divided into two main classifications, which are dimension jobs (those with RDE_EXTRACT_DIM_* in their job names) and fact jobs (those with RDE_EXTRACT_FACT_* in their job names). They are also grouped into execution phases based on their functional usage, as described in the tables below. The phases are all run in parallel to each other and don’t have dependencies between them, they are purely for ease of use.

Table 4-1 RDE Dimension Phases

DIMENSION PHASE No.	GROUPING FACTOR
P1	Consists of dimension jobs that populate the `GRP1`, `GRP2`, and `GRP3` staging tables
P2	Consists of the Security jobs (RAF table entries)
P3	Consists of dimension jobs related to the item (for example, Merch hierarchy, item charges, item season, `RDW_DELETE*`)
P4	Consists of dimension jobs related to Custom Flex Attributes (CFA)
P5	Consists of dimension jobs related to Replenishment
P6	Consists of dimension jobs related to Merch Organization Hierarchy (for example, location list, location traits, organization financial information, and so on)
P7	Consists of dimension jobs related to Transfers (for example, transfer details, transfer charges, and so on)
P8	Consists of dimension jobs related to extract of codes used by Merchandising (for example, Inventory Adjustment reasons, Inventory status types, codes, and so on)
P9	Consists of dimension jobs related to the supplier (for example, supplier traits, supplier information, and so on)
P10	Consists of dimension jobs related to Purchase Orders (for example, PO Details, Shipment Details, ELC, and so on)
P11	Consists of dimension jobs related to allocation (for example, Allocation detail, allocation charges, and so on)
P12	Consists of dimension jobs related to Merchandising Calendar information
P13	Consists of dimension jobs related to Merchandising promotions
P14	Consists of dimension jobs related to employee information
P15	Consists of dimension jobs related to competitor information
P16	Consists of dimension jobs related to Merchandising Parameter tables (`*_GS`).
P17	Consists of dimension jobs related to buyer information
P18	Consists of Merchandising Lookup Dimension information.
P19	Consists of Company Closure Dimension information.
P20	Consists of Deal Dimension information.
P21	Consists of Stock Count Dimension information.

Table 4-2 RDE Fact Phases

FACT PHASE No.	GROUPING FACTOR
P1	Consists of cost fact information jobs (for example, Base Cost, net Cost, and so on)
P2	Consists of price fact information jobs (for example, item price, competitor price, and so on)
P3	Consists of purchase order fact jobs
P4	Consists of transfer / RTV fact jobs
P5	Consists of Supplier fact jobs
P6	Consists of Stock Ledger fact jobs
P7	Consists of fact jobs related to inventory (for example, unavailable inventory, inventory receipt, and so on)
P8	Consists of fact jobs related to transactions - they mostly read from `IF_TRAN_DATA` (for example, deal income, intercompany margin, and so on)
P9	Consists of Allocation fact jobs
P10	Consists of stock count fact jobs
P11	Consists of replenishment fact jobs
P12	Consists of deal actuals fact jobs

Ad Hoc Processes

There are several standalone ad hoc processes available for executing the RDE programs outside of a normal batch cycle. These processes can be used to integrate dimension or fact data to RAP during initial implementation, or simply to run the extracts and validate the outputs without actually loading them into the platform. The table below summarizes these processes and their usage.

Table 4-3 RDE Ad Hoc Processes

Process Name	Usage
RDE_ALLOCDETAILDYSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the allocation dimension (`W_RTL_ALC_DETAILS_DS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_CE_DIM_FLOW_ADHOC	Execute the dimension data extracts from CE and write the result to RAP input staging tables directly. Data can then be moved into RAP if desired by using the `RI_DIM_INITIAL_ADHOC` process.
RDE_DEALINILDSDE_INITIAL_ADHOC	Extract deal income transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_DEAL_INCOME_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_DIM_FLOW_ADHOC	Execute the dimension data extracts from RMFCS and write the result to RAP input staging tables directly. Data can then be moved into RAP if desired by using the `RI_DIM_INITIAL_ADHOC` process.
RDE_EXTRACT_SALES_ADHOC	Extract daily sales data from the Sales Audit staging tables to the RAP staging tables. This process is mainly intended to test the sales extracts outside the normal batch and to validate the data transformations, or use the RAP sales history load ad hoc processes to bring the sales into the platform.
RDE_FACT_FLOW_ADHOC	Execute the fact data extracts from RMFCS and write the result to RAP input staging tables directly. This is mainly intended to allow a complete run of RDE fact jobs outside the normal batch process, loading the data into RI would require the use of numerous fact jobs and processes depending on the data needed. This process may run as full or incremental loads depending on the POM system options used for ODI runs.
RDE_INTCMPMRGINSDE_HIST_ADHOC	Extract intercompany margin transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_ICMARGIN_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_INVPOS_SEED_ADHOC	Run the inventory position fact seed job needed to create full snapshots of inventory data in RI. After running these jobs, you may use the `SEED_W_RTL_INV_IT_LC_DY_F_PROCESS_ADHOC` process to load it (you must disable the COPY/STG steps of the seed processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_INVRECLASSSDE_HIST_ADHOC	Extract inventory reclass transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_INVRECLASS_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_INVRTVFACT_INITIAL_ADHOC	Extract RTV transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_INVRTV_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_IVADJILDSDE_INITIAL_ADHOC	Extract adjustment transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_ADJUSTMENTS_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_IVRCEXPILDSDE_INITIAL_ADHOC	Extract receipt expenses transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_INVRC_EXP_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_IVRCPILDSDE_INITIAL_ADHOC	Extract receipts transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_INVRECEIPTS_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_IVTSFILDSDE_INITIAL_ADHOC	Extract transfer transaction history from RMFCS to RAP staging tables. Load the data into RAP using the `HIST_CSV_TRANSFER_LOAD_ADHOC` process (you must disable the COPY/STG steps of the processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_POONALCILDSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the PO orders on allocation fact (`W_RTL_PO_ONALC_IT_LC_DY_FS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_POSITIONALFACT_SEED_ADHOC	Run all of the positional fact seed jobs needed to create full snapshots of positional data in RAP. After running these jobs, you may use the `SEED_*_ADHOC` processes to load each dataset (you must disable the COPY/STG steps of the seed processes before running them, because those steps will attempt to load from flat files instead of RMFCS).
RDE_REPLDAYSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the Replenishment Days dimension (`W_RTL_REPL_DAY_DS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_REPLDEMANDILSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the Replenishment Additional Demand fact (`W_RTL_REPL_DMD_IT_LC_DY_FS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_REPLSTOREORDILSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the Replenishment Store Orders fact (`W_RTL_REPL_ORD_IT_LC_DY_FS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_REPLSUPDIMSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the Replenishment Supplier Dims dimension (`W_RTL_REPL_SUP_SIM_DS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_REPLWFORDILDSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the Replenishment Wholesale/Franchise Orders fact (`W_RTL_REPL_WF_ORD_IT_LC_DY_FS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_SHIPDETAILSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the shipment details dimension (`W_RTL_SHIP_DETAILS_DS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_SHIPILDSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the shipment details fact (`W_RTL_SHIP_IT_LC_DY_FS`). Intended for data validation and history conversion. Meant to be loaded into RAP data warehouse using the nightly batch jobs.
RDE_TSFILDSDE_INITIAL_ADHOC	Extracts a full snapshot of data from RMFCS for the transfer details fact (`W_RTL_TSF_IT_LC_DY_FS`). Intended for data validation and history conversion. Meant to be loaded into the RAP data warehouse using the nightly batch jobs.

Batch Grants and Synonym Setup (Gen 2 Architecture)

Retail Data Extractor (RDE) programs require various database grants and synonyms in order to function on the Golden Gate replicated objects and move that data into RAP for further processing. Additional grants and synonyms are also used to expose data to Innovation Workbench (IW) for implementers to directly query. These configurations are applied during the provisioning and application patching; however, in rare instances, it is possible for a grant or synonym to become invalidated outside of those times. Symptoms of this issue are:

RDE batch programs fail with an error like ORA-00942: table or view does not exist, and the program was previously working without error
A SQL query from APEX returns an error like ORA-00942: table or view does not exist, and you are sure the object in question should be available to query

If you ever need to re-apply these grants and synonyms, ad hoc programs are available in POM for this purpose. The way to use these processes is to run the GRANT process of a particular type first, followed by the SYNONYM process of the same type.

Table 4-4 RDE Synonym and Grant Processes

Process Name	Usage
RDE_GRANT_MFCS_TO_BATCH_ADHOC	Ad hoc process that grants the MFCS Replicating Views to batch user (`RABE01USER`).
RDE_GRANT_MFCS_TO_APEX_ADHOC	Ad hoc process that grants the MFCS Replicating Views to Retail Workspace (IW).
RDE_CREATE_SYNONYM_FOR_MFCS_ADHOC	Ad hoc process that creates synonyms for the MFCS Replicating Views to batch user (`RABE01USER`).
RDE_CREATE_SYNONYM_FOR_MFCS_APEX_ADHOC	Ad hoc process that creates synonyms for the MFCS Replicating Views to Retail Workspace (IW).
RDE_GRANT_ORCE_TO_BATCH_ADHOC	Ad hoc process that grants the ORCE Replicating Views to batch user (`RABE01USER`).
RDE_GRANT_ORCE_TO_APEX_ADHOC	Ad hoc process that grants the ORCE Replicating Views to Retail Workspace (IW).
RDE_CREATE_SYNONYM_FOR_ORCE_ADHOC	Ad hoc process that creates synonyms for the ORCE Replicating Views to batch user (`RABE01USER`).
RDE_CREATE_SYNONYM_FOR_ORCE_APEX_ADHOC	Ad hoc process that creates synonyms for the ORCE Replicating Views to Retail Workspace (IW).
RDE_GRANT_BATCH_TO_APEX_ADHOC	Ad hoc process that grants batch-owned RDE temporary tables and views to Retail Workspace (IW).
RDE_CREATE_SYNONYM_FOR_BATCH_APEX_ADHOC	Ad hoc process that creates synonyms for the batch-owned RDE temporary tables and views to Retail Workspace (IW).

Batch Dependency Setup (Gen 2 Architecture)

RDE jobs have pre-defined dependencies with RI, as well as interschedule dependencies with RMFCS. When you enable the RDE jobs, the dependencies with RI/AIF will be enabled automatically, but you will need to manually enable/disable the RMFCS interschedule dependencies based on your needs.

You should start with all dependencies enabled, and only disable them if you are trying to run the batch cycle out of sync from the RMFCS batch. The inter-schedule dependencies fall into two categories: discreet jobs that perform some check on RMFCS data, and POM dependencies that cross-reference another RMFCS batch program. The first category of jobs check the availability of data from the RMFCS signaling table called RMS_RDE_BATCH_STATUS. The RDE jobs that check the signaling table in RMFCS are:

RDE_INTERSCHED_CHECK_RESAEXTRACT_PROCESS / RDE_INTERSCHED_CHECK_RESAEXTRACT_JOB - Checks the completion of the RESA_EXTRACT job in RMFCS
RDE_INTERSCHED_CHECK_INVSNAPSHOT_PROCESS / RDE_INTERSCHED_CHECK_INVSNAPSHOT_JOB - Checks the completion of the INVENTORY_SNAPSHOT job that signifies that the ITEM_LOC_SOH_EOD table in RMFCS is now available for the RDE extract
RDE_INTERSCHED_CHECK_STAGETRANDATA_PROCESS / RDE_INTERSCHED_CHECK_STAGETRANDATA_JOB - Checks the completion of the STAGE_TRAN_DATA job that signifies whether the IF_TRAN_DATA table in RMFCS is now available for the RDE extract

If the RDE jobs run in parallel with the RMFCS batch, then all these jobs must be enabled. If you are running RDE jobs outside the RMFCS batch, then these jobs must be disabled during those runs. The jobs will wait indefinitely for a signal from the RMFCS batch, which they will never receive if you are running RDE jobs independently.

The second category of dependencies are found on the RDE jobs themselves when you click on a job to view its details in POM or click the Interschedule Dependencies link in Batch Monitoring UI. These jobs are listed below, along with the RMFCS jobs they depend on. You must verify these are enabled before trying to run RDE batches (unless the associated RMFCS job is disabled, in which case the RDE dependency can be turned off as well). If any of these are disabled, you will need to use Batch Administration to enable them by locating each job and clicking into the details to enable all dependencies for it.

RDE_SETUP_INCRMNTL_DEALACT_PROCESS / RDE_SETUP_INCRMNTL_DEALACT_JOB – This RDE job waits for the following MFCS jobs to complete:
- RPM_PRICE_EVENT_EXECUTION_PROCESS / RPM_PRICE_EVENT_EXECUTION_JOB
RDE_EXTRACT_DIM_P5_REPLDAYSDE_PROCESS / RDE_EXTRACT_DIM_P5_REPLDAYSDE_JOB – This RDE job waits for the following MFCS jobs to complete:
- REPLENISHMENT_PROCESS / RPLEXT_JOB
RDE_EXTRACT_DIM_P3_PRDITMATTRSDE_PROCESS / RDE_EXTRACT_DIM_P3_PRDITMATTRSDE_JOB – This RDE job waits for the following MFCS jobs to complete:
- REPLENISHMENT_PROCESS / RPLEXT_JOB
RDE_EXTRACT_DIM_P21_STKCNTSDE_PROCESS/RDE_EXTRACT_DIM_P21_STKCNTSDE_JOB and RDE_EXTRACT_FACT_P10_STKCNTILSDE_PROCESS/RDE_EXTRACT_FACT_P10_STKCNTILSDE_JOB – These RDE jobs wait for the following MFCS jobs to complete:
- STKVAR_PROCESS/STKVAR_POST_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB – This RDE job waits for the following MFCS jobs to complete:
- ALLOCBT_PROCESS / ALLOCBT_JOB
- BATCH_RFMCURRCONV_PROCESS / BATCH_RFMCURRCONV_JOB
- COSTCOMPUPD_ELCEXPRG_PROCESS / ELCEXCPRG_JOB
- EDIDLCON_PROCESS / EDIDLCON_JOB
- EXPORT_STG_PURGE_PROCESS / EXPORT_STG_PURGE_JOB
- EDIUPAVL_PROCESS / EDIUPAVL_JOB
- LIKESTOREBATCH_PROCESS / LIKESTOREBATCH_JOB
- POSCDNLD_PROCESS / POSCDNLD_POST_JOB
- REPLINDBATCH_PROCESS / REPLINDBATCH_JOB
- SALESPROCESS_PROCESS / SALESUPLOADARCH_JOB
- STKVAR_PROCESS / STKVAR_JOB
RDEBATCH_INITIAL_START_PROCESS / RDEBATCH_INITIAL_START_MILEMARKER_JOB – This RDE job waits for the RMFCS job STOP_RIB_ADAPTOR_INV_PROCESS / STOP_RIB_ADAPTOR_INV_JOB to complete.

If you cannot see any dependencies in the POM UI, then your POM system options may have them disabled. Make sure to check the System Configuration for AIF DATA and ensure the dependency options are set to Enabled.

Batch Link Setup (Gen 2 Architecture)

Aside from the dependencies, you also need to be aware of the Schedule Link that is defined between MERCH and AIF DATA schedules. By default, the schedule link will be disabled, so you must go into the AIF DATA schedule links section from Batch Monitoring and enable any links shown. The schedule link will allow RDE and RI jobs to start automatically after Merchandising jobs are run in their nightly batch cycle. There is one schedule link defined that will trigger the RDE job RDEBATCH_INITIAL_START_MILEMARKER_JOB after Merchandising runs. If the MERCH and AIF DATA schedules are in the same POM instance, then you must enable the Schedule Link before running any batches. If they are in different instances, then the link will not be visible and cannot be used. The schedule link also cannot be used if you choose to start the AIF DATA batch at a fixed time every day using the Scheduler Configuration in POM. The schedule links and time-based schedules are mutually exclusive, only one option can be used to start a nightly batch cycle.

Module Setup in Retail Home (Gen 2 Architecture)

Before you configure any individual jobs in POM itself, it is best to set up your Customer Modules in Retail Home to reflect your planned data flows. Go to the Customer Modules Management screen as an administrator user and review the options following this guidance:

Under the RAP > RAP_COMMON section:
- Enable or disable the BATCH modules per your functional needs (enable everything if unsure).
- Disable the HISTORY module if you are planning to immediately start loading Merchandising data. Enable it if you will load history data using CSV file interfaces.
- Enable or disable the AIF modules based on your AI Foundation solution plans. Ensure AIF > CONTROLFILES is disabled as RDE jobs supercede this functionality.
- Enable the RDE_CE and RDE_RMS modules fully, depending on which source applications are available in your environments.
- Disable RDXBATCH if you are not using any Planning solution in RAP or enable it if you do plan to use MFP, AP, or IPO.
- Disable SIBATCH and SICONTROLFILES module sets, because they are superceded by RDE integration.
- Disable the ZIP_FILES modules unless you have a need for one of them for non-Mechandising data.
(For RI customers) Under the RI > RCI section, enable or disable the module depending on your plans to use Retail Insights customer-related functionality. Disable the RI > RCI > CONTROLFILES and SICONTROLFILES modules, because RDE jobs replace this functionality. The BATCH modules can be left enabled if you are unsure whether these modules are needed.
(For RI customers) Under the RI > RMI section, enable or disable the module depending on your plans to use Retail Insights merchandising-related functionality. Disable the RI > RMI > CONTROLFILES and SICONTROLFILES modules, because RDE jobs replace this functionality. The BATCH modules can be left enabled if you are unsure whether these modules are needed.

Once all modules are configured, go back into the POM Batch Administration UI and perform a Sync with MDF action on the AIF DATA schedule. This is a one-time activity to streamline the POM schedule setup, after which you will want to perform a review of the POM schedule and refine the enabled/disabled jobs further to cover any specific file or data requirements.

Even if you are not syncing with MDF at this time, you must still perform the Retail Home setup because the CONTROLFILES and SICONTROLFILES modules are used implicitly by AIF DATA schedule programs to know which data files to expect in the batch runs. Any misconfiguration could lead to the program DAT_FILE_VALIDATE_JOB failing or running for several hours while waiting for data files you didn’t provide. Similarly, if you misconfigure the ZIP_FILES modules, then you will encounter errors/delays in the ZIP_FILE_WAIT_JOB as it looks for the expected ZIP files.

Batch Job Setup (Gen 2 Architecture)

The way you configure the integration with RMFCS varies depending on where your Merchandising applications reside. In this scenario, you have both RMFCS and CE in our 2^nd generation architecture and the version number is 22.1 or greater.

If you followed the Retail Home setup steps prior to this section, then most of the jobs listed below should already be configured to your specifications. However, it is still good to validate the necessary jobs are enabled/disabled per the requirements before attempting any batch run. Take the following steps to review/configure the RDE portion of the AIF DATA batch schedule:

Enable the jobs RDE_SETUP_INCRMNTL_RESA_JOB, RDE_SETUP_INCRMNTL_DEALACT_JOB, RDE_SETUP_INCRMNTL_JOB, and RDE_INCRMNTL_AUDIT_PRG_JOB which are mandatory for sales integration with Sales Audit and Deals integration with MFCS.
Enable the jobs ETLREFRESHGENSDE_JOB and ETL_REFRESH_RI_JOB, which are both responsible for cleanup of data in the C_LOAD_DATES batch orchestration table. ETLREFRESHGENSDE_JOB manages the RDE portion of data in this table, while ETL_REFRESH_RI_JOB manages the rest. The batch will not execute properly if either of these jobs are disabled.
Disable the batch schedule link between BATCH_INITIAL_START_PROCESS / GENERIC_BATCH_MILE_MARKER_JOB and RDE schedule’s RDE_BATCHFINAL_PROCESS / RDE_BATCHFINAL_EXTLOAD_SUCCESS_JOB (if one is visible). This batch link should be disabled now because RDE is a part of AIF DATA’s schedule and is on the same POM and batch pod, which was not true in prior architectures.
If the client opts not to integrate the ORCE customer data, the ORCE jobs can be disabled (those with RDE_EXTRACT_CE_*). These jobs are under the following modules:
- RDE_CE
- RDE_CE_BATCH
- RDE_CE_REQUIRED
- RDE_CE_OPTIONAL
- RDE_CE_CUSTOMER
- RDE_CE_CUSTSEG
- RDE_CE_LOYALTY
If the client opts to integrate the ORCE customer data (which means that the ORCE jobs are enabled - those with RDE_EXTRACT_CE_*), the following AIF DATA jobs should be disabled as the customer data will directly be populated without an input file:
- W_RTL_CUST_DEDUP_DS_COPY_JOB
- W_RTL_CUST_DEDUP_DS_STG_JOB
- W_RTL_CUST_LYL_AWD_TRX_DY_FS_COPY_JOB
- W_RTL_CUST_LYL_AWD_TRX_DY_FS_STG_JOB
- W_RTL_CUST_LYL_TRX_LC_DY_FS_STG_JOB
- W_RTL_CUST_LYL_TRX_LC_DY_FS_COPY_JOB
- W_RTL_CUST_LYL_ACCT_DS_COPY_JOB
- W_RTL_CUST_LYL_PROG_DS_COPY_JOB
- W_RTL_CUSTSEG_DS_COPY_JOB
- W_RTL_CUSTSEG_DS_STG_JOB
- W_RTL_CUSTSEG_DS_ORASE_JOB
- W_RTL_CUST_CUSTSEG_DS_COPY_JOB
- W_RTL_CUST_CUSTSEG_DS_STG_JOB
- W_RTL_CUST_CUSTSEG_DS_ORASE_JOB
- W_RTL_CUSTSEG_ATTR_DS_COPY_JOB
- W_RTL_CUSTSEG_ATTR_DS_STG_JOB
- W_RTL_CUST_HOUSEHOLD_DS_COPY_JOB
- W_RTL_CUST_HOUSEHOLD_DS_STG_JOB
- W_RTL_CUST_ADDRESS_DS_COPY_JOB
- W_RTL_CUST_ADDRESS_DS_STG_JOB
- W_PARTY_PER_DS_COPY_JOB
- W_PARTY_PER_DS_STG_JOB
- W_RTL_PARTY_PER_ATTR_DS_COPY_JOB
- W_RTL_PARTY_PER_ATTR_DS_STG_JOB
- W_HOUSEHOLD_DS_COPY_JOB
- W_HOUSEHOLD_DS_STG_JOB
Disable most of the AIF DATA copy jobs (those with *_COPY_JOB) except ones needed for non-RMFCS sources. These jobs should be disabled because these jobs will copy files and upload them from object storage. This is not needed because data is loaded directly into the staging tables and flat files are not expected to arrive for processing. Most of these jobs are under the following modules:
- RI_DAT_STAGE
- RSP_DAT_STAGE
Disable most of the AIF DATA stage jobs (those with *_STG_JOB) ) except ones needed for non-RMFCS sources. These jobs should be disabled as these jobs read from a flat file which are not available if using this integration. Most of these jobs are under the following modules:
- RI_DAT_STAGE
- RSP_DAT_STAGE
Disable the RAP Simplified Interface jobs (those with SI_*, COPY_SI_*, and STG_SI_* at the start of the name) as RMFCS will be the source of data to feed RI. Most of these jobs are under the modules with the patterns below:
- RI_SI*
- RSP_SI*
Disable the AIF DATA program W_PROD_CAT_DH_CLOSE_JOB, which is used to close unused hierarchy levels when non-Merchandising incremental hierarchy loads are used in RAP. It must not run with Merchandising, because the product hierarchy data is already being managed by RDE extracts.
Disable the AIF DATA program BATCH_START_NOTIFICATION_JOB (specifically the version belonging to process SIL_INITIAL_PROCESS) because this is redundant with jobs included in the RDE portion of the schedule.
If you are not providing any flat file uploads and using only RMFCS data, you may disable the jobs in CONTROL_FILE_VALIDATION_PROCESS, which will prevent any data files from being processed (and potentially overwriting the RMFCS data).
Disable the job named TRUNCATE_STAGE_TABLES_JOB, which is used only for data file loads and cannot be run when RDE jobs are used for direct integration. A similar job named RDE_TRUNCATE_STAGE_TABLES_JOB should remain enabled as this does apply to RDE job execution.

Batch Job Setup (Gen 1 Architecture)

If your RMFCS version is in the Oracle cloud but the version number is 19.3 or earlier, then follow this process to configure the integration. In this case, RDE is a separate module installed in the RMFCS cloud, so the batch must be reconfigured accordingly to have the correct dependencies.

Disable all the inter-schedule dependencies related to RDE in the RI schedule, as there is a separate batch schedule used for RDE that contains these:

CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS ALLOCBT_PROCESS / ALLOCBT_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS BATCH_RFMCURRCONV_PROCESS / BATCH_RFMCURRCONV_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS COSTCOMPUPD_ELCEXPRG_PROCESS / ELCEXCPRG_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS EDIDLCON_PROCESS / EDIDLCON_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS EXPORT_STG_PURGE_PROCESS / EXPORT_STG_PURGE_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS EDIUPAVL_PROCESS / EDIUPAVL_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS LIKESTOREBATCH_PROCESS / LIKESTOREBATCH_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS POSCDNLD_PROCESS / POSCDNLD_POST_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS REPLINDBATCH_PROCESS / REPLINDBATCH_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS SALESPROCESS_PROCESS / SALESUPLOADARCH_JOB
CSTISLDSDE_PROCESS / CSTISLDSDE_JOB dependency with RMFCS STKVAR_PROCESS / STKVAR_JOB
RDEBATCH_INITIAL_START_PROCESS / RDEBATCH_INITIAL_START_MILEMARKER_JOB dependency with RMFCS STOP_RIB_ADAPTOR_INV_PROCESS / STOP_RIB_ADAPTOR_INV_JOB

Disable the batch link related to RMFCS in the RI schedule:
1. SETUP_PROCESS / REFRESHODIVARIABLES_JOB dependency with RMFCS STOP_RIB_ADAPTOR_INV_PROCESS / STOP_RIB_ADAPTOR_INV_JOB
Disable all the ORCE jobs in AIF DATA (those with RDE_EXTRACT_CE*). These jobs should not be executed because RDE is not in Gen 2 Architecture. The Customer Data jobs in RI should be enabled instead (for example, W_RTL_CUSTSEG_DS_COPY_JOB, W_RTL_CUSTSEG_DS_STG_JOB)
Disable all the RDE jobs in AIF DATA (those with RDE_EXTRACT_*). These jobs should not be executed as a separate RDE job schedule in POM will be setup for it. These jobs are under the RDE_RMS_* modules.
Make sure that the AIF DATA copy jobs (those with *_COPY_JOB) are enabled. These jobs should be enabled as these jobs will copy files and upload them to the object storage which is the source of the files for RI processing.
Make sure that the AIF DATA stage jobs (those with *_STG_JOB) are enabled. These jobs should be enabled as these jobs will read from flat files and load them into the RI staging tables.
Disable the AIF DATA Simplified Interface jobs (those with SI_*) as MFCS will be the source of data to feed RI. Most of these jobs are under the following modules with the pattern below:
1. RI_SI*
2. RSP_SI*

Batch Setup for RMS On-Premise

If your RMS application is installed on a local server outside the Oracle cloud, then you will need to integrate your local RDE installation with the RAP cloud following the guidance below. Additionally, you should also perform all the steps in the prior section to disable the RDE components of the RI POM schedule and enable the file load procedures, since you will be sending in files from RDE.

Download the latest RDE version 22 patch from My Oracle Support, as the changes to support Object Storage upload are deployed by running the installer and upgrading your RDE environment.
Disable FTP Configuration in RDE by setting the input.do.install.ftp to false in the ant.install.properties file. This must be disabled because File Transfer Services (FTS) for the Retail Analytics and Planning cloud services are made available in this release, replacing the current SFTP process
Check that the FTS configuration file ra_objstore.cfg is available in RDE's $MMHOME/etc directory. The FTS configuration file contains the following variable set-up used for the Object Storage:
- RA_FTS_OBJSTORE_IND – This will be set to Y so that FTS will be enabled
- RA_FTS_OBJSTORE_URL – This is the Base URL
- RA_FTS_OBJSTORE_ENVNAMESPACE – This is the Tenant
- RA_FTS_OBJSTORE_IDCS_URL – This is the IDCS URL appended with /oauth2/v1/token at the end
- RA_FTS_OBJSTORE_IDCS_CLIENTID – This is the Client ID
- RA_FTS_OBJSTORE_IDCS_CLIENTSECRET – This is the Client ID Secret
- RA_FTS_OBJSTORE_IDCS_SCOPE – This is the IDCS Scope
- RI_OBJSTORE_UPLOAD_PREFIX – This is the Storage Prefix and is set to ris/incomingpointing to the correct Object Storage directory for RI input files
Refer to the File Transfer Services section of this document for instructions on how to get the values for each of the variables above.
Enable the File Transfer Service (FTS) in RDE by setting the RA_FTS_OBJSTORE_IND to Y in the FTS Configuration file ra_objstore.cfg found in RDE’s $MMHOME/etc directory. This must be enabled so that the RDE nightly zip file job (RTLRDEZIP_PROCESS / RTLRDEZIP_JOB) and all existing ad hoc zip file jobs (RTLUASDE_INITIAL_DIMMENSION_LOAD_ADHOC / RTLRDEZIP_HIST_JOB, RTLRDEZIP_HIST_PROCESS_ADHOC / RTLRDEZIP_HIST_JOB, INVRTVFACT_ADHOC / ADHOCINVRTVSDE_JOB, SEEDPOSITIONALFACT_ADHOC / SEEDRDEZIP_JOB) will automatically upload files to the Object Storage through FTS for RI to pick up and download for further processing.
Once these changes are applied, it will no longer be possible to upload to SFTP; you will be sending the ZIP files only to Object Storage as specified in the install properties and configuration changes.

RDE Job Configuration

RDE programs have many configuration options available in the C_ODI_PARAM_VW table in the Control & Tactical Center. These must be reviewed prior to running RDE jobs. For any RDE job having an incremental flag below, the associated jobs in the RI/AIF DATA batch schedule also have incremental flags that must be updated at the same time. Having the RDE and AIF DATA flags be out of sync can result in data loss.

In addition to these parameters, it is also important to understand the MFCS settings relating to data purging and configure them accordingly before using RDE to extract data. Because RDE runs only at the end of the day after MFCS has started a nightly cycle, it is critical that no table in MFCS is set to purge data immediately (purge days <= 1). It is best if all purge-related MFCS settings are extended far enough so that, even if an RDE batch is missed for a day or two, there will not be any data lost due to MFCS nightly purge programs.

One MFCS setting in particular, EDI_REV_DAYS, must be updated to be high enough so that there is no chance of purging old order revisions while they might still receive updates that RDE needs to extract. We recommend changing this value to be at least 30 days (or longer, if you have any processes that might update an order 30+ days after initially closing it). The associated purchase order purge setting, ORDER_HISTORY_MONTHS, must also be more than a month out.

Scenario	Parameter	Usage
GLOBAL	RPM_PROMO_EVENT_LEVEL	Enable (set to `Y`) if using legacy RPM on-premise functionality.
GLOBAL	CE_PROMO_BRAND_TARGET	Determines whether promotion details from Customer Engagement (CE) will use the `BRAND` or `SUPPLIER_SITE` field. Promotions from CE have an optional brand identifier but it may contain either a brand ID or a supplier ID, so you will need to configure which of these two columns in `W_RTL_PROMO_CE_IT_LC_DS` will be used. Default = BRAND
GLOBAL	CUST_DEDUP_TYPE_CODE	Determines which customer type in Customer Engagement will be used to import deduplicated customer IDs for the purpose of updating the `W_PARTY_PER_D` table. Default = PREVIOUS_RELATE_ID
GLOBAL	RETURN_REASON_CAT_CODE	Merchandising code type for customer return reason codes.
GLOBAL	RTVR_REASON_CAT_CODE	Merchandising code type for RTV reason codes.
GLOBAL	WHOLESALE_CHANNEL	Identify whether there is a wholesale channel setup in Merchandising.
GLOBAL	ITEM_GRP1_IS_INCREMENTAL	Controls whether item attributes are incremental or full snapshots on the daily load.
GLOBAL	RMS_VERS_CHECK	Controls the behavior of code that is linked to a specific Merchandising version.
GLOBAL	RA_INV_WAC_IND	Controls the inventory cost calculation in RDE. When set to `Y` it will use Weighted Average Cost (WAC) as the item cost for all items. When set to `N` it will dynamically load Merchandising valuation methods set per department or item and apply them, choosing from average cost, unit cost, and retail-based cost.
GLOBAL	RA_INV_TAX_IND	Controls the calculation and removal of tax amounts from retail valuation of stock on hand and on-order amounts. When set to `N`, only simple VAT (SVAT) calculations are supported and non-VAT items are left as-is. When set to `Y`, the system dynamically loads Merchandising global tax and VAT information and applies it by item/location.
GLOBAL	RA_SLS_TAX_IND	Controls whether the sales will extract retail and discount amount exclusive of VAT. If value is `Y` then the retail and discount amounts in the sales extract will be VAT-exclusive. If value is `N`, then the retail and discount amounts in the sales extract will be VAT-inclusive. Value defaults to `N` as that was the default program behavior in earlier versions, before this configuration was added.
GLOBAL	RDE_INCRMNTL_AU_PRG_DAYS	This parameter is used to determine the retention period of the `C_RDE_INCRMNTL_TBL_CTRL_AU` integration audit table, set as a number in days.
GLOBAL	PO_EXCHANGE_DT_TYPE	Controls the date used to convert currency amounts on purchase orders extracted from Merchandising Foundation Cloud Service. By default, the system will convert currency amounts using the current business date (`C`), which means a change to exchange rates will also change the converted cost and retail amounts on the order. Update this parameter to a value of `A` to use the PO Approval Date, which does not change each time the order data is extracted, resulting in fixed cost/retail rates over time.
GLOBAL	PO_PACK_LEVEL_IND	When set to `Y`, extracts purchase orders from MFCS at pack item level. When set to `N`, pack items are converted to their components. Default value is `N`, meaning that all PO data is extracted at component item level and packs are split into their components. This setting may be needed for Inventory Planning & Optimization (IPO) projects where pack items will be allocated or transferred at pack level.
SDE_RETAILINVRECEIPTSFACT	VWH_NO_ALC_RCPTS	Specify a type of warehouse that cannot receive allocations in the feed to RI. Converts the allocations to normal transfer receipts. Uses codes from `VWH_TYPE` column in Merchandising.
SDE_RETAILINVRECEIPTSFACT	STORE_NO_ALC_RCPTS	Specify a type of store that cannot receive allocations in the feed to RI. Converts the allocations to normal transfer receipts.
SDE_RETAILITEMDIMENSION	IS_INCREMENTAL	Controls whether the product dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILITEMLOCATIONRANGEDIMENSION	IS_INCREMENTAL	Controls whether the product location range dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILITEMSUPPLIERDIMENSION	IS_INCREMENTAL	Controls whether the supplier-item dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILSUBSTITUTEITEMDIMENSION	IS_INCREMENTAL	Controls whether the substitute-item dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILITEMLOCATIONDIMENSION	IS_INCREMENTAL	Controls whether the product location attribute dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILITEMLOCCFADIMENSION	IS_INCREMENTAL	Controls whether the product location CFAS dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILSUPPCFADIMENSION	IS_INCREMENTAL	Controls whether the supplier CFAS dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILLOCATIONCFADIMENSION	IS_INCREMENTAL	Controls whether the location CFAS dimension is a full snapshot or incremental changes only for the daily load.
SDE_RETAILITEMCFADIMENSION	IS_INCREMENTAL	Controls whether the product CFAS dimension is a full snapshot or incremental changes only for the daily load.

The flags that impact the incremental/full load behavior for the AIF DATA jobs linked to RDE jobs are also provided below and should be configured at the same time.

Scenario	Parameter	Usage
SIL_ITEMDIMENSION	IS_INCREMENTAL	Controls whether the product dimension is a full snapshot or incremental changes only for the daily load.
SIL_RETAILITEMCFADIMENSION	IS_INCREMENTAL	Controls whether the product CFAS dimension is a full snapshot or incremental changes only for the daily load.
SIL_RETAILITEMLOCCFADIMENSION	IS_INCREMENTAL	Controls whether the product location CFAS dimension is a full snapshot or incremental changes only for the daily load.
SIL_RETAILLOCATIONCFADIMENSION	IS_INCREMENTAL	Controls whether the location CFAS dimension is a full snapshot or incremental changes only for the daily load.
SIL_RETAILSUPPCFADIMENSION	IS_INCREMENTAL	Controls whether the supplier CFAS dimension is a full snapshot or incremental changes only for the daily load.
SIL_RETAILSUBSTITUTEITEMDIMENSION	IS_INCREMENTAL	Controls whether the substitute item dimension is a full snapshot or incremental changes only for the daily load.
SIL_RETAILPROMOTIONDIMENSION	RI_INCREMENTAL_IND	Controls whether the promotion dimension is a full snapshot or incremental changes only for the daily load.

Using RDE for Calendar Setup (Gen 2 Architecture)

RDE can be used to integrate the calendar from Merchandising for initial setup of a new RAP environment; however there are several manual steps you must take to perform this activity. You have the option of following the steps below, or you can perform the file-based calendar load as defined in Calendar Setup. Whichever option you choose, the calendar must be set up before you can load any other data from Merchandising.

The out-of-box Merchandising calendar does not conform to the preferred RAP calendar structure. The RAP calendar must start from Day 1 of a fiscal year, and the Merchandising calendar does not (if no changes were made to it after provisioning). You must use the Calendar Maintenance functions of Merchandising to edit the business calendar, adding or deleting periods such that the first fiscal period defined is period 1 of the fiscal year, and the first date for that period is day 1 of that fiscal year. Refer to the Configure Calendar section of the Merchandising Implementation Guide for details.. For example, if your fiscal calendar starts in February 2020, then the first record in the CALENDAR table must be for this same month. YEAR_454 will be 2020 and MONTH_454 will be 2.
Configure C_ODI_PARAM for your START_DT and END_DT. START_DT must be set in one of these ways:
1. The first day of a fiscal year in the calendar (that is, the same date as the FIRST_DAY value for the first fiscal period of an FY).
2. Some date earlier than anything in the CALENDAR table. If your first CALENDAR period is February 2020, then START_DT can be set to 20190101. The only reason to do this is if you want the Gregorian calendar to have additional Gregorian years available for any downstream use.
Configure the jobs in the AIF DATA schedule for loading the data. You will need the RDE job RDE_EXTRACT_DIM_P12_MCALPERIODSDE_JOB to extract the data, which is part of the RDE_DIM_FLOW_ADHOC process. Configure the CALENDAR_LOAD_ADHOC process to load this data and perform initial environment setup activities. You must disable the following jobs:
- COPY_SI_CALENDAR_JOB
- STG_SI_CALENDAR_JOB
- SI_W_MCAL_PERIODS_DS_JOB
Run RDE_EXTRACT_DIM_P12_MCALPERIODSDE_JOB to extract the data from Merchandising and verify that the table W_MCAL_PERIOD_DS contains the full calendar information by querying it from APEX.
Run the modified CALENDAR_LOAD_ADHOC process and all later steps starting with step 4 in the Calendar Setup.
If you have any failure on the DIM_CALENDAR_VALIDATOR_JOB, it means your Merchandising calendar may need more changes to align with the RAP data requirements. Modify the data in the source and start over, being sure to use C_LOAD_DATES_CLEANUP_ADHOC to clear any failure statuses from the database before restarting.

If the validator job rule CAL_R2 continues to happen after updating the Merchandising calendar, but you know that your first calendar year is not meeting the requirements and want to bypass the error for now, then you would need to update the table C_DIM_RULE_LIST from the Control & Tactical Center. Change the error type for this rule to W so that it only throws a warning in the batch program instead of failing. For example, if your Merchandising calendar starts in 2010 and you are not going to load any data until 2020 in RAP, then having an invalid first year of the calendar is not going to block you from other data load activities.

Using RDE for Dimension Loads (Gen 2 Architecture)

RDE can be used to integrate the foundation dimensions such as Product and Location hierarchies from Merchandising for initial setup of a new RAP environment. However, there are several manual steps you must take to perform this activity.

The AIF DATA ad hoc process RDE_DIM_FLOW_ADHOC must be configured and run. Enable all jobs in the process if you want to extract all foundation dimensions, or selectively disable jobs you do not wish to run. Restart your POM schedule and then execute the process. The process will extract data from Merchandising tables (replicated to RAP through Golden Gate Hub) and directly insert data to RAP foundation staging tables. For example, the job RDE_EXTRACT_DIM_P3_PRDHIERSDE_JOB will source data from Merchandising hierarchy tables like CLASS and DEPS and directly insert them into the W_PROD_CAT_DHS table in RAP.
Some dimension extracts support full or incremental extract options as parameters instead of database configurations. The jobs that support this will have parameters on the job such as rdeitemsupcountrydimext.ksh #SysOpt.rdeMMHOME I, where the last value is either I or F for incremental/full extraction logic. You have the option to switch between I and F as needed to change the extract logic. RDE_EXTRACT_CLRPRICESDE_XTERN_JOB and RDE_EXTRACT_DIM_P5_REPLSUPDIMSDE_JOB are two examples of jobs that support this parameter.
The AIF DATA ad hoc process RI_DIM_INITIAL_ADHOC will then be used to import the foundation data from the staging tables to the target tables. Before running the process, you must make sure all jobs are disabled relating to flat file loads, because you are bypassing those steps with the RDE jobs. Disable all jobs having a name with COPY, STG, STAGING, or SI in the job name. Following the same flow for product hierarchy data as in step 1, you need to disable these jobs relating to the product hierarchy flat file load:
- COPY_SI_PRODUCT_JOB
- STG_SI_PRODUCT_JOB
- SI_W_PROD_CAT_DHS_JOB

The remaining job that is active for the product hierarchy load is W_PROD_CAT_DH_TYPE1_JOB, which loads the RDE data from W_PROD_CAT_DHS to the W_PROD_CAT_DH table.

Once you have disabled all flat file jobs, restart the POM schedule as needed and then run the RI_DIM_INITIAL_ADHOC process. This moves all Merchandising data from the RAP staging tables into the data warehouse internal tables. Once all jobs are complete, the remaining steps to move data to AIF and PDS are the same as documented in the Data Loads and Initial Batch Processing chapter.

Using RDE for Initial Seeding (Gen 2 Architecture)

RDE nightly batch programs can be used to perform initial seeding and full snapshots of positional facts without running any ad hoc processes for data loading. This provides a way to seamlessly transition from history data loads to nightly batch loads.

Prerequisites for starting this process are:

You must have already initialized the RAP calendar (either by using RDE as described in the prior sections or by loading a calendar file following the Calendar Setup process).
If you will load any historical data for prior dates, you must do that first and come back to this section when you are ready to cut over from history loads to RDE direct integration.
The current business date in the data warehouse must be one day prior to the current business date being extracted from MFCS (also known as VDATE). If this was not already updated as part of loading historical data, then you must use the ad hoc process RESET_BUSINESS_DATE_ADHOC to set it now.

Follow the steps below to perform this transition to nightly batches:

Navigate to the System Options in POM for the AIF DATA batch schedule.
Update the variables RDE_RunFactVersion and RDE_RunFactODIVersion. By default, they should have a value of I as their rightmost input parameter, which is the normal incremental batch run. Change the value to F, which will trigger a full snapshot batch run. Do not change any other values already in these options except the letter I or F at the end. The RDE_DIM_FLOW_ADHOC process also uses these parameters to extract either full or incremental datasets, if you want to use that process to extract the fact data outside of nightly batch.
If you are running the extract outside the Merchandising nightly batch, then disable or skip the interschedule validation jobs (any job starting with RDE_INTERSCHED*) as well as RDE_SETUP_INCRMNTL_CLRPRICE_JOB, RDE_SETUP_INCRMNTL_RESA_JOB, and RDE_SETUP_INCRMNTL_DEALACT_JOB in the RDE portion of the batch flow that will prevent you from running without MFCS nightly jobs. These jobs look for status updates from MFCS nightly jobs and eventually fail if no updates are found.
Schedule and run the full Merchandising and AIF nightly batch cycle and validate that all nightly data was processed as expected in your RAP solutions. If you want to validate the RDE extracts prior to running the rest of the nightly batches in RAP (for example, to confirm the full extracts worked as intended) you may place a Hold on one of the first data warehouse load jobs in the schedule, such as BATCH_START_NOTIFICATION_JOB.

There are numerous validations and checkpoints in the AIF DATA batch that aim to prevent improper use of the nightly batch cycle by failing the batch when an issue is detected. These jobs are listed below, along with reasons they might fail if this is your first time running a nightly batch cycle.

Job	Reasons for Failure
RDE_BATCHFINAL_CHKBATCHSTATUSSDE_JOB	Checks the `C_LOAD_DATES` table for any failed RDE extract jobs. This fails if there is at least one extract job that failed. The purpose is to give you a chance to correct RDE failures before you start loading the RAP data warehouse.
ZIP_FILE_WAIT_JOB	This job is normally disabled when RDE is used; but if it is enabled, it will wait for ZIP files from Object Storage and eventually fail if none are found. If you are not providing any ZIP files, disable the job.
DAT_FILE_VALIDATE_JOB	Associated with the ZIP file jobs, and validates that all required files are present and fails if not. If you are not providing any ZIP files, disable this job.
ETL_REFRESH_RI_JOB	Checks the `C_LOAD_DATES` table for any failed RI or data warehouse jobs. This job will fail if it finds any prior job execution in a Failed or InProgress state, which prevents the next batch cycle from resuming until the issue is checked. This is a safety mechanism to prevent new instances of a process from running when prior executions failed and were not addressed. If all jobs in `C_LOAD_DATES` are successful, then it truncates the table and ends this job.
FACT_POSFACT_VALIDATOR_JOB	Checks that the `DAY_DT` values on all positional fact loads (such as Inventory Position) is equal to the current business date only (positional facts do not support back-posting data) and fails if any issues are found. This usually means that the business date in RAP is not correct (at this point in batch, the RAP business date should equal the MFCS `VDATE` that was extracted by the RDE jobs in this run).
DIM_CALENDAR_VALIDATOR_JOB	Checks that the incoming calendar is properly formed with no fatal errors in the configuration of fiscal periods. For MFCS data, this can fail if the system options for the MFCS calendar are out of sync with the actual data in the `CALENDAR` table.
DIM_PROD_VALIDATOR_JOB	Checks that the incoming product hierarchy and item data is properly formed and complete. MFCS data can fail several of the validation rules; review the AIF Operations Guide for details.
DIM_ORG_VALIDATOR_JOB	Checks that the incoming location hierarchy and store/warehouse data is properly formed and complete. MFCS data can fail several of the validation rules; review the AIF Operations Guide for details.

Using RDE for Initial Seeding (Gen 1 Architecture)

RDE ad hoc batch programs in the RMFCS 19.x cloud can be used for initial seeding of RAP but the process is different from the 2^nd generation architecture, as the integration is through flat files, not direct loads. This section assumes you have already set up your RAP applications, including calendar loads, following the file-based approach documented in Setup and Configuration and Data Loads and Initial Batch Processing. Do not proceed with these steps until you have at least done the initial calendar and partition setup.

For daily batches, integration from RDE (in Merchandising) to RAP occurs automatically as part of the RDE ZIP file upload jobs. RDE will push the ZIP file to the File Transfer Services location used by AI Foundation for incoming data (ris/incoming path in FTS). At this point, you have the option to run the AI Foundation batch jobs to use that ZIP or download it from FTS to manually modify it and re-upload it. Once the AI Foundation nightly batches are enabled, you would also enable the batch link connecting AIF to RDE, and then the entire end-to-end process will occur without user intervention.

For initial seeding, you would follow the process below:

Set up a full RDE batch (by enabling batch links/dependencies to the RMFCS schedule) and let it run nightly to get the full set of RDE files for dimensions and facts.
The file will be pushed automatically to RAP FTS. Download the RI_RMS_DATA.zip file from FTS; do not load it into RAP yet.
Run the process SEEDPOSITIONALFACT_ADHOC, which will extract full snapshots of all positional data, zip them, and push them to the RAP FTS location.
Download the RIHIST_RMS_DATA.zip file from FTS and copy the full snapshots of positional facts into the RI_RMS_DATA.zip file generated by the RDE nightly process (replacing the incremental files that were extracted).
Upload the modified RDE nightly ZIP file to RAP FTS at the ris/incoming location (same as you would for all nightly batches going forward). Upload any additional ZIP files you need for the nightly batches, such as ORASE_WEEKLY.zip or RAP_DATA.zip, if you want these other files loaded in the same batch.
Advance the ETL business date in AIF to one day before the current batch, if it’s not already set to that date, using the ad hoc process RESET_BUSINESS_DATE_ADHOC. Review any configurations in C_ODI_PARAM and RSE_CONFIG tables which may have been altered for your historical loads but need updates for nightly batch data. For example, you may want to update RI_INVAGE_REQ_IND in C_ODI_PARAM if you need calculations of first/last receipt dates and inventory age from the RMFCS data.
Schedule a run of the full AIF nightly batch. Ensure your AIF POM schedule dates for the nightly batch run is aligned with the completed run of RMFCS/RDE, because, from this point forward, the batch schedules will need to remain in sync.

Your transactional facts, such as sales and receipts, should already have history loaded up to this first run of nightly batches, because the next RDE nightly batch will only extract data for the current vdate in RMFCS (for example, it will use the contents of the IF_TRAN_DATA daily transaction table for most fact updates besides sales, which come from Sales Audit directly). Once this first AIF batch completes using the full snapshot of positional data, you may prepare for regular nightly batches which will use the incremental extracts from RDE.

The calendar validator job rule CAL_R2 may cause the batch to fail if this is the first time using Merchandising calendar data directly. This is because the default system calendar in Merchandising does not follow RAP recommendations, which is that the first year of the calendar must be a complete fiscal year. If this happens, verify that the first year of the Merchandising calendar exists much earlier than any actual data in RAP (for example, the Merchandising calendar starts in 2010 but RAP data only exists from year 2020 onwards). If this is confirmed, you may change the validation rule to be a warning instead of an error. Update the table C_DIM_RULE_LIST from the Control & Tactical Center. Change the error type for this rule to W so that it only throws a warning in the batch program instead of failing, and then restart the failed validator job as needed.

4 Integration with Merchandising