4 RDF Cloud Service Extensibility

As mentioned in Chapter 3, "RDF Configuration," apart from configuring the RDF application through the plug-ins, RDF also supports extensibility of the GA configuration. This chapter describes the rules and restrictions enforced to extend the RDF GA configuration, so as to preserve the customizations in future patch and upgrades.

RDF also provides a mechanism for implementers to extend the RDF Batch process, where in custom rule groups can be executed during the batch process. RDF also supports Dashboard extensibility.

The solutions within the RDF GA configuration can be categorized into:

Solutions that is extensible.
Solutions that cannot be extensible.

The Solutions that cannot be customized are the ones not generated by the plug-in. The non extensible solution is:

Common

Generally the solutions generated by the plug-in can be customized; however they should follow the rules for extending a solution. The extensible solutions are NewItem, PrepDemand and RDF.

Supported Customization of RDF Configuration

The following sections list the customizations that are allowed to the RDF configuration. These configuration components can be customized:

Solution
Measures
Rules and Rule groups
Workbooks and worksheets
Hierarchy
Taskflow
Styles

All the names of custom realized measure, rule set, rule group, rule, workbook, worksheet, and styles should begin with the prefix c_ or C_.

Custom worksheets can only be added into existing RDFCS GA workbook tabs for the plug-in generated solutions.

Rules for Customizing Hierarchy

The following hierarchy customizations are allowed to the RDF configuration:

Clients are allowed to add new hierarchy or add new dimension into the existing hierarchy. No dimension can be added to calendar hierarchy that is lower than day. No change can be made to the RDF internal hierarchies.
Clients are allowed to change the label of existing hierarchies or dimensions.
All the dimension and roll-up order in the product, RHS product, location and RHS location hierarchy must be preserved in the custom configuration.

Rules for Adding Measures

The following rules apply when adding measures to the RDF configuration:

Clients are allowed to add new custom measures into the custom solution and reference them as an external measure in the extensible solutions.
Clients can also add new custom metric as a major component in the extensible solutions. It is strongly recommended not to mix custom metrics with the RDF metrics.
Custom measures should follow the naming convention and should begin with a &rsquor;C_' or &rsquor;c_' prefix.
Only the published GA measures can be used in custom rules and custom workbooks. Only writable GA measures can be used on the left hand side of an rule expression. The read only GA measures can only be used on the right hand side of the rule expression.

Publishing Measures

The published GA measures can be divided into these categories:

Read only—can only be used on the right hand side of the expression
Writable—can be used on both the left hand side and right hand side of the expression
RuleGroupOnlyWritable—a specific measure that can be read/write in the specified rule group
Loadable—measures that can be loaded using OAT and can be present in the custom load batch control file.
WorkbookMeasureOverride—measures whose property can be overridden in the associated workbook
ReadableExecutionSet—list of GA batch control exec set names that can be called from within custom batch control exec file.

The list of published measures can change based on forecast levels in a particular configuration. Therefore it is dynamically generated at each RDF configuration regeneration.

The contents of the list is saved in a file named: publishedRDFMeasures.properties.

The file is located under [config]/plugins. Before writing custom rules, regenerate your RDF configuration and then open the file to search for published RDF measures.

Custom Measure Characteristics:

Each line of the file has three fields that is | separated.
The first field is either Read Only, Writable, or RuleGroupOnlyWritable.
The second field is the measure name.
The third field is the measure label.
For RuleGroupOnlyWritable, it includes an extra field, rule group name, in the last column.
For WorkbookMeasureOverride, the last column is the name of the workbook in which this measure is allowed to be overridden.

Example 4-1 Sample Custom Measure

ReadOnly|PreSeaProf|Seasonal Profile
ReadOnly|activefcstitem01|Active Forecast Items
ReadOnly|activefcstitem07|Active Forecast Items

