Skip Headers
Oracle® Retail Advanced Inventory Planning Operations Guide
Release 14.1.1
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

3 AIP Interfaces and Transformation Scripts

The AIP system interfaces with the merchandising system, the forecasting system, and any other external system that provides data in the predetermined file format. This chapter provides information on how AIP interfaces with various RMS versions and RDF. For a complete list of supported RMS versions, see the Oracle Retail Advanced Inventory Planning Installation Guide.

RMS to AIP Interfaces and Transformation Scripts

During AIP installation, the RMS-AIP transform scripts and output schema files were installed to a directory specified by the user, as the Dir to store RMS transform files. This location is referred to as $RMS_AIP_TRANSFORM for this section. Refer to the Oracle Retail Advanced Inventory Planning Installation Guide for more information about the installation details.

The AIP installation includes a separate set of transformation scripts for interfacing with RMS 10, 11, and 13.0/13.1. These were installed to
$RMS_AIP_TRANSFORM/k_shell_scripts. The schema files in $RMS_AIP_TRANSFORM/aip_schema_dir are used for interfacing with any version of RMS. The following documentation describes the differences in the interfacing process for each version of RMS.

The overall process of interfacing RMS with AIP begins with generation of the RMS RETL extracts. A separate set of RMS extract scripts and schema files control this generation. These scripts and schema are not included in the AIP installation.

After generating the RMS RETL extracts, the RMS-AIP transformation scripts convert the RMS RETL extracts into RPAS loadable format. There are two sets of schema files: one which matches the formats of the RMS RETL extract files, and a second which matches the formats of the RPAS-loadable files.

Transform Interface Scripts

Location: $RMS_AIP_TRANSFORM/k_shell_scripts and $RPAS_HOME/bin

The Transform Interface Scripts are the Korn shell scripts used to drive the process for transforming the RMS RETL extract files into AIP RPAS domain-loadable files.

The $RMS_AIP_TRANSFORM/k_shell_scripts directory's contents should have been copied to $RPAS_HOME/bin during installation.

The execution of these scripts is controlled by running the master script:

  • aip_t_master_rms10.ksh for RMS 10.x

  • aip_t_master_rms11.ksh for RMS 11.x

  • aip_t_master_rms13.ksh for RMS 13.1/13.0

  • aip_t_master_rms13.2.ksh for RMS 13.2

  • aip_t_master_rms14.0.ksh for RMS 14.0

These scripts are run before running the AIP RPAS batch.

RMS 14.0 Transform Interface Scripts

The execution of these scripts is controlled by running the master script, aip_t_master_rms14.0.ksh for RMS 14.0 transforms.

These scripts are run before running the AIP RPAS batch.

For RMS 14.0, $RPAS_HOME/bin must contain the following scripts:

  • aip_t_master_rms14.0.ksh

  • aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl

  • aipt_delete_input_files.ksh

  • aipt_future_delivery_rms14.0.ksh

  • aipt_item_rms14.0.ksh

  • aipt_move.ksh

  • aipt_orghier_rms14.0.ksh

  • aipt_rename.ksh

  • aipt_sr0_dayslsld_rms14.0.ksh

  • aipt_str_prd_life_rms14.0.ksh

  • aipt_sub_item_rms14.0.ksh

RMS 13.2 Transform Interface Scripts

The execution of these scripts is controlled by running the master script, aip_t_master_rms13.2.ksh for RMS 13.2 transforms.

These scripts are run before running the AIP RPAS batch.

For RMS 13.2, $RPAS_HOME/bin must contain the following scripts:

  • aip_t_master_rms13.2.ksh

  • aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl

  • aipt_delete_input_files.ksh

  • aipt_future_delivery_rms13.2.ksh

  • aipt_item_rms13.2.ksh

  • aipt_move.ksh

  • aipt_orghier_rms13.2.ksh

  • aipt_rename.ksh

  • aipt_sr0_dayslsld_rms13.2.ksh

  • aipt_str_prd_life_rms13.2.ksh

  • aipt_sub_item_rms13.2.ksh

RMS 13.1/13.0 Transform Interface Scripts

The execution of these scripts is controlled by running the master script, aip_t_master_rms13.ksh for RMS 13.1/13.0 transforms.

These scripts are run before running the AIP RPAS batch.

For RMS 13.1/13.0, $RPAS_HOME/bin must contain the following scripts:

  • aip_t_master_rms13.ksh

  • aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl

  • aipt_delete_input_files.ksh

  • aipt_future_delivery_rms13.ksh

  • aipt_item_rms13.ksh

  • aipt_move.ksh

  • aipt_orghier_rms13.ksh

  • aipt_pad.ksh, aipt_pad_splr.awk, aipt_pad_whse.awk

  • aipt_rename.ksh

  • aipt_sr0_dayslsld_rms13.ksh

  • aipt_str_prd_life_rms13.ksh

  • aipt_sub_item_rms13.ksh

