7 Java Batch Processes

This chapter discusses Java-based batch processing within RPM.

Java Batch Processes

This section provides the following:

• An overview of RPM's batch processing

• A description of how to run batch processes, along with key parameters

• A functional summary of each batch process, along with its dependencies

• A description of some of the features of the batch processes (such as batch return values)

Java Batch Process Architectural Overview

The goal of much of RPM's Java batch processing is to select business objects from the persisted mechanism (for example, a database) by a certain criteria and then to transform them by their state. These RPM Java-based batch processes remove some of the processing load from the real-time online system and are run periodically.

Note the following characteristics of RPM's batch processes:

• RPM batch processes are run in Java. For the most part, batch processes engage in their own primary processing.

• They are not accessible through a graphical user interface (GUI).

• They are scheduled by the retailer.

• They are designed to process large volumes of data, depending upon the circumstances and process.

• They are not file-based batch processes.

Running RPM Batch Processes

This section describes Java-based and PL/SQL based batch processes.

Java Based Batch Processes

Java batch processes are scheduled through executable shell scripts (.sh files). Oracle Retail provides each of these shell scripts. During the installation process, the batch shell scripts and the .jar files on which they depend are copied to a client-specified directory structure.

Also as part of the installation process, the application user and batch user alias are created and the corresponding credentials are stored inside a wallet. The batch user alias can be the same as the application user ID. RPM batches use the user alias provided at the command line to fetch the password from the wallet and authenticate the user permission before executing the batch. See the Oracle Retail Price Management Installation Guide for details. The batch shell scripts must be run from within the directory structure to which they are copied.

Each script performs the following internally:

• sets up the Java runtime environment before the Java process is run

• triggers the Java batch process

To use the scripts, confirm that the scripts are executable (using ls -l) and run "chmod +x *.sh" if necessary. The shell scripts take at least one argument: userAlias and any extras necessary for the batch. The output can be redirected to a log file (as shown in the following example).

Note: The script launchRpmBatch.sh must be modified to include the correct environment information before any of the batch scripts run correctly.

The following is an example of how to use a batch shell script:

./locationMoveBatch.sh userAlias > log 2>&1

Note: The User Alias and the User ID needs to be same for running RPM batches.

PL/SQL Based Batch Processes

PL/SQL batch processes are scheduled through executable shell scripts (.sh files). Oracle Retail provides each of these shell scripts. During the installation process, the batch shell scripts are copied to a client-specified directory structure. Also as part of the installation process, the database user alias is created and the corresponding credentials are stored inside a wallet. The database user alias can be the same as the application user ID. RPM batches use the user alias provided at the command line to fetch the database connection string from the wallet and authenticate the user as part of any database connections that happen as part of the batch. See the Oracle Retail Price Management Installation Guide for details. The batch shell scripts must be run from within the directory structure to which they are copied.

Additional Notes

• All the output (including errors) is sent to the log file.

• The scripts are meant to run in Bash. They have problems with other shells.

• There is one exception to this rule. When run on a SunOS system, if the batch takes an input parameter of number of concurrent threads should be run at one time (slots), then the batch must be run with a Korn Shell interpreter.

• If the scripts are edited on a Windows computer and then transferred to UNIX, they may have carriage returns (^M) added to the line ends. These carriage returns (^M) cause problems and should be removed.

Scheduler and the Command Line

If the retailer uses a scheduler, arguments are placed into the schedule.

If the retailer does not use a scheduler, arguments must be passed in at the UNIX command line.

The Java batch processes are to be called via the shell scripts. These scripts take any and all arguments that their corresponding batch process would take when executing.

Functional Descriptions and Dependencies

The following table summarizes RPM's batch processes and describes the business functionality of each batch process.

Table 7-1 Functional Descriptions and Dependencies

Batch processes	Details
ClearancePriceChangePublishBatch	This batch process formats and stages output of clearance price change price events to be published via a flat file format.
FutureRetailRollUpBatch.sh	This batch attempts to roll up timelines at a lower level by comparing lower level timelines to higher levels and removing any lower level timelines that match higher level timelines exactly.
InjectorPriceEventBatch	This batch program performs the necessary work to import pricing events (regular price changes, clearance price changes and simple promotions) and optionally submit the events for approval.
ItemLocDeleteBatch	This batch program handles RMS deletions of items and item locations.
itemReclassBatch	When items are moved from one department/class/subclass to another in the merchandising system, this batch process accordingly sets the correct department/class/subclass for these items in the RPM_FUTURE_RETAIL table.
LocationMoveBatch	This batch process moves locations between zones in a zone group.
MerchExtractKickOffBatch	This batch process builds worksheets in RPM. MerchExtractKickOffBatch.java either creates or updates worksheets based on price strategies and the calendars attached to them.
NewItemLocationBatch	This batch ranges item locations by putting them into the future retail table and RPM_ITEM_LOC. Item and locations are fed to this program via the RPM_STAGE_ITEM_LOC table, which is populated by an RMS process.
NightlyBatchCleanup	This batch performs "clean up" logic against certain RPM database structures.
PriceChangeAreaDifferentialBatch	This batch program allows the user to generate and approve Price Changes for selected secondary areas of an Area Differential.
PriceChangeAutoApproveResults PurgeBatch	This batch process deletes old error message from the price change auto approve batch program.
PriceChangePurgeBatch	This batch process deletes past price changes.
PriceChangePurgeWorkspaceBatch	This batch process deletes abandoned price change workspace records.
PriceEventExecutionBatch	This batch process performs the necessary work to start (regular price change, clearance price change, promotions) and end (price clearances, promotions) pricing events.
priceEventExecutionForChunkCC EmergencyEvents	This batch will allow the user to update RMS near real time for emergency price events that are processed through Chunk Conflict Checking.
PriceEventItemListPurgeBatch	This batch deletes records on RPM_MERCH_LIST_HEAD, RPM_MERCH_LIST_DETAIL, and RPM_PEIL_DEPT_CLASS_SUBCLASS where they are no longer linked to a price event.
PriceStrategyCalendarBatch	This batch process maintains calendars assigned to price strategies.
primaryZoneModificationsBatch.sh	This batch updates the future retail tables whenever the primary zone group definition for a merchandise hierarchy is updated, added, or removed so that the future retail tables reflect timelines at the zone level correctly.
ProcessPendingChunkBatch	This batch will attempt to re-process any push back threads that failed during the chunk conflict checking process.
PromotionArchiveBatch	This batch archives promotions that have an end date in the past.
PromotionPriceChangePublishBatch	This batch process formats and stages output of promotion price change price events.
PromotionPurgeBatch	This batch process deletes old and rejected promotions.
purgeBulkConflictCheckArtifacts	This batch program allows you to clean up conflict checking-related working tables in event that there are records left in these tables.
purgeConCheckResultsErrorData.sh	This batch process purges conflict check results and errors that are tied a price event that no longer resides in the system.
PurgeExpiredExecutedOrApprovedClearancesBatch	This batch process deletes expired clearances in Executed or Approved statuses.
PurgeLocationMovesBatch	This batch process cleans up expired/executed location moves
purgeRPMBatchRunHistory	This batch process will truncate partitions from the RPM_BATCH_RUN_HISTORY table based on the system option sets in the BATCH_RUN_HIST_MONTHS column.
purgeTxnExclusionSkulistWS.sh	This batch process will truncate data in the rpm_prom_txn_excl_skulist_ws table.
PurgePayloadsBatch	This batch program purges entries related to price events from the RPM_*PAYLOAD tables.
PurgeUnusedAndAbandoned ClearancesBatch	This batch process deletes unused and rejected clearances.
RegularPriceChangePublishBatch	This batch process formats and stages output of regular price change price events.
RPMtoORPOSPublishBatch	The RPMtoORPOSPublishBatch program formats and stages output of different price events like PriceChange, Clearance, and Promotions.
RPMtoORPOSPublishExport	The RPMtoORPOSPublishExport program calls the SQL script, RPMtoORPOSSpoolMsg.sql. This script spools the data collected from the publish tables of price events (Price Change, Clearance, and Promotion). TheRPMtoORPOSPublishExport program also may call the RPMtoORPOSSpoolCP.sql script, based on an input parameter and the RPMtoORPOSSpoolMsg.sql script.
stagePromosForExtDashboard	The stagePromosForExtDashboard program will retrieve item location information that are on valid promotion from the RPM promotion table into a staging table.
statusPageCommandLine Application	The status page batch program (statusPageCommandLineApplication.sh) performs some data checks, to verify that some of the assumptions that the application makes about the data are not violated.
TaskPurgeBatch	The TaskPurgeBatch purges the entries from RPM_*TASK tables based on the entered purge days and the status indicator.
WorksheetAutoApproveBatch	This batch process approves worksheets that have not been acted upon by the end of the review period. The strategies must be marked as auto-approve in order to be processed.
ZoneFutureRetailPurgeBatch	This batch process deletes past zone/item price change actions.

Batch Process Scheduling

Before setting up an RPM process schedule, familiarize yourself with Batch Schedule document published in conjunction with this release.

Threading and the RPM_BATCH_CONTROL Table

Some RPM batch processes use the RPM_BATCH_CONTROL table, which is a database administrator (DBA) maintained table and is populated by the retailer. This table defines the following:

• The batch process that is to be threaded.

  The number of threads that should be run at a time.

  How much data each thread should process (for example, 2 strategies per thread, 500 item/location/price changes by thread, and so on).

  Each batch design later in this chapter states the following in its Threading section.

• Whether the batch process utilizes the RPM_BATCH_CONTROL table.

  Whether or not the batch process is threaded.

  How the batch process is threaded (by strategy, by department, and so on).

Return Value Batch Standards

All batch processes in RPM conform to the Oracle Retail batch standards. They are executed and terminated in the same manner as other batch processes in the Oracle Retail suite of products. The following guidelines describe the return values that RPM's batch processes utilize.

Return Values

0 – The function completed without error.

1 – A fatal error occurred. The error messages are logged, and the process is halted.

Batch Logging

Relevant progress messages are logged with regard to batch program runtime information. The setting for these log messages is at the Info level in log4j.

For more information, see Chapter 2, "Backend System Administration and Configuration".

Batch Run History Logging

All batch processes in RPM will maintain a history of batch runs. This information is stored in the table RPM_BATCH_RUN_HISTORY. RPM Batch process will call an autonomous transaction function to insert this information into the history table without impacting any other transactional data. The function will return a value of 1 for success or 0 for failure.

Note: Two RPM batches do not have the batch run logging history:- RPMtoORPOSPublishBatch.sh- RPMtoORPOSPublishExport.sh

ClearancePriceChangePublishBatch Batch Design

The ClearancePriceChangePublishBatch program formats and stages output of clearance price change price events.

The corresponding clearancePriceChangePublishExport shell script produces a pipe ("|") delimited flat-file export based on the output of the ClearancePriceChangePublishBatch.

Usage

The following command runs the ClearancePriceChangePublishBatch job:

ClearancePriceChangePublishBatch.sh userAlias

The following command runs the clearancePriceChangePublishExport job:

clearancePriceChangePublishExport.sh </@tnsaliasname> <slots> <log_path> <error_path> [export_path(optional)]

Where the first argument is the database connect alias (/@tnsaliasname), the second argument is to indicate the maximum number of concurrent threads should run at a time, the third and fourth argument are the path where the log file and error file should be written, and the last argument, the export_path is optional; if not supplied, the path ../output is used.

Detail

The batch looks for price events in the RPM_PRICE_EVENT_PAYLOAD table with a RIB_FAMILY of CLRPRCCHG and distributes those events to multiple threads based on the settings in the RPM_BATCH_CONTROL table. Each thread reads in its set of clearance price change events from tables RPM_PRICE_EVENT_PAYLOAD and RPM_CLEARANCE_PAYLOAD and generates output in RPM_PRICE_PUBLISH_DATA. After the flat file is successfully generated by the Export script (see the following format), the associated records in the payload tables are deleted.

PurgePayloadsBatch should be run to delete records in the payload tables.

A flat-file per location based on the data from payload table that need to be published/processed will be created. The naming convention for the flat file will be (CLRPC_<timestamp>_<location>_<loc_type>.dat), where <timestamp> is the current system time stamp, <location> is the location id and <loc_type> is the type of the location where 'S' is for Store and 'W' is for Warehouse.

Output File

FHEAD – REQUIRED: File identification, one line per file.

FDETL – OPTIONAL: Price Change Event (Create or Modify).

FDELE – OPTIONAL: Price Change Event (Delete).

FTAIL – REQUIRED: End of file marker, one line per file.

Output File Layout

Table 7-2 Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
FHEAD	Record Descriptor	Char(5)	FHEAD	File head marker
	Line id	Number(10)	1	Unique line identification
	File Type	Char(5)	CLRPC	Clearance Price Changes
	Export timestamp	Timestamp		System clock timestamp (YYYYMMDDHHMISS)
	Location	Number(10)		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
FDETL	Record Descriptor	Char(5)	FDETL	File Detail Marker (1 per clearance create or modify)
	Line id	Number(10)		Unique line identification
	Event Type	Char(3)		CRE = Create, MOD = Modify
	Id	Number(15)		Clearance identifier
	Item	Char(25)		Item identifier
	Effective Date	Date		Clearance Effective Date (YYYYMMDDHH24MISS)
	Selling Retail	Number(20,4)		Selling retail with price change applied
	Selling Retail UOM	Char(4)		Selling retail unit of measure
	Selling Retail Currency	Char(3)		Selling retail currency
	Reset Clearance Id	Number(15)		Clearance reset identification
FDELE	Record Descriptor	Char(5)	FDELE	File Detail Delete Marker (1 per clearance delete)
	Line id	Number(10)		Unique line identification
	Id	Number(15)		Clearance identifier
	Item	Char(25)		Item identifier
