7 Batch Processing

This chapter contains a summary of the scripts that are used to maintain Category Management through batch processing.

Before the first batch run, the system environment must be set up, along with certain data measures (batch parameters) that control the batch calculations. Pre-batch setup is described in this chapter.

See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on formatting load data files and on utilities that enable administrators to load data into RPAS.

Note:

Comma-separated values (CSV) files are recommended to reduce the sizes of load files.

Batch Script Summary

The following directories are used by the batch scripts. These directories are subdirectories of the <CM_HOME> directory. The <CM_HOME> directory is defined by the implementer.

Table 7-1 Directories Used by Batch Scripts

Directory Name	Content of the Directory
bin	Batch scripts
config	Category Management template configuration
domain	Domains
input	Input files for building the domain
logs	Log files from running any of the batch scripts
temp	Temporary files used by the batch scripts

Batch Script Summary Table

Table 7-2 summarizes the available batch scripts, rule groups, and custom menu actions. The batch scripts are located in the <CM_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
cm_batch.ksh	Script	Weekly	None
processcdts.ksh	Script	As needed	None
deleteCdts.ksh	Script	As needed	None

Scripts and custom menus write processing information to the batch log files. These are located by default at <CM_HOME>/logs and are grouped by date and script name. The logs contain detailed information on batch execution, including indications of errors, exceptions, or failures. If there are no errors, the batch completed successfully.

Batch Scripts

This section contains detailed information on the batch scripts.

cm_batch.ksh

Script

cm_batch.ksh

No arguments are expected or processed by the script.

Notes

This script is performs many functions related to keeping information within RCM current and consistent. The operations that are performed by this script include the following:

Calculating the elapsed period, functionality provided by RPAS to ensure historical data is read-only.
Applying the elapsed period to market and retailer measures within the solution.
Propagating changes made by administrative updates to various other measures, such as repopulating picklists.
Refreshing the forecasted sales information.
Refreshing the timeshifted LY data for market and retailer information.
Aggregating and pre-calculating information for later, faster use in workbooks.
Refreshing product attribute values.

The script should be run regularly and frequently - daily or weekly being recommended. It may also be run whenever there are significant updates to data; the updates should be applied to the system.

Note that if RPAS_TODAY is set, the script uses this instead of the current system date. This could be useful, for example, for testing.

The actions the script takes are done by invoking various rule groups within RCM. There are dependencies between the various rule groups, and running the rule groups out of the order specified in cm_batch.ksh can lead to unpredictable results.

Processing logs for this script are written to the <CM_HOME>/logs/<date_dir>/<calling_script>/cm_batch<unique id> directory. Here,

<date_dir> is a directory with a name corresponding to the date the script was run, in the format YYYY-MM-DD.
<calling_script> is the name of the script that calls the cm_batch.ksh script, along with a <unique id>. Most often, this directory is called "build" or omitted. If the script is called directly from the command line, this will be blank.
<unique id> is a system generated string of numbers that is unique in this context.

Inside this folder, the log file is called cm_batch.log. Additional folders are created for every invocation of the script.

processcdts.ksh

Script

processcdts.ksh

Usage

processcdts.ksh -f <cdtfile> [-l <label>]

<cdtfile> is the name of the XML file that contains a consumer decision tree (CDT). The script expects the CDT file to be in the <domain>/cdt_interface/import directory.

<label> is an optional label that is stored in the domain for the given CDT.

Notes

This script is used to load CDT XML files into the domain. It is called by build.ksh, which performs the initial domain build and the Accept XML custom menu. It parses the XML and translates the structure described in the file into measures that are used to create dynamic workbook hierarchies.

The script calls a java utility to perform the XML parsing and dynamic hierarchy measure construction. The java class files are located in $RPAS_HOME/applib/aaiCatMan.jar. This jar file must be present in the correct location for the processcdts.ksh script to run. The script also ensures that the environment variable RPAS_JAVA_CLASSPATH contains the path to this jar.

