C Appendix: RDF Cloud Service Integration with PDS and BDI

This appendix describes how RDF Cloud Service supports integration with RMF CS using Bulk Data Interface (BDI) and Planning Data Storage (PDS). It also allows using only PDS to share data across different RPAS Planning applications if they are registered against it and have common shared hierarchies and positions.

For information on the BDI process flow, see the BDI Process Flow appendix in the Oracle Retail Predictive Application Server Cloud Edition Implementation Guide.

Using PDS

RPAS applications can share measures across shared applications if they share common hierarchies and measure data. RPAS has a PDS which can store the shared dimensions and fact data (shared measures).

A PDS-enabled domain needs an Integration Configuration which contains Shared Dimension data and also shared measures as Fact data that is grouped as Fact Group across different RPAS applications.

All RPAS applications that can be integrated using PDS share a common GA Integration Configuration which is part of the RPAS Application Standard Libraries (RASL) package called RGBU_RDM.xml that is pre-configured.

The following section describes the shared dimension and measure data from the RDF CS solution which is present in Integration Configuration.

Using BDI

BDI allows sharing data across the enterprise. RPAS have BDI importers that import the data from the RMF CS database tables into the PDS. If the customer implements RMF CS and BDI, then the use of PDS is mandatory, as currently the data loaded into BDI can only be internally transformed to PDS shared measures. For more details about PDS, see Using PDS.

If BDI is enabled, there is no need for retailers to export flat files from RMS. In order for the batch process to not wait for the files from RMS, the Batch Uses BDI Boolean flag needs to be set to True.

Shared Hierarchies

Shared Hierarchies in PDS should have the union of all dimensions across the different RPAS applications without any User Defined Dimensions and also all of them should have the same names for common hierarchies and common shared dimensions. If RMF CS integration and BDI are used, those hierarchies will be loaded as part of that scheduled process in BDI.

If the customer is only using PDS and not using BDI, the customer has to first load the shared hierarchies into one of the RPAS applications by calling the loadDimData utility by using Standard Admin Tasks after uploading the shared dimension file named as <hier>.csv.dat with header information including all shared dimension positions with position labels. In the header, the dimension name should be the shared dimension name in the hierarchy file and the dimension label should be <dim>_label.

The file should be uploaded into the $INCOMING_FTP_PATH/rdm_input/dimdata directory.

If the domain is registered against PDS, then the Batch Uses PDS Boolean flag will be set during batch. It controls the flow of the weekly batch.

The RDF CS weekly batch, in turn calls the batch framework service dimdataload to load the dimension data into PDS, if the domain is registered against PDS (Batch Uses PDS flag is set) and not using BDI (Batch Uses BDI flag is not set) to get its data.

Loading dimension data will only load the dimension details into the PDS. The customer needs to run the standard loadHier utility without any input files, in order to synchronize the domain dimension data with PDS for updated positions. That will also be run by default as part of the weekly batch process.

The following tables, Table C-1 through Table C-4, list the shared hierarchies and dimensions for RDF CS available in the GA Integration Configuration. Any additional dimensions present in these hierarchies which are not present in RDF CS can be from another shared application. Those also need to be provided if the customer loads those positions into PDS.

Table C-1 Calendar Hierarchy (clnd)

Shared Dimension	Shared Dimension Label	Aggregate Dimension
day	Day	Not Applicable
week	Week	day
mnth	Month	week
qrtr	Quarter	mnth
half	Half	qrtr
year	Year	half
woyr	Week of Year	year
dow	Day of Week	day

Table C-2 Product Hierarchy (prod)

Shared Dimension	Shared Dimension Label	Aggregate Dimension
sku	Item	Not Applicable
skup	Style/Color	sku
skug	Style	skup
scls	Subclass	skug
clss	Class	scls
dept	Department	clss
pgrp	Group	dept
dvsn	Division	pgrp
cmpp	Company	dvsn
brnd	Brand	sku
vndr	Vendor	sku

Table C-3 Location Hierarchy (loc)

Shared Dimension	Shared Dimension Label	Aggregate Dimension
stor	Location	Not Applicable
dstr	District	stor
regn	Region	dstr
chnl	Channel	regn
chan	Chain	chnl
comp	Company	chan
loct	Location Type	stor
phwh	Physical Warehouse	stor
fflt	Fulfillment Type	stor
tdar	Trade Area	stor
strc	Store Cluster	stor
chnc	Cluster Channel	strc
sfmt	Store Format	stor
stcl	Store Class	stor

Table C-4 Product Attribute Hierarchy (patr)