FTAIL	Record Descriptor	Char(5)	FTAIL	File tail marker
	Line id	Number(10)		Unique line identification
	Number of lines	Number(10)		Number of lines in file not counting FHEAD and FTAIL

Assumptions and Scheduling Notes

ClearancePriceChangePublishBatch should be run after the WorksheetAutoApproveBatch.

ClearancePriceChangePublishExport should be executed as follows:

• After every successful run of ClearancePriceChangePublishBatch.

• BeforePurgePayloadsBatch.

Primary Tables Involved

• RPM_PRICE_EVENT_PAYLOAD

• RPM_CLEARANCE_PAYLOAD

Threading

The ClearancePriceChangePublishBatch program is threaded. The LUW is a single clearance price change event.

Configuration

The following property must be set in rpm.properties on the application server when using this batch program to publish clearance price events:

delete_staged_rib_payloads=false

FutureRetailRollUpBatch Design

This batch attempts to roll up timelines at a lower level by comparing lower level timelines to higher levels and removing any lower level timelines that match higher level timelines exactly.

Usage

Use the following command to run the job:

futureRetailRollUpBatch.sh userAlias

Where userAlias is a required argument. It represents the alias tied to a valid RPM user as stored in wallets.

Details

The batch calls the package RPM_ROLLUP.THREAD_ROLLUP_FR and RPM_ROLLUP. ROLL_FUTURE_RETAIL. This package attempts to roll up lower level timelines to existing higher level timelines (for example, from Item/Location to Parent/Zone) by comparing two related timelines and removing the lower level timelines if the two match exactly for all records.

Assumptions and Scheduling Notes

This process must be executed during the batch window. As it runs, other processes must not access the future retail tables. This batch can be run ad-hoc.

Primary Tables Involved

• RPM_FUTURE_RETAIL

• RPM_PROMO_ITEM_LOC_EXPL

• RPM_CUST_SEGMENT_PROMO_FR

Threading

The FutureRetailRollUpBatch program is threaded by item.

InjectorPriceEventBatch Batch Design

The Injector Price Event Batch (InjectorPriceEventBatch.java) performs the necessary work to import pricing events (Price Changes, Clearance, Clearance Reset, and Promotion) and optionally submit the events for approval.

Usage

Use the following command to run the job:

InjectorPriceEventBatch.sh userAlias [status=status_value] [event_type=event_type_

value] [polling_interval=polling_interval_value]

Where:

• userAlias is a required argument. It represents the alias tied to a valid RPM user as stored in wallets.

• status_value is an optional argument. It defines the status for the imported data to process. Valid options are N (New), A (Approve), E (Error), W (Worksheet) or F (Failure). The default is N (New).

• event_type_value is an optional argument. It defines the type of pricing event to process. Valid options are PC (Price Change), CL (Clearance), NR (New Clearance Reset), SP (Simple Promo), TP(Threshold Promo), FP(Finance Promo), CP(Complex/Multibuy Promo) or TXN(Transaction Promo). The default is PC (price change).

• polling_interval_value is an optional argument. It defines the interval in seconds for the batch to verify if conflict checking is complete. Valid values for the interval are 1 to 1000. The default is 10 seconds.

UserAlias should be first in the list of arguments; all other optional arguments may follow in any order.

Except for userAlias, the argument identifier should precede each optional argument (for example, event_type=PC).

The following are examples of how applying specific combinations of arguments affects the output of the InjectorPriceEventBatch job:

• Where only user alias is defined by the user

  Arguments:

  InjectorPriceEventBatch retailUser

  Results: The batch processes price changes from the staging table in New status, checking the approval process for completion every 10 seconds.

• Where all arguments are defined by the user

  Arguments:

  InjectorPriceEventBatch retailUser status=W event_type=CL polling_interval=300

  Results: The batch processes clearances from the staging table in Worksheet status, checking the approval process for completion every 5 minutes (300 seconds).

Additional Notes

The batch should be run through the shell script injectorPriceEventBatch.sh.

Details

The batch program imports price events that have been generated by an external system into the RPM application, those includes regular price changes, clearances, new clearance resets, simple promotions, threshold promotion, complex/multi-buy promotion, transaction promotion and finance promotion.

The batch does not make any assumptions about the source of the price event data. The only requirement for the data is to adhere to the predefined importing data format. The contract on the incoming data is defined by the structure of the staging tables the batch depends on. The staging tables work as the interface point between RPM and the external system providing the data. All the necessary data transformation possibly required to accommodate RPM price event data requirements should be done before populating the staging tables and is a client responsibility.

Importing Staged Price Changes

Staged price change data should be placed by the system administrator into RPM_STAGE_PRICE_CHANGE table. The table has a structure similar to that of RPM_PRICE_CHANGE but with the following limitations:

• No price change exceptions are allowed.

• No parent exceptions are allowed.

Importing Staged Clearances

Staged clearance data should be placed by the system data administrator into RPM_STAGE_CLEARANCE table. The table has a structure similar to that of RPM_CLEARANCE but with the following limitations:

• No clearance exceptions are allowed.

Importing Staged New Clearance Reset Data

Staged new clearance reset data should be placed by the system data administrator into RPM_STAGE_CLEARANCE_RESET table. The table has a structure similar to that of RPM_CLEARANCE_RESET but with the limitations that it can only process one single effective date per run.

Importing Staged Simple Promotions

Staged simple promo data should be placed by the system data administrator into RPM_STAGE_SIMPLE_PROMO table. The table has the structure similar to RPM_PROMO, RPM_PROMO_COMP and RPM_PROMO_DTL rolled into one, but with the limitation that no exceptions are allowed.

Importing Staged Threshold Promotions

Staged threshold promo data should be placed by the system data administrator into RPM_STAGE_THRESHOLD table. The table has the structure similar to RPM_PROMO, RPM_PROMO_COMP and RPM_PROMO_DTL rolled into one, but with the limitation that no exceptions are allowed.

Importing Staged Multi-Buy/Complex Promotions

Staged Multi-Buy promo data should be placed by the system data administrator into RPM_STAGE_MULTIBUY_HEADER, RPM_STAGE_MULTIBUY_BUYLIST, and RPM_STAGE_MULTIBUY_RWDLIST tables. The header table has the structure similar to RPM_PROMO, RPM_PROMO_COMP and RPM_PROMO_DTL rolled into one, but with the limitation that no exceptions are allowed. The other two tables have the structure to hold the Buy List and Reward List information.

Importing Staged Finance Promotions

Staged Finance promo data should be placed by the system data administrator into RPM_STAGE_FINANCE_PROMO table. The table has the structure similar to RPM_PROMO, RPM_PROMO_COMP and RPM_PROMO_DTL rolled into one, but with the limitation that no exceptions are allowed.

Importing Staged Transaction Promotions

Staged Transaction promo data should be placed by the system data administrator into RPM_STAGE_TRAN_PROMO_HEADER, RPM_STAGE_TRAN_PROMO_BUYLIST and RPM_STAGE_TRAN_PROMO_RWDLIST tables. The header table has the structure similar to RPM_PROMO, RPM_PROMO_COMP and RPM_PROMO_DTL rolled into one, but with the limitation that no exceptions are allowed. The other two tables have the structure to hold the Buy List and Reward List information.

The staged price event data can be staged at the location, zone or zone group levels. If staged at location or zone level, that data will be directly used for creating a price event. If zone group is used for the staged data, an initial step in the batch process will explode that zone group into multiple staged records at the zone level - one for each zone in the zone group for staged price change, clearance, new clearance reset, simple promotion and threshold promotion data. For Multi-Buy/Complex, Transaction and Finance promotion data staged at the zone group level, the associated promotion detail will be created using all zones from the zone group provided, resulting in a single promotion detail impacting multiple zones.

Other than the fields carrying price event data, the stage tables (parent only tables where there is parent/child relationship in place) hold fields that facilitate data processing.

• Status defines the current state of the data in the staging table. The status should not be confused with the status of the price event in RPM, even though there are some correlations. Possible statuses are N (New), W (Worksheet), A (Approved), E(Error), F (Failed) and X (eXploded). Initial data should be created in the New status. The rest of the statuses are the result of data lifecycle.

  • New status indicates the data has not been processed yet.

  • Worksheet status indicates the data has been processed and been successfully imported into RPM. It also indicates that at the time of import, approval was not required.

  • Error status indicates the data has been processed, but the import has failed due to invalid data. The data administrator can correct the data, and processing can be retried.

  • Failed status indicates the data has been successfully imported, but some conflicts have been encountered. The data administrator can correct the data (for example, by changing the effective date of the event to eliminate the conflict), and processing can be retried.

  • Exploded status indicates the record is for a zone group and was exploded to one or more zone level staged records.

  • Approved status indicates the data has been successfully imported and successfully approved without any conflict.

• Auto approve indicator defines whether the processing batch should attempt to approve the price event after successfully importing the data.

• Thread Num is the thread number the record is processed in by the batch.

• The error message field indicates the first error encountered while importing data. The field actually holds an error message key rather than the actual error message. When a conflict is encountered during an approval attempt, the field holds the CONFLICT_EXISTS key

• Process ID uniquely identifies the batch run. The field is populated for records with all statuses except New.

• ID (for example, price change display id, clearance display id, promo display id, promo_id) is populated only upon successful import of the data once all processing is complete.

• Exclusion Created indicates if a System Generated Exclusion (SGE) was created while approving the price change.

• The batch will only process Threshold, Finance, Complex (Multi-Buy) and transaction promotion if the system option for ALLOW_COMPLEX_PROMOS_IND is set to 1 or it will fail and stop processing.

Main Steps Taken by the Batch

The batch will first assign a process id value to all records to be processed by that run of batch based on the input status of records to process. With a process id in hand, the system is then able to call the previously existing hook for custom processing of staged data for the ”pre processing” requirements that a client might have. The system will also look for data staged at the zone group level and do all necessary explosions of zone group data depending upon price event type.

The processing will then move on to the initialization of threads where each record is assigned a thread number and event ids. At this point in the processing, the system also updates all records being processed to what the end status of the record should be from injector validation alone. It also validate promotion header and component creation data along with the custom attributes data if there is any and with the validation of vendor funding data for any new deals to be created. The system will also call any custom validation process for custom attributes data if there is one setup in the system.

The batch validates the data based on RPM validity rules. If at least a single field for a record is not valid, the record is rejected. The first encountered error is reported (ERROR_MESSAGE column in the staging table is populated), and the status is set to 'E'rror. The records with multiple incorrect data fields would need to be processed multiple times unless corrected by the data administrator all at once. If no pricing events have been generated the batch terminates at this stage. All records in the staging table that match the run argument criteria are processed at once. At the same time all records are independent in that data errors encountered on one record do not impact processing of other records. If any record fails validation, the status is updated to reflect that situation and at the end of the processing, nothing is updated to a status that is incorrect.

With thread numbers assigned, the system is able to find the total count of threads to provide back to the application server along with validation the data at a detail level. After each thread has validated event level data, the system will then move on gather counts of data processed for the end of processing reporting that is output to the console. It will also call the previously existing hook for custom processing of staged data for the ”post processing” requirements that a client might have along with cleaning up promotion data that was optimistically created at the start of the batch but is not utilized due to validation errors at the detail level.

If at least a single pricing event is generated, the batch proceeds with an optional approval step. For the batch to attempt the approval on a record, the data administrator should set the auto approval flag to ON (AUTO_APPROVE_IND should be set to 1). In this case, the batch attempts to approve the price event which involves conflict checking. For any events that are to be processed through conflict checking, the system will stage data for the initialization of conflict checking and then move into the conflict checking realm of RPM. Once all conflict checking has completed, the system will update the status of staged records based on the outcome of conflict checking and complete all processing.

The final step for the batch process is to generate a report. The report gives the system administrator statistics on the batch run. The following information is provided:

• The initial status in which the batch was processed

• Event type

• Number of records imported

• Number of records requiring approval

• Number of records successfully approved

• Number of records failed approval

Assumptions and Scheduling Notes

• It is assumed that a single instance of the batch is running at a time so a single event type is processed at a time.

• Approved pricing events on the staging tables can only be reprocess for un-approval. See the section, "InjectorPriceEventBatch Batch—Rollback and Reprocessing".

Primary Tables Involved

• RPM_STAGE_PRICE_CHANGE

• RPM_STAGE_CLEARANCE

• RPM_STAGE_CLEARANCE_RESET

• RPM_STAGE_SIMPLE_PROMO

• RPM_STAGE_THRESHOLD_PROMO

• RPM_STAGE_COMP_THRESH_LINK

• RPM_STAGE_FINANCE_PROMO

• RPM_STAGE_FIN_CRED_DTL

• RPM_STAGE_FIN_THRESH_DTL

• RPM_STAGE_MULTIBUY_HEADER

• RPM_STAGE_MULTIBUY_BUYLIST

• RPM_STAGE_MULTIBUY_RWDLIST

• RPM_STAGE_TRAN_PROMO_HEADER

• RPM_STAGE_TRAN_PROMO_BUYLIST

• RPM_STAGE_TRAN_PROMO_RWDLIST

• RPM_STAGE_PC_CUST_ATTR

• RPM_STAGE_CLR_CUST_ATTR

• RPM_STAGE_PROM_CUST_ATTR

• RPM_STAGE_PROM_COMP_CUST_ATTR

• RPM_STAGE_PROM_DTL_CUST_ATTR

• RPM_PROMO

• RPM_PROMO_COMP

• RPM_PROMO_DTL

• RPM_PROMO_DTL_LIST_GRP

• RPM_PROMO_DTL_LIST

• RPM_PROMO_DTL_MERCH_NODE

• RPM_PROMO_DTL_DISC_LADDER

• RPM_PROMO_ZONE_LOCATION

• RPM_PRICE_CHANGE

• RPM_CLEARANCE

• RPM_CLEARANCE_RESET

• RPM_PENDING_DEAL