Generally, forecasting parameter overrides such as Forecast Method Override, Custom Alerts, auxiliary inputs to RDF such as Promotion Aggregation Profile, and Grouping Membership were writable because an implementer may set them up through customized rules.

Rules for Adding Custom Rules

The following rules apply when adding custom rules to the RDF configuration:

Custom rule sets, rule groups and rule names should begin with the &rsquor;C_' or &rsquor;c_' prefix.
Custom rule groups should not include any GA rules.
Custom rules can use the published readonly GA measures listed in the publishedRDFMeasures.properties file. However, the custom rules cannot modify the value of the readonly GA measure. Hence the readonly GA measure cannot appear on the LHS of a custom rule.
Custom Rules can be added to custom rule group. It can also be added to the plug-in generated GA workbook rulegroups such as load rule group, calc rule group, refresh rule group, commit rule group and custom menu rule. However Custom Rules can not be added to plug-in generated batch rule group.

Rules for Workbooks and Worksheets Extensibility

The following rules apply when adding custom rules to the RDF workbooks and worksheets extensibility:

New Custom workbook and worksheets names should begin with the &rsquor;C_' or &rsquor;c_' prefix.
Apart from the Custom Solution, custom workbooks can also be added to the extensible RDF GA solutions.

Workbook Measure Override Extensibility

RDF supports certain GA measures to be overridden in the GA workbook. These measures are listed in the WorkbookMeasureOverride section of the publishedRdfMeasures.properties file.

For example:

WorkbookMeasureOverride|ppsstdesadjustp01|Std ES Adjustment Flag|PpsAdminP01

This indicates that the measure ppsstdesadjustp01 can be overridden in the PpsAdminP01 workbook.

The following rules apply to override measure properties:

Base State and Agg State can be overridden.
Range property of static picklists can be overridden. Note that options can only be removed; new options cannot be added.

Elapsed Lock Override

RDF supports the RPAS platform feature of Elapsed Lock Override in the following scenarios:

Custom measures in a workbook can have the Elapsed Lock Override set to true.

Custom workbooks can have this field set to true for GA measures that are in the Writable list of the published measures.

Note:

If a GA measure is not been enabled as Elapsed Lock Override, the following steps can achieve the same behavior:

Make sure the GA measure is writable.
Register a custom measure and load it from the GA measure.
Set the custom measure as Elapsed Lock Override.
Edit the custom measure in the workbook.
Commit the custom measure back into the GA measure.

Rules for Adding Custom Real Time Alerts into Existing Workbooks

Perform the following steps when adding custom real time alerts into existing workbooks.

Note:

These steps have to be performed using RPAS Configuration Tools. Copying, pasting or direct editing of xml files is prohibited.

To add custom real time alert into existing workbooks, all measures related to the custom real time alert need to be added to the workbook.
Create a style for the custom real time alert in the configuration.
Create a custom real time alert in an RDF workbook using the measures and style created from the previous steps.
If a real time alert defined in custom solution will be used in a GA workbook, the real time alert measure should be imported as an external measure in the corresponding GA solution.
We must ensure that the rule group consistency is maintained while adding any custom rules that might be needed to calculate an alert measure.

The RDF plug-in will preserve a custom real time alert during regeneration

Adding a Custom Solution

Custom solution is a separate solution within the RDF Configuration. It can be used to accommodate custom workbooks, rules, alerts to do custom reporting, custom logic and threshold alerts by using GA measures (based on the extensible GA measures in Table 4-1). In addition, measures and alerts defined in the custom solution can be plugged into existing workbooks in GA solution based on the contexts defined. Clients are allowed to create their own custom solutions by following the rules mentioned above. To use a GA measure in custom workbooks, the GA measure should be imported as an external measure in custom solution.

Adding Custom Styles

New styles can be added in the Style Definition window of Configuration Tools. The custom style name should be prefixed with either c_ or C_. Style names that do not adhere to the naming convention will be caught during the configuration validation. Any new style added will be retained during upgrades and patches.