Processed CDTs are stored in the <domain>/cdt_interface/processed/cdts directory. The script generates a large number of measure load files, named DHD_Name* and DHD_Label*, and loads them into the domain. The processed DHD_Name* and DHD_Label* measures are copied with other loaded measures to the <domain>/input/processed directory.

Processing logs for this script are written to the <CM_HOME>/logs/<date_dir>/<calling_script>/processcdts<unique id> directory. Here,

<date_dir> is a directory with a name corresponding to the date the script was run, in the format YYYY-MM-DD.
<calling_script> is the name of the script that calls the processcdts.ksh script, along with a <unique id>. Most often, this directory is called "build" or "acceptEditedCdts", after the scripts that most often call processcdts.ksh. If the script is called directly from the command line, this will be blank.
<unique id> is a system generated string of numbers that is unique in this context.

Inside this folder, the log file is called processcdts.log. Additional folders are created for every invocation of the script.

When the domain is first built, a fixed number of versions are allotted for CDTs for each consumer segment. processcdts.ksh loads each CDT into the first available slot for that category/trading area/consumer segment. If there are more CDTs for a particular category/trading area/consumer segment than there are available slots, processcdts.ksh will exit with an error message. New version slots must be created, via Dynamic Position Management. See the Oracle Retail Predictive Application Server Configuration Tools User Guide and the Oracle Retail Predictive Application Server User Guide for the Fusion Client for more information on Dynamic Position Management.

deleteCdts.ksh

Script

deleteCdts.ksh

Usage

deleteCdts.ksh

Notes

This script is used to delete Consumer Decision Trees (CDTs) from the RCM RPAS domain. The operations performed by this batch script depend on user operations in the Category Management Administration workbook.

In the Category Management Administration workbook/CDT Maintenance step/Delete CDTs view, the user may select CDTs for deletion. This workbook must be committed. Then, run the deleteCdts.ksh script from the UNIX command line. The script works on the domain specified by the $CM_MASTERDOMAIN variable in the $CM_HOME/bin/environment.ksh script.

Running deleteCDTs.ksh from the command line removes CDT information from all measures associated with those CDTs marked for deletion in the view:

The string measures storing the XML representation of the deleted CDT are cleared.
CDTS deleted are not available for selection in the Assortment Planning workbook's wizard train-stop for selecting CDT Version.
Dynamic Hierarchy Dimension levels created from processing the deleted CDT, using Accept XML in the workbook, or using the processcdts.ksh from the command line, are removed from the system.
CDT Editor no longer shows the deleted CDT.
The Delete CDT measure in the Delete CDTs view is cleared.

Before Running Category Management Batch Scripts for the First Time

Before running Category Management batch scripts for the first time, do the following:

Set the following variables:
- RPAS_HOME
- RPAS_JAVA_CLASSPATH
- LD_LIBRARY_PATH (only for Solaris and Linux Operating Systems)
- LIBPATH (only for AIX)
- SHLIB_PATH (only for HP-UX)
- PATH
Update the following variable settings in the file $CM_HOME/bin/environment.ksh to reflect current directory paths and environment:
- CM_HOME
- CM_DOMAINHOME
- CM_MASTERDOMAIN
- CM_CONFIGNAME
- CM_CDTSTORE
- CM_CONFIGHOME
- CM_EXPORT
- CM_INPUTHOME
- CM_LOG_DIR
- CM_TEMP
- CM_BATCH
- RECORDLOGLEVEL
- RPAS_LOG_LEVEL
- RPAS_TODAY
The following syntax allows the script to set a default value for each variable when it is not defined, but leaves the value unchanged if the variable has been previously defined in, for example, the user's .profile:

: ${variable:=value}

The directory $CM_HOME/bin should exist and be added to the PATH variable.

The values for RPAS_LOG_LEVEL and RECORDLOGLEVEL can be any one of the following: all, profile, debug, audit, information, warning, error, or none. These two variables are usually both set to warning or both set to error.
Make sure to include both $RPAS_HOME/bin and $CM_HOME/bin in the PATH variable. Also, add the full directory path containing the Batch Script Architecture scripts to the PATH variable. For more information, see the Oracle Retail Batch Script Architecture Implementation Guide.