| Oracle® Retail Advanced Science Engine Implementation Guide Release 14.1 E59126-02 |
|
 Previous |
 Next |
| Oracle® Retail Advanced Science Engine Implementation Guide Release 14.1 E59126-02 |
|
Previous |
Next |
This chapter provides a high level step-by-step procedure for the installation and implementation of ORASE applications. Each step refers to more details, either in this document or other documents. It is recommended that you use this chapter as a map, diving into the details for each step and coming back to this to this overview chapter in order to maintain your orientation and to navigate to the next step.
This chapter contains the following sections:
Prior to installing and implementing ORASE, ensure that the following prerequisites have been completed.
The technical stack defined in the Oracle Retail Advanced Science Engine Installation Guide must be installed, configured, and at the correct revision level. The RA Data Model (RADM) must be installed and populated with the data required by ORASE. See Appendix B, "Database Detail Definitions" for details about the required RA tables.
Here is a high-level overview of the steps involved in the deployment, installation, and implementation of ORASE. The details about customization, attribute pre-processing, configuration, and various options or alternatives are provided later in this chapter in the sections Error: Reference source not found and Error: Reference source not found
It is recommended that you first complete a minimal deployment before starting a complex configuration that involves computational servers, WebLogic clustering, and RAC.
You must complete the following platform deployment steps before you install ORASE. Platform Implementation Steps for the required specifications.
Install and configure RPAS and Category Management.
Install and configure the Oracle database server(s).
Install and configure RADM.
Load the dimension data required by the ORASE applications into RADM.
Install and configure the application server(s).
Install the WebLogic server and ADF on the application server(s).
Optionally, install and configure the computation server(s) for AC and/or ASO.
Here are the steps to follow to complete the installation and implementation of ORASE. See ORASE Installation and Implementation Steps for details.
Install the RPAS Fusion Client (if installing ASO MicroApp)
Install the ORASE Database Components (AC, ASO, CDT, DT and/or MBA) as needed.
Install the ORASE Application Components (AC, ASO MicroApp, ASO Standalone, CDT, DT, and/or MBA), as needed.
Configure the ORASE application roles and users.
Edit and load common seed data.
Perform attribute preprocessing for CDT and DT, as appropriate.
For each of the applications you have installed (AC, ASO, CDT, DT, and/or MBA):
Edit the application's rse_config.ctl seed configuration data file.
If installing ASO Database Component:
Perform any ASO-specific attribute preprocessing.
Load the seed configuration and application data.
If installing ASO Database Component:
Update the planogram-to-assortment mapping table
Test the functionality and execution of the application.
Configure, schedule, and execute the batch scripts.
This section provides additional details about the steps outlined in Process Overview.
Before you install the ORASE applications, you must ensure that the underlying platforms are properly implemented. This includes servers, Oracle database, RADM, WebLogic application servers, RPAS, Category Management application, and, optionally, computational servers.
The main steps are listed here, with reference to specific documentation for the details.
See Chapter 2, "Architecture" for an overview of the ORASE platforms and for the specific supported versions for each platform component.
Install and configure Category Management/RPAS.
For more information on this process, see the Oracle Retail Category Management Installation Guide and Oracle Retail Category Management Implementation Guide as well as the Oracle Retail Predictive Application Server documentation.
Install and configure the Oracle database server(s).
For more information on this process, see the Oracle 12cR1 documentation set.
Install and configure RADM.
For more information on this process, see the Oracle Retail Analytics Installation Guide.
Load the dimension data required by ORASE onto RADM.
For more information on this process, see Oracle Retail Analytics Implementation Guide, Oracle Retail Analytics Data Model, and Appendix E, "Retail Analytics Interfaces Files."
Install and configure the application server(s).
For more information on supported platforms, see the Oracle Retail Category Management Installation Guide and Oracle Retail Category Management Implementation Guide. In addition, see vendor-specific documentation as necessary.
Install the WebLogic server and ADF on the application server(s).
For more information on configuring WebLogic, see Chapter 5, "Configuration.". In addition. see the Oracle WebLogic 12c documentation set.
Optionally, install the RPAS Fusion Client. ASO is a component of CM and is normally installed as a MicroApplication using the same RPAS Fusion Client on which CM is installed. See the Oracle Retail Category Management Installation Guide and Oracle Retail Category Management Implementation Guide for details on installing and implementing the RPAS Fusion Client for CM.
Optionally, install and configure the computation server(s) for AC or ASO. See Chapter 8, "Server Configuration."
For more information on supported platforms, see the Oracle Retail Category Management Installation Guide and Oracle Retail Category Management Implementation Guide. In addition, see vendor-specific documentation as necessary.
You must complete all the steps described in Platform Implementation Steps before you begin the steps described in this section. The order of steps provided here is designed to simplify the process. The advanced user may be able to change the process order or skip some steps; however, that is not recommended and not documented here.
The ORASE installer installs and configures the artifacts that are required by the AC, ASO, CDT, DT, and/or MBA Database Components. Install each of the applications you need, following the instructions provided in the Oracle Retail Advanced Science Engine Installation Guide.
The installer completes the following:
It copies onto the file system:
The ETL and batch scripts for managing data loading, synchronization, and movement
Oracle Coherence (which is optional for scaling AC and/or ASO)
It creates in the Oracle database:
ORASE database objects, including tables and views
PL/SQL packages (procedures) and types
The ORASE installer installs and configures the artifacts that are required by the AC, ASO MicroApp, ASO Standalone, CDT, DT, and/or MBA applications. Install each of the applications you need, following the instructions provided in the Oracle Retail Advanced Science Engine Installation Guide.
The installer completes the following:
It deploys on the Oracle WebLogic Application Server
The UI/middle tier for each application
The ORASE UI and Business Layer applications for each application, as appropriate
Before any user can log into any ORASE application, you must set up application roles, add users, and assign users to the correct roles. To do this, complete the steps described in Chapter 5, "Configuration."
A demo dataset is available to use to configure the applications and then use the applications. It is installed here:
$RSE_HOME/dataset/orase_demo_dataset.tgz
To use the demo dataset, you can select the Option to have the Installer unzip and load it, or you can untar it to the $RSE_HOME directory
tar xvf $RSE_HOME/dataset/orase_demo_dataset.tgz -C $RSE_HOME/
|
Note: Prior to running any installed .ksh scripts, you must source the RSE Environment Setup file located here: $RSE_HOME/common/scripts/lib/rse.env. To source this file, use the command. $RSE_HOME/common/scripts/lib/rse.env |
During an implementation of any ORASE modules, several steps are required after the completion of the installation process. This section provides some details related to these post-install steps.
The rse_config.ksh and the rse_master.ksh script are located in the $RSE_HOME/common/scripts/bin directory. In addition, similar scripts are located within each of the application directories, for example, $RSE_HOME/cdm/cis/scripts/bin has a cis_config.ksh and a cis_master.ksh script. All of the *config.ksh and *master.ksh are similar in nature, so this section focuses on the rse_config.ksh and rse_master.ksh as examples. However, the concepts apply equally to the application-specific *config.ksh and *master.ksh scripts.
Configuration Script (rse_config.ksh)
The rse_config.ksh loads all the relevant *.ctl files contained in the $RSE_HOME/common/data/seed_data directory. Upon successful completion of a load of a file, the script maintains a file called processed.lst in the same seed_data directory. Upon subsequent execution of rse_config.ksh, the contents of processed.lst is checked. If a file was previously loaded, no attempt will be made to reload it. This setup prevents the routine from abnormal termination if a step encounters a problem. If a problem does occur with rse_config.ksh and a file is loaded even though the status does not reflect success, the processed.lst file may be manually edited to prevent the script from trying to process that file on subsequence executions. In a similar manner, if a particular process previously succeeded, but it needs to be reloaded, the processed.lst file can be edited to remove that control file so that subsequent executions will re-run that file.
Master Setup Scripts (rse_master.ksh)
The rse_master.ksh script facilitates the execution of all routines needed to get the applications ready for use. Prior to running the script, all data in RADM must already be available and any configuration changes must have already been performed.
The rse_master.ksh script uses command line switches to control the execution of different parts of the script. Run rse_master.ksh -9 to see a list of options that are valid for the script. Two options are present to help run multiple steps. The -A option runs all options, and the -R option resumes with the step that follows the -R option. The script has been written so that the options are treated like switches. If you provide an option after the -A or after the initial option provided to -R, then that particular series of steps will not be executed. The default option for running rse_master.ksh (ie. rse_master.ksh -Act) results in the skipping of steps c and step t.
Standard Interface Processing
The standard approach for processing inbound data interfaces consists of populating a staging /interface table (which ends with a name of _STG) with data. After the staging table is populated, the data must be processed so it can be incorporated into the appropriate application tables. If any data validation errors occur while the interface is being loaded, the standard process is for the erroneous data to be populated into a matching table that ends with _BAD instead of _STG. This "bad" table contains an ERROR_ROWID column that identifies the row in the _STG table in which a problem occurred. Additionally, an ERROR_DESCR column describes what was invalid about the row. These columns can help determine what to do to resolve the errors and, if necessary, remove the rows from the _STG table.
All ORASE applications share a set of configurable parameters that must be loaded into the RSE_CONFIG table. All have default values and are configurable and editable by the administrator. This section explains how to load and, if desired, edit these parameters.
The .ctl files for common configuration data must be edited and loaded into the staging tables. This data is common to all ORASE applications. The .ctl files for common seed data are located in the directory: <RSE_HOME>/common/data/seed_data. (RSE_HOME is set by the user during installation.)
Review the .ctl files in that directory and adjust any configurations needed for the environment. Some configurations cannot be changed after the application has been used; therefore, you must carefully consider the parameters listed in Table 3-1. The remainder are optional and default to reasonable valuables.
The following configuration parameters must be initialized during setup. The values for hierarchy level and type are recommended for any installation that integrates with the CM installation and must match for all installed applications.
Table 3-1 Mandatory Common RSE Database Configuration Parameters
| Application | Parameter | Description | Value |
|---|---|---|---|
|
RSE |
CAL_PERIOD_LEVEL |
This is the calendar hierarchy level that is used to drive RSE processing. |
4 |
|
RSE |
CHAIN_LEVEL_DESC |
The description to use for any top level hierarchy element, when one must be manually created. |
CHAIN |
|
RSE |
CMGRP_HIER_TYPE |
The hierarchy ID to use for the CM Group. Recommendation is for a normal installation with Category Management. |
1 |
|
RSE |
CMGRP_LEVEL_ID |
The hierarchy level ID that contains the level of the product hierarchy where the CM Group level exists (installation configuration). Recommendation is for a normal installation with Category Management. |
5 |
|
RSE |
MT_TZ |
The time zone that is used by application server(s), that is, by the middle-tier. It must match SELECT tzname FROM V$TIMEZONE_NAMES. |
America/New_York |
|
RSE |
PRIMARY_LANGUAGE_CODE |
The name of the language code to use for all RSE data sourced from RA. |
EN |
|
RSE |
RA_FISCAL_CAL_ID |
The ID of the calendar to use from RA (since RA supports multiple calendars). |
1240 |
|
RSE |
TRADE_AREA_HIER_TYPE |
The hierarchy ID to use for the Trade Area (installation configuration). |
6 |
|
RSE |
UI_TZ |
The time zone for display. It must match SELECT tzname FROM V$TIMEZONE_NAMES. |
America/New_York |
For the complete list, see Oracle Retail Advanced Science Engine Implementation Guide, Volume 2 - Data Processes and Configuration Variables.
Load the Common ORASE Seed Data
Load the common ORASE seed configuration and data by executing the following load scripts:
cd $RSE_HOME/common/scripts/bin ./rse_config.ksh ./rse_master.ksh - Act
See Chapter 6, "Data Integration and Interfaces" for details about additional customizations and data load options.
Product attributes are required by CDT and DT and are stored in the RADM. Attribute preprocessing is independent of the ORASE database and happens in RA or flat files generated by the user. Once these tables and files are correct, you can load the resulting attributes in the ORASE schema as part of the data load process, as described in the section For Each Application Installed, Complete the Following Steps.
Here are the basic attribute pre-processing steps:
Populate RADM with raw attribute data.
Optionally, perform translation.
Parse.
Cleanse and standardize.
Categorize and label.
Define the attributes.
Bin and group.
For details on these steps, see Chapter 9, "Attribute Processing".
All ORASE applications require and depend on RADM data and ETL components. You must install, configure, and populate RADM with the data required by these applications before you install the applications themselves.
As part of the process of loading data for the applications, common RADM data needed by ORASE applications is loaded into the ORASE database. The steps below load RA dimension, hierarchy, attribute, and other common configuration data shared by ORASE applications. This data is loaded only once by the first application loaded (normally CDT). As part of this load process, each application also loads any application-specific configuration and application data it needs.
You must complete the following series of steps for each of the applications (AC, ASO, CDT, DT, and MBA) that you install.
Edit the remaining application configuration seed data .ctl files
Load the seed configuration and application data in each application using the load scripts
The seed data load scripts include a config.ksh script for loading configuration and a master.ksh script for loading data. The master.ksh script invokes a number of scripts that load specific data either from staging, RA, or external files. If you want to edit the master.ksh to change the scripts it calls, see Oracle Retail Advanced Science Engine Implementation Guide, Volume 2 - Data Processes and Configuration Variables for details.
Edit rse_config.ctl seed data
You must edit and load the rse_config.ctl file for each installed ORASE application's configuration data. Each application has its own version of rse_config.ctl in the following directory locations:
AC: <RSE_HOME>/cdm/cis/data/seed_data
ASO: <RSE_HOME>/so/data/seed_data
CDT: <RSE_HOME>/cdm/cdt/data/seed_data
DT: <RSE_HOME>/cdm/dt/data/seed_data
MBA: <RSE_HOME>/cdm/mba/data/seed_data
Review rse_config.ctl in the directory listed for each application and adjust any configurations needed for the environment. Some configurations cannot be changed after the application has been used and must be carefully considered now. These are listed in Table 3-2, Table 3-3, and Table 3-4. The rest of the configurations are optional and default to reasonable valuables.
The four major categories of ORASE parameters are:
CDT and DT time scale, filter, and priority controls
CDT and DT UI field value and histogram report defaults
CDT calculation controls, including tree calculations, pruning, demand and replenishment settings (that is, settings for demand and replenishment models)
DT default controls for attributes, similarities, and DT calculations
All ORASE applications have configurable parameters in the RSE_CONFIG table. All have default values and are configurable and editable by the administrator. In general, if a user does not select a value for a particular field, it will default to the value listed in this table. Often, the parameter is not selectable from the UI, and this value is used by the application until it is changed in the database. Parameters that must be initialized at setup are listed in Table 3-2, Table 3-3, and Table 3-4.
See Oracle Retail Advanced Science Engine Implementation Guide, Volume 2 - Data Processes and Configuration Variables for the complete list of the configurations that are configurable, updateable by the application, and required at the time of initialization.
Table 3-2 contains the mandatory configuration parameters for CDT.
Table 3-2 Mandatory CDT Configuration Parameters
| Application | Parameter | Description | Value |
|---|---|---|---|
|
CDT |
CDT_CAL_HIER_TYPE |
The hierarchy ID to use for the fiscal calendar (installation configuration). |
11 |
|
CDT |
CDT_CAL_LEVEL_ID |
The hierarchy level ID that contains the level of the calendar hierarchy that CDT operates on. (This should equate to the Week - Installation configuration). |
4 |
|
CDT |
CDT_CMGRP_LEVEL_ID |
The hierarchy level ID that contains the level of the product hierarchy that CDTs are created for (installation configuration). |
5 |
|
CDT |
CDT_CUSTSEG_HIER_TYPE |
The hierarchy ID to use for customer segment (installation configuration). |
4 |
|
CDT |
CDT_CUSTSEG_LEVEL_ID |
The hierarchy level ID that contains the level of the customer segment hierarchy that CDTs are created for (installation configuration). |
2 |
|
CDT |
CDT_LOC_HIER_TYPE |
The hierarchy ID to use for location (installation configuration). |
2 |
|
CDT |
CDT_LOC_LEVEL_ID |
The hierarchy level ID that contains the level of the location hierarchy that CDTs are created for (installation configuration). |
Best equivalent for trade area level |
|
CDT |
CDT_PROD_HIER_TYPE |
The hierarchy ID to use for the CM Group (installation configuration). The recommendation is for a normal installation with CM |
1 |
|
CDT |
DEF_NUM_WEEKS_FOR_SIMILARITY |
The default number of weeks of sales transaction data to be used by the similarity process. This is used when the user does not specify time intervals. |
15 |
Table 3-3 contains the mandatory configuration parameters for DT.
Table 3-3 Mandatory DT Configuration Parameters
| Application | Parameter | Description | Value |
|---|---|---|---|
|
DT |
AE_CALC_INT_LENGTH |
The number of weeks to group together for in an interval for the AE calculation. |
4 |
|
DT |
CDT_SIMILARITY_AVAILABLE |
Whether the CDT similarity has been made available to DT. |
Y |
|
DT |
DT_CAL_HIER_TYPE |
The hierarchy ID to use for the fiscal calendar. |
11 |
|
DT |
DT_CAL_LEVEL_ID |
The hierarchy level ID that contains the level of the calendar hierarchy that DT operates on. (It should equate to week.) |
4 |
|
DT |
DT_CMGRP_LEVEL_ID |
The hierarchy level ID that contains the level of the product hierarchy that DTs are created for. |
5 |
|
DT |
DT_LOC_HIER_TYPE |
The hierarchy ID to use for location. |
5 |
|
DT |
DT_LOC_LEVEL_ID |
The hierarchy level ID that contains the level of the location hierarchy that DTs are created for. |
Best equivalent for trade area level |
|
DT |
DT_PROD_HIER_TYPE |
The hierarchy ID to use for the CM Group. |
1 |
|
DT |
PR_LOC_STATUS_LAST_COMPLETED_WK |
The last completed week for the SKU/Store ranging data copying. |
Week ID from RSE_CAL_HIER |
|
DT |
WGT_CALC_INTERVAL_LENGTH |
The number of weeks to group into an interval that is then used to perform weight calculations. |
4 |
Table 3-4 contains the mandatory configuration parameters for AC.
Table 3-4 Mandatory AC Configuration Parameters
| Application | Parameter | Description | Value |
|---|---|---|---|
|
CIS |
CIS_DFLT_CALENDAR_HIER_TYPE_ID |
the default calendar hierarchy for clustering. |
11 |
|
CIS |
CIS_DFLT_LOCATION_HIER_TYPE_ID |
The default location hierarchy for clustering. |
2 |
|
CIS |
CIS_DFLT_PRODUCT_HIER_TYPE_ID |
The default product hierarchy for clustering. |
1 |
|
CIS |
PERF_CIS_APPROACH |
The approach to use for performance based clustering. The available options are CDT and DT. |
CDT |
|
Note: There are no mandatory configuration parameters for MBA. |
Table 3-5 Mandatory ASO Configuration Parameters
| Application | Parameter | Description | Value |
|---|---|---|---|
|
SO |
SO_CAL_HIER_TYPE |
The hierarchy ID to use for the calendar (installation configuration). |
10 |
|
SO |
SO_FISCAL_CAL_HIER_TYPE |
The hierarchy ID to use for the fiscal calendar (installation configuration). |
11 |
|
SO |
SO_LOC_HIER_TYPE |
The hierarchy ID to use for location (installation configuration). |
2 |
|
SO |
SO_PROD_HIER_LEVEL_FOR_LEAF_NODE |
The product hierarchy level number for leaf node. |
7 |
|
SO |
SO_PROD_HIER_TYPE |
The hierarchy ID to use for the product (installation configuration). |
1 |
For the complete list of ASO configuration parameters, see Oracle Retail Advanced Science Engine Implementation Guide, Volume 2 - Data Processes and Configuration Variables.
Prepare the ASO Seed Data for Loading
The following seed data must be loaded for ASO. All of these files are loaded by so_config.ksh from the <RSE_HOME>/so/data/infile directory. You should review the config script and verify the exact name and location of each file that is expected to be loaded.
ASO application seed data. The ASO seed data .ctl files are in the directory <RSE_HOME> /so/data/seed_data. The default .ctl files control loading input files that match the input file interfaces defined in Chapter 6, "Data Integration and Interfaces". If you have any custom seed data, any .ctl files they need should be placed here and executed manually.
CM input file data, including assortment data, new items, and forecast. CM input files are part of the standard file interface between CM and ASO, created by the CM application as part of an ASO request. This data is loaded as part of the normal batch process. See the Oracle Retail Category Management User Guide and Oracle Retail Category Management Implementation Guide for details.
External file data, including planograms and replenishment. External data is loaded from user-created files as needed via ETL scripts. This includes data on assortments, product, forecasts, planogram display, and replenishment. You must create these import files according to the file interface definitions defined in Chapter 6, "Data Integration and Interfaces".
Perform the ASO-Specific Attribute Preprocessing
ASO uses product attributes, but for a different purpose than ORASE. In ASO, product attributes are used to define product placement constraints during space optimization. Because of this, ASO may have some product constraints that differ from CDT or DT product constraints. The resulting attributes are loaded in the ASO schema as part of the ORASE data load process.
Additional background information and the steps to do this are defined under Chapter 9, "Attribute Processing".
Edit the remaining application configuration seed data .ctl files
Review any additional seed data .ctl files in the directory for each application and adjust any as needed for the specific application.
|
Note: The merchandise hierarchy levels defined in rse_hier_level.ctl must align with the common data that was loaded from RADM. |
Load the seed configuration and application data in each application using the load scripts
Execute the following load scripts.
For AC:
cd $CIS_HOME/scripts/bin ./cis_config.ksh ./cis_master.ksh -A
See Chapter 5, "Configuration" for details about the additional AC customization and configuration capability.
For ASO:
cd $ASO_HOME/scripts/bin ./so_config.ksh ./so_master.ksh -A
For CDT:
cd $CDT_HOME/scripts/bin ./cdt_config.ksh ./cdt_master.ksh -A
For DT:
cd $DT_HOME/scripts/bin ./dt_config.ksh ./dt_master.ksh -A
For MBA:
cd $MBA_HOME/scripts/bin ./mba_config.ksh ./mba_master.ksh -A
See "Market Basket Analysis Overview" for details about the additional MBA customization and configuration capability.
The relationships between assortment and planogram data that you loaded must be defined. This mapping simplifies the job of the application planner by partially automating the mapping of sets of planograms with assortments. This mapping process also matches the seasonality of planograms and assortments and considers demand spread factors for products that are assigned to multiple planogram sets at one time. You do this by creating or editing a pair of mapping files. Batch scripts automate the loading of these files and the subsequent mapping process in order to define the relationships of the planograms to the assortments.
The planogram-assortment mapping files must be created and loaded before either the assortments or the planograms can be used by ASO. If you load any new planograms or assortments into ASO after the initial mapping, you must update and load the new mapping files before the new planograms and assortments can be used in ASO. These files are:
Assortment and Space Optimization POG to Assortment Mapping File. This file contains the planogram hierarchy to assortment product mapping information. This data is used to identify which planogram should be used for each product.
Assortment and Space Optimization POG Season to Assortment Mapping File. This file contains the planogram season to assortment date mapping. Once the mapping from product to planogram has been performed, a second pass is used to identify the specific planogram and assortment(s) in the table for the seasonal time period.
The details for these mapping files are defined in Chapter 6, "Data Integration and Interfaces."
Test the functionality and execution of the application
Each ORASE application must be tested for basic functionality and any issues with the deployment, installation, implementation be resolved before proceeding. See the Oracle Retail Advanced Science Engine User Guide and the Oracle Retail Assortment and Space Optimization User Guide for details about using each application.
Note that the WebLogic domain must be restarted in order to load the latest database configuration changes before everything is fully functional because changes to RSE_CONFIG are only picked up at startup.
Configure, schedule, and execute the batch scripts
For each application, periodic batch scripts must be scheduled to load ongoing application data and keep the various dimensions up to date and in synchronization. Export processes can also be set up in order to export data to other applications. For the list of batch processes, their order, priority and frequency, see Oracle Retail Advanced Science Engine Implementation Guide, Volume 2 - Data Processes and Configuration Variables.
When you are installing ASO into the RPAS Fusion Client as a Micro application, you must configure the task flows so that they appear in CM's Fusion Client UI.
Module Taskflow Configuration for ASO
Insert the following module_step elements in the file TaskflowMultiSolution.xml. Place them inside the RPAS task element that corresponds to the desired parent task-Flevel node in the RPAS navigation tree. The TaskflowMultiSolution.xml can be found in the <FC install dir>/MultiSolution directory. For an example of the complete file, see Appendix A, "Sample Taskflow_MultiSolution.xml File for ASO/Fusion Client Integration."
<module_step>
<name>sia-so.asomain.microapp.name</name>
<description>sia-so.asomain.microapp.desc</description>
<module>asomain</module>
<module_bundle>sia-so</module_bundle>
<order_num>6</order_num>
</module_step>
This entry must be added twice by default.
First instance: under Activity1.Task2.Step8 (this comes under the Assortment Planning at Cluster task). The <order_num> tag here is important, and it should be <order_num>6</order_num>.
Second instance: under Activity1.Task3.Step10 (this comes under the Assortment Planning at Store task) The <order_num> tag here should be <order_num>2</order_num>.
For the above XML, the sub-elements of the module step are described in Table 3-6.
Table 3-6 Sub-Elements
| Element | Description |
|---|---|
|
Name |
Resource key for the text used for rendering the module link in the navigation tree. The key is required to be defined in resources/MultiSolutionBundle.properties. |
|
Description |
Resource key for the descriptive text in the pop-up that appears when the user hovers over the module link. The key is to be defined in resources/MultiSolutionBundle.properties. |
|
Module |
The name of the plug-in (that is, module) that is specified in the bundle manifest file. The bundle manifest file is named <bundle-name>-bundle-manifest.xml and is located in <FC-install-dir>/functionalmodulebundles/<bundle-name>. |
|
module_bundle |
The name of the plug-in bundle. It can be obtained from the bundle manifest file. See the description of the module element above. |
|
order_num |
This dictates the position of the module link in relation to all the nodes under the parent RPAS task. |
Resource Keys Defined in MultiSolutionBundle.properties
As described in Table 3-6, the resource keys used in the module link definitions are defined in the file:
<FC install dir>/MultiSolution/resources/MultiSolutionBundle.properties.
The entries are:
sia-so.asomain.microapp.name=Assortment and Space Optimization
sia-so.asomain.microapp.desc=Assortment and Space Optimization
A sample Taskflow_MultiSolution.xml can be found in Appendix A, "Sample Taskflow_MultiSolution.xml File for ASO/Fusion Client Integration".
|
Note: Gurobi is only required for ASO Standalone and ASO MicroApp. |
Enabling Gurobi for ASO
After installation, <RSE_HOME> contains:
<RSE_HOME>/so/export/gurobi.jar
[the gurobi.jar is platform specific]
<RSE_HOME> also contains one of the following sets of files, depending upon the platform.
AIX
<RSE_HOME>/so/export/aix64/libGurobiJni55.a<RSE_HOME>/so/export/aix64/libgurobi55.a
Linux
<RSE_HOME>/so/export/linux64/libGurobiJni55.so<RSE_HOME>/so/export/linux64/libgurobi55.so
Solaris
<RSE_HOME>/so/export/solaris64/libGurobiJni55.so<RSE_HOME>/so/export/solaris64/libgurobi55.so
Adding Gurobi JNI Directory to PATCH_LIBPATH for WLS
Edit <WLS_DOMAIN_HOME>/bin/setDomainEnv.sh
After these lines (near Line 209):
Path and Path for this domain, # Please uncomment the following lines and add a valid value for the environment variables # set PATCH_CLASSPATH=[myPatchClasspath] (windows) # set PATCH_LIBPATH=[myPatchLibpath] (windows) # set PATCH_PATH=[myPatchPath] (windows) # PATCH_CLASSPATH=[myPatchClasspath] (unix) # PATCH_LIBPATH=[myPatchLibpath] (unix) # PATCH_PATH=[myPatchPath] (unix)
If installing on AIX, add these two lines after the above.
PATCH_LIBPATH=<RSE_HOME>/so/export/aix64 export PATCH_LIBPATH
If installing on Linux, add these two lines after the above.
PATCH_LIBPATH=<RSE_HOME>/so/export/linux64 export PATCH_LIBPATH
If installing on Solaris, add these two lines after the above.
PATCH_LIBPATH=<RSE_HOME>/so/export/solaris64 export PATCH_LIBPATH