RMS 11 Transform Interface Scripts

The execution of these scripts is controlled by running the master script,
aip_t_master_rms11.ksh for RMS 11 transforms. These scripts are run before the AIP RPAS batch is run.

For RMS 11, $RPAS_HOME/bin must contain the following scripts:

  • aip_t_master_rms11.ksh

  • aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl

  • aipt_delete_input_files.ksh

  • aipt_future_delivery_rms11.ksh

  • aipt_item_rms11.ksh

  • aipt_move.ksh

  • aipt_orghier_rms11.ksh

  • aipt_pad.ksh, aipt_pad_splr.awk, aipt_pad_whse.awk

  • aipt_rename.ksh

  • aipt_sr0_dayslsld_rms11.ksh

  • aipt_str_prd_life_rms11.ksh

  • aipt_sub_item_rms11.ksh

RMS 10 Transform Interface Scripts

The execution of these scripts is controlled by running the aip_t_master_rms10.ksh for RMS 10 transforms. These scripts are run before the AIP RPAS batch is run.

For RMS 10, $RPAS_HOME/bin must contain the following scripts:

  • aip_t_master_rms10.ksh

  • aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl

  • aipt_delete_input_files.ksh

  • aipt_future_delivery_rms10.ksh

  • aipt_item_rms10.ksh

  • aipt_move.ksh

  • aipt_orghier_rms10.ksh

  • aipt_pad.ksh, aipt_pad_splr.awk, aipt_pad_whse.awk

  • aipt_rename.ksh

  • aipt_sr0_dayslsld_rms10.ksh

  • aipt_str_prd_life_rms10.ksh

  • aipt_sub_item_rms10.ksh

Input Schema Files

Location: The schema files matching the RMS RETL extracts are provided by the RMS installation. These files are owned by RMS and are not included with the AIP Package.

Input schema files are the schema files which are required by the Transform Interface scripts to read the RETL extracts from RMS.

These files are used as output schema by the RMS RETL extract scripts.

RMS 14.0, 13.2, 13.1/13.0, and RMS 11 Input Schema Files

For RMS 14.0, 13.2, 13.1/13.0, and RMS 11, the $RMS_ SCHEMA_DIR directory (refer to aip_env_rpas.sh in the Oracle Retail Advanced Inventory Planning Implementation Guide) must contain the following input schema files from the RMS installation:


Note:

While the file names for these schema files do not differ among RMS versions 14.0, 13.2, 13.1/13.0, and RMS 11, the contents of the files vary among the four versions. Ensure you copy in the correct version of the RMS output schema into $RMS_SCHEMA_DIR.

  • rmse_aip_alloc_in_well.schema

  • rmse_aip_dmx_bndprdasc.schema

  • rmse_aip_future_delivery_alloc.schema

  • rmse_aip_future_delivery_order.schema

  • rmse_aip_future_delivery_tsf.schema

  • rmse_aip_item_loc_traits.schema

  • rmse_aip_item_master.schema

  • rmse_aip_item_retail.schema

  • rmse_aip_item_supp_country.schema

  • rmse_aip_merchhier.schema

  • rmse_aip_orghier.schema

  • rmse_aip_purged_item.schema

  • rmse_aip_store.schema

  • rmse_aip_substitute_items.schema

  • rmse_aip_tsf_in_well.schema

  • rmse_aip_wh.schema

  • rmse_aip_wh_dat.schema

  • rmse_rpas_daily_sales.schema

RMS 10 Input Schema Files

For RMS 10, the $RMS_SCHEMA_DIR directory (refer to aip_env_rpas.sh in the Oracle Retail Advanced Inventory Planning Implementation Guide) must contain the following input schema files from the RMS installation:

  • rmse_aip_item_master.schema

  • rmse_alloc_in_well.schema

  • rmse_daily_sales.schema

  • rmse_dmx_bndprdasc.schema

  • rmse_future_delivery_alloc.schema

  • rmse_future_delivery_order.schema

  • rmse_future_delivery_tsf.schema

  • rmse_item_loc_traits.schema

  • rmse_item_retail.schema

  • rmse_item_supp_country.schema

  • rmse_merchhier.schema

  • rmse_orghier.schema

  • rmse_purged_item.schema

  • rmse_store.schema

  • rmse_substitute_items.schema

  • rmse_tsf_in_well.schema

  • rmse_wh.schema

  • rmse_whse1.schema

Output Schema Files

Location: $RMS_AIP_TRANSFORM/aip_schema_dir

Output Schema files are the schema files which are required by the Transform Interface scripts to write the AIP loads/feeds. These files are owned by AIP and should have been unpacked to $RMS_AIP_TRANSFORM/aip_schema_dir during AIP installation.

These output schema files are the same regardless of which version of RMS is interfaced with AIP.

