This chapter covers the following topics:
Oracle recommends using the latest version of Java 6 or 7. The version installed on the client does not have to be the same as the version that you use on the server. However, all clients must use the same JRE version. To change the JRE version on the client machine, download and install the required Java plug-in. For details, see Java Tips.
Note: The JRE defaults to the latest version installed. For example, if you have both Java 6 and 7 installed on the same machine, Demantra will be executed with 7 unless you have disabled that particular version in the Java control panel.
To check the installation logs:
Check the basic installer log file: C:\tmp\Demantra-install.log.
Check the database log files written by the Installer. Depending on the installation, the Installer writes some or all of the following log files into Demantra_root\Demand Planner\Database Objects\database_type_name:
import.log (Information on the import process of the dump file)
For Oracle: run_build_procedures.LST (Information on the loading of the procedures into the new user.) and other *.LST files.
Check the db_exception_log table.
If you upgraded the database user, also check the following:
The upgrade.log file provides details on the database upgrade process. This file is in the same directory as the other Installer log files.
version_detail table is updated to the new version only if the upgrade procedure finishes successfully.
As part of the Demantra installation, the following privilege is set in the Oracle database by the Demantra installation process:
SQL > GRANT CREATE ANY DIRECTORY TO demantra_user;
This privilege is needed for setting up JD Edwards EnterpriseOne integration.
If you are not planning to use JD Edwards integration, run the following command after setup:
SQL> REVOKE CREATE ANY DIRECTORY FROM demantra_user;
If you are planning to use JD Edwards integration, run the above command after your JD Edwards integration is working, not immediately after installation.
The Oracle Demantra Installer upgrade procedure does not change the current values of any parameters, although it may change the default value of a parameter. The individual upgrade sections of this document specify any suggested manual parameter changes.
It does add new parameters for the new release and sets their default values.
The Oracle Demantra Installer does not make any changes to your custom procedures, functions, or views. It is your responsibility to make adjustments to your custom features as needed so that they work with the new release. For information on preserving customizations during an upgrade, see the Business Applications Language information in the Oracle Demantra Implementation Guide.
These are some examples of how Oracle Demantra works with languages when you upgrade.
You install an Oracle Demantra non-translated release (before release 7.3.0) and begin your implementation in U.S. English. During this process, you maintain the standard application and add some new content (either in U.S. English, or using the limited non-U.S. English capabilities for worksheet and series names).
Then, you upgrade to a translated release (release 7.3.0 and later) to take advantage of the translations of standard application objects and platform menus and labels. You select a language other than U.S. English.
As a result of the upgrade, the following occurs:
Standard, unmodified application objects, for example, series, worksheet, content, workflow, integration interfaces, and methods, are available in the default language.
Standard, modified application objects are available in the default language if they upgrade. Oracle Demantra identifies standard objects with an internal application identifier; therefore, the standard translation of series name and hint supersede your modifications. You must restore your modifications after the upgrades.
Customizations in U.S. English remain in U.S. English. You must translate these manually.
You install an Oracle Demantra non-translated release (before release 7.3.0), with patches to allow creation of certain objects (for example, worksheets and series) in a non-U.S. English language. You implement new content in the non-U.S. English language and also modify standard application strings to non-U.S. English.
Then, you upgrade to a translated release (release 7.3.0 and later) to take advantage of the full user interface translation to the non-U.S English language and you select the same language as that of your partially translated release.
As a result of the upgrade, the following occurs:
Standard, unmodified application objects--(series, worksheet, content, workflow, integration interfaces, methods)--are available in the default language.
Standard, modified application objects are available in the default language if they upgrade. Oracle Demantra identifies standard objects with an internal application identifier; therefore, the standard translation of series name and hint supersede your modifications. You must restore your modifications after the upgrades.
Customizations in the non-U.S. English language remain in the non-U.S. English language.
Customizations in U.S. English remain in U.S. English. You must translate these manually.
You install and implement an Oracle Demantra translated release. You make slight modifications to the standard application, for example, add new series, slightly change the name of a worksheet or two, or add some new worksheets and workflows.
Then, you run the Installer to upgrade to a higher translated release and choose the same language while preserving your own modifications.
As a result of the upgrade, the following occurs:
Standard, unmodified application objects--(series, worksheet, content, workflow, integration interfaces, methods)--continue to be available in the default language.
Standard, modified application objects are available in the default language if they upgrade. Oracle Demantra identifies standard objects with an internal application identifier; therefore, the standard translation of series name and hint supersede your modifications. You must restore your modifications after the upgrades.
New standard application objects are available in the default language.
Customizations in the default language remain in the default language.
You rollout a model in one region and language and want to use that same model in another region and language.
You copy the original regional schema, import it into a new instance, strip it of data, and run the Installer against this schema, choosing a new language.
As a result of the upgrade, the following occurs:
Standard, unmodified application objects (for example, series, worksheet, content, workflow, integration interfaces, and methods) are available in the new default language.
Standard, modified application objects are available in the new default language.
All new standard application objects will be available in the new default language.
Customizations in the original language remain in the original default language. You must translate these manually.
Note: Oracle Demantra release 12.2 and later handles currency symbols differently than in the 7.3.x release. In the 7.3.x releases, the currency symbol reflected the locale that was defined on the end user's client machine (for example, if the user was based in the US, the USD currency symbol ($) was used). In implementations spanning multiple countries and locales this could result with the same value being shown with different symbols presenting incorrect information. In release 12.2 and later the currency symbol does not change by the user locale. Instead, the currency symbol set in the Business Modeler is used for all users.
If you upgraded the database user, make sure that upgrade ran correctly. See Checking the Log Files and Tables.
If you perform an application upgrade and new engine profiles are added, be sure to review the following parameters to ensure they are set correctly.
last_date
last_date_backup
If you are not sure what these parameters should be set to, Oracle recommends using the settings of the 'Base' engine profile. Additionally, after performing an application upgrade to move your data model to either a daily or a monthly system, the following parameters should be evaluated in the same manner:
AverageHorizon
HistoryLength
MinLengthForDetect
PromotionStartDate
StartAverage
TestPeriod
TrendPeriod
dying_time
hist_glob_prop
lead
mature_age
season
start_date
test_samp_len
timeunit
Note: "Timeunit" is not visible using Business Modeler and must be reviewed and modified using a tool such as SQL Developer.
Application upgrades to release 12.2 are supported from release 7.1 and later.
Refer to Upgrade Preparation Checklist before you begin.
The upgrading of the schema occurs during the installation process. Once you arrive at the Schema Options screen, your choices are as follows:
If your application is highly customized and does not follow the standard baseline Oracle application configuration (standard data model), Oracle recommends that you upgrade the platform only. This upgrades only the software functionality and does not change the application configurations in the database schema.
If your application includes a few or no customizations to the standard baseline Oracle application configuration (standard data model), Oracle recommends that you upgrade both the platform and application.
If you are upgrading both the platform and application, you can decide either to run an automatic upgrade or a manual upgrade based on these criteria:
Automatic Upgrade: You have few or no customizations, you don't need to select upgrade actions for each individual object, and you are satisfied with basing your upgrade on a set of default upgrade preferences.
Manual Upgrade: You have some customizations or if you want to have control over how the objects are upgraded.
For automatic upgrade:
On the BAL Upgrade Options screen, choose Automatic Upgrade. The BAL Explorer upgrades the schema in the background.
When it is done, it launches Business Modeler; you can apply configuration changes to the destination schema. From the Configuration menu, select Validate BAL Import. Then, activate the BAL configurations.
When you are done, the installation process continues.
For manual upgrade:
On the BAL Upgrade Options screen, choose Manual Upgrade.
Use the BAL Explorer utility to analyze the relationship between objects, compare schemas, and specify how individual objects are upgraded when conflicts occur between the schemas. You can specify a different default upgrade action by object. For more information, see “Upgrading Using Oracle Demantra Business Application Language” in the Oracle Demantra Implementation Guide.
When you are finished upgrading the schema, BAL Explorer launches Business Modeler; you can apply configuration changes to the destination schema. From the Configuration menu, select Validate BAL Import. Then, activate the BAL configurations.
When you are done, the installation process continues.
Important: To prevent issues with client expressions that may refer to seeded series names, any seeded series names that were changed will revert back to their original text during the upgrade. Therefore, if you renamed seeded series, you must restore the modification after the upgrade is complete.
Note: If you are upgrading to 12.2 or later, any seeded series names that contain restricted characters like slash (/) or hyphen (-) will no longer have these characters after the upgrade.
Using the SQL insert statement, the SYS_PARAMS table can be updated to include the SYNCHRONIZE_USER_SERIES parameter that automatically provides users created in the Business Modeler with access to new seeded series upon upgrading. This parameter must be set prior to upgrading to the latest version of Demantra, or else all the new seeded series will only be available to the component owners (such as dm). Without adding the SYNCHRONIZE_USERS_SERIES parameter, the administrator must manually configure all other users to provide them with access to the new series.
Below is the syntax for this parameter:
insert into SYS_PARAMS (PNAME, PVAL, DESCRIPTION) VALUES 'SYNCHRONIZE_USER_SERIES', 'DCM_PRODUCT:157, DCM_PRODUCT:178', 'Provides users created in Business Modeler with access to all new seeded series for specified components when upgrading');
Where:
PNAME = SYNCHRONIZE_USER_SERIES
PVAL = DCM_PRODUCT:157, DCM_PRODUCT:178
DESCRIPTION = Provides users created in Business Modeler with access to all new seeded series for specified components when upgrading
This statement provides all users created in Business Modeler with access to any new seeded series for both the Demand Management and Sales and Operations Planning components (application IDs 157 and 178, respectively). The description shown here is just an example; you can enter different text if desired, but note that this column cannot exceed 255 characters. If you define this parameter, it persists in the Demantra schema and is respected during future upgrades.
The following steps are necessary to support Service Parts Forecasting when upgrading software and data from a pre-7.3.1 version of Demantra:
Review the Engine Profiles
Modify the Init Params Table Name
Enable the SPF Rolling Profile Group
Before installing or upgrading Demantra version 7.3.1, you must review any engine profiles to ensure they are not referencing init_params_XXX tables used by some of our new engine profiles provided in release 7.3.1.
Using SQL Developer or similar tool, run the following command: select * from engine_profiles;
Note the values in column INIT_PARAMS_TABLE_NAME.
If any profiles are pointing to the tables INIT_PARAMS_121, INIT_PARAMS_122, INIT_PARAMS_141, and INIT_PARAMS_142, the table referenced to by these engine profiles must be modified to point to a new table name.
Note: When upgrading to this release, you must select the "Application and Platform Upgrade" option (Upgrade Options screen) to enable SPF functionality. SPF will not be enabled if you choose the "Platform Only" option.
After reviewing your existing engine profiles, if any of your profiles are referencing INIT_PARAMS_121, INIT_PARAMS_122, INIT_PARAMS_141 or INIT_PARAMS_142, do the following to change your existing table names:
Log in to Business Modeler.
From the Parameters menu, choose System Parameters, then Engine.
Find the appropriate engine profile and click Edit.
Rename the table in the “Init Params Table Name” field. Enter a table name that is not currently in use. For example, change INIT_PARAMS_121 to INIT_PARAMS_222.
The seeded "SPF" Rolling Profile Group is disabled by default. After installing or upgrading, you must perform the following steps to ensure that SPF forecasts are archived.
Log into the database using SQL Developer or similar application.
In the ROLLING_GROUPS table, enable the “SPF” rolling profile group by setting IS_ACTIVE to '1'.
Note: When multiple profile groups are enabled, Oracle does not recommend running profile groups from the analytical engine (via INSERT_UNITS). Instead, schedule them to run separately via a workflow that executes the EXECUTE_PROFILES procedure and passes a specific rolling group ID. To disable execution of profile groups by the engine, set the engine parameter RunInsertUnits to 3.
For more information, refer to the Oracle Demantra Analytical Engine Guide.
In release 7.3.0.1 and later, two new internal Configure to Order (CTO) levels are available: CTO Parent and CTO Child. These new levels define the CTO Tree. These levels are used instead of the 'Parent Item' and 'Item' levels used in release 7.3.0 (the first Demantra release that supported CTO).
Depending on your current Demantra version, you may need to perform the steps in this section to upgrade CTO structures and (optionally) upgrade your CTO data.
If you are upgrading from release 7.3.0, then you must perform the steps in this section.
You do NOT have to perform the steps in this section if:
You are upgrading from a pre-7.3.0 version of Oracle Demantra
Or
You are upgrading from release 7.3.0.1 or later
Note: Demantra release 7.3.0.1 and later also provides an automatic setting for enabling the CTO Tree view without the need to manually include CTO Parent level and CTO Child levels in worksheets. Depending on your needs, you may want to remove the Parent Item from current CTO worksheets. When using the context menu on the Item-level Show CTO Tree, the system automatically includes and hides the CTO Parent level and CTO Child levels and displays the item as a CTO Tree.
Prerequisites:
If you are not using standard collections, please review the new structures for the integration tables: BIIO_CTO_LEVEL and BIIO_CTO_CHILD.
If you will be reloading fresh data and want to preserve overrides, Oracle recommends exporting all overrides with an integration interface. For example, create an interface at the "Base Model", "Parent Item", "Item", and any additional item or location dimensions, and include series such as Base Override, Forecast Dependent Demand Override, and so on. These overrides can then be restored after fresh data reload with an import integration interface.
To Upgrade Software and Application to Support CTO Functionality:
If you are upgrading from release 7.3.0, the upgrade process contains two stages:
Software and metadata upgrade - This is achieved by selecting 'Application and Platform' when running the installer.
Data upgrade - This is a manual process that upgrades your data for the new CTO Levels and provides a mechanism to use existing data without the need to reload new data.
Important: Data upgrade is not necessary if you are planning to reload a new full data set.
Stage One: Software and Metadata Updating:
Make sure you have a working backup.
Back up user overrides manually or by creating an integration interface as described in the Prerequisites above.
Run the Demantra Installer. In the Upgrade Options page, be sure to select the 'Application and Platform Upgrade' option. See Upgrading from 7.1 and Higher for more details. Important: When the upgrade is complete, perform the next step only if you are NOT planning to reload a new CTO data set. This step should be performed before starting Demantra.
Stage Two: Manually Updating Data
If you are not planning to reload all CTO data, upgrade existing CTO data using the procedure APPPROC_UPDATE_CTO_LEVEL_7301. This procedure will generate data for the "CTO Child" level using data from "Parent Item" and "Item" levels. It also populates Demantra internal tables for CTO (T_EP_CTO, T_EP_CTO_MATRIX, T_EP_CTO_DATA).
This procedure utilizes the Oracle database job queue. By default this spawns 10 jobs in the USER_JOBS tables. On systems that can support more parallels jobs, you can extend the number of jobs in JOB_QUEUE_PROCESSES and execute the procedure with more jobs.
Execute procedure with default 10 jobs:
exec APPPROC_UPDATE_CTO_LEVEL_7301;
Execute procedure with 20 jobs:
exec APPPROC_UPDATE_CTO_LEVEL_7301( 20 );
Monitor job completion until no jobs are listed in the USER_JOBS table:
select * from user_jobs
Create the new Demantra.war and deploy to your application server.
For more information, see “Configure to Order” in the Oracle Demantra Integration Guide.
If you want to upgrade from a version earlier than 7.1, you must update to an intermediate release like 7.3.0.2, and then upgrade to the current version.