• RPM_PENDING_DEAL_DETAIL

• DEAL_COMP_PROM

• RPM_PRICE_CHANGE_CUST_ATTR

• RPM_CLEARANCE_CUST_ATTR

• RPM_PROMO_CUST_ATTR

• RPM_PROMO_COMP_CUST_ATTR

• RPM_PROMO_DTL_CUST_ATTR

Threading

The injector batch utilizes threading of the event level validation and creation. The logical unit of work for each thread is determined by a record on the RPM_BATCH_CONTROL table. This record also determines the maximum number of concurrent threads that should be executing at a time. This LUW and number of threads are entirely separate from the LUW and number of threads for conflict checking – no correlation exists between the two.

In addition to threading of the event level validation and creation, there are two functions in the injector PLSQL package body that utilize parallel hints. There are several SQL statements in each function with this hint in place. Out of the box, the degree of parallelism is set to four. Clients should consider modifying these hints to reflect a degree of parallelism that is appropriate for the environment hardware that they have in place.

InjectorPriceEventBatch Batch—Rollback and Reprocessing

If there is a mistake (such as a wrong date or retail) in the data file and bulk numbers of price events are created with the data, it is necessary to roll back all data to reprocess the file with the correct values.

The following are the steps to change a price change or clearance and promotion from Approved to Worksheet status:

1. To set the approved events back to Worksheet status, leave/create the data in the appropriate staging table as done for an initial run of the batch to create price events. Run the price injector batch with a status parameter of A so that all of the price events with a status of A are processed for un-approval. The parameter sets the price event back to Worksheet status.

2. Verify that the price events are set back to Worksheet status in the staging table and the user interface.

ItemLocDeleteBatch Batch

The ItemLocDeleteBatch program handles RMS deletions of items and item locations. When RMS deletes an item or an item location, RPM removes the Item/Location rows from the RPM_FUTURE_RETAIL table so that pricing events are no longer published out of RPM for that data set. RPM will also remove any data that's specific to items and item/locations deleted from RMS in price event tables. This batch will also remove records from the RPM_ITEM_LOC table when an item/location relationship is removed.

The RPM_STAGE_DELETED_ITEM_LOC table is populated by the trigger RMS_TABLE_RPM_ITL_AIR in RMS.

Usage

The following command runs the ItemLocDeleteBatch job:

ItemLocDeleteBatch.sh userAlias

The argument is the user ID.

Follow these steps to use this batch:

1. Delete existing records from the table RPM_STAGE_DELETED_ITEM_LOC.

2. Enable the new trigger RMS_TABLE_RPM_ITL_AIR on table ITEM_LOC.

3. Run the new batch (ItemLocDeleteBatch.sh) one time to process any records remaining in the RPM_STAGE_DELETED_ITEM_LOC table.

Scheduling Notes

This batch can be run ad hoc.

itemReclassBatch Batch Design

When items are moved from one department/class/subclass to another in the merchandising system, this batch process accordingly sets the correct department/class/subclass for these items in the RPM_FUTURE_RETAIL table and the RPM_ITEM_LOC table if the item has move departments.

Usage

The following command runs the ItemReclassBatch job:

ItemReclassBatch.sh userAlias

Where the argument is the user ID.

Detail

The batch calls the package RPM_ITEM_RECLASS_SQL.RECLASS_FUTURE_RETAIL. This package looks for items in the RPM_ITEM_MODIFICATION table and updates the table RPM_FUTURE_RETAIL and RPM_ITEM_LOC with the new department/class/subclass. The package then subsequently deletes all the records in the RPM_ITEM_MODIFICATION table.

Assumptions and Scheduling Notes

The RPM_ITEM_MODIFICATION table must have been already populated with the reclassed items by the ItemModification injector.

Primary Tables Involved

• RPM_ITEM_MODIFICATION

• RPM_FUTURE_RETAIL

Threading

The itemReclassBatch program is not threaded.

PL/SQL Interface Point

Package: RPM_ITEM_RECLASS

LocationMoveBatch Batch Design

The LocationMoveBatch program moves locations between zones in a zone group.

Usage

The following command runs the LocationMoveBatch job:

LocationMoveBatch.sh userAlias[max_retry]

Where the first argument is the userAlias. UserAlias is a required argument. The second argument (max_retry) is optional and specifies the maximum retry count for the batch when running in Restart mode.

Detail

The batch looks for scheduled location moves and updates the zone structure tables with the new zone structure.

• Remove the location from the old zone.

• Add the location to the new zone.

Update RPM_FUTURE_RETAIL table to reflect the location move.

• Price events (standard price change, clearance price change, promotion) scheduled for item/locations affected by the move at the old zone level are removed from RPM_FUTURE_RETAIL.

• Price events (standard price change, clearance price change, promotion) scheduled for item/locations affected by the move at the new zone are added to RPM_FUTURE_RETAIL.

• Conflict checking is run on RPM_FUTURE_RETAIL after events from the old zone are removed and events from the new zone are added. If conflicts are encountered during conflict checking, exceptions/exclusions are pulled off the conflicting event.

Report any exceptions/exclusions that were created during the RPM_FUTURE_RETAIL update process. Changes made are held on:

• RPM_LOC_MOVE_PRC_CHNG_EX

• RPM_LOC_MOVE_CLEARANCE_EX

• RPM_LOC_MOVE_PROMO_COMP_DTL_EX

Update the status of the location move to Executed.

If errors occur during processing, the Location Move Batch finishes and logs the errors to the RPM_LOCATION_MOVE_ERROR table. Users can use this table to ascertain the source of the problems, correct them, and then start the Location Move batch Restart mode. The batch running in Restart mode attempts to apply the price events for the location move to FUTURE_RETAIL.

To start the batch in Restart mode, an additional parameter (second parameter) must be passed into the batch program indicating the maximum number of retries. If this parameter is set, then the batch is driven off of the RPM_LOCATION_MOVE_ERROR table for records that have less retry attempts than the maximum number of retries flag (RETRY_NUMBER). If there is still an error in processing in Restart mode, the error record is updated and the RETRY_NUMBER is incremented.

Assumptions and Scheduling Notes

LocationMoveBatch must run before the following programs:

• PriceEventExecutionBatch

• MerchExtractKickOffBatch

Primary Tables Involved

RPM_FUTURE_RETAIL

Threading

The LocationMoveBatch program is threaded. Each location move request is given its own thread.

LocationMoveScheduleBatch Batch Design

The LocationMoveScheduleBatch program schedules location moves between zones in a zone group.

Usage

The following command runs the LocationMoveScheduleBatch job:

LocationMoveScheduleBatch.sh userAlias

Detail

The batch finds and processes all approved location moves.

Verify the following hard-stop conditions before processing each location move:

• The move date cannot be less than today plus Location Move Lead Time.

• The currency for the old zone and new zone must be the same.

• Zone level promotions cannot overlap, unless allowed by the current system option settings.

• There can be no existing location move request in scheduled state for the same location.

• Worksheet review periods cannot overlap, unless allowed by the current system option settings.

Update the RPM_FUTURE_RETAIL table to reflect the location move:

• Price events scheduled for item/locations affected by the move at the old zone level are removed from RPM_FUTURE_RETAIL.

• Conflict checking is run on RPM_FUTURE_RETAIL after events from the old zone are removed. If conflicts are encountered during conflict checking, the location move will fail and no further processing will occur for this location move.

Update the status of the location move to Scheduled.

Resolve overlapping promotions according to the current system option settings:

• Overlapping promotions are updated with appropriate exceptions/exclusions according to the current system option settings for overlapping promotions.

• Conflict checking is run on RPM_FUTURE_RETAIL to approve the updates to overlapping promotions. If conflicts are encountered during conflict checking, the location remains in Scheduled status, but the promotion exceptions/exclusions that failed conflict checking are recorded in RPM_LOC_MOVE_PROMO_COMP_DTL_EX.

Assumptions and Scheduling Notes

LocationMoveScheduleBatch must be run before LocationMoveBatch.

Primary (RPM) Tables Involved

• RPM_FUTURE_RETAIL

• RPM_LOCATION_MOVE

Threading

The LocationMoveScheduleBatch program is threaded. Each location move request is given its own thread.

MerchExtractKickOffBatch Batch Design

The MerchExtractKickOffBatch.java batch program builds worksheets in RPM. MerchExtractKickOffBatch.java either creates or updates worksheets based on price strategies and the calendars attached to them.

Usage

The following command runs the MerchExtractKickOffBatch job:

MerchExtractKickOffBatch.sh userAlias [mode]

Where userAlias is the user ID. The optional mode argument can be used to split the processing into three components: pre-process, process, and post-process. The valid values for the mode argument are PRE, PROCESS, POST, and ALL. ALL is the default value for the mode argument when no value is provided.

The program is split into sections for performance and functional reasons. The population of the RPM_PRE_ME tables in the setup section allows access to the largest RMS tables in the most efficient manner. The splitting of the worksheet creation section ensures that a worksheet is not reprocessed in the case of a failure in a different worksheet. The splitting of a post process helps to avoid locking issues.

Detail

Setup: (included in modes: ALL and PRE) clean up expired worksheets and prepare for creation of new worksheets.

• Delete worksheets that are at the end of their review period.

• Get list of all strategies that need to be processed today. Create copies of the strategies as needed.

• Determine what strategies need to be grouped together based on the RPM_DEPT_AGGREGATION. WORKSHEET_LEVEL.

• Stage data in RPM_PRE_ME_AGGREGATION, RPM_PRE_ME_ITEM_LOC, RPM_PRE_ME_COST, and RPM_PRE_ME_RETAIL. This is done for performance reasons. This allows the program to access large tables in an efficient as possible manner.

Worksheet Creation: (included in modes: ALL and PROCESS).

• Start threads based on the values in RPM_BATCH_CONTRL for MerchExtractKickOffBatch.java.

• Call RPM_EXT_SQL, a PL/SQL package, to extract RPM information. The package is called at the strategy and RPM_DEPT_AGGREGATION. WORKSHEET_LEVEL level. It pulls large amounts of data from various RMS tables and populates the RPM_WORKSHEET_ITEM_DATA, RPM_WORKSHEET_ITEM_LOC_DATA, and RPM_WORKSHEET_ZONE_DATA tables. The RPM_MERCH_EXTRACT_CONFIG table is used to exclude certain families of data from being included in the population. If this table is not populated, all values are included in the population of the RPM_WORKSHEET_ITEM_DATA, RPM_WORKSHEET_ITEM_LOC_DATA, and RPM_WORKSHEET_ZONE_DATA tables.

• For each worksheet detail record created, perform the following:

  • Use the price strategy to propose a retail value.

  • Apply candidate rules.

  • Apply price guides.

The following are potential reasons why item/locations are not included in a worksheet:

• The item/location falls under an exclusion type candidate rule.

• The item/location does not have a cost on the RMS FUTURE_COST table.

• The item's market basket codes vary across locations in a zone.

• The item's link code varies across locations in a zone.

• If a link code is identified on an item/location, and there is any item within that link code (at that location) that has not been brought into the worksheet, all of the item/locations with that link code are excluded from the worksheet.

• The item's selling unit of measure varies across locations in a zone.

• The item is part of an area differential item exclusion.

• Item/locations in a single link code have varying selling unit of measures.

If an item does not make it into a worksheet, a row is inserted into the RPM_MERCH_EXTRACT_DELETIONS table for each item location along with a reason that the item location was not included in the worksheet.

Post process: (included in modes: ALL and POST)

• Update the COMP_PRICE_HIST table. This logic needs to be in a post process to avoid locking issues as multiple threads can share competitive pricing information.

Assumptions and Scheduling Notes

The following programs must run before MerchExtractKickOffBatch.sh:

• PriceStrategyCalendarBatch

• LocationMoveBatch

Primary (RPM) Tables Involved

• RPM_WORKSHEET_STATUS

• RPM_WORKSHEET_ITEM_DATA

• RPM_WORKSHEET_ITEM_LOC_DATA

• RPM_WORKSHEET_ZONE_DATA

• RPM_STRATEGY

  • RPM_STRATEGY_CLEARANCE

  • RPM_STRATEGY_CLEARANCE_MKDN

  • RPM_STRATEGY_COMPETITIVE

  • RPM_STRATEGY_DETAIL

  • RPM_STRATEGY_MARGIN

  • RPM_STRATEGY_REF_COMP

  • RPM_STRATEGY_WH

• RPM_AREA_DIFF

  • RPM_AREA_DIFF_EXCLUDE

  • RPM_AREA_DIFF_PRIM

  • RPM_AREA_DIFF_WH

• RPM_CALENDAR

  • RPM_CALENDAR_PERIOD

• RPM_CANDIDATE_RULE

  • RPM_CONDITION

  • RPM_VARIABLE

  • RPM_VARIABLE_DEPT_LINK

• RPM_PRICE_GUIDE

  • RPM_PRICE_GUIDE_DEPT

  • RPM_PRICE_GUIDE_INTERVAL

Threading

MerchExtractKickOffBatch.java is threaded. The RPM_BATCH_CONTROL table must include a record for MerchExtractKickOffBatch.java for it to run in threaded mode. MerchExtractKickOffBatch.java is threaded by strategies and the RPM_DEPT_AGGREGATION.WORKSHEET_LEVEL setting.

PL/SQL Interface Point

Package: RPM_EXT_SQL

NewItemLocBatch Batch Design

The NewItemLocBatch program ranges item locations by putting them into the future retail table. Item locations are fed to this program via the RPM_STAGE_ITEM_LOC table, which is populated by an RMS process.

Usage

The following command runs the NewItemLocBatch job:

NewItemLocBatch.sh user Alias [status] [error commit count/process id] Where:

• userAlias is a required argument. It represents the alias tied to a valid RPM user as stored in wallets.