The $AIP_SCHEMA_DIR (refer to aip_env_rpas.sh in the Oracle Retail Advanced Inventory Planning Implementation Guide) directory must contain the following output schema files from the AIP installation:

  • aipt_dm0_pmsendsrc.schema

  • aipt_dm0_pmsstasrc.schema

  • aipt_dmx_dscdt_.schema

  • aipt_dmx_vadprdasc.schema

  • aipt_item.schema

  • aipt_loc.schema

  • aipt_sr0_dayslsld.schema

  • aipt_sr0_it_.schema

  • aipt_sr0_oo_.schema

  • aipt_str_prd_life.schema

  • aipt_wr1_aiw.schema

  • aipt_wr1_it_.schema

  • aipt_wr1_oo_.schema

  • aipt_wr1_tiw.schema

RETL Extracts (Data Files from RMS)

Location: RMS server

The RETL Extracts from RMS are used as AIP loads/feeds. Following are the four categories of RETL Extracts:


Note:

The four sets of files must be copied from the RMS server to the AIP server, into the $RAW_RMS_DATA_DIR directory.

RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts

The following sections list the RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts for each group described in Table 3-1.

Needed by AIP RPAS Domain: RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts that are Transformed

Following is the list of RETL Extracts that are used by the RMS 14.0, 13.2, and 13.1/13.0-AIP Interface Transform scripts to generate a new set of AIP RPAS loads/feeds.

  • date_format_preference.txt

  • dmx_bndprdasc.txt

  • last_day_of_week.txt

  • rmse_aip_alloc_in_well.dat

  • rmse_aip_future_delivery_alloc.dat

  • rmse_aip_future_delivery_order.dat

  • rmse_aip_future_delivery_tsf.dat

  • rmse_aip_item_loc_traits.dat

  • rmse_aip_item_master.dat

  • rmse_aip_item_retail.dat

  • rmse_aip_item_supp_country.dat

  • rmse_aip_merchhier.dat

  • rmse_aip_orghier.dat

  • rmse_aip_purged_item.dat

  • rmse_aip_store.dat

  • rmse_aip_substitute_items.dat

  • rmse_aip_tsf_in_well.dat

  • rmse_aip_wh.dat

  • rmse_aip_wh.txt

  • rmse_aip_wh_type.txt

  • rmse_rpas_clndmstr.dat

  • rmse_rpas_daily_sales.dat


Note:

dmx_bndprdasc.txt is used by the transformation process, but is also a direct feed into AIP RPAS.

Needed by AIP RPAS Domain: RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts that are not Transformed

The following are the RETL extracts used by RMS 14.0, 13.2, and 13.1/13.0that do not need to be transformed by AIP

  • splr.txt

  • dmx_dirspl.txt

  • dmx_prdspllks.txt

  • sr0_curinv_[1..n].txt

  • wr1_curinv.txt


Note:

As previously shown, the sr0_curinv data feed may be partitioned. For example: sr0_curinv_1.txt, sr0_curinv_2.txt. The data always has at least one partition, namely sr0_curinv_1.txt. AIP RPAS batch steps combine any partitions before loading the data into the AIP domain.

Needed by AIP Oracle Database: RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts that are not Transformed

Following are the RMS 14.0, 13.2, and 13.1/13.0 RETL extracts which are not used by AIP RPAS batch but are used by AIP Oracle batch.

  • closed_order.txt

  • received_qty.txt

RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts that are not used by AIP

Following are the RMS 14.0, 13.2, and 13.1/13.0 RETL extracts which at this time are not used by AIP.

  • rmse_aip_item_supp_country_reject_ord_mult.txt

  • rmse_aip_suppliers.dat

RMS 11 RETL Extracts

The following sections list the RMS 11 RETL Extracts for each group described in Table 3-1.

Needed by AIP RPAS Domain: RMS 11 RETL Extracts that are Transformed

Following is the list of RETL Extracts that are used by the RMS 11-AIP Interface Transform scripts to generate a new set of AIP RPAS loads/feeds.

  • date_format_preference.txt

  • dmx_bndprdasc.txt

  • last_day_of_week.txt

  • rmse_aip_alloc_in_well.dat

  • rmse_aip_future_delivery_alloc.dat

  • rmse_aip_future_delivery_order.dat

  • rmse_aip_future_delivery_tsf.dat

  • rmse_aip_item_loc_traits.dat

  • rmse_aip_item_master.dat

  • rmse_aip_item_retail.dat

  • rmse_aip_item_supp_country.dat

  • rmse_aip_merchhier.dat

  • rmse_aip_orghier.dat

  • rmse_aip_purged_item.dat

  • rmse_aip_store.dat

  • rmse_aip_substitute_items.dat

  • rmse_aip_tsf_in_well.dat

  • rmse_aip_wh.dat

  • rmse_aip_wh.txt

  • rmse_aip_wh_type.txt

  • rmse_clndmstr.dat

  • rmse_rpas_daily_sales.dat


Note:

