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 Process�es

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 example below).�

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 Guidefor 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 are two exceptions to this run. The RPMtoORPOSPublishExport.sh and priceEventPayloadPopulationBatch.sh batches when run on a SunOS system, they 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.�

Script Catalog

Script	Batch program executed
clearancePriceChangePublishBatch.sh	ClearancePriceChangePublishBatch
clearancePriceChangePublishExport.sh	FutureRetailRollupBatch
FutureRetailRollUpBatch.sh
GenerateFutureRetailRollUpBatch.sh	GenerateFutureRetailRollupBatch
injectorPriceEventBatch.sh	injectorPriceEventBatch
itemLocDeleteBatch.sh	ItemLocDeleteBatch
itemReclassBatch.sh	itemReclassBatch
launchRpmBatch.sh	The retailer does not schedule this script. Other batch programs call this script behind the scenes. Note: This script sets up environment information and takes as a parameter the name of the batch program to run.
locationMoveBatch.sh	LocationMoveBatch
locationMoveScheduleBatch.sh
merchExtractKickOffBatch.sh	MerchExtractKickOffBatch
newItemLocationBatch.sh	NewItemLocationBatch
PriceChangeAreaDifferentialBatch.sh	PriceChangeAreaDifferentialBatch
priceChangeAutoApproveResultsPurgeBatch.sh	PriceChangeAutoApproveResultsPurgeBatch
priceChangePurgeBatch.sh	PriceChangePurgeBatch
priceChangePurgeWorkspaceBatch.sh	PriceChangePurgeWorkspaceBatch
priceEventExecutionBatch.sh	PriceEventExecutionBatch
priceEventExecutionDealsBatch.sh
priceEventExecutionRMSBatch.sh
priceEventPayloadPopulationBatch.sh	PriceEventPayloadPopulationBatch
priceStrategyCalendarBatch.sh	PriceStrategyCalendarBatch
primaryZoneModificationsBatch.sh
processPendingChunkBatch.sh	ProcessPendingChunkBatch
promotionArchiveBatch.sh	PromotionArchiveBatch
promotionPriceChangePublishBatch.sh	PromotionPriceChangePublishBatch
promotionPriceChangePublishExport.sh
promotionPurgeBatch.sh	PromotionPurgeBatch
purgeBulkConflictCheckArtifacts.sh	purgeBulkConflictCheckArtifacts
purgeExpiredExecutedOrApprovedClearancesBatch.sh	PurgeExpiredExecutedOrApprovedClearancesBatch
purgeLocationMovesBatch.sh	PurgeLocationMovesBatch
PurgePayloadsBatch.sh	PurgePayloadsBatch
purgeUnusedAndAbandonedClearancesBatch.sh	PurgeUnusedAndAbandonedClearancesBatch
refreshPosDataBatch.sh
regularPriceChangePublishBatch.sh	RegularPriceChangePublishBatch
regularPriceChangePublishExport.sh
RPMtoORPOSPublishBatch	RPMtoORPOSPublishBatch
RPMtoORPOSPublishExport	RPMtoORPOSPublishExport
statusPageCommandLineApplication.sh	statusPageCommandLineApplication
taskPurgeBatch.sh	TaskPurgeBatch
worksheetAutoApproveBatch.sh	WorksheetAutoApproveBatch
zoneFutureRetailPurgeBatch.sh	ZoneFutureRetailPurgeBatch

Scheduler and the Command Line�

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

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-2

Batch processes	Details
ClearancePriceChangePublishBatch	This batch process formats and stages output of clearance price change price events.
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.
GenerateFutureRetailRollUpBatch.sh	This batch is a conversion process that utilizes existing item/location level timeline data to create timelines at higher levels.
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 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.
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 change, promotions) pricing events.
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.
PurgeExpiredExecutedOrApprovedClearancesBatch	This batch process deletes expired clearances in Executed or Approved statuses.
PurgeLocationMovesBatch	This batch process cleans up expired/executed location moves
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.
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 maintain margin strategy 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.�"

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 userAlias

The following command runs the clearancePriceChangePublishExport job:�

clearancePriceChangePublishExport.sh database-connect-alias path�

Where the first argument is the database connect alias (/@db_connection_alias) and the second argument is the path where the file should be written. The path is optional and 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 format below), the associated records in the payload tables are deleted.�

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

A single flat-file (CLRPC_<timestamp>.pub�) is created, where <timestamp> is the current system time stamp.

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

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)
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
	Location	Number(10)		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
	Effective Date	Date		Clearance Effective Date (DD-MMM-YY)
	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
	Location	Number(10)		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
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

The following command runs the FutureRetailRollUpBatch job:

FutureRetailRollUpBatch userid [dept=<deptId> class=<classId> subclass=<subclassId>]

Where the argument is the user ID. The remaining arguments are optional, but the merchandise hierarchy to be processed can be specified.

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 after every successful run of GenerateFutureRetailRollUpBatch. As it runs, other processes must not access the future retail tables. After the conversion/upgrade, 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.

GenerateFutureRetailRollUpBatch Design

This batch is a conversion process that utilizes existing item/location level timeline data and create timelines at higher levels.

Usage

The following command runs the GenerateFutureRetailRollUpBatch job:

GenerateFutureRetailRollUpBatch userid [dept=<deptId> class=<classId> subclass=<subclassId>]

Where the argument is the user ID. The remaining arguments are optional, but the merchandise hierarchy to be processed can be specified.

Details

The batch calls the package, RPM_GENERATE_ROLLUP_FR_SQL.THREAD_ROLLUP_FR and RPM_GENERATE_ROLLUP_FR_SQL. GENERATE_ROLLUP_FR. This package generates timelines above the Item/Location level using existing Item/Location level timelines as described below:

For every Parent/Zone combination within the MOM infrastructure, this conversion script gathers up all existing Item/Location timelines on Future Retail and counts the number of records in each timeline with price events affecting them (by looking at the price_change_id field, the clearance_id, on_simple_promo_ind and on_complex_promo_retail), along with the total number of records for each timeline.
With these two counts at hand, all timelines with the same count of records in their timelines are grouped together. For the sake of example, the group with the greatest number of timelines in it is Group A.
The timelines are sorted by the count of price events affecting that timeline. The timelines with the fewest price events affecting them are identified.
In the order specified here, the timeline in Group A with the fewest price events and the fewest location moves affecting it is selected. If there is more than one timeline that meets these requirements, the timeline with the Item ID that has the smallest value is selected. If more than one timeline meets these requirements, the timeline with the smallest Location ID value is selected from the remaining timelines.
For every Item/Zone combination within MOM, where the item has no parent item, the same logic is utilized, except the information is grouped initially by Item/Zone rather than by Parent/Zone.
For every Parent/Loc combination within MOM, the same logic is utilized, except the information is grouped initially by Parent/Location rather than by Parent/Zone. This is done for all locations, regardless of whether the location is part of the primary zone group for the given item's merchandise hierarchy.
For every Parent-Diff/Zone combination within MOM for diff_1 items above the transaction level, the same logic is utilized, except the information is grouped initially by Parent-Diff/Zone rather than by Parent/Zone.
For every Parent-Diff/Loc combination within MOM, for diff_1 items above the transaction level, the same logic is utilized, except the information is grouped initially by Parent-Diff/Location rather than by Parent/Zone. This is done for all locations, regardless of whether the location is part of the primary zone group for the given item's merchandise hierarchy.

The Item/location timelines that are selected to be copied for generating higher level timelines are not necessarily those that will allow the FutureRetailRollUpBatch process to reduce the data load as much as it possibly could. However, this process allows the system to remove lower level timelines in the future, as the future retail timelines will become more and more in line from higher to lower levels (for example,from Parent/Zone level to Item/Location level).

Assumptions and Scheduling Notes

This process has to be executed as part of a conversion/upgrade process.

Primary Tables Involved

RPM_FUTURE_RETAIL
RPM_PROMO_ITEM_LOC_EXPL
RPM_CUST_SEGMENT_PROMO_FR

Threading

The GenerateFutureRetailRollUpBatch program is threaded by item.

InjectorPriceEventBatch Batch Design�

The price events injecting batch process (InjectorPriceEventBatch.java) performs the necessary work to import pricing events (regular price changes, clearance price changes and simple promotions) and optionally submit the events for approval.�

Usage�

Use the following command to run the job:�

InjectorPriceEventBatch 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), 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) or SP (simple 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 diapason for the interval is 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 event_type=CL status=W 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 by means of shell script injectorPriceEventBatch.sh.�

Details�

The batch program imports regular price changes, clearance, and simple promotions that have been generated by an external to RPM application. 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 changes 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.�
No vendor funding is allowed.�
No deals are allowed.�

Other than the field carrying data payload, the table holds fields that facilitate data processing.�

Auto approve indicator defines whether the processing batch should attempt to approve the price change after successfully importing the data.
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) and F (Failed). Initial data should be created in the New status. The rest of the statuses are the result of data lifecycle.

The records in all but Approved statuses are eligible for processing by the batch:
- 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.
- Approved status indicates the data has been successfully imported and successfully approved without any conflicts.�
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.�
Price change display ID is populated only upon successful import of the data.�

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�.
No reset records are allowed.�
No vendor funding is allowed.�
No deals are allowed�.

As the PROMO_ID column in the RPM_STAGE_PROMO_COMP_SIMPLE table is a required column, this batch job does not generate the Promotion Header record and assumes the simple promotion will be injected into an existing Promotion Header. This can be achieved by using the existing Promotion Header or by populating the Promotion Header (RPM_PROMO table) before populating the RPM_STAGE_PROMO_COMP_SIMPLE staging table.

Other than the field carrying data payload, the table holds fields that facilitate processing.�

Auto approve indicator defines if the processing batch should attempt to approve the clearance after successfully importing the data.�
Status defines the current state of the data. Possible statuses are N (New), W (Worksheet), A (Approved), E (Error) and F (Failed). Initial data should be created in the N (New) status. The rest of the statuses are the result of data lifecycle. The records in all but Approved statuses are eligible for processing. �
- 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.
- Approved status indicates the data has been successfully imported and successfully approved without any conflicts.�
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.�
Clearance display ID is populated only upon successful import of the data.�

Importing Staged Simple Promotions�

Staged simple promo data should be placed by the system data administrator into RPM_STAGE_PROMO_COMP_SIMPLE table. The table has the structure similar to that of RPM_PROMO_COMP_SIMPLE but with the limitation that no exceptions are allowed.�

Other than the field carrying data payload, the table holds fields that facilitate processing.�

Auto approve indicator defines if the processing batch should attempt to approve the promotion after successfully importing the data.�
Status defines the current state of the data. Possible statuses are N (New), W (Worksheet), A (Approved), E (Error) and F (Failed). Initial data should be created in the N (New) status. The rest of the statuses are the result of data lifecycle. The records in all but Approved statuses are eligible for processing.
- 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.
- Approved status indicates the data has been successfully imported and successfully approved without any conflicts.�
The error message field indicates the first error encountered while importing the data. The field actually holds an error message key rather than the actual error message. �
Process ID uniquely identifies the batch run. The field is populated for records with all statuses except New.�

Main Steps Taken by the Batch�

Generate the pricing events (import pricing events). This step loads data from the staging table (actual table depends on the event type specified as a batch argument). 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 ERROR. 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 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 populating the staging data should set auto approval flag on the record to ON (AUTO_APPRVE_IND should be set to 1).

In this case the batch attempts to approve the price event. This involves conflict checking, which can take quiet a long time depending on the volume of data. This step ends only when the approval process reports completion of all threads responsible for conflict checking. Depending on the volume of data, the interval the batch uses to poll conflict checking logic for completion should be adjusted accordingly. �
If auto approval was not requested or approval process failed, the data is left in appropriate RPM table in Worksheet status. If the approval is successful, the data is in Approved status. The status on the staging table after the approval step is either Approved or Failed, depending on how the process terminates. �
The conflict checking logic does not purge intermediate data to allow the batch to inquire on the state of the conflict checking process. After it was determined that the CC logic is complete the batch purges CC intermediate data.�
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�

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 cannot be processed again.�

Primary Tables Involved�

RPM_STAGE_PRICE_CHANGE and RPM_PRICE_CHANGE.�
RPM_STAGE_CLEARANCE and RPM_CLEARANCE.�
RPM_STAGE_PROMO_COMP_SIMPLE, 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.�

These tables provide data to be imported by the batch. Each record is independently processed.�

Threading�

The InjectorPriceEventBatch program is not threaded by itself. The main batch logic is executed as part of a single thread. At the same time the batch relies for approval on a multi-threaded conflict checking logic. The batch polls this logic with the interval defined by the polling_interval parameter to identify the completion point.�

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:�

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.�
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. 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. �

Usage�

The following command runs the ItemLocDeleteBatch job:�

�ItemLocDeleteBatch.sh userAlias

The argument is the user ID.�

Follow these steps to use this batch:�

Delete existing records from the table RPM_STAGE_DELETED_ITEM_LOC.�
Enable the new trigger RMS_TABLE_RPM_ITL_AIR on table ITEM_LOC.�
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 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�
RPM_ITEM_LOC

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 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.

Detail �

The batch looks for scheduled zone location move 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 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 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 FUTURE_RETAIL.�
Conflict checking is run on FUTURE_RETAIL after event 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 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 (third 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 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 schedule 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 "Sheduled" 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 userAlias <mode>�

where userid 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 date 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 PriceStrategyCalendarBatch:�

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 and location 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 userAlias <status> <logical commit count>]

The last two arguments are optional and direct the application as to what ”status” (the rows in the stage table with a status of N or E (new or error) and logical unit of work per thread to process. If none is indicated the logical unit of work is used for processing new rows.�

To use the batch, follow these steps.�

Delete existing records from table RPM_STAGE_ITEM_LOC�.
Enable the new trigger RMS_TABLE_RPM_ITL_AIUDR in table ITEM_LOC.�
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 FUTURE_RETAIL table to reflect the new item/location combination. If any approved price changes/promotions/clearances exist at a parent/zone level that encompasses the new item/location, these are also added to the FUTURE_RETAIL table for the new item/location.� Any active promotions that encompass the new item/location are also added to the RPM_FUTURE_RETIAL 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 create sall 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. 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

Threading�

NewItemLocBatch is threaded. RPM_BATCH_CONTROL should include a record for NewItemLocBatch for it to run in threaded mode. But if all the item/locations to be processed are related, then it will be processed in a single thread irrespective of the LUW count. In addition, if there are price events to inherit, then it chooses a path based on batch control settings similar to the ones for a price event approval from the UI, and it chooses to go to chunking or bulking based on the setting and volume of data.�

Bulk Conflict Checking�

This program now utilizes the new 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.�

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 job: �

PriceChangeAreaDifferentialBatch userAlias�

Additional Notes �

The batch should be run by means of the shell script named priceChangeAreaDifferentialBatch.sh. �

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 userAlias�

Detail �

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 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 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 require 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 RMS. 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 is 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.�

Usage�

The following commands need to be executed in order:�

PriceEventExecutionBatch userAlias [restartInd Y|N]
PriceEventExecutionRMSBatch userAlias
PriceEventExecutionDealsBatch 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.�
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_CLEARANCE.�
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 and 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 below.

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 promotions 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 procesesd 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.

PriceEventPayloadPopulationBatch Batch Design

The payload population batch batch process maintains payload population batch assigned to price strategies.

Usage

The following command runs the priceEventPayloadPopulationBatch job:

priceEventPayloadPopulationBatch.sh database-connect-string <slots> <status> <logpath> <error path>

Where the first argument is the database connection string and the second argument specifies how many threads should be run concurrently. The thirdargument specifies the status to process. Valid values are New and Error. The last two arguments specify where the log and error files should be generated, respectively.

Details

The batch first threads all staged data for payload population based on price event ID and bulk_cc_pe_id. Each thread is then processed and data is written to the necessary payload tables for the price event. Upon completion, the status of the thread is updated to C.

This batch should only be used when the value for RPM_SYSTEM_OPTIONS. CC_DIRECT_PAYLOAD_POPULATION is set to 0 indicating that the payload tables should not be populated as part of the conflict checking process.

Assumptions and Scheduling Notes

This batch can be run ad-hoc. The PriceEventPayloadPopulationBatch must run before the following programs:

RPMtoORPOSPublishBatch.sh
regularPriceChangePublishBatch.sh
promotionPriceChangePublishBatch.sh
clearancePriceChangePublishBatch.sh

Primary Tables Involved

RPM_STAGE_PUBLISH_DATA
RPM_STG_UPD_RST_ON_CLR_RMV
RPM_FUTURE_RETAIL_PL_STAGE
RPM_PROMO_IL_EXPL_PL_STAGE
RPM_CS_PROMO_FR_PL_STAGE
RPM_CLEARANCE_PL_STAGE
RPM_PROMO_LOCATION_PAYLOAD
RPM_PROMO_ITEM_PAYLOAD
RPM_PROMO_ITEM_LOC_SR_PAYLOAD
RPM_PROMO_FIN_DTL_PAYLOAD
RPM_PROMO_DTL_PAYLOAD
RPM_PROMO_DTL_LIST_PAYLOAD
RPM_PROMO_DTL_LIST_GRP_PAYLOAD
RPM_PROMO_DISC_LDR_PAYLOAD
RPM_PRICE_EVENT_PAYLOAD
RPM_PRICE_CHG_PAYLOAD
RPM_CLEARANCE_PAYLOAD

Threading

The priceEventPayloadPopulationBatch.sh program is threaded by price event and bulk_cc_pe_id.

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.�

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 userAlias

Detail �

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 update sthe 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 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 userAlias

Detail �

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 <database-connect-alias> <log-path> <error-path> <process-type> 

Where the first argument is the 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; the last argument is process type. Valid values are 1(process all promos at a time), 2( process one promo at a time). The process-type is optional and if not supplied, it will be defaulted to 1.

Detail �

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_LADDER
RPM_PROMO_DTL_MERCH_NODE
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_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 userAlias

The following command runs the promotionPriceChangePublishExport job:�

promotionPriceChangePublishExport.sh database-connect-alias path�

Where the first argument is the database connect alias (/@db_connect_alias) and the second argument is the path where the file should be written. The 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 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 below) and generates output in RPM_PRICE_PUBLISH_DATA.

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