Validating the Customized Configuration

A script, rdf_config_validation.ksh, has been provided to allow the customer or implementer to validate that the customizations conform to the rules outlined above. For details of the script, refer to Configuration Validation.

This script can be run on Windows with the RDF Starter Kit. To do this, the implementer will need to make sure that they have a pristine copy of the GA configuration as well as the custom configuration.

For example, if the GA configuration has been copied to C:\Oracle\configurations\GA\RDF and the custom configuration is in C:\Oracle\configurations\RDF, then the script can be called from a Cygwin zsh shell:

$RPAS_HOME/bin/rdf_config_validation.ksh -n RDF -d /cygdrive/c/Oracle/configurations -c /cygdrive/c/Oracle/configurations/GA/RDF/RDF.xml

Successful Run of the Validation Script

If all the validations pass, it will output the following message:

Example 4-2 Message for Successful Run of Validation Script

09:04:47 : INFORMATION : rdf_config_validation.ksh[0] - rdf_config_validation.ksh completed.
09:04:47 : INFORMATION : rdf_config_validation.ksh[0] - Program completed successfully.
09:04:47 : INFORMATION : rdf_config_validation.ksh[0] - Exiting script with code: 0

Unsuccessful Run of the Validation Script

If all the validations do not pass, it will output the following message:

Note:

The bold line shows where the details of the validation failure are in the log. (In the actual log, this line is not bold.)

Example 4-3 Message for Unsuccessful Run of Validation Script

09:15:12 : INFORMATION : rdf_config_validation.ksh[0] - For details of validation, look in '/cygdrive/d/retek/logs/2017-07-18/rdf_config_validation.091506.1/rdf_config_validation.log'.
09:15:12 : INFORMATION : rdf_config_validation.ksh[0] - _call executing command 'execplug-inTask.sh RDF:com.retek.labs.rdf.plug-in.installer.RDFConfigurationValidation /cygdrive/c/Oracle/configurations/GA/RDF/RDF.xml /cygdrive/c/Oracle/configurations RDF'
09:15:17 : INFORMATION : rdf_config_validation.ksh[0] - _call of command 'execplug-inTask.sh RDF:com.retek.labs.rdf.plug-in.installer.RDFConfigurationValidation /cygdrive/c/Oracle/configurations/GA/RDF/RDF.xml /cygdrive/c/Oracle/configurations RDF' complete
09:15:17 : ERROR : rdf_config_validation.ksh[0] - Nonzero exit status code.
09:15:17 : INFORMATION : rdf_config_validation.ksh[0] - Exiting script with code: 9

Taskflow Extensibility

The RDF Taskflow is extensible. The implementer can customize the taskflow in Configuration tools to add custom taskflow components like activitives, tasks, steps, tabs and worksheets. Any custom taskflow component added to GA taskflow component will be retained after plug-in automation. As part of extensibility, RDF provides a mechanism where in, the implementer can hide certain components of the GA configuration and taskflow by editing a property file. The property file is a simple text file named extend_rdf.properties and is located inside the plug-in directory of the configuration.A sample file is included in the plug-ins directory of the GA configuration for reference.

For example, RDF\plug-ins\ extend_rdf.properties

The format of the file is shown as:

Stage|Component|Action|Value

For example, Customization | Worksheet | Hide | activity_ni.task_niattmaint.NITREVSht1

Each line consists of four fields separated by the &rsquor;|' character. The value field can contain a comma separated list of values. Note that the value field should specify the fully qualified name of the taskflow component. Refer to the sample file. Any line that begins with a &rsquor;#' character is considered a comment line and is ignored.

The names of the Taskflow entities can be found in the taskflow.xml file located in the configuration directory.

The various GA configuration components that can be hidden are listed in the following table:

Component	Description
Activity	Hides the specified Taskflow activity. The value field is the taskflow activity name.
Task	Hides the specified Taskflow task. The value field is the taskflow task name.
Step	Hides the specified Taskflow step. The value field is the taskflow step name.
Tab	Hides the specified Taskflow tab. The value field is the taskflow tab name.
Worksheet	Hides the specified worksheet. The value field is the worksheet name.
Realtime Alert	Hides the specified Real Time Alert. The value field is the real time alert name.

Customizing the RDF Batch Process

This section describes how to customize the RDF GA batch process to meet the business needs of the retailer. Details on the RDF GA batch process is described in the Administration guide. The Configured Batch tasks have the below tasks related to batch control:

Retrieve Batch Control File – allows the current batch control files to be retrieved for inspection and modification.
Update Batch Control File – After inspecting the current batch control files, the implementer can edit the batch control files to customize the batch process.

Details on the previous two tasks are described in the Oracle Retail Demand Forecasting Administration Guide.

The RDF Batch process is based on the RPAS Enterprise Edition Batch Framework, which makes use of a set of control files. Table 4-1 lists the RDF Batch control files that can be customized. For detailed information on the RPAS Batch Framework, refer to the Oracle Retail Predictive Application Server Implementation Guide.

Table 4-1 Customizable RDF Batch Control Files

Control File	Description
batch_exec_list.txt	This is the controller and entry point for all the other services, specifying groups of services to be run in a specific order.
batch_calc_list.txt	This control file groups all the calc services that need to run using mace.
batch_refresh_list.txt	This control file groups all Workbook refresh rule groups
batch_loadmeas_list.txt	This control file groups measures that need to be loaded into domain using the measure load service
batch_exportmeas_list.txt	This control file groups measures that need to be exported out of the domain using export measure service.
batch_xform_list.txt	This control file handles the transform file service to perform file transformations to support simple integration capabilities.
batch_oat_list.txt	This file lists the configured batch tasks that appear in the OAT drop down list.

Custom Hooks and Boolean Scalar Measures for Flow Control

There are two ways to customize the batch control files:

Custom Hooks
Boolean Scalar Measures for Flow Control

The custom hooks are an optional batch set executed by GA batch control files. The implementor can define the contents of these batch set in the customized batch control file that lives in the [domain]/batch_control_cust. If these hooks are not defined, the batch process skips these hooks, If they are defined, its contents are executed.

RDF also defines a list of Boolean Scalar Measures in the domain to control if certain GA defined batch sets can be skipped or not. The following tables lists the hooks and Boolean Scalar Measures.

Estimation Phase

Table 4-2 lists the hooks for the Estimation Phase.

Table 4-2 Estimation Phase Hooks

Hook	Description
hook_pre_slc_est_SF_	This hook is added before the GA Short Lifecycle estimation calculations. _SF_ needs to be replaced by level number.
hook_post_slc_est_SF_	This hook is added after the GA Short Lifecycle estimation calculations. _SF_ needs to be replaced by level number.
hook_pre_llc_est_BF_	This hook is added before the GA Long Lifecycle (baseline only) estimation calculations. _BF_ needs to be replaced by level number.
hook_post_llc_est_BF	This hook is added after the GA Long Lifecycle (baseline only) estimation calculations. . _BF_ needs to be replaced by level number.
hook_pre_csl_est_CF_	This hook is added before the GA Long Lifecycle (casual) estimation calculations. . _CF_ needs to be replaced by level number.
hook_post_csl_est_CF_	This hook is added after the GA Long Lifecycle (casual) estimation calculations. . _CF_ needs to be replaced by level number.

Preprocess is Intertwined with Estimation Phase

Table 4-3 lists the hooks for when preprocess is intertwined with the Estimation Phase.

Table 4-3 Preprocess is Intertwined with the Estimation Phase Hooks