• The 'status' argument is optional and directs the application as to what "status" to process. If it's not specified, the batch will default it to 'N'ew mode. The last argument can be optional or required depending upon the status argument as describe in the section below.

Valid values for the status argument are:

• 'N'ew

  This will process records with status of N (New) from the staging table. When the batch is run in this mode, the last argument is not needed.

• 'E'rror

  This will process records with status of E (Error) from the staging table. When the batch is run in this mode, the batch can have the error commit count argument as an optional argument.

  
  

  Note: Error commit count is optional and is used only when the status argument is 'E'. If not specified, the batch will use the logical unit of work for processing

  
  

• 'R'estart

  When the batch is run in this mode, then the process_id argument is required. This mode will only restart the rolling up functionality that is part of location move. It will call the RPM_NEW_ITEM_LOC_SQL.COMPLETE_PROCESSING for the threads that have been identified as failed. A required valid process ID parameter will also need to be passed in as well to indicate what process ID the batch should restart.

  
  

  Note: process id argument is required and is only used when the status argument is 'R'estart.

  
  

To use the batch, follow these steps.

1. Delete existing records from table RPM_STAGE_ITEM_LOC

2. Enable the new trigger RMS_TABLE_RPM_ITL_AIUDR in table ITEM_LOC.

3. Run the batch (NewItemLocBatch.sh) one time to process any records remaining in RPM_STAGE_ITEM_LOC.

Detail

The batch selects rows from the stage table and updates the RPM_FUTURE_RETAIL table to reflect the new item/location combination. If any approved price changes/promotions/clearances exist that encompasses the new item/location, these are also added to the RPM_FUTURE_RETAIL table for the new item/location.

Any active clearance events or promotions that encompass the new item/location are also added to the RPM_FUTURE_RETAIL table for the new item/location.

This batch also creates records on the RPM_ITEM_LOC table for all transaction level items and each location that they are ranged to as these item/locations come into the RPM system.

The batch initially creates all timelines at the transaction item and location level and applies all future/current price events that the item/location should inherit. Then the batch executes logic to generate timelines at levels above the item/location. Following that, the batch executes logic that attempts to roll up lower level timelines to the higher levels generated.

If an item/location timeline is being added under an existing higher level timeline (for example, a new location is ranged to a parent item, and the location is part of the primary zone group for that parent item), the batch process generates only the transaction item and location level timelines for all children under the parent and location that was added. The batch will not execute any logic that generates higher level timelines, nor will it attempt to roll up any lower level timelines for this data, but will resolve any timelines that are needed due to newly created intersections.

Assumptions and Scheduling Notes

This batch may be run ad-hoc but cannot have more than one instances running at the same time in different modes. However, it should be noted that the item/locations to be processed only inherit pricing events that are approved (or active) at the time of the run.

Primary Tables Involved

• RPM_STAGE_ITEM_LOC

• RPM_STAGE_ITEM_LOC_CLEAN

• RPM_FUTURE_RETAIL

• RPM_ITEM_LOC

• RPM_NIL_COMPROC_THREAD_STATUS

• RPM_NIL_BULKCCPE_PROCESS_ID

Threading

The NewItemLocBatch is threaded by related item-locations where "related" means transaction items under a single parent items and locations within a zone that is part of a primary zone group. Additionally, if there are price events to inherit, normal bulk or chunk conflict checking threading is utilized.

If there are price events, then it chooses a path based on batch control settings similar to the ones for a price event approval from UI, and it chooses to go to chunking or bulking based on setting and the volume of data.

Bulk Conflict Checking

This program utilizes the bulk conflict checking framework inside of RPM. Each thread that is spawned by the RPM batch threading framework (threaded by item/loc) may spawn other threads (by pricing events) during its processing. See Chapter 4, ”Conflict Checking,” for more details.

Processing Stage Rows in Error Status

This program is set up to re-process (re-attempt) rows that end up in error status. In the event that an error occurs during the processing of new status rows, the program should update the status on the stage table with E along with an error message.Once the error has been fixed, you can re-run this program with status E in an attempt to get the item/loc into RPM.

Processing Stage Rows in Restart Status

When running in Restart mode, the batch will attempt to re-process the future retail roll up functionality and to clean up item location staging tables. It will delete the records that were completely processed from the staging tables.

This mode has to be executed when there are threads/process ID that have errors or did not complete the roll-up process and clean-up of staging tables. This should be part of the business process. For example, clients can do this ad-hoc when no one is using the application. They also have to establish how they are going to retrieve process id and threads that need reprocessing. If there won't be an established process for running NIL Batch in restart mode, the NIL thread status and staging tables data will increase and won't be cleaned up.

NightlyBatchCleanup Batch Design

The nightlyBatchCleanup batch program performs "clean up" logic against certain RPM Database structures.

Usage

The following command runs the nightlyBatchCleanup job:

nightlyBatchCleanup.sh </@tnsaliasname> <pre -or- post > <log path >

where the first argument is the database connection alias (/@tnsaliasname) and the second argument is either pre or post and the third argument is the log path.

Details

The changes against the database structures will be executed in a single statement at a time and will continue to process if it fails. Any failure will be logged in the log file.

Assumptions and Scheduling Notes

This batch should be run before the nightly batch window in "pre" mode and after the nightly batch window in "post" mode.

Threading

This batch is not threaded.

PriceChangeAreaDifferentialBatch Batch Design

The Price Change Area Differential batch process (PriceChangeAreaDifferentialBatch.java) allows the user to generate and approve Price Changes for selected secondary areas of an Area Differential.

Usage

Use the following command to run the PricerChangeAreaDifferentialBatch job:

PricerChangeAreaDifferentialBatch.sh userAlias

Details

• The Bulk Conflict Checking engine is used to conflict check the generated Price Changes

• Instead of the batch process spawning multiple threads to do the approval, the threading is done by the Bulk Conflict Checking engine

Assumptions and Scheduling Notes

Only one instance of the batch (per database) may be run at a time.

Primary Tables Involved

• RPM_AREA_DIFF

• RPM_PRICE_CHANGE

• RPM_FUTURE_RETAIL (if auto-approve)

PriceChangeAutoApproveResultsPurgeBatch Batch Design

The PriceChangeAutoApproveResultsPurgeBatch program deletes old error message from the price change auto-approve batch program.

Usage

The following command runs the PriceChangeAutoApproveResultsPurgeBatch job:

PriceChangeAutoApproveResultsPurgeBatch.sh userAlias

Details

The PriceChangeAutoApproveResultsPurgeBatch program deletes price change auto approve errors. These errors are generated when the WorksheetAutoApproveBatch cannot approve a price change that it has created. The price change auto approve errors are deleted based on the effective dates of the price changes associated with the error. The price change auto approve errors are delete when the effective date of the price changes attempted to be approved is less than or equal to the vdate.

Assumptions and Scheduling Notes

PriceChangeAutoApproveResultsPurgeBatch can be run ad hoc.

Primary Tables Involved

• RPM_MAINT_MARGIN_ERR

• RPM_MAINT_MARGIN_ERR_DTL

Threading

The PriceChangeAutoApproveResultsPurgeBatch program is not threaded.

PriceChangePurgeBatch Batch Design

The PriceChangePurgeBatch program deletes past price changes.

Usage

The following command runs the PriceChangePurgeBatch job:

PriceChangePurgeBatch.sh userAlias

Detail

The PriceChangePurgeBatch program deletes price changes that have an effective date that is less than the vdate.

Assumptions and Scheduling Notes

PriceChangePurgeBatch can be run ad hoc.

Primary Tables Involved

RPM_PRICE_CHANGE

Threading

The PricechangePurgeBatch program is not threaded.

PriceChangePurgeWorkspaceBatch Batch Design

The PriceChangePurgeWorkspaceBatch program deletes abandoned price change workspace records.

Usage

The following command runs the PriceChangePurgeWorkspaceBatch job:

PriceChangePurgeWorkspaceBatch,sh userAlias

Where the argument is the user ID.

Detail

When users access the price change dialogue, records are created in workspace tables. These records are typically removed when the user exits the price change dialogue. However, it is possible that the workspace records may be abandoned. When this action occurs, the PriceChangePurgeWorkspaceBatch deletes them. The PriceChangePurgeWorkspaceBatch deletes records in the workspace table that are over n days old, where n is a system-defined number of days.

Assumptions and Scheduling Notes

PriceChangePurgeWorkspaceBatch can be run ad hoc.

Primary Tables Involved

• RPM_PRICE_WORKSPACE

• RPM_PRICE_WORKSPACE_DETAIL

Threading

The PriceChangePurgeWorkspaceBatch program is not threaded.

Price Event Execution Batch Processes

The price event execution batch processes perform the necessary work to start (regular price change, clearance price change, promotions) and end (clearance, promotions) pricing events.

Executing price events requires running three batch programs:

• PriceEventExecutionBatch.java identifies the events that need to be executed and stages the affected item-locations for the next batch to process. If this batch fails to process a particular price event, that event remains in ”approved” status and the next-day batch run is guaranteed to pick up this failed price event for re-processing.

• PriceEventExecutionRMSBatch.java processes the item-locations affected by the price events being executed in RPM. If this batch fails to process a particular item-location for one or more price events, the affected events are in ”executed” status and the item-locations that failed to process remains staged in RPM_EVENT_ITEMLOC. These item-locations are picked up again by the next-day batch run.

• PriceEventExecutionDealsBatch.java processes the deals affected by the price events being executed. If this batch fails to process a particular item-location deal for one or more price events, the affected events is in ”executed” status and their associated item-locations are posted in RMS ITEM_LOC and PRICE_HIST tables. However, the item-location deals that failed to process remains in RPM_EVENT_ITEMLOC_DEALS and the next-day batch run is guaranteed to pick these up.

  
  

  Note: There is also another batch that performs similar type of work to start and end price events, but it is specifically design for Emergency Price Events. For details, please refer to Price Event Execution For ChunkCCEmergencyEvents Batch processes section.

  
  

Usage

The following commands need to be executed in order:

PriceEventExecutionBatch.sh userAlias [restartInd Y|N]
PriceEventExecutionRMSBatch.sh userAlias
PriceEventExecutionDealsBatch.sh userAlias

Where the last argument of the PriceEventExecutionBatch indicates if the run should start over (use a value of N) or pick up where the previous run left off (use a value of Y).

Detail

The batch programs process regular price changes, clearance price changes, and promotions events that are scheduled for the run date. Restartability features allow events missed in past runs of the batch to be picked up in later runs. When posting information in the ITEM_LOC and PRICE_HIST table, the batch process respects the active dates of their associated price events.

• Promotions

  • Promotions that are scheduled to start are activated. These include all approved promotions whose start dates are <= VDATE+1.

  • Promotions that are scheduled to end are completed. These include all active promotions whose end dates are <= VDATE.

  • Only data for simple promotions are processed by the PriceEventExecutionRMSBatch.

• Clearances

  • Clearance markdowns that are scheduled to take place are executed. These include all clearances whose effective dates are <= VDATE+1.

  • Clearances that are scheduled to be completed (reset) are completed.

• Regular price changes

  • Regular price changes that are scheduled to take place are executed. These include all price changes whose effective dates are <= VDATE+1.

Assumptions and Scheduling Notes

The batch processes must run in the following order:

• PriceEventExecutionBatch

• PriceEventExecutionRMSBatch

• PriceEventExecutionDealsBatch

The previous three processes must run before the following programs:

• Storeadd (RMS)

• MerchExtractKickOffBatch

The following programs must run before the PriceEventExecution batch processes:

• Salstage (RMS)

• LocationMoveBatch

Primary Tables Involved

• RPM_PRICE_CHANGE

• RPM_PROMO

• RPM_CLEARANCE

• RPM_PROMO_COMP

• RPM_PROMO_DTL

• RPM_PROMO_DTL_LIST_GRP

• RPM_PROMO_DTL_LIST

• RPM_PROMO_DTL_MERCH_NODE

• RPM_PROMO_DTL_DISC_LADDER

• RPM_PROMO_ZONE_LOCATION

RMS Interface Point

The PriceEventExecutionRMSBatch interfaces with the RMS price change subscription package RMSSUB_PRICE_CHANGE. All price change, clearance, and promotion prices are passed along to this RMS package at the item location level and are applied in RMS.

Threading

Two of the three batch programs involved in price event execution utilize concurrent processing. They are PriceEventExecutionBatch and PriceEventExecutionRMSBatch. Each program has a separate strategy, as described in the following.

• PriceEventExecutionBatch is threaded by a variable number of item-locations affected by the pricing events to be executed.

• To configure threading for this program, a record containing the following values must be inserted in the RPM_BATCH_CONTROL table.

  Variable Name	Description
  BATCH_CONTROL_ID	System-generated sequence number.
  PROGRAM_NAME	com.retek.rpm.batch.PriceEventExecutionBatch
  NUM_THREADS	Number of threads to run concurrently.
  THREAD_LUW_COUNT	Number of item-locations to be executed in one thread.

  
  

Example:

For a promotion price event, where there are 50 promotion details, affecting 100,000 item-locations, in approved status--and where start and end dates are VDATE+1, the initial RPM_BATCH_CONTROL table settings are as follows:

Variable Name	Description
BATCH_CONTROL_ID	1
PROGRAM_NAME	com.retek.rpm.batch.PriceEventExecutionBatch
NUM_THREADS	3
THREAD_LUW_COUNT	10,000

When the PriceEventExecutionBatch program runs on VDATE, the 100,000 item-locations are grouped into ten sets of 10,000 (based on THREAD_LUW_COUNT). A unique thread number is assigned to each group.

Each set of 10,000 item-locations details is processed in three threads, based on NUM_THREADS. The three threads process concurrently for a group, and they may not finish at the same time. So as execution of one thread within a group completes, processing of the first thread of the next group begins--until all promotion details are processed.

• PriceEventExecutionRMSBatch is threaded by a variable number of item-locations affected by the pricing events to be executed.