dmx_bndprdasc.txt is used by the transformation process, but is also a direct feed into AIP RPAS.

Needed by AIP RPAS Domain: RMS 11 RETL Extracts that are not Transformed

The following are the RETL extracts used by RMS 11 that do not need to be transformed by AIP.

  • splr.txt

  • dmx_dirspl.txt

  • dmx_prdspllks.txt

  • sr0_curinv_[1..n].txt

  • wr1_curinv.txt


Note:

As previously shown, the sr0_curinv data feed may be partitioned. For example: sr0_curinv_1.txt, sr0_curinv_2.txt. The data always has at least one partition, namely sr0_curinv_1.txt. AIP RPAS batch steps combine any partitions before loading the data into the AIP domain.

Needed by AIP Oracle Database: RMS 11 RETL Extracts that are not Transformed

Following are the RMS 11 RETL extracts which are not used by AIP RPAS batch but are used by AIP Oracle batch.

  • closed_order.txt

  • received_qty.txt

RMS 11 RETL Extracts that are not used by AIP

Following are the RMS 11 RETL extracts which at this time are not used by AIP.

  • rmse_aip_item_supp_country_reject_ord_mult.txt

  • rmse_aip_suppliers.dat

RMS 10 RETL Extracts

The following sections list the RMS 10 RETL Extracts for each group described in Table 3-1.

Needed by AIP RPAS Domain: RMS 10 RETL Extracts that are Transformed

Following is the list of RETL Extracts that are used by the RMS 10-AIP Interface Transform scripts to generate a new set of AIP RPAS loads/feeds.

  • date_format_preference.txt

  • dmx_bndprdasc.txt

  • last_day_of_week.txt

  • rmse_aip_item_master.dat

  • rmse_aip_wh.txt

  • rmse_alloc_in_well.dat

  • rmse_clndmstr.dat

  • rmse_daily_sales.dat

  • rmse_future_delivery_alloc.dat

  • rmse_future_delivery_order.dat

  • rmse_future_delivery_tsf.dat

  • rmse_item_loc_traits.dat

  • rmse_item_retail.dat

  • rmse_item_supp_country.dat

  • rmse_merchhier.dat

  • rmse_orghier.dat

  • rmse_purged_item.dat

  • rmse_store.dat

  • rmse_substitute_items.dat

  • rmse_tsf_in_well.dat

  • rmse_wh.dat

  • rmse_wh_type.txt


Note:

dmx_bndprdasc.txt is used by the transformation process, but is also a direct feed into AIP RPAS.

Needed by AIP RPAS Domain: RMS 10 RETL Extracts that are not Transformed

The following are the RMS 10 RETL extracts that do not need to be transformed by AIP.

  • splr.txt

  • dmx_dirspl.txt

  • dmx_prdspllks.txt

  • sr0_curinv_[1..n].txt

  • wr1_curinv.txt


Note:

As previously shown, the sr0_curinv data feed may be partitioned. For example: sr0_curinv_1.txt, sr0_curinv_2.txt. The data always has at least one partition, namely sr0_curinv_1.txt. AIP RPAS batch steps combine any partitions before loading the data into the AIP domain.

Needed by AIP Oracle Database: RMS 10 RETL Extracts that are not Transformed

Following are the RMS 10 RETL extracts which are not used by AIP RPAS batch but are used by AIP Oracle batch.

  • closed_order.txt

  • received_qty.txt

RMS 10 RETL Extracts that are not used by AIP

Following are the RMS 10 RETL extracts, which for this release are not used by AIP.

  • rmse_aip_item_supp_country_reject_ord_mult.txt

  • rmse_aip_suppliers.dat

Running the Transform Scripts

This section provides information for running the transform scripts on AIP Oracle and AIP RPAS.

File Transformation and Transfer (AIP RPAS)