Hook	Description
hook_pre_preprocess_seasonal_CF_	Where_CF_ should be replaced by the final level name. This hook is called before running preprocessing path to produce baseline data source
hook_post_preprocess_seasonal_CF_	Where_CF_ should be replaced by final level name. This hook is called after running preprocessing path to produce baseline data source
*hook_pre_preprocess_promo_CF_	Where_CF_ should be replaced by final level name. This hook is called before running preprocessing path to produce causal data source
*hook_post_preprocess_promo_CF_	Where_CF_ should be replaced by final level name. This hook is called after running preprocessing path to produce causal data source
hook_post_csl_estimate_depromote_CF_	Where_CF_ should be replaced by final level name. This hook is called after the estimation batch is done when depromote preprocessing is configured.
hook_ppsindicator_CFSEASONALXP_	Where_CFSEASONALXP_ should be replaced by the preprocessing path name. The path should be the one that produce baseline data source. This hook is called after GA promotion indicators and promo lift calculation and before calling preprocessing special expression_. It is intended for implementer to add custom steps to calculate promolift if they set precalcpromolift to false.
hook_post_csl_est_seasonal_CF_	Where_CF_ should be replaced by final level name. This hook is called after creating approved seasonal curves.
hook_ppsindicator_CFPROMOXP_	Where_CFPROMOXP_ should be replaced by preprocessing path name. The path should be the one that have deseasonal configured and produce causal data source. This hook is called after GA calculate seasonal profile and before running the preprocessing special expression. It is intended for implementer to add custom steps to modify seasonal profile.
hook_post_csl_est_promo_CF_	Where_CF_ should be replaced by final level name. This hook is called after producing approved promo effects.

Weekly Batch Forecasting Phase

Table 4-4 lists the hooks for the Weekly Batch Forecasting Phase.

Table 4-4 Weekly Batch Forecasting Phase Hooks

Hook	Description
hook_preload	This hook is before data loading, at the begining of batch weekly forecast
hook_pre_post_data_load	This hook is between GA measure load and post_data_load rule group run
hook_pre_preprocess	This hook is between post_data_load rule group run and preprocess
hook_ppsindicator	This hook is between preprocess seasonal profile calculation and preprocessing batch
hook_post_preprocess	This hook is after the preprocessing phase and before generating the forecasts.
hook_pre_forecast	This hook is after New Item calculation and before the forecast generation step.
hook_frcst_adjust_SF_	This hook is provided to add custom forecast adjustment calculations for Short Lifecycle and Long Lifecycle. Thiss hook is before the alert calculation step. _SF_,_BF_ ,_CF_ needs to be replaced by a level number.
hook_frcst_adjust_BF_
hook_frcst_adjust_CF_
hook_frcst_alert_SF_	This hook is provided to add custom forecast alert calculations for Short Lifecycle and Long Lifecycle. This hook is before the Forecast Approval step. _SF_, _BF_ and _CF_ needs to be replaced by a level number.
hook_frcst_alert_BF_
hook_frcst_alert_CF_
hook_frcst_approval_SF_	This hook is provided to add custom Forecast approval calculations for short Lifecycle and Long Lifecycle. This hook is added before the dashboard calculations. _SF_, _BF_ and _CF_ needs to be replaced by a level number.
hook_frcst_approval_BF_
hook_frcst_approval_CF_
hook_post_forecast	This hook is between forecast and export
hook_post_export	This hook is after export

Boolean Scalar Measures

Table 4-5 lists the Boolean Scalar Measures.

Table 4-5 Boolean Scalar Measures