Shared Dimension	Shared Dimension Label	Aggregate Dimension
patv	Product Attribute Value	Not Applicable
patt	Product Attribute Type	patv

Note: If the customer implementation uses RMF CS flat files for integration and are not using BDI but would like to also use PDS, then it is only partially supported, customer has to customize the batch transform process to transform the RMS files to create the shared hierarchy files from the RMS files as needed by PDS with headers.

Note: GA batch control files contain entries only to load shared hierarchies used by the application into PDS, but PDS can have more hierarchies not used by the current application. If not using BDI to load PDS, it is recommended to load the shared hierarchy common across multiple applications into only one application which contains most of the shared hierarchies. That way the customer can avoid uploading shared hierarchies data into multiple applications.

Shared Fact Data

PDS shared measure data are called as Fact Data to share across different planning applications.

Shared fact data are grouped together as fact groups to enable them to be accessed together. If RMF CS Integration and BDI are used, those shared fact measures are directly loaded as part of the scheduled process in BDI. If the customer is only using PDS and not using BDI, then they have to load the fact data into one of the RPAS applications by calling the loadFactData utility by using Standard Admin Tasks after uploading the shared fact file named as <fact_group>.csv.ovr or <fact_group>.csv.rpl with the header as the shared fact name. The customer can use any single file with any name or split them into multiple files to load different fact measures if all of them have the same base intersection, but it is recommended to load the files after grouping them as per the fact groups to allow them to load in parallel.

The file should be uploaded into the $INCOMING_FTP_PATH/rdm_input/factdata directory.

If the domain is registered against PDS, then the Batch Uses PDS Boolean flag will be set during batch. It controls the flow of weekly batch.

Loading fact data will only load the fact data into PDS and will automatically make the mapped shared measures available into the registered domains, customer does not have to load those shared measures again into domains.

Table C-5 lists the shared measures for RDF CS available in the GA Integration Configuration.

Table C-5 RDF CS Shared Measures Available in the GA Integration Configuration

Fact Name	Fact Label	Fact Group Name	Shared Measure Name
psal	Promotion Sales	psal	psal
rsal	Regular Sales	rsal	rsal
csal	Clearance Sales	csal	csal
LdPreOosInd	Loaded Out of Stock Indicator	wsal	PreOosInd
appwkfrcst	Approved Forecast	fcst	appwkfrcst
appwkbaseline	Approved Baseline	Fcst	appwkbaseline
appwkcumint	Approved Forecast Error	Fcst	appwkcumint
appdayfrcst	Approved Forecast - Day Level	fcst_day	appdatfrcst
appdaybaseline	Approved Baseline - Day Level	fcst_day	appdaybaseline
appdaycumint	Approved Forecast Error - Day Level	fcst_day	appdaycumint

Note: If you want to integrate RDF CS with RMF CS using flat files and use PDS but not use BDI, then it is only partially supported. You have to customize the batch transform process to transform the RMS files to fact files with headers fact names as headers to load into PDS.

Note: Currently BDI-PDS existing integration is not extensible, it cannot be further customized to add more measures to be integrated from BDI. Only existing measures present in GA Integration configuration for PDS can now be integrated with BDI.

Note: PDS allows using fact measures with a lower intersection than the shared measures present in the domain and allows them to aggregate it while accessing the data from PDS. For MFP CS, all fact measures loaded at the sku level are aggregated and viewed as shared measures in MFP CS at the scls level.

Implementation Steps with BDI, PDS, and RMF CS Integration

If BDI implementation with RMF CS is used for implementation, the following steps need to be done in this order. The steps assume that RPAS, RASL, UI, and BDI are already deployed:

1. Once MFP Cloud Service environment is provisioned, using bootstrap build MFP domain using the initial set of customer hierarchy data. For Shared Hierarchies which are expected to come from BDI/PDS, load only with valid positions which are in BDI. It's not necessary to have all records, but atleast one valid position in each of the shared hierarchy files is needed.

2. Build PDS using the default integration configuration, without uploading any data. After PDS is built, it will also register the domain against that PDS.

3. Integrate with BDI and load PDS by running the BDI Process Flows. That should load the PDS schemas with data from BDI for both shared dimensions and shared measure (fact) data.

4. Upload the hierarchy files for non-shared hierarchies and run the Load Hierarchies OAT task under Configured Batch Tasks. It will synch up the shared hierarchies with PDS and load the non-shared hierarchies from the uploaded files.

5. Set the Batch Uses BDI and Enable RMF CS Boolean measures in the Admin workbooks.

6. Set up the necessary Admin data or load the admin data files.

7. Run the weekly batch to process all loaded actuals (from PDS for shared data).