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 and partitioning, 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:

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

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

3. Run the process SEEDPOSITIONALFACT_ADHOC, which will extract full snapshots of all positional data, zip them, and push them to the RAP FTS location.

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

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

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

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