A single flat-file (PRMPC_<timestamp>.pub�) is created, where <timestamp> is the current system time stamp.�

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_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.
TLLST (required): Promotion Location List (one or more per TPDTL).
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).
TPILSR (optional): Promotion Item Location Selling retail (one or more per TPDTL).
TPCDT (optional): Promotion Credit Detail (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

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)
	Format Version	Char(5)	1.0	File Format Version
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 (YYYYMMDD)
	End Date	Date		End Date of Promotion Component Detail (YYYYMMDD)
	Apply Order	Number(1)		Application Order of the Promotion
	Threshold Id	Number(6)		Threshold identifier
	Customer Type Id	Number(10)		Customer Type identifier
TLLST	Record Descriptor	Char(5)	TLLST	Promotion Detail Component
	Line id	Number(10)		Unique line identifier
	Location Id	Number(10)		Org Node (Store or Warehouse) identifier
	Location Type	Char(1)		Org Node Type (Store or Warehouse)
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
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
	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
TPILSR	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
	Location Id	Number(10)		Org Node (Store or Warehouse) identifier
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
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
	Location Id	Number(10)		Org Node (Store or Warehouse) 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�

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 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_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 userAlias

Where the argument is the user ID.

Detail�

The current release of RPM comes with the Bulk Conflict Checking and Chunk Conflict Checking engines. 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 Bulk 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

PurgeExpiredExecutedOrApprovedClearancesBatch Batch Design�

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

Usage�

The following command runs the PurgeExpiredExecutedOrApprovedClearancesBatch job:�

PurgeExpiredExecutedOrApprovedClearancesBatch <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.

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 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. �

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.shsh db_connection_alias <publish-status>_<log-path>

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

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:

<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

<publish-status>

Description

This setting results in purged price events that have been exported by RMPtoORPOSPublishExport.sh

This setting results in purged price events that have been exported by any one of the following:

regularPriceChangePublishExport.sh

clearancePriceChangePublishExport.sh

promotionPriceChangePublishExport.sh

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:

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
3	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 <database-connect-alias> <log path> <error path>

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 <username> <location>[date (YYYYMMdd)]�

Where the first argument is the username. The second argument is the store location id. The fourth 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 below. 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 can be run ad hoc. �

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_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 database-connect-alias path