Boolean Scalar Measure	Description
loadrmsdata	This measure is defaulted to false. Set it to true if RDF is integrated with RMS.
runpreprocess	This measure is defaulted to true. Set it to false if preprocessing is not configed or user would like to skip preprocess for batch_weekly.
PreCalcPromoInd	This measure is defaulted to true. RDF automatically calculate the promotion indicator used in preprocessing through merging of promotion variables in causal forecast level. Set it to false if customer would like to load the promotion indicator for de-promote instead of merging promotion variables.
runnewitembatch	This measure is defaulted to true. Set it to false if new item is not configed or user would like to skip new item batch for batch_weekly.
runestimate_SF_	This measure is defaulted to true. Set it to false if customer would like to avoid running estimation on certain short life cycle levels. _SF_ needs to be replaced by level number.
runfrcst_SF_	This measure is defaulted to true. Set it to false if customer would like to avoid running forecast on certain short life cycle level. _SF_ needs to be replaced by level number.
runestimate_BF_	This measure is defaulted to true. Set it to false if customer would like to avoid running estimation on certain baseline only level. _BF_ needs to be replaced by level number.
clearcurve_BF_	This measure is defaulted to true. Set it to false if customer would like to keep seasonal curves for previous estimation run if no season curve is produced from current run. _BF_ needs to be replaced by level number.
runfrcst_BF_	This measure is defaulted to true. Set it to false if customer would like to avoid running forecast on certain baseline only level. _BF_ needs to be replaced by level number.
runnewitem_BF_	This measure is defaulted to true. Set it to false if customer would like to avoid incorporate new item forecast on certain baseline only level. _BF_ needs to be replaced by level number.
runestimate_CF_	This measure is defaulted to true. Set it to false if customer would like to avoid running estimation on certain causal level. _CF_ needs to be replaced by level number.
clearcurve_CF_	This measure is defaulted to true. Set it to false if customer would like to keep seasonal curves for previous estimation run if no season curve is produced from current run. _CF_ needs to be replaced by level number.
runfrcst_CF_	This measure is defaulted to true. Set it to false if customer would like to avoid running forecast on certain causal level. _CF_ needs to be replaced by level number.
runnewitem_CF_	This measure is defaulted to true. Set it to false if customer would like to avoid incorporate new item forecast on certain causal level. _CF_ needs to be replaced by level number.

RDF Batch Control File Customization Guidelines

Follow these guidelines for RDF Batch Control File Customization:

The file, batch_oat_list.txt, is the only batch control file in which customers can overwrite the GA setnames (such as exec, calc).
For all other batch control files, avoid overwriting GA setnames. GA batch control files have provided various hooks for the batch process. For additional custom steps, try to put them into the hooks.
GA batch control files have provided a mechanism to skip certain GA steps using boolean scalar measure that can be set in the domain. For example loadrmsdata will allow skip of rms data transformation. runpreprocess, runnewitembatch and runexport allows skip of preprocess, newitem batch and GA export steps. To skip the GA steps, use these mechanism instead of overwriting GA setnames.
For GA hierarchy that is unused in your implementation such as attribute hierarchy, just provide empty hierarchy file. For unused GA measures,no need to provide the data file. RPAS would be able to skip it if no files were provided.
Do not remove any GA clnd hierarchy reorder step, this step is very important for proper functioning of RDF.
For ease of maintenance, all custom batch set name or step names should be prefixed with c_

Examples

The following is an example of custom batch_exec_list.txt, batch_calc_list.txt, batch_loadmeas_list.txt and batch_exportmeas_list.txt.

In this example, the following modification were added to batch _weekly process.

Hierarchy and measure data file were unpacked.
Custom measures were loaded after GA measure load.
Outlier indicator for preprocessing were calculated use custom rules
Custom approval alerts were run afetr GA alerts and before approval
Promotion effects were exported after GA exports

Batch Control Samples

The following sections list samples of batch control processes.

batch_exec_list.txt

Example 4-4 # unpack data file before data load

hook_pre_load | unpack      | rdf_hier.tar.gz hook_pre_load | unpack      | rdf_meas.tar.gz

Example 4-5 # load custome measures after GA hier and measure load

hook_pre_post_data_load | measload    | c_weeklyLoad

Example 4-6 # calculate outlier indicator used in preprocess using custom rules