The following steps describe how to run the transform scripts for AIP RPAS.

  1. Copy Group 1 and Group 2 extracts from the RMS server to the
    $RAW_RMS_DATA_DIR directory on the AIP server. This process is not part of the Transformation process or AIP batch. It must be scheduled by the client.

  2. Copy the RMS RETL Extract schema files for the version of RMS you are running from the RMS installation to the directory specified by the $RMS_SCHEMA_DIR in $RPAS_HOME/bin/aip_env_rpas.sh. Note that previous versions of AIP utilized separate variable names for different versions of RMS. This version of AIP uses a single variable: $RMS_SCHEMA_DIR.

  3. Copy the $RMS_AIP_TRANSFORM/aip_schema_dir files from the AIP installation into the $AIP_SCHEMA_DIR. This needs to be done only once per AIP install/patch release.

  4. Optionally modify the clnd.prefixes and clnd.day_of_week configuration files, located in the AIP RPAS domain, in $AIPDOMAIN/interface/config/hier, in order to customize the calendar dimension prefixes as well as day of week names.

  5. Run the scripts according to the following table:


    When extracts are from: Then run:

    RMS 14.0 aip_t_master_rms14.0.ksh

    RMS 13.2 RMS 13.2 | aip_t_master_rms13.2.ksh

    RMS 13.1/13.0 aip_t_master_rms13.ksh

    RMS 11 aip_t_master_rms11.ksh

    RMS 10 aip_t_master_rms10.ksh

    The location of these scripts is $RPAS_HOME/bin. Either script executes the appropriate RMS-AIP Interface Transform scripts.

    Once this script has successfully completed, the following new AIP loads/feeds are created:


    clnd.csv.dat loc.txt wr1_aiw.txt

    dm0_pmsendsrc.txt sr0_dayslsld.txt wr1_it_.txt

    dm0_pmsstasrc.txt sr0_it_.txt wr1_oo_.txt

    dmx_dscdt_.txt sr0_oo_.txt wr1_tiw.txt

    dmx_vadprdasc.txt sr0_prdlfe.txt wh_type.txt

    item.txt whse.txt

    After the transforms scripts create the new files, there is logic in the scripts to move all files required by AIP RPAS into $INTERFACE_RMS_DIR/input (defined in aip_constants_rpas.sh.) This is the location where the files are processed by AIP RPAS batch. In addition, there is logic in the scripts (see
    aipt_delete_input_files.ksh) to remove the raw RMS data from the
    $RAW_RMS_DATA_DIR directory which are not needed by the AIP RPAS domain.

    The file clnd.csv.dat is moved to $INTERFACE_RMS_DIR/input and
    $PURGE_IMPORT_HIER_DIR.

File Transfer for Order Management (AIP Oracle Database)

The client must schedule a batch job to copy Group 3 extracts from the RMS server to the AIP Oracle server location defined by $ONL_INBOUND_DIR in the
aip_env_online.sh file. The suffixes for each of the two files (closed_order.txt and received_qty.txt) must be renamed to .dat, to create closed_order.dat and
received_qty.dat.

The cron_import.sh script does not FTP or copy these two data files to the DM Online server, nor does it uncompress, or untar any package (for example, om.tar.Z) containing these files. Clients can still use the om.tar.Z file. However, they are required to tar, compress, ftp, uncompress, and untar by using a batch scheduler.


Note:

AIP also accepts the OM file rmse_order_purge.txt in this location. However, this file is not critical to AIP—it can be configured as optional—and must be generated from a custom RMS script.

At this point, the RMS-AIP transformation is complete.

RDF to AIP Interfaces

AIP does not provide transformation scripts to format data files from RDF. The data files are expected to arrive in an AIP loadable format. AIP does not provide any script to transfer the RDF data into AIP. You need to have a job scheduled to transfer the files from the RDF server to the AIP RPAS server.

This batch job must copy or FTP the forecast data from the RDF server location to the AIP location, $AIPDOMAIN/interface/forecast.

RDF Extracts

The following table describes the forecast data files that are loaded from the forecasting system into AIP.

Input File Name Description
iprdfdtdaltv.txt WRP RDF Alert
sr0_rdfdtdmsk.txt RDF Detailed Alert Masks
sr0_fcterrlvl1.txt Store Weekly Demand Forecast Error
sr0_fcterrlvl2.txt Store Weekly Demand Forecast Error
sr0_rdfdtdcnt.txt RDF Detail Alert Count
sr0_frclvl1_[1..n].txt Store Approved RDF Forecast Level 1
sr0_frclvl2_[1..n].txt Store Approved RDF Forecast Level 2

Once the files are loaded onto the AIP RPAS platform, the AIP RPAS batch script processes the files. The check_load_forecast_data.sh wrapper script is executed to verify that all required files are present before proceeding to load the data into the AIP measures.

AIP to RMS Interface

The AIP Order Management releases data into the staging tables.

  • The polling thread runs EJB at certain time intervals.

  • EJB's stateless Session Beans polls data from the staging table and publishes messages to RIB.

  • RMS uses RIB to receive messages published by AIP.

Figure 3-1 shows the AIP to RMS process flow.

Figure 3-1 AIP to RMS Process Flow

Surrounding text describes Figure 3-1 .

Message Types

There are five types of messages:

Message Type Description
XORDERCRE Create Purchase Order
XORDERDTLCRE Create Purchase Order Detail
XORDERMOD Modify Purchase Order
XORDERDTLMOD Modify Purchase Order Detail
XTSFCRE Create Transfer

RIB Order Publication

The Oracle Retail Integration Bus (RIB) is a near real-time data synchronization solution used by AIP for publishing orders to RMS. Order publication begins with the order release batch adding the affected order to the appropriate message family queue staging table, and then marking each message with a sequence number. AIP publishes two sets of order messages to the RIB: Purchase Orders and Transfers. RMS subscribes to the RIB messages and inserts the orders into the appropriate RMS Purchase Order and Transfer tables.

AIP Message Flow

