Oracle® Retail Assortment Planning Implementation Guide Release 14.1.1 E62994-01 |
|
![]() Previous |
![]() Next |
This chapter contains a summary of the scripts that are needed to execute and maintain AP.
Details of the batch scripts are described in Chapter 6. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on formatting the load data files and on the utilities that enable administrators to load data into RPAS.
Note: Comma-separated values (CSV) files are recommended to reduce the sizes of load files. |
The following directories are used by the batch scripts. These directories are subdirectories of the $AP_HOME
directory.
Table 7-2 summarizes the available batch scripts, rule groups, and custom menu actions. The batch scripts are located in the <AP_HOME>/bin
directory. The following information is included in the table:
Name of the batch operation
Type (rule group, script, custom menu)
Suggestion on how often to run the script
List of other batch operations on which there is a dependency
Table 7-2 Batch Script Summary
Name | Type | Suggested Frequency | Dependencies |
---|---|---|---|
ap_sib_batch.ksh |
Script |
Daily |
environment.ksh |
ap_load_measures.ksh |
Script |
Weekly |
base_importlist.txt, environment.ksh |
ap_batch.ksh |
Script |
Weekly |
environment.ksh |
importfromSPO.ksh |
Script |
As needed |
environment.ksh, |
exportToIP_noODI.ksh |
Script |
As needed |
environment.ksh, |
exportToAlloc.ksh |
Script |
As needed |
environment.ksh |
exportToPPK.ksh |
Script |
As needed |
environment.ksh, |
BP_PreRange.ksh |
Script |
Automatic |
environment.ksh |
environment.ksh |
Script |
As needed |
None |
PreRange.ksh |
Script |
Automatic |
environment.ksh |
Two scripts are included in the other batch scripts to control logging and set environment variables.
The first script, message.ksh, controls the overall logging. The script writes batch script details to a daily log file. The daily log file is created in the $AP_HOME/logs
directory and can be in the format of MnthID_Day.log, for example, Apr_02.log.
The second script, environment.ksh, is called at the beginning of every batch script. This script must be called prior to starting a DomainDaemon so that the necessary environment variables are set. This script sets the following variables:
export AP_CONFIGNAME=APFA
export AP_CONFIGHOME=$AP_HOME/config
export AP_DOMAINHOME=$AP_HOME/domain
export AP_EXPORT=$AP_MASTERDOMAIN/output
export AP_INPUTHOME=$AP_HOME/input
export AP_LOG_DIR=$AP_HOME/logs
export AP_MASTERDOMAIN=$AP_DOMAINHOME/APFA
export AP_TEMP=$AP_HOME/temp
export AP_BATCH=$AP_HOME/bin
export AP_GUROBI_DUMP_PATH=$AP_HOME/logs
export RECORDLOGLEVEL=warning
The script environment.ksh also exports the variable RPAS_JAVA_CLASSPATH. The required components for RPAS_JAVA_CLASSPATH are:
$RPAS_HOME/applib/adflogginghandler.jar
$RPAS_HOME/applib/adfm.jar
$RPAS_HOME/applib/adf-share-base.jar
$RPAS_HOME/applib/adf-share-ca.jar
$RPAS_HOME/applib/aaiAP.jar
$RPAS_HOME/applib/aaijni.jar
$RPAS_HOME/applib/castor-1.3.3-core.jar
$RPAS_HOME/applib/castor-1.3.3-xml.jar
$RPAS_HOME/applib/coherence.jar
$RPAS_HOME/applib/commons-cli-1.2.jar
$RPAS_HOME/applib/commons-collections-3.2.1.jar
$RPAS_HOME/applib/commons-io-2.4.jar
$RPAS_HOME/applib/commons-lang-2.6.jar
$RPAS_HOME/applib/commons-lang3-3.3.2.jar
$RPAS_HOME/applib/commons-logging-1.1.1.jar
$RPAS_HOME/applib/commons-math-2.2.jar
$RPAS_HOME/applib/gurobi.jar
$RPAS_HOME/applib/javax.persistence_2.0.jar
$RPAS_HOME/applib/jps-api.jar
$RPAS_HOME/applib/junit.jar
$RPAS_HOME/applib/log4j-1.2.17.jar
$RPAS_HOME/applib/lpspec.jar
$RPAS_HOME/applib/ojdbc7.jar
$RPAS_HOME/applib/opencsv-2.1.jar
$RPAS_HOME/applib/resourcebundle.jar
$RPAS_HOME/applib/rse_analytics.jar
$RPAS_HOME/applib/rse_common.jar
$RPAS_HOME/applib/spring-beans-4.0.2.RELEASE.jar
$RPAS_HOME/applib/spring-context-4.0.2.RELEASE.jar
$RPAS_HOME/applib/spring-core-4.0.2.RELEASE.jar
$RPAS_HOME/lib/oracleRpasUtils.jar
$RPAS_HOME/lib/rpasjni.jar
The script environment.ksh has the correct format for this environment variable.
A system administrator can scan the logs for any errors, exceptions, or failures. If there are none, the batch completed successfully.
During implementation, the following scheduling of the batch processes is required:
Daily batch
Weekly batch
Monthly batch
Yearly batch
The Generally Available (GA) solution does not provide all the scripts to cover the batch processes. The shell scripts function as the wrapper for calling the RPAS utility to execute a specific task. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on RPAS utilities for batch maintenance.
Some of the key batch processes to consider during implementation are:
Start/Stop DomainDaemon process which allows user connection to the application
Backup process (both domains and log files/processed data files)
Check for CommitASAP process
Hierarchy load and purge process
Load measure process: importdata.ksh script can be utilized to perform this task
Export data process
Daily Batch Process
Daily batch covers the process of updating the hierarchy, importing data, and exporting the plan data.
The general standard process is as follows:
Stop the DomainDaemon process. This prevents the users from connecting to the application while the batch process is executing. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on how to start/stop the user connections to the application using the RPAS utility DomainDaemon.
Create a job to run the script ap_sib_batch.ksh. This script calls rule groups in the domain to refresh the data sent to RMS using the Slow Item Build process.
Note: This step is only necessary if the implementation is using the Slow Item Build feature. No daily batch is necessary if Slow Item Build is not used. For more information on Slow Item Build, see the Oracle Retail Assortment Planning User Guide for the RPAS Fusion Client. |
Start the DomainDaemon process. This enables the users to connect to the application after the batch processes are complete.
Weekly Batch Process
Weekly batch covers the process of updating the hierarchy, importing data, and exporting the plan data.
The general standard process is as follows:
Stop the DomainDaemon process. This prevents the users from connecting to the application while the batch process is executing. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on how to start/stop the user connections to the application using the RPAS utility DomainDaemon.
Create and run a script that calls the RPAS utility loadHier. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on this RPAS utility. The hierarchy files must be placed in the domain/input
directory. This process updates the domain hierarchy positions/labels with the latest hierarchy definition.
Run the import data script to load the latest data into the domain. This is the ap_load_measures.ksh script. The script detail is provided in Chapter 6. The data files must be placed in the domain/input
directory. This process updates the measure data based on the measure file extension. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on load file format and extension types.
Run the post-processing script called ap_batch.ksh. This script runs the following batch rule groups that processes the loaded data into the format required for measures shown in the application:
Batch_GB: This rule group sets the flag for weeks that are considered to be elapsed in the application. If the week ending day is Saturday, this batch process must run from midnight Saturday through Sunday.
Batch_WP_Update: This rule group updates the Working Plan (WP) measures with the weekly posted data for elapsed weeks. This maintains the planned data for unelapsed weeks, but updates the elapsed weeks with the actuals.
Batch_Inv_Flow: This rule group updates the inventory flow measures, that is, Beginning of Period Inventory (BOP) values and End of Period Inventory (EOP) values based on the latest posted Sales and Receipt values.
Curve_Calc: This rule group updates the Sales Curve % and Seasonality Curve % measures based on the loaded MFP targets and loaded Sales Curve profiles. This rule group is not required in batch if the targets and profile values are planned within the application using the Maintenance workbooks provided.
Export plan data to IP, Allocation, and Prepack (if required). The export script details are provided in Chapter 6. Some of the export script also calls batch rule groups to pre-process the plan data into the format required for export. The following rule groups are used for export:
AP_to_IP: This rule group pre-processes the data into the format required by IP. It takes the plan measure and aggregates/spreads the data into the base intersection that matches the format required by IP. The base intersection required is specified in the file AP_IP_transferList.txt.
AP_to_Alloc: This rule group pre-processes the data into the format required by Allocation. It takes the measure data to populate the export measure which conforms to the format required by the export script.
AP_to_Alloc_Cl: This rule group sets the mask measure flag to false after the pre-processing of AP_to_Alloc is completed.
Start the DomainDaemon process. This will allow the users to connect to the application after the batch processes are complete.
These are the scripts that are called by the user in the application during the planning process:
PreRange_GB: Sets the foundation for the PreRange and BP_PreRange at the master domain level.
PreRange: Sets the pre-range mask for the Store Clustering, Shopping List, Wedge, Buying Plan, and Weekly & Historical Review workbooks.
BP_PreRange: Sets the pre-range mask for the Buying Plan workbook.
The purpose of these scripts is to set the pre-range mask measure for some of the planning workbooks. This mask measure establishes a mapping between the positions of the hierarchies in the intersection of the measure which governs the position availability in the workbook wizard process. Since the user's plan from one workbook to another workbook impacts this mask measure definition, the user has the control of when to execute these scripts as part of the planning process.