• To configure threading for this program, a record containing the following values must be inserted in the RPM_BATCH_CONTROL table:

  Variable Name	Description
  BATCH_CONTROL_ID	System-generated sequence number.
  PROGRAM_NAME	com.retek.rpm.batch.PriceEventExecutionBatchRMSBatch
  NUM_THREADS	Number of threads to run concurrently.
  THREAD_LUW_COUNT	Number of item-locations to be executed in one thread.

  
  

Example:

Where there are various price events affecting 100,000 item-locations, the initial RPM_BATCH_CONTROL table settings are follows:

Variable Name	Description
BATCH_CONTROL_ID	2
PROGRAM_NAME	com.retek.rpm.batch.PriceEventExecutionRMSBatch
NUM_THREADS	3
THREAD_LUW_COUNT	10,000

When the PriceEventExecutionRMSBatch program runs on VDATE, the 100,000 item-locations are grouped into 10 sets of 10,000 item-locations (based on THREAD_LUW_COUNT). A unique thread number is assigned to each group.

Each set of 10,000 item-locations is processed in three threads, based on NUM_THREADS. The three threads process concurrently for a group, and they may not finish at the same time. So as execution of one thread within a group completes, processing of the first thread of the next group begins--until all item-locations are processed.

The item-locations have been staged by the PriceEventExecutionBatch program. When the PriceEventExecutionRMSBatch job is completed, these item-locations are updated in RMS.

PriceEventExecutionForChunkCCEmergencyEvents Batch Design

The priceEventExecutionForChunkCCEmergencyEvents processes perform the necessary work to start and end Emergency Price Events that are processed through Chunk Conflict Checking Engine. This will allow the system to update RMS near real time.

Usage

The following command runs the priceEventExecutionForChunkCCEmergencyEvents job:

priceEventExecutionForChunkCCEmergencyEvents.sh <connection_alias> <logpath> <errpath>

Where the first argument is the database connect alias (/@db_connection_alias), the second argument is the path where the log file will be created and the third argument is the path where the error file will be created.

Detail

The priceEventExecutionForChunkCCEmergencyEvents batch program process Emergency regular price changes, clearance price changes, and promotions events that are scheduled to run on vdate or less than vdate. All processes for the emergency batch are similar to the priceEventExecutionBatch in the above that it is also update RMS tables in one batch. It is calling the same function with different parameter so that the system knows to process an Emergency Price Events or Non-Emergency Price Events. Instead of having a separate batch to update RMS for item location and pricing tables and RMS Deal Information, the priceEventExecutionForChunkCCEmergencyEvents batch processes all in one batch.

Primary Tables Involved

• RPM_CHUNK_CC_STAGE_PEE

• RPM_PRICE_CHANGE

• RPM_PROMO

• RPM_CLEARANCE

• RPM_PROMO_COMP

• RPM_PROMO_DTL

• RPM_PROMO_DTL_LIST_GRP

• RPM_PROMO_DTL_LIST

• RPM_PROMO_DTL_MERCH_NODE

• RPM_PROMO_DTL_DISC_LADDER

• RPM_PROMO_ZONE_LOCATIN

Threading

The threading for priceEventExecutionForChunkCCEmergencyEvents batch is similar to the priceEventExecutionBatch. It utilizes concurrent processing and is threaded by a number of item-locations affected by the pricing events to be executed. For more detail, please see the PriceEventExecutionBatch process in the Threading section.

PriceEventItemListPurgeBatch Batch Design

The priceEventItemListPurgeBatch program removes price event item list information that is no longer being used.

Usage

The following command runs the priceEventItemListPurgeBatch job:

priceEventItemListPurgeBatch.sh database-connect-alias logpath errpath

Where the first argument is the database connect alias (/@db_connection_alias), the second argument is the path where the log file will be created and the third argument is the path where the error file will be created.

Detail

The priceEventItemListPurgeBatch program deletes data for price event item lists that are not associated with a price event.

Primary Tables Involved

• RPM_MERCH_LIST_HEAD

• RPM_MERCH_LIST_DETAIL

• RPM_PEIL_DEPT_CLASS_SUBCLASS

Threading

The priceEventItemListPurgeBatch program is not threaded.

PriceStrategyCalendarBatch Batch Design

The calendar expiration batch process (PriceStrategyCalendarBatch.java) maintains calendars assigned to price strategies.

Usage

The following command runs the PriceStrategyCalendarBatch job:

PriceStrategyCalendarBatch.sh userAlias

Details

The batch looks at price strategies that have expired or suspended calendars.

If a strategy has new calendars setup, the batch replaces the strategies' current calendar with the new calendar.

If a strategy does not have a new calendars setup and the expired calendar has a replacement calendar specified, the batch replaces the strategies' current calendar with the current calendar's replacement calendar.

Assumptions and Scheduling Notes

PriceStrategyCalendarBatch must run before the following programs:

• PriceEventExecutionBatch

• MerchExtractKickOffBatch

Primary Tables Involved

• RPM_STRATEGY

• RPM_CALENDAR

• RPM_CALENDAR_PERIOD

Threading

The PriceStrategyCalendarBatch program is not threaded.

primaryZoneModificationsBatch Design

This batch updates the future retail tables whenever the primary zone group definition for a merchandise hierarchy is updated/added/removed so that the future retail tables correctly reflect timelines at the zone level.

Usage

The following command runs the primaryZoneModificationsBatch job:

primaryZoneModificationsBatch.sh database-connect-string LogPath ErrorPath

Where the first argument is the database connection string and the second argument specifies the path from where the log file should be generated. The third argument specifies the path from where the error file should be generated.

Details

The batch calls the package RPM_PRIMARY_ZONE_UPDATE_SQL.EXECUTE. This package updates all future retail data for any merchandise hierarchies, where the primary zone group definition was modified/created/deleted and there is no other higher level merchandise hierarchy primary zone group definition that matches the new value within the system. The batch allows for future retail timelines at the zone level to accurately reflect the correct zone, and for timelines at the location level (where the location is part of the primary zone group for the given merchandise hierarchy) to correctly reference the correct zone.

Assumptions and Scheduling Notes

This process must be executed during the batch window. As it runs, other processes must not access the future retail tables.

Primary Tables Involved

• RPM_FUTURE_RETAIL

• RPM_PROMO_ITEM_LOC_EXPL

• RPM_CUST_SEGMENT_PROMO_FR

• RPM_PRIM_ZONE_MODIFICATIONS

Threading

The primaryZoneModificationsBatch program is not threaded.

ProcessPendingChunkBatch Batch Design

The ProcessPendingChunkBatch program attempts to reprocess push-back logic for threads that encountered errors.

Usage

The following command runs the ProcessPendingChunkBatch job:

ProcessPendingChunkBatch.sh userAlias

Details

The batch looks for any push-back threads that completed with error and any price events that encountered errors in the post-push-back logic and attempts to reprocess them using the same logic that is used during the regular conflict checking processing.

Assumptions and Scheduling Notes

The ProcessPendingChunkBatch process can be run ad-hoc - the event of a price event moving to a pending status triggering the need to run this batch. Prior to running this batch, a DBA needs to verify what issues were encountered that caused a price event to be moved to a pending status (issues like unable to extend table space). These issues need to be rectified prior to running this batch. If no action is taken to resolve these issues, the batch will likely encounter the same issues and the price events will be left in a pending status.

Primary Tables Involved

• RPM_BULK_CC_PE_CHUNK

• RPM_BULK_CC_PE_THREAD

• RPM_FUTURE_RETAIL_WS

• RPM_CLEARANCE_WS

• RPM_PROMO_ITEM_LOC_EXPL_WS

• RPM_CUST_SEGMENT_PROMO_FR_WS

• RPM_FUTURE_RETAIL

• RPM_CLEARANCE

• RPM_PROMO_ITEM_LOC_EXPL

• RPM_CUST_SEGMENT_PROMO_FR

Threading

The ProcessPendingChunkBatch program is threaded in that it will reuse the same threading logic used by the conflict checking engine when attempting to reprocess push-back threads.

PromotionArchiveBatch Batch Design

The PromotionArchiveBatch program moves promotions from active/working tables to history promotion tables.

Usage

The following command runs the PromotionArchiveBatch job:

PromotionArchiveBatch.sh userAlias

Details

The batch will move promotions as a whole and once the rpm_promo.end_date value is <= vdate - 1 from the active/working tables to the history versions of each table.

Assumptions and Scheduling Notes

None.

Primary Tables Involved

• RPM_PROMO

• RPM_PROMO_COMP

• RPM_PROMO_DTL

• RPM_PROMO_ZONE_LOCATION

• RPM_PROMO_DTL_LIST_GRP

• RPM_PROMO_DTL_LIST

• RPM_PROMO_DTL_DISC_LADDERRPM_PROMO_DTL_MERCH_NODE

• RPM_PROMO_DTL_PRC_RANGE

• RPM_PENDING_DEAL_DETAIL

• RPM_PROMO_DEAL_LINK

• RPM_PROMO_HIST

• RPM_PROMO_COMP_HIST

• RPM_PROMO_DTL_HIST

• RPM_PROMO_ZONE_LOCATION_HIST

• RPM_PROMO_DTL_LIST_GRP_HIST

• RPM_PROMO_DTL_LIST_HIST

• RPM_PROMO_DTL_DISC_LDR_HIST

• RPM_PROMO_DTL_MERCH_NODE_HIST

• RPM_PROMO_DTL_PRC_RANGE_HIST

• RPM_PROMO_DTL_SKULIST

• RPM_PROMO_DTL_SKULIST_HIST

Threading

The PromotionArchiveBatch program is not threaded.

PromotionPriceChangePublishBatch Batch Design

The PromotionPriceChangePublishBatch program formats and stages output of promotion price change price events.

The corresponding promotionPriceChangePublishExport shell script produces a pipe ("|") delimited flat-file export based on the output of the PromotionPriceChangePublishBatch.

Usage

The following command runs the PromotionPriceChangePublishBatch job:

PromotionPriceChangePublishBatch.sh userAlias

The following command runs the promotionPriceChangePublishExport job:

promotionPriceChangePublishExport.sh </@tnsaliasname> <slots> <log_path> <error_path> [export_path]

Where the first argument is the database connect alias (/@tnsaliasname), the second argument is to indicate the maximum number of concurrent threads should run at a time, the third and fourth argument are the path where the log file and error file should be written, and the last argument, the export_path is optional; if not supplied, the path ../output is used.

Details

The batch looks for price events in the RPM_PRICE_EVENT_PAYLOAD table with a RIB_FAMILY of PrmPrcChg and distributes those events to multiple threads based on the settings in the RPM_BATCH_CONTROL table. Each thread reads in its set of promotion price change events from tables RPM_PRICE_EVENT_PAYLOAD and the related promotion payload tables (see the following) and generates output in RPM_PRICE_PUBLISH_DATA.

PurgePayloadsBatch should be run to delete records in the payload tables.

A flat-file per location based on the data from payload table that need to be published/processed will be created. .The naming convention for the flat file will be (PRMPC_<timestamp>_<location>_<loc_type>.dat), where <timestamp> is the current system time stamp, <location> is the location id and <loc_type> is the type of the location where 'S' is for Store.

The Item data (TLITM records) will include fully exploded details for how the promotion detail was setup within RPM. The actual item that will participate in the promotion should not be derived from this data. Rather, the item /selling retail data in the file (TPISR records) will always show what item are participating in the promotion for a specific location and what the associated retail is for the given item/location at the date/time specified in the record. The correct way to determine what item actually participates in the promotion is using the item listed in the TPISR records.

Input Tables

• RPM_PRICE_EVENT_PAYLOAD

• RPM_PROMO_ITEM_PAYLOAD

• RPM_PROMO_LOCATION_PAYLOAD

• RPM_PROMO_DISC_LDR_PAYLOAD

• RPM_PROMO_DTL_LIST_PAYLOAD

• RPM_PROMO_DTL_LIST_GRP_PAYLOAD

• RPM_PROMO_DTL_PAYLOAD

• RPM_PROMO_ITEM_LOC_SR_PAYLOAD

• RPM_PROMO_DTL_PRC_RNG_PAYLOAD

• RPM_PROMO_DTL_CIL_PAYLOADRPM_PROMO_DTL_CIL_ITEM_PAYLOAD

• RPM_PROMO_DTL_CIL_LOC_PAYLOAD

• RPM_PROMO_CREDIT_DTL

• RPM_FINANCIALS_DTL

Output File Record Types

• FHEAD (required): File identification, one line per file.

• TMBPE (optional): Event Type.

• TPDTL (required): Promotion Component Detail.

• TPGRP (required): Promotion Group (one or more per TPDTL).

• TGLST (required): Promotion List (one or more per TPGRP).

• TLITM (required): Promotion Item (one or more per TGLST).

• TPDSC (required): Promotion Discount (one or more per TGLST).

• TPISR (required): Promotion Item Selling retail (one or more per TPDTL).

• TPCDT (optional): Promotion Credit Detail (one or more per TPDTL).

• TPCI (optional): Promotion Cancel Item (one or more per TPDTL).

• TTAIL (required): Transaction tail (one per promotion).

• FPDEL (optional): Promotion Delete.

• FTAIL (required): End of file marker, one line per file.

Output File Layout