Where the first argument is the database connect alias (/@db_connection_alias) and the second argument is the path where the file should be written. The 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 single flat-file (REGPC_<timestamp>.pub) is created, where <timestamp> is the current system time stamp.�

Output File�s

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

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)
	Format Version	Char(5)	1.0	File Format Version
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
	Location	Number(10)		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
	Effective Date	Date		Effective Date of price change �(DD-MMM-YY)
	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 Retail
	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
	Location	Number(10)		Location identifier
	Location Type	Char(1)		S = Store, W = Warehouse
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 <database-connect-alias> <log path> <error path>

Detail

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_ITEM_PAYLOAD

S.No.

Price Event

Related Tables

Regular Price Change

RPM_PRICE_CHG_PAYLOAD,

RPM_PRICE_EVENT_PAYLOAD

Clearance

RPM_CLEARANCE_PAYLOAD,

RPM_PRICE_EVENT_PAYLOAD

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_ITEM_PAYLOAD

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

S.No.	Price Event	Related Tables
1	Price Change	RPM_ORPOS_PRICE_CHANGE_PUBLISH
2	Clearance	RPM_ORPOS_PRICE_CHANGE_PUBLISH
3	Simple Promo	RPM_ORPOS_SIMPLE_PROMO_PUBLISH
4	Threshold Promo	RPM_ORPOS_CMPLX_PROMO_PUBLISH
5	Complex 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. This batch should be executed before the following batches.

RegularPriceChangePublishBatch
RegularPriceChangePublishExport
ClearancePriceChangePublishBatch
ClearancePriceChangePublishExport
PromotionPriceChangePublishBatch
PromotionPriceChangePublishExport

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). Spooled file contains the data in XML format. The XML file complies with the given XSD standard.

Usage

The following command runs the RPMtoORPOSPublishExport job:

RPRPMtoORPOSPublishExport <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 "pwd" (present working directory) 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 a valid directory at the same level as PWD.

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 new 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.

OutputFile

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 should comply with the XSD standard and contain three different types of tag structures. The three types of tag structures are as follows:

S.No.	RPM Price Event Name	ORPOS Equivalent Name / Tag Structure Name
1	Price Change/Clearance	Price Change
2	Simple Promotion	Price Promotion
3	Threshold/Multi-buy Promotion	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:

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:�

statusPageCommandLineApplication.sh <userAlias> [phase-choice] [max-rows-choice]
statusPageCommandLineApplication.sh <userAlias> duplicate [dept=<department>[class=<class> [subclass=<subclass>]]]
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:�

../statusPageCommandLineApplication.sh retailUser S

The following is sample output of the batch program:�

Performing System Check�
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:216)�
at com.retek.platform.service.ServiceAccessor.callRemoteMethod(ServiceAccessor.java:300)�
at com.retek.platform.service.ServiceAccessor.remoteTransaction(ServiceAccessor.java:485)�
at com.retek.platform.service.ServiceAccessorProxy.invoke(ServiceAccessorProxy.java:51)�
at $Proxy4.performRibMessageCheck(Unknown Source)�
at com.retek.rpm.statuspage.RpmRibMessageCheck.execute(RpmRibMessageCheck.java:25)�
at com.retek.rpm.statuspage.StatusPageCheck.runTest(StatusPageCheck.java:15)�
at com.retek.rpm.statuspage.StatusPageProcessor.execute(StatusPageProcessor.java:19)�
at com.retek.rpm.statuspage.StatusPageCommandLineApplication.performAction(StatusPageCommandLineApplication.java:80)�
at com.retek.rpm.statuspage.StatusPageCommandLineApplication.main(StatusPageCommandLineApplication.java:65)�
Caused by: �
<com.retek.rpm.app.statuspage.service.RpmRibMessageStatusException>�
<message>�
  No cause associated�
</message>�
</com.retek.rpm.app.statuspage.service.RpmRibMessageStatusException>�
�
at com.retek.rpm.app.statuspage.service.StatusPageAppServiceImpl.performRibMessageCheck(StatusPageAppServiceImpl.java:71)�
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)�
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))�
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))�
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 maintain margin strategy 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 maintain margin strategy 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 be 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. Please 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 userAlias

Where the argument is the user ID.

Detail �

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.