hook_ppsindicator | calc | c_outlier_calc

Example 4-7 # calculate custom approval alerts after GA approval alerts

hook_frcst_alert07 | exec | c_calc_cust_alerts

Example 4-8 # custom export

hook_post_export | measexport | c_export_promoeffects
c_calc_cust_alerts | calc |c_custalert1
c_calc_cust_alerts | calc |c_custalert2

batch_calc_list.txt

Example 4-9 #outlier calculation

c_outlier_calc | G | GROUP | c_HBICalcTodayIdx
c_outlier_calc | G | GROUP | c_dataprocess
c_outlier_calc | G | GROUP | c_calc_outlier

Example 4-10 #custom approval alerts calculation

c_custalert1 | G | GROUP | c_custalert1
c_custalert2 | G | GROUP | c_custalert2

batch_loadmeas_list.txt

Example 4-11 # load custom measure

c_weeklyLoad | M | c_ActiveItem
c_weeklyLoad | M | c_DisContinue

batch_exportmeas_list.txt

Example 4-12 # export custom measure

c_export_promoeffects|O|promoeffects.csv.dat
c_export_promoeffects|X|storsku_lprm
c_export_promoeffects|F|c_ExportMask
c_export_promoeffects|S|ftp
c_export_promoeffects|M|prmbldeff07

Custom Batch Control Validation

The extensible / custom batch control files need to follow the guidelines previously listed so as to future proof the retailer. That means the retailer should receive software updates without breaking the existing customizations. To ensure that the batch control file guidelines are adhered to, a batch control validation module has been added.

The rdf_config_validation script has an optional parameter -b <parent directory of batch control files> which will validate the batch control files.

Batch control validation rules:

Apart from the batch_oat_list, none of the set names in the other batch control files can be overridden. That is, GA set names cannot be used in custom batch control files.
None of the custom batch control files can call the GA set names.
The batch_calc_list can only specify custom rule group names. Cannot specify expressions and GA rule group names.
The batch_loadmeas_list can specify measures that are listed in the Loadable or Writable list of the published measures in the publishedRdfMeasures.properties file
The batch_exportmeas_list can specify measures that are listed in the ReadOnly or Writable list of the published measures in the publishedRdfMeasures.properties file.
All custom set names should have a prefix of c_.

Note that the batch control validation is called automatically during domain build or patch. It is also called when the batch control files are uploaded using the Upload Batch Control files from OAT.

Parallel Processing Control for Cross-domain Causal Estimation

The calculation for cross-domain causal estimation requires a lot of memory. It is the only calculation in the RDF batch that may require implementors to set a maximum parallel process based on their domain configuration and hardware. An implementor can change the cross domain causal estimation thread count measure in the Batch Flow Management workbook to specify the maximum number of thread count allowed for this calculation. If the measure value is zero, it is using the same default settings as other calculations.

Dashboard Extensibility

RDF supports Dashboard Extensibility by allowing the Dashboard Settings configuration file to be customized.Refer to the chapter, ”Configuring Dashboards in RPASCE EE” in the Oracle Retail Predictive Application Server Cloud Edition (RPASCE) Configuration Tools User Guide for detailed information on Dashboard components.

As part of extensible dashboard, the following are supported:

Adding custom Metric and Exception profiles.
Adding a custom tile to GA Metric and Exception profiles.
Removing GA tiles and profiles.

Figure 4-1 shows the RDF Dashboard as seen in the UI. It consists of two Metric profiles and two Exception profiles.

Figure 4-1 RDF CS Dashboard

Note that the Exception profiles consist of Exception Tiles, and the Metric Profile consists of metric tiles of the type Comparison Tile. Currently RDF does not support the Variance Metric tile.

In Figure 4-1,the Overview Metric profile is selected and the Total Sales tile is highlighted with two sub-measures: Promo Sales and Markdown Sales.