Table 7-3 Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
FHEAD	Record Descriptor	Char(5)	FHEAD	File head marker
	Line id	Number(10)	1	Unique line identifier
	File Type	Char(5)	PROMO	Promotions
	Export timestamp	Timestamp		System clock timestamp (YYYYMMDDHHMISS)
	Location	Number(100		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
TMBPE	Record Descriptor	Char(5)	TMBPE	Promotion (transaction head)
	Line id	Number(10)		Unique line identifier
	Event Type	Char(3)		CRE = Create, MOD = Modify
TPDTL	Record Descriptor	Char(5)	TPDTL	Promotion Detail Component
	Line id	Number(10)		Unique line identifier
	Promo Id	Number(10)		Promotion identifier
	Promo Comp Id	Number(10)		Promotion Component Id
	Promo Name	Char(160)		Promotion Header Name
	Promo Desc	Char(640)		Promotion Header Description
	Promo Comp Desc	Char(160)		Promotion Component Name
	Promo Type	Number(2)		Promotion Component Type
	Promo Comp Detail Id	Number(10)		Promotion Component Detail identifier
	Start Date	Date		Start Date of Promotion Component Detail (YYYYMMDDHH24MISS)
	End Date	Date		End Date of Promotion Component Detail (YYYYMMDDHH24MISS)
	Apply to Code	Number(1)		Holds the apply to code for the promotion detail. Determines if the promotion is applied to regular retail only (no clearances in effect), clearance retail only (when a clearance is in effect), or both regular and clearance retail. Valid values are 0 - Regular Only; 1 - Clearance Only; 2 - Regular and Clearance.
	Discount Limit			The number of times that the promotion that can be applied to a transaction.
	Apply Order	Number(1)		Application Order of the Promotion
	Threshold Id	Number(6)		Threshold identifier
	Customer Type Id	Number(10)		Customer Type identifier
	Threshold Qualification Type	Number(1)		The qualification type for the threshold. Will only be populated for threshold promotions. Valid values are 0 for item level and 1 for threshold level.
	Exclusion parent id	Number(10)		The promotion component detail id for the parent event that this event is a child to. Used only for Transaction promotion detail exclusions to be able to connect the child exclusion to it's parent promotion detail.
TPGRP	Record Descriptor	Char(5)	TPGRP	Promotion Detail Group
	Line id	Number(10)		Unique line identifier
	Group Id	Number(10)		Group Number
TGLIST	Record Descriptor	Char(5)	TGLIST	Promotion Group List
	Line id	Number(10)		Unique line identifier
	List Id	Number(10)		List identifier
	Reward Application	Number(1)		How this reward is applied to the promotion detail.
	Description	Char(120)		Description
	Price Range Min	Number(20,4)		Contains price range promotion minimum valid retail value.
	Price Range Max	Number(20,4)		Contains price range promotion maximum valid retail value.
TLITM	Record Descriptor	Char(5)	TLITM	Promotion Group List
	Line id	Number(10)		Unique line identifier
	Item Id	Char(25)		Transaction Item Identifier
TPDSC	Record Descriptor	Char(5)	TPDSC	Discount Detail for List
	Line id	Number(10)		Unique line identifier
	Change Type	Number(2)		Change Type. Valid Values: -1 (negative one) - No change 0 - Percentage change 1 - Amount change 2 - Fixed price 3 - Reset POS 4 - Exclude 5 - Amount off UOM 6 - Cheapest Free 7 - Finance promotion
	Change Amount	Number(20,4)		Change Amount
	Change Currency	Char(3)		Change Currency
	Change Percent	Number(20,4)		Change Percent
	Change Selling UOM	Char(4)		Change Selling UOM
	Qual Type	Number(2)		Qualification Type
	Qual Value	Number(2)		Qualification Value
	Change Duration	Number(20,4)		Change Duration
TPISR	Record Descriptor	Char(5)	TPILSR	Items in Promotion
	Line id	Number(10)		Unique line identifier
	Item Id	Char(25)	TTAIL	Transaction Item Identifier
	Selling Retail	Number(20,4)		Selling retail of the item
	Selling UOM	Char(4)		Selling UOM of the item
	Effective Date	Date		Effective Date of the selling retail - YYYYMMDDHH24MISS
	Selling Retail Currency	Char(3)		Selling retail currency
TPCDT	Record Descriptor	Char(5)	TPCDT	Credit Detail
	Credit Detail Id	Number(10)		Credit Detail Id
	Line Id	Number(10)		Unique line id
	Credit Type	Char(40)		Credit Type
	binNumber From	Number(10)		Bin Number From
	binNumberTo	Number(10)		Bin Number To
	Commission Rate	Number(10)		Commission Rate
	Comments	Char(160)		Comments
TTAIL	Record Descriptor	Char(5)	TTAIL	Transaction Tail
	Line id	Number(10)		Unique line identifier
TPCI	Record Descriptor	Char(5)	TPCIL	Cancel Item
	Line Id	Number(10)		Unique line identifier
	Promo ID	Number(10)		The ID of the promotion
	Promo Comp Id	Number(10)		Promotion Component Id
	Promo Comp Detail Id	Number(10)		Promotion Component Detail identifier
	Item Id	Char(25)		Transaction Item Identifier for item
	Cancellation Date	Date		Cancellation effective date — YYYYMMDDHH24MISS
FPDEL	Record Descriptor	Char(5)	FPDEL	Delete Promotion
	Line id	Number(10)		Unique line identifier
	Promo ID	Number(10)		The ID of the promotion
	Promo Comp Id	Number(10)		Promotion Component Id
	Promo Comp Detail Id	Number(10)		Promotion Component Detail identifier
	Group Id	Number(10)		Group Number
	List Id	Number(10)		List identifier
	Item Id	Char(25)		Transaction Item Identifier for item
FTAIL	Record Descriptor	Char(5)	FTAIL	File tail marker
	Line id	Number(10)		Unique line identifier
	Number of lines	Number(10)		Number of lines in file not counting FHEAD and FTAIL

Assumptions and Scheduling Notes

PromotionPriceChangePublishBatch should be run after the WorksheetAutoApproveBatch.

PromotionPriceChangePublishExport should be executed as follows:

• After every successful run of PromotionPriceChangePublishBatch.

• Before PurgePayloadsBatch.

Threading

The PromotionPriceChangePublish program is threaded. The LUW is a single rpm_price_event_payload record. (Multi-buy promotions are not split across threads but Simple and Threshold promotions may be.)

Configuration

The following property must be set in rpm.properties on the application server when using this batch program to publish promotion price events:

delete_staged_rib_payloads=false

PromotionPurgeBatch batch Design

The PromotionPurgeBatch program deletes old and rejected promotions.

Usage

The following command runs the PromotionPurgeBatch job:

PromotionPurgeBatch.sh userAlias

Detail

PromotionPurgeBatch deletes promotions based on two system options. RPM_SYSTEM_OPTIONS.PROMOTION_HIST_MONTHS and RPM_SYSTEM_OPTIONS.REJECT_HOLD_DAYS_PROMO. RPM_SYSTEM_OPTIONS.PROMOTION_HIST_MONTHS controls how long non-rejected promotions are held. RPM_SYSTEM_OPTIONS.REJECT_HOLD_DAYS_PROMO controls how long rejected promotions are held.

Assumptions and Scheduling Notes

PromotionPurgeBatch can be run ad hoc.

Primary Tables Involved

• RPM_LOC_MOVE_PROMO_COMP_DTL_EX

• RPM_CONFLICT_CHECK_RESULT

• RPM_PROM_COMP_AGG_TBL

• RPM_PROMO_DEAL_LINK

• RPM_PENDING_DEAL_DETAIL

• RPM_PENDING_DEAL

• RPM_PROMO_DTL_MERCH_NODE_HIST

• RPM_PROMO_DTL_DISC_LDR_HIST

• RPM_PROMO_DTL_LIST_HIST

• RPM_PROMO_DTL_LIST_GRP_HIST

• RPM_PROMO_ZONE_LOCATION_HIST

• RPM_PROMO_DTL_PRC_RANGE_HIST

• RPM_PROMO_DTL_HIST

• RPM_PROMO_COMP_HIST

• RPM_PROMO_HIST

• RPM_PROMO_CREDIT_DTL

Threading

This program is threaded.

PurgeBulkConflictCheckArtifacts Batch Design

The purgeBulkConflictCheckArtifacts program cleans up the working tables used by Bulk Conflict Checking and Chunk Conflict Checking engines.

Usage

The following command runs the purgeBulkConflictCheckArtifacts job:

purgeBulkConflictCheckArtifacts.sh userAlias

Where the argument is the user ID.

Detail

RPM utilizes the Bulk Conflict Checking and Chunk Conflict Checking engines for conflict checking. These engines use several working tables to do their processing. In normal conditions, these tables are supposed to be deleted at the end of the Conflict Checking process. But if there are any environment issues, it is possible that there will be some records left in these tables. This batch program cleans up those working tables. This batch makes sure that the system has a clean set of working tables for Bulk Conflict Checking and Chunk Conflict Checking for the next day. Users using the application with too many records left in these working tables could impact the performance of both Bulk Conflict Checking and Chunk Conflict Checking.

Assumptions and Scheduling Notes

purgeBulkConflictCheckArtifacts needs to run at the end of all other batch programs.

Primary Tables Involved

• RPM_BULK_CC_PE

• RPM_BULK_CC_PE_SEQUENCE

• RPM_BULK_CC_PE_THREAD

• RPM_BULK_CC_PE_IL

• RPM_FUTURE_RETAIL_WS

• RPM_PROMO_ITEM_LOC_EXPL_WS

• RPM_CUST_SEGMENT_PROMO_FR_WS

• RPM_CLEARANCE_WS

PurgeConCheckResultsErrorData Batch Design

The PurgeConCheckResultsErrorData program purges conflict check results and errors that are from price events that are no longer in the system.

Usage

The following command runs the PurgeConCheckResultsErrorData job:

purgeConCheckResultsErrorData.sh </@tnsaliasname> <log path>
<error path>

Where the first argument is the RPM database-connect-alias (/@tnsaliasname). The second argument is the log path where the log file is written. The third argument is the error path where the error file is written.

Detail

The PurgeConCheckResultsErrorData process deletes data from the RPM_CONFLICT_CHECK_RESULT, RPM_CON_CHECK_ERR and RPM_CON_CHECK_ERR_DETAIL tables when data on them references price events that are no longer in RPM.

Assumptions and Scheduling Notes

The PurgeConCheckResultsErrorData batch can be run ad hoc.

Primary Tables Involved

• RPM_CONFLICT_CHECK_RESULT

• RPM_CON_CHECK_ERR

• RPM_CON_CHECK_ERR_DETAIL

Threading

The PurgeConCheckResultsErrorData batch is not threaded.

PurgeExpiredExecutedOrApprovedClearancesBatch Batch Design

The PurgeExpiredExecutedOrApprovedClearancesBatch program deletes expired clearances in Executed or Approved statuses.

Usage

The following command runs the PurgeExpiredExecutedOrApprovedClearancesBatch job:

PurgeExpiredExecutedOrApprovedClearancesBatch </@tnsaliasname> <log path> <error path>

Where the first argument is the RPM database-connect-alias (/@tnsaliasname). The second argument is the log path where the log file is written. The third argument is the error path where the error file is written.

Detail

The PurgeExpiredExecutedOrApprovedClearancesBatch deletes clearances that meet the following criteria:

• Clearance effective date is older than the CLEARANCE_HIST_MONTHS system option.

• Clearance is on a valid future retail timeline (RPM_FUTURE_RETAIL).

• Clearance is in an Approved or Executed status.

Assumptions and Scheduling Notes

PurgeExpiredExecutedOrApprovedClearancesBatch can be run ad hoc.

Primary Tables Involved

• RPM_CLEARANCE

• RPM_CLEARANCE_RESET

Threading

The PurgeExpiredExecutedOrApprovedClearancesBatch program is not threaded.

PurgeLocationMovesBatch Batch Design

The PurgeLocationMovesBatch program deletes old expired and executed zone location moves.

Usage

The following command runs the PurgeLocationMovesBatch job:

PurgeLocationMovesBatch.sh userAlias

Detail

The PurgeLocationMovesBatch program deletes location moves based on their effective date. Location moves are purged regardless whether or not they have been executed. Location moves are purged when their effective date is RPM_SYSTEM_OPTIONS. LOCATION_MOVE_PURGE_DAYS days in the past.

Assumptions and Scheduling Notes

PurgeLocationMovesBatch can be run ad hoc.

Primary Tables Involved

• RPM_LOCATION_MOVE

• RPM_LOC_MOVE_PROMO_ERROR

• RPM_LOC_MOVE_PRC_STRT_ERR

• RPM_LOC_MOVE_PRC_CHNG_EX

• RPM_LOC_MOVE_CLEARANCE_EX

• RPM_LOC_MOVE_PROMO_COMP_DTL_EX

Threading

The PurgeLocationMovesBatch.java program is multithreaded.

purgeRPMBatchRunHistory Batch Design

The purgeRPMBatchRunHistory program will truncate partitions from the RPM_BATCH_RUN_HISTORY table based on the value in the BATCH_RUN_HIST_MONTHS column in the RPM_SYSTEM_OPTIONS table.

Depending on the value for the system option, the batch will determined which partition(s) should be truncated by utilizing the data from the DBA_TAB_PARTITIONS table.

Usage

The following command runs the purgeRPMBatchRunHistory job:purgeRPMBatchRunHistory.sh </@tnsaliasname> <log path> <error path>Where the first argument is the RPM database-connection-alias (/@tnsaliasname). The second argument is the log path where the log file is written. The third argument is the error path where the error file is written.

Assumptions and Scheduling Notes

purgeRPMBatchRunHistory can be run ad hoc.

Primary Tables Involved

• RPM_BATCH_RUN_HISTORY

• RPM_SYSTEM_OPTIONS

PurgePayloadsBatch Batch Design

The PurgePayloadsBatch program purges entries to price events from the RPM_*PAYLOAD tables.

Usage

The following command runs the PurgePayloadsBatch job:

purgePayloadsBatch.sh </@tnsaliasname> <publish-status>_<log-path>

Where the first argument is the database connection alias (/@tnsaliasname).

The second argument is the publish status of the price event record. Valid values are 1, 2 and 3, as described in the following table:

Table 7-4 Publish Status of the Price Event Record

<publish-status>	Description
1	This setting results in purged price events that have been exported by RMPtoORPOSPublishExport.sh
2	This setting results in purged price events that have been exported by any one of the following: regularPriceChangePublishExport.sh clearancePriceChangePublishExport.sh promotionPriceChangePublishExport.sh
3	This setting results in purged price events that have been exported by RPMtoORPOSPublishExport.sh AND by any one of the following: regularPriceChangePublishExport.sh clearancePriceChangePublishExport.sh promotionPriceChangePublishExport.sh

Detail

The PurgePayloadsBatch program purges the price events from the payload tables based on the <publish-status> argument. Publish status is stored in the PUBLISH_STATUS column of the RPM_PRICE_EVENT_PAYLOAD table. Valid values are 0, 1, 2, and 3, as described in the following table:

Table 7-5 Publish Status Description

PUBLISH_STATUS	Description
0	This is the default value for the field. The PurgePayloadsBatch job will not purge event records with PUBLISH_STATUS=0. The error message, You must specify publish status: 1/2/3 displays if the user attempts to run the batch with <publish-status>=0.
1	Price event records with PUBLISH_STATUS=1 have been exported by RPMtoORPOSPublishExport.sh
2	Price event records with Publish_status=2 have been exported by any one of the following: regularPriceChangePublishExport.sh clearancePriceChangePublishExport.sh promotionPriceChangePublishExport.sh
	Price event records with PUBLISH_STATUS=3 have been exported by RPMtoORPOSPublishExport.sh AND by any one of the following: regularPriceChangePublishExport.sh clearancePriceChangePublishExport.sh promotionPriceChangePublishExport.sh

Assumptions and Scheduling Notes

PurgePayloadsBatch should be run after the successful completion of the following batch jobs:

• RPMtoORPOSPublishExport.sh

• regularPriceChangePublishExport.sh

• clearancePriceChangePublishExport.sh

• promotionPriceChangePublishExport.sh

Primary Tables Involved

• RPM_PRICE_CHG_PAYLOAD

• RPM_CLEARANCE_PAYLOAD

• RPM_PROMO_DTL_PAYLOAD

• RPM_PROMO_FIN_DTL_PAYLOAD

• RPM_PRICE_EVENT_PAYLOAD

Threading

The PurgePayloadsBatch program is not threaded.

PurgeUnusedAndAbandonedClearancesBatch Batch Design

The PurgeUnusedAndAbandonedClearancesBatch program deletes unused and rejected clearances.

Usage

The following command runs the PurgeUnusedAndAbandonedClearancesBatch job:

PurgeUnusedAndAbandonedClearancesBatch.sh </@tnsaliasname> <log path> <error path>

Where the first argument is the RPM database-connect-alias (/@tnsaliasname). The second argument is the log path where the log file is written. The third argument is the error path where the error file is written.

Detail

The PurgeUnusedAndAbandonedClearancesBatch program deletes clearances from the RPM_CLEARANCE table that meet one of the following three criteria:

• Clearance effective date is older than the CLEARANCE_HIST_MONTHS system option.

• Clearance is in Worksheet or Submitted status.

Or

• Clearance effective date is older than the CLEARANCE_HIST_MONTHS system option.

• Clearance is in Execute or Approved status.

• Clearance is not on a future retail timeline.

Or

• Clearance effective date is older than the REJECT_HOLD_DAYS_PC_CLEAR system option.

• Clearance is in Rejected status.

Assumptions and Scheduling Notes

PurgeUnusedAndAbandonedClearancesBatch can be run ad hoc.

Primary Tables Involved

• RPM_CLEARANCE

• RPM_CLEARANCE_RESET

Threading

The PurgeUnusedAndAbandonedClearancesBatch program is not threaded.

RefreshPosDataBatch Batch Design

The RefreshPosDataBatch batch is intended to provide the Point of Sale (POS) application with data refresh capability. This batch generates all future pending pricing information for a store, starting with a specified date that is passed as a parameter.

It then looks for pending price events pertaining to the specified store ID in the RPM_ FUTURE_RETAIL table and populates the payload tables with pending price event information, starting from the specified action date.

The information is then sent to POS for the purpose of refreshing all future price events for a store. The batch is not intended to be used for a new store or a new instance of POS in an existing store.

Usage

The following command runs the RefreshPosDataBatch job:

RefreshPosDataBatch.sh userAlias <location> [date (YYYYMMdd)]

Where the first argument is the username. The second argument is the store location id. The third argument is the action date from which the pricing information data is required. The action date must be in the format YYYYMMdd and must be set to VDATE+1 or greater. If the action date is not provided, the field will default to VDATE+1.

Detail

The RefreshPosDataBatch program deletes the contents of the payload tables listed in the following. It then looks for price events pertaining to the specified store id in RPM_FUTURE_RETAIL table and populates the payload tables with price event information, starting from the specified action data till the current day. If the action date is not specified, the program populates the payload tables with data starting from V-DATE+1. If the Warehouse ID needs to be specified as a location, then the system option, Recognize WHs as Location, must be set in System Options.

Assumptions and Scheduling Notes

RefreshPosDataBatch needs to run after the following batch process:

• RPMtoORPOSPublishBatch.sh

• regularPricechangePublishBatch.sh

• clearancePriceChangePublishBatch.sh

• promotionPriceChangePublishBatch.sh

Primary Tables Involved

• RPM_PRICE_EVENT_PAYLOAD

• RPM_PRICE_CHG_PAYLOAD

• RPM_CLEARANCE_PAYLOAD

• RPM_PROMO_DTL_PAYLOAD

• RPM_PROMO_DISC_LDR_PAYLOAD

• RPM_PROMO_DTL_LIST_GRP_PAYLOAD

• RPM_PROMO_DTL_LIST_PAYLOAD

• RPM_PROMO_DTL_PRC_RNG_PAYLOAD

• RPM_PROMO_DTL_PAYLOAD

• RPM_PROMO_FIN_DTL_PAYLOAD

• RPM_PROMO_ITEM_LOC_SR_PAYLOAD

• RPM_PROMO_ITEM_PAYLOAD

• RPM_PROMO_LOCATION_PAYLOAD

Output

There is no separate output. The data from the RPM_FUTURE_RETAIL populates the tables above.

Threading

The RefreshPosDataBatch program is threaded based on department count.

• The value of number of threads for the batch is independent of the column value NUM_THREADS in RPM_BATCH_CONTROL table.

• Number of threads used will be decided by two parameters.

  • Total number of department present in the DEPTS table (SELECT COUNT(*) FROM DEPS).

  • THREAD_LUW_COUNT value present in the RPM_BATCH_CONTROL table (SELECT thread_luw_count FROM RPM_BATCH_CONTROL WHERE program_name =
    'com.retek.rpm.batch.refreshPos.RefreshPosDataBatch').

Total number of threads used by this program is CEIL (total department / THREAD_LUW_COUNT)

For example, if the total departments = 10000, THREAD_LUW_COUNT=100m then number of threads used is 10000 / 100 = 100

so this means THREAD_LUW_COUNT is not just the departments, but it is number of departments per thread.

RegularPriceChangePublishBatch Batch Design

The RegularPriceChangePublishBatch program formats and stages output of regular price change price events.

The corresponding regularPriceChangePublishExport shell script produces a pipe ("|") delimited flat-file export based on the output of the RegularPriceChangePublishBatch.

Usage

The following command runs the RegularPriceChangePublishBatch job:

RegularPriceChangePublishBatch userAlias

The following command runs the regularPriceChangePublishExport job:

rregularPriceChangePublishExport.sh </@tnsaliasname> <slots> <log_path> <error_path> [export_path(optional)]

Where the first argument is the database connect alias (/@tnsaliasname), the second argument is to indicate the maximum number of concurrent threads should run at a time, the third and fourth argument are the path where the log file and error file should be written, and the last argument, the export_path is optional; if not supplied, the path ../output is used.

Detail

The batch looks for price events in the RPM_PRICE_EVENT_PAYLOAD table with a RIB_FAMILY of ”REGPRCCHG” and distributes those events to multiple threads based on the settings in the RPM_BATCH_CONTROL table. Each thread reads in its set of regular price change events from tables RPM_PRICE_EVENT_PAYLOAD and RPM_PRICE_CHG_PAYLOAD and generates output in RPM_PRICE_PUBLISH_DATA.

PurgePayloadsBatch should be run to delete records in the payload tables.

A flat-file per location based on the data from payload table that need to be published/processed will be created. The naming convention for the flat file will be (REGPC_<timestamp> _<location>_<loc_type>.dat), where <timestamp> is the current system time stamp, <location> is the location id and <loc_type> is the type of the location where 'S' is for Store and 'W' is for Warehouse.

Output Files

FHEAD (required): File identification, one line per file.

FDETL (optional): Price Change Event (Create or Modify).

FDELE (optional): Price Change Event (Delete).

FTAIL (required): End of file marker, one line per file.

Output File Layout

Table 7-6 Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
FHEAD	Record Descriptor	Char(5)	FHEAD	File head marker
	Line id	Number(10)	1	Unique line identifier
	File Type	Char(5)	REGPC	Regular Price Changes
	Export timestamp	Timestamp		System clock timestamp (YYYYMMDDHHMISS)
	Location	Number(10)		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
FDETL	Record Descriptor	Char(5)	FDETL	File Detail Marker (1 per price change create or modify)
	Line id	Number(10)		Unique line identifier
	Event Type	Char(3)		CRE = Create, MOD = Modify
	Id	Number(15)		Price Change identifier
	Item	Char(25)		Item identifier
	Effective Date	Date		Effective Date of price change (YYYYMMDDHH24MISS)
	Selling Unit Change Ind	Number(1)		Did selling unit retail change with this price event (0 = no change, 1 = changed)
	Selling Retail	Number(20,4)		Selling retail with price change applied
	Selling Retail UOM	Char(4)		Selling retail unit of measure
	Selling Retail Currency	Char(3)		Selling retail currency
	Multi-Unit Change Ind	Number(1)		Did multi-unit retail change with this price event (0 = no change, 1 = changed)
	Multi-Units	Number(12,4)		Number of multi-units
	Multi-Unit Retail	Number(20,4)		Multi-Unit Retails
	Multi-Unit UOM	Char(4)		Multi-Unit Retail Unit Of Measure
	Multi-Unit Currency	Char(3)		Multi-Unit Retail Currency
FDELE	Record Descriptor	Char(5)	FDELE	File Detail Delete Marker (1 per price change delete)
	Line id	Number(10)		Unique line identifier
	Id	Number(15)		Price Change identifier
	Item	Char(25)		Item identifier
FTAIL	Record Descriptor	Char(5)	FTAIL	File tail marker
	Line id	Number(10)		Unique line identifier
	Number of lines	Number(10)		Number of lines in file not counting FHEAD and FTAIL

Assumptions and Scheduling Notes

RegularPriceChangePublishBatch should be run after the WorksheetAutoApproveBatch.

RegularPriceChangePublishExport should be run after every successful run of RegularPriceChangePublishBatch.

Primary Tables Involved

• RPM_PRICE_EVENT_PAYLOAD

• RPM_PRICE_CHG_PAYLOAD

Threading

This program is threaded. The LUW is a single regular price change event.

Configuration

The following property must be set in rpm.properties on the application server when using this batch program to publish regular price events:

delete_staged_rib_payloads=false

RPMtoORPOSPublishBatch Batch Design

The RPMtoORPOSPublishBatch program formats and stages output of different price events like PriceChange, Clearance and Promotions. The RPMtoORPOSPublishExport shell script produces an xml file based on the output of the RPMtoORPOSPublishBatch.

Usage

The following command runs the RPMtoORPOSPublishBatch job:

RPMtoORPOSPublishBatch.sh <database-connect-alias> <log path> <error path>

Where the first argument is the RPM database-connect-alias (/@db_connection_alias). The second argument is the log path where the log file is written. The third argument is the error path where the error file is written.

Details

The batch took data for different price events in the payload and price event tables. Each price events have their own payload tables.

S.No.	Price Event	Related Tables
1	Regular Price Change	RPM_PRICE_CHG_PAYLOAD, RPM_PRICE_EVENT_PAYLOAD
2	Clearance	RPM_CLEARANCE_PAYLOAD, RPM_PRICE_EVENT_PAYLOAD
3	Promotion	RPM_PROMO_DTL_PAYLOAD RPM_PRICE_EVENT_PAYLOAD RPM_PROMO_LOCATION_PAYLOAD RPM_PROMO_DTL_LIST_GRP_PAYLOAD RPM_PROMO_DTL_LIST_PAYLOAD RPM_PROMO_DTL_PRC_RNG_PAYLOAD RPM_PROMO_ITEM_PAYLOAD RPM_PROMO_DTL_CIL_PAYLOAD RPM_PROMO_DTL_CIL_ITEM_PAYLOAD RPM_PROMO_DTL_CIL_LOC_PAYLOAD

The data collected from all these payload tables is formatted and inserted in different tables.

Price Event Type	Related Tables
Price Change	RPM_ORPOS_PRICE_CHANGE_PUBLISH
Clearance	RPM_ORPOS_PRICE_CHANGE_PUBLISH
Simple Promo	RPM_ORPOS_SIMPLE_PROMO_PUBLISH
Threshold Promo	RPM_ORPOS_CMPLX_PROMO_PUBLISH
Complex Promo	RPM_ORPOS_CMPLX_PROMO_PUBLISH
Transaction Promo	RPM_ORPOS_CMPLX_PROMO_PUBLISH

Output

There is no separate output. The data mentioned in the above tables are the output of the batch program.

Assumptions and Scheduling Notes

RPMtoORPOSPublishBatch should be run after WorksheetAutoApproveBatch.

Primary Tables Involved

• RPM_ORPOS_PRICE_CHANGE_PUBLISH

• RPM_ORPOS_SIMPLE_PROMO_PUBLISH

Configuration

The following property must be set in rpm.properties on the application server when using this batch program to publish all price events:

delete_staged_rib_payloads=false

RPMtoORPOSPublishExport Batch Design

The RPMtoORPOSPublishExport program calls the SQL script, RPMtoORPOSSpoolMsg.sql. This script spools the data collected from different publish tables of different price events (Price Change, Clearance and Promotion). The spooled file contains the data in XML format. The XML file complies with the given XSD standard for the Oracle Retail Point of Sale (ORPOS).

Usage

The following command runs the RPMtoORPOSPublishExport job:

RPRPMtoORPOSPublishExport.sh <database-connect-alias> <Number of slots>  <log path> <error path> <Export path> 

Where the first argument is the RPM database-connect-alias (/@db_connection_alias); the second argument is the number of slots (or number of threads to be executed in parallel); the third argument is the log path where the log file is written; the fourth argument is the error path where the error file is written; the fifth argument is the Export path or Result path where the generated xml files are written. The export path is optional. If it is not supplied, the present working directory (pwd) will be used for the same.

Note: The number of slots variable must be greater than zero. The log and error path parameters must be valid directories.

Detail

The batch looks for data in different publish tables.

• The batch invokes a SQL script by passing the store_id. In the SQL script, the spool filename is generated in the following way: PricingExtract_<store_id>.xml. A file is generated for all the stores whether price events exist or not. Each price event possesses different structures. These structures and values comply with the XSD standard.

• The batch script also invokes a spool routine to compile item import XML with list group IDs. The XML, ItemClassificationMod.xml, contains mod item messages that include the items and all applicable list group IDs for all stores.

Output File

The output file is an XML file (PricingExtract_<store_id>.xml) that is generated on a per store basis. The PricingExtract_<store_id>.xml file complies with the XSD standard for ORPOS and contains three different types of tag structures. The three types of tag structures are as follows:

RPM Price Event Name	ORPOS Equivalent Name / Tag Structure Name
Price Changes	Price Change
Clearances	Clearances
Simple Promotions	Price Promotion
Threshold/Multi-buy/Transaction Promotions	Discount Rule

Assumptions and Scheduling Notes

RPMtoORPOSPublishExport should be executed as follows:

• After every successful run of RPMtoORPOSPublishBatch.

• Before PurgePayloadsBatch is run.

Primary Tables Involved

• RPM_ORPOS_PRICE_CHANGE_PUBLISH

• RPM_ORPOS_SIMPLE_PROMO_PUBLISH

• RPM_ORPOS_CREDIT_PROMO_PUBLISH

• RPM_ORPOS_CMPLX_PROMO_PUBLISH

Threading

The RPMtoORPOSPublishExport program is threaded. The LUW is a single store.

Configuration

The following property must be set in rpm.properties on the application server when using this batch program to publish all price events:

delete_staged_rib_payloads=false

Note: When the RPM application server is installed on a SunOS operating system, the shell interpreter specification for this batch needs to be manually modified at the time of installation. It should be updated to use the Korn Shell interpreter rather than the Bourne Shell interpreter.

stagePromosForExtDashboard Batch Design

The stagePromosForExtDashboard batch program will retrieve valid promotions from RPM Promo tables at an item location level into a staging table. It is mainly used for external system or reporting purposes. Allocation OI functionality uses the data built by this batch process.

Usage

The following command runs the stagePromosForExtDashboard job:

stagePromosForExtDashboard.sh <connetion_alias> <slots> <luw> <log_path> <error_path>

where the first argument is the database connect alias (/@db_connection_alias), the second argument is to indicate the maximum number of concurrent threads should run at a time, the third argument is the logical unit of work per thread and the fourth and fifth arguments are where the log file and error file should be written.

Details

The stagePromosForExtDashboard batch retrieve all valid promotions from vdate+1 up to the next four weeks that are currently active or approved from RPM Promo tables and write it into the RPM_PROMO_DASHBOARD table at the item location level. The batch logic will not verify item-loc ranging when populating the RPM_PROMO_DASHBOARD table. Any external logic that queries data from this table will need to ensure ranging.

Assumptions and Scheduling Notes

stagePromosForExtDashboard should be run daily.

Primary Tables Involved

• RPM_PROMO_DASHBOARD_THREAD

• RPM_PROMO_DASHBOARD

• RPM_PROMO

• RPM_PROMO_COMP

• RPM_PROMO_DTL

• RPM_PROMO_DTL_MERCH_NODE

• RPM_PROMO_ZONE_LOCATION

• RPM_PROMO_DTL_DISC_LADDER

• RPM_PROMO_DTL_SKULIST

• RPM_MERCH_LIST_DETAIL

Threading

The stagePromosForExtDashboard batch is threaded by promotion detail id.

statusPageCommandLineApplication Batch Design

The status page batch program (statusPageCommandLineApplication.sh) performs some data checks, to verify that some of the assumptions that the application makes about the data are not violated. The checks are done with SQL counts; each check should return zero rows.

These are the data checks that are performed:

• Missing department aggregations-When departments are created in RMS, a row should be inserted into the RPM_DEPT_AGGREGATION table.

• Missing primary zone groups-Each merchandise hierarchy (department or lower) should have a row in the RPM_MERCH_RETAIL_DEF table.

• Missing item/locations from future retail-When an item is ranged to a location in RMS, a row should be inserted into the RPM_ITEM_LOC table.

• Duplicate future retail-There should only be one row in the RPM_FUTURE_RETAIL, RPM_PROMO_ITEM_LOC_EXPL, and RPM_CUSTOMER_SEGMENT_PROMO_FR tableS per item, item diff, location, zone_node_type, and action date.

• Missing future retail timelines-Timelines should match up between the RPM_FUTURE_RETAIL, RPM_PROMO_ITEM_LOC_EXPL, and RPM_CUSTOMER_SEGMENT_PROMO_FR tables

The command usage is as follows. Terms in <angle brackets> are required user inputs. Terms in [brackets] are optional:

1. statusPageCommandLineApplication.sh <userAlias> [phase-choice] [max-rows-choice]

2. statusPageCommandLineApplication.sh <userAlias> duplicate [dept=<department>[class=<class> [subclass=<subclass>]]]

3. statusPageCommandLineApplication.sh <userAlias> missing [dept=<department>[class=<class> [subclass=<subclass>]]]

To answer the questions from above one of the following valid values for [phase-choice] should be used. Or if no option is given the Both (B) option will be used:

S	System check only
D	Data integrity check only
B (default)	Both

The value specified for max-rows-choice is the maximum row count for the query. By default, the query is run for the full count.

To search for duplicate or missing data the second or third option of the command usage should be used. An optional Department/Class/Subclass hierarchy can be entered to narrow the search. If no hierarchy is given all data is checked.

The text below represents a sample output using the System Check Only (S) option. The output will be different for each of the different command usages:

tusPageCommandLineApplication.sh retailUser S

The following is sample output of the batch program:

The following RpmRibMessageStatusException is normal.
We need to throw an exception to ensure that the test messages are rolled back.
10:30:04,599 ERROR [ServiceAccessor] InvocationTargetException received on a service call...
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java(Compiled Code))
at com.retek.platform.service.ServiceCommandImpl.execute(ServiceCommandImpl.java(Compiled Code))
at com.retek.platform.service.impl.CommandExecutionServiceEjb.executeCommand(CommandExecutionServiceEjb.java(Compiled Code))
at com.retek.platform.service.impl.EJSRemoteStatelessCommandExecutionService_76208b17.executeCommand(Unknown Source)
at com.retek.platform.service.impl._EJSRemoteStatelessCommandExecutionService_76208b17_Tie.executeCommand__com_retek_platform_service_ServiceCommand(_EJSRemoteStatelessCommandExecutionService_76208b17_Tie.java(Compiled Code))
at com.retek.platform.service.impl._EJSRemoteStatelessCommandExecutionService_76208b17_Tie._invoke(_EJSRemoteStatelessCommandExecutionService_76208b17_Tie.java(Compiled Code))
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java(Compiled Code))
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java(Compiled Code))
at com.ibm.rmi.iiop.ORB.process(ORB.java(Compiled Code))
at com.ibm.CORBA.iiop.ORB.process(ORB.java(Compiled Code))
at com.ibm.rmi.iiop.Connection.doWork(Connection.java(Compiled Code))
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java(Compiled Code))
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java(Compiled Code))
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code))
*****************************************
Starting Report
com.retek.rpm.statuspage.RsmServerCheck Passed 
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmLoginCheck Passed 
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmDataAccessCheck Passed 
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed REGPRCCHG.REGPRCCHGCRE is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed REGPRCCHG.REGPRCCHGMOD is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed REGPRCCHG.REGPRCCHGDEL is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed CLRPRCCHG.CLRPRCCHGCRE is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed CLRPRCCHG.CLRPRCCHGMOD is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed CLRPRCCHG.CLRPRCCHGDEL is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed PRMPRCCHG.PRMPRCCHGCRE MULTIBUYPROMOCRE is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed PRMPRCCHG.PRMPRCCHGMOD MULTIBUYPROMOMOD is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
com.retek.rpm.statuspage.RpmRibMessageCheck Passed PRMPRCCHG.PRMPRCCHGDEL MULTIBUYPROMODEL is ON ************************The above exception indicates that we have passed ***************************
*****************************************
Starting Report
RpmJmsServerCheck Passed 
 