A polling operation in the servlet triggers the message creation. The polling is performed by two threads:

  • One for the PO_MFQUEUE staging table

  • One for the TSF_MFQUEUE staging table

The polling is controlled by the configuration settings in the main.properties file.

The order period count defines the number of time intervals that are to be used. An order period count of 0 indicates that no orders are released. If the order period count is 0, no threads are started.

The time interval defines the amount of time for which the threads sleep. A thread does not go to sleep until less than the maximum number of allowable messages is processed in a given call to the publisher (OrderSenderBean). Publishing less than the maximum allowable messages indicates that all orders on the staging table (at the time it was queried) have been processed. Any orders added to the staging table afterward, are processed the next time the thread wakes up and the publisher is invoked.

For each order period count greater than zero, an order period start and order period end must be added to the properties file. When the thread wakes up and the current time falls between the start and end of any of the intervals (up to X intervals, where X is the order period count), the thread calls the publication procedure. If desired, various time intervals can be created to manage the publication of orders by forcing the threads to poll the staging tables only between certain time periods.

The publisher is an Enterprise Java Session Bean named OrderSenderBean. Its checkAndPublish method queries the staging table and the base order tables to get the message details. The publisher also ensures that the messages are published to the RIB, in the correct order.

Once the message payload is built by the OrderSenderBean, the RIB message publisher takes the payload and wraps it with an envelope used by the RIB infrastructure.

Purchase Order Message

The purchase order publication messages are in the XOrder message family. In AIP, this message family processes the staged orders on the PO_MFQUEUE table. There are four purchase order message types used by AIP:

All four message types use XOrderDesc.dtd.

XORDERCRE

This message type indicates that a brand new purchase order is being sent to RMS. The orders are sent to RMS in an A (Approved) status. This message type is inserted into PO_MFQUEUE in three different circumstances:

The purchase order was released by the batch, or you chose to release the purchase order in the OM Order Maintenance screen.

You created a new purchase order in the OM Order Create screen.

In the OM Order Maintenance screen, you chose to move a purchase order delivery date, or destination, or both, and also generate a new order number.

XORDERDTLCRE

This message type indicates that a new line item is being added to the purchase order after the order was externally communicated. This message type is inserted into PO_MFQUEUE when you have moved the purchase order destination and chosen to retain the existing order number, and the destination does not already exist on the order for that item.

XORDERMOD

This message type indicates that a modification was made to the overall purchase order details (header level information). This message type is inserted into PO_MFQUEUE in the following circumstances:

You have moved the purchase order delivery date and chosen to retain the existing order number.

You have canceled all ordered quantities of all items on the purchase order. The total order quantity for the entire purchase order is zero. The purchase order is sent to RMS with a C (Canceled) status.

XORDERDTLMOD

This message type indicates that a modification was made to the purchase order line items after the order was externally communicated. This message type is inserted into PO_MFQUEUE when you perform various actions in the OM Order Maintenance screen:

You modify the order quantity of a purchase order that is not closed.

You chose to move a purchase order line item to a new destination, and also retain the order number. If the move-to destination already exists on the order, a message is written to the staging table to increase the quantity at the move-to location.


Note:

Only one message can be inserted for the move-to destination for a particular purchase order. This is either an XORDERDTLCRE if the destination is new, or, XORDERDTLMOD if the SKU is already being delivered to the move-to destination.

The order quantity of the move from destination must be decremented to equal the received quantity. A message is staged for the move from destination.

Transfer Message

The transfer publication messages are in the XTsf message family. In AIP, this message family processes the staged orders on the TSF_MFQUEUE table. There is one transfer message type used by AIP. It uses XTsfDesc.dtd.

XTSFCRE

