Scpo Installadmin Guide

Installation/Administration Guide JDA® Supply Chain Planning and Optimization Release 8.1.0.0 Last updated: 14 April 2014

JDA Software Group, Inc.

Legal notice Rights to the content of this document

Copyright © 1997-2014 JDA Software Group, Inc. All rights reserved.

Printed in the United States of America.

Reproduction of this document or any portion of it, in any form, without the express written consent of JDA Software Group, Inc. ("JDA") is prohibited.

These materials are protected by the Copyright Act of 1976, as amended, as an unpublished work and the foregoing notice and legend shall not be deemed to constitute publication or an intent to publish thereunder. These materials are proprietary and confidential information of JDA and may be disclosed and used only as authorized in a signed, written agreement controlling such disclosure or use.

The fact that a particular name or logo does not appear on this notice does not constitute a waiver of any intellectual property rights that JDA has established in any of its products, feature or service names, or logos.

Modifications to the contents of this document

JDA reserves the right, at any time and without notice, to change these materials or any of the functions, features, and specifications of any of the software described herein. JDA shall have no warranty obligation with respect to these materials of the software described herein, except as provided in the JDA software license agreement with an authorized licensee.

Rights to the functionality of this document

Described functionality may not be available as part of a customer's maintenance agreement or the JDA Investment Protection Program. New features and products are subject to license fees. JDA warranty and support obligations apply only to the documentation as delivered by JDA, and are void if the documentation is modified or supplemented by anyone other than JDA. This document embodies JDA valuable trade secrets, is confidential to JDA, and must be kept in confidence and returned upon the expiration or termination of your JDA license agreement. You are not permitted to copy, extract, distribute, transfer, or share the contents of this document with anyone except authorized individuals within your organization.

Technical documentation

NOTICE: This design or technical documentation is supplied as a courtesy only and does not form part of the "Documentation" as defined in your JDA license agreement. This design or technical documentation is supplied in the English language only and is supplied "as is" and without warranties. JDA, at its discretion, may choose to offer this document in additional languages, but is under no obligation to do so. JDA undertakes no obligation to update this design or technical documentation.

Patents

This product may be protected by one or more US patents. Please see the JDA Patents website (http://jda.com/JDAPatents).

This product may be protected by one or more of the following non-US patents:

Europe Patent No. 0861474 (E) Taiwan Patent No. 161120 Taiwan Patent No. I222584

Europe Patent No. 0861474 (UK) Taiwan Patent No. 161181 Taiwan Patent No. I222585

German Patent No. 10195871 Taiwan Patent No. 161494 Taiwan Patent No. I222586

German Patent No. 69507020.7 Taiwan Patent No. 163816 Taiwan Patent No. I225208










http://jda.com/JDAPatents



German Patent No. DE10195968 Taiwan Patent No. 384430 Taiwan Patent No. I242952

Taiwan Patent No. 100569 Taiwan Patent No. 425517 Taiwan Patent No. I251760














Taiwan Patent No. 146038 Taiwan Patent No. 544598 Taiwan Patent No. M377652

Taiwan Patent No. 154327 Taiwan Patent No. 544599 Taiwan Patent No. NI-158220





Taiwan Patent No. 157467 Taiwan Patent No. I221578 Taiwan Patent No. NI-182974

Taiwan Patent No. 159609 Taiwan Patent No. I221978


Provide feedback on this document JDA values your opinion and strives to ensure that the documentation you receive is clear, concise, and provides the appropriate information required for you to use each JDA application efficiently.

If you would like to provide feedback on this document, you can submit your questions or suggestions to the JDA Documentation Management team (mailto:[email protected]) and they will be forwarded to the appropriate development teams for review and consideration in a future release.

mailto:[email protected]


Software implementation advisement IMPORTANT: Although JDA licenses packaged software, JDA solutions offer complex capability and scalability requiring trained, experienced personnel to install and implement. Even robust documentation is no substitute for JDA certified consultants. JDA implementation experience in addition to training, both on the JDA solutions and on their underlying technologies as defined in JDA solution documentation, are the keys to success. Given JDA’s mission to ensure customers achieve optimal results, JDA strongly recommends you use certified consultants who understand JDA applications and delivery methodologies. Without this guidance, you can expect to experience implementation challenges that cannot be addressed effectively under your JDA support agreement. In these circumstances, JDA Support Services will refer you to the Consulting Services team who can be engaged to answer questions and guide the implementation.

Software support The JDA Solution Investment Policy includes three support levels to maximize your benefit. By supporting only the newest software versions, JDA can provide you with exemplary service, allowing you to realize an evolving return on your software investment. Through the JDAUser website (http://www.jdauser.com), you can access a comprehensive summary of your licensed applications and their current levels of support.

http://www.jdauser.com/


Table of Contents Chapter 1. Overview ........................................................................................................ 1

High-level roadmap of installation .................................................................................. 1 Conventions used in this guide ............................................................................. 1 About JDA documentation set ............................................................................... 2 Online help ........................................................................................................ 3 Technical documentation ..................................................................................... 3 Release notes ..................................................................................................... 3 Get additional help from JDA ................................................................................ 4

SCPO architecture ........................................................................................................ 5 System architecture ............................................................................................ 5 Other supported configurations ............................................................................. 7 Guidelines for browser usage................................................................................ 7

Chapter 2. Pre-requisites ................................................................................................. 9 Before you install ......................................................................................................... 9

Chapter 3. Pre-installation tasks ................................................................................... 10 Pre-installation checklist ............................................................................................. 10 Gather information .................................................................................................... 10 Configure database .................................................................................................... 10

Prepare an Oracle database for SCPO .................................................................. 10 Windows client setup for JDA Production and Sourcing Optimization ................................. 12

Chapter 4. Installation ................................................................................................... 13 Installation checklist .................................................................................................. 13 Install the SCPO software ........................................................................................... 13

Install the SCPO software on UNIX and Windows .................................................. 14 Install SCPO SRE .............................................................................................. 18 Uninstall the software ........................................................................................ 21

Install JDA Production and Sourcing Optimization Client ................................................. 23 Download and run the Production and Sourcing Optimization Client ........................ 23 Upgrade Production and Sourcing Optimization Client software ............................... 24 Uninstall Production and Sourcing Optimization Client ........................................... 24

Install Demand Field Sales mobile application ............................................................... 24

Chapter 5. Post-installation tasks .................................................................................. 25 Post-installation checklist ............................................................................................ 25 Create the SCPO database schema objects ................................................................... 25

Create the SCPO schema-UNIX or Windows ......................................................... 25 Create the 8.1 schema ...................................................................................... 26

Upgrade to SCPO 8.1 ................................................................................................. 30 Overview of the upgrade process ........................................................................ 31 Migration guidelines .......................................................................................... 31 Guidelines for the SCPO database ....................................................................... 33 Migrate the SCPO schema from 6.x, or 7.1.x to 7.2 - UNIX .................................... 33 Migrate the SCPO schema from 6.x, or 7.1.x to 7.2 - Windows ............................... 44 Migrate the SCPO schema from 7.2.x, 7.3.x, 7.4.0, 7.4.1 to 8.1.0.0 - UNIX or Windows54 Migrate SCPO schema from 7.4.2 or later to version 8.1 ........................................ 75 Migrate from DPEE to SCPO 8.1 - UNIX or Windows .............................................. 79 Migrate from JDA Strategy 6.2 to SCPO 8.1 - UNIX or Windows .............................. 86 Add subcomponents .......................................................................................... 91 Migrate Compressed Data Storage (CDS) ............................................................. 91


Deploy Replenishment Workbench for JDA Enterprise Supply Planning, JDA Fulfillment, and JDA Master Planning .......................................................................................... 96 Add subcomponents .......................................................................................... 97

Access SCPO ............................................................................................................. 97 Configure application server ........................................................................................ 98

Configure the environment - UNIX ...................................................................... 98 Configure the server ......................................................................................... 98 Configure the environment - SRE ........................................................................ 98

Configure Decision Support Workbench for a cluster .................................................... 115 Migrate Shelf Connected Supply Chain Report Model to Collaborative Shelf Planning and Analytics ............................................................................................................................. 115

Chapter 6. Utilities and common tasks ........................................................................ 117 Import data ............................................................................................................ 117

How IGP works with SCPO ............................................................................... 117 Customize the import process .......................................................................... 117 Before you begin batch processing .................................................................... 118 Prepare to load SCPO data ............................................................................... 118 Load data ...................................................................................................... 121 Application-specific setup procedures for import processes ................................... 129

Run batch processes ................................................................................................ 136 Use SRE to launch batch processes ................................................................... 136 Create the process request XML file .................................................................. 136 Examples of process request XML files ............................................................... 137 Start a node pool ............................................................................................ 138 Run SREBatchUtility ........................................................................................ 139 Batch-only processes for Demand ..................................................................... 139 Monitor and manage SCPO SRE processes ......................................................... 141 Run non-SRE batch processes .......................................................................... 141

SCPO Partial Database Extract Instructions ................................................................. 142 Features and Limitations .................................................................................. 142 Instructions .................................................................................................... 143

Update the configuration code after installing a new software license ............................. 145

Appendix A. Support for Demand Decision Support Workbench, Promotions Management Workbench, and Production and Sourcing Optimization Client on WebSphere ............. 146

Set up WebSphere server ......................................................................................... 146 Import certificates to the server trust store ........................................................ 146 Create the client trust store ............................................................................. 146 Create a client key file with a self-signed certificate ............................................ 146 Create a client trust file and import signers data ................................................. 147 Distribute among applet/Production and Sourcing Optimization clients .................. 147 Change key and trust store passwords .............................................................. 148

Appendix B. Patches .................................................................................................... 150 Full patch ............................................................................................................... 150 Partial patch ........................................................................................................... 151 Revert patch ........................................................................................................... 151

Rollback full patch ........................................................................................... 151 Rollback partial patch ...................................................................................... 153

Appendix C. Glossary ................................................................................................... 155

Index ........................................................................................................................... 158

Overview

Chapter 1. Overview This chapter introduces the Supply Chain Planning and Optimization (SCPO) components. This guide provides information on installing, configuring, and administering the SCPO suite of products. Use it in conjunction with the JDA Platform Installation/Administration Guide.

SCPO is a web-based decision-support system that provides tools to help you plan and control your manufacturing and distribution operations. Use these tools to determine how much product is needed to meet customer demand, where the product is needed, when it needs to be there, and how best to supply it to meet the demand.

SCPO combines the key components of enterprise-wide logistics planning into a group of applications, each of which enables you to control a specific aspect of the supply chain planning process. Depending on your organization's business needs, you can install SCPO applications individually, or in combination with other SCPO applications. SCPO is supported by the JDA Platform software, which provides Security Manager and a central launch point for the applications. All SCPO products use the SCPO relational database to store and manage their data.

High-level roadmap of installation This section describes the high-level tasks that are required to install SCPO.

If you are installing SCPO for the first time, follow the high-level installation and configuration tasks described in this section. If you are upgrading an existing system to SCPO version 8.1, follow the tasks listed in "Overview of the upgrade process (on page 31)".

Task Description Required or Optional

Step 1: Install prerequisite software Use the information in Hardware and software requirements section of the JDA Platform Release Notes file to determine the correct operating system and patch levels.

Required

Step 2: Create the SCPO tablespaces.

See "Create a SCPO tablespace and user (on page 11)".

Required

Step 3: Install SCPO version 8.1 See "SCPO software installation". Required

Step 4: Perform post installation configuration tasks.

See "Post-installation configuration". Required

Step 5: Create the SCPO user, schema if not created during installation.

See "Create the SCPO database schema (on page 25)".

Optional

Step 6: Configure the JDA server (configureJDAServer).

See JDA Platform Installation/Administration Guide.

Required

If you need to install additional SCPO components after the installation process is complete, see Add subcomponents (on page 97).

Conventions used in this guide This section describes the typographic conventions used in this guide.

DVD and electronic image In this guide, the term DVD refers to software distributed on JDA DVDs and to software distributed electronically. Both forms of distribution consist of either a Windows Zip file or a UNIX Tar file.

When specifying the electronic image, the following syntax is used:

<image_dir>\scpoweb

JDA Supply Chain Planning and Optimization Installation/Administration Guide 1 © 1997-2014 JDA Software Group, Inc.- Confidential

Overview

User input Examples of user input appear in a monospaced font as in this example:

dm_vpcatalog.bat wwfmgr wwfmgr

In this example, the exact (literal) commands to enter to perform the step are displayed. See the following sections for information on specifying optional values and variables.

Optional values When showing the syntax and format for entering commands at the command-line prompt or in input files, this guide shows optional values enclosed in brackets ([]). For example, the following is the syntax for running a batch command:

NWImport -C<control_file> -D<data_file> [-L<userid> -P<password> -E<enterprise> -Z<partner_data_file> -O]

In this example, you must enter the -C and -D options, but the -L, -P, -E, -Z, and -O options are optional. When entering optional values, do not enter the brackets around the options.

Variables Italic font in brackets represents a placeholder value or variable that you enter. For example:

CP_CONFIG_READER=<value>

In this example, enter the first part exactly as shown, but replace <value> with the actual value for your environment.

Directories When specifying the path to JDA installed directories and files, the following syntax is used:

<install_dir>\config\bin\scpoweb

<install_dir>\config\database\scpoweb

The <install_dir> represents the drive letter and actual directory where JDA version 8.1 components are installed. For example, c:/jdav800/MSAM or./home/usr01/apps/jdav800/MSAM, where MSAM is the name of your SCPO database. Back slashes are used to represent directory paths for both Windows and UNIX platforms where the directory structure is the same.

Oracle database names In this guide, MSAM is used in most of the examples to represent an Oracle database name. This is a suggested, but not required, name for a sample database. You can substitute another name.

Menu or registry path Multiple menu selections and registry entry paths are shown using right-facing carats, as in the following example:

From your Windows desktop, click Start > Programs > JDA 8.1 > SCPO.

Registry entries are often shown this way as well, such as in this example:

HKEY_LOCAL_MACHINE > SOFTWARE > JDA > JDA System > 8.1

About JDA documentation set If you need additional help or have problems with your application, see "Get additional help from JDA (on page 4)".


Overview

Online help The SCPO application contains online help that can guide you through the user interface. Each page has its own context-sensitive help that describes the purpose of each component of the page. In addition, user information is included to describe high-level processes and procedures, as well as provide step-by-step instructions for completing a task.

You can access online help for a particular page by clicking the Help link at the top of the page. In the help, you can access additional information through the Table of Contents or by using the index. You can also search the help using Search located at the top of the Help window.

The SCPO suite of applications includes components and utilities that are used by multiple applications as well as components that are specific to a single application. When using SCPO applications, you need to be aware of your location in the system as it determines the help content to which you have access. For example, if you are working in a Flexible Editor page, which is part of the basic SCPO architecture, and you click the Help link, you access general help information for common SCPO components. This help includes information about common features, such as Flexible Editor, calendar management, and import/export. This help also contains the definitions for each database table. However, this help does not provide information about specific SCPO application features, such as forecasting, planning, distribution, or allocation.

To access information about application-specific features, you must access the help for that application. To do so, open the appropriate page in the application. If you are unsure of the page to use, open any application-specific page, such as Plan Analysis for Fulfillment or Demand Workbench for Demand, then click the Help link on that page. The context-sensitive help topic for the active page is displayed in the right frame and the Table of Contents for the entire application help system is displayed in the left frame. You can then use the Table of Contents, Search, or Index functions to find the appropriate application-specific information.

Technical documentation The following technical documentation is available for JDA applications:

• Installation/Administration information is available in the Supply Chain Planning and Optimization Installation/Administration Guide.

• Database information (detailed information about the tables and columns in the SCPO database) is available in the application Reference Guides. For each application that uses JDA Platform, this information is also included in the Online Expert.

• The Supply Chain Planning and Optimization (SCPO) version 8.1 Release Notes, release_notes_generalSCPO.pdf, contains information that pertains to all SCPO applications. Individual product Release Notes are also available for each JDA application for which you are licensed, and are named using the format release_notes_<appname>.pdf (for example, release_notes_demand.pdf).

When you install the application, you can open technical documents from:

• Doc\guides\en directory on the JDA DVD (for technical guides)

• Doc directory on the JDA DVD (for release notes)

• JDA 8.1 program group on the Windows Start menu

• Installed directory structure

Release notes The Supply Chain Planning and Optimization (SCPO) version 8.1 Release Notes contains information that pertains to all SCPO applications. Individual product Release Notes are also available for each JDA application for which you are licensed.


Overview

The General SCPO Release Notes file is called release_notes_generalSCPO.pdf. File names for individual product Release notes files are in the format release_notes_<appname>.pdf (for example, release_notes_demand.pdf). You can open Release Notes files from:

• The doc directory on the JDA DVD

• The JDA 8.1 program group on the Windows Start menu

• The installed directory structure

The Release Notes contains sections with the following information:

• Hardware and software requirements

• Open-source software acknowledgements

• Installation information

• Information alerts

Get additional help from JDA In addition to the provided documentation, many additional resources are available to help you understand and work with your JDA applications.

• JDA Support Services

JDA Support Services enhances your experience with JDA solutions throughout the lifetime of your relationship with JDA Software. Support Services provides many key values, including:

• Worldwide support provided locally for issue resolution, including functional and technical assistance

• Defined service levels and proactive escalation paths

• Special Interest Group (SIG) membership

• Access to new software releases

• Access to the JDAUser website (http://www.jdauser.com), which provides:

• Self-service user administration

• Online knowledge base

• Online case management and user communities

• Product documentation and release announcements

• JDA Education Services

To enhance the return on your JDA solution investment, JDA Education Services provides options to optimize your experience and knowledge. JDA Education Services offers high-quality training with e-learning and instructor-led training opportunities. JDA Education Services also offers the JDA Certification Program, which defines a curriculum that maximizes your knowledge and qualifications for a specific job. Certification programs employ a blend of learning methods that end with an industry-recognized exam. See the JDALearn website (http://www.jdalearn.com) for more information.

• JDA Consulting Services

JDA Consulting Services provides a broad range of services, including:

• Process definition and improvement

• Change management

• Program and project management

• Functional and technical consulting


http://www.jdauser.com/

http://www.jdalearn.com/

Overview

• Performance engineering

• Solution delivery

Every solution deployment begins with the JDA Enterprise Methodology, which encompasses both technology and implementation expertise. JDA Consulting Services works collaboratively with you to help your business realize the results you need, on time and on budget.

• JDA Cloud Services

JDA Cloud Services enables you to achieve faster deployment, rapid time to value, investment protection, and improved cost structure with JDA supply chain solutions. This allows you to focus on your core business while JDA manages the JDA applications. Areas of specialty include:

• Solution availability management

• Performance management

• Issue resolution

• Change management

• Security management

• Optimization and analytics management

For more information on any of the JDA Services, see the JDA Services website (http://www.jda.com/services/services/).

SCPO architecture This chapter provides an overview of the Supply Chain Planning and Optimization (SCPO) architecture, which is built on the JDA Platform architecture. For details on the underlying architecture, see the JDA Platform Installation/Administration Guide.

System architecture SCPO requires the following components:

• Supported operating system

• Supported version of Oracle. The Oracle database hosts the SCPO and JDA Platform schemas. The Oracle database can be on the application server or a different server. See the Oracle documentation for information on installing and configuring Oracle.

• Supported application server and Java Development Kit

• JDA Platform, which handles all requests for data from the SCPO database and most data processing. JDA Platform must be installed before installing SCPO. Always install the version of JDA Platform that supports your version of SCPO.

• SCPO applications, which consist of:

• JDA Demand

• JDA Demand Decomposition

• JDA Demand Management Foundation

• JDA Dynamic Demand Response

• JDA Enterprise Supply Planning

• JDA Flowcasting

• JDA Fulfillment

• JDA Markdown Optimization


http://www.jda.com/services/services/

Overview

• JDA Master Planning

• JDA Production and Sourcing Optimization

• JDA Promotions Management

• JDA Strategic Pricing

• JDA Travel Price Optimization

The license file that you specify during the Platform installation process determines the applications that are enabled on the application server.

• SCPO common components:

• Common utilities, such as Calendar Manager and Scenario Manager, which are available from the Directory

• An administrator or other authorized user creates roles and users using the Security Manager and User Manager UIs. When created, users are assigned to one or more roles, which determine the applications and data they are permitted to access. See the Security Manager Online Help for details.

• ILOG CPLEX is installed on the application server as part of the SCPO installation. CPLEX is optimization software that is used by the JDA Production and Sourcing Optimization and Travel Price Optimization applications to solve complex linear optimization problems/algorithms.

• Users of the Enterprise Supply Planning, Fulfillment, and Master Planning Replenishment Workbench access data through a .NET application that is downloaded from the JDA Directory and installed on the local client machine. These applications require the .NET client on the client computer. For more information to .NET, see 'NET UI Framework Installation and Deployment' in the JDA Platform Installation/Administration Guide.

• JDA Demand and Promotions Management have Java applet clients that are downloaded through the browser. These clients require that the appropriate version of Java be installed on the client computer.

• All other JDA application users access the application server over the Internet or organization intranet. The 'thin client' requires a supported browser. Users specify an HTML URL that links them to the login screen. See the "Hardware and software requirements" in the JDA Platform Release Notes for supported browser levels.


Overview

The basic system architecture is shown in following figure. In this configuration, a single Java Virtual Machine (UNIX or Windows) hosts the application server, JDA Platform, SCPO application, server-side components, and database management system.

Application Server with

JDK

Web Clients Application Server

SCPO with batch

componentsOperating

system (UNIX or Windows)

JDA PSO Client

JDA Platform

Oracle DB(SCPO/WWF/ABPP

schemas)

Figure 1: Standard configuration- Supply Chain Planning and Optimization

A single-machine configuration may not meet your organization’s requirements. If your business process requires that you run algorithmic-intensive processes, offloading these processes to one or more JDA Platform SRE machines may improve performance. See "Other supported configurations" (on page 7) for an overview of this and other configuration options for SCPO.

Other supported configurations In addition to the basic configuration described previously, you can configure SCPO as follows:

• In a clustered application server environment, you can deploy SCPO in a WebLogic or WebSphere cluster for improved user interface scalability and performance. A cluster configuration involves a Web Server tier distributing requests to multiple application servers that use the same application schemas. See the JDA Platform Installation/Administration Guide for procedures on configuring a clustered environment.

• Using additional servers to host the service runtime environment (SRE) to offload algorithm processing from the application server, JDA SRE can deploy on multiple servers to achieve improved scalability, performance, and reliability. This architecture simplifies deployment of multiple processes on different machines and provides better process status life-cycle management. It also includes a coordination layer that manages the sequence of steps in a multiple-process algorithm run. See the JDA Platform Installation/Administration Guide for more information.

Guidelines for browser usage If you are upgrading from a SCPO version 7.x release, then you should clear your browser cache before accessing SCPO. See Access SCPO (on page 97).


Overview

The following guidelines apply to the use of multiple browser windows:

• Multiple windows are supported under Internet Explorer when initiated using the File-> New Session command.

• Multiple Internet Explorer windows started by pressing Ctrl+N or Ctrl+T are not supported because they share the session.

• Pages cannot automatically refresh when working in multiple windows; therefore, you must re-run the search on a page when moving between windows.

Refer "Hardware and software requirements" in the JDA Platform Release Notes for supported browser levels.


Pre-requisites

Chapter 2. Pre-requisites This chapter provides instructions for preparing to install Supply Chain Planning and Optimization (SCPO) on UNIX or Windows.

Before you install JDA uses Install Anywhere for installation, which provides a graphical interface on Windows and a console interface on UNIX. A silent installation mode is also available, which reads installation variables from a properties file.

Before installing SCPO on the application server:

• You must install JDA Platform before installing SCPO. JDA Platform provides the basic functionality that SCPO depends on, such as security, single sign-on, and integration.

• You must have the Oracle username and password for the JDA Foundation schema. The SCPO schema must be in the same Oracle SID as the Foundation schema. The scripts to create or migrate the Foundation schema are installed with JDA Platform.

• You must have access to the Oracle system user in order to create an Oracle username and password for the SCPO schema. The scripts to migrate or create a new SCPO schema are included in the SCPO installation.

• If you are installing JDA Production and Sourcing Optimization, you must have installed the appropriate version of Windows with the appropriate service packs and patch bundles on the computer that will serve as the Production and Sourcing Optimization client.

See Hardware and software requirements in the JDA Platform Release Notes for specific operating system and patch requirements for Windows and UNIX, for the supported Oracle versions, and for any additional base software prerequisites. If you are licensed for a specific JDA SCPO application, see the Hardware and software requirements in the specific application Release Notes for additional hardware and software requirements for that product.

Note: The basic operating system and service pack or patch bundle levels are the same for most JDA Platform-based 8.1 products. However, you should check and fulfill the specific requirements for the SCPO component.


Pre-installation tasks

Chapter 3. Pre-installation tasks Pre-installation checklist Perform the following tasks before the installation:

• Install Platform.

• Set up Oracle:

• Create an Oracle tablespace for the SCPO schema. Specify this SCPO tablespace during installation. By default, the SCPO tablespace is SCPODATA, but you can specify another tablespace during installation, which will be used to create the SCPO user.

Gather information The installation program prompts you for information about your system and the environment in which it runs. Before installing, you need the following tools and information:

• User ID with administrative privileges (Windows) or user ID and password with appropriate file access permissions (UNIX)

• SCPO 8.1 software image

• Directory where you want to install the server software. This is the directory where the JDA Platform is installed, for example, c:\jda\jdav80\0

• Oracle user and password for the SCPO schema. SCPO uses this account to connect to the SCPO database.

• SCPO tablespaces to hold the application data and indexes.

• Password for the system, SCPO and Platform schema.

Configure database

Prepare an Oracle database for SCPO You must have an Oracle database to run the SCPO application and store your data. The database must be created using UTF8. Create the database after installing the software using the scripts provided by JDA Platform. The JDA database creation scripts create a new UTF8 database using character set AL32UTF8. See the JDA Platform Installation/Administration Guide for procedures on running these scripts.

If you plan to use an existing UTF8 database that was not created using JDA scripts, you must modify the database before using it with SCPO version 8.1 by following the instructions in this appendix.

Note: SCPO date columns must include an hour and minute timestamp. The Oracle default date format does not include an hour and minute timestamp, so you must add the NLS_DATE_FORMAT setting to your environment before you create, migrate, or access a SCPO database. The value must be RRRR-MM-DD-HH24:MI.

To create a JDA Oracle database on either UNIX or Windows, you must:

• Create or modify the Oracle database.

• Create the application-specific tablespace and user. See Create a SCPO tablespace and user (on page 11).

• Create or migrate the application-specific schema. See Create the SCPO database schema (on page 25) or Upgrade to SCPO 8. (on page 30)1.



In addition, you must possess a strong knowledge of Oracle, SQL*Plus, and tablespace and user creation. All SQL scripts should be executed using SQL*Plus.

Prepare an existing database for a SCPO tablespace Follow the procedures in this section if you did not create your Oracle database using JDA scripts.

Note: These procedures are common to both UNIX and Windows, unless specified.

1. Set the following parameters in init<SID>.ora. Usually, this file is located in directory $ORACLE_BASE/admin/<SID>/pfile (UNIX) and %ORACLE_BASE%\admin\<SID>\pfile (Windows).

utl_file_dir=*

db_cache_advice = OFF

job_queue_processes = 1

2. Verify that the ORACLE_SID environment variable is set to the name of the database designated to contain the SCPO tablespace and that the database instance is running. To verify this, at a command line prompt, enter the following:

echo $ORACLE_SID (for UNIX)

set ora (for Windows)

You can set the ORACLE_SID by entering the following:

export ORACLE_SID=MSAM (for UNIX)

set ORACLE_SID=MSAM (for Windows)

3. Make sure that the Oracle user who owns the SCPO schema does not exist, and that the database does not have any existing SCPO data in it.

4. See Create the SCPO tablespaces and user-UNIX or Windows (on page 11).

Create a SCPO tablespace This appendix contains instructions for creating a set of SCPO tablespaces and tables in an existing Oracle database. The instructions in this appendix assume that you have created an Oracle instance (SID) for the SCPO database using the procedures in the JDA Platform Installation/Administration Guide or prepared an existing database using the procedures in Prepare an Oracle database for SCPO (on page 10).

Before you install, you must create a tablespace to hold the SCPO application data and indexes. In addition, you must create the SCPO user and assign the default tablespace. The SCPO user owns all objects in the tablespace. JDA provides a script to create these objects. The script creates the following tablespaces:

• SCPODATA: Contains SCPO application data.

• SCPOINDEX: Contains SCPO indexes.

Note: The SCPOINDEX tablespace is optional. The scripts that create the SCPO database objects do not automatically place indexes in a separate tablespace.

Create the SCPO tablespaces he database instance must already exist before performing the following procedures.

1. If you did not create the database using JDA scripts, set the appropriate database initialization parameters specified in the JDA Platform Installation/Administration Guide.

2. Change to directory:

• UNIX: <install_dir>/config/database/setup/unix



• Windows: <install_dir>\config\database\setup\windows

3. Using a text editor, open cr_scpo_ts.sql.

4. Search and replace all occurrences of "%%%%%%%%" in the file with the name of your Oracle database (SID).

5. Review and validate all directory paths and file destinations.

6. Modify the default size for the SCPO tablespaces, as needed.

7. Save the file and exit the text editor.

8. Run the file by entering the following:

UNIX:

export ORACLE_SID=<sid_name>

sqlplus system/<password> @cr_scpo_ts.sql

Windows:

set ORACLE_SID=<sid_name>

sqlplus system/<password> @cr_scpo_ts.sql

The script creates the scpodata and scpoindex tablespaces.

9. Examine cr_scpo_ts.log to verify successful creation of all user objects.

Windows client setup for JDA Production and Sourcing Optimization Many JDA Production and Sourcing Optimization operations are performed in the Production and Sourcing Optimization client application, which must be installed on your individual Production and Sourcing Optimization users' computers.

Before you install the JDA Production and Sourcing Optimization client software, be sure that the appropriate version of Windows is installed with the appropriate service packs and/or patches. See "Hardware and software requirements" in the JDA Production and Sourcing Optimization Release Notes for specific requirements.


Installation

Chapter 4. Installation Installation checklist During installation, use the following table to note the values that you are using during installation:

Description Value

Installation directory

JDA Platform installed with SCPO license

If installation contains post-installation database tasks, set ORACLE_HOME

Oracle database schema owner and password

SCPO database tablespace name

SCPO database connection pool sizes

If running the post-installation steps to create the SCPO schemas, the Oracle system password and Foundation password is required

Tip: For your convenience, you can take a printout of this checklist to ensure that you complete all of the necessary tasks.

S. No Tasks Status Notes

1 Install Platform and configure the Platform schema

2 Create database tablespace for SCPO user

3 Install SCPO. Optionally, create the SCPO user and schema in the post-installation options

4 Create or migrate the SCPO database (if not created during post-installation)

5 Configure Platform server

6 Verify SCPO installation

7 Install SCPO SRE (if required)

Install the SCPO software This chapter provides detailed instructions for installing Supply Chain Planning and Optimization (SCPO) on UNIX or Windows.

The instructions in this chapter assume that you have a strong knowledge of:

• Windows, or your particular UNIX operating system, including how to:

• Create users, files, and directories


Installation

• Use the Windows registry

• Set permissions and environment variables

• Configure batch scripts

• The Oracle database management system, including how to create databases and tablespaces and administer Oracle database users and Oracle roles

Before installing any JDA applications, review Preinstallation requirements (on page 9) to ensure that your system has the necessary prerequisite software installed.

Install the SCPO software on UNIX and Windows This section describes information that you need to gather and how to install the SCPO software on both UNIX and Windows. Before you install SCPO, you must install JDA Platform. To use a silent installation for SCPO, see Silent installation for SCPO (on page 16).

Install SCPO JDA uses InstallAnywhere to install software. The InstallAnywhere utility provides a graphical installation on Windows and a console installation on UNIX. Alternatively, you can perform a silent installation that runs without intervention using the procedures in Silent installation for SCPO (on page 16). If you are installing on UNIX remotely from a personal computer using telnet, then you can use console or silent installation.

Note: If you receive an error message regarding insufficient disk space while installing SCPO on UNIX, set the IATEMPDIR environment variable to a directory on a disk partition that has sufficient disk space available. To set the variable, enter one of the following commands at the UNIX command line prompt before running the installation program again:

• - Bourne shell (sh), ksh, bash and zsh:

$ IATEMPDIR=/your/free/space/directory

$ export IATEMPDIR

• - C shell (csh) and tcsh:

$ setenv IATEMPDIR=/your/free/space/directory

Replace /your/free/space/directory in the command with the name of the directory that has sufficient free space for the installation to continue.

To perform a graphical or console installation of SCPO:

1. If you have not already installed the JDA Platform, do that first. On Windows, the SCPO install utility will use the Registry to detect the Platform installation directory.

2. Log in to the computer using a User ID that has administrative privileges to the computer (Windows) or as the JDA user jdamgr (UNIX).

3. Save and exit other running programs.

4. Change to <image_dir>\scpoweb.

5. Change to the subdirectory for your operating system and run the appropriate SCPO file at the command-line prompt.

• AIX: /scpoweb/aix/installSCPOWeb.bin

• Linux: /scpoweb/linux/installSCPOWeb.bin

• Solaris: /scpoweb/solaris/installSCPOWeb.bin

• Windows: \scpoweb\windows\installSCPOWeb.exe


Installation

If the console displays an error on UNIX platforms that the file cannot be run, change the permissions on the file. For example,

chmod +x installSCPOWeb.bin

Try running the binary file again. On Windows, the Introduction dialog box is displayed.

6. Click Next to continue.

7. Accept the terms of the License Agreement, then click Next.

8. On the Enter JDA Platform Install Folder dialog box, verify the path where the JDA Platform was installed, for example, C:\jda\jdav800. Click Choose to change the path. Click Next. On Windows platforms, the Choose Shortcut Folder dialog box is displayed. UNIX does not have an equivalent window.

If you receive the following error:

The JDA Platform files have not been installed.

Click Previous and verify the path where you installed JDA Platform. Platform must be installed first.

9. The License Check Status displays the components with the installed license. Click Next.

Note: An Invalid License File error message is displayed if you do not have any SCPO products enabled in the license that was installed with JDA Platform.

10. On the Choose Shortcut Folder dialog box select the desired location for a shortcut to SCPO. (You should add SCPO to the folder where the JDA Platform was installed.) Click Next.

11. Enter the Oracle Database Settings. These settings control version access to the SCPO database.

• For User ID, enter the Oracle user name for the SCPO schema owner (for example, SCPOMGR). The user account owns all objects in the SCPO database.

• For Password, enter the password for the SCPO schema owner.

Click Next.

12. Enter the SCPO Tablespace name for the SCPO schema user, for example, SCPODATA. Click Next.

13. Configure the SCPO Connection Pool, then select Next. The default values may need to be increased for larger implementations. Enter the following:

• Connection Pool Initial Capacity. The default is 10.

• Connection Pool Max Capacity. The default is 100.

• Connection Pool Capacity Increment. The default is 5.

Note: SCPO uses the SCPOConnectionPool configured after installation. If necessary, change these settings after installation. See the JDA Platform Installation/Administration Guide for information on changing connection pool settings after installation.

The Pre-Installation Summary dialog box displays your configuration choices, including the amount of disk storage space required and available.

14. To change the settings, click Previous. To proceed with the installation, click Install. The installation utility copies files from the DVD to your computer. This process may take a few minutes.

Caution: When you click Install on the Pre-Installation Summary window, a progress window is displayed. Do not close this window. Doing so causes the installation to fail.

15. The Post Installation Steps window is displayed. You can select the following post installation tasks to:


Installation

• Create SCPO Database Users: Create the SCPO database users.

• Create SCPO Database: Create and populate the SCPO database schema.

• Configure Platform Server (WebLogic only): Configure the JDA Platform server. This runs the batch command configureJDAServer.

• Oracle SYSTEM Password: Required to create the SCPO users and schema.This password is not stored in the installation.

• Foundation Password: Required to create the SCPO schema.This password is not stored in the installation.

Note: You can run the command file runPostInstallTask.cmd (Windows) or runPostInstallTask.sh (Unix) to invoke post installation tasks anytime after installation.

16. On the Install Complete dialog box, click Done.

17. Verify the installation. The installation creates a JDA_SCPO_8.1_InstallLog.xml file in the <install_dir> directory. This file contains a summary of the installation, and should be retained for reference. Search for the <ActionsSummary> tag name near the top of the file. It has several nested tags: successes, warnings, non-fatal errors, fatal errors, and notes. You can examine these for problems with the installation. This file also contains a summary of the directories created and the files copied to your computer.

18. Perform post-installation configuration. See "Post-installation configuration".

19. If creating a new, empty database schema and you did not create the database schema in the post-installation steps, create the SCPO database (see "Create the SCPO database schema (on page 25)"). If you are migrating a database from an earlier version, migrate the SCPO database (see "Upgrade to SCPO 8. (on page 30)1").

20. If not done during the post-installation tasks, configure the JDA server by running configureJDAServer using the instructions in JDA Platform Installation/Administration Guide.

21. Configure SCPO. See "Configure the SCPO application".

22. Customize the SCPO database. See "Customize and maintain the database".

23. Start the JDA Platform Server.

Note: To re-create the configuration code for a new license file, see "Update the configuration code after installing a new software license (on page 145)".

Silent installation for SCPO 1. Log in to the computer using a User ID that has administrative privileges to the computer.


3. Change to <image_dir>\scpoweb. Copy installSCPOWeb.properties to the computer where the software will be installed.

4. Change to the directory for your operating system. Copy the appropriate executable or binary file to the same directory as the previous step

• AIX: /scpoweb/aix/installSCPOWeb.bin

• Linux: /scpoweb/linux/installSCPOWeb.bin

• Solaris: /scpoweb/solaris/installSCPOWeb.bin

• Windows: \scpoweb\windows\installSCPOWeb.exe

5. Using a text editor, open installSCPOWeb.properties. Some properties have default values. Enter values for all properties. For help in configuring the file, see the following list of properties required for silent installation.

• INSTALLER_UI: Silent. Do not change.


Installation

• USER_INSTALL_DIR: Directory where JDA Platform is installed, for example, D:\\jdav800. Use double-back slashes on Windows and single-forward slashes on UNIX.

• ORACLE_DB_1: Oracle user name for the SCPO schema owner. The user account owns all objects in the SCPO database.

• ORACLE_DB_2: Password for the Oracle user account.

• SCPO_TABLESPACE: Tablespace name for the SCPO schema user.

• SCPOWEB_CONN_POOL_VAR_1: Initial capacity for the connection pool. The default value is 10.

• SCPOWEB_CONN_POOL_VAR_2: Maximum capacity for the connection pool. The default value is 100.

• SCPOWEB_CONN_POOL_VAR_3: Increment value for the connection pool. The default value is 5

• POST_INSTALL_SCPO_CREATE_USER_ANSWER: Option to create SCPO database user. The default value is 0, which will not run this step..

• POST_INSTALL_SCPO_CREATE_DB_ANSWER: Option to create SCPO database. The default value is 0, which will not run this step.

• POST_INSTALL_CONFIGURE_SERVER_ANSWER: Option to configure Platform server. The default value is 0, which will not run this step. Note that this option is not supported on WebSphere.

• ORACLE_SYSTEM_PASSWORD: Password for Oracle system. Required if the POST_INSTALL_SCPO_CREATE_USER_ANSWER is 1.

• ORACLE_WWF_PASSWORD: Password for Foundation. Required if the POST_INSTALL_SCPO_CREATE_USER_ANSWER is 1.

6. Save and exit installSCPOWeb.properties.

7. Open a command-line prompt and change to the directory containing installSCPOWeb.properties and the installSCPOWeb executable or binary. Enter the following command:

installSCPOWeb.[exe|bin] -f

The command prompt may return quickly, but the installation takes a few minutes. If you changed the name of the properties file, or stored it in a different location, then you must specify it at the command line. For example,

installSCPOWeb.[exe|bin] -f <path>\<properties_file>

8. Verify the installation. The installation creates a JDA_SCPO_8.1_InstallLog.xml file in the <install_dir> directory. This file contains a summary of the installation, and should be retained for reference. Search for the <ActionsSummary> tag name near the top of the file. It has several nested tags: successes, warnings, non-fatal errors, fatal errors, and notes. You can examine these for problems with the installation. This file also contains a summary of the directories created and the files copied to your computer.

9. After verifying the installation, follow steps in the section Install SCPO (on page 14).


Installed program directory structure When you install SCPO on UNIX or Windows, the installation program automatically appends a directory structure to the JDA Platform config directory and copies selected application files to the directory. This directory structure is outlined in the table below:

Directories added to JDA Platform directory structure


Installation

Subdirectories in Windows

Contents

\bin\scpoweb Batch process command files, scripts, executables, and shared files

\database\scpoweb Database creation and migration scripts: shell (.ksh) / batch (.bat) and SQL (.sql)

\database\reporting Reporting related scripts to populate the JDA Directory.

\database\scpoweb\migrate

Database full schema utility (manufs.ksh/manufs.bat and manufs.sql) and related scripts for migration from pre 7.x versions of SCPO

\database\scpoweb\migration

Database migration scripts for migration from 7.6 to 8.1. These scripts allow a more seamless migration without having to migrate through interim versions.

\lib Contains JDA and third party JAR files required to run the application. . The JAR files present depend on what JDA applications are installed.

\logs Default location for log files

\ear\scpoweb Contains application JAR (Java Archive) and WAR (Web Archive) files in a folder for each JDA SCPO based application that is installed

\doc Release Notes files and other documentation files in PDF format.

\reports Reporting Cognos models, as well as template reports that can be used as a starting point for implementation.

The following information is specific to SCPO installation on Windows:

• If selected during installation, adds a menu link to the Windows Start > Programs menu under JDA 8.1.

• Creates a registry key for JDA 8.1 > SCPO under HKEY_LOCAL_MACHINE > SOFTWARE > JDA > JDA System.

• Installs all required third-party components in the <install_dir>\config\lib\vendor directory.

• Modifies selected variables in various configuration files to the values you enter.

Install SCPO SRE JDA Platform version 8.1 provides a thin installation to support the service runtime environment (SRE) framework. SCPO also has an SRE component. Running CPU-intensive algorithms and batch processes on a separate SRE machine will improve the performance of the application server.


Installation

This section describes how to install the SCPO SRE component. Before you proceed, you must install the JDA Platform SRE component. It is not necessary for the application server software be installed or running on the SRE machine. However, the SRE machine must point to an application server where the JDA Platform Server is running. It must also connect to the SCPO database server. See the JDA Platform Installation/Administration Guide for instructions on installing JDA Platform SRE and the WebSphere Application Server software.

Install SCPO SRE using the graphical interface Note: To perform a silent installation, see the Silent installation for SCPO SRE (on page 20).

1. If you have not already installed the JDA Platform SRE, do that first. The SCPO SRE install utility will search for and detect the SRE installation directory.

2. Log in to the computer using a User ID that has administrative privileges to the computer (Windows) or as the JDA user jdamgr (UNIX).


4. Change to <image_dir>\scpoweb_sre.

5. Change to the subdirectory for your operating system and execute the appropriate file at the command-line prompt

• AIX:/scpoweb_sre/aix/installSCPOWeb_SRE.bin

• Linux: /scpoweb_sre/linux/installSCPOWeb_SRE.bin

• Solaris:/scpoweb_sre/solaris/installSCPOWeb_SRE.bin

• Windows:\scpoweb_sre\windows\installSCPOWeb_SRE.exe

If the console displays an error on UNIX platforms that the file cannot be run, change the permissions on the file. For example,

chmod +x installSCPOWeb_SRE.bin

Try running the binary file again. The console may return UNIX hot-key errors similar to these:

Warning: Cannot convert string ...

Warning: Cannot convert string "<Key>Escape,_Key_Cancel" to type

VirtualBinding

These warnings are normal and you should proceed with the installation.

On Windows, the Introduction dialog box is displayed.

6. Click Next to continue.

7. On the Choose JDA SRE Install Folder dialog box, verify the path where the JDA Platform SRE was installed, for example, c:\jda\jdav800_SRE. Click Choose to change the path. Click Next.

If you receive the following error:

The JDA Platform SRE files are not installed. Please run the JDA Platform SRE installation before installing the product.

Click Previous and verify the path to where you installed JDA Platform SRE. The SRE must be installed first.

8. Enter the Oracle Database Settings. These settings control SCPO SRE access to the SCPO database.

• For User ID, enter the Oracle user name for the SCPO schema owner. The user account owns all objects in the SCPO database.

• For Password, enter the password for the SCPO schema owner.


Installation

9. Click Next. The Pre-Installation Summary dialog box displays your configuration choices, including the amount of disk storage space required and available.

10. To change the settings, click Previous. To proceed with the installation, click Install. Installation may take a few minutes.

11. On the Install Complete dialog box, click Done.

12. Verify the installation. The installation creates a JDA_SCPO_SRE_8.1_InstallLog.xml file in the <install_dir> directory. This file contains a summary of the installation, and should be retained for reference. Search for the <ActionsSummary> tag name near the top of the file. It has several nested tags: successes, warnings, non-fatal errors, fatal errors, and notes. You can examine these for problems with the installation. This file also contains a summary of the directories created and the files copied to your computer.

Silent installation for SCPO SRE 1. If you have not already installed the JDA Platform SRE, do that first. The SCPO SRE install utility

will search for and detect the SRE installation directory.

2. Log in to the computer using a User ID that has administrative privileges to the computer.


4. Change to directory <image_dir>\scpoweb_sre. Copy installSCPOWeb_SRE.properties to the computer where the software will be installed.

5. Change to the directory for your operating system and copy the appropriate executable or binary to the same directory as in the previous step.

• AIX:/scpoweb_sre/aix/installSCPOWeb_SRE.bin

• Linux: /scpoweb_sre/linux/installSCPOWeb_SRE.bin

• Solaris:/scpoweb_sre/solaris/installSCPOWeb_SRE.bin

• Windows:\scpoweb_sre\windows\installSCPOWeb_SRE.exe

6. Using a text editor, open installSCPOWeb.properties. This file contains all properties required to perform a silent install of SCPO; however, only a subset of these properties is required to install SCPO SRE. Properties that must be set for SCPO SRE are identified by "(SRE)" in the property description line in the file. Some properties have default values. For help in configuring the file, see the following list of properties.

• INSTALLER_UI: Silent. Do not change.

• USER_INSTALL_DIR: Directory where JDA Platform SRE is installed, for example, D:\\jda\\jdav800_sre. Use double-back slashes on Windows and single-forward slashes on UNIX.

• ORACLE_DB_1: Oracle user name for the SCPO schema owner. The user account owns all objects in the SCPO database.

• ORACLE_DB_2: Password for the Oracle user account.

7. Save and exit installSCPOWeb.properties.

8. Open a command-line prompt and change to the directory containing the installSCPOWeb_SRE.properties and installSCPOWeb_SRE executable or binary. Enter the following command:

installSCPOWeb_SRE.[exe|bin] -f

The command prompt may return quickly, but the installation takes a few minutes. If you changed the name of the properties file or stored it in a different location, then you must specify it at the command line. For example

installSCPOWeb_SRE.[exe|bin] -f <path>\<properties_file>


Installation

9. Verify the installation. The installation creates a JDA_SCPO_SRE_8.1_InstallLog.xml file in the <install_dir> directory. This file contains a summary of the installation, and should be retained for reference. Search for the <ActionsSummary> tag name near the top of the file. It has several nested tags: successes, warnings, non-fatal errors, fatal errors, and notes. You can examine these for problems with the installation. This file also contains a summary of the directories created and the files copied to your computer.

Installed program directory structure–SCPO SRE When you install SCPO SRE on UNIX, the installation program automatically appends a directory structure to the structure created by the JDA Platform SRE and copies selected application files to the directory. The installation program also adds application-specific files to existing JDA Platform directories. The following table lists these files as well as the subdirectories that the installation program creates and their contents.

Directories and files created during SCPO SRE installation

Subdirectories Contents

\config\lib Application and vendor jar files

\config\properties SCPO properties files

\config\resources SCPO resource bundles and properties files

\config\bin\scpoweb Shared libraries, executables, and command files

\install Component properties files for SCPO

\UninstallerData\SCPO SRE Uninstall

Files required to uninstall SCPO SRE

The following information is specific to SCPO SRE installation on Windows:

• Creates a submenu under JDA 8.1 for SCPO SRE on your Start menu under Programs. The SCPO SRE submenu contains a shortcut to Uninstall SCPO SRE.

• Creates a registry key for JDA SCPOWeb SRE 8.1 under HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows > CurrentVersion > Uninstall.

• Adds or updates Windows system environment variables, based on the values you enter during installation.

• Creates a JDA_SCPO_SRE_8.1_InstallLog.xml file in the <install_dir> directory.

Uninstall the software You can uninstall SCPO software components using the following procedures

Uninstall SCPO You can uninstall SCPO after it has been installed using the uninstall utility provided with the software. You should always use the utility to uninstall SCPO.

1. Stop the JDA Platform Server.

2. On Windows, select Start > Programs > JDA 8.1 > SCPO > Uninstall SCPO.

If you did not install the software to the Windows Start menu, or if you installed on UNIX, open a command-line prompt. Change to directory <install_dir>\UninstallerData\SCPOUninstall. On Windows, run the file Uninstall SCPO.exe by enclosing it in quotation marks:

"Uninstall SCPO.exe"

On UNIX, run Uninstall_SCPO.bin. For example,


Installation

Uninstall_SCPO

On UNIX, this may return hot-key errors similar to the following:



These errors are normal and you can proceed with the uninstallation.

3. Remove directories or files not deleted during the uninstallation.

4. If you do not plan to reinstall the application, you must remove rows from the CSM_APPLICATION table using Oracle. If you do not remove the rows from the CSM_APPLICATION table, then the applications will continue to display to users after they successfully log on. For example, the entries in the CSM_APPLICATION table look like:

Application_Name Display_Name

SCPOWeb.Flowcasting Flowcasting

SCPOWeb.Demand Demand

SCPOWeb.DemandDecomposition

Demand Decomposition

SCPOWeb.DemandRichUI Demand (Thick UI)

SCPOWeb.DRM Demand Revenue Management

SCPOWeb.DU Demand Unconstraining

SCPOWeb.DynamicDemandResponse

Dynamic Demand Response

SCPOWeb.EnterpriseSupplyPlanning

Enterprise Supply Planning

SCPOWeb.Fulfillment Fulfillment

SCPOWeb.Markdown Markdown Optimization

SCPOWeb.MasterPlanning Master Planning

SCPOWeb.MfgSuiteFoundation

Manufacturing Suite Foundation

SCPOWeb.PromotionsManagement

Promotions Management

SCPOWeb SCPO Suite

SCPOWeb.Strategy Production and Sourcing Optimization

SCPOWeb.PrecisionPricing Strategic Pricing

SCPOWeb.NPO Travel Price Optimization

SCPOWeb.Supply Supply

Caution: Removing the entry for WebWORKS (JDA Platform) renders the system inaccessible.

5. If you plan to continue using other JDA applications, regenerate configuration using the utility configureJDAServer. See the section on regenerating configuration and startup files in the JDA Platform Installation/Administration Guide.


Installation

6. Restart the JDA Platform Server.

Uninstall SCPO SRE You can uninstall SCPO SRE using the uninstall utility provided with the software. You should always use the utility to uninstall SCPO SRE.

1. On Windows, select Start > Programs > JDA 8.1 > SCPO SRE > Uninstall SCPO SRE.

2. In the Uninstall JDA SCPO SRE 8.1 dialog box, click Uninstall. When the uninstall process completes, click Done.

If you did not install the software to the Windows Start menu, or if you installed on UNIX, open a command-line prompt. Change to directory <install_dir>\UninstallerData\SCPOSREUninstall. On Windows, run the file Uninstall SCPO SRE.exe by enclosing it in quotation marks:

"Uninstall SCPO SRE.exe"

On UNIX, run Uninstall_SCPO_SRE.bin. For example,

Uninstall_SCPO_SRE.bin

On UNIX, this may return hot-key errors similar to the following:



These errors are normal and you can proceed with the uninstallation.

3. Remove directories or files not deleted during the uninstallation.

Install JDA Production and Sourcing Optimization Client The Production and Sourcing Optimization (PSO) Client enables you to model and optimize your supply chain.

Download and run the Production and Sourcing Optimization Client The downloadable PSO Client is a Java Web Start (JWS) implementation of the application. Click PSO Client in the Directory to download the application files to your computer.

Note: To download and run the PSO Client on WebSphere, see JDA Production and Sourcing Optimization (Java Web Start Client): Set up Websphere server.

To launch the PSO Client using JWS:

1. Log on to the JDA Platform server.

2. On the Home page, click on the Solution Navigation icon.

3. Click on the Navigate Directory icon.

4. Click JDA Production and Sourcing Optimization from the Directory Hierarchy pane.

5. Click PSO Client from the Directory Links pane. The JWS window, and the Security Warning dialog box are displayed. Note: If you do not have JRE installed on your computer, the message You do not have the supported version of JRE installed on your computer. Install and refresh your browser. is displayed along with the Click here to install JRE link for installation. For information on the supported version of JRE, see the Production and Sourcing Optimization Release Notes.

6. Select Always trust content from this publisher.

7. Click Run. The JDA Production and Sourcing Optimization Desktop is displayed.


Installation

Note: While loading bigger models, if you experience an "Out of memory" error when running the Production and Sourcing Optimization Client, it requires more memory to be allocated. For WebLogic: Modify the settings in the strategyclientdynamic.jnlp file located in the <install_dir>\config\ear\scpoweb\scpoweb\Strategy\jws\dynamic server directory. Change the value for -Xms256M and -Xmx1024M in the following line to a higher number, such as 1536m: <java version="1.6+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-Dweblogic.MaxMessageSize=2000000000 -Dsun.java2d.noddraw=true -Xms256M -Xmx1024M -Djaxp.debug=1 -Djava.security.debug=all"/>. For WebSphere: Modify the settings in the strategyclientdynamicwas.jnlp file located in the $WAS_HOME/profiles/<profile name>/installedApps/<cell name>/<APP_CONFIG_NAME>.ear/scpoweb/scpoweb.war/strategy/jws/config/dynamic server directory. Change the value for -Xms256M and -Xmx1024M in the following line to a higher number, such as 1536m: <java version="1.6+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-Xms256M –Xmx1024M -Djava.security.debug=all"/>.

Upgrade Production and Sourcing Optimization Client software When you upgrade from version 6.x to version 8.1, remove the Production and Sourcing Optimization Client from Java Application Cache Viewer and download from 8.1. For details, see Download and run Production and Sourcing Optimization Client.

Uninstall Production and Sourcing Optimization Client To uninstall the Production and Sourcing Optimization Client, remove it from the Java Web Start cache.

1. Select Start>Run. The Run dialog box is displayed.

2. Run the Java Application Cache Viewer by entering javaws in the Run dialog box.

3. Select Production and Sourcing Optimization Client.

4. Click Remove Selected Application.

Install Demand Field Sales mobile application (Updated in the 8.1.0.1 patch) Demand Field Sales is a mobile application that allows a sales persona to review and edit DFU Measure data. To view the relevant data the users must be configured using the Configure Demand Field Sales page in the JDA Demand application.

To install the application on the mobile:

1. Connect the ipad to JDA network.

2. Open Safari on ipad and enter the following URL:

http://macmini.vortexconnect.com/mobileframework/. The list of applications is displayed in this page.

3. Click Install Application for Field Sales. A dialog-box is displayed to confirm the installation.

4. Click Install to install the application or click Cancel. The application is installed on the ipad.

5. Tap the Field Sales icon on the ipad. A Customer ID Setup screen is displayed. Enter the pre-configured Customer ID.

For more information on configuring the Customer ID, contact JDA Consulting Services.

6. Tap Submit to save the settings.

7. You can now login with a valid Username and Password.

Note: The mobile device must have iOS 7 operating system.


Post-installation tasks

Chapter 5. Post-installation tasks Post-installation checklist During post installation, use the following table to note the various tasks that you must perform.

Tasks Value

Configure the Platform server

Create or migrate the database

Configure SRE

Manage solution navigation

Create the SCPO database schema objects This chapter describes how to create the SCPO database schema. You must install SCPO before following the instructions in this chapter. You must also have the supported version of Oracle with all patches, installed on the server hosting the database.

If you are migrating to SCPO version 8.1, see Upgrade to SCPO 8. (on page 30)1 for procedures on migrating your existing database.

Caution: If integrating JDA Demand with JDA Market Manager, do not place the SCPO database and Collaborative Services databases in the same Oracle schema. You may experience schema conflicts. However, the schemas must reside in the same database instance.

Note: Placeholder records are used in the SCPO database to maintain Foreign Key constraints. The records are primary key rows for tables that are referred to by other tables for which a value is not required. Some placeholder records contain the text "Blank <table_name> (system row - do not delete)" in the Description column of the table, where <table_name> is the name of the database table. Some place holder records, for example for UOM table, can also be of the integer datatype. Do not delete these records from the database.

Create the SCPO schema-UNIX or Windows Note: You can configure the SCPO schema on an Oracle database that is already created. However, the database encoding must be UTF8 with character set AL32UTF8 using CHAR semantics.

Before you create the SCPO schema, perform the following tasks:

• Ensure that your system is set up using the instructions in Set up a UNIX server or Set up a Windows server and that you have created your Oracle database.

• If you created your database using the scripts provided by JDA Platform, proceed to Create the SCPO tablespaces and user-UNIX or Windows (on page 11).

• If you did not use the JDA provided scripts to create your Oracle database, verify that the database character set for your database is AL32UTF8. See Verify the database character set. In addition, run a command against the database in which you will create your SCPO tablespaces using the instructions in Prepare an existing database for a SCPO tablespace (on page 11). Next, create the SCPO tablespaces and user (see Create the SCPO tablespaces and user-UNIX or Windows (on page 11)).



• SCPO date columns must include an hour and minute timestamp. The Oracle default date format does not include an hour and minute timestamp, so you must add the NLS_DATE_FORMAT setting to your environment before you create, migrate, or access a SCPO database. The value must be RRRR-MM-DD-HH24:MI.

• If you are using the database creation script provided by JDA, ensure to set the NLS_DATE_LANGUAGE environment variable to AMERICAN:

• UNIX:export NLS_DATE_LANGUAGE = AMERICAN

• Windows:set NLS_DATE_LANGUAGE = AMERICAN

Create the 8.1 schema Two methods exist for creating the 8.1 schema:

• Create an empty database (no data) using a SQL script .See Create an empty database (on page 26). The empty database does not include the JDA Platform schemas (Foundation and ABPP), which means you must have created those schemas previously. See the JDA Platform Installation/Administration Guide. You can import data into the empty database using the Interface Generation Program (IGP). See Import data (on page 117).

• Import a sample database (sample data). See Import a sample database (on page 27). The sample database includes the Foundation 8.1 schema, and enables you to start the JDA Platform Server immediately. The sample database has sample data that may be useful for testing or training, including predefined SCPO resources, roles, and a SCPO administrative user, called ADMINID.

Create an empty database Use the following procedures to create a new SCPO database and load application data into the Foundation schema. The Foundation schema must already exist. The procedures also activate the SCPO components for which you are licensed. After you finish these instructions, proceed to Import data (on page 117) to load your data to the SCPO database using a batch process.

Before creating the database verify that a new JDA Foundation schema is created using the instructions in the JDA Platform Installation/Administration Guide. To create the SCPO schema:

1. From the <install_dir>\config\bin\scpoweb directory, run:

runPostInstallTask

2. Press Enter to continue

3. Enter the Oracle System password

4. Enter the Foundation schema password

5. Enter the SCPO schema password

6. Enter one or more of the following options, separated by a comma:

drop_users

create_users

create_scpo_database

If the SCPO user already exists in the database, and you want to drop and re-create the user, enter

drop_users,create_users,create_scpo_database

If you already have a database user created, you can enter only create_scpo_database to create the SCPO database objects.

The script writes log files to the <install_dir>\config\database\scpoweb directory.



After the data tablespace is prepared, alternatively you can run the following scripts to create the 8.1 full schema which creates an empty database into which you can import or enter your own data.

Note: Set the ORACLE_SID environment variable prior to running the create_newdb_scpo script.

Step Script

Run as Schema Owner

Description

1 create_newdb_scpo

SCPO

From the <install_dir>\config\database\scpoweb directory, run this script as follows:

UNIX: create_newdb_scpo.ksh <scpouser> <scpopassword> <wwfuser> <wwfpassword> <system_user> <system_password> <oracle_sid>

Windows: create_newdb_scpo.bat <scpouser> <scpopassword> <wwfuser> <wwfpassword> <system_user> <system_password> <oracle_sid>

Replace <scpouser> and <scpopassword> with the SCPO schema owner and password, <wwfuser> and <wwfpassword> with Foundation schema owner and password, <system_user> and <system_password> with System owner and password. This script creates the scpo_db_creation.log file. Check this log file for any errors.

Note: This script may take longer to run than you expect, and you will receive no messages during processing. When the system prompt returns, processing has completed.

2 load_translated_metadata From the <install_dir>\config\database\scpoweb directory, run this script as follows :

UNIX: load_translated_metadata.ksh <wwfuser> <wwfpassword> <tns_name>

Windows:

load_translated_metadata.bat <wwfuser> <wwfpassword> <tns_name>

This script loads internationalized metadata into the Foundation schema for the SCPO tables.

Configure the Server. See the JDA Platform Installation/Administration Guide for details.

Note: Adjust the number of nodes in SRE_NODE_POOL.NUMBER_OF_NODES in the JDA Foundation schema as required before starting the node pool. You must have at least as many nodes as there are continuous jobs in the sre_job table (sre_job:is_continuous_enabled=1), if that job is assigned to the node pool.

Import a sample database The sample database contains database objects owned by three different Oracle users: scpomgr (SCPO schema), wwfmgr (Foundation schema), and abppmgr (ABPP schema). Therefore, when importing the sample database, you must import the schemas owned by each of these schema owners.

The sample database is designed to quickly provide a functioning server. The recommended tablespace size for the sample database is 3 GB.

The following procedure assumes that you have already created the Oracle users that will serve as the schema owners.



1. Open a command line prompt and navigate to directory <install_dir>/config/database/scpoweb/sample (UNIX) or <install_dir>\config\database\scpoweb\sample (Windows).

2. Import the JDA schemas into the database by following the below instructions:

You must use Oracle data pump to import the sample database dump. Data Pump is server-based, and not client-based. Dump files, log files, and SQL files are accessed relative to the server-based directory paths, so that, appropriate file security can be enforced. Data Pump requires you to specify directory paths as directory objects. A directory object maps a name to a directory name on the file system.

Before running a Data Pump Import, a directory object must be created by a DBA or by any user with CREATE ANY DIRECTORY privilege. While importing the dump using 'impdp' utility, specify the directory object with the DIRECTORY parameter.

For Example:

CREATE DIRECTORY dumpdir AS '/datafiles/dumps';

For example, if importing the dump to the Foundation user called wwfmgr, an ABPP user called abppmgr, and the SCPO user called scpomgr, then the import is similar to the following:

impdp system/manager dumpfile=sample80.dp.dmp schemas=wwfmgr,scpomgr,abppmgr directory=dumpdir logfile=sample80_imp.log

If importing the dump to a different Foundation user called wwfmgr1, ABPP user called abppmgr1, and the SCPO user called scpomgr1, then the import is similar to the following:

impdp system/manager schemas=wwfmgr,scpomgr,abppmgr remap_schema=wwfmgr:wwfmgr1,scpomgr:scpomgr1,abppmgr:abppmgr1 directory=datadir1 dumpfile=sample80.dp.dmp logfile=sample80.dp.log

3. Open a command line prompt and navigate to directory <install_dir>/config/database/platform (UNIX) or <install_dir>\config\database\platform (Windows).

4. If you specified a user other than scpomgr for <scpouser> in step 5, run the script change_schema_name.sql as the Oracle system user, using SQL*Plus and the following syntax:

sqlplus system/manager @change_schema_name.sql <old_schema_name> <new_schema_name> <wwfuser>

Replace <old_schema_name> with the user scpomgr, <new_schema_name> with the Oracle user ID that you want to own the SCPO schema, and <wwfuser> with the name of the Foundation schema owner. For example:

sqlplus system/manager @change_schema_name.sql scpomgr <new_schema_name> wwfmgr

This script changes the SCPO schema owner in the database.

Note: When you installed SCPO, the software replaced a variable in several SCPO files with the Oracle user ID and password you specified during installation. If your schema owner is different from the user you entered during installation, these files must be updated to reflect the correct SCPO schema owner before you start the JDA Platform Server. To update the files, uninstall and reinstall the SCPO software using the new SCPO schema owner after database creation.

5. Using SQL*Plus, run enroll_app_schema.sql as the Oracle system user and pass the SCPO schema owner as the parameter using the following syntax:

sqlplus system/manager @enroll_app_schema.sql <scpouser>

Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and the Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and the Foundation metadata layer. The script also creates a log file enroll_app_schema.log.



6. If you specified a user other than wwfmgr for <wwfuser> in Step 5, do the following:

a. Run change_schema_name.sql as the Oracle system user again, this time to change the Foundation schema owner in the database. For example, if you want to change the Foundation schema owner from the default user, wwfmgr, to wwfmgr2, run the script change_schema_name.sql, as follows:


Replace <old_schema_name> with the old Foundation schema owner and replace both <new_schema_name> and <wwfuser> with the new Foundation schema owner. For example:

sqlplus system/manager @change_schema_name.sql wwfmgr wwfmgr2 wwfmgr2

Note: When you installed JDA Platform, the software replaced a variable in several Platform files with the Oracle user ID and password you specified during installation. If your schema owner is different from the user you entered during installation, you must uninstall and reinstall the Platform software using the new Foundation schema owner.

b. Run update_app_synonyms.sql in <install_dir>config/database/platform (UNIX) or <install_dir>config\database\platform (Windows) as the Oracle system user to update the application synonyms with the changed JDA Foundation schema name using the following syntax:

sqlplus system/manager @update_app_synonyms.sql <old_schema_name> <new_schema_name> <scpouser>

Replace <old_schema_name> with the old Foundation schema owner, replace <new_schema_name> with the new Foundation schema owner and <scpouser> with the SCPO schema owner. For example:

sqlplus system/manager @update_app_synonyms.sql csmmgr wwfmgr scpomgr

c. Using a text editor, search for all occurrences of user wwfmgr in igp_view_definitions.sql located in <install_dir>/config/database/scpoweb (UNIX) or <install_dir>\config\database\scpoweb (Windows) and replace them with your JDA Foundation schema owner for example, wwfmgr2. Next run the script as follows:

sqlplus <scpouser>/<scpopassword> @igp_view_definitions.sql

Replace <scpouser> and <scpopassword> with the SCPO schema owner and password; for example, scpomgr. This script updates the JDA Foundation schema owner in four Oracle views, IGPXML_*, which reside in the SCPO schema. The Interface Generation Program (IGP) component of JDA Platform uses these views for importing data into the SCPO database.

7. Run the following scripts when importing the migrated 8.1 database or the sample 8.1 database:

a. Run fix_sequence_nextval.sql using the following syntax.

sqlplus <scpouser> <scpopassword> @fix_sequence_nextval.sql

Replace <scpouser> and <scpopassword> with the SCPO schema owner and password.

b. Run fix_sequence_nextval_csm.sql using the following syntax.

sqlplus <wwfuser> <wwfpassword> @fix_sequence_nextval_csm.sql

Replace <wwfuser> and <wwfpassword> with the Foundation schema owner and password.

Running these scripts ensures that the SEQUENCE's next value is greater than the largest value in the column that uses the SEQUENCE.

8. Create stored procedures for JDA applications as follows:

a. From a command line prompt, navigate to directory <install_dir>/config/database/scpoweb (UNIX) or <install_dir>\config\database\scpoweb (Windows).



b. Run db_storedobjects.ksh (UNIX) or db_storedobjects.bat (Windows) using the following syntax:

UNIX:

db_storedobjects.ksh <scpouser> <scpopassword>

Windows:

db_storedobjects.bat <scpouser> <scpopassword>

Replace <scpouser> and <scpopassword> with the user name and password for the SCPO schema owner. This shell script creates all JDA application stored procedures and functions on your database.

c. Check the log file, db_storedobjects.log, for any errors.

Note: Every time you run db_storedobjects, it adds an entry for that build in SCPOMGR.SYS_LASTFIX.

9. Run set_config_code.sh (UNIX) or set_config_code.bat (Windows) as the Foundation schema owner and the SCPO schema owner using the following syntax:

UNIX:

set_config_code.sh <wwfuser> <wwfpassword> <scpouser> <scpopassword>

Windows:

set_config_code.bat <wwfuser> <wwfpassword> <scpouser> <scpopassword>

This script activates the SCPO components based on the license file used during installation.

10. Change the creation date for the ADMINID account, if necessary. This may be necessary because the JDA Security module checks the first_login_time_window in the webworks_config.xml file. Change the creation date to the current date on the server.

a. Using SQL*Plus, connect to the Foundation schema using the following syntax:

sqlplus <wwfuser>/<wwfpassword>

b. Update the ADMINID creation date by executing the following statement:

update csm_account_status

set creation_date=SYSDATE

where user_name='ADMINID';

c. Commit the changes.

11. Configure the JDA server using the instructions in the JDA Platform Installation/Administration Guide.

12. Start the CIS Agent and SSO Server using the instructions in the JDA Platform Installation/Administration Guide.


Note: Adjust the number of nodes in SRE_NODE_POOL.NUMBER_OF_NODES in the JDA Foundation schema as required before starting the node pool. You must have at least as many nodes as there are continuous jobs in the sre_job table (sre_job:is_continuous_enabled=1), if that job is assigned to the node pool.

Upgrade to SCPO 8.1 This chapter provides detailed instructions on how to upgrade to SCPO 8.1 and migrate an existing database.

The instructions in this chapter assume that you have a working knowledge of:



• Your particular operating system, including setting environment variables.

• The Oracle database management system, including creating databases, tablespaces, and administering Oracle database users. Use SQL*Plus for executing JDA provided SQL scripts.

Overview of the upgrade process To upgrade from a previous version of Supply Chain Planning and Optimization, use the following procedure.

Note: To upgrade from Demand Planning Extended Edition (DPEE) version 6.1.X, see Migrate from DPEE to SCPO 8.1-UNIX or Windows (on page 79). To upgrade from JDA Strategy 6.2, see Migrate from JDA Strategy 6.2 to SCPO 8.1-UNIX or Windows (on page 86).

1. Back up your existing database. See the Oracle documentation.

2. Install JDA Platform version 8.1 on the server and set up the JDA Platform database. See the JDA Platform Installation/Administration Guide.

3. Install SCPO version 8.1 into the JDA Platform installation.

4. Perform post-installation configuration tasks. See Post-installation configuration.

5. Migrate the JDA Platform schemas to version 8.1. See JDA Platform Installation/Administration Guide.

6. Migrate your SCPO database to version 8.1. Follow the appropriate procedures in this chapter based on the current level of your database.

Install the JDA Platform and SCPO service runtime environment (SRE) components on a standalone JDA Platform SRE machine, as needed. See JDA Platform Installation/Administration Guide and Install SCPO SRE. (on page 18)

7. Configure the JDA server (configureJDAServer). See JDA Platform Installation/Administration Guide.

8. Start the JDA Platform Server. See JDA Platform Installation/Administration Guide.

9. Configure the JDA Platform service runtime environment for SCPO processes. See Configure the environment (on page 98).

10. Configure the SCPO application. See Configure the SCPO application.

11. Customize the SCPO database. See Customize and maintain the database.

12. Define security objects for SCPO. See Implement security.

13. Prepare the SCPO database for importing data, then load data into the database. See Import data (on page 117).

Migration guidelines The SCPO migration process generates a number of log files. Some shell scripts generate aggregate log files, which contain the results of each SQL script run by the shell script. Aggregate log files have a file extension of .out. Review each log file or aggregate log file for errors before proceeding to the next step in the process. In general, you can ignore Oracle errors regarding dropped objects such as database tables and columns. The migration scripts issue a drop statement before creating each object. Do not delete the log files.

Note: If you are using the database creation script provided by JDA, set the NLS_DATE_LANGUAGE environment variable to AMERICAN using the following commands:

• UNIX: export NLS_DATE_LANGUAGE = AMERICAN

• Windows: set NLS_DATE_LANGUAGE = AMERICAN

If you need to migrate a remote database, use @TNS_NAME with the password. For example, dm_migrate741.ksh scpomgr scpomgr@TNS_NAME wwfmgr wwfmgr@TNS_NAME. JDA Supply Chain Planning and Optimization Installation/Administration Guide 31 © 1997-2014 JDA Software Group, Inc.- Confidential


Migrate and import a previous 7.x dump If you are migrating and importing a previous 7.x dump, perform the following steps before migrating:

1. If you specified a user other than scpomgr while importing the schema, run the script change_schema_name.sql as the Oracle system user in SQL*Plus, using the following syntax:


Replace <old_schema_name> with the user scpomgr, <new_schema_name> with the Oracle user ID that you want to own the SCPO schema, and <wwfuser> with the name of the JDA Foundation schema owner. For example:

sqlplus system/manager @change_schema_name.sql scpomgr <new_schema_name> wwfmgr

This script changes the SCPO schema owner in the metadata in the database.

Note: When you installed SCPO, the software replaced a variable in several SCPO files with the Oracle user ID and password you specified during installation. If your schema owner is different from the user you entered during installation, you must uninstall and reinstall the SCPO software using the correct SCPO schema owner.

1. Change to directory <install_dir>\config\database\platform.

2. Using SQL*Plus, run enroll_app_schema.sql as the Oracle system user and pass the SCPO schema owner as the parameter, using the following syntax:


Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and the JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and the JDA Foundation metadata layer. The script also creates a log file, enroll_app_schema.log.

Note: Occasionally during migration, the enroll_app_schema.sql script will display error messages regarding invalid views or procedures. If this happens before the last time you run the script, you can ignore the errors. However, if the last run of the script displays an error, recompile the views or procedures using Oracle. See the Oracle documentation for instructions.

3. If you specified a user other than wwfmgr for <wwfuser> while importing the Foundation schema, do the following:

a. Run change_schema_name.sql as the Oracle system user again. Change the JDA Foundation schema owner in the database. For example, if you want to change the JDA Foundation schema owner from the default user, wwfmgr, to wwfmgr2, run the script change_schema_name.sql, as follows:


Replace <old_schema_name> with the old JDA Foundation schema owner and replace both <new_schema_name> and <wwfuser> with the new JDA Foundation schema owner. For example:

sqlplus system/manager @change_schema_name.sql wwfmgr wwfmgr2 wwfmgr

Note: When you installed JDA Platform, the software replaced a variable in several Platform files with the Oracle user ID and password you specified during installation. If your schema owner is different from the user you entered during installation, you must uninstall and reinstall the Platform software using the correct JDA Foundation schema owner.

b. Run update_app_synonyms.sql in <install_dir>config/database/platform (UNIX) or <install_dir>config\database\platform (Windows) as the Oracle system user to update the application synonyms with the changed JDA Foundation schema name, using the following syntax:




Replace <old_schema_name> with the old Foundation schema owner, <new_schema_name> with the new Foundation schema owner and <scpouser> with the SCPO schema owner. For example:


4. Optionally, grant the necessary privileges to the SCPO schema owner using SQL*PLUS:

a. Log in to SQL*Plus as the Oracle system user.

b. Enter the following commands:

GRANT CONNECT, RESOURCE, CREATE TABLE, CREATE SYNONYM, CREATE SEQUENCE, CREATE VIEW TO <scpouser>;

GRANT UNLIMITED TABLESPACE TO <scpouser>;

where <scpouser> is the user you specified when you imported the database.

Migrate the JDA Platform using the instructions in the JDA Platform Installation/Administration Guide, then migrate the SCPO schema using the instructions in the following sections.

1. Configure the JDA server using the instructions in the JDA Platform Installation/Administration Guide.


To improve the performance of the migration process, it is important to estimate database statistics several times throughout the migration process as new objects are being created and selected. Oracle provides a utility to perform this task.

Guidelines for the SCPO database Note the following important guideline regarding the SCPO database:

• Beginning with 7.2.0.1, the SCPO database migration process no longer requires that the SCPO schema owner be user stsc with DBA privilege. Following database migration to version 7.2, you can revoke DBA privilege from the stsc user or run an optional JDA script to change the SCPO schema owner to a different Oracle user.

• For more guidelines, see Create the SCPO database schema (on page 25).

Migrate the SCPO schema from 6.x, or 7.1.x to 7.2 - UNIX This section describes the basic steps for migrating the SCPO database schema from earlier versions to SCPO version 7.2. Use the procedures in this section if you are upgrading your software and you want to migrate your current database. If you have a 7.2.0.1 or a later SCPO database schema, see Migrate the SCPO schema from 7.2.x, 7.3.x, or 7.4.x to 8.1 - UNIX or Windows (on page 54).

Before you begin the migration process, review the steps in Overview of the upgrade process (on page 31). Next, proceed to the appropriate section of this chapter, depending on your current database level.

Migrate a version 6.1.x database to 6.2 - UNIX To migrate a version 6.1.x database to 6.2 (full schema), you must generate the full database schema, then run a single shell script. You will need to modify the SID initialization file and to stop and restart the Oracle database for the migration.

Before you proceed, your database must be at level 78, 785, or 786. The following steps will migrate your database to level 81. The database must be at level 81 to migrate to further versions.

1. Back up your current database before starting the migration.



2. Open a command-line prompt.

3. Using SQL*Plus to verify the database level by querying the dbconfig table as the SCPO schema owner, stsc. Enter the following:

select * from dbconfig;

The value in the LEVELNUM column should be 78, 785, or 786.

4. Set the ORACLE_SID to the database you want to migrate, using the following command.

export ORACLE_SID=<SID>

5. Change to directory <install_dir>/config/database/scpoweb/migrate.

6. Using SQL*Plus, run manufs_grants.sql as the Oracle system user. For example:

sqlplus system/manager @manufs_grants.sql

7. Close all open database connections and run the full schema utility manufs.ksh by entering the following:

manufs.ksh stsc <password>

Replace <password> with the password for the stsc user. This file calls and runs two SQL scripts.

8. Review manufs.log for errors. The log file should state that the full database schema completed successfully. This utility raises the database to level 79. Query the dbconfig table using SQL*Plus to verify that the database is at the correct level.

If the following errors are displayed in manufs.log:

UDT names conflicts with application system table names.

UDC names conflicts with application system column names.

then a user-defined table (UDT) or user-defined column (UDC) has the same name as a table or column in the full schema. To resolve this issue, you must rename or delete the user-defined table or user-defined column. Contact JDA Support Services for assistance. Afterwards, run the manufs utility again.

If errors other than UDC and UDT are displayed, you should restore your backed-up database and repeat the steps in this section. Contact your JDA Implementation Services or JDA Support Services representative for assistance.

9. Change to directory <install_dir>/config/database/scpoweb/migrate, which contains the migration scripts. This directory contains a script file and several SQL scripts.

10. Run the shell script dm_migrate62.ksh using the following syntax:

dm_migrate62.ksh stsc <password>

Replace <password> with the password for the stsc user. This file calls and runs several SQL scripts and creates a log file for each. The file also creates an aggregate log file, dm_migrate62.out.

11. Using a text editor, open dm_migrate62.out. Search for instances of ORA- to find individual Oracle errors and the table or column that was involved. Ignore the following types of errors:

• Unique Constraint violations

• Column already exists

• Invalid Identifier

• Name already used by another object

12. Verify the database level. Using SQL*Plus, query the dbconfig table as user stsc:


The value in the LEVELNUM column should be 80, which indicates the migration was successful.



Migrate a version 6.2 database to 7.0 - UNIX Follow these instructions if you are upgrading from SCPO Client/Server 6.2 to SCPO Web 7.0. The instructions will migrate your database to level 81.

Before proceeding with this section, the SCPO database must be at full schema, level 81. In addition, the migration process requires that shell scripts be run against the SCPO database and JDA Foundation schemas. Therefore, before migrating your SCPO database to 7.0, you must create the JDA Foundation 8.1.0.0 schema. For procedures on creating the JDA Foundation schema, see the JDA Platform Installation/Administration Guide.

Note: The SCPO and JDA Foundation schemas may be owned by the same database user or by different database users. You must know this information before proceeding.

Note: During each step of the migration, check the log files or aggregate log (dm*.out) files for Oracle errors.

Prepare SCPO Client/Server 6.2 for migration to SCPO Web 7.0 Note: The scripts in this section refer to versions 6.2 and 7.0, but they match the JDA Foundation 8.1.0.0 schema. You must run all of these scripts.

1. Back up your database.

2. Open a command line prompt.

3. If you did not create your database using JDA scripts, set the following parameters in the init<SID>.ora file. Usually, this file is located in directory $ORACLE_BASE/admin/<SID>/pfile.

utl_file_dir=*



4. Set the ORACLE_SID to the database you want to migrate.

export ORACLE_SID=<SID>

5. Verify that the database is at full schema, level 80. Log in to SQL*Plus as user stsc and enter the following command:


The value in the LEVELNUM column must be 80 before proceeding.

6. Change to directory <install_dir>/config/database/scpoweb.

7. Using SQL*Plus, run new_csm_load.sql as the JDA Foundation schema owner. For example, if wwfmgr owns the JDA Foundation schema and the password is wwfmgr, then enter the following:

sqlplus wwfmgr/wwfmgr @new_csm_load.sql

This script inserts SCPO application data into the CSM and metadata tables in the JDA Foundation schema. It also generates a log file, new_csm_load.log.


9. Run dm_scpoweb_6201.ksh against the SCPO database, using the following syntax:

dm_scpoweb_6201.ksh stsc <password>

Replace <password> with the password for the stsc user. The file creates an aggregate log file, dm_scpoweb_6201.out.



Add referential integrity to the SCPO database The process of adding referential integrity creates foreign key constraints to ensure data integrity for the database. This process may identify errors in log files; for example, the inability to successfully enable a foreign key constraint because of orphaned child records. Review these errors carefully. You must resolve these errors before completing referential integrity. JDA provides scripts and sample SQL queries to help identify the errors.

Caution: Scenarios created in previous releases will be deleted during this process. You may want to review any scenarios in the database before proceeding.


2. Using SQL*Plus, run gather_db_stats.sql as the Oracle system user for SCPO schema using the following syntax:

sqlplus system/manager @gather_db_stats.sql

Enter the schema_name when prompted. For example: <scpouser> when running on the SCPO schema.

3. Back up your current database.



6. Run the shell script dm_addreferentialintegrity.ksh using the following syntax:

dm_addreferentialintegrity.ksh stsc <password>

Replace <password> with the password for the stsc user. This file calls several SQL scripts and runs them sequentially.

Note: After running dm_addreferentialintegrity.ksh for the first time, you should address failures of primary key constraints before you run dm_deletebadrows.sql, which cleans up any inconsistent data:

a. Identify any tables where duplicate rows were found.

b. Query the tables to identify duplicate keys.

c. After examining duplications, delete the duplicate data

d. Re-run dm_addpkconstraints.sql to create the primary key constraints that failed.

e. Continue resolving failures with foreign key constraint enablement in dm_refint9_enablefkconstraints.log (Step 7).

7. Check dm_addreferentialintegrity.out for errors.

8. Open dm_refint9_enablefkconstraints.log. This log contains foreign key constraint validation errors. For example:

SQL> ALTER TABLE DFUTOSKU ENABLE CONSTRAINT DFUTOSKU_SKU_FK1 exceptions INTO SCPOConstraintCreationErrors;

ALTER TABLE DFUTOSKU ENABLE CONSTRAINT DFUTOSKU_SKU_FK1 exceptions INTO SCPOConstraintCreationErrors

*

ERROR at line 1:

ORA-02298: cannot validate (STSC.DFUTOSKU_SKU_FK1) - parent keys not found

This error indicates that the DFUTOSKU table has orphaned child records. An ITEM,LOC key in the SKU table was not found matching an ITEM,SKULOC key in the DFUTOSKU table.

9. If errors are present in dm_refint9_enablefkconstraints.log, open SQL*Plus and enter the following query to identify the total number of rows in error:



select count(*) from SCPOConstraintCreationErrors;

The result is the total number of orphaned child records identified during the referential integrity process. These child records are attempting to refer to a row in a primary table, but the row does not exist.

10. Using SQL*Plus, run dm_showbadrows.sql. This script writes the data in error to dm_showbadrows.log. Open this log file and review it. You have two options for resolving these data conditions:

• Add a row to the primary table for each child record identified. To help you with this process, the dm_badrows.sql file was created automatically. It contains individual select statements for each table containing errors during the referential integrity process. After adding the rows, proceed to the next step.

• Delete the data. You can delete data from all tables or delete data from one table at a time.

• To delete all orphan records in all tables, use SQL*Plus to run the script dm_deletebadrows.sql. This script does not remove rows from the DBPARAM table (data in the DMDCAL and SUMMARYDMDGROUP columns may have caused problems). The row in DBPARAM cannot be deleted. If necessary, replace fields in DBPARAM.DMDCAL and DBPARAM.SUMMARYDMDGROUP with a blank space. Proceed to Step 10.

• To delete all orphan records in each table individually, open dm_deletepertable.sql. Replace all instances of CHANGETHIS to the name of the table containing orphan records. Save and run the script. Repeat the process for each table containing data in error, then proceed to step 10.

11. Using SQL*Plus, run dm_enablefkconstraints.sql. If all data conditions have been resolved successfully, then the dm_refint9_enablefkconstraints.log will not contain errors and the SCPOConstraintCreationErrors table will be empty. You can drop the table SCPOConstraintCreationErrors from the schema.

Migrate the SCPO database to 7.0 After adding referential integrity, migrate the SCPO database to level 81.






Replace <password> with the password for the stsc user. This file calls and runs several SQL scripts. It also generates an aggregate log file dm_migrate70.out. Check the log for errors.

Note: In JDA Demand, the migration changes the history. Type 1 history is total history, Type 2 history represents historic overrides, and Base history is derived by subtracting Type 2 history from Type 1 history. Type 3 history has been added to store data-driven events for Lewandowski models only.



The value in the LEVELNUM column should be 81.

Migrate a version 7.0 database to 7.1 - UNIX Caution: If you are currently running JDA Demand or JDA Fulfillment version 7.0 and you are beginning the migration process at version 7.0, do not perform the migration procedures described in this guide. Instead, contact JDA Support Services for migration instructions. If you are continuing the migration process from an earlier version, proceed with this section.



To migrate a version 7.0 database to 7.1 (full schema), level 82, you must have the supported version of Oracle installed, and the SCPO database must be at full schema, level 81. Also, the 8.1.0.0 Foundation schema must exist.

The migration process requires that shell scripts be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.



3. Verify the following:

• SCPO database is at level 81. Query the dbconfig table using SQL*Plus as the SCPO schema owner, stsc:



• Foundation schema is at 8.1.0.0. Use SQL*Plus as the JDA Foundation schema owner. For example:

sqlplus wwfmgr/wwfmgr

select value from csm_schema_log where name = 'DATABASE_VERSION';


5. Do one of the following:

• If you started the SCPO 8.1.0.0 migration process with a version 5.4.x or 6.x database, skip to step 8.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run the script load_csm_71.sql as the JDA Foundation schema owner, using SQL*Plus. For example, if wwfmgr owns the JDA Foundation schema and the password is wwfmgr, then enter:

sqlplus wwfmgr/wwfmgr @load_csm_71.sql

This script inserts SCPO application data into the CSM and metadata tables in the JDA Foundation schema. It also generates a log file, load_csm_71.out.

6. Run the shell script dm_dumpfe71.ksh using the same database user as Step 5. This file calls and runs a SQL script. For example,

dm_dumpfe71.ksh wwfmgr wwfmgr

The file also creates an aggregate log file dm_dumpfe71.out.

7. Run the shell script dm_fe2scpo71.ksh using the following syntax:

dm_fe2scpo71.ksh stsc <password>

Replace <password> with the password for the stsc user. This file calls and runs a SQL script. The file also creates an aggregate log file, dm_fe2scpo71.out.



Replace <password> with the password for the stsc user. This file calls and runs several SQL scripts. The file also creates an aggregate log file, dm_migrate71.out. The following errors may be displayed in the console and the .out file:

UPDATE Fcst SET Type = 99 WHERE

Type in (2, 5) and (FcstId <> 'AUTO ADJUSTMENT' or Type<> 5);




*

ERROR at line 1:

ORA-00001: unique constraint (STSC.FCST_PK) violated

UPDATE FcstDraft SET Type = 99 WHERE



*

ERROR at line 1:

ORA-00001: unique constraint (STSC.FCSTDRAFT_PK) violated

These errors occur when JDA Demand Type 2 and 5 records are migrated to Type 99. Several records can exist for each DFU, so a constraint error occurs where the FCSTID is blank or the same for two or more records. These errors are normal. The migration is necessary for integration with JDA Market Manager.

Note: If you do not plan to integrate with JDA Market Manager, remove the Type 99 records from the SCPO database after you migrate to version 7.1. Otherwise, some JDA Demand processes may complete with errors. See Removing old data from the SCPO database.

9. Using SQL*Plus, run dm_DemandWorkbenchInstances.sql using the following syntax:

sqlplus <wwfuser>/<wwfpassword> @dm_DemandWorkbenchInstances.sql

Replace <wwfuser> and <wwfpassword> with the username and password for the JDA Foundation schema owner.

This script is created by the migration process and may not have any statements to run, depending on whether your WebFTOpts table had data to migrate. Check the log file, dm_DemandWorkbenchInstances.log, for any errors.

10. Run dm_ForecastOverrideInstances.sql using the same syntax and database user as in Step 9.

This script is created by the migration process and may not have any statements to run, depending on whether your WebFOOpts table had data to migrate. Check the log file, dm_ForecastOverrideInstances.log, for any errors.




Migrate a version 7.1 database to 7.1.1 - UNIX To migrate a version 7.1 database to 7.1.1 (full schema) level 83, you must have the supported version of Oracle installed and the SCPO database must be at full schema, level 82. Also, the 8.1.0.0 JDA Foundation schema must exist.


Caution: The Fulfillment table SubstSKUReqmts (Substitute SKU Requirements) was dropped from the SCPO database schema in version 7.1.1. After migration, any data in that table will be lost. If you want to save the data, back up the table before migration.









• JDA Foundation schema is at 8.1.0.0. Use SQL*Plus as the JDA Foundation schema owner. For example:





• If you started the SCPO 8.1.0.0 migration process with a version 5.4.x or 6.x database, skip to Step 6.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_711.sql as the JDA Foundation schema owner using SQL*Plus.




Replace <password> with the password for the stsc user. This file calls and runs several SQL scripts. The file also creates an aggregate log file, dm_migrate711.out.




Migrate a version 7.1.1 database to 7.2 - UNIX To migrate a version 7.1.1 database to 7.2, you must have the supported version of Oracle installed and the SCPO database must be at full schema, level 83. Also, JDA Platform 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.


Before you proceed, perform the following pre-migration steps:

• Check data for constraint violations (on page 40)

• Check your data for invalid user-defined columns (UDCs) (on page 41)

The migration steps described in Migrate to 7.2 (on page 42) will take you to database level 84.

Check data for constraint violations SCPO 7.2 includes new Oracle check constraints on database columns that existed in version 7.1.1. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. For example, if a row contains the value 110 in LOC.LAT and the check constraint defines the valid range to be between -90 and 90, the row would violate the check constraint and would cause the migration process to fail.



Therefore, before you migrate your database to version 7.2, check your data for possible constraint violations by running the script dm_checkconstraints.ksh. This file, which calls several SQL scripts, identifies rows in which the data for a column falls outside the valid range defined for that column. Rows that fail constraint checks are logged in dm_checkconstraints.out. Review the data in this file to identify failed rows. Search for the string "ORA-", which identifies any integrity issues. Next, review dm_showbadrows72.log to determine the keys to the data rows that have inconsistencies. Adjust the column values in your database to fall in the valid range before you begin the migration process.

Note: When validating integrity constraints during Master Planning migration, you must use the dm_showbadrows72.log file to perform a pre-migration check of the foreign key relationship from CustOrder (Cust, HeaderExtRef) to CustOrderHeader (Cust, ExtRef).




4. Run the script dm_checkconstraints.ksh using the following syntax:

dm_checkconstraints.ksh stsc <password>

Replace <password> with the password for the stsc user. This file calls several SQL scripts and runs them sequentially. Failed rows can be viewed in dm_checkconstraints.out.

5. Review the failed rows identified in dm_checkconstraints.out and correct the invalid data in your database.

6. Rerun dm_checkconstraints.ksh to ensure that all errors have been corrected.

Check your data for invalid user-defined columns (UDCs) SCPO provides a script that checks the data in your database for invalid UDCs. This script, check_udc.sql, verifies the validity of UDCs by doing the following:

• Checks all columns in the database to identify UDCs that are not configured as UDCs. The column number for these columns falls in the UDC range but COL.USERCOLSW is not set.

• Checks all UDCs to ensure that the columns exist in the schema.

The script also creates a log file, check_udc.log. Review the log file to determine whether your database contains invalid UDCs. You must correct invalid UDCs before proceeding with migration.



3. Using SQL*Plus, run check_udc.sql using the following syntax:

sqlplus stsc/<password> @check_udc.sql

Replace <password> with the password for the stsc user.

4. Review the log file check_udc.log for errors. The log file contains sections for each check performed by the script. Do the following:

• If the log file identifies columns that are not configured as UDCs, verify that the columns are actually UDCs and determine how they were created. For each column that represents a valid UDC, set COL.USERCOLSW to 1 in the database.

• If the log file identifies UDCs that do not exist in the schema, stop the migration process and contact JDA Support Services for assistance.

The following sample log file results if your database contains no invalid UDCs:

Checking for UDCs that are not configured as UDCs...

no rows selected



Checking for UDCs that are not present in the schema...

no rows selected

Migrate to 7.2 1. Open a command line prompt.








3. Change to directory <install_dir>/config/database/platform.

4. Using SQL*Plus, run enroll_app_schema.sql as the Oracle system user. For example:


Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and JDA Foundation metadata layer. The script also creates a log file enroll_app_schema.log.

Note: While running enroll_app_schema.sql, ignore any error messages that refer to the DEMANDASSOCVIEW, SUPPLYASSOCVIEW, and SUPPLYORDERVIEW views. These views become valid only after the database is completely migrated to 7.2.


6. Using SQL*Plus, run gensys_migration.sql using the following syntax:

sqlplus stsc/<password> @gensys_migration.sql


This file calls and runs SQL scripts.


8. Run verify_ds_tables.sql as the JDA Foundation schema owner to verify if you have any invalid searches in the Foundation schema. For example:

sqlplus wwfmgr/wwfmgr @verify_ds_tables.sql

If the script displays invalid searches, then you must run cleanse_ds_tables.sql to verify and delete the invalid searches. This script can be run with two options.

• L: Use this option to list the invalid searches. For example:

sqlplus wwfmgr/wwfmgr @cleanse_ds_tables.sql L

• D: Use this option to delete the invalid searches. For example:

sqlplus wwfmgr/wwfmgr @cleanse_ds_tables.sql D




10. Run migrate_relatedLinkToDynamicNav.sql using the following syntax:

sqlplus <wwfuser>/<wwfpassword> @migrate_relatedLinkToDynamicNav.sql

Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password.

This script migrates SCPO 7.1.1 related links to Dynamic Navigation in JDA Foundation 7.2.

11. Using SQL*Plus, run scpo_grants.sql as the Oracle system user. For example, enter:

sqlplus system/manager @scpo_grants.sql

This SQL script grants the SCPO schema owner access to JDA Foundation tables needed to create a database. See scpo_grants.log for errors.


dm_migrate72.ksh stsc <scpopassword> <wwfuser> <wwfpassword>

Replace <scpopassword> with the password for the stsc user. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password. This file calls and runs several SQL scripts. The file also creates an aggregate log file, dm_migrate72.log. Review the log file for errors.

13. Run migrate_relatedProcessToDynamicNav.sql as the JDA Foundation schema owner. For example:

sqlplus wwfmgr/wwfmgr @migrate_relatedProcessToDynamicNav.sql

This script migrates SCPO 7.1.1 related processes to Dynamic Navigation in JDA Foundation 7.2.


• If you started the SCPO 8.1.0.0 migration process with a version 5.4.x or 6.x database, skip to step 15.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_72.sql as the JDA Foundation schema owner. For example:


The script creates a log file load_csm_72.log. Review the log file for errors.


16. Run convert_to_char_semantic.sql as the Oracle system user. For example:

sqlplus system/manager @convert_to_char_semantic.sql

The script also creates a log file, convert_to_char_semantic.log. Review the log file for errors. Ignore Tab and Col errors. Objects considered invalid by Oracle cannot be compiled and you will receive an error. Generally, you can ignore these errors or remove the invalid object and re-run the script.

This script converts all VARCHAR2 and CHAR column types to NLS Character Length Semantics. This step is required for UTF8 databases.

17. Using SQL*Plus, run gather_db_stats.sql as the Oracle system user for both JDA Foundation and SCPO schemas using the following syntax:


Enter the schema_name when prompted. For example: <wwfuser> while running on the Foundation schema and <scpouser> when running on the SCPO schema.

18. Optionally, grant the necessary privileges to the stsc user as follows:





grant connect, resource, create table, create synonym, create sequence, create view to stsc;

grant unlimited tablespace to stsc;

Note: The migration process requires these privileges. If you subsequently have to remigrate your database, you must grant these privileges to stsc before proceeding.

19. Log in to SQL*Plus as the JDA Foundation schema owner and query the database to verify the database level for SCPO. For example:


select * from md_config


Migrate the SCPO schema from 6.x, or 7.1.x to 7.2 - Windows This section describes the basic steps for migrating from a previous version Supply Chain Planning and Optimization. Use the procedures in this section if you are upgrading your software and you want to migrate your current database. The section provides details on migrating the SCPO database schema from earlier versions to SCPO version 7.2. If you have a 7.2.0.1 SCPO database schema or a later version, see Migrate the SCPO schema from 7.2.x, 7.3.x, or 7.4.x to 8.1.0.0 - UNIX or Windows (on page 54).

Database migration must be performed in the sequence described in this section. For example, if you have a version 5.4 database, you must first upgrade to version 6.1.x.

Before you begin the migration process, complete Steps 1-11 in "Overview of the upgrade process (on page 31)". Next, proceed to the appropriate section of this chapter, depending on your current database level.

Migrate a version 6.1.x database to 6.2 - Windows To migrate a version 6.1.x database to 6.2 (full schema), you must generate the full database schema, then run a single batch file. You must modify the SID initialization file and stop and restart the Oracle database for the migration.

Before you proceed, your database must be at level 78, 785, or 786. The following steps will migrate your database to level 80. The database must be at level 80 to migrate to further versions.



3. Verify the database level by querying the dbconfig table using SQL*Plus as the SCPO schema owner, stsc:


The value in the LEVELNUM column should be level 78, 785, or 786.


set ORACLE_SID=<SID>

5. Navigate to directory <install_dir>\config\database\scpoweb\migrate.

6. Using SQL*Plus, run manufs_grants.sql as the Oracle system user. For example:

sqlplus system/manager @manufs_grants.sql

7. Close all open database connections and run the full schema utility, manufs.bat, by entering the following:

manufs.bat stsc <password>

Replace <password> with the password for the user stsc. This file calls and runs two SQL scripts. JDA Supply Chain Planning and Optimization Installation/Administration Guide 44 © 1997-2014 JDA Software Group, Inc.- Confidential


8. Review manufs.log for errors. The log file should state that the full database schema was completed successfully. This utility raises the database to level 79.

The following errors may be displayed in manufs.log:

UDT names conflicts with application system table names.

UDC names conflicts with application system column names.

If displayed, a user-defined table (UDT) or user-defined column (UDC) has the same name as a table or column in the full schema. To resolve this, you must either rename or delete the user-defined table or user-defined column, then run manufs again.

If errors other than UDC and UDT are displayed, then you should restore your backed-up database and repeat the steps in this section. Contact your JDA Implementation Services or JDA Support Services representative for assistance.

9. Change to directory <install_dir>\config\database\scpoweb\migrate, which contains a batch file and several migration scripts.

10. Run dm_migrate62.bat using the following syntax:

dm_migrate62.bat stsc <password>

Replace <password> with the password for the user stsc. This batch file calls and runs several SQL scripts and creates a log file for each. The batch file also creates an aggregate log file, dm_migrate62.out.

11. Using Notepad, open dm_migrate62.out. Search for instances of "ORA-" to find individual Oracle errors and the table or column that involved. Ignore the following types of errors:

• Unique Constraint violations

• Column already exists

• Invalid Identifier

• Name already used by another object



The value in the LEVELNUM column should be 80, which indicates the migration was successful.

Migrate a version 6.2 database to 7.0 - Windows Before proceeding with this section, the SCPO database must be at full schema, level 80. In addition, the migration process requires that shell scripts be run against the SCPO database and JDA Foundation schemas. Therefore, before migrating your SCPO database to 7.0, you must create the JDA Platform 8.1.0.0 schema. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding. For procedures on creating the JDA Foundation schema. See the JDA Platform Installation/Administration Guide.

Note: The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.

Note: During each step of the migration, check the log files or aggregate log (dm*.out) files for Oracle errors.

Prepare SCPO Client/Server 6.2 for migration to SCPO Web 7.0 The scripts in this section refer to versions 6.2 and 7.0, but they match the JDA Platform 8.1.0.0 schema. You must run all of these scripts.





3. If you did not create your database using JDA scripts, set the following parameters in the init<SID>.ora file. This file typically is located in directory %ORACLE_BASE%\admin\<SID>\pfile.

utl_file_dir=*




set ORACLE_SID=<SID>

5. Verify that the database is at full schema, level 80. Log in to SQL*Plus as stsc and enter the following command:


The value in the LEVELNUM column must be 80 before proceeding.

6. Change to directory <install_dir>\config\database\scpoweb.

7. Using SQL*Plus, run new_csm_load.sql as the JDA Foundation schema owner. For example, if wwfmgr owns the JDA Foundation schema and the password is wwfmgr, then enter:

sqlplus wwfmgr/wwfmgr @new_csm_load.sql

This script inserts SCPO application data into the CSM and metadata tables in the JDA Foundation schema. It also generates a log file, new_csm_load.log.

8. Change to directory <install_dir>\config\database\scpoweb\migrate.

9. Run dm_scpoweb_6201.bat against the SCPO database using the following syntax:

dm_scpoweb_6201.bat stsc <password>

where stsc owns the SCPO database.

The batch file also creates an aggregate log file, dm_scpoweb_6201.out.

Add referential integrity to the SCPO database The process of adding referential integrity creates foreign key constraints to ensure data integrity for the database. This process may identify errors in log files; for example, the inability to successfully enable a foreign key constraint because of orphaned child records. Review these errors carefully. You must resolve these errors before completing referential integrity. JDA provides scripts and sample SQL queries to help identify the errors.

Caution: Scenarios created in previous releases will be deleted during this process. You may want to review any scenarios in the database before proceeding.


2. Using SQL*Plus, run gather_db_stats.sql as the Oracle system user for SCPO schema using the following syntax:






6. Run the batch file dm_addreferentialintegrity.bat using the following syntax:

dm_addreferentialintegrity.bat stsc <password>



Replace <password> with the password for the stsc user. This batch file calls several SQL scripts and run them sequentially.

Note: After running dm_addreferentialintegrity.ksh for the first time, it is recommended that you address failures of primary key constraints first, especially before choosing to run dm_deletebadrows.sql, which cleans up all the inconsistent data, (1) identify any tables where duplicate rows were found, (2) query these tables to identify duplicate keys, (3) after examining duplications, delete the duplicate data, and (4) re-run dm_addpkconstraints.sql, in order to create the primary key constraints that failed. Then, continue resolving failures with foreign key constraint enablement in dm_refint9_enablefkconstraints.log (Step 6).

The process generates a log file for each SQL script run as well as an aggregate log file dm_addreferentialintegrity.out. Check the log for errors.

7. Open the dm_refint9_enablefkconstraints.log. This log contains foreign key constraint validation errors. For example,

SQL> ALTER TABLE DFUTOSKU ENABLE CONSTRAINT DFUTOSKU_SKU_FK1 exceptions INTO SCPOConstraintCreationErrors;

ALTER TABLE DFUTOSKU ENABLE CONSTRAINT DFUTOSKU_SKU_FK1 exceptions INTO SCPOConstraintCreationErrors

*

ERROR at line 1:

ORA-02298: cannot validate (STSC.DFUTOSKU_SKU_FK1) - parent keys not found

This error indicates that the DFUTOSKU table has orphaned child records. An ITEM,LOC key in the SKU table was not found matching an ITEM,SKULOC key in the DFUTOSKU table.

8. If errors are present in the dm_refint9_enablefkconstraints.log, open SQL*Plus and enter the following query to get the total number of rows in error:

select count(*) from SCPOConstraintCreationErrors;

The result is the total number of orphaned child records identified during the referential integrity process. These child records are attempting to refer to a row in a primary table, but the row does not exist.

9. Using SQL*Plus, run dm_showbadrows.sql. This script writes the data in error to dm_showbadrows.log. Open this log file and review it. You have two options for resolving these data conditions:

• Add a row to the primary table for each child record identified. To help you with this process, the dm_badrows.sql file was created automatically. It contains individual select statements for each table containing errors during the referential integrity process. After adding the rows, proceed to step 9.

• Delete the data. Perform this step only to delete data. You can delete data from all tables or delete data from one table at a time.

• To delete all the orphan records in all tables, use SQL*Plus to run the script dm_deletebadrows.sql. This script does not remove rows from the DBPARAM table (data in the DMDCAL and SUMMARYDMDGROUP columns may have caused problems). The row in DBPARAM cannot be deleted. If necessary, replace fields in DBPARAM.DMDCAL and DBPARAM.SUMMARYDMDGROUP with a blank space. Proceed to step 9.

• To delete all the orphan records on a per table basis, open the script dm_deletepertable.sql. Replace all instances of CHANGETHIS to the name of the table containing orphan records. Save and run the script. Repeat for each table containing data in error. Proceed to step 9.



10. Using SQL*Plus, run dm_enablefkconstraints.sql. If all data conditions have been resolved successfully, then the dm_refint9_enablefkconstraints.log will not contain errors and the SCPOConstraintCreationErrors table will be empty. You can drop the table SCPOConstraintCreationErrors from the schema.

11. Proceed to Migrate the SCPO database to 7.0 (on page 48).

Migrate the SCPO database to 7.0 After adding referential integrity, migrate the SCPO database to level 81 using these instructions.




4. Run the batch script dm_migrate70.bat using the following syntax:


Replace <password> with the password for the stsc user. This batch file calls and runs several SQL scripts. It also generates an aggregate log file, dm_migrate70.out. Check the log for errors.

Note: In JDA Demand, the migration changes the history. Type 1 history is total history, Type 2 history represents historic overrides, and Base history is derived by subtracting Type 2 history from Type 1 history. Type 3 history has been added to store data-driven events for Lewandowski models only.




Migrate a version 7.0 database to 7.1 - Windows Note: If you are currently running JDA Demand or JDA Fulfillment version 7.0 and you are beginning the migration process at version 7.0, do not perform the migration procedures described in this guide. Instead, contact JDA Customer Support for migration instructions. If you are continuing the migration process from an earlier version, proceed with this section.

To migrate a version 7.0 database to 7.1 (full schema) level 82, you must have the supported version of Oracle installed, and the SCPO database must be at full schema, level 81. Also, the 8.1.0.0 JDA Foundation schema must exist.

The migration process requires that batch scripts be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.




• SCPO database is at level 81.Query the dbconfig table using SQL*Plus as the SCPO schema owner, stsc:










• If you started the SCPO 8.1.0.0 migration process with a version 6.x database, skip to step 8.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run the script load_csm_71.sql as the JDA Foundation schema owner, using SQL*Plus. For example, if wwfmgr owns the JDA Foundation schema and the password is wwfmgr, then enter:



6. Run dm_dumpfe71.bat using the same database user as step 5. This file calls and runs a SQL script. For example,

dm_dumpfe71.bat wwfmgr wwfmgr

The batch file also creates an aggregate log file, dm_dumpfe71.out.

7. Run the batch file dm_fe2scpo71.bat using the following syntax:

dm_fe2scpo71.bat stsc <password>

Replace <password> with the password for the stsc user. This batch file calls and runs a SQL script. The batch file also creates an aggregate log file, dm_fe2scpo71.out.



Replace <password> with the password for the stsc user. This batch file calls and runs several SQL scripts. The batch file also creates an aggregate log file, dm_migrate71.out. The following errors may be displayed in the console and .out file:




*

ERROR at line 1:

ORA-00001: unique constraint (STSC.FCST_PK) violated




*

ERROR at line 1:

ORA-00001: unique constraint (STSC.FCSTDRAFT_PK) violated

These errors occur when JDA Demand Type 2 and 5 records are migrated to Type 99. Several records can exist for each DFU, so a constraint error occurs where the FCSTID is blank or the same for two or more records. These errors are normal. The migration is necessary for integration with JDA Market Manager.

Note: If you do not plan to integrate with JDA Market Manager, remove the Type 99 records from the SCPO database after you migrate. Otherwise, some JDA Demand processes may complete with errors. See Removing old data from the SCPO database.

9. Using SQL*Plus, run dm_DemandWorkbenchInstances.sql using the following syntax:



sqlplus <wwfuser>/<wwfpassword> @dm_DemandWorkbenchInstances.sql

This script is created by the migration process and may not have any statements to run, depending on whether your WebFTOpts table had data to migrate. Check dm_DemandWorkbenchInstances.log for errors.

10. Run dm_ForecastOverrideInstances.sql using the same syntax and database user as step 9.

This script is created by the migration process and may not have any statements to run, depending on whether your WebFOOpts table had data to migrate. Check dm_ForecastOverrideInstances.log for errors.




Migrate a version 7.1 database to 7.1.1 - Windows To migrate a version 7.1 database to 7.1.1 (full schema), level 83, you must have the supported version of Oracle installed and the SCPO database must be at full schema, level 82. Also, the 8.1.0.0 JDA Foundation schema must exist.













• If you started the SCPO 8.1.0.0 migration process with a version 6.x database, skip to Step 6.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_711.sql as the JDA Foundation schema owner using SQL*Plus. For example, if wwfmgr owns the JDA Foundation schema and the password is wwfmgr, then enter:





Replace <password> with the password for the stsc user. This batch file calls and runs several SQL scripts. The batch file also creates an aggregate log file, dm_migrate711.out.

7. Verify the database level. Using SQL*Plus, query the dbconfig table as user stsc: JDA Supply Chain Planning and Optimization Installation/Administration Guide 50 © 1997-2014 JDA Software Group, Inc.- Confidential




Migrate a version 7.1.1 database to 7.2 - Windows To migrate a version 7.1.1 database to 7.2, you must have the supported version of Oracle installed and the SCPO database must be at full schema, level 83. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.




• Check data for invalid user-defined columns (UDCs) (on page 51)


Check data for constraint violations SCPO version 7.2 includes new Oracle check constraints on database columns that existed in version 7.1.1. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. For example, if a row contains the value 110 in LOC.LAT and the check constraint defines the valid range to be between -90 and 90, the row would violate the check constraint and would cause the migration process to fail. Therefore, before you migrate your database to version 7.2, check your data for possible constraint violations by running dm_checkconstraints.bat. This file, which calls several SQL scripts, identifies rows in which the data for a column falls outside the valid range defined for that column. Rows that fail constraint checks are logged in dm_checkconstraints.out. Review this file to identify failed rows. Search for the string "ORA-", which identifies any integrity issues. Next, review dm_showbadrows72.log to determine the keys to the data rows that have inconsistencies. Adjust the column values in your database to fall in the valid range before you begin the migration process.

Note: When validating integrity constraints during Master Planning migration, you must use dm_showbadrows72.log to perform a pre-migration check of the foreign key relationship of CustOrder (Cust, HeaderExtRef) to CustOrderHeader (Cust, ExtRef).




4. Run dm_checkconstraints.bat using the following syntax:

dm_checkconstraints.bat stsc <password>

Replace <password> with the password for the stsc user. This file calls several SQL scripts and runs them sequentially. Failed rows can be viewed in dm_checkconstraints.out.

5. Review the failed rows identified in dm_checkconstraints.out and correct the invalid data in your database.

6. Rerun dm_checkconstraints.bat to ensure that all errors have been corrected.

Check data for invalid user-defined columns (UDCs) SCPO provides a script that checks the data in your database for invalid UDCs. This script, check_udc.sql, verifies the validity of UDCs by doing the following:

• Checks all columns in the database to identify UDCs that are not configured as UDCs. The column number for these columns falls in the UDC range but COL.USERCOLSW is not set.



• Checks all UDCs to ensure that the columns exist in the schema.

The script also creates a log file, check_udc.log. Review the log file to determine whether your database contains invalid UDCs. You must correct invalid UDCs before proceeding with migration.



3. Using SQL*Plus, run check_udc.sql using the following syntax:

sqlplus stsc/<password> @check_udc.sql

Replace <password> with the password for the stsc user. For example, if the password for user stsc is stsc, then enter:

sqlplus stsc/stsc @check_udc.sql

4. Review check_udc.log for errors. The log file contains sections for each check performed by the script. Do the following:

• If the log file identifies columns that are not configured as UDCs, verify that the columns are actually UDCs and determine how they were created. For each column that represents a valid UDC, set COL.USERCOLSW to 1 in the database.

• If the log file identifies UDCs that do not exist in the schema, stop the migration process and contact JDA Support Services for assistance.

The following sample log file results if your database contains no invalid UDCs:

Checking for UDCs that are not configured as UDCs...

no rows selected

Checking for UDCs that are not present in the schema...

no rows selected

Migrate to 7.2 1. Open a command line prompt.


• SCPO database is at level 83 by querying the dbconfig table using SQL*Plus as the SCPO schema owner, stsc:



• JDA Foundation schema is at 8.1.0.0 by using SQL*Plus as the JDA Foundation schema owner. For example:






Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and the JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and the JDA Foundation metadata layer. The script also creates a log file enroll_app_schema.log.



Note: While running enroll_app_schema.sql, ignore any error messages that refer to DEMANDASSOCVIEW, SUPPLYASSOCVIEW, and SUPPLYORDERVIEW views. These views become valid only after the database is completely migrated to 7.2.


6. Using SQL*Plus, run gensys_migration.sql using the following syntax:

sqlplus stsc/<password> @gensys_migration.sql


This file calls and runs SQL scripts.


8. Run verify_ds_tables.sql as the JDA Foundation schema owner to verify if you have any invalid searches in the Foundation schema. For example:

sqlplus wwfmgr/wwfmgr @verify_ds_tables.sql

If the script displays invalid searches, you must run cleanse_ds_tables.sql to verify and delete the invalid searches. This script can be run with two options.

• L: Use this option to list the invalid searches. For example:

sqlplus wwfmgr/wwfmgr @cleanse_ds_tables.sql L

• D: Use this option to delete the invalid searches. For example:

sqlplus wwfmgr/wwfmgr @cleanse_ds_tables.sql D


10. Run migrate_relatedLinkToDynamicNav.sql using the following syntax:

sqlplus <wwfuser>/<wwfpassword> @migrate_relatedLinkToDynamicNav.sql

Replace <wwfuser> and <wwfpassword> with the username and password for the JDA Foundation schema owner.

This script migrates SCPO 7.1.1 related links to Dynamic Navigation in JDA Foundation 7.2.



This SQL script grants the SCPO schema owner access to the JDA Foundation tables need to create a database. See scpo_grants.log for errors.


dm_migrate72.bat stsc <scpopassword> <wwfuser> <wwfpassword>

Replace <scpopassword> with the password for the stsc user. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password. This batch file calls and runs several SQL scripts. The batch file also creates an aggregate log file, dm_migrate72.log. Review the log file for errors.

13. Run migrate_relatedProcessToDynamicNav.sql as the JDA Foundation schema owner. For example:

sqlplus wwfmgr/wwfmgr @migrate_relatedProcessToDynamicNav.sql

This script migrates SCPO 7.1.1 related processes to Dynamic Navigation in JDA Foundation 7.2.



• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run the script load_csm_72.sql as the JDA Foundation schema owner. For example:




The script creates a log file, load_csm_72.log. Review the log file for errors.

15. Change to directory <install_dir>\config\database\oracle\platform.

16. Run convert_to_char_semantic.sql as the Oracle system user. For example:

sqlplus system/manager @convert_to_char_semantic.sql

The script creates a log file, convert_to_char_semantic.log. Review the log file for errors. Ignore Tab and Col errors. Objects considered invalid by Oracle cannot be compiled and you will receive an error. Generally, you can ignore these errors, or remove the invalid object and re-run the script.

This script converts all VARCHAR2 and CHAR column types to NLS Character Length Semantics. This step is required for UTF8 databases.



Enter the schema_name when prompted. For example: <wwfuser> while running on the Foundation schema and <scpouser> when running on the SCPO schema

18. Optionally, grant the necessary privileges to the stsc user as follows:



grant connect, resource, create table, create synonym, create sequence, create view to stsc;

grant unlimited tablespace to stsc;

Note: The migration process requires these privileges. If you subsequently have to remigrate your database, you must grant these privileges to stsc before proceeding.

19. Log in to SQL*Plus as the JDA Foundation schema owner, then query the database to verify the database level for SCPO. For example:




Migrate the SCPO schema from 7.2.x, 7.3.x, 7.4.0, 7.4.1 to 8.1.0.0 - UNIX or Windows This section describes the basic steps for migrating your database from a previous version of JDA Supply Chain Planning and Optimization. Database migration preserves your data while providing the 8.1.0.0 schema necessary for version 8.1.0.0.

Database migration must be performed in the sequence described in this section. For example, if you have a version 7.2 database, you must first upgrade to version 7.3.x.

Before you begin the migration process, review the section Overview of the upgrade process (on page 31). Next, proceed to the appropriate section of this chapter, depending on your current database level.

Migrate a version 7.2 database to 7.2.0.1 To migrate a version 7.2 database to 7.2.0.1, level 85, you must have the supported version of Oracle installed and the SCPO database must be at 7.2, level 84. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.



The migration process requires that shell scripts/batch files be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.




• SCPO database is at level 84. Query the md_config table using SQL*Plus as the JDA Foundation schema owner.


For example: sqlplus wwfmgr/wwfmgr

select * from md_config;


• JDA Foundation schema is at 8.1.0.0. Using SQL*Plus as the JDA Foundation schema owner.




4. Change to directory <install_dir>/config/database/platform (UNIX) or <install_dir>\config\database\platform (Windows).



Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and the JDA Foundation metadata layer. The script also creates a log file, enroll_app_schema.log.

6. Change to directory <install_dir>/config/database/scpoweb (UNIX) or <install_dir>\config\database\scpoweb (Windows).

7. Run dm_migrate7201.ksh (UNIX) or dm_migrate7201.bat (Windows) using the following syntax:

UNIX:

dm_migrate7201.ksh <scpouser> <scpopassword> <wwfuser> <wwfpassword>

Windows:

dm_migrate7201.bat <scpouser> <scpopassword> <wwfuser> <wwfpassword>

Replace <scpouser> and <scpopassword> with the SCPO schema owner and password. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password. This file calls and runs SQL scripts. Check dm_migrate7201.out for errors.



• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_7201.sql as the JDA Foundation schema owner using SQL*Plus. For example:

sqlplus <wwfuser>/<wwfpassword> @load_csm_7201.sql



This file calls and runs SQL scripts that add metadata for various SCPO applications to the JDA Foundation schema. The script creates a log file, load_csm_7201.log. Review the log file for errors. Ignore Unique Constraint Violation and Integrity Constraint errors.

9. Log in to SQL*Plus as the JDA Foundation schema owner and query the database to verify the database level for SCPO.





Migrate a version 7.2.0.1 database to 7.2.1 To migrate a version 7.2.0.1 database to 7.2.1, level 86, you must have the supported version of Oracle installed and the SCPO database must be at level 85. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.

The migration process requires that shell scripts/batch files be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.

Check data for constraint violations SCPO version 7.2.1 includes Oracle check constraints on database columns that existed in version 7.2.0.1. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. For example, if a row contains the value 110 in LOC.LAT and the check constraint defines the valid range to be between -90 and 90, the row would violate the check constraint and would cause the migration process to fail. Therefore, before you migrate your database to version 7.2.1, check your data for possible constraint violations by running dm_checkconstraints721.ksh (UNIX) or dm_checkconstraints721.bat (Windows). This file, which calls several SQL scripts, identifies rows in which the data for a column falls outside the valid range defined for that column. Rows that fail constraint checks are logged in dm_checkconstraints721.out. Review the data in this file to identify failed rows. Search for the string "ORA-", which identifies any integrity issues. Next, review dm_showbadrows721.log to determine the keys to the data rows that have inconsistencies. Adjust the column values in your database to fall in the valid range before you begin the migration process.

Note: When validating integrity constraints during Master Planning migration, you must use dm_showbadrows721.log to perform a pre-migration check of several new foreign key relationships.




4. Run dm_checkconstraints721.ksh (UNIX) or dm_checkconstraints721.bat (Windows) using the following syntax:

UNIX:

dm_checkconstraints721.ksh <scpouser> <password>

Windows:

dm_checkconstraints721.bat <scpouser> <password>

Replace <scpouser> and <password> with the SCPO schema owner and password. This file calls several SQL scripts and runs them sequentially. Failed rows can be viewed in dm_checkconstraints721.out.



5. Review the failed rows identified in dm_checkconstraints721.out and correct the invalid data in your database.

6. Rerun dm_checkconstraints721.ksh / dm_checkconstraints721.bat to ensure that all errors have been corrected.

Migrate to 7.2.1 1. Back up your database.



• SCPO database is at level 85. Querying the md_config table using SQL*Plus as the JDA Foundation schema owner.





• JDA Foundation schema is at 8.1.0.0. Use SQL*Plus as the JDA Foundation schema owner.





5. Using SQL*Plus, run scpo_grants.sql as the Oracle system user. For example, enter the following:


This SQL script grants the SCPO schema owner access to the JDA Foundation tables needed to create a database. See scpo_grants.log for errors.


UNIX:


Windows:


Replace <scpouser> and <scpopassword> with the SCPO schema owner and password. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password. This file calls and runs SQL scripts. Check dm_migrate721.log for errors.









• If you started the SCPO 8.1.0.0 migration process with a version 6.x database, run fix_csm72_direct_migr.sql as the JDA Foundation schema owner. For example:

sqlplus <wwfuser>/<wwfpassword> @fix_csm72_direct_migr.sql

Next, continue to Step 11.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_721.ksh (UNIX) or load_csm_721.bat as the JDA Foundation schema owner and the SCPO schema owner. For example:

UNIX:

load_csm_721.ksh <wwfuser> <wwfpassword> <scpouser> <scpopassword>

Windows:

load_csm_721.bat <wwfuser> <wwfpassword> <scpouser> <scpopassword>

This file calls and runs SQL scripts. The script creates a log file, load_csm_721.out. Review the log file for errors.




Replace <scpouser> with the SCPO schema owner. It is important to rerun this script even though it was run in Step 8, because in Step 10, several new tables are created to which the JDA Foundation schema owner has not been given permissions. The script also creates the enroll_app_schema.log file.

13. Log in to SQL*Plus as the JDA Foundation schema owner and query the database to verify the database level for SCPO. Type the following command:



Migrate a version 7.2.1 database to 7.2.1.1 To migrate a version 7.2.1 database to 7.2.1.1, level 87, you must have the supported version of Oracle installed and the SCPO database must be at level 86. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.

Migrate to 7.2.1.1 The migration process requires that shell scripts/batch files be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.




















UNIX:


Windows:







Note: Occasionally during migration, the enroll_app_schema.sql script displays error messages regarding invalid views or procedures. If this happens before the last time you run the script, you can ignore the errors. However, if the last run of the script displays this type of error, recompile the views or procedures using Oracle. See the Oracle documentation for instructions.



• If you started the SCPO 8.1.0.0 migration process with a version 6.x database, continue to Step 11.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_7211.ksh (UNIX) or load_csm_7211.bat (Windows) as the JDA Foundation schema owner and the SCPO schema owner. For example:

UNIX:




Windows:


This file calls and runs SQL scripts. The script creates a log file, load_csm_7211.log. Review the log file for errors.




Migrate a version 7.2.1.1 or 7.2.2 database to 7.3 To migrate a version 7.2.1.1 or 7.2.2 database to 7.3, level 88, you must have the supported version of Oracle installed and the SCPO database must be at level 87. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.



• Check data for invalid user-defined columns (UDCs) (on page 86)


Check data for constraint violations SCPO version 7.3 includes new Oracle check constraints on database columns that existed in version 7.2.1.1 or 7.2.2 and attempts to add any missing constraints. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. Before you migrate your database to version 7.3, check and add missing constraints by running chk_fk_references.sql. This script attempts to add any missing Foreign Key constraints. The missing constraints are logged in missing_fk_references.log. Success or failure of attempts to add missing FK constraints is logged in add_missing_fk_references.log. For attempts that fail, pointers to inconsistent data are written to temporary table SCPOFKConstraintErrs and the results are reported in show_missing_fk_badrows.log.



3. Change to the directory <install_dir>/config/database/scpoweb (UNIX) or <install_dir>\config\database\scpoweb (Windows).

4. Run chk_fk_references.sql as the SCPO schema owner using the following syntax:

sqlplus <scpouser>/<scpopassword> @chk_fk_references.sql

This file calls several SQL scripts and runs them sequentially. The file logs missing constraints in missing_fk_references.log.

5. Review the failed rows identified in add_missing_fk_references.log and correct the invalid data in your database.

6. Rerun the chk_fk_references.sql script to ensure that all errors have been corrected.

Migrate to 7.3 The migration process requires that shell scripts/batch files be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.















4. If not already run, run the following SQL query as the Oracle system user to grant the relevant rights to the SCPOMGR user:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO <scpouser>;

Example:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO SCPOMGR;






UNIX:

dm_migrate73.ksh <scpouser> <scpopassword> <wwfuser> <wwfpassword> JDA Supply Chain Planning and Optimization Installation/Administration Guide 61 © 1997-2014 JDA Software Group, Inc.- Confidential


Windows:









11. Perform one of the following:

• If you started the SCPO 8.1.0.0 migration process with a version 6.x database, continue to step 12.

• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_73.ksh (UNIX) or load_csm_73.bat (Windows) as the JDA Foundation schema owner and SCPO schema owner. For example:

UNIX:


Windows:






Replace <scpouser> with the SCPO schema owner. This step grants the JDA Foundation schema owner access to any new KEY tables created in step 11. The script also creates a log file, enroll_app_schema.log.







Enter the schema name when prompted. For example: <wwfuser> while running on the Foundation schema and <scpouser> when running on the SCPO schema.




Migrate a version 7.3 database to 7.3.0.1 To migrate a version 7.3 database to 7.3.0.1, level 89, you must have the supported version of Oracle installed and the SCPO database must be at level 88. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.















GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO <scpouser>;

For example:



GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO SCPOMGR;




This SQL script grants the SCPO schema owner access to the JDA Foundation tables needed to create a database. See the scpo_grants.log file for errors.


UNIX:


Windows:


Replace <scpouser> and <scpopassword> with the SCPO schema owner and password. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password. Check dm_migrate7301.log for errors.




Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and the JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and JDA Foundation metadata layer. The script also creates a log file enroll_app_schema.log.

Note: Occasionally during migration, enroll_app_schema.sql displays error messages regarding invalid views or procedures. If this happens before the last time you run the script, you can ignore the errors. However, if the last run of the script displays this type of error, recompile the views or procedures using Oracle. See the Oracle documentation for instructions.




• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_7301.ksh (UNIX) or load_csm_7301.bat (Windows) as the JDA Foundation schema owner and SCPO schema owner using the following syntax:



UNIX:


Windows:






Replace <scpouser> with the SCPO schema owner. This step grants the JDA Foundation schema owner access to any new KEY tables created in step 11. The script also creates a log file enroll_app_schema.log.





Enter the schema name when prompted. For example: <wwf_schema_name> while running on the Foundation schema and <scpo_schema_name> when running on the SCPO schema.



For example: sqlplus wwfmgr/wwfmgr;



Migrate a version 7.3.0.1 database to 7.4.0.0 To migrate a version 7.3.0.1 database to 7.4.0.0, level 90, you must have the supported version of Oracle installed and the SCPO database must be at level 89. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.

Check data for constraint violations SCPO version 7.4 includes new Oracle check constraints on database columns that existed in version 7.3.0.1. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. For example, if a row contains the value 110 in LOC.LAT and the check constraint defines the valid range to be between -90 and 90, the row would violate the check constraint and would cause the migration process to fail.



Before you migrate your database to version 7.4, check your data for possible constraint violations by running dm_checkconstraints74.ksh (UNIX) or dm_checkconstraints74.bat (Windows). This file, which calls several SQL scripts, identifies rows in which the data for a column falls outside the valid range defined for that column. Rows that fail constraint checks are logged in dm_checkconstraints74.out. Review the data in this file to identify failed constraints. Search for the string "ORA-", which identifies any integrity issues. Next, review dm_showbadrows74.log to determine the keys to the data rows that have inconsistencies. Adjust the column values in your database to fall in the valid range before you begin the migration process.





UNIX:

dm_checkconstraints74.ksh <scpouser> <scpopassword>

Windows:

dm_checkconstraints74.bat <scpouser> <scpopassword>

Replace <password> with the password for the scpomgr user. This file calls several SQL scripts and runs them sequentially. Failed rows can be viewed in dm_checkconstraints74.out.


6. Rerun dm_checkconstraints74.ksh / dm_checkconstraints74.bat to ensure that all errors have been corrected.

















GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO <scpouser>;

For example:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO SCPOMGR;




This SQL script grants the SCPO schema owner access to the JDA Foundation tables needed to create a database. See the scpo_grants.log for errors.


UNIX:


Windows:






Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and the JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and JDA Foundation metadata layer. The script also creates a log file, enroll_app_schema.log.

Note: Occasionally during migration, enroll_app_schema.sql script displays error messages regarding invalid views or procedures. If this happens before the last time you run the script, you can ignore the errors. However, if the last run of the script displays this type of error, recompile the views or procedures using Oracle. See the Oracle documentation for instructions.






• If you started the SCPO 8.1.0.0 migration process with a version 7.x database, run load_csm_74.ksh (UNIX) or load_csm_74.bat (Windows) as the JDA Foundation schema owner and SCPO schema owner. For example:

UNIX:


Windows:











Enter the schema_name when prompted. For example: <wwf_schema_name> when running on the Foundation schema and <scpo_schema_name> when running on the SCPO schema.






Migrate a version 7.4.0.0 database to 7.4.1 To migrate a version 7.4.0.0 database to 7.4.1, level 91, you must have the supported version of Oracle installed and the SCPO database must be at level 90. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.



Check data for constraint violations SCPO version 7.4.1 includes new Oracle check constraints on database columns that existed in version 7.4.0.0. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. For example, if a row contains the value 110 in LOC.LAT and the check constraint defines the valid range to be between -90 and 90, the row would violate the check constraint and would cause the migration process to fail.

Before you migrate your database to version 7.4.1, check your data for possible constraint violations by running dm_checkconstraints741.ksh (UNIX) or dm_checkconstraints741.bat (Windows). This file, which calls several SQL scripts, identifies rows in which the data for a column falls outside the valid range defined for that column. Rows that fail constraint checks are logged in dm_checkconstraints741.out. Review the data in this file to identify failed constraints. Search for the string "ORA-", which identifies integrity issues. Next, review dm_showbadrows741.log to determine the keys to the data rows that have inconsistencies. Adjust the column values in your database to fall in the valid range before you begin the migration process.





UNIX:


Windows:


Replace <scpopassword> with the password for the <scpouser>. This file calls several SQL scripts and runs them sequentially. The file logs failed rows in dm_checkconstraints741.out.


6. Rerun dm_checkconstraints741.ksh or dm_checkconstraints741.bat to ensure that all errors have been corrected.

Migrate to 7.4.1 The migration process requires that shell scripts/batch files be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.















4. If not already run, run the following SQL query as the Oracle system user to grant the relevant rights to SCPOMGR user:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO <scpouser>;

For example:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO SCPOMGR;

5. Change to directory <install_dir>/config/scpoweb/database (UNIX) or <install_dir>\config\scpoweb\database (Windows).





UNIX:


Windows:



8. Change to directory <install_dir>/config/webworks/database/oracle (UNIX) or <install_dir>\config\webworks\database\oracle (Windows).











UNIX:


Windows:



12. Change to directory <install_dir>/config/webworks/database/oracle (UNIX) or <install_dir>\config\webworks\database\oracle (Windows).






15. Using SQL*Plus, run gather_db_stats.sql as the Oracle system user for both JDA Foundation and SCPO schemas. For example:


Enter the schema_name when prompted. For example: <wwf_schema_name> when running on the Foundation schema and <scpo_schema_name> when running on the SCPO schema.








Migrate a version 7.4.1 database to 7.4.2 To migrate a version 7.4.1 database to 7.4.2, level 92, you must have the supported version of Oracle installed and the SCPO database must be at level 91. Also, JDA Platform version 8.1.0.0 must be installed and the 8.1.0.0 JDA Foundation schema must exist.

Check data for constraint violations SCPO version 7.4.2 includes Oracle check constraints on database columns that existed in version 7.4.1. As a result, some rows in your database may contain data that is out of range and therefore no longer valid. For example, if a row contains the value 110 in LOC.LAT and the check constraint defines the valid range to be between -90 and 90, the row would violate the check constraint and would cause the migration process to fail.

Before you migrate your database to version 7.4.2, check your data for possible constraint violations by running dm_checkconstraints742.ksh (UNIX) or dm_checkconstraints742.bat (Windows). This file, which calls several SQL scripts, identifies rows in which the data for a column falls outside the valid range defined for that column. Rows that fail constraint checks are logged in dm_checkconstraints742.out. Review the data in this file to identify failed constraints. Search for the string "ORA-", which identifies any integrity issues. Next, review dm_showbadrows742.log to determine the keys to the data rows that have inconsistencies. Adjust the column values in your database to fall in the valid range before you begin the migration process.





UNIX:


Windows:


Replace <scpopassword> with the password for the <scpouser>. This file calls several SQL scripts and runs them sequentially. Failed rows can be viewed in dm_checkconstraints742.out.


6. Rerun dm_checkconstraints742.ksh or dm_checkconstraints742.bat to ensure that all errors have been corrected.

Migrate to 7.4.2 The migration process requires that shell scripts/batch files be run against the SCPO database and JDA Foundation schemas. The schemas may be owned by the same database user or by different database users. You must know this information before proceeding.


2. Open a command_line prompt.













4. If not already run, run the following SQL query as the Oracle system user to grant the relevant rights to SCPOMGR user:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO <scpouser>;

For example:

GRANT

CONNECT,

CREATE TABLE,

CREATE VIEW,

CREATE SYNONYM,

CREATE SEQUENCE,

RESOURCE

TO SCPOMGR;






UNIX:


Windows:














UNIX:


Windows:






Replace <scpouser> with the SCPO schema owner. This step grants the JDA Foundation schema owner access to any new KEY tables created in step 11. The script also creates a log file, enroll_app_schema.log.









Migrate SCPO schema from 7.4.2 or later to version 8.1 If your database is at version 7.4.2 or later, you can migrate your database directly to version 8.1 without going through interim steps. Ensure that you migrate your JDA Foundation schema to version 8.1 before migrating the SCPO schema.

The SCPO migration will create two reference schemas during migration: WWFREFOSM for the Foundation metadata and SCPOREFOSM for the SCPO reference schema. The reference schemas serve as a references to update the JDA Foundation and SCPO schemas to the current version. In the instructions below, <wwf_target_schemaname> and <scpo_target_schemaname> refer to the schema that you are migrating.


2. Open a command-line or shell prompt.

3. Change to directory to <install_dir>/config/database/scpoweb/migration and run the pre-migration script, passing in the name of the target schema:

Note: This SCPO version includes new Oracle constraints that may not be in earlier versions. As a result, some rows in your database can contain data that is out of range and therefore no longer valid. The script premigrate_scpo is provided to check for constraint violations.

premigrate_scpo < scpo_target_schemaname > <scpo_target_pwd> <wwf_target_schemaname> <wwf_target_pwd> <system_user> <system_pwd> <db_hostname> <db_service> <db_listner_port> [Rerun(Y/N]

For example:

premigrate_scpo scpomgr scpomgr wwfmgr wwfmgr system password hoststring o11gr203 1521

Enter Y at the end if you are running the premigration script a second time, and do not need to re-create the reference schema. For example:

premigrate_scpo scpomgr scpomgr wwfmgr wwfmgr system password hoststring o11gr203 1521 Y

In this case, the reference schemas will not be re-created. By default, the Rerun option is N (no), which will always create (or re-create) the reference schemas.

4. Review premigrate_scpo.log to identify failed constraints. (Search for "ORA-", which identifies integrity issues.) Review the show_badrows.log to determine the keys to the data rows that have inconsistencies. If errors are reported, adjust the column values in your database to fall in the valid range. After you have corrected any inconsistencies in the database, re-run premigrate_scpo.cmd/ksh to ensure that all errors have been resolved before continuing with the migration.

5. Run the migration script to migrate the database to the 8.1 level. Check the log files for ORA- errors once the script completes execution.

migrate_scpo <scpotarget_user> <scpotarget_pwd> <wwftarget_user> <wwftarget_pwd> <system_user> <system_pwd> <db_hostname> <db_service> <db_listner_port> [Rerun(Y/N]

For example:

migrate_scpo scpomgr scpomgr wwfmgr wwfmgr system password hoststring o11gr203 1521

Enter Y for Rerun if you have already run the migration previously and do not want to have the reference schema re-created.

6. Verify the migration log (migrate_scpo.log) for errors.

Clean up Flexible Editor instances



In some cases, you may have Flexible Editor instances in your database that refer to tables that are not configured for your system. JDA provides a script to identify and/or delete these extraneous Flexible Editor instances. Use the following command to run the script after migration:

Sqlplus <wwfuser>/<wwfpassword> @cleanse_unconfigured_fe_instances.sql [C,L,D]

• C provides the number of instances that are not configured.

• L lists the instances that are not configured.

• D deletes the instances that are not configured.

Run post-migration scripts for 6.x migrations(optional) This section describes optional post-migration scripts that you can run if you are migrating from SCPO 6.x. The migration process creates these scripts.

Post-migration scripts-UNIX or Windows

Script location Purpose Dependencies

<install_dir>/config/database/scpoweb/dm_uvp2fe.sql (UNIX)

or

<install_dir>\config\scpoweb\database\dm_uvp2fe.sql (Windows)

This script determines and creates the scripts to convert the client/server userviews.

The script also creates the following scripts in the Oracle DB server's $ORACLE_HOME/database directory:

• dm_insert_vpfe_02_<SID>.sql

• dm_insert_vpfe_134_<SID>.sql

This script creates a log, dm_uvp2fe.log. Run this script against the JDA Foundation schema.

None

$ORACLE_HOME/database/dm_insert_vpfe_02_<SID>.sql (UNIX)

or

$ORACLE_HOME\database\dm_insert_vpfe_02_<SID>.sql (Windows)

Converts migrated 5.x or 6.x client/server Editor and Graph userviews to Flexible Editor (FE) instances. See the table after this table.

In some cases (for example, if you are strictly managing FE instances (formerly userviews)), you may not want to run this script.

Run this script against the JDA Foundation schema.

To run this script, you must first run dm_uvp2fe.sql.

$ORACLE_HOME/database/dm_insert_vpfe_134_<SID>.sql (UNIX)

or

$ORACLE_HOME\database\dm_insert_vpfe_134_<SID>.sql (Windows)

Converts migrated 5.x or 6.x client/server Export, Import, and Report (Print) userviews to Flexible Editor (FE) instances. See the table after this table.

In some cases (for example, if you are strictly managing FE instances (formerly userviews)), you may not want to run this script.

Run this script against the JDA Foundation schema.

To run this script, you must first run dm_uvp2fe.sql.




<install_dir>/config/database/scpoweb/dm_migrate_feexpressions.sql (UNIX)

or

<install_dir>\config\database\scpoweb\dm_migrate_feexpressions.sql (Windows)

Adds column expressions to the FE_Expression table in the JDA Foundation schema, and adds a row to the FE_Instance_Cols table for each expression column that is part of a userview. Run this script as owner of the JDA Foundation schema.

Note: Run this script only if you have already run one of the optional scripts created by dm_uvp2fe.sql.

To run this script, you must first run dm_insert_vpfe_02.sql or dm_insert_vpfe_134.sql

<install_dir>/config/database/scpoweb/dm_scpo2csmuser.sql (UNIX)

or

<install_dir>\config\database\scpoweb\dm_scpo2csmuser.sql (Windows)

Creates a script to migrate SCPO users, roles, and Table access control lists (ACLs) into the Security Manager.

Run this script as the JDA Foundation schema owner.

To actually complete the migration, you must run the generated script, dm_insert_csm_objects.sql.

None

<install_dir>/config/database/scpoweb/dm_insert_csm_objects.sql (UNIX)

or

<install_dir>\config\database\scpoweb\dm_insert_csm_objects.sql (Windows)

Migrates SCPO users, roles, and Table ACLs into CSM. A default password is used for any new CSM user created.


To run this script, you must first run dm_scpo2csmuser.sql.

<install_dir>/config/database/scpoweb/dm_migrate_data_selections.sql (UNIX)

or

<install_dir>\config\database\scpoweb\dm_migrate_data_selections.sql (Windows)

Migrates SCPO data selections (DS) into CSM Searches. See the table after this table to determine how the data selections are migrated based on various combinations of Desktop and Userview scopes. Ignore the Add desktop name column; instead, an incremental number is used to ensure that no names are duplicated.


None

<install_dir>/config/database/scpoweb/dm_desktop2tasklist.sql (UNIX)

or

<install_dir>\config\database\scpoweb\dm_desktop2tasklist.sql (Windows)

Migrates SCPO Desktops into CSM tasks and tasklists. The User or Public scope on the desktop is maintained as User or Public tasks. Only FE userviews are migrated. All FE userviews belonging to a Desktop are created as part of the tasklist.

Run this script as JDA Foundation schema owner.

To run this script, you must first run

dm_insert_csm_objects.sql and either dm_insert_vpfe_02_<SID>.sql or dm_insert_vpfe_134_<SID>.sql.




<install_dir>/config/database/scpoweb/dm_migrate_6x_fixes.sql (UNIX)

or

<install_dir>\config\database\scpoweb\dm_migrate_6x_fixes.sql (Windows)

The script migrates the Master Planning option sets added in 6.x and fixes the issue related to Calendar Manager Instance.

Run this script as JDA Foundation schema owner.

None

Conversion of migrated userviews to Flexible Editor instances-UNIX and Windows

Desktop scope Userview scope Shared Add desktop name

Public Public Yes No

Public Desktop Yes Yes

Public User No No

User Public Yes No

User Desktop No Yes, and adds _DT to the end

User User No No

To run the optional post-migration scripts:


2. Set the ORACLE_SID to the database hosting the JDA Foundation schema.

3. Change to the directory where the script you want to run is located.

4. Run the optional script according to the information described in the "Post-migration scripts-UNIX or Windows" table in this section.

Change schema owners Optionally, change the SCPO schema owner from stsc to a different Oracle user as follows:

1. Export your database using Oracle Export.

2. Reimport your database from user stsc to the new SCPO schema owner.


4. Run change_schema_name.sql as the Oracle system user. For example:


Replace <old_schema_name> with the user stsc, <new_schema_name> with the Oracle user ID that you want to own the SCPO schema, and <wwfuser> with the name of the JDA Foundation schema owner. For example,

sqlplus system/manager @change_schema_name.sql stsc scpomgr wwfmgr

5. Rerun enroll_app_schema.sql as the Oracle system user. For example:

sqlplus system/manager @enroll_app_schema.sql <scpouser> JDA Supply Chain Planning and Optimization Installation/Administration Guide 78 © 1997-2014 JDA Software Group, Inc.- Confidential


Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema and JDA Foundation schema. Permissions on the ManugisticsPkg are granted to the application schema owner. This is necessary to support the automatic features in the service runtime environment and JDA Foundation metadata layer. The script also creates a log file, enroll_app_schema.log.

Note: When you installed SCPO, the software replaced a variable in several SCPO files with the Oracle user ID and password you specified during installation. These files must be updated to reflect the new SCPO schema owner before you start the JDA Platform Server. To perform this task, uninstall and reinstall the SCPO software using the new SCPO schema owner.

To change the JDA Foundation schema owner to a different Oracle user, repeat steps 1 through Ring834725 for the JDA Foundation schema owner. When you run change_schema_name.sql, replace <old_schema_name> with the old JDA Foundation schema owner and replace both <new_schema_name> and <wwfuser> with the new JDA Foundation schema owner.

For example, if you want to change the JDA Foundation schema owner from wwfmgr wwfmgr2, run the script change_schema_name.sql as follows:

sqlplus system/manager @change_schema_name.sql wwfmgr wwfmgr2 wwfmgr

Note: When you installed JDA Platform, the software replaced a variable in several Platform files with the Oracle user ID and password you specified during installation. These files must be updated to reflect the new JDA Foundation schema owner before you start the JDA Platform Server. To perform this task, uninstall and reinstall the Platform software using the new JDA Foundation schema owner.

After running the change_schema_name.sql script, run update_app_synonyms.sql in <install_dir>/config/database/platform as the Oracle system user to update the application synonyms with the changed JDA Foundation schema name. For example:


Replace <old_schema_name> with the old Foundation schema owner, <new_schema_name> with the new Foundation schema owner, and <scpouser> with the SCPO schema owner. For example:


Migrate from DPEE to SCPO 8.1 - UNIX or Windows This section describes procedures for migrating data from a Demand Planning Extended Edition (DPEE) version 6.1.x database to a SCPO version 8.1 database (MD_CONFIG.LEVELNUM = 97).

Before you begin migration from DPEE to SCPO 8.1 Before you begin, ensure that your DPEE database is at the 6.1.x level (FORSYS_SYSTEM.CVERSION = "6.10001215"). If you are running an earlier version of DPEE, you must migrate your DPEE database to level 6.10001215 or higher before you migrate to SCPO version 8.1.

• If you are running an earlier version of DPEE, contact JDA Support Services for assistance.

Incremental migrations are not supported in 8.1. If you previously migrated from DPEE to SCPO version 7.0 using the patch CD, you cannot migrate from SCPO version 7.0 to version 8.1. You must install SCPO 8.1 and repeat the migration process in its entirety by migrating from DPEE to SCPO 8.1.

Enable the DPEE migration component After you have installed JDA Platform 8.1 and SCPO 8.1, perform the following steps to enable the DPEE migration component.

For IBM WebSphere:

1. Using a text editor, open <install_dir>\config\bin\scpoweb\addDPEEConnectionPool.ksh (addDPEEConnectionPool.cmd) and update the values for WEBWORKS_HOME and PATH.



Note: If you are running the application server (IBM WebSphere) in a clustered environment using an RAC (Real Application Cluster) SID, update the values for SERVER_HOST_NAME and SERVER_SOAP_PORT, as below:

SERVER_HOST_NAME = <DEPLOYMENT_MANAGER_HOST_NAME>

SERVER_SOAP_PORT = <DEPLOYMENT_MANAGER_SOAP_PORT>

Replace the text in < > with the appropriate information.

2. Run <install_dir>\config\bin\scpoweb\addDPEEConnectionPool.ksh (addDPEEConnectionPool.cmd) using the following syntax:

addDPEEConnectionPool.ksh <admin_user> <admin_password> <db_host> <db_port> <db_sid> <db_username> <db_password>

Note: If you are running the application server (IBM WebSphere) in a clustered environment using an RAC (Real Application Cluster) SID, run the <install_dir>\config\bin\scpoweb\addDPEEConnectionPool_ND.ksh (addDPEEConnectionPool_ND.cmd) using the following syntax:

addDPEEConnectionPool_ND.ksh <admin_user> <admin_password> <nodeName> <db_host> <db_port> <db_sid> <db_username> <db_password>

where, db_sid = instance name, and node name = node of the profile on which the application is installed.

3. Restart the JDA Platform Server after creating the connection pool.

4. Migrate DPEE using the steps mentioned in the section Run the migration (on page 84).

For Oracle WebLogic:

1. Using a text editor, open <install_dir>\config\bin\scpoweb\EnableDPEEMigration.ksh (EnableDPEEMigration.cmd) and update the values for BEA_HOME and WEBWORKS_HOME.

2. Open <install_dir>\config\bin\scpoweb\createDPEEConnectionPool.py and update the values for the following variables:

# Weblogic server details

SERVER_HOST_NAME = "<SERVER HOSTNAME>"

SERVER_STANDARD_PORT = "<SERVER PORT NUMBER>"

WEBWORKS_HOME = "<WEBWORKS HOME>"

# Enter DP/EE database details

DPEE_DB_HOST = "<DPEE DB HOSTNAME>"

DPEE_DB_PORT = "<DPEE DB PORTNUMBER>"

DPEE_DB_SID = "<DPEE DB SID>"

DPEE_DB_USERNAME = "<DPEE DB USERNAME>"

DPEE_DB_PASSWORD = "<DPEE DB PASSWORD>"

For example:

SERVER_STANDARD_PORT = "7001"

DPEE_DB_USERNAME = "dpmgr"



3. Start the JDA Platform Server:

a. Open a command line prompt.

b. Change to directory <install_dir>\config\database\platform and enter the following command:

startWebworksServer

4. Run the command to enable DPEE migration:

a. Open a command_line prompt.

b. Change to directory <install_dir>\config\bin\scpoweb and enter the following command:

EnableDPEEMigration.cmd

Note: Use the following command on UNIX:

EnableDPEEMigration.sh

5. If you are using Real Application Cluster (RAC) configuration for Oracle, open <install_dir>\config\JDADomain\config\jdbc\DPEEConnectionPool*.xml and update the connection string in the following URL to use RAC:

Change:

<url>jdbc:oracle:thin:@#SINGLENODE_CONNECTION_STRING#</url>

to

<url>jdbc:oracle:thin:@#RAC_CONNECTION_STRING#</url>


Migration process overview The key components of the migration process are the command file, MigrateDPEE.cmd (Windows) or MigrateDPEE.sh (UNIX), and the properties file, DPEEMigration.properties. The properties file contains settings used by the migration process to migrate data from a DPEE 6.1.X database to the SCPO 8.1 database.

Migration steps Before migration, enable the DPEE migration component. See "Enable the DPEE migration component (on page 79)".

The migration process includes the following high-level steps:

• Pre-migration preparation (on page 83)

This phase prepares your data for migration and sets up the migration properties file.

• Run the migration (on page 84)

This phase runs the command file to transform and move the data.

• Post-migration procedures (on page 84)

This phase modifies the SCPO data created by the migration process.

After migration, disable the DPEE migration component to improve system performance. See "Disable the DPEE migration component (on page 85)".

How data is migrated The migration process consists of separate steps for each type of data to be migrated. The following table describes each step.



Steps in the DPEE to SCPO 8.1 migration process

Step Data type Description DPEE tables SCPO tables

1 Hierarchies Hierarchical structure

Hierarchical entries

FFW_STRUCTDEF

FFW_H_ENTRIES

DIMENSION, HIERARCHY, HIERARCHY_ENTRY, HIERARCHY_LEVEL

2 DFUs DFU naming

DFU parameters

FFW_TSRELATIONFORSYS_TSBASIC

DFUVIEW, DFU

3 Users User/password FFW_LICENSE CSM_USER, CSM_PASSWORD, CSM_ACCOUNT_STATUS

4 OPS matrix Lewandowski

Algorithm parameters and optimization

FORSYS_FSBASIC

FORSYS_OPSMTX

OPSMATRIX

5 History History data FORSYS_TSVEC HIST

6 Mean value changes

Mean value adjustment

FORSYS_MEANCHG MEANVALUEADJ

7 DDEs Data driven events

FORSYS_SEPRCNTFORSYS_TSSEPRCNT

DDEPROFILE

DFUDDEMAP

8 Forecast modifications

Forecast locks FORSYS_TSFCMOD FCST or FCSTDRAFT

9 Seasonality Lewandowski Seasonality

FORSYS_TSVEC SMOOTHSEASON

10 Judgment events

Forecast overrides

FORSYS_TSSEABS FCST or FCSTDRAFT

11 Reconciliation models

Reconcile process FFW_NOMO_HEADFFW_NOMO_POS

MAP, MAP_PROFILE, MAP_PROFILE_DATA, and DFUMAPGEN_LINK

12 Data selections

Search criteria FFW_SELDEF FILT, FILTTEST, and HIERARCHICAL_FILT_

VALUE

13 Life Cycle and Linear Causal Factors

Lifecycles and Linear Causal Factors

FORSYS_TSXSEASON and FORSYS_XSEASON

LEWFACTOR, LEWFACTORVALUE, and LEWANDOWSKIPARAM (lifecycle and causal factor descriptions are migrated into the LewFactor name field). Nonlinear Causal Factors are not migrated.



Step Data type Description DPEE tables SCPO tables

14 Time phased conversion factors (TPCF)

Price profile FORSYS_TSPLAN

FORSYS_TSBASIC

PRICEPROFILE and PRICEPROFILEVAL

DFUVIEW and DFU

15 Targets Target FORSYS_TSTARGET TARGET and TARGETDFUMAP

You control the DPEE data that is migrated by changing the value for the corresponding property from False to True in the "Migration operations" section of the properties file. If you set all properties to true before running MigrateDPEE, the migration process migrates all DPEE data in the order listed above. If the process encounters a fatal error in any step, it terminates and logs the error in a file. You must either correct the error and rerun the process or bypass that step in the process by setting its value to false in the properties file. Data that was migrated successfully in steps before the step in which the error occurred does not need to be processed again.

Note: If you choose to migrate portions of the data rather than all data at once, you must migrate hierarchies first, followed by DFUs. You can migrate the other types of data in any order or choose not to migrate them. Do not migrate hierarchy data more than once. Otherwise, the process completes with errors and you must delete duplicate data in SCPO. If you run the migration multiple times for the other types of data, the process skips or replaces records, as appropriate.

Pre-migration preparation This section describes activities that you must perform before running the migration process.

Prepare data • The DPEE and SCPO databases may be in different SIDs.

• At least three hierarchies must exist in the DPEE database. Three of the hierarchies must be able to be mapped to DmdUnit, DmdGroup, and Loc.

• The DTA utility must be installed or DTA's DFUMATCH table must be present in the DPEE schema. You must delete obsolete DFUs from the DFUMATCH table before migration.

• A valid model must be defined in the SCPO MODEL table. The model record must have algorithm = 4 (Lewandowski) and must have a valid history stream. This model is used to define all DFUs being moved from DPEE.

• A valid calendar must be defined in the SCPO database schema for each period in the DPEE database. The earliest date of each calendar must be at least as early as the first period of data in DPEE.

• Select the CODE, LNAME, or SNAME column from FFW_H_ENTRIES in DPEE to use as the hierarchy entry values in SCPO. Each of the values in this column must be unique in the hierarchy. The validation routine flags values that are not unique, so you can rename them through DPEE. If you choose to rename values, back up your DPEE database first. Optionally, you can choose to move one of the other two names into the DESCR column for the DmdUnit, DmdGroup, or Loc tables, and create a comment with the other.

• The values in FFW_H_ENTRIES may not contain the delimiter used for searches (SCPO database schema), DBPARAM.DELIMITERCHAR. You can correct this by changing the names in DPEE or by changing the SCPO delimiter character in SCPO.

• The lengths of values in FFW_H_ENTRIES may not be longer than the corresponding field in SCPO. See the DPEE Reference Guide and SCPO Online Expert for a description of field lengths.



Set up the properties file 1. Using a text editor, open <install_dir>\config\properties\DPEEMigration.properties and

specify appropriate values for the properties in the file. Replace variables and placeholders with values that are pertinent to your operation.

The values for some properties in DPEEMigration.properties must already exist in Security Manager. For example:

• The migrationUserName value must be defined in CSM_USER.

• The defaultUserRole values must be defined in CSM_ROLE.

• The defaultEnterpriseName value must be defined in CSM_ENTERPRISE.

Note: For help with configuring the file, see the comment lines in the file.

2. Save and exit DPEEMigration.properties.

Run the migration 1. Make sure the JDA Platform Server is running.


3. Change to directory <install_dir>\config\bin\scpoweb.

4. Run MigrateDPEE.cmd (Windows) or MigrateDPEE.sh (UNIX). Enter the following command:

MigrateDPEE

The MigrateDPEE command takes a single parameter. For example:

MigrateDPEE.cmd -credentials “credentials.properties”

Specify the full path and file name (“<path>credentials.properties”) in the command.

A validation routine checks the validity of the properties file and the schema and data in the two databases. If the validation fails, the errors are reported in a log file and the migration stops. Otherwise, the migration proceeds. The process displays the message "Ending DPEE Migration" when the migration is complete.

5. After the migration process completes, view the migration log files by navigating to the path specified by the "logDirectory" parameter in DPEEMigration.properties. The default path is <install_dir>\config\logs. The following files are produced:

• DPEEMigration.log: Lists the migration steps that were performed.

• DPEEMigrationError.log: Lists any errors that were reported by the validation or migration steps. These errors may not be fatal. For example, an attempt to migrate history for a DFU may generate a "collision" if the DFU already has history. Depending on the properties file "replaceData" parameter, the DFU may be skipped or the old history may be replaced by the migrated history. In either case, a record is written to DPEEMigrationError.log to identify the DFU and what was done.

Post-migration procedures The migration process is unable to convert all DPEE data for use by SCPO. Therefore, you must make the following changes manually after migration:

• The Data Selection migration creates unique names in the form DPEEXXXXXXXXXXX, where 'X' is a digit. The original DPEE name (which is too long for the SCPO field) is stored in the description field for the data selection. If you want to assign more meaningful names to data selections, you can do so at this time. All data selections are created as user data selections rather than public. The owning user is identified by the "userName" parameter in the properties file. If you want to change the owner or scope, you can use SCPO to do so at this time.



• Some of the data selections may no longer make sense. For example, if one dimension of a data selection refers to an entry that no longer exists in DPEE, that dimension is omitted in SCPO. Therefore, the data selection is not usable, so it should be deleted.

• The Reconciliation model migration creates unique MAP names in the form MAPXXXXXXXXXXX, where 'X' is a digit. The original DPEE name is stored in the MAP description field. If you want to rename the MAP names, do so now. The data selection used for the map generation (found in the DFUMAPGEN_LINK table, ASSOC_SEARCH, SEARCH_FILTSCOPE, and SEARCH_USERID columns) is a dummy value because DPEE reconciliation models do not have an associated data selection. Replace those data selections with valid ones. After that is done, you can run DFUMapGenerate on the migrated maps. However, run this process on a few maps at a time to avoid running out of connection pools.

• In the Security Manager, adjust the roles and other information for any users created by the migration.

• Calculate the forecast and run reconciliation, where appropriate, for any DFUs that have been migrated. Forecast data is not migrated.

Disable the DPEE migration component After you have completed the DPEE to SCPO migration process, you should disable the DPEE migration component.

For IBM WebSphere:

1. Using a text editor, open <install_dir>\config\bin\scpoweb\deleteDPEEConnectionPool.ksh (deleteDPEEConnectionPool.cmd), then update the values for WEBWORKS_HOME and PATH.

Note: If you are running the application server (IBM WebSphere) in a clustered environment using an RAC (Real Application Cluster) SID, update the values for SERVER_HOST_NAME and SERVER_SOAP_PORT, as below:

SERVER_HOST_NAME = <DEPLOYMENT_MANAGER_HOST_NAME>

SERVER_SOAP_PORT = <DEPLOYMENT_MANAGER_SOAP_PORT>

Replace the text in < > with the appropriate information.

2. Run <install_dir>\config\bin\scpoweb\deleteDPEEConnectionPool.ksh (deleteDPEEConnectionPool.cmd) to delete the connection pool created for migration using the following syntax:

deleteDPEEConnectionPool.ksh (deleteDPEEConnectionPool.cmd) <admin_user> <admin_password> <db_host> <db_port> <db_sid> <db_username> <db_password>

Note: If you are running the application server (IBM WebSphere) in a clustered environment using an RAC (Real Application Cluster) SID, run <Install_dir>\config\bin\scpoweb\deleteDPEEConnectionPool_ND.ksh (deleteDPEEConnectionPool_ND.cmd) using the following syntax:

deleteDPEEConnectionPool_ND.cmd <admin_user> <admin_password> <nodeName>

3. Restart the JDA Platform server after deleting the connection pool.

For Oracle WebLogic:

1. Using a text editor, open <install_dir>\config\bin\scpoweb\DisableDPEEMigration.cmd (DisableDPEEMigration.sh), then update the values for BEA_HOME and WEBWORKS_HOME.

2. Open <install_dir>\config\bin\scpoweb\deleteDPEEConnectionPool.py, then update the values for the following variables.

# Weblogic server details



SERVER_HOST_NAME = "<SERVER HOSTNAME>"

SERVER_STANDARD_PORT = "<SERVER PORT NUMBER>"

WEBWORKS_HOME = "<WEBWORKS HOME>"

For example:

SERVER_STANDARD_PORT = "7001"

3. Run the command to disable DPEE migration:

a. Start the web_server.

b. Open a command_line prompt.

c. Change to directory <install_dir>\config\bin\scpoweb

d. Enter the following command:

DisableDPEEMigration.cmd

Note: Use the following command on UNIX:

DisableDPEEMigration.sh


Migrate from JDA Strategy 6.2 to SCPO 8.1 - UNIX or Windows This section describes procedures for migrating data from a JDA Strategy version 6.2 object-oriented database to a new SCPO version 8.1 Oracle relational database (MD_CONFIG.LEVELNUM = 93). If you need to upgrade and migrate your database from an earlier version of Production and Sourcing Optimization, contact JDA Customer Support Solutions for assistance.

Before you can migrate your Production and Sourcing Optimization database, you must create the SCPO version 8.1 database. In addition, JDA Platform version 8.1 must be installed and the JDA Foundation 8.1 schema must already exist. See the JDA Platform Installation/Administration Guide.

Note: You must migrate the Strategy 6.2 data into an empty SCPO database using the procedures in this chapter. If you already have a SCPO database that contains data for another JDA application, such as JDA Fulfillment, migrate that database to version 8.1. See Migrate the SCPO schema from 5.4, 6.x, or 7.1.x to 7.2 - UNIX (on page 33), "Migrate the SCPO schema from 5.4, 6.x, or 7.1.x to 7.2 - Windows" (on page 44), or "Migrate the SCPO schema from 7.2.x, 7.3.x, 7.4.x- UNIX or Windows (on page 54). Use a method such as the Oracle Merge feature to merge the records from both databases into a single 8.1 SCPO database.

Caution: This procedure is very complicated and could potentially corrupt your database. It should be performed by an experienced DBA with the assistance of a JDA Technical Consulting representative.

Migration considerations This section describes information to consider when migrating from JDA Strategy version 6.2 to SCPO version 8.1:

Components that are not migrated The following JDA Production and Sourcing Optimization components are not migrated from 6.2 to 8.1:

• Scenarios

• Data selections

• Fixed costs

After migration, recreate the desired scenarios and data selections using the SCPO application. Fixed costs are not supported in Production and Sourcing Optimization 8.1.



Work with tiered costs In JDA Strategy version 6.2, users specified the accumulation period for a tiered cost by selecting a period type and the number of accumulation periods. For example, if a user specified monthly for the period type and 6 for the number of accumulation periods, Strategy tracked the quantity purchased or utilized over 6 months, and selected the appropriate cost/price tier (volume discount) to use for each month.

In SCPO version 8.1, users accomplish this task by selecting an accumulation calendar to use for the tiered cost. The calendar has a DURTYPE column (minutes, hours, days, weeks, months, quarters, years), DUR column (integer number of accumulation periods), and REPEATTIMES column (number of times to repeat the period). For example, a weekly calendar for one year would be:

DURTYPE=4 (weekly)

DUR=1 (one week per period)

REPEATTIMES=52 (52 periods in one year)

The JDA Strategy migration process automatically generates a calendar from the 6.2 data and sets the accumulation calendar appropriately. However, the 6.2 data model does not have a corresponding value for REPEATTIMES. Therefore, the migration process assigns a default value for REPEATTIMES to the migrated data based on DURTYPE. The following table shows the default values in the SCPO 8.1 database:

6.2 DURTYPE value 8.1 REPEATTIMES value

Days 365/DUR (rounded down to the nearest integer)

Weeks 52

Months 60

Quarters 20

Years 5

To extend the calendar beyond the default value in the REPEATTIMES column or shorten it to improve performance, use the application pages to edit the values in this column after migration.

Another difference between JDA Strategy version 6.2 and SCPO 8.1 is that a tier in a tiered cost can be closed in 8.1. This functionality was not available in JDA Strategy version 6.2. Instead, to signify that a tier was closed, users assigned an extremely high batch cost (by convention, any value over $1 billion) to the tier. Therefore, the migration process treats tiers with a $1 billion or higher batch cost as closed and sets the batch cost to $0 and the value for CLOSEDSW to 1.

Strategy 6.2 migration process overview 1. Back up the existing JDA Strategy 6.2 database. See the Installation/Administration Guide for JDA

Scheduling and Strategy version 6.2.

2. Set up the application environment. Upgrade the operating system and install the supported version of Oracle. See the JDA Platform Installation/Administration Guide and Preinstallation procedures.

3. Install the application server (Oracle WebLogic or IBM WebSphere) and JDA Platform version 8.1 on the server. See the JDA Platform Installation/Administration Guide.

4. Create a new Oracle UTF8 database instance with character set AL32UTF8 for the SCPO database. The JDA Foundation installation provides sample scripts.

If you did not use the JDA provided scripts to create your Oracle UTF8 database, verify that the database character set for your database is AL32UTF8. In addition, you must run a command against the database in which you will create your SCPO tablespaces.



SCPO date columns must include an hour and minute timestamp. The Oracle default date format does not include an hour and minute timestamp, so you must add the NLS_DATE_FORMAT setting to your environment before you create or access a SCPO database. The value must be RRRR-MM-DD-HH24:MI.

See the JDA Platform Installation/Administration Guide to create a new database or Prepare Oracle database for SCPO (on page 10) to prepare an existing UTF8 database for SCPO.

5. Create the JDA Foundation tablespace and user. See the JDA Platform Installation/Administration Guide.

6. Create the JDA Foundation 8.1 schema. See the JDA Platform Installation/Administration Guide.

7. Install SCPO version 8.1. See SCPO software installation.

8. Perform post-installation configuration tasks. See Post-installation configuration.

9. Create the SCPO tablespaces and user. See "Create a SCPO tablespace and user (on page 11)".

10. Create the SCPO schema. The SCPO database must exist at level 88. See "Create the SCPO database schema (on page 25)".

11. To increase the speed of migration, run the Oracle utility dbms_stats.gather_database_stats on the server. This utility gathers database optimizer statistics for all database objects. See "Pre-migration preparation (on page 89)".

12. Export all required data from the Strategy 6.2 database into the native Strategy 6.2 Export format using the 6.2 Strategy Export procedure. See the Reference Guide for JDA Strategy version 6.2.

13. Run the Strategy 7.2.x Migration Utility on the application server. See Migrate your Strategy 6.2 database (on page 89).

14. Rerun dbms_stats.gather_database_stats on the server to optimize application performance. See "Optimize the database post-migration (on page 91)".

15. If applicable, merge the records from your new Production and Sourcing Optimization 8.1 database with those from an existing SCPO database into a single 8.1 SCPO database. See Oracle documentation.

Caution: Perform this step only with the assistance of a JDA Technical Consulting representative.

16. Install the JDA Platform and SCPO service runtime environment (SRE) components on a standalone JDA Platform SRE machine, as needed. See the JDA Platform Installation/Administration Guide and Install SCPO SRE (on page 18).

17. Configure the JDA Platform service runtime environment for SCPO processes. See "Configure the environment (on page 98)".

18. Configure the SCPO application. If you plan to allow JDA Strategy users to use scenarios and commit them to the database, you must add referential integrity constraints on the scenario (SIM_) tables. See "Configure the SCPO application" and "Enable JDA Production and Sourcing Optimization users to commit scenarios".

19. Customize the SCPO database. See "Customize and maintain the database".

20. Define security objects for SCPO. See "Implement security".

21. Prepare the SCPO database for data import, then load data into the database. See "Import data (on page 117)".

22. Install the JDA Platform SRE and the JDA Production and Sourcing Optimization client software on one or more computers. See the JDA Platform Installation/Administration Guide "Install JDA Production and Sourcing Optimization (on page 23)".

23. Configure the JDA server (configureJDAServer). See the JDA Platform Installation/Administration Guide.

24. Start the JDA Platform Server. See "Access SCPO (on page 97)".



Pre-migration preparation After you create the empty SCPO schema, using SQL*Plus, run gather_db_stats.sql as the Oracle system user for SCPO schemas using the following syntax:



Migrate the Strategy 6.2 database SCPO version 7.2.x provides a migration utility for JDA Strategy, <install_dir>\config\bin\scpoweb\StrategyMigration.cmd, which reads the Strategy 6.2 export format and inserts the data into the 8.1 SCPO relational database.

Before you run the migration utility, ensure that you have completed installation and configuration steps 1 through 11 in " Strategy 6.2 migration process overview". Perform step 12 to export all required data from the 6.2 Strategy database into the native Strategy 6.2 Export format using the 6.2 Strategy Export Procedure. See the Reference Guide for JDA Strategy 6.2 for instructions on exporting data.

After you have exported the Strategy 6.2 data, run the Strategy 7.2.x Migration Utility from the server. The utility reads the 6.2 Strategy Export files and inserts the data into the 8.1 SCPO relational database. The utility appends errors and tracing information to the JDA Platform Server trace file, <install_dir>\config\logs\manu.log (or manu_n.log where n is the number of the logfile creation sequence; for example, manu_1.log).

Rules for running StrategyMigration Observe the following rules when you run the StrategyMigration utility:

• Never migrate Strategy 6.2 data into a database that contains existing data for another SCPO application. Doing so might cause the migration to fail if duplicate data exists (for example, the same SKU is defined in both JDA Fulfillment and the JDA Strategy 6.2 export file).

• When you run StrategyMigration, specify the unit of measure (UOM) parameters, inputFile parameter, or both.

• If you specify one UOM parameter, you must specify all of them.

• If you run StrategyMigration multiple times to resolve errors, do the following to avoid duplicate key errors:

• Specify the UOM parameters only for the first execution.

• Use the truncate parameter on subsequent executions to purge previously migrated data from the SCPO database before attempting to migrate the data again.

Format and parameters for StrategyMigration The command-line format for StrategyMigration is as follows:

StrategyMigrate [-umcategories <category_file> -umunits <units_file> -umratio <conversion_file> -delimiter <delimiter character>] [-truncate] <inputFile>

• umcategories <category_file>: Name and location of the file containing custom (user-defined) categories of units of measure. For example, <install_dir>\manuv62\resource\umcategoriesen.txt.

• umunits <units_file>: Name and location of the file containing custom (user-defined) units of measure. For example, <install_dir>\manuv62\resource\umunitsen.txt.

• umratio <conversion_file>: Name and location of the file containing custom (user-defined) conversions between different units of measure. For example, <install_dir>\manuv62\resource\umratiosen.txt.



Note: The migration process may generate an error if the 6.2 export file uses UOM conversions and you do not migrate conversions.

• delimiter <delimiter character>: Name of the command line option for the StrategyMigration command that indicates whether a comma is assumed to be the delimiter. If the value for this option is not set, a comma is assumed. Otherwise, this option supports all Strategy 6.2 characters except the # symbol, which is reserved for comments.

• truncate: Deletes existing data in the SCPO database before migrating Strategy 6.2 data, with the exception of user-defined units of measure and process options. You must delete migrated UOM data from the 8.1 SCPO database manually (for example, using SQL*PLUS), if you subsequently modify the UOM files and want to remigrate them into the SCPO database. Otherwise, the migration process may generate duplicate key errors.

This parameter is not required the first time you run StrategyMigrate. If the migration utility finishes with errors, use this parameter on subsequent executions to purge previously migrated data from the SCPO database before attempting to migrate the data again. Otherwise, the migration process may generate duplicate key errors.

• <inputFile>: Name and location of the import file that contains the Strategy 6.2 data. This name corresponds to the name of the output file that you specified when you exported the data from Strategy 6.2. For example, <install_dir>\manuv62\scnams\impexp\myoutputfile.txt.

Run the StrategyMigration utility After you export all required data from the 6.2 Strategy database using the 6.2 Strategy Export Procedure, run the StrategyMigration utility to insert the data into the 8.1 SCPO relational database.

1. On the application server, open a command prompt window.

2. Change to directory <install_dir>\config\bin\scpoweb and enter:

StrategyMigration.cmd

followed by either the unit of measure parameters, the <inputFile>, or both.

For example:

StrategyMigration.cmd -umcategories <install_dir>\manuv62\resource\umcategoriesen.txt -umunits <install_dir>\manuv62\resource\umunitsen.txt -umratio <install_dir>\manuv62\resource\umratiosen.txt -truncate <install_dir>\manuv62\scnams\impexp\myinputfile.txt

Replace en in the file names with the correct language characters. See "Format and parameters for StrategyMigration" for a description of valid parameters.

3. When the migration utility completes, it appends data to the JDA Platform Server trace file, <install_dir>\config\logs\manu.log (or manu_n.log). Review the log file for errors.

4. If the migration utility finishes with errors, review and correct any errors in the 6.2 export file. Rerun the utility using the truncate parameter. Repeat this step until the utility completes with no errors. See Sample output (on page 90).

Sample output The following sample output is displayed when StrategyMigration runs successfully.

Creating NamedCalendars 0.1 seconds

Creating Tiered Cost Prices 0.1 seconds

Creating Items 0.1 seconds

First SourcingGroup pass Inserted 1 SourcingGroup(s). 0.0 seconds

Reading Locations 0.1 seconds

Creating Lanes 0.0 seconds



First SKU pass Inserted 63 SKUs. 0.0 seconds

Creating Make Processes Read 6 Make Processes. 0.0 seconds

Second SKU pass Updated 63 SKUs. 1.7 seconds

Creating Reusable Resources

Inserted 50 Resources. 0.3 seconds

Creating Purchase Processes Read 76 Sourcing records. 0.2 seconds

Creating Move Processes Read 13 Sourcing records. 0.0 seconds

Creating Resource Requirements Read 153 Resource Requirement records. 0.2 seconds

Creating SKURequirements 1.5 seconds

Second SourcingGroup pass Updated 1 SourcingGroup(s). 0.0 seconds

--------

Total 4.5 seconds

Process terminated with exit code 0

When StrategyMigration fails, it writes an exception to the terminal and to the log file.

Optimize the database post-migration After the Strategy migration utility has completed successfully, rerun dbms_stats.gather_database_stats on the server to optimize application performance.

Add subcomponents When you install SCPO, the system configures the application and database to use the components enabled by the configuration code you specified during installation. After you have completed the 8.1 migration, you can install additional components more easily because you have the full database schema.

Migrate Compressed Data Storage (CDS) This section provides detailed instructions on how to enable and configure the Compressed Data Storage for SCPO 8.1.0.0.

Before you begin enabling Compressed Data Storage This section describes activities that you must perform before enabling CDS.

If you want to enable CDS, validate the existing data before running the enable script. This validation identifies the data conditions that are incompatible with CDS.

Notes:

• While post migrating to 8.1.0.0 if CDS is enabled, then DFUTOSKUFCST is also be enabled for CDS. DFUTOSKUFCST PERIODS is same as FCST PERIODS.

• You can configure the DFUTOSKUFCST PERIODS using configure_compressed_data_storage.bat or configure_compressed_data_storage.ksh. DFUTOSKUFCST PERIODS must always be less than or equal to FCST PERIODS.

Validating the existing data After you have installed JDA Platform and SCPO, perform the following steps to validate the existing data:

1. In the <install_dir>\config\database\scpoweb directory, run this script as the Oracle system user:



pre_enable_compressed_data_storage wwfuser wwfpassword

Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password.

For example:

UNIX:

pre_enable_compressed_data_storage.ksh wwfmgr wwfmgr

Windows:

pre_enable_compressed_data_storage wwfmgr wwfmgr

This script validates the existing data and checks for any records that should be removed or updated before enabling compressed data storage.

2. Check the log file pre_enable_compressed_data_storage.log for any records that should be removed or updated.

Alerts for pre_enable_compressed_data_storage The following is the message list:

Searches may not be defined against FCST, FCSTDRAFT, HIST OR DFUTOSKUFCST when WIDE tables are enabled.

This means the primary table for the search may not be FCST, FCSTDRAFT, HIST or DFUTOSKUFCST.

Additionally, no searches may contain criteria based on FCST, FCSTDRAFT, HIST or DFUTOSKUFCST.

The following searches currently have FCST, FCSTDRAFT, HIST or DFUTOSKUFCST as the primary table.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

The following searches currently have criteria based on the FCST, FCSTDRAFT, HIST or DFUTOSKUFCST tables.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

CSM_FILTER_CRITERIA entries may not be used on the STARTDATE, DUR or QTY columns of FCST, FCSTDRAFT, HIST.

The following security filters in the CSM_FILTERS table have criteria based on STARTDATE, DUR or QTY.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

CSM_FILTER_CRITERIA entries may not be used on the DUR or TOTFCST columns of DFUTOSKUFCST.

The following security filters in the CSM_FILTERS table have criteria based on DUR OR TOTFCST.



----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

UDCS may not be added to WIDE tables.

The following columns are UDCS on a table that will become wide.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Expressions may not be used on the STARTDATE, DUR or QTY columns for WIDE tables in Flexible Editor.

The following Flexible Editor pages have expressions based on STARTDATE, DUR or QTY columns.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Expressions may not be used on the DUR, TOTFCST columns for COMPRESSED DATA STORAGE tables in Flexible Editor.

The following Flexible Editor pages have expressions based on DUR or TOTFCST columns.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Static filters may not be used on the STARTDATE, DUR or QTY columns for WIDE tables in Flexible Editor.

The following Flexible Editor pages have static filters based on STARTDATE, DUR or QTY columns.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Static filters may not be used on the DUR or TOTFCST columns for COMPRESSED DATA STORAGE tables in Flexible Editor.

The following Flexible Editor pages have static filters based on DUR or TOTFCST columns.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Paging may not be used on the STARTDATE, DUR or QTY columns for WIDE tables in Flexible Editor.



The following Flexible Editor pages have STARTDATE, DUR or QTY columns marked as paged.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Paging may not be used on the DUR or TOTFCST columns for COMPRESSED DATA STORAGE tables in Flexible Editor.

The following Flexible Editor pages have DUR or TOTFCST columns marked as paged

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

WIDE tables may not be mixed in the same Flexible Editor userview.

The following Flexible Editor instances have columns from multiple WIDE tables.

----------------------------------------------------------------------------------

<<LIST>>

----------------------------------------------------------------------------------

Commit the changes if anything listed above is updated or deleted.

If there are no records listed above, you may proceed with enabling CDS; otherwise proceed with enabling compressed data storage only after resolving the issues above.

Enable and configure CDS This section describes activities that you must perform to enable and configure CDS.

Enable CDS After you have run the pre_enable_compressed_data_storage script, perform the following steps to enable the CDS feature.

1. In the <install_dir>\config\database\scpoweb directory, run this script as the JDA Foundation schema owner and the SCPO schema owner:

enable_compressed_data_storage scpouser scpopassword wwfuser wwfpassword forecast_periods history_periods dfutoskufcst_periods

Replace scpouser and scpopassword with the SCPO schema owner and password. Replace wwfuser and wwfpassword with the JDA Foundation schema owner and password.

For example:

UNIX:

enable_compressed_data_storage.ksh scpomgr scpomgr wwfmgr wwfmgr 52 104 52

Windows:

enable_compressed_data_storage.bat scpomgr scpomgr wwfmgr wwfmgr 52 104 52



This script creates CDS tables (wide and narrow tables) for forecast, history, and DFUToSKUFcst with specified periods. This script also cleans up the type 1 and reconcile records in the forecast table by adjusting their quantity with the quantity of type 3.

Notes:

• The number of periods for CDS tables should be between 1 and 980. You have to explicitly enter the values for the number of periods.

• DFUTOSKUFCST PERIODS must be equal to or less than FCST PERIODS.

2. Check the enable_compressed_data_storage.log log file for any errors.

3. Run enroll_app_schema.sql.

In the <install_dir>\config\database\platform directory, run this script as the Oracle system user. For example:

sqlplus system/manager @enroll_app_schema.sql scpouser

Replace <scpouser> with the SCPO schema owner. The script sets up application schema permissions as well as permissions between the application schema, and the JDA Foundation schema and related objects. The script also creates enroll_app_schema.log.

Data Manipulations during Migration The enable script moves all non-type 1 and non-reconcile records to narrow tables and truncates the Fcst/FcstDraft tables. It updates the metadata to mark the database as CDS enabled. The metadata for table relationships are not created using this script. The application replicates the relationship records available in the Fcst/Hist/FcstDraft/DFUToSKUFcst tables for the wide and narrow tables at runtime. When this script is run, there will not be any Type1 and reconcile records in the FCST or FCSTDRAFT CDS tables. You need to run the Calculate Model and Reconcile processes in order to repopulate the Type 1 and reconcile records with type 3 being adjusted. Similarly, you must run the Transfer Forecast process to update the correct data into the DFUToSKUFcst table.

Note: In a typical client environment, the Type 1 and reconcile records constitute more than 80% of the table. Therefore, this process will remove most of the records in the Forecast tables.

Configuring CDS You can configure compressed data storage tables only if compressed data storage tables are already enabled with the enable_compressed_data_storage script. You can increase or decrease the number of periods for History, Forecast, and/or DFUToSKUFcst tables using the configure_compressed_data_storage script.

After you have run the enable_compressed_data_storage script, perform the following steps to configure the data in compressed data storage tables.


configure_compressed_data_storage scpouser scpopassword wwfuser wwfpassword option periods table

Replace <scpouser> and <scpopassword> with the SCPO schema owner and password. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password.

For example:

UNIX:

configure_compressed_data_storage.ksh scpomgr scpomgr wwfmgr wwfmgr add 10 history

configure_compressed_data_storage.ksh scpomgr scpomgr wwfmgr wwfmgr trim 10 forecast

configure_compressed_data_storage.ksh scpomgr scpomgr wwfmgr wwfmgr trim 10 dfutoskufcst



Windows:

configure_compressed_data_storage.bat scpomgr scpomgr wwfmgr wwfmgr add 10 forecast

configure_compressed_data_storage.bat scpomgr scpomgr wwfmgr wwfmgr add 10 history

configure_compressed_data_storage.bat scpomgr scpomgr wwfmgr wwfmgr trim 10 dfutoskufcst

This script adds or removes the specified periods to/from the forecast, history, and DFUToSKUFcst compressed data storage tables.

Notes:

• The number of periods to be added/ removed to/from compressed data storage tables should be between 1 and 980.

• While adding or trimming, DFUTOSKUFCST must be less than or equal to FCST PERIODS.

2. Check the configure_ compressed_data_storage.log log file for any errors.

Caution: Dropping the columns would lead to potential permanent data loss. While truncating the data from History tables, the most recent data may get dropped. This should be used with extreme caution.

Disable CDS You can run disable Compressed Data Storage only if compressed data storage tables are enabled that is, if the enable_compressed_data_storage script is already run.


disable_compressed_data_storage scpouser scpopassword wwfuser wwfpassword

Replace <scpouser> and <scpopassword> with the SCPO schema owner and password. Replace <wwfuser> and <wwfpassword> with the JDA Foundation schema owner and password.

For example:

UNIX:

disable_compressed_data_storage.ksh scpomgr scpomgr wwfmgr wwfmgr

Windows:

disable_compressed_data_storage.bat scpomgr scpomgr wwfmgr wwfmgr

This script disables compressed data storage tables by dropping the wide and narrow tables for forecast and history.

2. Check the log file disable_ compressed_data_storage.log for any errors.

Caution: Disabling the CDS tables leads to permanent data loss of the forecast and history tables. You must run the Merge Forecast process to preserve the data in the Fcst/FcstDraft tables before disabling CDS. Similarly, you must run the Transfer Forecast process to preserve the data in the DFUToSKUFcst table.

Deploy Replenishment Workbench for JDA Enterprise Supply Planning, JDA Fulfillment, and JDA Master Planning The Replenishment Workbench instances appear on the directory listing. For information on Deploying the Replenishment Workbench, see ".NET UI Framework Installation and Deployment" in the JDA Platform Installation/Administration Guide. If you have not deployed Replenishment Workbench and if you try to open the instance from the directory listing, error occurs.

Note: You need to install .NET on your system to use Replenishment Workbench. See JDA Platform Release Notes for the supported .NET version.

Migration of Plan Analysis instances to the Replenishment Workbench JDA Supply Chain Planning and Optimization Installation/Administration Guide 96 © 1997-2014 JDA Software Group, Inc.- Confidential


To create new Replenishment Workbench instances based on existing Plan Analysis instances, run the migrate_pa_to_replwb.bat script:

1. Specify the Oracle_SID.

2. Set the Oracle bin path.

3. In the <install_dir>\config\database\scpoweb directory, using SQL*Plus, run migrate_pa_to_replwb.ksh (UNIX) or migrate_pa_to_replwb.bat (Windows) script as the JDA Foundation schema owner using the following syntax:

UNIX:

migrate_pa_to_replwb.ksh <wwfuser> <wwfpassword>

Windows:

migrate_pa_to_replwb.bat <wwfuser> <wwfpassword>

This script creates new Replenishment Workbench instances with the name of the Plan Analysis instance with the suffix “– Repl Wb”. You can either migrate properties, if possible, or use the default values in Replenishment Workbench instances. In Plan Analysis, the TargetSKU tab properties are migrated to Replenishment Workbench instance properties.

Note: Make sure you run this script only after you have completed migrating the database to 8.1.

Add subcomponents When you install SCPO, the system configures the application and database to use the components enabled by the configuration code you specified during installation.

Access SCPO 1. Start the JDA Platform Server. Refer the instructions in the JDA Platform

Installation/Administartion Guide.

2. Type the address and port of the server into the address/location field of a browser window in the following format:

http://<computername>:<portnumber>

Note that a colon (:) separates the <computername> and <portnumber>. For example, if the JDA Platform Server name is nwserver and the listener port is 7001, enter the following:

http://nwserver:7001

In some cases, the fully-qualified domain may be necessary depending on the network configuration. For example,

http://nwserver.domain.com:7001

Contact your administrator if you do not know the name of your JDA Platform Server and its port.

3. In the JDA Solutions login page, enter the following:

• Your user name

• Your password

These entries are case-sensitive.

4. Click Log in. The Homepage is displayed with available options. If the login failed, re-enter the information. Contact your JDA administrator if you do not have the correct login information.

5. Use the Navigation Pane to navigate to pages in the SCPO applications.

If users experience unexpected behavior when they attempt to access SCPO, open the browser and clear the cache as follows:



1. In Internet Explorer, select Tools > Internet Options.

2. On the General tab, select Delete Cookies.

3. In the Delete Files window, select Delete all offline content and click OK to confirm the deletion.

Note: The configuration code controls applications that are installed, and therefore determines which database tables can be used. In Flexible Editor, users can view database tables common to all installed applications; however, users can enter data only in those tables for which they are licensed. An example is the DFU table for Fulfillment users. While the DFU table displays, Fulfillment-only users cannot access this table. This behavior is normal.

Configure application server After the setup program has finished installing the software on your computer, complete the following post installation configuration tasks.

Additional, application-specific configuration may be required following database initiation or migration. See Configure the SCPO application.

The information in this section is unique to SCPO. If you need additional information on configuring the JDA Platform Server, see the JDA Platform Installation/Administration Guide.

Configure the environment - UNIX Before starting the server on UNIX, you may need to edit the .profile of the SCPO user to include the following environment variables:

• LANG: Used to specify the locale. The locale must be installed on the UNIX platform. Type locale -a to list available locales. For example, to set a locale United States,enter: export LANG=en_US.ISO8859-1.

• LC_ALL:Used to set all locale-related environment variables, LC_*. For example,export LC_ALL=en_US.ISO8859-1.

Required only on Solaris systems. On all other SCPO platforms, LANG sets these variables.

• TNS_ADMIN: Path to the tnsnames.ora file. This setting is necessary if running the SCPO database scripts against a remote database server. For example,export TNS_ADMIN=$ORACLE_HOME/network/admin.

Configure the server SCPO provides configuration files that let you modify certain settings for your environment. The primary configuration file is scpo_config.xml, which can be edited using system properties in the user interface. However, some JDA applications use additional configuration files. See Configure the SCPO application for a description of these files and for procedures on editing the scpo_config.xml or editing properties in the System Properties.

Note that properties defined in the scpo_config.xml are relevant to the application server. Hints for algorithms should be specified in the sre_node_config_props table for the particular algorithm.

Most properties contain default values. Some properties contain values that are set during installation. Other properties require that you edit the file and set the appropriate values.

Configure the environment - SRE This chapter describes how to deploy SCPO processes in a JDA Platform service runtime environment (SRE). SRE provides parallel execution and distribution of JDA application processes on the JDA Platform Server or on standalone JDA Platform SRE machines. Processes are launched using command-line batch requests or the Web-enabled interface. See the JDA Platform Installation/Administration Guide for detailed instructions on configuring your environment to use SRE. JDA Supply Chain Planning and Optimization Installation/Administration Guide 98 © 1997-2014 JDA Software Group, Inc.- Confidential


How SCPO uses SRE SCPO uses the SRE framework provided by JDA Platform to launch processes such as algorithms. Installing JDA Platform automatically installs the SRE framework on the JDA Platform Server.

JDA Platform and SCPO also provide a thin installation for SRE, intended for a standalone machine. Ensure that the JDA Platform SRE machines are in the same network as the JDA Platform Server and database server. See the JDA Platform Installation/Administration Guide on how to install the JDA Platform SRE and Install SCPO SRE (on page 18) to install the SCPO SRE component.

Modify the default configuration for processes Configuration settings for SRE are maintained in a set of database tables in the JDA Foundation schema. These tables have the format SRE_<table_name>. SCPO loads default data for each valid process into these tables during the database creation or migration process. The settings specify where and how SCPO processes are to run. For example, you can configure a process to run only on a particular machine or you can distribute the processing load across multiple machines. See the JDA Platform Installation/Administration Guide for a description of the SRE database tables.

The standard JDA Platform installation process creates a default node pool called Basic on the JDA Platform Server. All SCPO processes are initially associated with this node pool. However, to achieve optimum performance, you may want to create additional node pools and reassign processes to the new pools. For example, the memory requirements for some SCPO processes exceed the default values provided in the node pool Basic. See Configure SRE for SCPO processes (on page 114) for details. The new node pools should be on a different machine from the JDA Platform Server. See the JDA Platform Installation/Administration Guide for procedures on creating and configuring node pools.

Note: The installation and migration procedures for SCPO applications assume that a node pool named 'Basic' exists. Therefore, do not delete this node pool. In addition, rather than modify the node pool Basic, you should create and modify additional node pools for use in your environment.

Caution: It is critical that you tune the default connection pool settings and SRE defaults to run properly in your environment. Contact JDA Support Services for assistance in determining the proper settings for your environment.

Deploy SCPO processes Each SCPO application provides predefined processes that are defined in the SRE tables in the JDA Foundation schema. Users can run these processes by using the Process pages in the GUI or using the JDA Platform SREBatchUtility command with an input process request XML file. Specific options are available for each process. See the JDA application online help for a description of process options and Run batch processes (on page 136) for procedures on running SCPO processes using the SREBatchUtility.

You can run SCPO processes on the JDA Platform Server as well as any standalone machine in the network that is configured with the JDA Platform and SCPO SRE components.

Continuous Jobs Some SCPO processes run as background processes; for example, Demand.CalcModelRMI. Processes that run in this mode are called continuous jobs. These jobs are always running rather than starting only when they receive an SRE job request. They exist to process single-entity job requests; for example, a single DFU or SKU. The system assigns continuous jobs when the node pool managers are started. Similar to other SCPO processes, continuous jobs are configured by default to run using node pool Basic. When you create or migrate your SCPO database, the size of node pool Basic is automatically incremented to handle these jobs. See the JDA Platform Installation/Administration Guide to determine whether a job is continuous or to stop a continuous job.

Note: Continuous jobs require that the JDA Platform Server be running. Otherwise, the jobs will not start successfully.



Multi-action Jobs Other SCPO processes divide their jobs into units of work, or actions, that can be processed concurrently. These processes have additional configuration parameters such as queue size and number of threads. Setting these parameters requires advanced configuration knowledge and is beyond the scope of this guide. Contact JDA Support Services for assistance.

SCPO Process Details Use the following SRE definitions when referring to individual SRE processes listed in the Supported configuration for SCPO processes table.

• Process Name: Name of the SRE process. The names are predefined by applications and stored in the JDA Foundation schema. You cannot create new SRE processes.

• Batch: Indicates the process can be invoked using SREBatchUtility. Some processes are internal meaning that a user cannot invoke them. Rather, the system runs it as a background process.

• Actions: Units of work. All SCPO processes use job actions. An action represents a subset of data for a job. Processes are either single or multi-action. A single-action process is run in a serial manner. Multi-action processes can be run in a parallel manner.

• S indicates a single-action job.

• M indicates a multi-action job.

• Pipelined: A process that is multi-action and multi-threaded, so that the execution of one action can overlap another are called pipelined jobs. Some SCPO processes are pipelined. A pipelined process generally requires more resources (memory, CPU, and database connections). The benefit is that pipelining is faster and therefore allows more jobs to run. You cannot enable (or disable) pipelining because the feature is inherent to the process.

- Indicates a pipelined process.

• T indicates a tunable pipelined process.

• S indicates a self-tuning pipelined process.

• Continuous: Processes that run as background processes are called continuous jobs. The system assigns continuous jobs when the node pool managers are started.

- Indicates a continuous type of process.

• Stored procedures: Code that primarily runs on the database server is stored procedure. Some processes use database stored procedures. For processes that use stored procedures, you may be able to tune the database server to optimize the process.

Note: Processes that use stored procedures cannot be canceled from the Process Status page after they are started.

- Indicates the process uses stored procedures.

XML request file

Use a process request XML with SREBatchUtility to request jobs. The XML schema is largely the same for all SCPO processes. However, not all processes use the following attributes.

• SimulationName:Indicates whether the process uses the simulationName attribute in the process request XML file.

- Indicates you can use simulationName.

• SearchName: Indicates whether the process uses the searchName attribute in the process request XML file. Specify the name of a valid search in the XML file using this attribute. Users create searches, which are table-based, using the application user interface. You can identify the primary table used in a search using VP_CATALOG_LISTING.PRIMARY_TABLE.

- Indicates you can use searchName.



A blank in this column indicates that the process does not use a search.

• Prompt: Indicates whether the process uses element prompt in the process request XML file.

- Indicates you can use prompt.

• ActionGroupSetName: Indicates whether the process uses the actionGroupSetName element in jobOptions.

- Indicates you can use actionGroupSetName.

• SRE Diagnostics: Indicates whether the process uses the SRE Diagnostics element.

- Indicates you can implement SRE Diagnostics.

• SRE Job Restart: Indicates whether the process uses job restart after action failure.

- Indicates you can use SRE Job Restart.

The following table lists all available SRE-based SCPO processes. An SRE service name consists of the application name followed by the process name. For example, the service name for the JDA Demand Delete Forecast process is Demand.ForecastDelete. Processes that are shared across multiple applications have the prefix SCPOWEB or DRM. Use this table to configure and optimize processes in your SRE environment. For SRE process definition, see the previous section.

Supported configuration for SCPO processes

SRE service name Process name

Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

JDA Enterprise Supply Planning

ESP.GenerateMasterPlan.Map

Generate Master Plan (MAP)

M

ESP.GenerateMasterPlan.LpOpt

Generate Master Plan (LpOpt)

M

MasterPlanning.CampaignPlanner

Optimize Production Changeover

M

MasterPlanning.DeepTree

Calculate Master Plan

M

MasterPlanning.OrderPegging

Generate Supply and Demand Links

M

MasterPlanning.OrderPeggingWithPriority

Generate Supply and Demand Links with Priority

M




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

MasterPlanning.PublishCampaign

Publish Optimal Production Changeover

M

MasterPlanning.Rbo Calculate Rules Based Priority

S

MasterPlanning.RequirementPlan

Calculate Requirement Plan

M

MasterPlanning.SigmoidPriority

Calculate Sigmoid Priority

M

MasterPlanning.SSOrder

Generate Safety Stock Orders

M

SCPOWeb.CalculateNetFcstError

Calculate Net Forecast Error

M T

SCPOWeb.CalculateSeasonalityError

Calculate Seasonality Error

S

SCPOWeb.FcstOrder Generate Forecast Orders

M

SCPOWeb.FcstTransfer

Transfer Forecast

S

SCPOWeb.HistTransfer

Transfer History

S

SCPOWeb.InventoryManagement

Calculate Statistical Safety Stock

M T

SCPOWeb.LevelSKU Level SKUs S

SCPOWeb.ScheduledReceipts

Recommend Scheduled Receipts

S

SCPOWeb.SKUExceptionBuilder

Generate SKU Exceptions

S

SCPOWeb.StoreResProjections

Store Resource Projections

S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

SCPOWeb.StoreSKUProjections

Store SKU Projections

M T

SCPOWeb.SeqIntExport

Transfer Planned Orders

M

SCPOWeb.SeqIntImport

Import Scheduled Receipts

M

Demand Management Foundation

Demand.CalcModel Calculate Model

M S

Demand.DFUMapGenerate

Generate DFU Map

S T

Demand.DFUMapVerify

Verify DFU Maps

S T

Demand.ForecastDelete

Delete Forecast

M T

Demand.ForecastImport

Import Forecast

M T

Demand.MapDFUs Map DFUs M S

Demand.MapDFUSubset

Map DFUs Subset

M S

Demand.PublishForecast

Publish Forecast

M S

Demand.Reconcile Reconcile Forecast

M S

Demand.ReconcileDFUSubset

Reconcile Forecast Subset

M S

Demand.StoreDerivedTable

Store Derived Tables

M S

Demand.StoreForecast

Store Forecast

M S

Demand.DeleteDFUs Delete DFUs M T

Demand.CalculateE3Error

Calculate E3 Error

M T

Demand.SpiCollectionBuilder

Build Seasonal Profile Collection

M T




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

Demand.TransferProfile

Transfer Seasonality Profiles

M T

Demand.BuildShortLifecycleCurve

Build Short Lifecycle Curve

M S

Demand.AssignShortLifecycleCurve

Assign Short Lifecycle Curve

M S

Demand.BuildWFMData

Load Work Force Management DFUs

S

JDA Flowcasting

Fulfillment.GradeSKUs

Grade SKUs M S

SCPOWeb.IdentifyandAnalyzeRootCauses

Identify and Analyze Root Causes

M S

SCPOWeb.PublishDataForReports

Publish Data for Reports

M S

JDA Demand

Demand.AttachRate Calculate Historical Attach Rate

M S

Demand.CalcModel Calculate Model

M S

Demand.CalcModelRMI

Calculate Model Continuous Process

M

DemandClassification.ClassificationOptimization

Classify DFUs and Tune Parameters

M S

DemandClassification.CreateClassificationModel

Add/Update Models

M S

Demand.CleanseHistory

Cleanse History

M S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

Demand.CompressCausalFactor

Compress Causal Factor

S T

Demand.CopyMeasuredata

Copy Measure Data

M T

Demand.CompressOverride

Compress Override

S T

Demand.DeleteAttachRate

Delete Attach Rate Workflow

M T

Demand.DeleteHistory

Delete History

S T

Demand.DependentDemand

Calculate Dependent Demand

M S

Demand.DFUMapGenerate

Generate DFU Map

S T

Demand.DFUMapVerify

Verify DFU Maps

S T

Demand.ForecastDelete

Delete Forecast

M T

Demand.ForecastImport

Import Forecast

M T

Demand.MapDFUs Map DFUs M S

Demand.MapDFUSubset

Map DFUs Subset

M S

Demand.MoveHistory

Move History M S

Demand.MergeForecast

Merge Forecast

M S

Demand.PublishForecast

Publish Forecast

M S

Demand.Reconcile Reconcile Forecast

M S

Demand.ReconcileDFUSubset

Reconcile Forecast Subset

M S

Demand.StoreDerivedTable

Store Derived Tables

M S

Demand.StoreForecast

Store Forecast

M S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

Demand.DeleteDFUs Delete DFUs M T

Demand.CalculateE3Error

Calculate E3 Error

M T

Demand.SpiCollectionBuilder

Build Seasonal Profile Collection

M T

Demand.TransferProfile

Transfer Seasonality Profiles

M T

Demand.BuildShortLifecycleCurve

Build Short Lifecycle Curve

M S

Demand.AssignShortLifecycleCurve

Assign Short Lifecycle Curve

M S

Demand.NPIByPriority

NPI By Priority

M

Demand.ExpandCalendar

Expand calendar

S

Demand.BuildWFMData

Load Work Force Management DFUs

S

JDA Demand Decomposition

DRM.Actualization Calculate Actuals

M T

DRM.Aggregation Aggregate History

M

DRM.CalculateCrossProductWeights

Calculate Cross Product Weights

M T

DRM.Calibration Estimate Market Response Model

M T

DRM.CrossRelationGeneration

Generate Cross Product Relationship

M T




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

DRM.Decomposition Deseasonalize Estimation Inputs

M T

DRM.ExtendedFPA* Adjust Forecast For Pricing and Promotions

S

DRM.FPA Transfer Price Forecast

M T

DRM.HoldoutEvaluation

Evaluate Model Performance

M S

DRM.Normalization Adjust History or Pricing and Promotions

M S

DRM.PriceCoefficientPublisher

Publish Price Coefficients

S

DRM.PriceElasticityComputation

Compute Price Elasticity

M T

DRM.PricePointFcstGeneration

Generate Price Point Forecast

M T

DRM.PriceRatioComputation

Compute Price Ratios

M T

DRM.PriceSensitivityComputation

Compute Price Sensitivity

M T

DRM.ReferencePriceComputation

Compute Reference Prices

M T

JDA Dynamic Demand Response

DynamicDemandResponse.AdvFcst

Calculate Dynamic Demand Response

M T

DynamicDemandResponse.AllocCalDFU

Generate Allocation Calendars for DFUs

M T




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

DynamicDemandResponse.AllocCalSKU

Generate Allocation Calendars for SKUs

M T

JDA Fulfillment

Fulfillment.CPPCommit

CPP Workbench Commit

S

Fulfillment. DashboardRMI service

Replenishment Dashboard

Fulfillment.CPPLoad CPP Workbench Load

S

Fulfillment.LevelSKUWithSrch

Level SKUs with Search

M S

Fulfillment.LoadBuilder

Build Transportation Loads

M S

Fulfillment.LoadLeveler

Level Production Loads

S

Fulfillment.MaterialAllocation

Allocate Materials

M T

Fulfillment.OrderBuilder

Optimize Orders

M S

Fulfillment.OrderBuilderRMI

Optimize Orders Continuous Process

M S

Fulfillment.OutOfStock

Detect Out Of Stock

M S

Fulfillment.Plan Calculate Plan

M S

Fulfillment.ProjOrderBuilder

Project Optimized Orders

M S

Fulfillment.AllocationCalcRMI

Allocation

Fulfillment. Aggregation

Calculate Aggregations

M S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

Fulfillment. Allocation

Calculate Allocations

M S

Calculate Mean Daily Demand

Fulfillment.CalcAvgDmd

M

Fulfillment.MSECalc Calculate SKU MSE

M T

Fulfillment.SKUClassification

SKU Classification

M


Generate Supply & Demand Links based on Priority

M


S



M



M T



S


M


Transfer Forecast

M S


Transfer History

S



M T




S

SCPOWeb.Simulation

Load scenarios

S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art



S



S



M S

JDA IPO

IPO.CalcAvgDmd Calculate Mean Daily Demand

M

IPO.CalcSupplyVar Calculate Lead Time Variance

M

IPO.Optimizer Optimize Inventory Policy

M


S


Transfer Forecast

S


IPO.GenStockingPlan

Generate Stocking Plan

M

IPO.MSECalc Calculate SKU MSE

M T

IPO.PublishOutput Publish IPO Output

M

IPO.SKUClassification

SKU Classification

M


Transfer History

M

JDA Markdown Optimization

Note: Refer to the JDA Demand Decomposition section for the list of common Pricing processes.

Markdown.CandidateIdentification

Identify Markdown Candidates

M T




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

Markdown.MetricsComputation

Compute Markdown Metrics

M T

Markdown.Optimize Optimize Markdowns

M T

JDA Master Planning

MasterPlanning.CampaignPlanner

Optimize Production Changeover

M

MasterPlanning.DeepTree

Calculate Master Plan

M

MasterPlanning.OrderPegging

Generate Supply and Demand Links

M


Generate Supply and Demand Links with Priority

M

MasterPlanning.PublishCampaign

Publish Optimal Production Changeover

M


S

MasterPlanning.RequirementPlan

Calculate Requirement Plan

M

MasterPlanning.SigmoidPriority

Calculate Sigmoid Priority

M



M



M T



S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art


M


Transfer Forecast

S


Transfer History

S



M T




S



S



S



M T

SCPOWeb.SeqIntExport

Transfer Planned Orders

M

SCPOWeb.SeqIntImport

Import Scheduled Receipts

M

JDA Promotions Management

Note: Refer to the JDA Demand Decomposition section for the list of common processes.

PromotionsManagement.BuildPromotionalHistoryProcess

Build Promotional History

M

PromotionsManagement.CollectorServiceRMI

Hierarchy Data Aggregator

S

PromotionsManagement.PriceRuleExport

Generate Price Rules Export

S

PromotionsManagement.PromoOfferExport

Export Promo Offer

S




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

PromotionsManagement.PromoOfferImport

Offer Import S

PromotionsManagement.PromoCandidateProcess

Promotion Candidate Process

S

PromotionsManagement.PromoOfferRefresh

Refresh Promo Offers

S

JDA Promotions Management with Statistical Forecasting

PromotionsManagement.Evaluation

Generate Promotional Forecast

S

JDA Strategic Planning

Note: Refer to the JDA Demand Decomposition section for the list of common Pricing processes.

DRM.Actualization Calculate Actuals

M T

DRM.ConstraintGeneration

Generate Constraints

M T

DRM.PricePointFcstGeneration

Generate Price Point Forecast

M T

PrecisionPricing.Evaluation

Evaluate Pricing Scenario

M T

PrecisionPricing.Optimization

Optimize Pricing Scenario

M T

JDA Production and Sourcing Optimization

SCPOWeb.Strategy Optimize Supply Chain

S

SCPOWeb.DistanceCalculation

Calculate distance between locations

S

SCPOWeb.InputDataIntegration

Input data integration

M

SCPOWeb.OutputDataIntegration

Output data integration

M




Act

ion

s (S

or

M)

Batc

h

Pip

eli

ned

Co

nti

nu

ou

s

Sto

red

Pro

ced

ure

sim

ula

tio

nN

am

e

searc

hN

am

e

pro

mp

t

act

ion

Gro

up

SetN

am

e

SR

E D

iag

no

stic

s

SR

E J

ob

Rest

art

SCPOWeb.WriteProjections

Store Projections and Statistics

M

JDA Revenue Management Foundation

DRM.DUAggregation Aggregate Demand and Availability Status

M

DRM.DUDisaggregation

Disaggregate Unconstrained Demand

M T

DRM.DUExpectationMaximization

Unconstrain Demand

M T

DRM.DUFSC Estimate Fractional Survival Curve

M T

*Adjust Forecast for Pricing and Promotions consists of three child processes, which are run in sequence: Delete Forecast, Transfer Price Forecast, and Import Forecast. Adjust Forecast for Pricing and Promotions is a single-action process and is not pipelined, but its child processes are multi-action and pipelined. Adjust Forecast for Pricing and Promotions does not use actionLifeCycle, but one of the child processes does.

Note: JDA Fulfillment Replenishment Dashboard feature (Fulfillment.DashboardRMI service) is supported. as lockable.

Configure SRE for SCPO processes This section describes unique SRE configuration requirements for selected SCPO processes. The memory requirements for the processes described in this section exceed the default values provided in the node pool Basic (128 MB). Typically, you do not need to modify the default memory settings for Basic, because many SCPO processes can run using these values. Instead, create one or more dedicated node pools for these high-memory jobs with higher memory settings. Associate each new node pool with its respective process. See the JDA Platform Installation/Administration Guide for procedures.

Note: Verify that your machine has sufficient memory for the node pool Basic. If it does not, decrease the number of nodes.

Contact JDA Support Solutions for recommended SRE configuration settings for other SCPO processes.

After you have configured SCPO processes, proceed to "Run batch processes (on page 136)" or "Export data".



JDA Production and Sourcing Optimization process Note that the JDA Production and Sourcing Optimization Optimize Supply Chain process must be run from an SRE instance on Windows. Running this process from the application server is not supported on Windows.

For optimum performance, set the memory requirements for the JDA Production and Sourcing Optimization Optimize Supply Chain process to at least -Xms512m -Xmx1024m in SRE_NODE_POOL.NODE_JAVA_OPTIONS. Also, you may have to increase the timeout settings for SCPOWeb.Strategy in SRE_ NODE_CONFIG from the default value of 600 seconds (10 minutes) to a higher number. A suggested range is 18000-36000. Some models may require significantly more time.

Configure Decision Support Workbench for a cluster In a clustered configuration, you can specify that the client applet use one or more backup servers in the event that the primary server is unavailable. To take advantage of this feature, you must modify the servers within the cluster to specify the primary server and any backup servers.

1. On each node in the cluster, change the jndi_provider_url to the form shown in the previous section.

2. On each node in the cluster, from the directory <install_dir>/config/bin/scpoweb, run the following commands:

runScpoTask prepare_applet

3. The above target recreates the JDA ear file (webworks.ear). The newly prepared ear file should be redeployed. This can be done by running the following command only on one node :

deployEarToCluster <DmgrHost> <DmgrBootstrapPort> <admin_user> <admin_password> <cluster_name>

For example, deployEarToCluster Host1 6103 appAdmin password JDACluster1

Note: The application binaries are copied over automatically to the cluster members and this process may take several minutes. After restarting the server, if you see an error similar to:

Error Message:JSPG0036E: Failed to find resource /vp/login/vpLoginPage.jsp

1. Run postDeployConfiguration from bin/platform directory.

2. Wait until the EAR is fully deployed and restart the JDA Supply Chain Planning and Optimization servers.

3. Restart all the JDA Supply Chain Planning and Optimization servers.

Migrate Shelf Connected Supply Chain Report Model to Collaborative Shelf Planning and Analytics You must perform the following when Shelf Connected Supply Chain (SCSC) model or reports are created or modified in 7.8:

Run the following query if new SCSC reports or queries or dadhboards are created in 7.8:

<install_dir>/config/database/reporting/cspa>sqlplus WWFMGR/WWFMGR@o11gr204 @ post_migration_78.sql

If customized changes are made to SCSC model in 7.8, perform the following to migrate SCSC Model to higher versions of Collaborative Shelf Planning and Analytics (CSPA) or Flowcasting:

1. Open IBM Cognos Framework Manager.

2. Select the CSPA model.



3. Import the required customized SCSC model in 7.8 into the CSPA model.

4. Save the CSPA model.

5. Run the <install_dir>\config\bin\bi\ManageModels.cmd command to publish the model.

Perform the following to migrate SCSC Reports from 7.8 to higher versions of CSPA or Flowcasting:

1. Login to JDA Shell.

2. Open any CSPA report in edit mode. The report opens in Report Studio.

3. Open the existing SCSC Reports that are created or modified in 7.8 under Public Folders/SCSC/Reports folder using the File>Open option.

4. Copy the XML specification to clipboard using the Tools>Copy Report to Clipboard option.

5. Paste the XML specification to any editor and replace all SCSC instances with CSPA.

6. Copy this modified XML specification and paste it in the Report Studio using the Tools>Open Report from Clipboard option.

7. Save the report to the Public Folders/CSPA/Reports folder.

To open any report that is created or modified in 7.8, in the migrated version, update the REPORTING_DIRECTORY_INSTANCE:search_path column must be updated. Replace all the search path values from SCSC to CSPA.

For example: Update /content/package[@defaultName='SCSC']/folder[@defaultName='Reports']/report[@defaultName="Over Stock Summary Report Template"] to /content/package[@defaultName='CSPA']/folder[@defaultName='Reports']/report[@defaultName="Over Stock Summary Report Template"].


Utilities and common tasks

Chapter 6. Utilities and common tasks Import data JDA application business processes require data to run. The source for this data can be another business system that is external to SCPO. You can load this data into the SCPO database using the Interface Generation Program (IGP) component of JDA Platform. The IGP lets you load large quantities of data from an external system in batch mode. Users can also import small quantities of data using the Import/Export Tool through the graphical user interface (GUI). See the online help for more information.

Before using IGP, you should have a strong knowledge of the SCPO database. In addition, you must install SCPO and create or migrate the SCPO 8.1 schema before. The JDA Foundation 8.1 schema must also exist.

The IGP is installed automatically when you install JDA Platform. The default installation directory for the IGP is <install_dir>\config\bin\platform (Windows) or $HOME/jda/jdav81/config/bin/platform (UNIX). For more information on the IGP, see the JDA Platform Interface Generation Program Reference Guide.

Note: IGP should be setup from full install of Platform and SCPO. IGP is not supported in an SRE install.

How IGP works with SCPO The IGP connects to the SCPO database using the JDBC thin driver. The database connectivity command is provided in <install_dir>\install\IGPProperty.properties.body.scpoweb. This file is a component of the IGP Properties file and contains settings specific to SCPO. When you install SCPO, the setup program replaces variables in the file with the appropriate values for your system.

Note: If you want to connect to a different database server than the one you specified during the installation process, you must modify the SCPO.dburl property in IGPProperty.properties.body.scpoweb to point to the correct database. Next, run the JDA Platform BuildConfiguration utility (config\bin\platform\BuildConfiguration.cmd) to regenerate IGPProperty.properties. See the JDA Platform Installation/Administration Guide for procedures on running the BuildConfiguration utility.

IGP uses an XML file along with the IGP properties file to create scripts that are used to generate interface tables, triggers, and stored procedures for the SCPO database. After the interface tables are generated, you transfer data from the source location to the interface tables using a tool such as Oracle's SQL*Loader.

Each time an insert statement is processed and data is inserted into an interface table, an "AFTER INSERT" trigger runs a stored procedure to move the data from the interface table to the live SCPO database table. The SCPO database enforces referential integrity. Records that pass the referential integrity checks are moved from the interface table to the live SCPO database table. Records that fail referential integrity checks are moved to the Error table that is associated with the interface table. You can correct data in the Error table and move it back to the appropriate interface table by writing a SQL statement that selects the corrected data from the Error table and inserts it into the appropriate interface table.

Customize the import process IGP provides several configuration options that enable you to tailor IGP for your site. For example, you can:



• Enhance security by running IGP in a shielded environment, in which only the generated stored procedures exist in the target (SCPO application) schema. All other IGP-related objects reside in the schema of the user that invoked the IGP. JDA Platform provides the scripts, cr_igp_user.sql in <install_dir>\config\database\setup and cr_igp_ts.sql in <install_dir>\config\database\setup\windows (windows) or <install_dir>\config\database\setup\unix (UNIX), to create an IGP user and tablespace respectively. After you have created the IGP user, run <install_dir>\config\database\platform\enroll_igp_schema.sql to grant SRE permissions to the user. See the JDA Platform Installation/Administration Guide for procedures on running these scripts.

Note: It is recommended that you run SCPO in a shielded environment, so the procedures in this chapter assume that you have created an IGP schema owner. When you run IGP commands, replace the variable igpusername/igppassword with the user name and password for the IGP schema owner.

• Generate the interface tables in a tablespace other than that used by the target schema to improve security and manageability.

• Specify how and when XML constraint failures will be reported.

• Prepare tables that contain a hierarchical structure for IGP processing by using self-referencing OIDs.

See the JDA Platform Interface Generation Program Reference Guide for information on configuring IGP.

Before you begin batch processing After you create or migrate the SCPO database schema to SCPO version 8.1, add any desired user-defined columns (UDCs) to the database tables using the procedures described in the JDA Foundation online help. Next, perform application-specific setup procedures for the JDA applications, as necessary, based on your intended use of the system:

• Modify the SCPO component of the IGP properties file to disable processing for the JDA Fulfillment Net Change feature, as needed. See Disable JDA Fulfillment Net Change feature (on page 129).

• Set up Time Phased Conversion Factors (TPCFs) if you use JDA Demand and you convert your prices into one or more currencies. See Apply price conversion factors for JDA Demand (on page 130).

• Import hierarchy entries for JDA Demand. See Import JDA Demand hierarchy entries (on page 131).

• Import forecast data into JDA Demand. See the Import JDA Demand forecast data (on page 134).

Prepare to load SCPO data 1. Back up your SCPO database.

2. Create an Oracle user account for running IGP and importing data into the IGP interface tables, using the JDA Platform cr_igp_user.sql script. When you subsequently run the IGP script wcif.plb, the script grants all necessary permissions to both the IGP user and the SCPO schema owner.

For more information on defining security for IGP, see the JDA Platform Installation/Administration Guide.

3. Create the Integration Jobs Table, which contains the results of all executions of stored procedures generated by the IGP. See Create the Integration Jobs table (on page 119).

4. Generate the XML file that IGP uses as input by running the IGPXMLGenerator utility. See Generate the input XML file (on page 120).



Subsequently, you must regenerate the input XML file, interface tables, and stored procedures whenever you modify IGP-supported database tables using the JDA Foundation Data Model Manager. Rerun the IGPXMLGenerator utility and IGP when you make the following changes:

• Add a user-defined column (UDC) to a database table

• Change the minimum, maximum, or default value for a column

• Change the valid enumerations (range) for a column

You can regenerate interface tables and stored procedures only for the modified table rather than for all database tables by running IGP using the tablename argument. See Run the Interface Generation Program(IGP) (on page 121). After you regenerate the interface tables, you can load data into the revised interface tables.

Create the IGP user Procedures in this chapter assume that you have created an IGP schema owner using the JDA Foundation script cr_igp_user.sql, and granted the necessary SRE permissions to the IGP owner using enroll_igp_schema.sql. These scripts are located in <install_dir>\config\database\setup and <install_dir>\config\database\platform, respectively. See the JDA Platform Installation/Administration Guide for procedures on running the cr_igp_user.sql script.

Create the Integration Jobs table Before running the IGP, you must create a Jobs table (INTJOBS), which records all the tracking information provided by each execution of each stored procedure generated by the IGP. The table contains one row for each unique combination of job ID, interface table name, and database table name. By default, IGP assigns the same job ID, INT_JOB, to each data load for a specific interface table and database table. You should assign a unique job ID to each new data load operation to prevent data in the INTJOBS table from being overwritten. Do this in one of two ways:

• Rename the job ID by using the igpjobmanager rename utility. See Rename a job ID (on page 127).

• Specify a default job ID in a SQL*Loader control file by using the CONSTANT keyword. See Oracle's SQL*Loader documentation for more information.

When a stored procedure successfully transfers data from an interface table to its associated database table, it records the number of rows that were inserted or updated in the INSERTCT or UPDATECT columns, respectively, of the INTJOBS table for the matching JOBID. The value in the TOTALROWSCT column is also incremented. Errors such as “TABLE NOT FOUND” or “COLUMN NOT FOUND” are recorded in the ERRORTEXT column of this table for the matching JOBID (however, these errors are rare). You can review the data in this table by using the igpjobmanager status utility or an Oracle utility. See Run the igpjobmanager status utility (on page 125). See the JDA Platform Installation/Administration Guide for more information on the INTJOBS table.

Create the INTJOBS table by executing the igp_init.cmd (Windows) or igp_init (UNIX) as the IGP user from a command line prompt in directory <install_dir>\config\bin\platform. Use the following syntax:

igp_init <igpusername>/<igppassword>[@oracle_connect_string]

Replace <igpusername>/<igppassword> with the username and password for the IGP schema owner.

For example,

igp_init igpmgr/igpmgr@UTF89iP5

The variable <oracle_connect_string> is required only if you are using SQLNet to connect to the database. This file calls and runs a SQL script. Ignore errors stating that an object does not exist. For example,

ERROR at line 1: JDA Supply Chain Planning and Optimization Installation/Administration Guide 119 © 1997-2014 JDA Software Group, Inc.- Confidential


ORA-00942: table or view does not exist

These errors are normal. The igp_init.cmd always attempts to drop existing objects and it will find none the first time it runs.

Generate the input XML file The IGP utility requires an application-specific XML configuration file as input. This file contains a list of all tables in the SCPO database into which you can load data using IGP. In addition, the file provides information about each table, such as the primary key. Before you run IGP, you must generate the XML file by running the IGPXMLGenerator utility. The utility examines the information stored in four Oracle views, IGPXML_*, which reside in the SCPO schema. It then generates the XML file using information extracted from these views. See the JDA Platform Interface Generation Program Reference Guide for a description of the views.

Note: If you are migrating to SCPO version 8.1, run the IGPXMLGenerator utility after migration to generate the input XML file for IGP. Next, run IGP to generate stored procedures and interface tables containing your existing user-defined columns (UDCs). Subsequently, repeat these steps to regenerate the input XML file, interface tables, and stored procedures whenever you modify IGP-supported database tables. See the JDA Interface Generation Program Guide for more information on using IGP with UDCs.

Execute the command Run IGPXMLGenerator by running igpxmlgen.cmd (Windows) or igpxmlgen (UNIX) from a command line prompt in directory <install_dir>\config\bin\platform. The utility must connect to the schema where the IGPXML_* views reside. Use the following syntax:

igpxmlgen <username> <password> <APPNAME> <schemaName> [<xmlFileName>]

where:

• username is the Oracle user who owns the schema containing the IGP views.

• password is the password of the schema owner for the IGP views.

• APPNAME is SCPO. It must match the case used in the IGP properties file.

• schemaName is the schema owner for the target database tables (application tables to be loaded by the IGP-generated stored procedures).

• xmlFileName is the name of the optional output XML file to be generated (defaults to <appName>_igp.xml).

SCPO stores the IGPXML_* views in the same schema as the application database tables. Therefore, if the SCPO schema owner is stsc with password stsc and the schema owner for the target database tables is stsc, enter the type the following command:

igpxmlgen stsc stsc SCPO stsc scpo_igp.xml

Output from the command As it runs, IGPXMLGenerator displays the name of each database table it adds to the XML file. For example:

Processing table: LewandowskiParam

Processing table: PlanOrder

Processing table: DFUView

This process may take a few minutes. When IGPXMLGenerator completes, it displays the total number of tables processed.

When you run IGP, the system validates the input XML file using igp_schema.dtd in <install_dir>\config\xsd. The XML configuration file contains the following information:



• Names of tables for which stored procedures need to be generated. Only relevant tables are included. Data cannot be imported into system tables or read-only tables.

• Sequence names and corresponding column names for columns that need to be populated by Oracle sequences, if applicable.

• Column range and value rules for each table.

This information is used by the IGP when creating interface table generation scripts.

Note: Do not edit the application XML configuration file that is generated by the IGPXMLGenerator utility.

Load data After you complete the steps in Prepare to load SCPO data (on page 118), perform the following high-level steps to load data:

1. Create the interface table generation script. See Run the Interface Generation Program(IGP) (on page 121).

2. Generate interface tables, triggers, and stored procedures for the SCPO database. See Generate interface tables and stored procedures (on page 122).

3. Import data to the interface tables using Oracle's SQL*Loader, SQL statements, or another method. See Import data into the interface tables (on page 125). If you choose to use SQL*Loader, create a sqlldr control file and data file for each interface table for which you want to load data. Copy these files to directory <install_dir>\config\bin\platform before you run IGP. After you load data to the interface tables, a set of stored procedures transfers the data from the interface tables to the live database tables.

4. Check for errors:

a. Run the igpjobmanager status utility to determine whether there were any critical errors. See Run the igpjobmanager status utility (on page 125). Alternately, you can review the INTJOBS table directly using an Oracle utility.

b. Check the return code passed to the operating system by the igpjobmanager status utility. See Check the return code (on page 126).

5. Resolve any errors that occurred during the data load process. See Resolve errors (on page 127).

6. If you want to import a new row into the same interface table in a subsequent data load operation and track the status of each load, rename the Job ID by running the igpjobmanager rename utility. See Rename a job ID (on page 127).

Run the Interface Generation Program (IGP) IGP parses the input XML configuration file and generates a script for creating interface tables, stored procedures, and triggers. IGP also creates an uninstall script. The names of the scripts depend on how you run IGP:

• If you generate interface tables for all database tables in the XML file, the output scripts are wcif.plb and uninstall_wcif.sql.

• If you generate interface tables for a specific table using the tablename argument, the output scripts are <tablename>.plb and uninstall_<tablename>.sql, where <tablename> is the name of the table you specified.

Note: If you have previously run IGP, correct any errors in the Error table and move the data to the appropriate interface table before you re-run IGP. Otherwise, the data in the Error table will be deleted when the IGP issues DROP TABLE statements.



Command line format for IGP Run IGP from directory <install_dir>\config\bin\platform. IGP takes the command line arguments described in the following table:

Command line arguments for IGP

Argument Description Value

-h Displays the following usage message:

Usage: IGP [-h] <username> <password> <config filename> <APPNAME>

-

username IGP user name username

password Password for IGP user name password

config filename Full path and file name of the application-specific XML configuration file that you created using the IGPXMLGenerator utility

<path_name>\<file_name>.xml

Default name is scpo_igp.xml.

APPNAME Target application for the integration. Must match the application name defined in the IGP properties file, including case.

SCPO

tablename Optional single table name constrains script generation to the specified table in the application database. In the absence of this argument, the generated script includes all tables in the application XML configuration file.

Leave blank to generate interface tables for all relevant application tables or specify a table name to generate interface tables for a specific table.

IGP example The following example runs igp.cmd using the D:\jdav800\config\bin\platform\scpo_igp.xml configuration file, for the SCPO database, to create an interface table generation script (wcif.plb). Run the script as the IGP user. The uninstall_wcif.sql script is also created.

igp igpmgr igpmgr d:\jdav800\config\bin\platform\scpo_igp.xml SCPO

Generate interface tables and stored procedures The interface table generation script parses the XML configuration file and examines the SCPO system tables to determine the schemas of the target tables. The XML file contains a list of all tables in the SCPO database into which you can load data using IGP. For each live SCPO database table described in the XML configuration file, the interface table generation script generates:

• Up to three interface tables, one for each data flow method or operation type (insert, update, and upsert). Interface tables are in the format INT<OPERATION>_<TABLENAME>. For example for the ITEM table, the interface tables are named INTINS_ITEM, INTUPD_ITEM, and INTUPS_ITEM.

• Up to three stored procedures, one for each operation type, in the format INT<OPERATION>PROC_<TABLENAME>.

• One error table in the format INTERR_<TABLENAME>. This error table contains the records that fail the integrity checks.

The script also generates the necessary AFTER INSERT triggers for each of the three interface tables in the format INT<OPERATION>TRIG_<TABLENAME>.



Note that <TABLENAME> in the file names of IGP database objects may not necessarily be the name of the database table associated with the objects. See Database object name conventions (on page 123).

Database object name conventions The names of database objects, such as triggers, stored procedures, and interface tables, must comply with the name restrictions associated with the database. For Oracle databases, the maximum table name length is 30 characters. When IGP generates a database object, its name convention requires 12 characters. Most table names for live SCPO tables occupy only 14 of the remaining 18 characters; four characters are reserved for the prefix SIM_, which is used by SCPO simulation tables.

Some application table names exceed 14 characters. SCPO provides a short table name as an alternate name for most tables that fall into this category. In addition, SCPO provides short table names for some JDA Promotions Management interface tables. To determine whether a short name exists for a table, use an Oracle utility to check the Oracle view IGPXML_TABLES.SHORT_TABLE_NAME in the SCPO schema.

Note: When you load data into the IGP interface tables, ensure that you specify the generated name that appears in the XML file, if it differs from the actual table name.

See the IGP chapter in the JDA Platform Installation/Administration Guide for more information on the naming conventions used for interface tables, stored procedures, and triggers and on the data flow methods.

Run the script You must run the interface table generation script, along with any additional custom scripts, before initiating integrations. Run the script from a command line prompt in directory <install_dir>\config\bin\platform using the format:

sqlplus <igpusername>/<igppassword>@<oracle_connect_string> @wcif.plb

For example:

sqlplus igpmgr/igpmgr@UTF89iP5 @wcif.plb

The variable <oracle_connect_string> is required only if you are using SQLNet to connect to the database. As the script runs, it prompts you to enter the following information:

• TNS_alias for your database

• Password for the SCPO schema owner

• Password for the IGP schema owner

This process may take several minutes.

Note: The first time you run the IGP, you may see messages informing you that tables cannot be dropped. You can ignore these errors because the IGP always attempts to drop existing tables and it will find none the first time it runs.

The wcif.plb and <tablename>.plb scripts spool error messages to files wcif.log and <tablename>.log, respectively.

Simplify Data Import You can optionally use a Flexible Editor page as a tool to view the IGP schema and to facilitate importing data using IGP. In addition, the IGP error tables can be enabled in Flexible Editor so that you can review failures that may have occurred during data import. Follow the steps in this section to enable this additional functionality.

After successfully setting up the IGP environment, perform the following steps:





sqlplus system/manager @enroll_app_schema.sql <igpuser>

Replace <igpuser> with the IGP schema owner. The script sets up application schema permissions as well as permissions between the IGP schema and the JDA Foundation schema.

3. Run igp_util from a command line prompt in the <install_dir>\config\bin\platform directory.

igp_util <igpuser> <igppasswd> <wwfuser> <wwfpasswd> <scpouser> <superuser>

Example:

igp_util igpmgr igpmgr wwfmgr wwfmgr scpomgr SuperUser

or

igp_util igpmgr igpmgr wwfmgr wwfmgr scpomgr System

Append the TNS name to the password if the database is not on the same machine.

4. Using SQL*Plus, run enroll_app_schema.sql to enroll the IGP user.

sqlplus system/manager @enroll_app_schema.sql <igpuser>

Replace <igpuser> with the IGP schema owner.

The igp_util batch script performs the following actions:

• Creates the INT_TABLE_INFO and INT_COLUMN_INFO tables in the IGP schema. These tables dynamically store the metadata related to the appropriate SCPO tables for data load through IGP.

• Populates the metadata related to IGP interface tables in the Foundation schema. The Flexible Editor pages ‘IGP TABLE INFO’ and ‘IGP COLUMN INFO’ are created under Utilities ->IGP Flexible Editor in the application directory.

• The ‘IGP TABLE INFO’ Flexible Editor page allows you to mark the required tables for which you want to load the data through IGP. To do so:

1. Select the DATALOADSW column for the required table.

2. Populate the “.CSV” file name with directory location in the CSV_FILE_NAME column for each table selected for data load.

• The ‘IGP COLUMN INFO’ Flexible Editor page allows you to mark the required columns of a specific table for which you want to load the data. To indicate that a column should be loaded, change the DATALOADSW column for the column. This page also provides the flexibility to generate scripts to load the data into multiple tables using single .CSV file by providing a parent table/ column name in the PARENT_TABLE/PARENT_COLUMN fields. For example, if you want to load data into the SKU table using a single .CSV file without loading the item and loc data separately, the data is first loaded into ITEM and LOC followed by SKU.

• Generates Flexible Editor pages for all interface error tables under Utilities -> IGP Flexible Editor in the application directory. These pages are used to view the data that failed during the IGP import process.

Generate Data Load Scripts To generate batch scripts for the tables or columns selected from IGP Flexible Editor pages, run the IGPDataLoadScriptGeneration utility. The utility generates control files and batch files for all the tables that were specified in the Flexible Editor page.

Usage:

IGPDataLoadScriptGeneration <username> <password> <APPNAME> <DataFilesDirectory>



Example:

IGPDataLoadScriptGeneration igpmgr igpmgr SCPO D:\DataFiles

This utility creates the batch file for each selected IGP interface table under the “..\batch file” directory. It also creates the control file for each selected IGP Interface table under the “..\control file” directory. You can then use these files to load your data into the database using IGP.

Import data into the interface tables After you generate the interface tables for SCPO, import data into them using Oracle SQL*Loader or another utility. You must load the data in a specific sequence, so you do not violate referential integrity constraints. Otherwise, the data load operation may fail. To determine the correct data loading sequence, see the appropriate JDA application reference guide for information on database table relationships.

If the generated list of constraint violations exceeds 2,000 characters, the IGP truncates the error message and prepends the following text to the message:

Check the XML configuration file for the complete list of constraints.

Upon the insertion of data into the interface table followed by a commit statement, an "AFTER INSERT" trigger runs a stored procedure to move the data from the interface table to the live SCPO database table.

If you choose to import data using Oracle SQL*Loader, create three sets of sqlldr control files and data files for each interface table (insert, update, and upsert). The file name and extension can be anything you choose. Create the sqlldr file in <install_dir>\config\bin\platform using a text editor or by using the Oracle SQL*Loader utility. Specify one interface table in the sqlldr file; SCPO does not support importing data into multiple tables. The sqlldr control file must contain required settings.

When IGP generates interface tables for each SCPO database table, it adds a JOBID column to each interface table. You can load a default job ID to this column by using the CONSTANT keyword in the SQL*Loader control file. See Oracle's SQL*Loader documentation for more information. IGP creates a record for this job ID in the INTJOBS table upon completion of the import process.

Check for errors Checking for errors involves two steps.

Note: If you load data into the interface tables using SQL statements, SQL*Plus displays the message "n rows created." if the import is successful, where n is number of rows. However, the transfer of data from the interface tables to the database tables can still fail. Review the SQL*Loader output file for errors following each data load operation. Check the results of the IGP execution as described in the following sections.

Run the igpjobmanager status utility Run the igpjobmanager status utility to determine whether any critical errors occurred during the transfer of data from the interface tables to the database tables. This utility:

• Queries the INTJOBS table.

• Evaluates the results of the data load operation for the specified job ID against the specified threshold or acceptable failure rate.

• Returns one of the return codes listed in the table under Check the return code (on page 126) to the operating system.

You can also view the data in the INTJOBS table directly by using an Oracle utility.



The igpjobmanager status utility uses the database connection parameters specified in IGPProperty.properties.body.scpoweb. These parameters are set by SCPO during the installation process.

Run igpjobmanager as the IGP user from a command line prompt in directory <install_dir>\config\bin\platform. Use the following syntax:

igpjobmanager -s <igpusername> <igppassword> SCPO <target_table_name> <interface_table_name> <job ID> [<acceptable_failure_rate>]

where <acceptable_failure_rate> is the percentage of total rows in a data load operation that can fail but still be considered a successful load. The default acceptable failure rate is 25 percent. For example, if you load 100 rows of data in a single load operation and 25 or fewer rows fail, the load is considered to be successful. If the number of failed rows exceeds the threshold you specify, then the igpjobmanager status utility generates a return code of 3 (Critical error).

You might find it useful to run this utility as part of a batch process that loads data into an interface table, then checks the status of the load before proceeding. Each load statement in the batch file would be processed only if the preceding job finished with an acceptable rate of failure. Otherwise, the batch file would exit with errors. See the sample batch file in the IGP chapter of the JDA Platform Installation/Administration Guide. For example, to check the status of a data load to the ITEM insert interface table using the default job ID INT_JOB and specify that a 15 percent rate of failure is acceptable for processing to continue, enter the following:

igpjobmanager -s igpmgr igpmgr SCPO ITEM INTINS_ITEM INT_JOB 15

In this example, if 15 percent or fewer rows failed during the insert into the INTINS_ITEM table, the igpjobmanager status utility returns a status of 2 (Warning). If more than 15 percent of the rows fail during the insert, then the utility returns a status of 3 (Critical error).

If the transfer of data from the interface tables to the database tables is successful, the utility produces output similar to the following:

Connecting to

HOST : webster

SID : UTF89iP5

INSERT COUNT : 3

UPDATE COUNT : 0

TOTAL ROWS COUNT : 3

FAILURE RATE : 0%

For more information on the igpjobmanager status utility, see the IGP chapter in the JDA Platform Installation/Administration Guide.

Check the return code After you run the igpjobmanager rename or status utility, the utility passes one of the return codes identified in the following table to the operating system, based on the results of the job ID rename process or load process.

Return codes for the igpjobmanager rename and status utilities



Return code igpjobmanager rename utility

igpjobmanager status utility

0 - Normal The jobs were renamed successfully.

All rows were loaded successfully.

2 - Warning The job ID to rename does not exist.

Some rows were rejected during the load process; however, the threshold was not exceeded.

3 - Critical The job cannot be renamed due to an issue, such as a constraint violation or invalid characters.

If you specified a threshold, the threshold was exceeded.

4 - Fatal The rename utility cannot connect to the database or cannot locate IGPProperty.properties. This error is also returned if you specify an invalid application name when you run the utility. The application name must be SCPO.

The status utility cannot connect to the database or cannot locate IGPProperty.properties.

Query the return code by entering the following command at a command line prompt:

• On a Windows system, enter the following:

echo %errorlevel%

• On a UNIX system, enter the following:

echo $?

Resolve errors Errors reported by the DBMS during execution of the stored procedure are captured in the Error table. The error table contains the same schema as the associated interface table. In addition, the error table has columns that contain the error message and the time when the error occurred. You can correct data in the Error table and move it back to the appropriate interface table by writing a SQL statement that selects the corrected data from the Error table and inserts it into the appropriate interface table.

Note: If you want to correct data in the Error table and move it to the appropriate interface table, you must do so before running IGP-generated scripts (wcif.plb) again. Otherwise, the data in the Error table will be deleted when the IGP issues DROP TABLE statements.

After you have corrected any errors, start the JDA Platform server, if it is not already running.

Rename a job ID The IGP records the results of each data load operation in the INTJOBS table. The table contains one row for each unique combination of job ID, interface table name, and database table name. By default, IGP assigns the same job ID, INT_JOB, to each data load for a specific interface table and database table.



You can rename the job ID for a load in the INTJOBS table using the igpjobmanager rename utility. Use this utility to run multiple data loads for the same interface table and track the results of each load separately. For example, if your business process requires that you load data into the ITEM table on an hourly basis, you might want to include a date and timestamp in each job ID to differentiate between process runs. Each hourly load would then create a new row in the INTJOBS table. You might find it useful to run this utility as part of a batch process that loads data into an interface table, then renames the load in the INTJOBS table before processing the next load specified in the batch file. See the sample batch file in the IGP chapter of the JDA Platform Installation/Administration Guide.

The igpjobmanager rename utility uses the database connection parameters specified in IGPProperty.properties.body.scpoweb. These parameters are set by SCPO during the installation process.

Run igpjobmanager from a command line prompt in directory <install_dir>\config\bin\platform. Use the following syntax:

igpjobmanager -r <igpusername> <igppassword> SCPO [<old_jobID> [<new_jobID>]]

The default value for <old_jobID> is INT_JOB. If you do not specify a value for <new_jobID>, the rename utility uses <old_jobID>_<SYSDATE>.

For example, to rename default job ID INT_JOB to ITEMJOB_102404_0100, which loaded data into the ITEM table on October 24, 2004 at 1:00 a.m., type:

igpjobmanager -r igpmgr igpmgr SCPO INT_JOB ITEMJOB_102404_0100

This command updates the existing row in the INTJOBS table. It also updates the job ID for corresponding rows in the error table. Assigning a unique job ID to each load allows you to collect statistics for a particular job, and helps you to identify the loads that contain errors. You can review the status of the load by using the igpjobmanager status utility or an Oracle utility. See Run the igpjobmanager status utility (on page 125).

When the igpjobmanager rename utility completes, it returns one of the return codes listed in the table under Check the return code (on page 126).

For more information on the igpjobmanager rename utility, see the JDA Platform Interface Generation Program Reference Guide.

Rules on importing data Observe the following guidelines when you import data:

• The version 7.2.1 (level 86) SCPO database enforces referential integrity among parent and child tables. During the import process, the system performs referential integrity checks to validate that new rows do not refer to non-existent rows in other tables. Data must be imported into the interface tables in the correct sequence, or the IGP data transfer from the interface tables to the database tables will fail. The system logs failed rows in the import results file. See the appropriate JDA application reference guide for information on parent and child table relationships.

• SCPO allows you to import data into a single table only. Therefore, if you export a Flexible Editor page that uses more than one database table, you cannot reimport it.

• You can import into a Live or scenario table (table name that begins with SIM_).

• Import does not support aggregation or allocation of data. Aggregation and allocation of data must be performed after the data has been imported.

• The import file must contain text in either character-delimited or fixed-width format. Delimited files do not require a .csv file extension.

Note: Check the Oracle documentation for importing data through SQL*Loader, especially if you are importing extended ASCII or double-byte data. You must specify character semantics and database encoding correctly in your control file when you are importing into the UTF8 database.



• The order of the columns in the control file does not have to match the order in the database. However, the order of the columns in the data file must match the control file.

• IGP populates columns for which values are not specified in the control and data files with default values, provided they exist in the database table.

• For user-defined columns (UDCs), supply all required values in the data file. The import will fail if you neglect to supply data where columns are not null.

• SQL*Loader affixes a prefix of '20' to dates that are specified using a two-digit year. For example, if you specify 98 in the data file, SQL*Loader interprets the date as 2098. Therefore, consider specifying dates using a four-digit year (YYYY), particularly when importing history records.

• When users attempt to import or export large amounts of data using the JDA Foundation Flexible Editor import and export tools, which are available through the browser interface, the Please Wait window can time out if the import or export process exceeds the default wait time of 2 minutes. You can increase the wait time by modifying the sre_total_wait property in the System_Properties table. The time is specified in milliseconds. Note also that the maximum upload file size for GUI-based import is 100 MB. See the JDA Platform Installation/Administration Guide for a description of Flexible Editor properties and to the System Properties online help for information on modifying JDA Foundation properties.

• Modify pre-8.1 control files to reflect database changes before using them to import data with 8.1. For example, if the database was migrated to version 7.1.1, some migrated userviews (Flexible Editor pages) may include columns from the SKU table that have been removed by the migration scripts. In cases where columns have been added to a table, try adding filler data to the control and data files so that the FE page imports correctly.

• The data type for DBPARAM.FISCALYRSTART and CALDATA.EFF is NUMBER. Therefore, before importing data using IGP or another tool, convert any dates for these columns to the number of minutes that have elapsed since January 1, 1970 00:00. Otherwise, the import will fail.

• To import a Microsoft Excel file, you must first save the file using the Save As a CSV (Comma Separated Values) file type option.

Application-specific setup procedures for import processes This section describes the application-specific setup procedures.

Disable JDA Fulfillment Net Change feature The JDA Fulfillment Calculate Plan process selects SKUs for replanning, based on the value set for the SKU:NetchgSw flag. When you import data into the interface table for a table that affects the planning of a SKU (for example, the CUSTORDER table), an IGP trigger automatically calls a stored procedure that sets the NETCHGSW flag in the SKU table to 1 (On) for that item. The next time a user runs the Calculate Plan process, the process selects that SKU for replanning. See the JDA Fulfillment Reference Guide for a list of tables that affect the NETCHGSW flag.

Although it may be desirable to flag changes to tables that affect the results of the Calculate Plan process, running these additional stored procedures slows the import process. If you want to reduce the time it takes to import your data, you can disable the Net Change process before running IGP by modifying IGPProperty.properties.body.scpoweb. This file is a component of the IGP Properties file and contains settings specific to SCPO.

You can disable the Net Change process for some or all tables that affect the Calculate Plan process. For each table of this type, the component properties file contains a separate line for each mode of operation (INSERT, UPDATE, and UPSERT).

Note: If you choose to disable the Net Change process, you must do so before you run IGP. Otherwise, if you subsequently modify IGPProperty.properties.body.scpoweb, you must rerun IGP to regenerate all the triggers and stored procedures.

1. Stop the JDA Platform Server, if it is running.



2. Using a text editor, open IGPProperty.properties.body.scpoweb in the <install_dir>\install directory.

3. In the PRE AND POST PROCESSING STORED PROCEDURES section of the file, remove or comment out the group of lines associated with each table and mode of operation for which you want to disable the Net Change process. For example, to disable Net Change pre- and post-processing stored procedures for INSERT mode for the ALLOCSTRAT table, remove or comment out the following lines in the file:

SCPO.ALLOCSTRAT.INS.PRESP= Planning_IGP_Integration.Planning_IGP_PreProc

SCPO.ALLOCSTRAT.INS.PRESP.TOTALPARAMS= 2

SCPO.ALLOCSTRAT.INS.PRESP.PARAM1= 'ALLOCSTRAT'

SCPO.ALLOCSTRAT.INS.PRESP.PARAM2= 2

SCPO.ALLOCSTRAT.INS.POSTSP= Planning_IGP_Integration.Planning_IGP_PostProc

SCPO.ALLOCSTRAT.INS.POSTSP.TOTALPARAMS= 2

SCPO.ALLOCSTRAT.INS.POSTSP.PARAM1= 'ALLOCSTRAT'

SCPO.ALLOCSTRAT.INS.POSTSP.PARAM2= 2

4. Save the file and exit the editor.

5. Regenerate IGPProperty.properties using the BuildConfiguration utility. See the section on regenerating configuration and startup files in the JDA Platform Installation/Administration Guide.

6. If you modified the SCPO IGP properties file after you created interface tables, triggers, and stored procedures for the SCPO database using IGP, perform the following steps:

a. Rerun igp.cmd to regenerate the interface table generation script. See Run the Interface Generation Program(IGP) (on page 121).

b. Rerun the interface table generation script to regenerate interface tables, triggers, and stored procedures. See Generate interface tables and stored procedures (on page 122).


Apply price conversion factors for JDA Demand SCPO allows users to view history and forecast data in revenue by applying price conversion factors, or time-phased conversion factors (TPCFs), to DFUs. Users can display TPCFs on the following application pages: Demand Workbench, Flexible Allocation, Forecast Overrides, and Target Manager, providing they have read access to the corresponding features.

You can apply one or more TPCFs to each DFU. If you plan to convert DFUs into multiple currencies, you can import the base price, then the currency conversion rates, to calculate dollars to Euros, dollars to Yen, and so on. Modifications to revenue are saved in the base units. You can import TPCFs into any calendar; however, TPCF time periods do not have to correspond to calendar time periods.

Several database tables and columns are designed specifically to support this feature, including a column in the DFUView table, which is used for conversion factors. You must import data into these tables before users can use the TPCFs feature. Otherwise, when users attempt to use this feature, the error message "TPCF setup is invalid" is displayed. Additionally, as currency rates change, you must import the new rates into the database. See the JDA Demand online help for more information on these tables.

Users responsible for maintaining TPCF data using the Time-Phased Conversion Factors page must have CREATE, U permission to the tables listed below. Users require READ permission to open pages that display TPCFs.

1. Import your price conversion factor data.

a. For one currency, import data into these tables:



• Currency

• Currency Profile (Even if you are only converting units to USD (U.S. dollars), the Currency Profile table must contain a row for this conversion (USD to USD).)

• Price Profile

• DFUView

• Price Profile Values

b. For multiple currencies, import data into the Currency Profile Values table in addition to the listed tables.

2. Set the default currency type to use for price conversions in JDA Demand:

a. On the JDA Welcome page, click Preferences.

b. From the Preferences drop-down list, select Demand Settings.

c. Under Conversion Factors, select a value from the Default Currency list.

3. Specify whether conversion factors should be displayed on each available page by modifying the Use Conversion Factors option on the associated Properties page.

When you apply the TPCF feature, the system automatically corrects any gaps in pricing data by extending the end date for one price to the start date of the next. For example, if the end date for Price A is 1/10/05 and the start date for Price B is 1/12/05, then the system extends the end date of Price A to 1/12/05 to eliminate the two-day gap between the price data.

Overlaps in pricing data are handled similarly. For example, if the end date for Price A is 1/15/05 and the start date for Price B is 1/10/05, then the system changes the end date of Price A to 1/10/05 to eliminate the five-day overlap between the price data.

See the online help for more information on defining price conversion factors.

Import JDA Demand hierarchy entries The hierarchy entry import process lets you import large quantities of hierarchy entries into the database in batch mode. This task is normally performed on a weekly or monthly basis.

You import JDA Demand hierarchy entries using IGP, but the import process is different from other SCPO import processes, because hierarchy entry data is stored in the JDA Foundation schema rather than the SCPO schema, where other SCPO data is stored.

JDA Demand provides a static XML input file for use with this import process, <install_dir>\config\bin\scpoweb\hierarchyentry_igp.xml. When you run IGP using this input file, the IGP generates interface tables only for the GS_HIERARCHY_ENTRY table, rather than all tables in the database.

Before you import hierarchy entries, ensure the following:

• Hierarchy structure exists in the database. See the JDA Demand online help for procedures on creating hierarchy structures.

• Appropriate security privileges are defined in Security Manager.

• User that will own the IGP schema exists. You can create the IGP user by running cr_igp_user.sql in <install_dir>\config\database\setup. See the JDA Platform Installation/Administration Guide for procedures on running this script.

Note: Only the IGP user can import hierarchy entry data using IGP.

JDA provides a sqlldr control file, hierarchy_entry.ctl, in directory <install_dir>\config\scpoweb\bin, for importing hierarchy entry data. The control file specifies the name of the IGP interface table into which the data must be loaded.



1. Create hierarchy stored procedures:

a. Change to directory <install_dir>\config\database\scpoweb\demand.

b. Using SQL*Plus, run PKG_db_storedobjects_hierarchyUpdate.sql as the JDA Foundation schema owner. For example:

sqlplus wwfmgr/wwfmgr @PKG_db_storedobjects_hierarchyUpdate.sql

Ignore errors relating to missing interface tables, which will be created in a later step.

2. Define the schema owner for the hierarchy entry import process:

a. Using a text editor, open IGPProperty.properties in directory <install_dir>\config\properties. Modify the Schema Owner Configuration section of the file. Change the line:

##<APPNAME>.schemaOwner=<schema name>

to the following:

DEM.schemaOwner=WWFMGR

b. Save the file and exit the text editor.

3. Create the interface table generation script for hierarchy update:

a. Change to directory <install_dir>\config\bin\platform.

b. Run IGP as the IGP schema owner. For example:

igp igpmgr igpmgr <install_dir>\config\bin\scpoweb\hierarchyentry_igp.xml DEM

4. Using SQL*Plus, run the interface table generation script wcif.plb as the IGP schema owner. For example:

sqlplus igpmgr/igpmgr @wcif.plb

The script generates the interface table INTINS_GS_HIERARCHY_ENTRY and error table INTERR_GS_HIERARCHY_ENTRY for hierarchy entry data.

5. Grant update privilege to user wwfmgr for tables INTINS_GS_HIERARCHY_ENTRY and INTERR_GS_HIERARCHY_ENTRY. For example:

sqlplus igpmgr/igpmgr

grant update on igpmgr.INTINS_GS_HIERARCHY_ENTRY to wwfmgr

grant update on igpmgr.INTERR_GS_HIERARCHY_ENTRY to wwfmgr

6. Create a sqlldr data file, for example, hierarchy.dat, using the following format:

Parent Name, Hierarchy Name, Hierarchy entry name

The following is a sample input file:

,"Locations","US"

"WEST","Locations","LA"

In this example, a comma is used as the delimiter. Line one begins with a comma, which indicates that the entry does not have a parent and is therefore located at the top of the tree. For other entries that have a parent name, the hierarchy_entry table should already contain the parent entry record.


8. Load hierarchy entry data into the IGP interface table you created in step 4. For example, to use Oracle's SQL*Loader, type the following:

sqlldr igpmgr/igpmgr hierarchy_entry.ctl

A stored procedure moves the data from the interface table to the live SCPO database table.



Import JDA Demand DDE data The Data-Driven Event (DDE) IGP import process facilitates the import of DDE data into the SCPO database. DDE data are stored in two tables, DDEPROFILE and DFUDDEMAP. These tables are linked by the primary key DDEPROFILEID of the DDEPROFILE table. The DDE IGP import process increments the DDEPROFILEID using the Oracle sequence DDEPROFILEENTRYSEQ and populates the STARTPCT values in the DDEPROFILE table and the OPTIMPCT values in the DFUDDEMAP table. The DDE IGP import process also checks for the following constraints:

• STARTPCT: Valid values are from -99.99 to 9999.99.

• MODEL: Valid models are Lewandowski models with algorithm=4 in the MODEL table.

• STARTDATE: Valid start date is later than DFU.HISTSTART and earlier than DFU.DMDPOSTDATE + DFU.FCSTHOR.

• DMDUNIT, DMDGROUP, LOC, and MODEL: Valid DFU model exists in the DFU table.

JDA Demand provides a static XML input file, located at <install_dir>\config\bin\scpoweb\ddeprofile_igp.xml, for use with this import process. When you run IGP using this input file, IGP generates interface tables only for the DDEPROFILE table rather than for all the tables in the database.

Before you import DDE data, ensure that the user that will own the IGP schema exists. You can create the IGP user by running cr_igp_user.sql in <install_dir>\config\database\setup. See the JDA Platform Installation/Administration Guide for procedures on running this script.

To import DDE data using IGP:

1. Create the interface generation script for DDE:

a. Change to directory <install_dir>\config\bin\platform.

b. Run IGP as the IGP schema owner. For example:

Igp igpmgr igpmgr

<install_dir>\config\bin\scpoweb\ddeprofile_igp.xml SCPO

2. Using SQL*Plus, run the interface table generation script wcif.plb as the IGP schema owner. For example:

Sqlplus igpmgr/igpmgr @wcif.plb

The script generates the interface table INTINS_DDEPROFILE and error table INTERR_DDEPROFILE.

3. Create a sqlldr control file; for example, ddeprofile.ctl:

LOAD DATA

INFILE 'd:\jdav800\config\bin\scpoweb\ddeprofile.dat'

BADFILE 'd:\jdav800\config\bin\scpoweb\ddeprofile.bad'

DISCARDFILE 'd:\jdav800\config\bin\scpoweb\ddeprofile.dsc'

APPEND INTO TABLE “INTINS_DDEPROFILE”

REENABLE DISABLED_CONSTRAINTS

FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '”' and '”' TRAILING NULLCOLS

(STARTPCT1 FLOAT EXTERNAL(10),

STARTPCT2 FLOAT EXTERNAL(10),







DMDCAL,

DMDUNIT,

DMDGROUP,

LOC,

MODEL,

STARTDATE DATE “DD-MON-YYYY HH:MI:SS AM”,

DESCR,

DDEPROFILEID “STSC.DDEPROFILEENTRYSEQ.nextval”)

4. Create a sqlldr data file; for example, ddeprofile.dat using the following format:

STARTPCT1, STARTPCT2, STARTPCT3, STARTPCT4, STARTPCT5, STARTPCT6, DMDCAL, DMDUNIT, DMDGROUP, LOC, MODEL, STARTDATE, DESCR

For example:

1,1,1,0,0,0,DMDMONTH, 120-42-105, CLUB, LA, ORDER_LEW, 01-Jan-2001, TEST


6. Load DDE data into the IGP interface table you created in Step 2. For example, to use Oracle's SQL*Loader, type the following:

sqlldr igpmgr/igpmgr ddeprofile.ctl

A stored procedure moves data from the interface table to the live SCPO database table.

Import JDA Demand forecast data You can import forecast data into JDA Demand using the Import Forecast process in two steps. First, load forecast data into a staging table in the database using IGP. Next, run the Import Forecast process to transfer the data from the staging table to either the FCST or FCSTDRAFT database table. The Import Forecast process is available in both the GUI and batch using SREBatchUtility.

1. Configure IGP using the instructions in this chapter. This process includes generating the input XML file and the interface tables for the staging table FORECASTRECORDIMPORT.

IGP generates the following interface tables for FORECASTRECORDIMPORT:

• INTINS_FORECASTRECORDIMPO: Data to be imported into FORECASTRECORDIMPORT.

• INTERR_FORECASTRECORDIMPO: Data to be loaded to the INTINS_FORECASTRECORDIMPO table due to errors.

2. Load data into the INTINS_FORECASTRECORDIMPO interface table using Oracle's SQL*Loader, SQL statements, or another method. See Import data into the interface tables (on page 125). If you choose to use SQL*Loader, create a sqlldr control file and data file for the INTINS_FORECASTRECORDIMPO interface table. See the JDA Demand online help for a description of the FORECASTRECORDIMPORT table and Sample control file for forecast data import (on page 135) and Sample data file for forecast data import (on page 135) for sample files.

After you load data into the INTINS_FORECASTRECORDIMPO interface table, a set of stored procedures transfers the data from the interface table to the live database table FORECASTRECORDIMPORT.



3. Run the JDA Demand Import Forecast process using the GUI or SREBatchUtility. This process transfers the forecast records from the staging table FORECASTRECORDIMPORT to either the FCST or FCSTDRAFT table, based on the option set and search you specify. Define the option in the GUI before you run this process in batch. See the JDA Demand online help for more information on the Import Forecast process and Run batch processes (on page 136) for information on running this process in batch.

Sample control file for forecast data import The following sample control file loads data from FCSTIMPORT.dat into the INTINS_FORECASTRECORDIMPO interface table. An IGP stored procedure then transfers the data into the FORECASTRECORDIMPORT table.

OPTIONS (SKIP=1, ERRORS=12000)

LOAD DATA

INFILE '<install_dir>\config\bin\platform\FCSTIMPORT.dat'

BADFILE '<install_dir>\config\bin\platform\FCSTIMPORT.bad'

DISCARDFILE '<install_dir>\config\bin\platform\FCSTIMPORT.dsc'

APPEND

INTO TABLE "INTINS_FORECASTRECORDIMPO"

REENABLE DISABLED_CONSTRAINTS

FIELDS TERMINATED BY ','

OPTIONALLY ENCLOSED BY '"' AND '"'

TRAILING NULLCOLS

(DMDUNIT,

DMDGROUP,

LOC,

MODEL,

STARTDATE DATE "DD-MON-YYYY HH:MI:SS AM",

TYPE,

FCSTID,

DURATION,

QTY

)

Sample data file for forecast data import The following sample data file loads forecast data for JDA Demand. The duration can be specified using any valid SCPO format. For example, 1W, 31D, 24H, or 1440M. Lowercase characters (w, d, h, or m) are acceptable. If no character is specified (as in this example), the default duration is minutes.

When you run the Import Forecast process to transfer the forecast data from the FORECASTRECORDIMPORT table to either the FCST or FCSTDRAFT table, the process converts the duration specified in the data file into minutes. Following the conversion, the process discards any forecast record for which the duration is not a multiple of 1440.



"10100","SOUP","BIRM","ORDER_LEW","01-Jan-2005 12:00:00 AM",3,"FCSTLOCK",44640, 100

"10100","SOUP","BOISE","ORDER_LEW","01-Jan-2005 12:00:00 AM",6,"OVERRIDE",44640, 100

"10100","SOUP","LA","ORDER_LEW","01-Jan-2005 12:00:00 AM",3,"FCSTLOCK",44640, 100

Run batch processes SCPO uses the service runtime environment (SRE) framework provided by JDA Platform to launch most JDA application batch processes. SRE provides parallel execution of processes on the JDA Platform Server or on standalone JDA Platform SRE machines. See the JDA Platform Installation/Administration Guide for a comprehensive description of SRE terminology and architecture.

Before you can start SCPO batch processes, you must configure the processes to run based on the available machines in your environment. First, perform the SRE configuration tasks described in the JDA Platform Installation/Administration Guide. Next, see Configure the environment (on page 98) for information on deploying SCPO processes using SRE.

JDA Promotions Management and JDA Markdown Optimization use a special batch process to load model specification files. See Load Promotions and Markdown model files (on page 141).

Use SRE to launch batch processes SCPO uses the JDA Platform SREBatchUtility command file to launch batch processes on the JDA Platform Server and on standalone JDA Platform SRE machines. Batch processes must be launched from a command line prompt. To run SREBatchUtility, you must have:

• A valid and well-formed process request XML file that specifies the service name and other parameters. See Examples of process request XML files (on page 137).

• A valid CSM user account with execute permission for resource Process Manager. The user name/password combination must appear in credentials.properties. Password must be encrypted using genEncryptedPassword utility in <install_dir>\config\bin\platform. See the JDA Platform Installation/Administration Guide for instructions on creating this file. If a value is specified in the CSM_ACL_RESOURCE_NAME column in the SRE_SERVICE_INFO table for the service that you want to run, the user name must also have execute permission for that service resource.

Create the process request XML file You must have an input XML file to request specific processes. The process request XML file must comply with the JDA Foundation schema definition file process_request.xsd in directory <install_dir>\config\xsd. Do not change the schema definition file. Otherwise, SCPO processes may not start.

The request XML requires the document root batchjob. This element has attributes for the XML namespace and schema definition file, process_request.xsd. You can use an optional attribute logFilePrefix to specify a log file. Use the required option element to specify application-specific parameters for SCPO batch processing. See Examples of process request XML files (on page 137) for more information. See the JDA Platform Installation/Administration Guide for a complete description of the valid elements and attributes for each process request XML file.

Note: When creating the process request XML file, use an XML editor that validates the file based on the schema definition file. Do not change the schema definition file.

Rules for the process request XML file Observe the following rules when you create a process request XML file.

• The batchJob element must appear once because it is the document root.



• The processRequest element can appear more than once in a file. This means you can launch more than one job in a single XML file. Processing stops if a job fails with a return code of 3 or higher.

• Use the processOptionSet element to specify the option set for the job.

• Use the processOptionOverrides element to override default values in the specified option set.

• If your XML file includes text strings containing characters that are used in the XML language, you must encode the characters so they are not interpreted as XML. XML provides an escape mechanism called "entities" that lets you encode special structures. For example, specify the following characters using the formats shown.

• & (ampersand):_&

• ' (apostrophe):_'

• > (greater than):_>

Examples of process request XML files SCPO provides a file, <install_dir>\config\bin\scpoweb\batchSample.xml, which contains sample XML for running many JDA application processes using SREBatchUtility. You can copy this file and tailor it for your use.

This section provides additional examples of process request XML files. When editing the files, change only the attribute values in quotation marks. See the JDA Platform Installation/Administration Guide for a complete description of valid elements and attributes.

Sample XML for the JDA Demand applications Import Forecast The following process request XML file for the JDA Demand Import Forecast process (Demand.ForecastImport) uses the optional element jobOptions. This process transfers forecast data that you loaded into the staging database table FORECASTRECORDIMPORT using IGP to either the FCST or FCSTDRAFT database table based on the optionSetName you specify in the XML file. You specify the forecast records that should be imported using the searchName attribute.

<?xml version='1.0' encoding='UTF-8'?>

<batchJob xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="process_request.xsd"

logFilePrefix="forecastinsert">

<processRequest processName="Demand.ForecastImport" nodeConfigurationName="DEFAULT">

<processOptionSet optionSetName="FcstInsert" enterpriseName="Manugistics" isPublic="true" />

<searches>

<search enterpriseName="Manugistics" searchName="ALLFCSTIMPREC" isPublic="true" />

</searches>

<jobOptions>

<traceCategoryRange>

<category>PROCESS_STATUS</category>

<category>PROCESS_DEBUG</category>



<category>APPLICATION_EXCEPTION</category>

</traceCategoryRange>

</jobOptions>

</processRequest>

</batchJob>

Delete Forecast The following process request XML file for the JDA Demand Delete Forecast process (Demand.ForecastDelete) also uses the optional element jobOptions.

<?xml version='1.0' encoding='UTF-8'?>

<batchJob xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="process_request.xsd"

logFilePrefix="forecastdelete">

<processRequest processName="Demand.ForecastDelete" nodeConfigurationName="DEFAULT">

<processOptionSet optionSetName="FcstDelete" enterpriseName="Manugistics" isPublic="true" />

<searches>

<search enterpriseName="Manugistics" searchName="ALL DMDUNITS" isPublic="true" />

</searches>

<jobOptions>

<traceCategoryRange>

<category>PROCESS_STATUS</category>

<category>PROCESS_DEBUG</category>

<category>APPLICATION_EXCEPTION</category>

</traceCategoryRange>

</jobOptions>

</processRequest>

</batchJob>

Start a node pool Before you can run SCPO batch processes, you must start the JDA Platform node pool manager. A node pool manager starts and manages a single node pool on a specific machine. Each running node is a daemon waiting to perform a service.

To start a pool of nodes, use the command startNodePoolManager. You can start the node pool manager on the JDA Platform Server or on a machine where the JDA Platform SRE is installed. You must specify the name of the pool that is associated with the service you want to start. You can also configure a node pool as a Windows service. See the JDA Platform Installation/Administration Guide for instructions on configuring and starting a node pool.



Run SREBatchUtility Run SREBatchUtility from a command line prompt to launch batch processes on the JDA Platform Server or on JDA Platform SRE machines. You must have a valid input XML file to request specific processes. The XML file must comply with schema definition file process_request.xsd in directory <install_dir>\config\xsd. Do not change the schema definition file. Otherwise, SCPO processes may not start.

Before you run batch processes using SREBatchUtility, you may want to validate your process request XML file against the schema definition file to ensure that the syntax is correct. Do this by running SREBatchUtility using the optional parameter validateOnly.

See the JDA Platform Installation/Administration Guide for procedures on running SREBatchUtility.

Note: Before you can run a process in batch mode, you must have defined at least one option set name for that process using the GUI. See the online help for information on creating process option sets.

Override default values The SRE_SERVICE_OPTION_SET table includes default values for each SCPO process, which are used each time a process runs. When you execute processes from a command line using SREBatchUtility, you can override selected default values in the option set by using the processOptionOverrides element in the input XML file. See the JDA Platform Installation/Administration Guide for more information.

Find and correct processing errors SRE provides several log files to help you analyze job activity, troubleshooting problems, and trace errors. After SREBatchUtility finishes, review the contents of these log files to get information about batch processing results. See the JDA Platform Installation/Administration Guide for the location of these files and a description of their contents.

Batch-only processes for Demand JDA Demand provides three processes that are available in batch mode only: Compress MLR Causal Factors, Delete History, and Compress Events. Run these processes using the JDA Platform SREBatchUtility. Sample process request XML files for these processes are included in <install_dir>\config\bin\scpoweb\batchSample.xml.

Compress MLR Causal Factors The Compress MLR Causal Factors process lets you compress the MLR causal factor values data. This function was previously controlled by an initialization variable. Run this process after loading new causal factors.

Before you can run this process, the Causal Factor Value table must be populated. Also, the Demand database must have a configuration code that supports the MLR algorithm. After you run this process, only the dates that turn a causal factor on and off are listed in the Causal Factor Value table.

For example, if a holiday, such as Christmas, is being used as a causal factor, only two dates per year need to be entered in the Causal Factor Value table: one date to activate the causal factors and a second date to deactivate the DFU. However, you can load every day of the year during the import. In this case, you can compress the causal factors.

The following example illustrates a sample Christmas causal factor before compression (assuming that 1/1/02 is the first date of history):

01/01/020

01/02/020



01/03/020

...

12/25/021

12/26/020

12/27/020

...

The following example illustrates a sample Christmas causal factor after compression (assuming that 1/1/02 is the first date of history):

01/01/020

12/25/021

12/26/020

12/25/031

12/26/030

12/25/041

12/26/040

Delete History The Delete History process lets you delete old history from the History table. Previously, the Calculate Model process deleted history that was older than the MaxHist column in the DFU table, but only for the Update Fourier option set. In SCPO version 7.2, the delete functionality was moved out of the Calculate Model process and into the new Delete History process, which supports all algorithms.

Before you can run the Delete History process, history older than the MaxHist duration in the DFU table must exist. After you run this process, any history records that are older than the maximum history duration are deleted from the History table.

Compress Events The Compress Events process lets you compress multiple event records with the same start date and duration into the smallest possible number of records. This process is designed to improve loading performance of the Demand Workbench, Override Manager, and Flexible Allocation pages after multiple events have been added to a DFU. This process can be run using data from the Hist, Fcst, and FcstDraft tables. Run the Compress Events process if you experience performance issues when using the Demand Workbench, Override Manager, and Flexible Allocation pages. The compressed records are stored with ID as COMPRESS-TIMESTAMP-INDEX.

The following example illustrates how the Compress Events process compresses the event records for a specific DFU.

Existing Override

1/1/2004 7d 300

Override forecast for this period to 500

1/1/2004 7d 300

1/1/2004 7d 200

Override forecast for this period to 100

1/1/2004 7d 300

1/1/2004 7d 200

1/1/2004 7d -400



When you run the Compress Events process for the DFU in this example, the three override records are compressed into a single record in the database:

1/1/2004 7d 100

Monitor and manage SCPO SRE processes JDA Platform provides a Web-enabled tool, Process Manager, for monitoring, managing, and running JDA application processes. The processes run on nodes configured by the system administrator. Process Manager provides an interface to the JDA Platform service runtime environment (SRE). Depending on the permissions assigned in Security Manager, users can view, manage, and run jobs. All users can view the status of their jobs. See the JDA Platform Installation/Administration Guide and the JDA Foundation online help for more information.

Caution: It is critical that you tune the default connection pool settings and the SRE defaults to run in your environment. See JDA Consulting Services for assistance in determining the proper settings.

Run non-SRE batch processes Some JDA applications use batch processes that run outside of the SRE framework. These processes are described in the following sections.

Load model files for Demand Decomposition, Shelf Price Optimization, Markdown Optimization, or Promotions Management Before running the Estimate Market Response Model and other processes, you must upload model specification files using the utility DRMModelUtil. Model specifications are in files, sometimes called GLINT files (Generalized Linear Modeling Toolkit). JDA provides the following sample GLINT files:

• calibrationModel.txt

• DecompositionModel.txt

• evaluationModel.txt

• NormalizationModel.txt

• Optimization_Default.txt

• Optimization_Simple.txt

• preaggregationmetrix.txt

• postaggregationmetrix.txt

• Price-Elasticity.txt

Note: If you imported the sample80.dmp database for training or testing, you should reload the sample model files.

Run the batch process DRMModelUtil.sh (UNIX) or DRModelUtil.bat (Windows) at the command line prompt, using the following syntax:

DRMModelUtil <Direction> <ModelFileName> <ModelID> <ModelColumnName>

All options for DRMModelUtil are required.

• Direction: Valid value is in or out. Use in to load model into database. Use out to export model to the specified file.

• Model File Name: File name for the model. You can specify the full path.

• Model ID: Identifies the model name in the database; for example, DEFAULTMODEL.

• Model Column Name: Use one of the following:

• CalibrationSpec



• DecompositionSpec

• NormalizationSpec

• OptimizationSpec

• EvaluationSpec

To load model specification files:



3. Use the following syntax to run DRMModelUtil:

DRMModelUtil <Direction> <ModelFileName> <ModelID> <ModelColumnName>

For example, if loading model file NormalizationModel.txt, where the ID is DEFAULTMODEL and the column name is NormalizationSpec, enter the following:

DRMModelUtil in c:\jdav800\config\drm\NormalizationModel.txt DEFAULTMODEL NormalizationSpec

When the process completes, the command line prompt returns.

4. If you encounter errors, verify the following items:

• Path to the model file

• Model ID, which must be unique

• Oracle database is running

SCPO Partial Database Extract Instructions The Partial Database Extract utility allows you to extract selected data from a database, and load it into a support or development database for issue replication and resolution.

Use the following steps to run the Partial Database Extract utility:

1. Run the DBExtractBatch file. It creates setup files and directories for the extract. It also populates primary keys for the DFUs or SKUs to be extracted to a temporary table in the database.

2. Run the export script. This script exports the data specified in the previous step into Oracle dump files.

3. Archive and compress all files, and send the resulting compressed archive file to JDA Support. The data files can then be imported into a database in Client Support or Development.

Note: If DBExtractBatch.cmd(<install_loc>/config/bin/scpoweb) is executed, the respective logs are written to dbExtractTrace.log file under <install_loc>/config/logs directory.

Features and Limitations Features of the SCPO Partial Database Extract utility are summarized below:

• You can extract the data based on the Search (either public or private) and the SRE Process (Job) ID.

• During extract, you can specifically include or exclude tables to be exported in a properties file.

Limitations using the SCPO Partial Database Extract utility are listed below:

• Supports only JDA Enterprise Supply Planning, JDA Demand, JDA Fulfillment, JDA Master Planning, and JDA Production and Sourcing Optimization.

• Supported only for the purposes of providing data to JDA Customer Support Services.



Instructions To extract data:

1. Open a command prompt or a shell prompt and navigate to the ..\config\bin\scpoweb directory.

2. Run the DBExtractBatch.cmd (Windows) or DBExtractBatch (UNIX) file with either the Process ID or the Search parameters.

DBExtractBatch <APPName> <Search> <scope> <Owner> <Parallel> <JDASysPWD>

or

DBExtractBatch <APPName> <processID> FAIL <Parallel> <JDASysPWD>

Parameter Search option Process ID option

Valid values

Application Name X X Demand or Fulfillment. This parameter is mandatory.

Search Name X The name of a valid public or private search that can be used to extract DFUs or SKUs. “Published To” searches are not supported. If the search name has spaces, use double-quotes around the search name.

Search Scope X PUBLIC or USER. Use PUBLIC for a search published to all. Use USER for private searches.

Owner X (private only) The name of the user who owns a private search. Needed only if a private search name is specified.

Process ID X The process ID (Job ID) for which you want to extract associated SKUs or DFUs. The process ID is displayed in the Process Manager in the Job ID column, or in the SRE_JOB_SUMMARY and related SRE tables.

Note: This option is valid only if SKUs exist in the PROCESSSKU or PROCESSDFU table, which occurs if a process fails.

Failed SKUs or DFUs

X When extracting using Process ID, use FAIL to retrieve only DFUs or SKUs that have failed actions.

Parallel X Optional parameter to specify the number of parallel server processes used in export and import operations.

JDA System Password

X Required JDA System password.

For example:

To extract all SKUs associated with the public search Region1SKUs, enter:

DBExtractBatch Fulfillment Region1SKUs PUBLIC JDA_SYSTEM

To extract all SKUs associated with the private search MySKUs, owned by JSmith, enter:

DBExtractBatch Fulfillment MySKUs USER JSmith JDA_SYSTEM

To extract all DFUs associated with the public search Boise DFUs, enter: JDA Supply Chain Planning and Optimization Installation/Administration Guide 143 © 1997-2014 JDA Software Group, Inc.- Confidential


DBExtractBatch Demand “Boise DFUs” PUBLIC JDA_SYSTEM

To extract all DFUs associated with the failed process ID 2800, enter:

DBExtractBatch Demand 2800 JDA_SYSTEM

To extract only DFUs that have failed actions in the failed process ID 2800, enter:

DBExtractBatch Demand 2800 FAIL JDA_SYSTEM

To extract SKUs using parallel option, enter:

DBExtractBatch Fulfillment ALL-SKUS PUBLIC 3 JDA_SYSTEM

To extract only DFUs that have failed actions in the failed process ID 2800 using parallel option, enter:

DBExtractBatch Demand 2800 FAIL 3 JDA_SYSTEM

After the DBExtractBatch file is run, the following folders and files are created in the current folder:

• the DBExtract folder, which contains the following folders and files:

• the exportparamfiles folder, which contains parameter files to be passed into the export.

• the importparamfiles folder, which contains parameter files to be passed into the import.

Note: The paramfiles created have Oracle passwords in them. You may choose to delete the param files after running DBExportScript.

• the DBExtractTrace.log file.

• the DBExportScript batch or shell file, which is used to export the data.

• the DBImportScript batch or shell file, which is used by JDA Support to import the data.

• the DisableConstraints.sql file.

• the EnableConstraints.sql file.

One of the following tables is created in the SCPO schema:

• DBEXTRACTDFU (if a Demand extract is performed)

• DBEXTRACTSKU (if a Fulfillment extract is performed)

1. Export the data using the following instructions:

The DBExportScript (Windows) or DBExportScript.sh (UNIX) script uses the Data Pump utility ‘expdp’. Data Pump is a server-based, and not client-based. Dump files, log files, and SQL files are accessed relative to the server-based directory paths, so that, appropriate file security can be enforced. Data Pump requires you to specify directory paths as directory objects. A directory object maps a name to a valid directory name on the same server as the database.

Before running the DBExportScript (Windows) or DBExportScript.sh (UNIX) script, a directory object must be created by a DBA or by any user with CREATE ANY DIRECTORY privilege. While exporting the dump using the DBExportScript (Windows) or DBExportScript.sh (UNIX) script, specify the directory object as a parameter.

For Example:

Unix:

CREATE DIRECTORY dumpdir AS '/oradev/dumps';

Windows:

CREATE DIRECTORY dumpdir AS 'D:\oradev\dumps';

Note: You have to grant read and write permissions on the directory dumpdir to system user.

For Example: GRANT READ, WRITE ON DIRECTORY dumpdir to SYSTEM.



Run the DBExportScript (Windows) or DBExportScript.sh (UNIX) script with the created directory object as a parameter.

Note: User should have execute permission on DBExportScript.

For Example:

Unix:

DBExportScript dumpdir

Windows:

DBExportScript.sh dumpdir;

The relevant dump files are extracted to the created directory folder in the same server as the database. Logs for the export are also written to the same folder.

For Example:

Unix:

The extracted dumps and log files can be found in '/oradev/dumps' directory.

Windows:

The extracted dumps and log files can be found in 'D:\oradev\dumps' directory.

2. Archive and compress the DBExtract folder and the created directory folder contents that you created in step 1 and send the resulting compressed archive file to JDA Support.

Update the configuration code after installing a new software license When you install SCPO, the installation generates a configuration code for SCPO based on the products that are enabled in the license file installed with JDA Platform. This configuration code is then used to configure the SCPO installation and database. If you update the license file after installation so that it changes the set of SCPO products that are licensed, you must update the generated SCPO configuration code. If you do not update the configuration code, you may receive a licensing error when starting the server.

After installing a new license, perform the following to re-create the configuration code:

1. Open a command line or shell prompt and navigate to the directory <install_dir>/config/bin/scpoweb (UNIX) or <install_dir>\config\bin\scpoweb (Windows).

2. Run the following to generate the configuration code:

runScpoTask generate_configcode

The updated configuration code is stored in config_code.txt in the <install_dir>\config\database\scpoweb directory.

3. Run the script set_config_code from the directory <install_dir>\config\database\scpoweb to update the database:

UNIX:

set_config_code.sh <wwfuser> <wwfpassword> <scpouser> <scpopassword>

Windows:

set_config_code.bat <wwfuser> <wwfpassword> <scpouser> <scpopassword>


Support for Demand Decision Support Workbench, Promotions Management Workbench, and Production and Sourcing Optimization Client on WebSphere

Appendix A. Support for Demand Decision Support Workbench, Promotions Management Workbench, and Production and Sourcing Optimization Client on WebSphere The Demand Decision Support Workbench and the Promotions Management Workbenches are applets that download to the client computer through the browser. The Production and Sourcing Optimization client is a Java application that is downloaded to the client using Java Web Start technology. If you are using WebSphere with any of these UIs, you need to configure the WebSphere server to enable communication between the client and the server.

To support the Decision Support Workbench and the Production and Sourcing Optimization client you need to:

• Set up WebSphere server (on page 146)

Set up WebSphere server If you are using the Demand Decision Support Workbench, the Promotions Management Workbench or Production and Sourcing Optimization, you need to configure the WebSphere server to be able to communicate with the client computers in order to download the applet or Production and Sourcing Optimization client. This section describes the steps to create a client key file and a client trust file that contains the certificates the client needs to download to load the applet-based workbenches or Production and Sourcing Optimization client.

Import certificates to the server trust store In an environment where you have multiple application servers, you can retrieve certificates from all servers into a single trust store, which you can then import into a common client trust file. To gather the certificates from multiple servers (whether clustered or standalone servers), go to the $WAS_HOME/profiles/<profile name>/bin directory and run the retrieveSigners.sh script to import signers data for all additional servers in the cluster:

retrieveSigners.bat NodeDefaultTrustStore ClientDefaultTrustStore -conntype SOAP -host <server host name> -port <SOAP_PORT_OF_SERVER> -user <Websphere admin user> -password <password>

For example:

retrieveSigners.sh NodeDefaultTrustStore ClientDefaultTrustStore -conntype SOAP -host jdasrv.corp.local -port 7006 -user appAdmin -password password

Note: The server you are retrieving the signers from must be running in order to retrieve the certificates. The script will import signers data into the file trust.p12 in the WebSphere profile.

Create the client trust store Use Key Management utility (ikeyman) from IBM to manage the client trust files. The utility requires that you have exported your DISPLAY environment to a valid X-window server. To run the utility, go to $WAS_HOME/bin and launch ikeyman.sh to view the IBM Key Management dialog box.

Create a client key file with a self-signed certificate On the IBM Key Management dialog box:

1. Using the top toolbar menu option, select Key Database File -> New. JDA Supply Chain Planning and Optimization Installation/Administration Guide 146 © 1997-2014 JDA Software Group, Inc.- Confidential


2. For the option Key Database type, select JKS from the drop-down list.

3. For the file name, enter ClientKeyFile.jks.

4. Click the Browse button next to the file name, select the path $WAS_HOME/profiles/<profile name>/etc and click OK. You are prompted to enter a password.

5. Enter the password in the Password and Confirm Password fields.

6. Click OK to exit the dialog box.

Note: The default password is WebAS; to use any other password, see Change key and trust store passwords (on page 148).

7. At the bottom right of the main screen, click New Self-Signed. The Create New Self-Signed Certificate is displayed.

8. For the Key Label field enter default.

9. For the Common Name field enter clientDSP.

If you are setting up for Production and Sourcing Optimization, enter psoclient.

10. For the validity period, change the field default value (the maximum value is 3650) and click OK.

Create a client trust file and import signers data From the IBM Key Management dialog box:

1. Using the top toolbar menu options, select Key Database File -> New.

2. For the option Key Database type, select JKS from the drop-down list.

3. For the file name enter ClientTrustFile.jks.

4. Click the Browse button next to the file name, select the path $WAS_HOME/profiles/<profile name>/etc and click Save.

5. Click OK to view the Password Prompt dialog box.

6. Enter the default password, WebAS, in the Password and Confirm Password fields, and click OK.

7. At the bottom right of the screen, click Import, to display the Open dialog box.

8. Select the Import Key, and for the option Key file type, select PKCS12 from the drop-down list.

9. Click the Browse button and go to the path $WAS_HOME/profiles/<profile name>/etc.

10. Select trust.p12 and click Open.

11. When prompted, click OK to display the Password Prompt dialog box.

12. Enter the trust.p12 password (the default password is WebAS) in the text field and click OK to view the Key Label List.

13. Select the default_signer and the certificates for any other servers that you want the client to connect to and click OK.

14. Select default_signer plus signers for any other servers in your cluster and click OK.

15. Click OK in the next screen to retain the defaults.

16. Use the top toolbar menu options to select Key Database File.

17. Click Exit to navigate away from the screen.

Distribute among applet/Production and Sourcing Optimization clients To distribute the self-signed certificate in ClientKeyFile.jks and the retrieved signers in ClientTrustFile.jks among the applet/Production and Sourcing Optimization clients:



1. In the $WAS_HOME/profiles/<profile name>/etc directory, verify there are two files with the names ClientKeyFile.jks and ClientTrustFile.jks

2. Create the directory <install_dir>/config/security if it does not already exist. Copy the two files ClientKeyFile.jks and ClientTrustFile.jks from the $WAS_HOME/profiles/<profile_name>/etc directory to the <Install_dir>/config/security directory. .

3. For applet, change directories to <Install_root>/config/bin/scpoweb and run the command runScpoTask prepare_applet.

For Production and Sourcing Optimization, run the command runScpoTask prepare_pso_war.

4. If you have not yet configured the server, configure the server using the instructions in the JDA Platform Installation/Adminstration Guide. If you have already configured the server, run the script deployEar or deployEarToCluster, based on the instructions in the JDA Platform Installation/Adminstration Guide.

5. For applet, verify that the jar was_security_applet.jar exists in $WAS_HOME/profiles/<profile name>/installedApps/<cell name>/WebWORKS.ear/scpoweb/dsworkbench.war/clientjars.

For Production and Sourcing Optimization, verify that the jar was_pso_security.jar exists in $WAS_HOME/profiles/<profile name>/installedApps/<cell name>/APP_CONFIG_NAME.ear/scpoweb/scpoweb.war/strategy/jws/config/lib.

Change key and trust store passwords If a password other than the default password, WebAS, is selected for ClientKeyFile.jks and ClientTrustFile.jks, the new password must be made available to the applet/Production and Sourcing Optimization client. The encrypted passwords are contained in a file named ssl.thinclient.props. Encrypt the new passwords, modify this file in the properties installation directory, and recreate the applet jar files with this new file using the following method:

1. Create the ClientKeyFile.jks and ClientTrustFile.jks with the required passwords. The password for these two files can be different.

2. Copy the file <Install_dir>/config/properties/ssl.thinclient.props to $WAS_HOME/profiles/<profile name>/bin/ssl.thinclient.encryptme.props.

3. Set the unencrypted password for ClientKeyFile.jsk and ClientTrustFile.jks in the new file ssl.thinclient.encryptme.props:

a. com.ibm.ssl.trustStorePassword=[new password 1]

b. com.ibm.ssl.keyStorePassword=[new password 2]

4. From this bin directory, run the following:

a. PropFilePasswordEncoder ssl.thinclient.encryptme.props com.ibm.ssl.trustStorePassword,com.ibm.ssl.keyStorePassword

5. Copy the new encrypted password lines over the matching ones in <Install_dir>/config/properties/ssl.thinclient.props

a. If encrypted properly, they are displayed as follows:

com.ibm.ssl.trustStorePassword={xor}FRsUNiwYLTo+K24=

com.ibm.ssl.keyStorePassword={xor}FRsUNiwYLTo+K20=

6. If you are still configuring security, return to those instructions.

7. For applet, if you have completed all planned configuration steps on the server, ensure that you finish the final steps to update the jars loaded by the client applet:

a. Change directories to <Install_root>/config/bin/scpoweb and execute the command runScpoTask prepare_applet.



b. Run the script deployEar or deployEarToCluster following the instructions in the JDA Platform Installation/Administration Guide.

c. Verify that the jar was_security_applet.jar exists in $WAS_HOME/profiles/<profile name>/installedApps/<cell name>/WebWORKS.ear/scpoweb/dsworkbench.war/clientjars.

For Production and Sourcing Optimization client, if you have completed all planned configuration steps on the server, ensure that you finish the final steps to update the jars loaded by the Production and Sourcing Optimization client:

d. Change directories to <Install_root>/config/bin/scpoweb and execute the command runScpoTask prepare_pso_war.

e. Run the script deployEar or deployEarToCluster following the instructions in the JDA Platform Installation/Administration Guide.

f. Verify that the jar was_pso_security.jar exists in $WAS_HOME/profiles/<profile name>/installedApps/<cell name>/APP_CONFIG_NAME.ear/scpoweb/scpoweb.war/strategy/jws/config/lib.


Patches

Appendix B. Patches SCPO applications allow both full patch installation and a partial patch installation.

In a full patch installation, a new installation binary is delivered. You install the patch to a new directory, and then deploy all related applications into that new directory. After installation, you need to customize based on your system requirements, as well as reconfigure your clustered configuration, if applicable.

The partial patch framework applies incremental patches to the installed JDA applications without the need to uninstall, re-install, and reconfigure the applications. Partial patch can support situations that require a code change. However, in some instances, certain changes require a full patch instead of a partial patch. JDA Support Services will advise you whether a particular fix requires a full patch installation or if a partial patch can be applied.

Partial patches are applied using a command line interface in the JDA installation. All patches are cumulative, whether the fix is a partial patch or full installation.

After either a full or partial patch is installed, you may need to complete manual steps in order to update your database or property files. See the patch documentation for specifics on making these changes.

Note: Production and Sourcing Optimization does not support partial patch for the Production and Sourcing Optimization client. Partial patch is supported only if Production and Sourcing Optimization client is deployed using Java Web Start. For more information on partial patch, see the JDA Platform Installation/Administration Guide.

Full patch A full patch is delivered as a new installation binary with the standard installation interface. To install a full patch, follow the instructions in the Installation section of this guide. If you have customized property files or other configuration files, you need to copy these files from the existing installation to the new patch installation to retain them in the customized form. You may also have to apply some changes manually to your properties files or database after the installation using instructions provided in the specific patch documentation.

JDA Supply Chain Planning and Optimization provides an additional database patch script in directory <install_dir>\config\database\scpoweb. It is not necessary to run this script unless specified in documentation for the JDA Supply Chain Planning and Optimization-based applications that you are using. The script is described for reference only.


Patches

Script Description

[Windows] apply_scpo_db_patches.cmd WWFUSER WWFPASSWORD SCPOUSER SCPOPASSWORD SYSTEMUSER SYSTEMPASSWORD

[Unix]

apply_scpo_db_patches.sh WWFUSER WWFPASSWORD SCPOUSER SCPOPASSWORD SYSTEMUSER SYSTEMPASSWORD

Here WWFUSER/WWFPASSWORD is the username/password of Foundation schema, SCPOUSER/SCPOPASSWORD is the username/password of SCPO schema, and SYSTEMUSER/SYSTEMPASSWORD is the Oracle system user and Oracle system password.

Please refer to the patch_readme.txt after installing the patch.

This utility will run all the SCPO database patches. If the current database patch is not the latest, then it will apply database patches to get the database to the latest patch.

After successful application of the patches, it will record an entry in CSM_SCHEMA_LOG.

Note: If -applydbpatches option is not used during partial patch installation, the apply_scpo_db_patches.cmd/sh must be run manually.

Partial patch See JDA Platform Installation/Administration Guide.

Revert patch If you want to revert back an installed patch to a prior patch level, use the revert patch script that is generated when you install a partial patch.

The revert file is created in the <Install_Dir>/backup directory and is named: revert_<type>_<patch_number>_<application>_<appserver>.zip

Note: The revert patch file is identical to a regular patch file. Every time you install a partial patch, a corresponding revert file is created. This can take you back to the patch level that existed before the installation of the partial patch. However, the partial patch framework does not create a second patch backup zip file when you revert the patch to the prior level.

Rollback full patch To rollback a full patch, follow the instructions provided in this section. You may also have to apply some changes manually to your properties files or database after the installation using instructions provided in the specific patch documentation.

JDA SCPO provides required scripts to roll back the database patches in the directory <install_dir>\config\database\scpoweb. It is not necessary to run this script unless specified in documentation for the JDA SCPO based applications that you are using. The script is described for reference only. JDA Supply Chain Planning and Optimization Installation/Administration Guide 151 © 1997-2014 JDA Software Group, Inc.- Confidential

Patches

Note: Before running the roll back script, go through the <application>_patch_readme.txt file to know the supported patch levels to which the patch can be reverted.

1. Run the rollback database patches with the current patch installation.

Script Description

[Windows] rollback__scpo_db_patches.cmd <foundation_user> <foundation_pw> <scpo_user> <scpo_pw> [<override>]

[UNIX] rollback__scpo_db_patches.sh <foundation_user> <foundation_pw> <scpo_user> <scpo_pw> [<override>]

Here <foundation_user> is the foundation database schema user and <foundation_pw> is the foundation database schema password.

<scpo_user> is the SCPO database schema user and <scpo_pw> is the SCPO database schema password.

Use the [<override>] option if you want to ignore the listings that are listed as part of pre-validation before the rollback and continue with the rollback.

This utility rolls back to the last applied SCPO patch. After successful rollback of the patches, it removes the patch entries from the SYS_LASTFIX table.

2. Install the appropriate full patch using the installation image. For more information, see "Full patch (on page 150)".

3. Run the postrollbackdbpatches script from the same installer that you have used in step 2.


Patches

Script Description

[Windows] post_rollback_scpo_db_patches.cmd <foundation_user> <foundation_pw> <scpo_user> <scpo_pw> <system_user> <system_pwd>

[UNIX] post_rollback_scpo_db_patches.sh <foundation_user> <foundation_pw> <scpo_user> <scpo_pw> <system_user> <system_pwd>

Here <foundation_user> is the foundation database schema user and <foundation_pw> is the foundation database schema password.

<scpo_user> is the SCPO database schema user and <scpo_pw> is the SCPO database schema password.

<system_user> is the database system user and <system_pwd> is the database system password.

This utility can be used to compile all the stored objects like packages, procedures, triggers and views after the patch rollback process.

4. If any validation message is displayed, check the dbpatch_rlbk_prevalidation.html file in the <Install_Dir>/config/bin/scpoweb directory. This file provides information on the list of records that are modified after applying the patch. The listed record should be verified and patch rollback should be run with the override option.

Rollback partial patch The patch roll back feature allows you to roll back the patch in the application and database level.

When you run this script, a confirmation message is displayed. If you type "Y", the patch is reverted to the prior patch. If you type "N", the patch is not reverted. It is also important to take a secondary backup of these revert files as in some cases the revert files in <Install_Dir>/backup are deleted accidentally.

Note: Before running the roll back script, go through the <application>_patch_readme.txt file to know the supported patch levels to which the patch can be reverted.

1. Copy the rollback file from the <Install_Dir>/backup directory which is named as revert_<type>_<patch_number>_<application>_<appserver>.zip to the <Install_Dir>/config/bin/platform directory.

2. Open a command or shell prompt, and navigate to the <Install_Dir>/config/bin/platform directory.

3. Run the following script:

Windows

installPatch <patch_file_location> -apply [-prompt(y,n)] [-rollbackdbpatches SystemPassword [-override]]

UNIX


Patches

installPatch <patch_file_location> -apply [-prompt(y,n)] [-rollbackdbpatches SystemPassword [-override]]

Parameters:

• SystemPassword is the password of the Oracle SYSTEM user.

• Use -rollbackdbpatches parameter only if you want to rollback database patches as a part of reverting the installed patch.

• Use -prompt parameter only if you want to revert the patch without being prompted, enter n.

• Use the –override option if you want to ignore the listings that are listed as part of pre-validation before the rollback and continue with the rollback.

• If the patch file is not in the bin/platform directory, specify the full path to the patch file as part of the patch_file_name. Provide the path without any spaces.

4. Verify that:

• If any validation message is displayed, check the dbpatch_rlbk_prevalidation.html file in the <Install_Dir>/config/database/scpoweb directory. This file provides information on the list of records that are modified after applying the patch. The listed record should be verified and patch rollback should be run with override option.

• The patch command is executed successfully and the "Build Successful" message is displayed on the command prompt.

• The file patchInstall_<type>_<application>_<patch_number>_<appserver>.log has no errors. This file is located in the <Install_Dir>/install directory.

5. Start the server and verify the patch type, label and the build date in the About page of the application.


Glossary

Appendix C. Glossary Access Control List (ACL): A list of resources associated with each role in Security Manager. The different types of resources are tables, columns, features, and entities. Depending on the resource type, the ACL permissions are create, read, update, delete, and execute.

American Standards Code for Information Interchange (ASCII): A seven-bit code comprising 128 characters. ASCII is a subset of Unicode. Some resource bundles use ASCII for double-byte languages such as Chinese and Japanese.

Administration server: In a cluster configuration, a single administration server is necessary to manage all managed servers in the cluster. The administration server can be on a separate machine or on the same machine as the managed servers. The cluster uses config.xml file on the admin server.

Batch: Commands performed on the server for specific processes, including data import and export. Different JDA products have unique batch processes.

Cluster: A group of physical machines configured to work together, usually for load balancing, failover, and performance improvement.

cluster-config.xml: Used in a cluster to configure the administration server with the names of the managed servers and the multicast IP address.

Security Manager: Provides a single point of security management. Security component installed on the server with the JDA Platform. Includes services and CSM database tables, which are part of the JDA Foundation schema.

config.xml: Configuration file containing the server name, port, protocol, database connection pools, security realm, and deployable EJBs.

Connection pool: Settings that control connections from the SCPO application to the SCPO database or JDA Foundation database.

Database: The relational database management system holding the JDA Foundation and SCPO database schemas.

Data domain: Rules for data types. Some JDA applications have predefined data domains that are loaded into the JDA Foundation schema during initialization or migration. Two types of data domains are used: enumeration (lists) and numeric ranges. An example of a data domain is minimum and maximum values for a field.

DAV: Data Access Validation

EDI: Electronic Data Interchange. A standard format for exchanging business data.

Entity: In Security Manager, a business object, usually consisting of more than one database table.

Enterprise: An organization, either the selling or customer organization. The host enterprise must create all other enterprises.

Enterprise hierarchy: The aggregate of all enterprises that follows a pyramid structure.

FE: Flexible Editor

Filter: A filter restricts a user's interface to data. A filter consists of one or more criteria. Managed in Security Manager.

Greenwich Mean Time (GMT): The default time zone in which the JDA Platform Server runs. JDA applications also use this time zone. Value is set in the startWebworkServer command file, but it should not be changed.


Glossary

Heartbeat: The process where node daemons send a message to the Node Group Manager indicating that they are active. Used in JDA Platform service runtime environment.

Interface Generation Program (IGP): A JDA Platform tool used to bulk load data into application schemas.

ISO-8859-1: An eight-bit code that extends ASCII. Defines 256 characters. Also called Latin 1. Some JDA applications use this as the default encoding in batch processing.

JDA Platform schema: Includes the CSM, SRE, metadata, and user preference tables. Creation and migration scripts are in the <install_dir>\config\database\platform directory.

JDA Platform SRE: A thin installation that provides the Java Runtime Environment (JRE) necessary for service runtime environment. It also provides command files to start node pools and launch processes.

JDBC: Java Database Connectivity. JDBC pools are created when the JDA Platform Server starts, unless the connection to the database fails. Connection pools are stored in config.xml file.

JMS: Java Message Service. Allows messaging between computers on a network.

JNDI: Java Naming and Directory Interface. The JNDI provider is a URL specified in webworks_config.xml file.

Job: A process with options configured that runs in service runtime environment.

JSP: Java Server Page. Method of delivering Web pages through servlets.

JVM: Java Virtual Machine. A Java virtual machine (JVM) is a computer that supports the Java programming language. UNIX and Windows platforms can run as a JVM.

Listen port: The port the JDA Platform Server listens on. Set during installation. Stored in the config.xml and webworks_config.xml files.

Managed server: A WebLogic or WebSphere instance in a cluster configuration, where one or more managed servers function together, usually for load-balancing. Each managed server requires JDA Platform and JDA applications. A single Windows or UNIX machine can have multiple managed servers.

Migration: Process of upgrading a database, including the schema and data, to a new version. Each phase of a migration must be completed successfully. JDA provides scripts to migrate a database.

Node: A service optimized for executing on one or more node daemons. Nodes perform units of work on a process in the service runtime environment. Nodes are managed in pools.

Node pools: A group of nodes on a machine. One or more node pools can run on a single machine.

Oracle Thin driver: The supported database driver used by JDA Platform and JDA applications. Installed with JDA Platform.

Partnership: A relationship between two enterprises that affects the data that can be shared. Managed in Security Manager.

Resource: A named object such as a table, column, feature, or entity. Each JDA application has a set of default resources that are loaded during database initialization or migration. Managed in Security Manager.

Resource bundle: A collection of files used by an application to provide web pages in the user's preferred language. Available in translated versions.

Role: A definition or profile of permissions for access to resources. Some JDA applications have predefined Roles. Managed in Security Manager.


Glossary

Schema: A database structure with tables, keys, and indexes for a specific JDA product. For example, the SCPO schema.

scpo_config.xml: Configuration file containing properties for SCPO. Includes settings that control connection pool, GUI, algorithms, and batch processing. Configured automatically during installation. Postinstallation changes usually require restarting the JDA Platform Server.

Service Runtime Environment (SRE): An architecture that provides parallel execution and distribution of processes on the JDA Platform Server or on JDA Platform SRE machines. SRE uses node daemons to run processes. The architecture can be configured to optimize performance of processes. SRE is independent of a cluster configuration.

Silent installation: An installation that uses a preconfiguration properties file and runs without displaying options in a graphical user interface. JDA Platform and JDA applications provide a properties file for silent installation. For installing WebLogic or WebSphere in a silent mode, you must create the properties file. When software is installed in silent mode, the uninstall is also silent. That is, it begins the uninstallation immediately.

SQL: Structured Query Language.

SQL*Plus: A command-line interface to the Oracle database.

UOM: Unit of measure.

User: A valid user account to access JDA applications. Manage user accounts in Security Manager.

User Defined Column (UDC): A feature designed to incorporate client-specific information into the database.

UTF-8: Universal Transformation Format. An eight-bit encoding that extends ASCII. Used as the default encoding for some parameters in the webworks_config.xml.

XML: eXtensible Markup Language. Format used for some configuration and input files. Also a file extension.

XSD: XML Schema Definition. Defines the structure and content of XML files used by SCPO.



Index . .profile • 98

A About JDA documentation set • 2 Access SCPO • 97 accessing

SCPO • 97 activating the SCPO components

new database • 26, 27 UNIX migration • 72

Add referential integrity to the SCPO database • 36, 46 Add subcomponents • 91, 97 ADMINID account • 26, 27 Alerts for pre_enable_compressed_data_storage • 92 Application-specific setup procedures for import processes

• 129 Apply price conversion factors for JDA Demand • 130

B batch commands

igp.cmd • 129 SREBatchUtility • 136, 139

Batch-only processes for Demand • 139 batchSample.xml • 137 Before you begin batch processing • 118 Before you begin enabling Compressed Data Storage • 91 Before you begin migration from DPEE to SCPO 8.1 • 79 Before you install • 9 browser cache, clearing • 7 browser windows, using multiple • 7 BuildConfiguration utility • 79, 97, 129

C Causal Factor Value table • 139 Change key and trust store passwords • 148 Change schema owners • 78 change_schema_name.sql script • 27, 78 changing

schema owners • 78 changing database connectivity information for IGP • 117 Check data for constraint violations • 40, 51, 56, 60, 65, 69,

72 Check data for invalid user-defined columns (UDCs) • 51 Check for errors • 125 Check the return code • 126

Check your data for invalid user-defined columns (UDCs) • 41

check_udc.log file • 41, 51 check_udc.sql • 41, 51 Clean up Flexible Editor instances • 75 clustered environment, running SCPO in • 7 Command line format for IGP • 122 Components that are not migrated • 86 Compress Events • 140 Compress MLR Causal Factors • 139 Compress MLR Causal Factors batch process, JDA

Demand • 139 compressing MLR causal factors • 139 config.xml file • 79, 97 config.xml.body.ear.body.scpoweb file • 85 config.xml.body.ear.body.scpoweb.demand file • 79 config.xml.body.scpoweb file • 79, 85 config.xml.body.scpoweb.oracle file • 79 Configure application server • 98 Configure database • 10 Configure Decision Support Workbench for a cluster • 115 Configure SRE for SCPO processes • 114 Configure the environment - SRE • 98 Configure the environment - UNIX • 98 Configure the server • 98 configuring

.profile for SCPO • 98 Configuring CDS • 95 CONSTANT keyword for SQL*Loader • 119, 125 continuous jobs • 99 Continuous Jobs • 99 Conventions used in this guide • 1 conventions, typographical • 1 convert_to_char_semantic.log file • 42, 52 convert_to_char_semantic.sql script • 42, 52 CPLEX • 5, 17 cr_igp_ts_user.bat file • 117, 119, 131 cr_igp_ts_user.ksh • 117, 119 cr_igp_ts_user.ksh script • 131 cr_scpo_ts_user.log file • 11 cr_scpo_ts_user.sql script • 11 Create a client key file with a self-signed certificate • 146 Create a client trust file and import signers data • 147 Create a SCPO tablespace • 11 Create an empty database • 26 Create the 8.1 schema • 26 Create the client trust store • 146 Create the IGP user • 119



Create the Integration Jobs table • 119 Create the process request XML file • 136 Create the SCPO database schema objects • 25 Create the SCPO schema-UNIX or Windows • 25 Create the SCPO tablespaces • 11 create_scpo_database.log file • 35, 45 create_scpo_database.sql script • 11 creating

sample database • 27 SCPO user • 11 tablespaces • 11

CSM_APPLICATION table • 21 csmload_scpo72.log file • 35, 45 customer support • 4 Customize the import process • 117

D data domain, defined • 155 Data Manipulations during Migration • 95 Database object name conventions • 123 database object naming conventions • 123 databases

migrating from 6.1.x under UNIX • 33 migrating from 6.1.x under Windows • 44 migrating from 6.2 under UNIX • 35 migrating from 6.2 under Windows • 45 migrating from 7.0 under UNIX • 37 migrating from 7.0 under Windows • 48 migrating from 7.1 under UNIX • 39 migrating from 7.1 under Windows • 50 migrating from 7.1.1 under UNIX • 40 migrating from 7.1.1 under Windows • 51 migrating from 7.2 • 54 migrating from 7.2.0.1 • 56 migrating from 7.2.1 • 58 migrating from 7.2.1.1 • 60 migrating from 7.3 • 63 migrating from 7.3.0.1 • 65 migrating from 7.4.0.0 • 68 migrating from 7.4.1.0 • 72 names, specifying • 2

db_storedobjects.bat • 26, 27 db_storedobjects.bat file • 72 db_storedobjects.ksh • 26, 27, 72 db_storedobjects.log file • 26, 27, 72 dbms_stats.gather_database_stats Oracle utility, running •

36, 42, 46, 52, 89 DBParam table, editing • 36, 46

default date format for Oracle • 25, 31, 87 Delete Forecast • 138 Delete Forecast XML file • 138 Delete History • 140 Delete Old History batch process, JDA Demand • 140 deleting old history data • 140 delimiters

for searches • 83 Demand Management Foundation (DMF) • 99 Deploy Replenishment Workbench for JDA Enterprise

Supply Planning, JDA Fulfillment, and JDA Master Planning • 96

Deploy SCPO processes • 99 DFU table • 140 directories

for Windows server • 17 specifying in print • 2

Directories • 2 directory structure • 17

SCPO SRE on UNIX and Windows • 21 Disable CDS • 96 Disable JDA Fulfillment Net Change feature • 129 Disable the DPEE migration component • 85 Distribute among applet/Production and Sourcing

Optimization clients • 147 dm_addreferentialintegrity.bat file • 46 dm_addreferentialintegrity.ksh script • 36 dm_addreferentialintegrity.out file • 36, 46 dm_checkconstraints.bat • 51 dm_checkconstraints.ksh • 40, 56 dm_checkconstraints.out file • 40, 51 dm_checkconstraints.out log file • 56 dm_checkconstraints721.bat • 56 dm_checkconstraints721.out log file • 56 dm_checkconstraints74.bat • 65 dm_checkconstraints74.ksh • 65 dm_checkconstraints74.out • 65 dm_checkconstraints741.bat • 69 dm_checkconstraints741.ksh • 69 dm_checkconstraints741.out • 69 dm_deletebadrows.sql script • 36, 46 dm_deletepertable.sql script • 36, 46 dm_DemandWorkbenchInstances.log file • 37, 48 dm_DemandWorkbenchInstances.sql script • 37, 48 dm_desktop2tasklist.sql script • 76 dm_dumpfe71.bat file • 48 dm_dumpfe71.ksh • 37 dm_dumpfe71.out file • 37, 48 dm_enablefkconstraints.sql script • 36, 46



dm_fe2scpo71.bat file • 48 dm_fe2scpo71.ksh • 37 dm_fe2scpo71.out file • 37, 48 dm_ForecastOverrideInstances.log file • 37, 48 dm_ForecastOverrideInstances.sql script • 37, 48 dm_insert_csm_objects.sql script • 76 dm_migrate_data_selections.sql script • 76 dm_migrate_feexpressions.sql script • 76 dm_migrate62.bat file • 44 dm_migrate62.ksh • 33 dm_migrate62.out file • 33, 44 dm_migrate70.bat file • 48 dm_migrate70.ksh • 37 dm_migrate70.out file • 37, 48 dm_migrate71.bat file • 48, 50 dm_migrate71.ksh • 37, 39 dm_migrate71.out file • 37, 39, 48, 50 dm_migrate72.bat file • 52 dm_migrate72.ksh • 42 dm_migrate72.log file • 42, 52 dm_migrate7201.bat file • 54 dm_migrate7201.ksh script • 54 dm_migrate7201.out • 54 dm_migrate721.bat script • 56 dm_migrate721.ksh script • 56 dm_migrate721.log • 56 dm_migrate7211.bat script • 58 dm_migrate7211.ksh script • 58 dm_migrate7211.log • 58 dm_migrate73.bat script • 60 dm_migrate73.ksh script • 60 dm_migrate73.log • 60 dm_migrate7301.bat script • 63 dm_migrate7301.ksh script • 63 dm_migrate7301.log • 63 dm_migrate74.bat script • 65 dm_migrate74.ksh script • 65 dm_migrate74.log • 65 dm_migrate741.bat script • 69 dm_migrate741.ksh script • 69 dm_migrate741.log • 69 dm_migrate742.bat script • 72 dm_migrate742.ksh script • 72 dm_migrate742.log • 72 dm_refint9_enablefkconstraints.log file • 36, 46 dm_scpo2csmuser.sql script • 76 dm_scpoweb_6201.bat file • 45 dm_scpoweb_6201.ksh • 35

dm_scpoweb_6201.out file • 35, 45 dm_showbadrows.log file • 36, 46 dm_showbadrows.sql script • 36, 46 dm_showbadrows72.log file • 40, 51 dm_showbadrows721.log file • 56 dm_showbadrows74.log • 65 dm_showbadrows741.log • 69 dm_uvp2fe.sql script • 76 DMF (Demand Management Foundation) • 99 documentation

using • 2 Download and run the Production and Sourcing

Optimization Client • 23 DPEE migration process • 79

description of steps • 81 disabling the components • 85 enabling the components • 79 overview • 81 post-migration procedures • 84 preparing for • 83 required database level • 79 running the process • 84 setting up the properties file • 84

DPEEMigration.log file • 84 DPEEMigration.properties file • 84 DPEEMigrationError.log file • 84 DRMModelUtil batch utility • 141 DRMModelUtil utility • 141 DTD files

igp_schema.dtd • 120 DVD and electronic image • 1

E Enable and configure CDS • 94 Enable CDS • 94 Enable the DPEE migration component • 79 enroll_app_schema.log file • 26, 27, 42, 52, 54, 56, 58, 60,

63, 65, 69, 72, 78 enroll_app_schema.sql script • 26, 27, 42, 52, 54, 56, 58,

60, 63, 65, 69, 72, 78 enroll_igp_schema.sql • 117 enterprise hierarchy • 155 enterprises • 155 environment variables

UNIX • 98 Error table • 117, 127 errors

foreign key constraint validations • 36 in the manufs.log • 33



ORA-00001 • 37, 48 ORA-00942 • 119 ORA-00955 • 27 ORA-02298 • 36, 46 ORA-02443 • 36, 46 Oracle • 31 UNIX hot-key • 19, 21, 23

Examples of process request XML files • 137 Execute the command • 120

F Features and Limitations • 142 Find and correct processing errors • 139 first_login_time_window property • 27 Format and parameters for StrategyMigration • 89 Full patch • 150

G Gather information • 10 Generate Data Load Scripts • 124 Generate interface tables and stored procedures • 122 Generate the input XML file • 120 generating IGP interface tables and stored procedures • 122 gensys_migration.sql script • 41, 42, 51, 52 Get additional help from JDA • 4 GLINT files • 141 Glossary • 155 GMT • 155 Guidelines for browser usage • 7 Guidelines for the SCPO database • 33

H help

customer support • 4 hierarchy entries, importing for JDA Demand • 131 hierarchy_entry.ctl • 131 hierarchyentry_igp.xml • 131 High-level roadmap of installation • 1 history

types • 37, 48 history data, deleting old • 140 How data is migrated • 81 How IGP works with SCPO • 117 How SCPO uses SRE • 99

I IGP

assigning a unique job ID • 119

changing database connectivity information • 117 checking for errors • 125 command line arguments • 122 creating an IGP user and tablespace • 117 creating the IGP user • 119 creating the Integration Jobs table • 119 disabling the Net Change feature • 129 generating the input XML file • 120 generating the interface tables and stored procedures •

122 loading data into the interface tables • 125 renaming a Job ID • 127 resolving errors • 127 return codes • 126 running • 121 running in a shielded environment • 117 security • 117 short table names • 123 specifying a default job ID • 119, 125 using Oracle views • 120 using with UDCs • 118

IGP example • 122 igp_init.cmd • 119 igp_schema.dtd file • 120 igpjobmanager status utility, running • 125 IGPProperty.properties.body.scpoweb file • 117, 129 IGPXMLGen.cmd/.sh • 120 IGPXMLGenerator utility • 118, 120 Import a sample database • 27 Import certificates to the server trust store • 146 Import data • 117 Import data into the interface tables • 125 Import Forecast • 137 Import Forecast process for JDA Demand • 134 Import Forecast XML file • 137 Import JDA Demand DDE data • 133 Import JDA Demand forecast data • 134 Import JDA Demand hierarchy entries • 131 importing

forecast data • 134 hierarchy entries • 131

importing data • 117 rules • 128

input, specifying what to type • 2 Install Demand Field Sales mobile application • 24 Install JDA Production and Sourcing Optimization Client •

23 Install SCPO • 14



Install SCPO SRE • 18 Install SCPO SRE using the graphical interface • 19 Install the SCPO software • 13 Install the SCPO software on UNIX and Windows • 14 Installation • 13 Installation checklist • 13 Installed program directory structure • 17 Installed program directory structure–SCPO SRE • 21 installing

preparing for on Windows • 10 SCPO SRE • 18

Instructions • 143 Integration Jobs table, creating • 119 INTJOBS table • 119

J JDA Production and Sourcing Optimization process • 115 JDA server

accessing • 97 JDA Strategy 6.2 migration process • 86 JDA Support Services • 4 JDA_SCPO_7.4.1_InstallLog.xml • 14 JDA_SCPO_7.4_InstallLog.xml • 16 JDA_SCPO_SRE_7.4.2_InstallLog.xml • 19 JDBC Thin driver • 117 job_queue_processes Oracle parameter, setting • 11, 32, 35,

45

L Legal notice • i Load data • 121 Load model files for Demand Decomposition, Shelf Price

Optimization, Markdown Optimization, or Promotions Management • 141

load_csm_71.out file • 37, 48 load_csm_71.sql • 37, 48 load_csm_711.out file • 39, 50 load_csm_711.sql • 39, 50 load_csm_7201.log file • 54 load_csm_7201.sql • 54, 56 load_csm_721.ksh • 56 load_csm_721.out file • 56 load_csm_7211.bat • 58 load_csm_7211.ksh • 58 load_csm_7211.log file • 58 load_csm_73.bat • 60 load_csm_73.ksh • 60 load_csm_73.out file • 60 load_csm_7301.bat • 63

load_csm_7301.ksh • 63 load_csm_7301.out file • 63 load_csm_74.bat • 65 load_csm_74.ksh • 65 load_csm_74.out file • 65 load_csm_741.bat • 69 load_csm_741.ksh • 69 load_csm_741.out file • 69 load_csm_742.bat • 72 load_csm_742.ksh • 72 load_csm_742.out file • 72 loading model specification files • 141 log files

check_udc.log • 41, 51 convert_to_char_semantic.log • 42, 52 cr_scpo_ts_user.log • 11 create_scpo_database.log • 35, 45 csmload_scpo72.log • 35, 45 db_storedobjects.log • 26, 27, 72 dm_addreferentialintegrity.out • 36, 46 dm_checkconstraints.out • 40, 51, 56 dm_checkconstraints721.out • 56 dm_DemandWorkbenchInstances.log • 37, 48 dm_dumpfe71.out • 37, 48 dm_fe2scpo71.out • 37, 48 dm_ForecastOverrideInstances.log • 37, 48 dm_migrate62.out • 33, 44 dm_migrate70.out • 37, 48 dm_migrate71.out • 37, 39, 48, 50 dm_migrate72.log • 42, 52 dm_migrate7201 • 54 dm_migrate721 • 56 dm_migrate7211 • 58 dm_migrate73 • 60 dm_migrate7301 • 63 dm_migrate74 • 65 dm_migrate741 • 69 dm_migrate742 • 72 dm_refint9_enablefkconstraints.log • 36, 46 dm_scpoweb_6201.out • 35, 45 dm_showbadrows.log • 36, 46 dm_showbadrows72.log • 40, 51 dm_showbadrows721.log • 56 DPEEMigration.log • 84 DPEEMigrationError.log • 84 enroll_app_schema • 26, 27, 42, 52, 54, 56, 58, 60, 63,

65, 69, 72, 78 load_csm_71.out • 37, 48



load_csm_711.out • 39, 50 load_csm_7201.log • 54 load_csm_721.out • 56 load_csm_7211.log • 58 load_csm_73.out • 60 load_csm_7301.out • 63 load_csm_74.out • 65 load_csm_741.out • 69 load_csm_742.out • 72 manufs.log • 33, 44 ManugisticsPkg.log • 27

M manufs.exe

UNIX • 33 Windows • 44

manufs.log file • 33, 44 manufs_grants.sql • 33, 44 ManugisticsPkg.log file • 27 ManugisticsPkg.sql script • 27 memory requirements

for JDA PSO process • 115 Menu or registry path • 2 Migrate a version 6.1.x database to 6.2 - UNIX • 33 Migrate a version 6.1.x database to 6.2 - Windows • 44 Migrate a version 6.2 database to 7.0 - UNIX • 35 Migrate a version 6.2 database to 7.0 - Windows • 45 Migrate a version 7.0 database to 7.1 - UNIX • 37 Migrate a version 7.0 database to 7.1 - Windows • 48 Migrate a version 7.1 database to 7.1.1 - UNIX • 39 Migrate a version 7.1 database to 7.1.1 - Windows • 50 Migrate a version 7.1.1 database to 7.2 - UNIX • 40 Migrate a version 7.1.1 database to 7.2 - Windows • 51 Migrate a version 7.2 database to 7.2.0.1 • 54 Migrate a version 7.2.0.1 database to 7.2.1 • 56 Migrate a version 7.2.1 database to 7.2.1.1 • 58 Migrate a version 7.2.1.1 or 7.2.2 database to 7.3 • 60 Migrate a version 7.3 database to 7.3.0.1 • 63 Migrate a version 7.3.0.1 database to 7.4.0.0 • 65 Migrate a version 7.4.0.0 database to 7.4.1 • 68 Migrate a version 7.4.1 database to 7.4.2 • 72 Migrate and import a previous 7.x dump • 32 Migrate Compressed Data Storage (CDS) • 91 Migrate from DPEE to SCPO 8.1 - UNIX or Windows • 79 Migrate from JDA Strategy 6.2 to SCPO 8.1 - UNIX or

Windows • 86 Migrate SCPO schema from 7.4.2 or later to version 8.1 •

75

Migrate Shelf Connected Supply Chain Report Model to Collaborative Shelf Planning and Analytics • 115

Migrate the SCPO database to 7.0 • 37, 48 Migrate the SCPO schema from 6.x, or 7.1.x to 7.2 - UNIX

• 33 Migrate the SCPO schema from 6.x, or 7.1.x to 7.2 -

Windows • 44 Migrate the SCPO schema from 7.2.x, 7.3.x, 7.4.0, 7.4.1 to

8.1.0.0 - UNIX or Windows • 54 Migrate the Strategy 6.2 database • 89 Migrate to 7.2 • 42, 52 Migrate to 7.2.1 • 57 Migrate to 7.2.1.1 • 58 Migrate to 7.3 • 60 Migrate to 7.3.0.1 • 63 Migrate to 7.4.0.0 • 66 Migrate to 7.4.1 • 69 Migrate to 7.4.2 • 72 migrate_relatedLinkToDynamicNav.sql script • 42, 52 migrate_relatedProcessToDynamicNav.sql • 42, 52 MigrateDPEE.cmd/.sh • 84 migrating

from 6.1.x under UNIX • 33 from 6.1.x under Windows • 44 from 6.2 under UNIX • 35 from 6.2 under Windows • 45 from 7.0 under UNIX • 37 from 7.0 under Windows • 48 from 7.1 under UNIX • 39 from 7.1 under Windows • 50 from 7.1.1 under UNIX • 40 from 7.1.1 under Windows • 51 from 7.2 • 54 from 7.2.0.1 • 56 from 7.2.1 • 58 from 7.2.1.1 • 60 from 7.3 • 63 from 7.3.0.1 • 65 from 7.4.0.0 • 68 from 7.4.1.0 • 72 from DPEE • 79 from JDA Strategy 6.2 • 86

migrating from 7.2 under UNIX, under Windows • 54

Migration considerations • 86 Migration guidelines • 31 Migration of Plan Analysis instances to the Replenishment

Workbench • 96 Migration process overview • 81



Migration steps • 81 MLR causal factors, compressing • 139 model specification files, loading • 141 Modify the default configuration for processes • 99 Monitor and manage SCPO SRE processes • 141 monitoring and managing SCPO SRE processes • 141 Multi-action Jobs • 100 multiple browser windows, guidelines for • 7

N Net Change feature, disabling for import • 129 new_csm_load.sql script • 35, 45 NLS_DATE_FORMAT setting • 25

O Online help • 3 Optimize the database post-migration • 91 Optional values • 2 optional values, specifying • 2 Oracle

default date format • 25, 31, 87 errors, ignoring • 31

Oracle database names • 2 Oracle errors

ORA-00001 • 37, 48 ORA-00942 • 119 ORA-00955 • 27 ORA-02298 • 36, 46 ORA-02443 • 36, 46

Oracle views for IGP • 120 Other supported configurations • 7 Output from the command • 120 Override default values • 139 Overview • 1 Overview of the upgrade process • 31

P Partial patch • 151 Patches • 150 placeholder records in the SCPO database • 25, 33 Post-installation checklist • 25 Post-installation tasks • 25 Post-migration procedures • 84 post-migration scripts, running • 51, 76 Pre-installation checklist • 10 Pre-installation tasks • 10 Pre-migration preparation • 83, 89 Prepare an existing database for a SCPO tablespace • 11

Prepare an Oracle database for SCPO • 10 Prepare data • 83 Prepare SCPO Client/Server 6.2 for migration to SCPO

Web 7.0 • 35, 45 Prepare to load SCPO data • 118 Pre-requisites • 9 price conversion factors, applying for JDA Demand • 130 process_request.xsd file • 136 Provide feedback on this document • i PSO

uninstalling the Client software • 24 upgrading the Client software • 24

R referential integrity • 36, 46, 117, 128 Release notes • 3 Rename a job ID • 127 Resolve errors • 127 return codes for IGP • 126 Revert patch • 151 Rollback full patch • 151 Rollback partial patch • 153 rules

importing data • 128 Rules for running StrategyMigration • 89 Rules for the process request XML file • 136 Rules on importing data • 128 Run batch processes • 136 Run non-SRE batch processes • 141 Run post-migration scripts for 6.x migrations(optional) • 76 Run SREBatchUtility • 139 Run the igpjobmanager status utility • 125 Run the Interface Generation Program (IGP) • 121 Run the migration • 84 Run the script • 123 Run the StrategyMigration utility • 90

S Sample control file for forecast data import • 135 Sample data file for forecast data import • 135 Sample output • 90 Sample XML for the JDA Demand applications • 137 sample742.dmp file • 11 scenario (SIM_*) tables • 128 schema

changing owners • 78 SCPO

accessing • 97



environment variables • 98 installing • 14 SCPO database • 9 silent installation • 16

SCPO architecture • 5 SCPO database • 5 SCPO Partial Database Extract Instructions • 142 SCPO Process Details • 100 SCPO user

creating • 11 SCPO.dburl property • 117 scpo.properties file • 98 scpo_grants.sql script • 26, 56, 58, 60, 63, 65, 69, 72 scpo_igp.xml • 122 SCPOConstraintCreationErrors table • 36 scpodata tablespace

creating under UNIX • 11 scpoindex tablespace

creating under UNIX • 11 security

for IGP • 117 Set up the properties file • 84 Set up WebSphere server • 146 set_config_code.bat • 26, 27, 72 set_config_code.sh • 26, 27, 72 short table name • 123 silent installation

SCPO • 16 Silent installation for SCPO • 16 Silent installation for SCPO SRE • 20 Simplify Data Import • 123 simulation tables • 123 SKU

NetchgSw flag • 129 Software implementation advisement • i software requirements

Windows • 9 Software support • i SQL*Loader CONSTANT keyword • 119, 125 SRE

configuring SCPO processes • 114 deploying SCPO processes • 99 modifying the default configuration for processes • 99 monitoring and managing SCPO processes • 141 understanding how SCPO uses • 99

SRE_ NODE_CONFIG table • 115 SRE_NODE_POOL table • 115 sre_total_wait property • 128

SREBatchUtility described • 136, 139

Start a node pool • 138 Strategy 6.2 migration process overview • 87 StrategyMigration.cmd • 89, 90 subcomponents, adding • 91, 97 Support for Demand Decision Support Workbench,

Promotions Management Workbench, and Production and Sourcing Optimization Client on WebSphere • 146

Supported configuration for SCPO processes • 101 System architecture • 5

T table(s)

DBParam, editing • 36, 46 tablespaces

recommended size for sample database • 27 Technical documentation • 3 timeout setting

adjusting sre_total_wait • 128 for JDA PSO process • 115

time-phased conversion factors (TPCFs) • 130 Type 99 records

creating • 37, 48 removing from the SCPO database • 37, 48

U UDCs

checking your database for invalid • 41 Uninstall Production and Sourcing Optimization Client • 24 Uninstall SCPO • 21 Uninstall SCPO SRE • 23 Uninstall the software • 21 uninstall_wcif.sql script • 121 uninstalling

JDA PSO Client software • 24 SCPO SRE • 23

UNIX environment variables • 98

UNIX hot-key errors • 19, 21, 23 Update the configuration code after installing a new

software license • 145 update_app_synonyms.sql script • 27, 32, 78 Upgrade Production and Sourcing Optimization Client

software • 24 Upgrade to SCPO 8.1 • 30 upgrading

JDA PSO Client software • 24 under UNIX • 31



upgrading from 7.2 under UNIX, under Windows • 54

Use SRE to launch batch processes • 136 User input • 2 user-defined columns

loading data into • 118 UTF8 character set • 25 Utilities and common tasks • 117

V Validating the existing data • 91 Variables • 2 variables, specifying • 2

W wcif.sql script • 121 webworks_config.xml • 128 Windows client setup for JDA Production and Sourcing

Optimization • 12 Work with tiered costs • 87

X XML files

batchSample.xml • 137 Delete Forecast • 138 hierarchyentry_igp.xml • 131 Import Forecast • 137 JDA_SCPO_7.4.1_InstallLog.xml • 14 JDA_SCPO_SRE_7.4.2_InstallLog.xml • 19 scpo_igp.xml • 122 webworks_config.xml • 128


Date post:	19-Dec-2015
Category:	Documents
Upload:	ssaishyam
View:	316 times
Download:	17 times

Scpo Installadmin Guide

Documents