Done.

TaskPurgeBatch Batch Design

The TaskPurgeBatch program purges entries related to location move, conflict check, bulk conflict check and worksheet conflict check tables. In short all RPM_*TASK tables.

Usage

The following command runs the TaskPurgeBatch job:

taskPurgeBatch.sh <userAlias> [<purgeDays>] [Y/N]

Where the second argument is number if purge days (positive integer) and the last argument is the complete status indicator which is either Y or N.

Detail

The TaskPurgeBatch purges the entries from RPM_*TASK tables based on the entered purge days and the status indicator. The purge days is taken with respect to the VDATE in PERIOD table. All the entries before VDATE - purgeDays are purged. Also the status indicator is considered while the values are being purged. If the status indicator is Y, then only tasks with completed status are purged otherwise status is not considered while purging.

Assumptions and Scheduling Notes

TaskPurgeBatch can be run ad hoc.

Primary Tables Involved

• RPM_LOCATION_MOVE_TASK

• RPM_CONFLICT_CHECK_TASK

• RPM_BULK_CC_TASK

• RPM_WORKSHEET_CC_TASK

• RPM_TASK

• RPM_CHUNK_CC_TASK

Threading

TaskPurgeBatch.java is not threaded.

WorksheetAutoApproveBatch Batch Design