This message type indicates that a brand new transfer is being sent to RMS. The transfers are sent to RMS in an A (Approved_ status. This message type is inserted into TSF_MFQUEUE when the transfer is released by the batch.

Contingency Overnight Order Processing

The contingency orders in OM give the planners a view of the expected future orders and also serve as backup in the event that new overnight orders cannot be produced from AIP replenishment batch. Since the contingency orders are yesterday's view of today's orders they are very close to the orders that would have likely been produced if today's run of the overnight replenishment batch had completed.

Contingency orders may be available to be released to the RMS in the event that AIP batch cannot produce an order plan, or the data imports into AIP Oracle cannot be completed. The contingency orders, sometimes referred to as yesterday's (forecast) orders, are orders that were generated as forecast orders during the previous batch run. During a normal batch run, yesterday's forecast orders that had not met their release lead time, and had not been released early, are re-planned to ensure the order quantities reflect the latest forecast and inventory information. At the end of the AIP RPAS batch run, the new orders to be release today along with some of the new forecast orders are exported from AIP RPAS to AIP Oracle. During the AIP RPAS replenishment batch calculation of the new order plan, AIP Oracle (OM) still has yesterday's forecast orders in the database. These orders remain in the Oracle database until the import scripts have been run to load the new orders from AIP RPAS.

It is important to understand that when following the contingency order steps, the contingency orders are a replacement for the orders that would normally be produced in the replenishment batch run for release today. When the batch run is complete, the orders must not be released or executed.

Purchase Order and Transfer Files

The following tables provide a list of the related Purchase Order and Transfer files and what orders are contained in each file.

Table 3-2 Store Orders Purchase Order and Transfer Files

Store Orders

strsplrord.dat

This file contains store Purchase Orders to be released today. It also contains all Purchase Orders forecasted for the entire planning horizon. The release date in the file indicates whether the order is to be released today, or whether it is a forecast order. Purchase Orders with a release date greater than today are forecast orders.

Data in this file is first loaded into interface_store_orders table and then copied into store_order table during the load process.

strwhord.dat

This file contains store Transfers to be released today. The release date in the file equals today.

Data in this file is first loaded into interface_store_transfers table during load and then copied into store_order table during the load process.

strsplrord.dat1

This file contains the forecasted store Purchase Orders with an expected release date of tomorrow.

strwhord.dat1

This file contains the forecasted store Transfers with an expected release date of tomorrow.


Table 3-3 Warehouse Orders Purchase Order and Transfer files

Warehouse Orders (Non-contents Orders)

vendor_to_wh_order.dat

This file contains into-warehouse Purchase Orders to be released today. It also contains all Purchase Orders forecasted for the entire planning horizon.

Data in this file is first loaded into warehouse_purchase_order table through i_non_contents_order table during load and then copied into non_contents_order table during merge (that runs before release) process.

wh_to_wh_transfer.dat

This file contains into-warehouse transfers to be released today. It also contains all Transfers forecasted for the entire planning horizon.

Data in this file is first loaded into i_non_contents_transfer table during load process. Transfers with release date of today are moved (not copied) into non_contents_order table during release process while transfers with future release dates are copied (not moved) into non_contents_order table during post-release.


Contingency Steps for Overnight Orders

Your operations to perform depend on the point of failure. For your selected failure point, be sure to read and understand all steps before taking action.


Note:

The following steps listed will release contingency orders include running cron_release_store_order.sh and cron_release_non_contents_order.sh from cron_release.sh. These are regularly schedule batch scripts that release the orders to be executed. They simply identify all into-store or into-warehouse orders in the Oracle database that have met their lead time.

These scripts must not be run a second time upon successful completion of AIP replenishment batch, otherwise, the system is likely to double order.


Failure Point 1: No Orders Imported from AIP RPAS

If AIP RPAS batch fails before completion of send_scrp_measures_to_online.sh no new RPAS order extracts are available for import into AIP Oracle.

Load Contingency Into-Store Transfers

Perform the following steps to load contingency into-store transfers:

  1. In the Oracle schema, navigate to $ONL_INBOUND_DIR.

  2. Add an extension, such as today's date, to strwhord.dat in order to prevent the file from being re-loaded into the Oracle table.

    For example, if today's date is 18-January-2015, rename the file to strsplrord.dat.20151801.

  3. Rename strwhord.dat1 to strwhord.dat.

  4. Navigate to $INTEGRATION_HOME.

  5. Execute script cron_import_order.sh with parameters -o transfer -d store. This loads the contingency store transfers found in the strwhord.dat file.

    No action is needed to load any other contingency orders. The contingency store purchase orders and contingency warehouse purchase orders and transfers were loaded during the previous run of cron_import_order.sh.

Release Remaining Orders That Have Met Their Lead Time

Perform the following steps to release remaining orders that have met their lead time:

  1. Run cron_release.sh to release today's contingency store purchase orders and transfers.

  2. Run cron_release.sh to release today's contingency warehouse purchase orders and transfers.


Note:

If failure occurs during send_scrp_measures_to_online.sh, some of the export files may have been generated. If you can verify that some of the files (strsplrord.dat, strwhord.dat, vendor_to_wh_order.dat, wh_to_wh_transfer.dat) have been completely extracted successfully, they should be manually moved to the Oracle database and manually loaded. If strwhord.dat is manually loaded, skip steps 1 through 5 in "Load Contingency Into-Store Transfers" and perform steps 1 and 2 in "Release Remaining Orders That Have Met Their Lead Time".

Failure Point 2: Loading strsplrord.dat

During the run of cron_import_order.sh while loading strsplrord.dat (scripts/import/ord_imp_store_ord_po_in.sh).

If the error is returned by the subscript ord_imp_store_ord_po_in.sh, the contingency purchase orders might have already been deleted in order to prepare the database to import the new purchase order plan.

  1. Manually delete any orders from the STORE_ORDER table that was partially loaded as a result of executing ord_imp_store_ord_po_in.sh. These orders can be identified as the orders that are in status U, release_date = VDATE, order number IS NULL and source_type = V.

  2. Navigate to $ONL_INBOUND_DIR. Make a backup of strsplrord.dat1 by renaming it strsplrord.dat1bak. This is restored at the end of the contingency process.

  3. Make a backup of strsplrord.dat by renaming it strsplrord.datbak.

  4. Navigate to $BSA_ARCHIVE_DIR. Locate the srp.tar.Z file archived with yesterday's date. Extract the strsplrord.dat1 file and copy it to $ONL_INBOUND_DIR.


    Note:

    Information about Batch Script Architecture (BSA) previously found in this guide is now in the Oracle Retail Planning Batch Script Architecture (BSA) Implementation Guide.

  5. Navigate to $ONL_INBOUND_DIR and rename strsplrord.dat1 to strsplrord.dat.

  6. Navigate to $INTEGRATION_HOME. Execute: cron_import_order.sh-o purchase -d store.

Release Orders That Have Met Their Lead Time

Perform the following steps to release orders that have met their lead time:

  1. Navigate to $INTEGRATION_HOME and execute cron_release.sh to release store purchase order.

  2. Restore backup files.

    Navigate to $ONL_INBOUND_DIR. Remove strsplrord.dat. Rename/move strsplrord.datbak to strsplrord.dat. Rename strsplrord.dat1bak to strsplrord.dat1.


Note:

This process only reloaded one day's worth of purchase orders. In the event that the Corrupt Data File process is needed in tomorrow's batch run, no contingency purchase orders are available.

It is also important to note that the contingency file (.dat1) contains any forecasted purchase orders that were released early. If any purchase orders that are scheduled for release today are executed early (during the previous Online day), a duplicate order is released today.


Failure Point 3: Loading strwhord.dat

During the run of cron_import_order.sh while loading strwhord.dat (scripts/import/ord_imp_store_ord_tsf_in.sh):

  1. Manually delete any orders from STORE_ORDER table that were partially loaded as a result of executing ord_imp_store_ord_tsf_in.sh. These orders can be identified as the orders that are in status U, release_date = VDATE, release_wave IS NULL, order number IS NULL and source_type = W.

  2. Navigate to $ONL_INBOUND_DIR. Make a backup of strwhord.dat1 by renaming it strwhord.dat1bak. This is restored at the end of the contingency process.

  3. Make a backup of strwhord.dat by renaming it strwhord.datbak.

  4. Navigate to $BSA_ARCHIVE_DIR. Locate the srp.tar.Z file archived with yesterday's date. Extract the strwhord.dat1 file and copy it to $ONL_INBOUND_DIR.

  5. Navigate to $ONL_INBOUND_DIR and rename strwhord.dat1 to strwhord.dat.

  6. Navigate to $INTEGRATION_HOME. Execute cron_import_order.sh -o transfer -d store. This loads the contingency transfers produced yesterday.

Release Orders That Have Met Their Lead Time

Perform the following steps to release orders that have met their lead time:

  1. Navigate to $INTEGRATION_HOME and execute cron_release.sh to release store transfer orders. Restore Backup Files

  2. Navigate to $ONL_INBOUND_DIR. Remove strwhord.dat. Rename/move strwhord.datbak to strwhord.dat. Rename strwhord.dat1bak to strwhord.dat1.

Failure Point 4: Loading vendor_to_wh_order.dat into warehouse_purchase_order table

This failure point can happen during the run of cron_import_order.sh (load) while loading vendor_to_wh_order.dat (scripts/import/ord_imp_non_cont_ord_fcst_in.sh) into warehouse_purchase_order table.

If the error was technical in nature and can be fixed, and the interface table i_non_contents_order_forecast still has the data, then rerunning the procedure retl_load.import_wh_purchase_order should be attempted to load the orders.

No contingency file is available in the AIP release. The vendor_to_wh_order.dat file archived in yesterday's srp.tar.Z contains contingency orders. However, it also contains the orders that were released yesterday. The orders which were released yesterday must be deleted from the file before it can be reloaded (including any orders that were released early.)

Failure Point 5: Loading wh_to_wh_transfer.dat into i_non_contents_transfer table

During the run of cron_import_order.sh while loading wh_to_wh_transfer.dat (scripts/import/ ord_imp_non_cont_tsf_in.sh)

No contingency file is available in the AIP release. The wh_to_wh_transfer.dat file archived in yesterday's srp.tar.Z contains contingency orders however it also contains the orders that were released yesterday. The orders which were released yesterday must be deleted from the file before it can be reloaded (including any orders that were released early).

Failure Point 6: Merging Warehouse Purchase Orders into non_contents_transfer table

This failure point can happen during the run of merge_order.sh.

If the failure happens after removing the contingency orders in non_contents_order, then orders should be manually copied from warehouse_purchase_order table into non_contents_order using a similar INSERT query as used in order_merge.copy_order_xxx function.

If the failure happens before removing the contingency orders (of previous merge run) in non_contents_order, then unreleased orders should be manually deleted from non_contents_order.

The script should then be attempted again to merge orders into non_contents_order table.