Dashboard Intersection

The RDF GA Dashboard workbook is built at the Sub-class, District level which is controlled by the Dashboard Intersection specified in the Common plug-in. Refer to "Set Up Common Configuration Details." The Dashboard intersection also defines the level to which we can drill down the Product and Location filters in the Dashboard.

Figure 4-2 Product / Location Filters in the Dashboard

Process to Customize the Dashboard

Dashboard profiles correspond to a worksheet in the Dashboard workbook template in the configuration; and the measures displayed in the tiles are measures present in the worksheet corresponding to that profile. So customizing the dashboard is a three-step process:

In the Configuration, add the worksheet, measures, and rules to the Dashboard workbook template.
Regenerate the configuration by running the plug-in automation and then validate the configuration by running the rdf_config_validation script. Refer to the section, "Validating the Customized Configuration," for more information.
Customize the GA Dashboard Settings file in the Deployment Tool.

Note that the Deployment Tool is a utility within the Configuration Tools. Refer to the section, Deployment Tool – Dashboard Settings Resource in the Oracle Retail Predictive Application Server Cloud Edition (RPASCE) Configuration Tools User Guide.

The RDF GA Dashboard Settings configuration file is located in the configuration: RDF\plugins\RDFDashboardSettings.json

Steps to add a custom profile:

In the Configuration Tool, add custom worksheet and measures to the worksheet in the dashboard workbook template in the configuration. Also add load/calc rule for the measures.
In the Deployment Tool, open the GA Dashboard Settings configuration file.
Add the custom profile (Exception or Metric) to the Dashboard Settings configuration file.
Save the file in the Deployment Tool.

Steps to add a custom tile:

Identify the profile and worksheet to which the custom tiles need to be added.
In the Configuration Tool, add the custom measures to the corresponding worksheet. Also add load/calc rule for the measures.
In the Deployment Tool, open the GA Dashboard Settings configuration file.
Based on whether Exception or Metric profile, add the Exception tile or Comparison Metric Tile.
Save the file in the Deployment Tool.

Steps to remove GA tiles and profiles:

Note:

Do not remove the GA measures or worksheet from the Dashboard workbook template in the configuration.

In the Deployment Tool, open the GA Dashboard Settings configuration file.
Delete the GA profile or tile.
Save the file in the Deployment Tool.

Save the Dashboard Settings Configuration file in the same location in the configuration, that is:RDF\plugins\RDFDashboardSettings.json. Since this file is stored inside the configuration, whenever the customer uploads the configuration to the INCOMING_FTP_PATH, the customized Dashboard Configuration file will be used by the application during the domain build or patch process.

Once the domain is built or patched, if minor changes need to be done to the Dashboard that do not require a configuration change, then RPASCE provides a mechanism to Upload and Retrieve JSON files from the application.

This is supported through the Configured Batch OAT task -> Manage JSON Files. Refer to the Oracle Retail Predictive Application Server Cloud Edition (RPASCE) Administration Guide for detailed information on the OAT tasks.

Steps to Retrieve/Upload the Dashboard Configuration file:

Go to the Configured Batch OAT task -> Manage JSON Files -> Retrieve option.
The dashboard settings file will be downloaded into the OUTGOING_FTP_PATH as RDF_json.tar.gz
Un-tar the file and open it in the Deployment Tools.
Edit the file. Note that only minor updates that do not require a configuration change can be made at this time.
Save the file and zip it up as RDF_json.tar.gz and then upload it to the INCOMING_FTP_PATH
Then go to the Configured Batch OAT task -> Manage JSON Files -> Upload option.
Log out and log in to the client.
The Dashboard should be updated with the changes

Applying Changes to the Cloud Environment

To implement these changes in the cloud environment, it is necessary to either build a new domain or patch the domain. Refer to the Install/Patch Domain chapter in the Oracle Retail Demand Forecasting Cloud Service Administration Guide.