The WorksheetAutoApproveBatch program approves worksheets that have not been acted upon by the end of the review period. The strategies must be marked as auto-approve in order to be processed.

Usage

The following command runs the WorksheetAutoApproveBatch job:

WorksheetAutoApproveBatch userAlias

Where the argument is the user ID.

Detail

The WorksheetAutoApproveBatch first finds strategies to process. In order to qualify the strategies must meet the following criteria:

• The strategies must be a with its auto-approve indicator set.

• The strategies must be associated with a calendar review period that is ending.

For each strategy that qualifies, worksheet detail records are processed. In order to be processed the worksheet detail records must meet the following criteria:

• The worksheet detail must be marked as either undecided or take.

• The worksheet detail record must represent an actual change in the retail.

• The worksheet detail must be in one of the following states:

  • New

  • In progress

  • Pending

  • Submitted

  • Submit rejected

  • Updated

Each worksheet detail that meets the above criteria has run through the approval logic. The approval logic attempts to create and approve a price change. If the price change cannot be approved, the reason is written to the Conflict Check Results Dialogue. Additionally, area differential logic is executed.

If dynamic area differentials are being used in the system, any secondary area worksheet detail records that exist are also processed. If the secondary area is marked as auto approve, the secondary worksheet detail record goes through the same logic as the original worksheet detail (depending on its state). If the secondary area is not marked as auto approve, the secondary worksheet detail record has a retail proposed for it and moves into new status and becomes available for review by online users.

After all the worksheet details for the working strategy have been run through their approval logic, the worksheet status is updated to reflect the changes made to the details.

Assumptions and Scheduling Notes

WorksheetAutoApproveBatch can be run ad hoc.

Primary Tables Involved

• RPM_STRATEGY_MAINT_MARGIN

• RPM_WORKSHEET_STATUS

• RPM_WORKSHEET_ITEM_DATA

• RPM_WORKSHEET_ITEM_LOC_DATA

• RPM_WORKSHEET_ZONE_DATA

• RPM_PRICE_CHANGE

• RPM_CLEARANCE

• RPM_FUTURE_RETAIL

• RPM_AREA_DIFF_PRIM

• RPM_AREA_DIFF

• RPM_MAINT_MARGIN_ERR

• RPM_MAINT_MARGIN_ERR_DTL

Threading

This program is threaded but does not use the RPM_BATCH_CONTROL table. See Chapter 4, "Conflict Checking", for thread configuration information.

ZoneFutureRetailPurgeBatch Batch Design

The ZoneFutureRetailPurgeBatch program deletes old error message from the price change auto approve batch program.

Usage

The following command runs the PriceChangeAutoApproveResultsPurgeBatch job:

ZoneFutureRetailPurgeBatch.sh userAlias

Where the argument is the user ID.

Details

The ZoneFutureRetailPurgeBatch program deletes all zone/item price change actions which:

• Have an ACTION_DATE value prior to VDATE.

• Have been superseded by at least one other change action whose ACTION_DATE is also prior to VDATE.

The effect is that, for each zone/item with a price change history, the most recent such action, prior to VDATE, remains after the purge is complete.

Assumptions and Scheduling Notes

ZoneFutureRetailPurgeBatch can be run ad hoc.

Primary Tables Involved

RPM_ZONE_FUTURE_RETAIL

Threading

This program is not threaded.