Platform Installadmin en

Installation/Administration Guide
JDA Platform
Release 2016.1.0.16
Legal notice
Rights to the content of this document
Copyright 1996-2017 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.
Trademark, Registered, and Service Mark notices
JDA is a registered trademark of JDA Software Group, Inc. JDALearn is a service mark of JDA Software Group, Inc.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. SAP and SAP HANA are trademarks or registered
trademarks of SAP SE in Germany and in several other countries. Microsoft, Encarta, MSN, and Windows are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Autodesk and Revit are
registered trademarks or trademarks of Autodesk, Inc., in the USA and other countries.
All other product names and company names may be the trademarks/service marks or registered trademarks/service marks of
their respective owners.
Throughout this document, certain designations may be used that are trademarks that identify the goods of third parties.
Although this document attempts to identify the particular trademark owner of each mark used, the absence of a trademark
symbol or other notations should not be taken as an indication that any such mark is not registered or proprietary to a third
party. Use of such third-party trademarks is solely for the purpose of accurately identifying the goods of such third party.
The information contained herein is subject to change without notice.
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 United States and foreign patents. Please see https://www.jda.com/legal/patents.
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:publication_services@jda.com) and they will
be forwarded to the appropriate development teams for review and consideration in a future release.
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 JDAs 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, enabling
you to realize an evolving return on your software investment. Through the JDA Customer Support
website (http://support.jda.com/), you can access a comprehensive summary of your licensed
applications and their current levels of support.
Table of Contents
Chapter 1. Overview ........................................................................................................ 7
A high-level roadmap of installation ............................................................................... 7
Architecture and concepts ............................................................................................. 8
Contents of the installation media .................................................................................. 8
Language support ........................................................................................................ 8
Get additional help from JDA ......................................................................................... 9
Chapter 2. Pre-requisites ............................................................................................... 11

Before you install ....................................................................................................... 11
System requirements ........................................................................................ 11
Gather information for the installation ................................................................. 16
Preconfiguration requirements for a clustered configuration ............................................ 17
Preconfiguration requirements WebLogic cluster ................................................... 17
Preconfiguration requirements WebSphere cluster ................................................ 17
Chapter 3. Pre-installation tasks ................................................................................... 19

Pre-installation checklist ............................................................................................. 19
Set up a Windows server ............................................................................................ 19
Install required tools and patches ....................................................................... 19
Set up a UNIX server ................................................................................................. 20
Install required tools and patches ....................................................................... 20
Create a JDA group ........................................................................................... 20
Create a JDA user ............................................................................................. 20
Set environment variables ................................................................................. 21
Set up Oracle ............................................................................................................ 21
SQL*Plus ......................................................................................................... 21
Oracle server and client ..................................................................................... 21
Create an Oracle database ................................................................................. 22
Install WebLogic application server on Windows ............................................................ 25
Install WebLogic application server on UNIX .................................................................. 26
Install WebSphere application server............................................................................ 27
Switch to use the Java7.1 SDK as the default Java with WebSphere ........................ 29
Validate the WebSphere installation with Java7 .................................................... 29
Create a WebSphere server profile ...................................................................... 30
Create a WebSphere profile for a non-clustered environment ................................. 31
Create WebSphere profiles for a clustered environment ......................................... 31
Chapter 4. Installation ................................................................................................... 33

Installation values required ......................................................................................... 33
Install Platform.......................................................................................................... 34
Silent installation for JDA Platform ...................................................................... 39
Install Platform SRE ................................................................................................... 45
Install JDA Platform SRE .................................................................................... 45
Install JDA Platform-based application SRE installations ......................................... 46
Silent installation for JDA Platform SRE ................................................................ 47
Cluster setup ............................................................................................................ 49
On WebLogic .................................................................................................... 49
On WebSphere ................................................................................................. 49
Installed program directory structure ........................................................................... 50
Access the JDA Platform Server ................................................................................... 51
Set browser properties ...................................................................................... 52
Synchronize users between ABPP and Foundation User Stores ......................................... 53
Export users..................................................................................................... 53
Import users .................................................................................................... 54
Uninstall ................................................................................................................... 57
Uninstall JDA Platform ....................................................................................... 57
Uninstall JDA Platform SRE................................................................................. 59
Remove Windows services ................................................................................. 60
Chapter 5. Post-installation tasks .................................................................................. 61

Post-installation checklist............................................................................................ 61
Configure the environment on UNIX ............................................................................. 61
Install additional JDA applications ....................................................................... 61
Reset user passwords after migration .................................................................. 62
Change permissions on WebSphere installation directories ..................................... 63
Set environment variables for internationalization ................................................. 63
Configure database .................................................................................................... 65
Create database users ....................................................................................... 65
Create the Platform schema objects .................................................................... 66
Upgrade the Foundation schema ......................................................................... 69
Migrate the Foundation schema on Oracle ............................................................ 70
Migrate the JDA Monitor schema ......................................................................... 71
Migrate Foundation schema from 7.1 to 7.1.1 on Oracle ........................................ 71
Migrate Foundation schema from 7.1.1 to 7.2 on Oracle ........................................ 71
Migrate Monitor schema 7.1 to 7.2 on Oracle ....................................................... 72
Migrate business rules ....................................................................................... 74
Migrate Monitor schema 7.2 to 7.2.1 on Oracle ..................................................... 76
Migrate business rules to version 7.2.1 ................................................................ 77
Reconfigure e-mail templates ............................................................................. 78
Migrate Foundation schema from 7.2.1 to 7.2.1.1 on Oracle ................................... 78
Migrate Foundation schema from 7.2.1.1 to 7.2.2 on Oracle ................................... 78
Migrate Monitor schema 7.2.1 to 7.2.2 on Oracle .................................................. 79
Migrate Foundation schema from 7.2.2 or 7.2.3 to 7.3. on Oracle ........................... 80
Migrate Monitor schema 7.2.2 to 7.3 on Oracle ..................................................... 81
Migrate Foundation schema from 7.3 to 7.3.0.1 on Oracle ..................................... 81
Migrate Monitor schema 7.3 to 7.3.0.1 on Oracle .................................................. 82
Migrate Foundation schema from 7.3.0.1 to 7.4. on Oracle .................................... 83
Migrate Monitor schema 7.3.0.1 to 7.4 on Oracle .................................................. 84
Migrate Monitor schema 7.4 to 7.4.1 on Oracle ..................................................... 86
Migrate Foundation Schema from 7.4.1 to 7.4.2 on Oracle ..................................... 87
Migrate Monitor schema 7.4.1 to 7.4.2 on Oracle .................................................. 88
Migrate Foundation schema from 7.4.2 or higher to 2016.1.................................... 88
Migrate Monitor schema from 7.4.2 or higher to 2016.1.0.x ................................... 91
Additional database scripts................................................................................. 92
Notes on migrating a database for a new character set .......................................... 93
Configure JDA Platform Server .................................................................................... 96
Start and stop the JDA Platform Server ........................................................................ 97
Start JDA Platform Server on Windows ................................................................ 98
Start JDA Platform Server on UNIX ..................................................................... 99
Reading the console during startup on a WebLogic platform ................................... 99
Reading the console during startup on a WebSphere platform .............................. 100
Shut down the JDA Platform Server................................................................... 100
Configure a cluster on WebLogic ................................................................................ 101
Cluster components ........................................................................................ 102
Configure IP addresses .................................................................................... 103
Install WebLogic for a cluster ........................................................................... 103
Enable WebLogic plug-in through WebLogic Admin Console .................................. 109
Generate an encryption key for a cluster............................................................ 109
Configure the cluster as a Windows service ........................................................ 110
Start the admin server .................................................................................... 110
Start the managed servers ............................................................................... 111
Access the cluster ........................................................................................... 111
Add a member server to a cluster ..................................................................... 111
Change the WebLogic cluster admin password .................................................... 112
Update JNDI lookup URLs in a Weblogic cluster .................................................. 112
Shut down Managed Server ............................................................................. 112
Shut down Admin Server ................................................................................. 113
Configure a cluster on WebSphere ............................................................................. 113
Cluster components ........................................................................................ 114
Configure IP addresses .................................................................................... 114
Install WebSphere for a cluster ......................................................................... 115
Set up the front end proxy HTTP server ............................................................. 116
Generate an encryption key for a cluster............................................................ 119
Update JNDI lookup URLs in a WebSphere cluster ............................................... 120
Start the admin server (Deployment Manager) ................................................... 120
Start the node agents...................................................................................... 120
Start the managed servers ............................................................................... 121
Access the cluster ........................................................................................... 121
Add or delete cluster members ......................................................................... 121
Items to verify after installation ........................................................................ 121
Delete the cluster ........................................................................................... 122
Node pool manager.................................................................................................. 122
Use the Basic node pool ................................................................................... 122
Start a node pool manager............................................................................... 122
Shut down a node pool manager....................................................................... 124
Add node configurations .................................................................................. 125
CIS high availability mode ........................................................................................ 127
Configure CIS for high availability in cluster mode .............................................. 127
Set the single sign-on domain for multi-application SSO ............................................... 128
Chapter 6. Utilities and common tasks ........................................................................ 129

Use the ldapUserExport utility ................................................................................... 129
Use the versionInfo utility ......................................................................................... 131
Use the genPasswordHash utility ............................................................................... 132
Use the pingWebworksServer utility ........................................................................... 132
Data Division Utility ................................................................................................. 132
Installation..................................................................................................... 132
Create the DDU stored procedure ..................................................................... 133
Run the DDU stored procedure ......................................................................... 133
Review the DDU_RESULTS table ....................................................................... 134
Multi-byte language support ............................................................................. 136
DDU examples................................................................................................ 136
Security ......................................................................................................... 137
Generate a credential file .......................................................................................... 138
Configure the JDA Platform Configuration files ............................................................. 138
JDA Platform technical integration points ........................................................... 138
Server configuration files ................................................................................. 138
Update server configuration ............................................................................. 141
Configure JDA SSO service timeout ............................................................................ 149
Control user access .................................................................................................. 149
Configure and enable external authentication .............................................................. 150
Configure external authentication with an HTTP header ................................................ 150
Configure external authentication with PingFederate .................................................... 150
Update the abpp.properties file to support PingFederate ...................................... 150
Update webworks_jaas.config file to support PingFederate ................................... 151
Verify PingFederate Setup ................................................................................ 151
Configure external authentication with SAML ............................................................... 151
Components of SAML ...................................................................................... 151
Authentication flow ......................................................................................... 152
Configure SAML properties ............................................................................... 153
Use LDAP with JDA Platform ...................................................................................... 157
Configure JDA Platform to use LDAP service ....................................................... 158
Install LDAP server certificate when using LDAPS ................................................ 158
Use the csmImport utility ......................................................................................... 159
Rules for creating the input XML file .................................................................. 160
Set security properties ............................................................................................. 165
Use secure sockets layer.................................................................................. 165
Generate an encryption key for multiple servers ................................................. 166
Set user password properties ........................................................................... 167
Force new passwords for all users ..................................................................... 167
Set login properties ......................................................................................... 167
Record failed logins ......................................................................................... 168
Event Services auditing ................................................................................... 168
Use encrypted authentication .................................................................................... 169
Generate an encrypted password for command-line authentication ....................... 170
Invoke batch commands ........................................................................................... 170
Change the WebLogic admin password ....................................................................... 171
Change the WebSphere admin user ........................................................................... 172
JDA event auditing ................................................................................................... 173
exportAuditSubscriptions utility ........................................................................ 174
importAuditSubscriptions utility ........................................................................ 174
Service Runtime Environment (SRE) .......................................................................... 174
Interface options for configuring SRE ................................................................ 174
Configure the Foundation schema for SRE .......................................................... 175
Adjust SRE global properties ............................................................................ 177
Configure a node pool for a cluster.................................................................... 179
Run processes in SRE ............................................................................................... 181
JDA Platform processes ................................................................................... 181
Run Update Parameters in batch ....................................................................... 181
Create process request XML file ........................................................................ 182
Run SREBatchUtility ........................................................................................ 188
Notes for users upgrading from 7.1.x to 7.4 ....................................................... 189
Understand continuous jobs ............................................................................. 190
Work with sre_configuration package ................................................................ 191
SRE job restart ............................................................................................... 192
Use SRE Custom processes ....................................................................................... 192
Add or edit custom process pages to directory .................................................... 192
Assign a custom process to a role ..................................................................... 193
Assign a custom process to a node pool ............................................................. 193
Troubleshooting SRE ................................................................................................ 193
System alerts ................................................................................................. 195
Return codes and job states ............................................................................. 199
Enterprise Change Management ................................................................................ 202
ECM import hierarchy ...................................................................................... 204
Use mcmExport .............................................................................................. 204
Use mcmImport .............................................................................................. 205
Use mcmReport .............................................................................................. 206
Process Manager ..................................................................................................... 207
Use SRE Custom processes .............................................................................. 207
Configure alternate text............................................................................................ 208
Create alternate text field using UpdateBaseColProps utility ................................. 208
User-defined tables .................................................................................................. 209
Create a user-defined table .............................................................................. 209
Enroll a user-defined table ............................................................................... 210
Change default display properties .............................................................................. 213
Edit resource files for double-byte languages...................................................... 213
Change task statuses ...................................................................................... 214
Modify server and browser properties ................................................................ 215
Create audit baseline data ........................................................................................ 217
Change schema name and password .......................................................................... 217
Infrastructure Services Launcher ............................................................................... 219
Configuration ................................................................................................. 219
Start the launcher ........................................................................................... 220
Infrastructure services overview ................................................................................ 223
Management Services ..................................................................................... 223
CIS Agent ...................................................................................................... 223
Infrastructure Services Manager ....................................................................... 223
Security Services ............................................................................................ 223
Single sign-on ......................................................................................................... 224
Session coordination service............................................................................. 224
Manage solution navigation ....................................................................................... 225
Update solution navigation ............................................................................... 225
Implement security in Solution Navigation.......................................................... 229
Configure Tab Title for URL link ........................................................................ 229
Configure Monitor .................................................................................................... 230
Enable Monitor after installation........................................................................ 230
Change e-mail templates ................................................................................. 230
Modify Monitor properties ................................................................................ 232
Configure the Data Comparison rule .................................................................. 233
Use Monitor batch processes ............................................................................ 241
Set up data .................................................................................................... 249
JDA Platform software licensing ................................................................................. 251
Install a license file ......................................................................................... 251
Integrate English Platform OnLine Experts in different locale ......................................... 252
Configure server desktop in the Citrix server to access RichUI application ....................... 253
Configuring the application for Security ...................................................................... 253
Configurations required for the JDA Platform Setup with Apache front-end server ... 254
Configurations required for the JDA Platform setup when SSL is enabled on front-end
webserver or application server ........................................................................ 254
Cross-Site Request Forgery attack control .......................................................... 254
Logging standardization............................................................................................ 255
Define the log file size ..................................................................................... 255
Add a new logger ............................................................................................ 256
Modify logging level ........................................................................................ 256
Synchronize log configuration in cluster ............................................................. 257
Log browser request details ............................................................................. 259
Identify current logging configuration ................................................................ 259
Configure custom logo.............................................................................................. 259
Update the Java patch version post installation ........................................................... 260
Configure time zone for ABPP in Platform setup ........................................................... 260
Concurrent login ...................................................................................................... 261
Configure last login information display ............................................................. 261
Enable concurrent login feature in cluster environment ........................................ 261
User Activity Audit ................................................................................................... 261
Auditing Information ....................................................................................... 262
Sample log..................................................................................................... 262
Configuring Event Handlers .............................................................................. 263
Configure maxRowsExportable parameter to a custom value ......................................... 263
Chapter 7. Troubleshooting ......................................................................................... 264

Troubleshoot the JDA Platform Server ........................................................................ 264
Troubleshooting steps ..................................................................................... 264
Troubleshooting SRE ................................................................................................ 268
System alerts ................................................................................................. 270
Return codes and job states ............................................................................. 274
DDU error codes ...................................................................................................... 276
Troubleshoot CIS in JDA Platform Server .................................................................... 277
CIS Issues when SSL is involved ....................................................................... 277
How to spot session stickiness issues ................................................................ 277
How many CIS agents/servers are active in a cluster? ......................................... 278
Features not working when SSO is enabled using Siteminder and lot of database server
related exceptions in SSO logs ......................................................................... 278
External Authentication issues when the parameter is other than SM_USER for
ex.XX_USER ................................................................................................... 279
No Configuration was registered that can handle the configuration named
HTTPHeaderLoginModule error when SSO with external authentication is configured279
Broken login page is displayed when SSL is configured in webserver ..................... 279
User tries to access the URL and it gives the error "SSO server not started" ........... 280
Users redirected to home page when SSL is configured with WebSphere setup ....... 280
Configuration required for postAbpprequest when https is enabled ........................ 281
Appendix A. Apply patch .............................................................................................. 282

Patch Overview ....................................................................................................... 282
Limitations of partial patches .................................................................................... 282
Patch Type .............................................................................................................. 282
Full Patch ....................................................................................................... 282
Partial Patch ................................................................................................... 283
Apply Partial Patches ....................................................................................... 284
Apply Partial Patch on Application Server through silent installation ...................... 284
Apply Partial Patch on Application Server Installations ......................................... 286
Apply Partial Patch on SRE Installations ............................................................. 287
Revert Patches ........................................................................................................ 288
Rollback full patch........................................................................................... 288
Rollback partial patch ...................................................................................... 289
Appendix B. Send a database to JDA ........................................................................... 291
Index ........................................................................................................................... 292

Overview
Chapter 1. Overview
A high-level roadmap of installation
This section describes the high-level tasks that are required to install JDA Platform.
Task Description Required

or
Optional
Step 1: Install prerequisite For supported versions of the operating system and Required
software required service packs or patches, see System requirements
(on page 11). The prerequisite software is not included with
JDA Platform.
Step 2: Set up a Windows This section describes the setup that is required on a Required
server or a UNIX server. Microsoft Windows Server or UNIX server before you install
JDA Platform. See Set up a Windows server (on page 19) or
Set up a UNIX server (on page 20)
Step 3:Set up Oracle Install the supported version of Oracle and any necessary Required
patches. See Set up Oracle (on page 21).
Step 4: Install Oracle Install the application server for JDA Platform. Required
WebLogic or IBM If you are using the Oracle Weblogic Server, see Install
WebSphere application WebLogic application server (on page 25).
server based on the
If you are using the IBM WebSphere application server, see
hardware platform.
Install WebSphere application server (on page 27)
Step 5: Create Oracle SID JDA provides scripts to create an Oracle instance and Required
and required tablespaces tablespaces. The database server can be on the same
machine as the JDA Platform Server or on a different
machine. For better performance, the database server
should be on a separate machine. See Create an Oracle
database (on page 22).
Step 6: Install JDA Install JDA Platform and the additional applications that will Required
Platform application and run with JDA Platform. If using WebLogic, you can optionally
any additional applications create the JDA Platform database users and the associated
that will be installed with JDA Platform database objects as part of the installation.
JDA Platform. You should only use this option if you do not have an
existing database to migrate from an earlier version. You
can also configure the JDA server during installation. See
Install Platform (on page 34).
Step 7: Create or migrate If not created during installation, create the Foundation and Required
database schemas ABPP schema using the instructions in Create the
(Platform and ABPP). Foundation schema and ABPP schema (on page 66). If you
are migrating from an earlier version, migrate the
Foundation and ABPP schemas
Step 8: Configure Platform Configure the JDA Platform server. See Configure the JDA Required
server Platform Server (on page 96).
Step 9: Install JDA Install JDA Platform SRE if the application you are installing Optional
Platform Service Runtime uses SRE and you want to run it from a different installation
Environment (SRE) than the application server. See Install Platform SRE (on
page 45).
JDA Platform Installation/Administration Guide 7

1996-2017 JDA Software Group, Inc.- Confidential
Overview
Task Description Required

or
Optional
Step 10: Configure JDA Configure the JDA Platform Service Runtime Environment Optional
Platform SRE (SRE). See SRE (on page 174).
Architecture and concepts

This guide contains information for JDA Platform, which includes the Security Manager, Service
Runtime Environment (SRE), and JDA Platform user interface components. It also includes database
initialization and migration information for JDA Platform and server configuration information which is
common to JDA Platform-based applications. This guide is installed as part of JDA Platform.
When you plan an architecture, consider the logical and physical layers and how they will be used. You
should develop your configuration after careful planning to ensure that it meets your requirements. For
more information on Platform architecture, see the Common Concepts Reference Guide. The physical
configurations presented the Common Concepts Reference Guide are provided as examples.
Contents of the installation media

The following software is on the JDA Platform installation image, as distributed electronically or on
DVDs.
JDA Platform 2016.1.0.x, which includes the JDA documentation. JDA documentation is provided in
Portable Document Format (PDF) format. The following documentation (PDF) is available on the DVD:
JDA Platform Installation/Administration Guide
JDA Platform Common Concepts Reference Guide
JDA Interface Generation Program Reference Guide
JDA Platform Release Notes

One of the following application servers (optionally available from JDA):
Oracle WebLogic Server: If licensed from JDA, the Oracle WebLogic Server (WLS) license is
granted per the terms of your End User Software License Agreement with JDA Software. Usage of
this WLS license must be in conjunction with the use of the JDA Solution with which it was
purchased. Refer to your End User License Agreement for further details.
IBM WebSphere Application Server: JDA certifies WebSphere on AIX only. Not all JDA
applications are supported on WebSphere. Consult the individual application
Installation/Administration Guide for exceptions. If licensed from JDA, the IBM WebSphere Server
license is granted per the terms of your End User Software License Agreement with JDA Software.
Usage of this license must be in conjunction with the use of the JDA Solution with which it was
purchased. Refer to your End User License Agreement for further details. To advance the
installation process, you must click Yes on the IBM WebSphere License Agreement. This is a
technical requirement and does not change the terms and conditions of your JDA End User
Software License Agreement with JDA Software.
Language support
This version of JDA Platform supports the following languages:
English
French

Overview
German (Software only)
Japanese
Russian
Spanish
Simplified Chinese
Portuguese (Software Only)
Italian (Software Only)
Note: The available version associated with each language may vary. Contact JDA Support Services
for the latest information on the language versions that are available.
Each language version is tested on the associated language operating system and on an English
operating system with the native language pack installed. The English version of the application is not
tested on cross-language environments.
OnLine Expert (Help) documentation is provided in the native language in most cases. All other
technical documentation is provided in English only.
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.
Note: The services provided may vary by application and implementation.
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 JDA Customer Support website (http://support.jda.com/), which provides:
Self-service user administration

Online knowledge base
Online case management and user communities
Product documentation and release announcements
JDA Education Services

Overview
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
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/).

Pre-requisites
Chapter 2. Pre-requisites
Before you install
This chapter provides information on tasks that you must perform before you install JDA Platform and
on how to configure the Platform database schema.
The instructions in this chapter assume that you have a strong knowledge of:
Microsoft Windows Server or UNIX, including setting environment variables
The Oracle database management system
Before you install any JDA application ensure that your system has the prerequisite software installed.
System requirements
JDA Platform server
JDA Platform server supports the following hardware and operating systems. Although the
requirements for JDA Platform-based applications are the same, you should check the application
Installation/Administration Guide for unique requirements. The operating system and hardware are not
provided with JDA Platform.
Notes:
Oracle installation is required to configure the JDA database during installation and
configuration of JDA Platform server. After installation and configuration, the application server
requires access to the Oracle JDBC driver (in your Oracle installation) to access the database.
Additionally, you must configure EZCONNECT in the sqlnet.ora file.
Computer processor models, memory, and disk requirements should be determined after
reviewing technical requirements.
On Linux OS, the default user limit value 1024 for the nofile and nproc parameters may result
in "java.lang.OutOfMemoryError: unable to create new native thread" errors while running SRE
processes.
To see the default value for all parameters, enter "ulimit a". The default value of 1024 for
nofile and nproc parameters on your system should be increased to 4096 or more. For more
information, see the Linux Administrators Guide.
OS Hardware JDK Application Oracle

Platform server database
AIX Version 7.1 TL4 SP1 pSeries WebLogic: Java 8 WebLogic Oracle
server SR2 (java version 12.2.1 (64 12.1.0.2 64-
1.8.0) bit) bit (client or
Java(TM) SE server)
Runtime WebSphere
Environment (build 8.5.5.7 (64-
pap6480sr2-
bit)
20151023_01(SR2)
WebSphere: Java
7 Release 1 SR3
FP10 (Java(TM) SE
Runtime
Environment (build

Pre-requisites
OS Hardware JDK Application Oracle

Platform server database
pap6470_27sr3fp10
-20150708_01(SR3
FP10))
Solaris 11.2 Sun SPARC WebLogic: WebLogic 12.2.1 Oracle

latest recommended patch Server Oracle JDK version (64 bit) 12.1.0.2 64-
bundle 1.8 update 66 (64- bit (client or
bit) server)
Windows Server 2012 R2 x86 WebLogic: WebLogic 12.2.1 Oracle

(64-bit) compliant Oracle JDK version (64 bit) 12.1.0.2 64-
processors 1.8 update 66 (64- bit (client or
bit) server)
Red Hat Enterprise Linux 7 x86_64 WebLogic: WebLogic 12.2.1 Oracle

update 1 with the following compliant Oracle JDK version (64 bit) 12.1.0.2 64-
patches: processors 1.8 update 66 (64- bit (client or
motif-2.3.4-7.el7.i686 and bit) server)
motif-2.3.4-7.el7.x86_64
libXtst-1.2.2-2.1.el7.x86_64
and libXtst-1.2.2-
2.1.el7.i686
glibc-2.17-
106.el7_2.1.x86_64 and
glibc-2.17-106.el7_2.1.i686
libstdc++-4.8.3-9.el7.i686
andlibstdc++-4.8.3-
9.el7.x86_64
nspr-4.10.8-2.el7_1.x86_64
and nspr-4.10.8-
2.el7_1.i686
* nss-3.16.2.3-5.el7.x86_64
and nss-3.16.2.3-5.el7.i686
Web Servers
JDA documents the specific web servers that we have tested with and have licenses for in JDA. Given
the wide range of vendors that provide these services, JDA does not test all the vendors but recognize
that clients will have a broad range to choose from. Both Oracle WebLogic and IBM WebSphere
document their supported web servers and load balancers. JDA has no code running within these tiers.
Given this, JDA will support customers running web servers that are supported by Oracle and IBM;
however, please recognize that JDA may only have the documented web servers within JDA. Therefore,
our ability to provide issue resolution for undocumented web servers may be limited.
OS Web Server
Solaris Oracle iPlanet version 7.x (WebLogic Server Plug-in 12c )

Pre-requisites
OS Web Server
AIX WebLogic: Oracle HTTP Server 12.2.1 (WLS Plug-in 12c) or Apache
HTTP server 2.4.4+
WebSphere: IBM HTTP Server version 8.5.5.7
Windows Internet Information Server 8.5
RedHat Enterprise Apache HTTP Server 2.4.4+

Linux
Acknowledgments
The open-source software that JDA Platform uses under certain terms of license agreements is listed
in the table below:
Open-Source Component Source Organization

Apache Cocoon Apache
Apache Axis2/C & Axis2/Java Apache
backport-util-concurrent Public Domain
Jakarta Regexp Library Apache
Java Mail API Sun Microsystems
JavaService BSD or GNU
Rolling File Trace Listener

True License Apache
wsit Sun Microsystems or GNU

Xalan Apache
Xerces Apache
Oracle database server

The Oracle database server is required to host JDA Platform and application schemas. The database
server can be located on the same machine as JDA Platform or on a different machine.
OS Database version
UNIX or Linux (64-bit) Oracle 12.1.0.2 64-bit (RAC and non-RAC) standard or
Windows Server 2012 R2 (64-bit) enterprise edition.
If you configure the database remotely, then you need Oracle Client software installed on the
application server. JDA Reporting requires 32-bit Oracle client software on the JDA application server.
For details, see JDA Reporting Installation/Administration Guide.

Pre-requisites
Resources for patches and service packs

If you have questions or problems on patches or service packs, contact the vendor. The sites listed
below are subject to change:
Maintenance Packages for AIX and the IBM SDK can be obtained at http://support.ibm.com and
http://www.ibm.com/developerworks/java/jdk/aix/service.html.
Patches for Solaris can be downloaded from https://support.oracle.com.
Patches for RedHat Linux can be downloaded from http://www.redhat.com.
Service packs for Windows can be downloaded from http://www.microsoft.com.
Patches for Oracle database server can be downloaded from https://support.oracle.com.
Note: JDA Platform does not support Windows multi-language versions. International users should
install the appropriate language version of Windows and service packs for their environment, for
example: French, Spanish, and Japanese. If you have any questions or problems, contact Microsoft.
JDA Platform SRE

JDA Platform Service Runtime Environment (SRE) is a thin installation that runs in a separate Java
environment for algorithm processing. SRE also provides command files to start node pool managers
and to run batch processes. JDA Platform hardware requirements for JDA Platform SRE depend on the
application processes you run. The machine must have sufficient memory to support the node pool(s)
and number of nodes configured on those node pools. You can install JDA Platform SRE on the same
machine as the JDA Platform Server or on standalone machines that connect to the JDA Platform
Server. JDA Platform SRE requires Oracle Client (or server) software to access the Oracle JDBC driver
for access to the database.
SRE requires the 64-bit JDK only. No other application server software is required on the SRE server.
OS Hardware JDK Oracle

Platform
AIX Version 7.1 TL4 SP1 pSeries WebLogic: Java 8 Oracle 12.1.0.2 64-
server SR2 bit (client or server)
WebSphere: Java 7
Release 1 SR3 FP20
(Java(TM) SE Runtime
Environment (build
pap6470_27sr3fp20-
20151106_01(SR3
FP20))
Solaris 11.2 latest recommended Sun SPARC WebLogic: Oracle Oracle 12.1.0.2 64-
patch bundle Server JDK version 1.8 bit (client or server)
update 66 (64-bit)
Windows Server 2012 R2 (64-bit) x86 WebLogic: Oracle Oracle 12.1.0.2 64-
compliant JDK version 1.8 bit (client or server)
processors update 66 (64-bit)
Red Hat Enterprise Linux 7 update 1 x86_64 WebLogic: Oracle Oracle 12.1.0.2 64-
JDK version 1.8 bit (client or server)
update 66 (64-bit)

Pre-requisites
Client
JDA applications use a thin-client architecture that requires a supported Web browser.
OS Hardware Platform Browser

Windows7 X86 compliant processors sufficient for the IE11 (64-bit or 32-bit)
(32-bit and 64-bit) operating system, usually 2.8 GHz or greater,
and: Chrome (32-bit)
Windows 8.1 Minimum recommended RAM: 4 GB

IE11 (64-bit or 32-bit)
(64-bit) Network connection to Internet or
Intranet Chrome (32-bit)
Windows 10 Minimum recommended screen resolution

IE11 (64-bit or 32-bit)
(64-bit) is 1280 x 1024
Note: JDA screens may render at lower

Chrome (32-bit)
resolutions, but are optimal at a higher Edge
resolution.
If using .NET UIs, a graphics card of 256

MB or higher
IMPORTANT: If using Internet Explorer, do not set the JDA website to use the Compatibility
settings. For more information, see the Disable Compatibility mode in Internet Explorer (page 52)
section.
Depending on what products or product components you are installing with JDA Platform, you may
need to install additional software on the client.
Note: For information on application specific requirements, see the respective products Installation
Guide or Installation/Administration Guide.
Additional client hardware and software planning factors:

Clients require a network connection to Internet or Intranet to access the servers.
Browsers must accept cookies.
Browsers must be able to run JavaScript.
JDA Platform is optimized to work with 100% browser zoom settings. User Interface elements may
get misaligned at other zoom levels.
Internet Explorer has an additional security feature that may block pop-ups and online help.
Users have two options to display the content:
Select the Information Bar in Internet Explorer to display pop-ups and help files on a one-time
basis.
In Internet Explorer, select Tools > Internet Options > Advanced > Security. Select
Allow active content to run in file on My Computer. This displays all content from the JDA
Platform Server.
Internet Explorer has the options of opening pop-ups in either a new tab or a new window. Set
Tools > Internet Options > Tabs > Settings > When a pop-up is encountered to Always
open pop-ups in a new window.
Verify that automatic caching is enabled for your browser.
1. Go to Tools > Internet Options > Browsing History > Settings.

Pre-requisites
2. Check for newer versions of stored pages is set to Automatically.
Note that use of multiple tabs in the JDA navigation frame will consume additional memory and
system resources on the client for each additional tab that is opened. Users who use multiple tabs
will need more resources than those users who maintain only a single JDA tab.
Gather information for the installation

The JDA Platform installation utility prompts for information about your system and the environment in
which it runs. To make the installation easier and successful, have the following information available
before installation:
Windows or UNIX login ID with administrative privileges. The user installing JDA Platform on UNIX
does not require root privileges.
JDA uncompressed software image.
The directory in which to install the software. Use a short path directory path, for example, c:\jda.
This path should not contain other non-JDA software installations such as WebLogic, WebSphere,
or Oracle. The directory names where you plan to install JDA Platform must use simple ASCII
characters. For example, A-Z a-z. The JDA Platform installation can create the directories for you.
The directory names should not contain spaces.
IMPORTANT: Avoid installing JDA Platform on network file system (NFS) mounted drives. Doing
so severely degrades the runtime performance.
The name of the current server and the port number on which you want the server to listen
(default port is 7001 for t3 Standard and 7002 for SSL/secure). In addition, you will need
additional ports for administrative purposes, depending on whether you are installing on WebLogic
or WebSphere.
For Oracle configuration, you need to know the database server name, service name, port, and the
JDA Platform schema names and passwords (by default JDA_SYSTEM, wwfmgr and abppmgr). If
you want to automatically create the JDA Platform Oracle database users or database objects at
the end of-installation, you need to supply the Oracle system user password.
Enable Oracle's easy connect naming method (EZCONNECT) in the sqlnet.ora on the application
server and any SRE servers. If this is not enabled, the connection strings may fail in the post-
installation and also in the subsequent Platform server startup.
The name of the Host Enterprise. The Host Enterprise is usually the company that either controls
all data in the system (the host enterprise), or a company that collaborates using the system (a
partner enterprise).
IMPORTANT: If migrating or upgrading a JDA Platform database, the name of the Host Enterprise
you enter must be identical to the Host Enterprise in the CSM_ENTERPRISE table. This value is
case sensitive.
Email information including the administrators email address, "From" email address, and the SMTP
Host Name. You can leave this information blank if you do not want to activate email, and you can
change email information after installation.
If you are using WebLogic, the WebLogic administrative username and password (by default
weblogic/weblogic1).
If you are using WebSphere, you need the following additional information:
Root privileges to install IBM WebSphere application server.

Pre-requisites
The absolute path where WebSphere is installed, for example,

/usr/local/IBM/WebSphere8.5/AppServer.
The user name and password for the UNIX account that can administer WebSphere processes.
This may be root, or it may be a user account that was specifically configured to run
WebSphere. See the WebSphere documentation on how to configure WebSphere as a user
other than root.
The Websphere administrative account (by default appAdmin) and password are required to
run some command files on UNIX.
Preconfiguration requirements for a clustered

configuration
Preconfiguration requirements WebLogic cluster
Configuring a cluster requires additional hardware/software requirements. Unless otherwise stated, the
following items are not included with the JDA Platform software.
Supported server platforms are the same as a standard configuration. For more information on the
supported version, see System requirements (on page 11).
In this version, cluster configuration servers do not require multiple IP addresses (sometimes
called multi-homed). The recommended implementation is a single IP address for all managed
servers on the same machine, and each managed server requires a unique listen port. A multi-
homed machine is still supported, in which case the same listen port could be used on each
machine.
WebLogic application server (available with JDA Platform) must be installed once on each machine
in the cluster. If you plan multiple managed servers on the same machine, install WebLogic only
once.
JDA Platform. Install JDA Platform and all JDA Platform-based applications for each managed
server and for the admin server.
Web server that Oracle supports for WebLogic server. See ORACLE documentation at
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-
100350.html for supported Web Servers.
Optional load director or intelligent load balancing component. This component can route http (or
https) requests directly to the WebLogic cluster or through the Web Server tier.
Preconfiguration requirements WebSphere cluster

Configuring a cluster requires additional hardware/software requirements. Unless otherwise stated, the
following items are not included with the JDA Platform software.
Supported server platforms are the same as a standard configuration. See the JDA Platform
Installation/Administration Guide for details on operating systems and patches.
For cluster configuration in this version, the servers do not require multiple IP addresses
(sometimes called multi-homed). The recommended implementation is a single IP address for all
managed servers on the same machine, and each managed server requires a unique listen port. A
multi-homed machine is still supported, in which case the same listen port could be used on each
machine.

Pre-requisites
IBM WebSphere (optionally available with JDA Platform) must be installed once on each machine in
the cluster.
JDA Platform. Install JDA Platform and all JDA Platform-based applications for each managed
server.
A Web Server supported by IBM with WebSphere can be configured as the Web Server tier.
Optional load director or intelligent load balancing component. This component can route http (or
https) requests directly to the WebSphere cluster or through the Web Server tier.

Pre-installation tasks
Chapter 3. Pre-installation tasks

Pre-installation checklist
Perform the following tasks before the installation:
Identify the server configuration, which includes following components:
Application servers
Oracle database server
Web server
SRE servers: If you are installing applications that use the Service Runtime Environment (SRE)
Set up Oracle:
Install the required version of the Oracle Server on the database server
Install the required version of the Oracle Client on the application server where you will run
database scripts
Ensure the required version of the Oracle Client is installed or the Oracle JDBC driver is
accessible to all application and SRE servers where you will install JDA Platform
Create an Oracle database with the required tablespace for the Platform schema. By default,
the Platform tablespace is WWFDATA, but is configurable during the installation.
Set ORACLE_HOME if you:
Run Platform installer with post installation database tasks.
Apply Partial database patches.
Set up the application server:
If installing WebLogic, install the supported version of Java on the application servers
Install the required application server (WebLogic or WebSphere) on the application servers
Set up the SRE servers (optional):
If installing SRE on a separate machine, install the supported version of Java on the SRE
servers
Set up a Windows server

This section describes the setup that is required on a Microsoft Windows Server before you install JDA
Platform. The Installation utility used by JDA Platform provides a graphical installation on Windows, or
you can perform a silent installation that runs without intervention.
Install required tools and patches

Before you install JDA Platform, you must have:
The supported version of Microsoft Windows Server installed with appropriate service packs

The supported version of the Oracle Database software installed on either the same machine or a
different machine. If the database is on a different machine, you need to install the Oracle client
and SQL*Net on the application server, In either case you must configure EZCONNECT in the
sqlnet.ora file.
See System requirements (on page 11) for specific operating system and patch requirements for
Microsoft Windows Server and Oracle, as well as any additional software prerequisites.
Note: The basic operating system and service pack levels are the same for many JDA Platform-based
products, but be sure to check and fulfill the specific requirements for the applications you plan to use.
Set up a UNIX server

This section describes the setup that is required on a UNIX server before installing JDA Platform. The
Installation utility used by JDA Platform provides a console installation, or you can perform a silent
installation that runs without intervention. If you are installing remotely using telnet from a personal
computer, you can use console or silent installation.
IMPORTANT: Avoid installing JDA Platform on network file system (NFS) mounted drives, because it
severely degrades the runtime performance.
Install required tools and patches

Before you install JDA Platform, you must have:
The appropriate version of UNIX software installed with appropriate options and patches or
maintenance packages
One of the following:
The supported version of Oracle WebLogic, if applicable, on the same machine.
The supported version of IBM WebSphere Network Deployment, if applicable, on the same
machine. See IBM documentation for installation instructions. JDA Platform enables a global
security realm with a custom active user registry; therefore, do not create a global security
realm in WebSphere before you install JDA Platform.
The supported version of the Oracle Database server software installed on either the same
machine or a different machine. If the database is on a different machine, you need to install the
Oracle client and SQL*Net on the application server and configure EZCONNECT in the sqlnet.ora
file.
See System requirements (on page 11) for specific operating system and patch requirements for your
UNIX operating system, the supported Oracle version, and any additional software prerequisites.
Note: The basic operating system and service pack levels are the same for many JDA Platform-based
products, but be sure to check and fulfill the specific requirements for the applications you plan to use.
Create a JDA group

Log in as the super user (root) and create a group called jda. All server accounts whose primary roles
are administration, configuration, or batch processing of JDA products must be created as part of this
group.
Create a JDA user

Create the user account jdamgr. Use this account to install or manage the application server, JDA
Platform, and JDA Platform-based applications. Set up the user as follows:

Assign the Korn shell as the default shell
Assign to jda as the default group
Assign a home directory (for example, /u01/apps/jda)
Set environment variables

Most environment variables can be set after you install the application server and JDA Platform. If you
are using the post-installation options to create the JDA Platform schemas, you need to have the
ORACLE_HOME set to the supported version of Oracle.
Note the following restrictions:
Do not export variables LANG, LC_ALL, or LC_CTYPE to a UTF-8 locale before you install JDA
Platform.
Set your LANG variable to an appropriate UTF-8 locale for your language before starting the JDA
Platform Server on UNIX.
Use the locale command to determine the current settings.
Set up Oracle
You must install the supported version of Oracle and any necessary patches. For more information, see
System requirements (on page 11).
The Oracle database server must be installed and configured before you configure the Foundation
schema. The database server can be on the same machine as the JDA Platform Server or on a different
machine. For better performance, the database server should be on a separate machine. The Oracle
client software must be installed on all application servers and the Oracle client must be installed or
the Oracle JDBC driver must be available on all SRE machines.
SQL*Plus
Use SQL*Plus to run all SQL scripts provided by JDA. In some cases, JDA uses batch or shell scripts to
call SQL scripts. Instructions for running JDA scripts are provided in this guide and other JDA
documentation.
Oracle server and client

You need Oracle Client software on each application server to run SQL scripts and to provide the
Oracle JDBC driver. For example, if JDA Platform is installed on machine A and the Oracle database is
on machine B, then machine A must have the supported version of the Oracle client. Machine B must
have the supported version of the Oracle server.
Machine A: (hosting JDA Platform) Machine B: (hosting Oracle database)

Oracle Client with Oracle Server with
TCP/IP Adapter listener.ora configured
SQL*Plus (to run JDA SQL scripts) Listener running with valid service handler
waiting to accept connections
tnsnames.ora file configured with Net Service
Name and Connect Descriptor of database
server
sqlnet.ora configured to use EZCONNECT

Create an Oracle database

After installing the supported version of Oracle and JDA Platform, you can create an Oracle database to
run JDA Platform-based applications and store your data. You can create the database using the scripts
in the JDA Platform installed directory structure.
IMPORTANT: You must have sufficient knowledge of Oracle and SQL*Plus. An experienced DBA
should participate in creating the Oracle database instance for optimal database performance and
recovery.
If you will not create your database SID using JDA scripts, or if you edit the initialization files, you
must have the following parameters in your init<SID>.ora file. Usually, this file is located in directory
oracle\admin\<SID>\pfile:
Parameter Description Value
db_block_size The db_block_size required to support large 16384

multibyte UTF8 characters.
nls_length_semantics Determines whether character data types use byte CHAR
or character semantics. Use CHAR. The default
value of this parameter is BYTE. Character-base
semantics allow the definition of storage
requirement for variable-width multi-byte strings in
terms of characters, simplifying column storage
specifications by eliminating the need to convert
between units. Changing the initialization parameter
to character-base semantics is required.
NLS_LENGTH_SEMANTICS does not apply to tables
in SYS and SYSTEM data dictionary because they
use byte semantics.
cursor_sharing Oracle Database can share cursors, which are EXACT
pointers to private SQL areas in the shared pool The
default may be changed to FORCE if recommended
by an Oracle expert.
optimizer_features_enable The version of the Oracle optimizer that is used. 12.1.0.2
Compatible The compatibility of the database to older versions. 12.1.0
utl_file_dir Only required for SCPO 6.x migration. This * (asterisk)

parameter allows RDBMS to write to a file.
Use the following SQL*Plus command to check parameter values:
select name, value from v$parameter where name= 'cursor_sharing';
After adjusting parameters, stop and restart the Oracle database.
Note: JDA currently supports a single instance database. While the use of Container or Pluggable
databases is supported by Oracle and may seem appropriate for a small development or QA
environment, JDA has not certified such configurations. Given the tuning requirements for databases
running JDA applications, JDA does not recommend such a configuration in a production environment.
Create an Oracle database

Follow the instructions in this section to create an Oracle instance on Windows. The following database
names are examples, but not required, for JDA applications:
NWSAMPLE: sample database

NWPROTO: prototype database4
NWPROD: production database
NWTEST: test database
1. Log into Windows using an ID that is part of the Administrators group or log onto UNIX as the
Oracle user.
Be sure you have set the following Oracle system environment variables set:
Environment
Value
variable
ORACLE_BASE The top-level Oracle directory (for example, c:\oracle or /u/oracle).
PATH Includes the \bin directory for the correct version of Oracle (for example,
c:\oracle\12.1.0.2\bin or /u/oracle/product/12.1.0.2/bin). The bin
directory for the supported Oracle version must be before the bin directory for
any other version of Oracle on the computer. For more information, see
On UNIX, LIBRARY Includes the $ORACLE_HOME/lib directory for the correct version of Oracle
PATH (LIBPATH, or (for example, /u/oracle/12.1.0.2/lib). The lib directory for the required
LD_LIBRARY_PATH, Oracle version must be listed before the Oracle lib directory for any other
depending on the OS) version of Oracle on the computer.
2. Copy the appropriate Windows or UNIX database scripts from the JDA Platform CD image to the
machine. The database directory on the CD image contains the following files:
CreateDB.sql
CreateDBCatalog.sql
CreateDBFiles.sql
initO12CR102.ora
JServer.sql
lockAccount.sql
O12CR102.bat or O12CR102.sh
O12CR102.sql
postDBCreation.sql
3. Copy the files to new files based on the name of the database being created. The database name
can have up to eight characters. For example, if you were creating a database called NWSAMPLE,
enter the following commands:
copy O12CR102.bat nwsample.bat or O12CR102.sh to nwsample.sh
copy O12CR102.sql nwsample.sql
copy initO12CR102.ora initnwsample.ora
copy the other files into the same directory
4. Using a text editor, open the file <SID>.bat/sh file (for example, NWSAMPLE.bat or
NWSAMPLE.sh).

a. Find and set the ORACLE_SID to the name of your database; for example, NWSAMPLE. This is
the name of your new Oracle instance (SID): set ORACLE_SID=nwsample
b. Find and set the ORACLE_BASE variable; for example: set ORACLE_BASE=c:\oracle or
/u/oracle/
c. Enter the ORACLE_HOME variable. This variable is set temporarily during the database
creation. When the process completes, the variable is reset. For example: set
ORACLE_HOME=c:\oracle\12.1.0.2
d. Search for "O12CR102" in <SID>.bat or <SID>.sh file and replace all occurrences with the
name of your database (for example, NWSAMPLE). It must match the name used in step 4.
e. Find the portion of the script that creates the subdirectories for the database files, and edit the
location for database subdirectories. The subdirectories store your Oracle database files.
Note: For optimal performance, you should spread the various database files across multiple
disks; in this case, you would edit the file to create multiple database directories on your
available disks (for example, d:\jdadb\oradata, e:\jdadb\oradata, f:\jdadb\oradata).
5. Using a text editor, open the file <SID>.sql (for example, NWSAMPLE.sql).
a. Search for "O12CR102"in <SID>.sql and replace with the name of your database (for
example, NWSAMPLE). It must match the name used in step 4.
b. Verify that all database file locations to conform to database directories.
c. If necessary, edit the tablespace and file sizes in the script.
IMPORTANT: You should consult with an experienced Oracle DBA concerning all of the
tablespace and file sizes specified in the script. The files sizes specified in the script are
appropriate for sample databases, but must be revised significantly for a production or test
database.
d. Search for two define strings. In the first, verify and change the password for the SYS user for
security.
change_on_install --change for security
In the second, verify and change the password for the system user for security:
manager --change for security
6. Using a text editor, open the file CreateDB.sql and search for and replace all "O12CR102" with the
name of your database (for example, NWSAMPLE).
IMPORTANT: In the database create script, the database character set is AL32UTF8. Do not change
this value, as this is the only supported database character set for the JDA products.
7. Edit the parameters in the file to conform to your system and to the size of the database you plan
to create. Parameter values are based on conservative requirements. You should adjust values
based on your specific requirements. Using a text editor, open the file init<SID>.ora (for
example, initnwsample.ora) and search for and replace all "O12CR102" with the name of your
database (for example, NWSAMPLE). Review and verify the following settings.
IMPORTANT: You should consult with an experienced Oracle DBA when editing these parameters.
a. On the database server, use a locale compatible with the database character set.
b. Edit any file locations to conform to your system.
c. Save and exit the file.
8. Using a text editor, open all the remaining database script files, search for "O12CR102" and replace
all occurrences with the name of your database (for example, NWSAMPLE).

CreateDBCatalog.sql
CreateDBFiles.sql
JServer.sql
lockAccount.sql
postDBCreation.sql
9. If you want to change the name of the default tablespace for the JDA Platform users, change the
tablespace name in the CreateDBFiles.sql script.
10. Create the database by opening a command-line or shell prompt and executing the batch or shell
file:
<SID>.bat or <SID>.sh
For example, if your database were named nwsample, you would type:
nwsample.bat or nwsample.sh
11. Allow several minutes for the process to complete. Generally, the process completes in less than an
30 minutes.
12. Review all script log files for errors that may have occurred during database creation. The following
error displays frequently, but it is normal and can be ignored:
public synonym to be dropped does not exist
If the database was created successfully, the database must be running. On Windows, the Oracle
service for the database specified in the script should be running. Check this by opening Services
in the Windows Administrative Tools. By default, this Windows service should start automatically
when the machine starts.
13. Create additional tablespaces for JDA applications you plan to install with JDA Platform. See Create
additional application tablespaces (on page 25).
Create additional application tablespaces

If you are installing and implementing the JDA Monitor application, you can create the Monitor tables in
the same schema with JDA Platform (by default WWFMGR), or you can create them in a separate
schema and tablespace. If you want to create the tablespace separately, use the script cr_ema_ts.sql
to create the Monitor tablespace.
If you are using an application that uses the Interface Generation Program for integration, use the
script cr_igp_ts.sql to create a tablespace for IGP.
Each additional application that you are installing should ship a script to create their application
tablespace and/or database user. Refer to the product documentation for details.
Install WebLogic application server on Windows

1. Install Java 8 (64-bit). For more information on the supported version, see System requirements
(on page 11).
2. Copy the WebLogic JAR file (wls_1221.jar) to the local system.
3. Add the location of the Java 8 bin directory to your environment variable PATH.
4. Run the installer by entering the following command through command prompt:
java -jar wls_1221.jar

The Oracle Fusion Middleware Welcome window is displayed.
5. Click Next. The Installation Location window is displayed.
6. Enter the installation path in the Oracle Home field. For example, c:\tools\weblogic\wls1221.
7. Click Next. The Installation Type window is displayed.
8. Select the WebLogic Server Installation option and click Next. The Prerequisites Checks
window is displayed.
9. Verify that both the Operating System and Java versions are correct, and then click Next. The
Specify Security Updates window is displayed.
10. If you have an Oracle Support account, select the I wish to receive security updates via My
Oracle Support check box to enter your Email ID and password to receive security updates. If you
do not have an Oracle Support account, deselect the I wish to receive security updates via My
Oracle Support check box.
Note: If you deselect the I wish to receive security updates via My Oracle Support check
box, an error message is displayed. Click Yes to go back to the Specify Security Updates window.
11. Click Next. The Installation Summary window is displayed.
12. Verify the installation options you selected. If you want to save these options to a response file,
click Save Response File and provide the location and name of the response file. Response files
can be used later in a silent installation purpose.
13. Click Next. The Installation Progress window is displayed.
14. This screen allows you to see the progress of the installation. Click Next when all the installation
tasks are completed. The Installation Complete window is displayed.
15. Deselect the Automatically Launch the Quickstart Configuration Wizard check box and click
Finish.
Install WebLogic application server on UNIX

To install WebLogic on UNIX using the console install, you need to set the DISPLAY environment
variable to a valid X-windows server.
1. Install Java 8 (64-bit) on the UNIX machine. For more information on the supported version, see
2. Copy the WebLogic JAR file (wls_1221.jar) to the UNIX machine.
3. Add the location of the Java 8 bin directory to your environment variable PATH.
4. Run the installer by entering the following command through command prompt:
java -jar wls_1221.jar
The Installation Inventory Setup window is displayed.
5. Enter the inventory installation location and click OK. The Oracle Fusion Middleware Welcome
6. Click Next. The Installation Location window is displayed.
7. Enter the installation path in the Oracle Home field. For example, /tools/weblogic/wls1221.
8. Click Next. The Installation Type window is displayed.
9. Select the WebLogic Server Installation option and click Next. The Prerequisites Checks

10. Verify that both the Operating System and Java versions are correct, and then click Next. The
Specify Security Updates window is displayed.
11. If you have an Oracle Support account, select the I wish to receive security updates via My
Oracle Support check box to enter your Email ID and password to receive security updates. If you
do not have an Oracle Support account, deselect the I wish to receive security updates via My
Oracle Support check box.
Note: If you deselect the I wish to receive security updates via My Oracle Support check
box, an error message is displayed. Click Yes to go back to the Specify Security Updates window.
12. Click Next. The Installation Summary window is displayed.
13. Verify the installation options you selected. If you want to save these options to a response file,
click Save Response File and provide the location and name of the response file. Response files
can be used later in a silent installation purpose.
14. Click Next. The Installation Progress window is displayed.
15. This screen allows you to see the progress of the installation. Click Next when all the installation
tasks are completed. The Installation Complete window is displayed.
16. Deselect the Automatically Launch the Quickstart Configuration Wizard check box and click
Finish.
Note: On a UNIX installation, permissions may not be set correctly if you are not using the same user
as installed the software. If you plan to run the JDA server with a different user than installed
WebLogic, then you need to ensure that the following permissions are set on the WebLogic installation:
The following files/directories need to be 755 (-rwxr-xr-x)
../wlserver/common/*
../wlserver/server/*
../oracle_common/modules/org.apache.ant_1.8.4
Install WebSphere application server

1. Install the IBM Installation Manager.
Note: IBM Installation Manager is required to install and update WebSphere and its supplements.
This is a 32-bit installation, even on a 64-bit machine.
a. Extract the agent.aix.1.6.1000.20121109.zip file to a temporary directory and run the

installation file to launch the installer.
b. Follow the prompts to install.
c. When complete, select the option to re-start the Installation Manager.
2. Create two directories to store the image files. For example:
\temp\websphere85base - extract the following WebSphere base installation files here:
WAS_ND_V8.5_1_OF_3.zip
3. If you want to install the WebSphere HTTP server, or the Web server plug-ins, create the following
additional directory:

\temp\websphere85_supplements - extract the following WebSphere supplement files

here:
WAS_V85_SUPPL_1_OF_3.zip,
WAS_V85_SUPPL_2_OF_3.zip
WAS_V85_SUPPL_3_OF_3.zip
4. Create two directories to store the image files.
\temp\websphere8557 - extract the following files here:
8.5.5-WS-WAS-FP7-part1.zip
8.5.5-WS-WAS-FP7-part2.zip
\temp\websphere8557_java7 - extract the following Java7 ZIP files in this directory:
7.1.3.10-WS-IBMWASJAVA-part1.zip
7.1.3.10-WS-IBMWASJAVA-part2.zip
5. If the WebSphere HTTP server is installed, or Web server plug-ins is installed, create an additional
directory and extract the two WebSphere supplement fix pack files.
\temp\websphere8557suppFP - extract the following files here:
8.5.5-WS-WASSup-FP7-part1.zip
8.5.5-WS-WASSup-FP7-part2.zip
6. From the Installation Manager:
Select File > Preferences > Passport Advantage and ensure this is deselected.
Select File > Preferences > Repository and create a repository for each of the directories
that you created (Step 1 through 4). You must select the repository.config file. This file is
available at the top of each of the directories.
When all repositories are created, click Test Connections to validate them.
Select OK to close the Preferences.
7. On the main screen, click Install. Lists of potential packages are displayed based on the
repositories that you selected.
a. Select IBM WebSphere Application Server Network Deployment.
If installing the HTTP server, select IBM HTTP Server for WebSphere Application
Server v8.5.5.7.
If installing the web server plug-ins, select Web Server Plug-ins for IBM WebSphere
Application Server v8.5.5.7.
b. Select IBM WebSphere SDK Java v7.1.3.10.
c. Click Next. The License window is displayed.
8. Select I Accept and click Next.
9. On the Install Package window, select Create a new package group and enter the location for
the installation.

10. Click Next. The Translations window is displayed.
11. Click Next. The Feature window is displayed.
12. Select the appropriate Java7 64-bit JDK file and click Next. The Summary Information window is
displayed.
13. Click Install. When complete, do not create any profiles through this UI.
14. Click None.
Switch to use the Java7.1 SDK as the default Java with

WebSphere
This release of JDA Platform requires Java7, which must be enabled by default in the WebSphere
application server. When you install Websphere 8.5, it contains both $WAS_HOME/AppServer/java
(Java 6) and $WAS_HOME/AppServer/java_1.7.1_64. By default, WebSphere 8.5 uses Java 6.
To use Java 1.7.1 as the default, run the following commands before creating profiles in the
installation.
From the $WAS_HOME/AppServer/bin directory:

./managesdk.sh -setNewProfileDefault -sdkname 1.7.1_64
This should return the following message:

CWSDK1022I: New profile creation will now use SDK name 1.7.1_64.
CWSDK1001I: Successfully performed the requested managesdk task.
To set WebSphere to use Java 1.7 in any of its commands, run the following command:
./managesdk.sh -setCommandDefault -sdkname 1.7.1_64
You should see the following message:

CWSDK1021I: The command default SDK name is now set to 1.7.1_64
To change all existing profiles to use Java 1.7:
./managesdk.sh -enableProfileAll -sdkname 1.7.1_64
You should see the following message.

To change a particular profile to use Java 1.7:

./managesdk.sh -enableProfile -profileName <profile_name> -sdkname 1.7.1_64 -
enableServers
Validate the WebSphere installation with Java7

From the $WAS_HOME/bin directory, run the following commands to validate the correct JVM is
enabled in the WebSphere installation:
./managesdk.sh -listAvailable
Both Java 1.6 and Java 1.7 is displayed, as follows:

CWSDK1003I: Available SDKs :
CWSDK1005I: SDK name: 1.6_64

CWSDK1005I: SDK name: 1.7.1_64

CWSDK1005I: SDK name: 1.7_64
To review the default profile creation JDK:

./managesdk.sh -getNewProfileDefault
The following output is displayed:

CWSDK1007I: New profile creation SDK name: 1.7.1_64
./managesdk.sh -listEnabledProfileAll
To confirm that Java 1.7 is used by default for all commands:

./managesdk.sh -getCommandDefault
You should see Java 1.7 as follows:

CWSDK1006I: COMMAND_DEFAULT_SDK = 1.7.1_64
Create a WebSphere server profile

1. In the Profile Management Tool, select Create.
2. Select Application Server Profile and click Next.
3. Select Advanced profile creation and click Next.
4. In the Optional Application Deployment, de-select the deployment of the default application
and keep the administrative console and click Next.
5. Enter the Profile Name and Location (the default location is $WAS_HOME/profiles) and click
Next.
Note: Ensure that the name of the directory matches the profile name (for example,
$WAS_HOME/profiles/<profile_name>).
6. Enter the Node Name (for example, demand1Node01), and accept the default Server Name and
Host Name values. Click Next.
7. Deselect the option to enable administrative security and click Next.
8. Accept the defaults values for the Security certificate (create new personal cert and root
signing cert) and click Next.
9. Update the security information in the Security Certificate part 2 window to expire in 10 years
instead of 1 year and click Next.
10. Enter the value in the Port field and click Next.
Note: In a shared machine, select contiguous ports within your port range.
11. Deselect the option to run as a Windows service and click Next.
12. Do not select the option to create a web server definition and click Next.
13. Review the summary and click Create to create the profile.

Create a WebSphere profile for a non-clustered environment

For a standalone (non-clustered) installation, use the following command to create a default profile
from the $WAS_HOME/bin directory:
manageprofiles.sh -create profileName <profile_name> -profilePath

$WAS_HOME/profiles/<profile_name> -templatePath $WAS_HOME/profileTemplates/default
-nodeName <profile_name>Node01 -cellName <profile_name>Cell01 -hostName <hostname>
-isDefault false -startingPort <port>
For example, to create a profile called jda2016, run the following command:
manageprofiles.sh -create profileName jda2016 -profilePath
$WAS_HOME/profiles/jda2016 -templatePath $WAS_HOME/profileTemplates/default -
nodeName jda2016Node01 -cellName jda2016Cell01 -hostName
jdaserver.company.corp.local -isDefault false -startingPort 7070
Note: The profile uses 20 ports from the starting point (including), so ensure that all ports are free.
Create WebSphere profiles for a clustered environment

If you plan to install in a clustered environment, create one Deployment Manager (Dmgr) profile and
multiple AppServer profiles. The number of AppServer profiles is equal to the number of cluster
members. The Dmgr is used as administer for the multiple AppServer profiles. By default, a AppServer
profile is not under the control of Dmgr. The AppServer profiles should be placed under the control of
Dmgr through a process called Federation. While installing WebSphere ND, if you have selected Cell as
the server environment, the Dmgr and one AppServer profile named AppSrv01 are created by default
and federated. Use the instructions in this section to federate other profiles.
To create a Dmgr profile, use the following command:
manageprofiles.sh -create -profileName <profile_name> -profilePath

$WAS_HOME/profiles/<profile_name> -templatePath
$WAS_HOME/profileTemplates/management -nodeName $1Node01 -cellName
<profile_name>01Cell -hostName <hostname> -isDefault false -startingPort <port> -
serverType DEPLOYMENT_MANAGER
For example, to create a Deployment Manager profile called Dmgr,
./manageprofiles.sh -create -profileName Dmgr -profilePath $WAS_HOME/profiles/Dmgr

-templatePath $WAS_HOME/profileTemplates/management -nodeName DmgrNode -cellName
DmgrCell -hostName host1.company.corp.local -isDefault false -startingPort 9601 -
serverType DEPLOYMENT_MANAGER
After you have created the Dmgr profile, start the manager process using the following command:
<WAS_HOME>/profiles/dmgr/bin/startManager.sh
Once the Manager is started, you should be able to access the WebSphere Console using the
administrative port for the profile (review the portdef.props in the profile properties directory for the
exact port for WC_adminhost):
http://host:port/ibm/console
Note: The process of configuring the clustered environment is called federation in WebSphere
terminology. To join the application profiles to the deployment manager, use the addNode.sh script
from each profile directory (for example, <WAS_HOME>/profiles/$AppProfile/bin):
For example, to set up a clustered environment, where the Dmgr on host1 and two JDA application
servers are running on host1 and host2 respectively:

1. Create two new application server profiles. For example, AppSrv01 on host1 and AppSrv02 on
host2. When creating the profiles ensure that these nodes have unique names, for example,
AppSrvNode01 and AppSrvNode02.
2. Ensure that deployment manager is running. For the following example, assume that Dmgr is
running on a server named host1 and uses 8879 as its SOAP port.
3. Federate the two nodes using the addNode.sh command from the bin directory for each of the
individual nodes using the syntax.
./addNode.sh <Dmgrhost> <DmgrSOAPport> -includeapps userName <username> -password
<password>
For example:
To federate AppSrv01 from directory <WAS_HOME>/profiles/AppSrv01/bin enter the

following:
addNode.sh host1 8879 includeapps userName appAdmin password password
To federate a node from a remote machine (host2 where AppSrv02 profile is located), from the
directory <WAS_HOME>/profiles/AppSrv02/bin, enter the following:
addNode.sh host1 8879 includeapps userName appAdmin password password
Once successfully federated, nodeagent processes are created for these nodes. The nodes are
displayed in the admin console. You can start and stop the node agents individually by using the
startNode.sh and stopNode.sh commands.

Installation
Chapter 4. Installation
Installation values required
Prior to installation, use the following table to make note of the values that you must fill in during
installation:
Description Value
Installation directory
WebLogic or WebSphere installation location.
If installing with WebSphere, the WebSphere profile name, the application
name, and the server name
Application server hostname
Application server ports (standard and SSL)
Admin server ports (standard and SSL) for WebLogic installs
CIS Agent and SSO server ports
Java installation directory (WebLogic only)
Host enterprise name
Web application context root
Environment name
Oracle home directory
Oracle database server, listener port, and Service name
Foundation database schema owner and password
JDA_SYSTEM database schema owner
ABPP database schema owner and password
Monitor database schema owner and password (if installing Monitor)
System and system administrators email address
SMTP server name
If running the post-installation steps to create the JDA Platform schemas,
the JDA_SYSTEM and Oracle System password is required.
Note: 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
2 Create database users (can be done during
installation)
JDA_SYSTEM
ABPP
Foundation

Installation
S. No Tasks Status Notes

3 Create or migrate database schemas (creating
an empty schema can be done during
installation)
JDA SYSTEM
ABPP
Foundation
4 Configure Platform server (can be done during
installation, but must be done after all
applications are installed)
5 Create Windows services (Windows only) -
can be done during installation
6 Verify Platform installation
7 Install Platform SRE (if required)
Install Platform
When you install JDA Platform, you should enter values in all requested fields. If you are unsure about
what to enter, you should still enter some value and make a note of it. The software does not function
correctly if many installation values are blank or incorrect. In some cases, you can change the values
after installation. Several values entered during installation populate JDA scripts. You can go back
during the installation to check or change entries. To use a silent installation, see Silent installation for
JDA Platform (on page 39).
IMPORTANT: Do not install JDA Platform under a UTF-8 locale on UNIX.
1. Log in to the computer as a user with privileges to install the software.
2. Save and exit other running programs.
3. Change to directory <image_dir>\platform.
4. Change to the subdirectory for your operating system and execute the binary or executable file at
the command-line or shell prompt:
AIX: /platform/aix/installPlatform.bin
Solaris: /platform/solaris/installPlatform.bin
Linux: /platform/linux/installPlatform.bin
Windows: \platform\windows\installPlatform.exe
If an error message is displayed on UNIX platforms that the file cannot be executed, you must
change the permissions. For example:
chmod +x installPlatform.bin
Run the binary file again. The Introduction window is displayed.
5. Click Next. In the License Agreement window, review and accept the license agreement.
6. Click Next. The Choose Install Folder window is displayed. Enter the full path to install the
software. The default installation directory is C:\JDA\JDAv2016_1 (on Windows) or the users
home directory on UNIX. You can enter or select the directory path. If you enter the directory
name, use ASCII characters (A-Za-z). The installation utility creates the directory path if it does
not exist.

Installation
CAUTION: This path is the WEBWORKS_HOME directory. When you install JDA
applications that are based on the JDA Platform, they must install to this path. Do not
install non-JDA software in this directory.
7. Click Next. On Windows, the Choose Shortcut Folder window is displayed, with options to create
an entry in the Start menu. UNIX does not have an equivalent window.
8. Click Next. The Use Installation Defaults window is displayed. Select the Use Installation
Defaults check box (Windows) or enter 1 (UNIX) to skip the below listed installer windows with
the default settings.
Application Server and CIS Ports (7001, 7002, 7003, 7004, 5015, 8088)
Platform and Monitor Schema Names (WWFMGR)
Tablespace names (WWFDATA)
Context Root (jda)
Database Connection Pool Sizes
Note: If you select the option to use the installation defaults, many of the subsequent screens
may be skipped or abbreviated.
9. Click Next or press Enter. The Choose License File window is displayed. Enter the path where the
license file is located.
Notes:
A software license file is required to run JDA Platform based applications. JDA provides the
license file with the software shipment. This license file is validated for all installations that are
performed in this JDA Platform installation directory. Once the license validation has
succeeded, you can continue with the installation.
In case of a software upgrade, JDA Platform needs to be re-installed with a new license.
10. Click Next. The Choose Application Server window is displayed. You can select WebLogic or
WebSphere.
If you have selected WebLogic, then perform the following steps:
a. Enter or select the location of the Weblogic 12.2.1 installation and click Next.
b. Java Home Folder: Enter or select the location of the supported version of Java for the
operating system.
c. WebLogic Server Folder: This should default to the location of your WebLogic server
installation (for example, d:\tools\weblogic12.2.1\wlserver_12.2.1). Confirm or
modify the location of the WebLogic installation and click Next
d. Enter the following details for Server Configuration:
Server Host Name: The name of the server machine.
Server Standard Port: One unique port that no one else on the machine is using.
Server Secure Port: One unique port that no one else on the machine is using
(usually the next port from the Server Standard Port). For example, Server Standard
Port number + 1.
Admin Server Port: A unique port that will be used for the Admin Server

Installation
Admin Server Secure Port: A unique port that will be used for the Admin Server
secure port.
If installing with WebSphere, then perform the following steps:
a. Enter the location of the WebSphere Home Folder (for example,

/usr/local/IBM/WebSphere8.5.5-64bit/AppServer). Confirm or change the location
of the WebSphere installation and click Next.
b. In the WebSphere Server Configuration, enter the following:
Server Host Name: The fully qualified name of the server machine.
Server Config Name: A unique name of installation for your WebSphere server (for
example, Platform).
Application Config Name: The name of the WebSphere application that you want to
create when you deploy the server.
Server profile name: Enter the WebSphere profile name for your installation (for
example, AppSvr01).
Server Standard Port: One unique port that no one else on the machine using. The
installation uses this port plus the next 19 consecutive ports. Do not use the ports that
are assigned to the WebSphere profile.
11. Click Next. The Hosting Enterprise Name window is displayed. Replace Company Name with the
name of the Host Enterprise. The Host Enterprise is the company that controls all data in the
system.
This entry is case-sensitive and can contain spaces. Because the Hosting Enterprise Name is used
to initialize and migrate the Foundation schema, do not leave it blank. If migrating the Foundation
schema, enter the name exactly as it appears in the following database query against the
Foundation schema:
select enterprise_name from csm_enterprise where enterprise_id=1;
12. Click Next. The Web Application Context Root window is displayed. Enter the common context root
to prefix all application URLs. The default is jda.
13. Click Next. The Environment Name window is displayed. You can enter a name to uniquely identify
the JDA environment. This name is displayed on the JDA title bar and in names of JDA Windows
services. You can leave this blank.
14. Click Next. The JDA System User Database Connection window is displayed. Enter the Oracle
User Name of the user you want to own the JDA system objects in the database. The default is
JDA_SYSTEM.
15. Click Next. The Choose Oracle Home Folder window is displayed. You can enter or select the oracle
home directory path.
16. Click Next. The Foundation Database Connection window is displayed. The JDA Platform Server
connects to the Foundation schema in Oracle using this information. Enter the following
parameters:
Oracle Host Name: The name of the Oracle database server where you will create the
Foundation schema. This could be a different server.
Oracle Listener Port Number: The TNS listen port for the Oracle database server.

Installation
Oracle Service Name: The Oracle System ID (SID), that is, the name of the instance
containing the Foundation schema.
Oracle User ID: The User ID that owns the Foundation schema.
Oracle Password: The password for the User ID.
17. Click Next. The Foundation Connection Pool window is displayed. The default values are
appropriate for most installations, but you may need larger values for larger installations. You can
change the values after installation.
Connection Pool Initial Capacity: The number of connections made to the database when
the pool is generated. The default is 5.
Connection Pool Max Capacity: The maximum number of connections to the database. The
default is 30.
Connection Pool Capacity Increment: The number of connections added to the database
when no connections are available, but not to exceed the maximum capacity. The default is 5.
18. Click Next. The ABPP Database Settings window is displayed.
ABPP Oracle User ID: The User ID that will own the ABPP schema (for example, abppmgr).
This schema is required for JDA Platform, and should be in a different schema than the
Foundation schema.
ABPP Oracle Password: Specify the user password.
19. Click Next. If you are licensed for Monitor, the Install JDA Monitor? window is displayed. Select
whether or not to install JDA Monitor.
Note: This window is only displayed if Monitor is enabled in your license file.
20. Click Next. The Monitor Database Settings window is displayed.
Monitor Oracle User ID: The User ID that owns the Monitor schema. This can be the same or
different from the Foundation schema name. If you are migrating a database, ensure this
matches the name of your existing Monitor schema.
Monitor Oracle Password: Specify the password.
Connection Pool Initial Capacity: The number of connections made to the database when
the pool is generated. The default is 5.
Connection Pool Max Capacity: The maximum number of connections to the database. The
default is 30.
Connection Pool Capacity Increment: The number of connections added to the database
when no connections are available, but not to exceed the maximum capacity. The default is 5.
21. Click Next. The Database Tablespaces window is displayed.
Foundation tablespace: The name of the tablespace you want to assign to the JDA Platform
database users. Default is WWFDATA.
Flexible Editor tablespace: Flexible Editor creates temporary tables in this Oracle tablespace
to support related navigation and other operations. Use a valid tablespace name to hold these
temporary tables. You can use the same tablespace name that will hold the Foundation
schema, or you can designate a different tablespace. You can change the tablespace after
installation in System Properties.

Installation
Monitor tablespace (if Monitor is installed): The name of the tablespace to assign to the
Monitor database user, if different from the Foundation user. Default is EMADATA.
22. Click Next. The CIS Settings window is displayed.
CIS Manager UI Port: The port number for the CIS SSO Manager. The CIS SSO Manager will
listen for requests on this port. The default is 8088.
CIS Agent Port: The port number for the CIS Agent. CIS Agent will listen for requests on this
port. The default value is 5015.
CIS Server Name: The name of the server where CIS is installed. If you intend to use the CIS
server that is installed as part of this installation, keep the default of "localhost". Otherwise,
enter the hostname of the server where you will run the CIS services.
23. Click Next. The Language Selection window is displayed with a list of additional languages for
which you want to install the online help (besides English). Select the check box next to a
language, to install help in that language also.
24. Click Next. The Email Configuration window is displayed. Based on certain events, the server
sends email messages through an SMTP host to recipients. Replace the defaults with actual values
for your environment. Enter the following:
System Administrators Email Address: This is the email address of the person who
maintains the server, for example, user@company.com. Use an actual email address that is
checked frequently.
Systems Email Address: This is the "From Address" that appears on emails sent by the
system. Use a unique name so it is easily distinguished.
SMTP Host Name: This is the name of the outgoing email server. Specify a mail transfer
agent used to transfer messages between machines. If you do not know this information, your
email system administrator should have it. For example, mail.server.com.
Note: For some migration activities, you will need the ability to send emails to users to reset
their passwords. Therefore, it is recommended that you configure this information during
installation.
25. Click Next. The Pre-Installation Summary window is displayed which lists the configuration
choices, including the amount of disk storage space required and available. To change the settings,
click Previous (Windows) or enter back (UNIX).
26. Click Install to proceed with the installation. The installation utility begins copying files from the
installation media to your computer. This may take several 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.
27. The Post Installation Steps window is displayed. You can select the following post installation tasks
to:
Create Platform Database Users: Create the Platform database users (JDA_SYSTEM,
Foundation, ABPP, and Monitor).
Create Platform Database Objects: Create and populate the Platform database
(JDA_SYSTEM, Foundation, ABPP, and Monitor)
Configure Platform Server (WebLogic only): Configure the JDA Platform server. This runs
the server configuration to create and deploy the JDA Platform server to a WebLogic domain.

Installation
Install Windows Service (Windows only): Configure the JDA Platform Server as a
Windows service.
If the options to Create the Platform Database Users or Create Platform Database Objects
are selected, you need to provide the following passwords:
JDA SYSTEM User Password: Required to create the JDA_SYSTEM user and schema if the
options to create the database users or objects are selected. This password is not stored in the
installation.
Oracle System Password: Required to create the JDA Platform users and schema. This
password is not stored in the installation.
Notes:
When you perform the post installation steps during the installation process, it also invokes
the Platform database patch scripts automatically and upgrades the Platform database to
the latest database patch level. If the post installation task is completed successfully, do
not run the standalone database patch scripts.
You can run the runPostInstallTask script through command prompt in the
\config\bin\platform directory to invoke the post installation tasks any time after
installation.
28. When the Install Complete window is displayed, click Done.
29. Verify the installation. The installation captures and creates record files during the installation. The
file JDA_Platform_2016.1_Install_<time_stamp>.xml in directory <install_dir> indicates
whether the installation was successful. The file platform-install-debug.txt contains the values
and environment used during installation.
Note: The database passwords are not retained in this file.
Both files should be retained for reference. The installation creates directories and files outlined in
Installed program directory structure.
This completes the JDA Platform installation.
Install additional applications that you will run with JDA Platform. After all applications are
installed, configure the application server if not done using the post-install tasks in the relevant
installation.
If you are migrating an existing database from an earlier version, migrate your Platform
schemas using the instructions in Upgrade the JDA Foundation schema (on page 69). If you
are using Monitor, migrate your existing Monitor schema using the instructions in Migrate the
JDA Monitor Schema.
If you are installing on UNIX, proceed to Configure the environment on UNIX (on page 61)
before creating or migrating your database.
Silent installation for JDA Platform

The silent installation for JDA Platform requires a properties file and the installation file. Place both files
in the same directory on the machine where the software is being installed. If installing multiple
applications, you can create a script to run multiple silent installations in sequence. JDA Platform must
be first in the sequence.
1. Log in to the computer as a user with the required privileges for installation.
2. Save and exit other programs running.

Installation
3. From the extracted CD image copy installPlatform.properties to the computer where the
software will be installed.
4. In the extracted CD image, change to the subdirectory for your operating system. Copy the
installation binary or executable file to the same directory as the previous step.
UNIX: installPlatform.bin
Windows: installPlatform.exe
5. Using a text editor, open installPlatform.properties and enter values for all the properties.
Note: Ensure that you do not add spaces or tabs at the end of any of the values in the properties
file.
Some properties have default values. For more information on configuring the file, see the
following table:
Property Description
INSTALLER_UI Use Silent. Do not change this setting.
USER_INSTALL_DIR The directory path where JDA Platform installs. On

Windows, use double back slashes between
directories. On UNIX, use single-forward slashes.
The path specified becomes the <install_dir>. For
example c:\\jda\\jdav2016_1 or
/usr/jda/jdav2016_1
APPSERVER Specify the application server name. Specify
weblogic or websphere. Note that websphere is
supported on AIX only.
HOST_ENTERPRISE_1 The Host Enterprise is the top-level enterprise. Do
not leave this blank. This entry is case sensitive. The
entry populates scripts for database creation and
migration. If migrating, enter the host enterprise
exactly as it appears in the database. To determine
the host enterprise, use the following SQL*Plus
query:
select enterprise_name from csm_enterprise
where enterprise_id=1;
CONTEXT_ROOT_1 Enter the common context root to prefix all
application URLs.
Note: The valid values are alpha-numeric characters
(0-9, a-z, A-Z), hyphen (-) and underscore (_). Any
other special character is not supported.
The values of minimum and maximum entries in this

field are 1-20.
SERVER_HOST_NAME The name of the server where the software is being
installed.
Note: Do not use localhost.
SERVER_STANDARD_PORT The standard protocol that the server listens on. For
example, 7001.

Installation
SERVER_SSL_PORT The secure listen port for the JDA Platform Server.
This must be different from
SERVER_STANDARD_PORT. For example, 7002. On
WebSphere, this should be set to the value of
SERVER_STANDARD_PORT+1
SERVER_ORB_PORT On WebLogic set to the same value as
SERVER_STANDARD_PORT. On WebSphere, set to a
value equal to SERVER_STANDARD_PORT + 4
LICENSE_FILE Full path to the license file that you received with the
software.
ORACLE_HOME Full path to the ORACLE_HOME directory on the
server.
WWF_SYS_DB_VAR_1 Enter the Oracle user name of the user that owns
the JDA System objects in the database. Default is
JDA_SYSTEM.
WWF_DB_CONNECTION_VAR_1 Host name of the server hosting the Oracle database
containing the Platform schemas.
WWF_DB_CONNECTION_VAR_2 Port where the Oracle server listens for connections.
Default is 1521.
WWF_DB_CONNECTION_VAR_3 Oracle service name.
WWF_DB_CONNECTION_VAR_4 The Oracle User ID to access the Foundation

schema. This user may or may not already exist.
WWF_DB_CONNECTION_VAR_5 The password associated with the Foundation Oracle
User ID.
WWF_CONNECTION_POOL_VAR_1 The initial capacity for the connection pool.
WWF_CONNECTION_POOL_VAR_2 The maximum capacity for the connection pool.
WWF_CONNECTION_POOL_VAR_3 The connection pool capacity increment.
FLEXIBLE_EDITOR_TS_1 The Oracle tablespace where Flexible Editor creates
temporary tables. This can be the same tablespace
used by the Foundation schema or a different
tablespace. You can change this value later in
System Properties.
Note: Tablespace will not be created during the
installation process. You must use an existing
tablespace or create a new tablespace after
installation.
FOUNDATION_TABLESPACE The Oracle tablespace that you will assign as the

default tablespace to the Platform database users.

Installation
SUPPORTED_LANGUAGES=en This specifies the additional languages for which you
want to install Online help (besides English). The
value is written to the installer.properties and is
used to deploy the correct help. If you want to
display the online help in other languages, provide
comma separated language abbreviations for the
respective languages. For example, provide en, fr
abbreviations to enable English and French help.
If online help for the translated language does not
exist then English help will be displayed by default.
List of language abbreviations:
English (en)
French (fr)
German (de)
Russion (ru)
Japanese (ja)
Spanish (es)
Chinese (zh)
Simplified Chinese (zh_CN)
Portuguese (pt)
Italian (it)
EMAIL_CONFIGURATION_1 The email address for the administrator. This should
be an actual email address that is checked
frequently.
EMAIL_CONFIGURATION_2 The "From" email address for email messages sent
from the server.
EMAIL_CONFIGURATION_3 The name of the mail server that can send server
messages. Specify a mail transfer agent used to
transfer messages between machines. If you do not
know the mail server, ask the email administrator.
INSTALL_MONITOR Enter yes if you are licensed for Monitor and want to
install it. Enter no if you are not licensed for Monitor,
or if you are licensed and do not want to install it.
EMA_DATABASE_1 Monitor database schema owner name

EMA_DATABASE_2 Monitor database schema owner password
EMA_TABLESPACE The Oracle tablespace that you will assign as the
default tablespace to the Monitor database user.
EMA_CONNECTION_POOL_1 The initial capacity for the Monitor connection pool.
EMA_CONNECTION_POOL_2 The maximum capacity for the Monitor connection
pool.
EMA_CONNECTION_POOL_3 The Monitor connection pool capacity increment.
ABPP_DATABASE_1 The Oracle User ID that owns the ABPP schema.
ABPP_DATABASE_2 The password associated with the Oracle ABPP User
ID.

Installation
CIS_PORTS_1 Port where the CIS Manager listens for connections if
CIS is installed. If you are not installing CIS, then
this is the CIS Manager port for a CIS server that is
already installed. Default is 8088.
CIS_PORTS_2 Port where the CIS Agent listens for connections if
CIS is installed. If you are not installing CIS, then
this is the CIS Agent port for a CIS server that is
already installed. Default is 5015.
CIS_PORTS_3 Server where CIS runs for this server. If CIS will run
on this JDA Platform server, the value is localhost
(the default). Else, enter the name of the server
where CIS will run. In a clustered configuration,
typically one server is configured as the primary CIS
server and another serves as a backup.
ENVIRONMENT_NAME An unique name for the installation, which will be
displayed in the UI banner (for example, Dev, Test,
Production) and in the names of any Windows
services. Created for the application server.
WebLogic only
WEBWORKS_JAVA_HOME The location of the java installation.
For the supported version of Java for your platform,
see System requirements (on page 11).
BEA_HOME Specify the WebLogic Home Directory.

WEBLOGIC_HOME Specify the WebLogic application server home
directory. This is a subdirectory of BEA_HOME,
usually wlserver 12.2.1.
SERVER_ADMIN_PORT The port for the WebLogic Admin Server (default
7003).
SERVER_ADMIN_SSL_PORT The secure port for the WebLogic Admin Server
(default 7004).
WebSphere
WAS_HOME The location of the WebSphere installation. For
example, /usr/local/IBM/WebSphere8.5.5-
64bit.
SERVER_SOAP_PORT The WebSphere SOAP Connector Port. This must be
set to a value equal to SERVER_STANDARD_PORT +
5
SERVER_CONFIG_NAME The WebSphere Server name.
APP_CONFIG_NAME The WebSphere Application name.
SERVER_PROFILE_NAME The WebSphere profile name. You must create this
profile in WebSphere before the installation.
Post-installation steps (optional)

Installation
POST_INSTALL_CREATE_USERS_ANSWER If 1, the JDA Platform users (JDA_SYSTEM,
WWFMGR, and ABPPMGR) are created. This assumes
that the tablespace specified by the
FOUNDATION_TABLESPACE property exists in the
database.
POST_INSTALL_CREATE_DB_ANSWER If set to 1, the JDA Platform schema is created.
POST_INSTALL_CONFIGURE_SERVER_ANSWER If set to 1, the JDA Platform server is configured
automatically. Note that this option is not supported
on WebSphere.
POST_INSTALL_INSTALL_SERVICES_ANSWER If set to 1, the JDA Platform server is configured as a
Windows Service based on the Environment Name
property (Windows only).
JDA_SYSTEM_USER_PASSWORD If the property to Create Users or Create the
database are enabled, the JDA_SYSTEM password is
required.
ORACLE_SYSTEM_PASSWORD If the property Create Users or Create the database
are enabled, the Oracle System password is
required.
6. Save and exit installPlatform.properties.
7. Open a command-line prompt and change to the directory containing the

installPlatform.properties and installPlatform.bin executable or binary. Type the following
command:
installPlatform.[exe|bin] -f <properties_file>
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,
installPlatform.[exe|bin] -f <path>\<properties_file>
Allow several minutes for the installation to run.
8. Verify the installation. Locate the variable INSTALL_SUCCESS (containing SUCCESS) in the log file
for successful installation, and if the same variable contains ERROR, the installation fails. For UNIX
platforms, the install command returns a return code of 1 to indicate a successful installation. Any
other return code means that the installation failed. The installation creates two files:
JDA_Platform_2016.1_Install_<time_stamp>.xml and the platform-install-debug.txt in
directory <install_dir>. These files contain a summary of the installation, and should be retained
for reference. The XML file also indicates whether the installation was successful. The installation
creates directories and files outlined in "Installed program directory structure" (on page 50).
This completes the JDA Platform installation.
If not created during the installation, create the Foundation and ABPP schemas using the
instructions in "Create the Foundation schema and ABPP schema" (on page 66) or migrate your
existing Foundation schema using the instructions in "Upgrade the JDA Foundation schema" (on
page 69). If you are licensed for Monitor, create the Monitor database schema using the
instructions in "Create the Monitor Database Schema" or migrate your existing Monitor schema
using the instructions in "Migrate the JDA Monitor Schema".
If you are installing on UNIX, proceed to "Configure the environment on UNIX (on page 61)"
before creating or migrating your database.

Installation
Install Platform SRE

Install JDA Platform SRE
1. Log in to the computer as a user with administrative privileges. If installing on UNIX, the user does
not require root.
2. Save and exit other running programs. It is not necessary to shut down the JDA Platform Server.
3. Change to <image_dir>\platform_sre.
4. Change to the subdirectory for your operating system and execute the binary or executable file at
the command-line prompt
UNIX: /platform_sre/<platform>/installPlatform_SRE.bin
Windows: \platform_sre\windows\installPlatform_SRE.exe
If the console displays an error on UNIX machines that the file cannot be executed, change the
permissions. For example:
chmod +x installPlatform_SRE.bin
5. The Introduction window is displayed. Click Next. Choose Install Folder window is displayed.
6. Specify the full path where you want to install the software. The default installation directory on
Windows is C:\jda\jdav2016_1_sre, but you can type or choose a different directory path. If
you enter the directory name, use simple ASCII characters (A-Za-z). The installation utility creates
the directory path if it does not already exist. Click Choose to use an existing directory. Click
Next. The Choose Shortcut Folder (Windows) window is displayed. UNIX does not have an
equivalent entry. This window has options for creating an entry on the Start menu.
7. Click Next. The Choose License File window is displayed.
8. Enter the path where the license file is located. Click Next. The Choose Application Server window
is displayed.
Note: A software license file is required to run JDA Platform based applications. JDA provides the
license file with the software shipment. This license file is validated for all installations that are
performed in this JDA Platform installation directory. Once the license validation has succeeded,
you can continue with the installation.
9. Click WebLogic or WebSphere, then select Next. The Choose the Java Home Folder window is
displayed.
10. Enter or select the Java Home location. For more information on the supported version, see System
requirements (on page 11).
11. Click Next. The Server Configuration window is displayed.
12. Specify the JDA Platform Server. The SRE instance must communicate with this server. More than
one JDA Platform SRE instance can point to the same JDA Platform Server.
Server Name: The name of the JDA Platform Server
Server Standard Port: The listen port
Server Secure Port: The secure listen port (Weblogic only)
13. Click Next. The JDA System User Database Details window is displayed. Enter the Oracle User
Name of the user you want to own the JDA system objects in the database. The default is
JDA_SYSTEM.

Installation
14. The Choose Oracle Home folder window is displayed. Enter the location of the Oracle home
directory.
15. Click Next. The Foundation Database Connection window is displayed. Configure the database
parameters necessary for the connection to the Foundation schema. Enter the following values for
the Oracle database server:
Oracle Host Name: This is the name of the server hosting the Foundation schema. This could
be a different server.
Oracle Listener Port Number: This is the TNS listener port for the Oracle database server.
Oracle Service Name: The Oracle SID (System ID), that is, the name of the instance
Oracle User ID: The User ID that owns the Foundation schema.
Oracle Password: The password for the Foundation User ID.
16. Click Next. The Pre-Installation Summary window displays your configuration choices, including
the amount of disk storage space required and available. To change the settings, click Previous.
To proceed with the installation, click Install. The installation utility begins copying files to your
computer. This may take several minutes.
17. When the Install Complete window is displayed, click Done.
Update the trust store in a Websphere configuration

After you install JDA Platform SRE on a remote computer, and before you are ready to use SRE,
remember to add the signer certificate from your server to your local trust store. The retrieveSigners
command needs to be run whether SRE is run from the application server installation or from a
separate SRE installation. Unless you perform this step, SRE cannot communicate with the WebSphere
server. This should be done when the server is running. If your servers are in a cluster, you should run
the command against all the servers in the cluster.
Run the retrieveSigners command from the config/bin/platform directory. Use the command as
follows:
retrieveSigners server_iiop_URL
For example:
retrieveSigners iiop://jdasrv:7006
The IIOP port is HTTP port + 4. If your HTTP port is 7002, then the IIOP port should be 7006 (7002 +
4).
Install JDA Platform-based application SRE installations

After you have installed the JDA Platform SRE, install JDA application SRE installations. For example,
installCollabSvcs_SRE or installSCPOWeb_SRE. The JDA Platform-based applications provide these
files.
IMPORTANT: JDA Platform and JDA Platform SRE have similar files. Use the following table as a guide
when updating the files with custom values.

Installation
Configuration files for JDA Platform SRE

File Notes
installerVars Contains settings for environment variables that are set during
installation. If you want to adjust those settings after installation, you
should do it here.
webworks_config.xml JDA Platform SRE instances have their own webworks_config.xml to

set local system properties. System Properties automatically updates
global property changes and makes them available to SRE. However,
node pools running on the SRE instance must be restarted to effect any
changes to system properties or if a local property is changed in the
webworks_config.xml.
dbconnections.properties JDA Platform SRE instances have their own dbconnections.properties.
If you change the database source, check the connection information in
this file. Node pools running on the SRE instance must be restarted to
effect any changes to the file.
Note: Passwords in this file are encrypted; use the genEncrypted
password utility to generate an encrypted password if you need to
change the database password.
webworks.common.vars JDA Platform SRE instances have their own webworks.common.vars.
Silent installation for JDA Platform SRE

A silent installation uses installPlatform_SRE.properties and the installation file. Place both files in
the same directory on the machine where the software is being installed. If installing multiple
applications, you can create a script to run multiple silent installations in sequence. JDA Platform SRE
must be first in the sequence.
1. Log in to the computer as a user with administrative privileges.
2. Save and exit other running programs.
3. Change to <image_dir>. Copy the installPlatform_SRE.properties file to a directory on the

machine where the software will be installed.
4. Change to the subdirectory for your operating system. Copy the binary or executable file to the
same directory as the previous step.
UNIX: /platform_sre/<platform>/installPlatform_SRE.bin
Windows: \platform_sre\windows\installPlatform_SRE.exe
5. Using a text editor, open installPlatform_SRE.properties and enter values for all the properties.
Some properties have default values. For help in configuring the file, see the following table.
INSTALLER_UI Use Silent. Do not change this setting.
USER_INSTALL_DIR The directory path where JDA Platform SRE installs. Use
double-back slashes for Windows and single-forward slashes
on UNIX. The path specified becomes the <install_dir>. On
Windows, use simple ASCII characters (A-Za-z). For example,
c:\\jda\\jdav2016_1.

Installation
APPSERVER Specify the application server to use. weblogic or
websphere
WEBWORKS_JAVA_HOME The location of the java folder.
For more information on the supported version, see System
requirements (on page 11).
SERVER_HOST_NAME Specify the JDA Platform Server. The SRE instance must
communicate with this server. More than one JDA Platform
SRE instance can point to the same JDA Platform Server.
SERVER_STANDARD_PORT The standard listen port for the JDA Platform Server. For
example, 7001.
SERVER_SSL_PORT The secure listen port for the JDA Platform Server specified in
SERVER_HOST_NAME.
SERVER_ORB_PORT On WebLogic set to the same value as
SERVER_STANDARD_PORT.
On WebSphere set SERVER_ORB_PORT to

SERVER_STANDARD_PORT + 4. For example, if
SERVER_STANDARD_PORT is 7001, the SSL Port will be
7005.
LICENSE_FILE Full path to the license file that you received with the
software.
ORACLE_HOME Full path to the ORACLE_HOME directory on the server.
WWF_SYS_DB_VAR_1 Enter the Oracle user name of the users that owns the JDA
System objects in the database. Default is JDA_SYSTEM.
WWF_DB_CONNECTION_VAR_1 The name of the server hosting the Oracle database
WWF_DB_CONNECTION_VAR_2 The port where the Oracle server listens for connections.
Default is 1521.
WWF_DB_CONNECTION_VAR_3 The Oracle SID that contains the Foundation schema.
WWF_DB_CONNECTION_VAR_4 The Oracle User ID to access the Foundation schema.

WWF_DB_CONNECTION_VAR_5 The password associated with the Oracle User ID.
6. Save installPlatform_SRE.properties and exit the text editor.
7. Open a command-line prompt and change to the directory containing the

installPlatform_SRE.properties and installPlatform_SRE executable or binary. Type the
following command:
installPlatform_SRE.[exe|bin] -f <properties_file>
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,
installPlatform_SRE.[exe|bin] -f <path>\<properties_file>
Allow several minutes for the installation to run.
8. Install JDA application SRE installations. For example, installCollabSvcs_SRE or

installSCPOWeb_SRE. The JDA applications provide these files.

Installation
Cluster setup
On WebLogic
Install WebLogic once on each machine in the cluster. Even if you plan more than one managed server
on a machine, install WebLogic only once. For detailed instructions on installing WebLogic, see Install
Weblogic Server (64-bit). After installation, continue with Install JDA Platform for a cluster (on page
49).
On WebSphere
Install Websphere once on each machine in the cluster, then create different WebSphere profiles that
are federated to a common Deployment Manager. For more information, see Install WebSphere
application server (on page 27).
Install JDA Platform for a cluster

Install JDA Platform once for each managed server. If you plan two managed servers on a machine,
then install JDA Platform twice to different directories. For example,
c:\jda\jdav2016_Foundation1
Each JDA Platform installation is referred to as a managed server. When installing the JDA Platform
multiple times on the same machine, enter the same information in all fields, with the following
exceptions:
In Choose Install Folder dialog box, enter a unique path for each installation.
In Choose Shortcut Folder dialog box, select a new Program Group for each installation or do
not create icons (Windows).
In Server Configuration dialog box, enter a different port number for each installation when
using a static IP address. For example, 7001, 8001. If the machine is multi-homed with more than
one static IP address, then you can use the same port number. Do not use localhost for the
machine name when installing JDA Platform. Use the actual server name.
In the Foundation Security Model Oracle Connection and ABPP Oracle connection dialog
box, the parameters must be the same for all installations. The managed servers must share the
same Platform schema.
Install JDA applications for the cluster

Install each application on each managed server and on the admin server. For example, if you have
installed JDA Platform in two locations, then you have two managed servers and the applications must
be installed to both instances. In this example, JDA Platform is installed in two locations, and the JDA
applications must also be installed in both:
Use the same Database Settings for the same applications. After installation, create or migrate the JDA
application database schemas.
Continue with "Configure the admin server" (on page 104).

Installation
Installed program directory structure

Installing the JDA Platform creates a directory structure shown in the following table. Other JDA
Platform-based applications append their directory structure to the <install_dir> directory. You should
not alter the directory structure or change files unless directed in this guide or by a JDA consultant.
JDA Platform directory structure

Directory Contents
config\<application> Directory for each JDA Platform-based application installed. The
application directory contains subdirectories that are not contained in the
database, bin, or doc folders. For example, config\scpoweb or
config\collabsvcs.
config\doc Contains the product Release Notes files. Online help and PDF Guides are
installed in the help and guides subdirectories
config\ear The root of the Enterprise Archive directory.
config\ear\<application> Contains application JAR (Java Archive) and WAR (Web Archive) files in a
folder for each JDA Platform-based application that is installed.
config\jmsstore Contains the persistent JMS message queues, usually DAT files. By
default, contains the file placeholder.txt to prevent removal of the
directory.
config\lib Contains wcif.jar and webworks.jar files as well as other application
jar files. For example, SCPOWeb.jar used by JDA Fulfillment and JDA
Demand. The JAR files present depend on what JDA applications are
installed.
config\logs Default location for common framework appserver.log and other log
files.
config\JDADomain Contains the config.xml file used to configure the server. All JDA
Platform-based products for the Web run under the JDADomain domain
name.
Note: Applicable for WebLogic only.
config\monitor Contains scripts and templates used with JDA Monitor. This directory
may be present even though you are not using JDA Monitor. JDA
applications use Monitor for business rule exception processing. The
applications place files in this directory. If not installing Monitor, you can
ignore this directory.
config\properties Contains JDA Platform XML and properties files such as
webworks_config.xml. Also contains JDA applications properties files
installed with each application.
config\reports Contains the Cognos models and deployment packages for JDA
Reporting. Each application places their files here.
config\resources Contains application resource bundles for the JDA Platform user
interface, including Security Manager. Also contains resource bundles for
many JDA Platform-based applications that are installed.
config\vendor Contains JAR files and third-party software files.
config\websphere Contains WebSphere setup related files

config\database\setup Contains scripts to create a tablespace, and to create an Oracle instance
(SID).

Installation
Directory Contents
config\database\platform Contains scripts to initialize or migrate the Platform schemas,
config\bin\platform Contains JDA Platform server configuration and startup scripts, utilities,
Interface Generation Program (IGP), and Data Division Utility (DDU)
tools.
config\wsdl Contains Web Services Description files, such as Security Services
config\xsd Contains XML schema definition and document type definitions (DTDs)
used during runtime and for batch processing.
install Contains the component files used to build the webworks_config.xml,
application.xml, and startWebworksServer files. Each installed JDA
application writes component files to this directory. The system uses the
component files to build the three configuration files. Also contains a
back-up copy of webworks_config.xml.
UninstallerData Contains a subdirectory for each JDA Platform-based product that is

installed. Each subdirectory contains the product uninstall utility.
Access the JDA Platform Server

Users access JDA applications using one of the supported Web browsers. Browsers must enable
JavaScript and cookies. For instructions, see "Set browser properties" (on page 52).
Most JDA Web-enabled products have similar browser specifications; however, you should check the
"System requirements" section in the Installation/Administration Guide for your specific product.
Users who run a filtering tool to block pop-up windows do not see dialog boxes and toolbars in the
applications. This can cause navigation problems. These filtering tools are sometimes used to block
pop-up advertisements common on the Internet. Users should be instructed to apply filters carefully,
or remove filters if they experience problems.
1. Start the JDA Platform Server.
2. Open a Web browser window.
3. Type the address and port of the JDA Platform server into the address/location field of a Web
browser window in the following format:
http://<computername>:<portnumber>
Note: A colon (:) separates the <computername> and <portnumber>. For example, if the JDA
Platform Server name is jdasrv and the listen port is 7001, you would type:
http://jdasrv:7001
In some cases, the fully-qualified domain may be necessary depending on the network
configuration. Users must enter the fully-qualified URL when the sso_cookie_domain property is
set in the webworks_config.xml file. For example:
http://jdasrv.domain.com:7001
Contact your administrator if you do not know the name of your JDA Platform Server and its port.
4. In the JDA Log In page, enter the following:
your user name
your password
These entries are case sensitive.

Installation
5. Click Log in. The Welcome page is displayed. If the login fails, reenter the information. Contact the
JDA administrator if you do not have the correct user name and password information.
If you incorrectly enter the user name and password more than the maximum number of attempts
allowed, the system locks the account for a brief duration. If you get such an error message,
contact your JDA administrator for assistance.
Set browser properties

Users should configure their browsers to operate efficiently with JDA Platform. Configuration includes
enabling JavaScript and setting cache. Users who upgrade from an earlier version of JDA Platform
should clear their cache before accessing the server. The following instructions apply to the supported
versions of Internet Explorer.
Enable JavaScript in Internet Explorer

1. In Internet Explorer, select Tools > Internet Options.
2. Select the Security tab.
3. Highlight the Internet icon.
4. Click Custom Level.
5. Under Script, find the menu item Active scripting. Click Enable.
6. Click OK.
Enable cookies in Internet Explorer

1. Connect to the JDA Platform Server.
2. Select Tools > Internet Options.
3. On the Privacy tab, select a privacy setting or click Advanced. Note that a first-party site is the
one currently being viewed while a third-party site is a site not currently loaded.
4. Select OK.
Clear the cache in Internet Explorer

2. On the General tab, click Delete in the Browsing history area.
3. Click OK.
Set the cache in Internet Explorer

2. On the General tab, select Settings.
3. Select Automatically.
Disable Compatibility mode in Internet Explorer

1. Select Tools > Compatibility view Settings.
2. Deselect the Display intranet sites in Compatibility View checkbox.
3. Click Close.

Installation
Synchronize users between ABPP and Foundation User

Stores
If you have installed JDA ABPP-based applications with JDA Platform, you must synchronize the user
stores between the ABPP and Foundation schemas before users can log in. For example, if you have
installed JDA Sequencing, Factory Planner, Order Promiser, or Sales & Operations Planning with JDA
Platform, you must synchronize the users and ensure that all users have been assigned a role in the
JDA Foundation schema. When users have been synchronized, the User Manager UI ensures
synchronization of all new users and edits to existing users in both user stores.
If you have installed only JDA Collaborate or Market Manager, JDA Reporting, or JDA Supply Chain
Planning & Optimization without Sales & Operations Planning or Oder Promiser and no other
applications based on ABPP, you do not need to synchronize users, as only the Foundation user store
will be used.
Note: If using Sales & Operations Planning, see the JDA Supply Chain Planning & Optimization
Installation/Administration Guide for more information on synchronizing the user data for S&OP.
To synchronize users from between user stores, use the UserExport and UserImport utilities.
Export users
The userExport utility is used to export the users from the staging environment and these exported
users can be imported to the production environment. With the help of this utility, users can be
exported from the different product instances and also this utility will offer the flexibility to export the
users by applying to filters. Following is the procedure to export the user from an instance:
1. Ensure the CIS, SSO, and JDA Servers are started.
2. The userExportConfig.xml file is provided as a template for input to the export operation. In the
<install_dir>\config\bin\platform directory a default userExportConfig.xml file is provided for
exporting the users. You can copy, and then edit the file to customize your export. Following
examples will illustrate different use cases.
3. From the <install_dir>\config\bin\platform directory, run the following scripts:
On Windows:
userExport -credentials <credential file> -sourceLocation <exportConfigFile.xml> -
targetLocation <outputFile.xml>
On UNIX:
userExport.sh -credentials <credential file> -sourceLocation <exportConfigFile.xml>
-targetLocation <outputFile.xml>
For example:
userExport -credentials credentials.properties -sourceLocation
userExportConfigFdn.xml -targetLocation exportedusers.xml
4. Export the Users from the both the Stores: To export all users from both data stores, which is
recommended for initial synchronization, edit the export configuration file as follows:
<ProductInfo ExportPassword="true">

<ProductInstance InstanceName="ABPP"/>
<ProductInstance InstanceName="Foundation"/>


Installation
<Filter> <LoginName Value=""/>

<FirstName Value=""/>
<LastName Value=""/>
<Email Value=""/>
<Status Value="ALL"/>
</Filter> </ProductInfo>
With the above configuration file, users from the foundation and ABPP instances will be exported.
5. Export the users from one store with password: If you want to export users from one product
instance (for example: Foundation instance) and include the password, you should edit the export
configuration file as follows.

<Filter> <LoginName Value=""/> <FirstName Value=""/>
<LastName Value=""/> <Email Value=""/>
<Status Value="ALL"/> </Filter>
</ProductInfo>
6. Export Users by applying the filters: The users can be exported by applying the filters. The
filters can be applied on the LoginName, FirstName, LastName, Email and Status attributes. If no
filter is provided, all users will be exported from the user store.
For example, to export only the SuperUser from the Foundation user store and include the
password, you should edit the export configuration file as follows:
<Filter>
<LoginName Value="SuperUser"/>
<FirstName Value=""/>
<LastName Value=""/>
<Email Value=""/>
<Status Value="ALL"/>
</Filter> </ProductInfo>
Once exported, you can use this file to import into the ABPP user store.
Import users
The UserImport utility is used to synchronize users between the JDA Platform and ABPP data stores,
or to import users from other systems into the JDA user stores.

Installation
Notes:
You cannot change the user status from active to inactive or inactive to active using
UserImport utility.
If the operation mode is Update then irrespective of the value of the flag
UpdateIfAlreadyExist, it always updates the user.
1. Make sure the JDA Server is started.
2. Ensure that your import XML file contains the properties that you want to use to import the users.
If importing to the Foundation user store, ensure the following script is included in the
Instances section of the file:
<Instance InstanceName="Foundation" UpdateIfAlreadyExist="yes"
Operation="UPSERT"/>
If importing to the ABPP user store, make sure the following line is included in the Instances
section:
<Instance InstanceName="ABPP" UpdateIfAlreadyExist="yes" Operation="UPSERT"/>
If initially synchronizing the system, ensure that both the Foundation and ABPP instances are
specified in the Instances section of the file.
Make sure that required fields are assigned either for the individual users or in the
DefaultValues of the file. See the userImportConfig.xml file for examples of fields that can
be included.
Note: Versions of JDA Platform prior to 8.0 did not require that the email address field be
populated for users. If you are using the database for password authentication, you must reset
all user passwords after upgrading from versions earlier than 8.0. JDA provides a
resetPassword utility to automatically reset and notify users how to change their default
password, but users must have an email address in order for the utility to send a new
password link to them. In addition, if you do not have passwords for users that are
synchronizing from the Foundation schema to ABPP, you must update the import file to include
a valid email address.
3. From the <install_dir>\config\bin\platform directory, run the following script:
Windows
userImport -credentials <credentials> -sourceLocation <importFile> [-changeStatus
<ACTIVATE/DEACTIVATE>]
UNIX
userImport.sh -credentials <credentials> -sourceLocation <importFile>
[-changeStatus <ACTIVATE/DEACTIVATE>]
Argument 'changeStatus' is to activate and deactivate users present under 'importFile'
The following operations are available:
Create: Creates the user in the target instance if the user is not available.
Update: Updates the existing user if modified.
Upsert: Supports both create and update operation.

Installation
If Operation is equal to upsert and you do not want to update the existing user, the flag,
UpdateIfAlreadyExist is available. If this flag is set to true, it updates the existing users. If it is
false, only new users are created. These settings can be configured globally if you are importing
many users. If you are importing a single user, the attributes are set individually for the specific
user. If the UpdatePassword flag is set to true, every time the user is updated along with the
password. Otherwise, it uses the default value.
For example, if importing into the ABPP user store, the beginning of the file may look similar to
this:
<UsersData>
<ImportConfig UpdatePassword="false">
<Instances>
<Instance InstanceName="ABPP" UpdateIfAlreadyExist="no" Operation="UPSERT"/>
</Instances>
<DefaultValues>
<PRIMARY_ATTRIBUTES>
<PASSWORD Value=""/>
<LOCALE Value=""/>
<EMAIL_ADDRESS Value=""/>
<PHONE Value=""/>
<FAX Value=""/>
<COUNTRY Value=""/>
<STATE Value=""/>
<CITY Value=""/>
<POSTAL_CODE Value=""/>
<ADDRESS1 Value=""/>
</PRIMARY_ATTRIBUTES>
<ADDITIONAL_ATTRIBUTES InstanceName="ABPP">
<USR_GRP Value="SU_UGP"/>
<MANAGER_ID Value="USR_1"/>
<ABSENTEE_ID Value="USR_1"/>
<ORG_ID Value="_SU_ORG_"/>
</ADDITIONAL_ATTRIBUTES> </ImportConfig>
:
Note: The UpdateIfAlreadyExist operation works only when the action type value is UPSERT. For
example:
Instance InstanceName="Foundation" UpdateIfAlreadyExist="yes" Operation="UPSERT"/>
In the above scenario existing user is updated.

<Instance InstanceName="Foundation" UpdateIfAlreadyExist="no" Operation="UPSERT"/>

Installation
In the above scenario, existing user will be not updated as the UpdateIfAlreadyExist value is "no". If
you want to import the user password, then set the ImportConfig UpdatePassword property from
"false" to "true". If you want to provide default values for particular fields, then fill in those values in
the <DefaultValues> section. If you want to import only particular users, provide that information in
the  section of the file.
Note: If 'changeStatus' argument is present, the CREATE, UPDATE, and UPSERT operations present
under exported XML or userImportconfig.xml will be ignored and status for all users present under
XML file will be updated according to the value of argument. Also, only LOGIN_NAME tag of the
userImportconfig file will be consider. For example, the userImportConfig.xml file may look
similar to this:
<UsersData>
<Users>
<User>
<LOGIN_NAME Value="testuser1"/>
</User>
<User>
<LOGIN_NAME Value="testuser2"/>
</User>
</Users>
</UsersData>
Uninstall
Uninstall JDA Platform
You can uninstall JDA Platform after it has been installed; however, you should not uninstall the JDA
Platform if other JDA Platform-based applications are running on the server. You must remove those
applications first. The software provides an uninstall utility for each application. If the machine has
startNodePoolManager or startWebworksServer configured as Windows services, you should
remove them first. Instructions are provided in this section. Otherwise, you cannot remove the
services after uninstalling JDA Platform. You must remove DDU and IGP before uninstalling JDA
Platform.
Uninstall DDU and IGP before you uninstall JDA Platform

The Interface Generation Program (IGP) and the Data Division Utility (DDU) create database objects
that are unknown to the JDA Platform uninstall script. Therefore, before you uninstall JDA Platform,
you should run the SQL scripts that remove these objects from your database.
CAUTION: The JDA Platform uninstall script may remove the SQL scripts needed to clean up
your database, so you must run the DDU and IGP uninstall SQL scripts before you uninstall
JDA Platform.

Installation
Remove DDU database objects

Since the DDU SQL script, ddu.plb, creates only a results table called DDU_RESULTS and the DDU
stored procedure, the single uninstall_ddu.sql script is sufficient to remove all DDU database objects.
Following are the steps for removing DDU database objects:
1. Change to directory <install_dir>\config\database\platform.
2. Using SQL*Plus, run the script uninstall_ddu.sql as the owner of the Foundation schema. For
example:
sqlplus wwfmgr/wwfmgr @uninstall_ddu.sql
The DDU_RESULTS table and stored procedure are dropped from the database.
Remove IGP database objects

Several SQL scripts may be required to remove all IGP database objects. The scripts reside in the
directory from which the IGP was invoked; typically in the directory:
<install_dir>\config\bin\platform
Uninstall SQL scripts for IGP database objects take the following form:
uninstall_wcif.sql
and is the database object uninstaller created when you run the IGP command with no tablename
arguments. It will remove all interface tables, stored procedures, and triggers created for all tables
described by the applications XML configuration file.
However, if you run the IGP command with a tablename argument, it will generate a script that
creates interface tables, stored procedures and triggers for only the specified table, along with an
uninstall file for that table, taking the following form:
uninstall_<tablename>.sql
which can remove only database objects associated with the specified table.
Typically, you would run the IGP command against the application XML configuration file at least once,
so you can use uninstall_wcif.sql to remove all IGP database objects, including all uninstall scripts.
1. Navigate to the directory from which you invoked the IGP command.
2. Using SQL*Plus, run the script uninstall_wcif.sql. For example:
sqlplus wwfmgr/wwfmgr @uninstall_wcif.sql
All IGP database objects are dropped from the database.
Note: If you did not run the IGP command with no tablename arguments, but rather ran it against
individual table names, you will need to run all of the resulting uninstall_<tablename>.sql scripts.
Uninstall JDA Platform

After removing DDU and IGP, you can uninstall JDA Platform. If your installation was silent, then the
uninstallation is also silent and begins immediately.
1. Stop the JDA Platform Server.
2. If the JDA Platform instance has node pools configured as Windows services, you should remove
them first. Otherwise, you cannot remove the service after uninstalling JDA Platform.
a. Close Windows Services if it is open.

Installation
b. Navigate to directory <install_dir>\config\bin\platform.

c. If you have Windows services created for the Node Pool Manager, use the following syntax to
remove them:
startNodePoolManager -RemoveService <pool_name>
d. Repeat for each node pool service on the machine.

3. If you created a Windows service for the JDA Platform Server, you should remove the service first.
a. Close Windows Services, if it is open.

b. Navigate to directory <install_dir>\config\bin\platform
c. Use the following syntax to remove the service:
startWebworksServer RemoveService -RemoveCIS
4. Uninstall the JDADesktop<server-name> client version of the .NET UI Framework.
a. Open Start > Control Panel > Programs and Features.

b. Select the JDADesktop<server-name> from the list of installed programs and click Remove.
5. If you installed a link on the Windows Start menu, select Start > Apps > JDA 2016.1 >
Uninstall JDA Platform.
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\PlatformUninstall.
On Windows, execute the file UninstallPlatform.exe:
UninstallPlatform.exe
On UNIX, run UninstallPlatform.bin. For example:

UninstallPlatform.bin
6. On Windows, restart the machine.
7. Remove any directories or files not deleted during the uninstallation.
8. If you do not plan to reinstall JDA Platform, then you can remove the JDA Platform schemas. Use
Oracle utilities to remove the database.
9. If you installed JDA Platform as a Windows service, the uninstall does not remove the service. You
can remove the service in Windows Registry Editor. The path is HKEY_LOCAL_MACHINE >
SYSTEM > CurrentControlSet > Services > JDA-AdminServer-Service.
10. If reinstalling the JDA Platform on Windows, then remove the directory structure and install
cleanly. For example, if JDA Platform was installed at c:\JDA\JDAv2016_1, then remove
directory JDAv2016_1 before reinstalling. Otherwise, the server may not start correctly.
Uninstall JDA Platform SRE

You can uninstall JDA Platform SRE after it has been installed. You should first uninstall JDA application
thin installations.
1. Shut down any running node pools.
2. If the machine has node pools configured as Windows services, you should remove the services
first. Otherwise, you cannot remove the service after uninstalling JDA Platform SRE.
a. Close Windows Services if it is open.

b. Change to directory <install_dir>\config\ bin\platform.
c. Use the following syntax:

Installation
d. Repeat for each node pool service on the machine.

3. If you installed a link on the Windows Start menu, select Start > Apps > JDA 2016.1 >
Uninstall JDA Platform.
If you did not install the software to the Windows Start menu, open a command-line prompt.
Change to directory <install_dir>\UninstallerData\PlatformSREUninstall and enter the
following:
UninstallPlatform_SRE.exe
4. On Windows, reboot the machine.
5. Remove directories or files not deleted during the uninstallation.
6. If reinstalling the JDA Platform SRE on Windows, remove the directory structure and install cleanly.
For example, if JDA Platform was installed at c:\jda\jda_SRE, then remove directory jda_SRE
before reinstalling. Otherwise, the software may not function correctly.
Remove Windows services

To manually remove the Windows services from Platform, perform the following steps:
1. Open a command line prompt as an administrator.
2. Run the following commands:

sc delete JDA_CIS_2016.1_Agent_<CIS Agent Port>
sc delete JDA_CIS_2016.1_SSOServer_<CIS Agent Port>
sc delete JDA-AdminServer-<Environment Name>
sc delete JDA-JDAServer-<Environment Name>

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 environment on UNIX
Configure database
Configure JDA Platform Server
Configure a cluster
Start JDA Platform Servers
Start Node pool manager
Synch users between ABPP and CSM User Stores
Configure the environment on UNIX

To connect to the database server, you require the following environment variables. If the following
variables are not set, you may be unable to access the database server to run the database scripts.
ORACLE_HOME=<path to Oracle install>
SID=<Oracle SID name>
TNS_ADMIN=<path to tnsnames.ora> May be useful if running database scripts from the

applications server against a remote database server.
LD_LIBRARY_PATH=<paths to Oracle shared libraries on Solaris or Linux>
LIBPATH=<path to Oracle shared libraries on AIX>
For convenience, you may set the following variables:
WEBWORKS_HOME=<path to Foundation installdir>
WAS_HOME=<path to Websphere dir>
For example, the .profile entries might look like the following:
export WEBWORKS_HOME=/u01/apps/jda/jdav2016_1
export ORACLE_HOME=/u/oracle/12.1.0.2
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export ORACLE_SID=NWSAMPLE
Install additional JDA applications

You can install additional JDA applications that are supported with this version of JDA Platform. After
installation of additional products, you must update the server configuration to recognize the new
applications using the configureJDAServer utility. See Configure JDA Platform Server (on page 96) for
information on how to run this utility.

Reset user passwords after migration

1. To generate a credentials file with the username and encrypted password for a user, run the
genCredentials.cmd file through command prompt from the <install_dir>\config\bin\platform
directory. You can use the following syntax:
genCredentials <credentials_file_name>
<credentials_file_name> is the credentials file name. When you run the script, the system
prompts you to enter a user name and password. Enter the operators current username and
password:
Enter the User ID: <Operator user name>
Enter the password to encrypt: <Operator password>
Enter the password again for confirmation: <Operator password>
2. To rest the password, run the resetUsersPassword utility through command prompt from the
<install_dir>\config\bin\platform directory.
resetUsersPassword -credentials <credentials> [-sourceLocation
configFileLocation]
Note: If the location of the configuration file is not specified, the resetUsersPassword utility will
reset all passwords in the system.
Option Description
-credentials The name of the credentials file containing the user name and encrypted
<credentials> password combination for the user who is authorized to run this utility. The
user must have create privileges in its Enterprise to create users.
-sourceLocation Optional configuration file that can be used to specify the set of users for the
<configFileLocation> reset password utility to operate on. There can be multiple UserName
entries specified in this file. If not specified, the utility will reset all user
passwords.
Modify the resetUsersPasswordConfig.xml file with the user details. This
file is located in the <install_dir>\config\bin\platform directory. Use the
following format while updating the resetUsersPasswordConfig.xml file:
<Users>
<UserName Value="USER 1"/>
</Users>
In this example, USER 1, USER 2 and USER 3 are the usernames for the
users whose passwords you want to reset. Any number of users can be listed
within the <Users> tag. Use the following syntax to run the
resetUsersPassword utility:
resetUsersPassword -credentials <credentials> -sourceLocation

resetUsersPasswordConfig.xml
The resetUsersPassword utility provides the capability to generate passwords for all users after
upgrading from an earlier version to version 8.0 or later. In version 8.0, user password encryption
has been upgraded to a more secure encryption algorithm. As a result, all user passwords must be
re-generated.

While generating the password, the utility does the following:
Resets the password to the new generated password for all associated product to which the
user is associated.
Mails the generated password to the registered email address of the user. Ensure that all users
have an email address in the CSM_USER or USER_PROFILE table before using this utility.
Changes the password expiration date to the current date to allow the user to login with the
new password and prompts the user to change the password.
Change permissions on WebSphere installation directories

This section applies only to UNIX installations that are using the WebSphere application server. After
installing JDA Platform and JDA Platform-based applications on UNIX, you must change permissions on
selected files and folders. Granting permissions is necessary when the user that installed or owns
WebSphere is different from the user that installed JDA Platform and JDA applications. You should
install all JDA Platform-based applications before you proceed.
If the user who owns IBM WebSphere is different from the user who owns or installs JDA Platform, the
user who owns JDA Platform must have full access to the $WAS_HOME/profiles/$profile directory
and its sub-directories. For example, if WebSphere is installed by root user and JDA Platform and JDA
applications are installed by user jdamgr on the Websphere profile default, then jdamgr user must
have full access to $WAS_HOME\profiles\default directory.
Set environment variables for internationalization

JDA Platform supports internationalization. This section contains information on setting additional
environment variables that may be useful for an international environment. For example, in some
cases, the database may contain special or double-byte characters common in an international
environment.
When installing the application server and JDA Platform on Windows, the directory names must use
simple ASCII characters (A-Za-z), and not use any accented or double-byte characters. For example, if
the directory names use special characters in Latin1 encoding, then JDA Platform components fail to
function.
Note: When creating an Oracle database, you must use character set AL32UTF8. This universal
database character set can support all supported languages, as well as both single- and double-byte
languages in a single instance. JDA provides scripts to assist you in creating the appropriate instance.
See the section Create an Oracle instance and user for JDA Platform.
To properly handle extended characters, you must set additional environment variables before starting
the JDA Platform Server. The system locale refers to the country and language. The locale must be
installed with your operating system, so they vary by operating system. The variables may differ
among various UNIX operating systems, so check documentation for your vendor. To see the locales
that are installed on a UNIX machine, enter the following:
locale -a
When you have extended characters in your database, you must use a compatible UTF-8 based locale
in the WebLogic server environment on UNIX. Otherwise, the server retrieves and converts the data
incorrectly. For example, if a Japanese database uses a AL32UTF8 character set and the UNIX server
locale is based on SJIS, the server will convert data from the database improperly. To resolve this, set
the server locale to a UTF8-based locale (for example, ja_JP.UTF8).
Set the following variables on UNIX, using the export command, before you start the JDA Platform
Server.

Setting operating system variables on UNIX
Variable Example
LANG Use to specify the locale. The locale must be supported on the UNIX platform. For
example, for English for the United States, type:
export LANG=en_US.ISO8859-1
For UTF-8 encoding:

export LANG=en_US.UTF-8
For Spanish:
export LANG=es_ES.ISO8859-1
Note: The LC_ALL variable sets LANG.
LC_CTYPE The variable LC_CTYPE must be exported on UNIX to the native locale to read
command-line messages in batch. Using a UTF8 locale may result in corrupted
messages.
For Traditional Chinese:
export LC_ALL=zh_TW.BIG5
Note: The LC_ALL variable sets LC_CTYPE.
LC_ALL The UNIX variable LC_ALL sets the variables above.
NLS_LANG Use to specify the type of data being imported/exported, display

messages, and set date and number formats. Examples are:
AMERICAN_AMERICA.WE8ISO8859P1
AMERICAN_AMERICA.AL32UTF8
JAPANESE_JAPAN.JA16SJIS
If migrating a database from version 7.1 or earlier, you must correctly set the
NLS_LANG variable. For more information on this process, see "Notes on
migrating a database for a new character set" (on page 93).
Set the sort parameter

Set the Oracle initialization parameter NLS_SORT in the init<SID>.ora file to the appropriate
language. This parameter ensures proper character sorting based on the language being used. Stop
and restart the Oracle instance after changing the init<SID>.ora.
NLS_SORT = <BINARY or language>
Binary sets the order to binary sort while specifying the language sets it to the linguistic sort in that
particular language.
For example, to set it to Binary, use the following:
NLS_SORT = Binary
For example, to set it to French, use the following:
NLS_SORT = French
If the database contains multiple Western languages, use the following:
NLS_SORT = WEST_EUROPEAN

For a list of valid values, run the following query:
Select * from v$nls_valid_values where parameter LIKE'%SORT%';
Configure database
If you are creating a new, empty JDA schema, following the instructions to create the required
database users and the database objects for those users.
If you are migrating a database from a prior version, import the database into your Oracle database
and follow the instructions to migrate the database. Depending on which version you are updating
from, you may need to create additional database users when migrating from an earlier version.
In documentation examples, wwfmgr is the Oracle user that owns the Foundation schema,
JDA_SYSTEM owns the JDA System schema, and ABPPMGR owns the ABPP schema. If you are using
the Interface Generation Program (IGP), igpmgr owns the IGP schema. Your schema names can be
different.
Before creating or migrating databases, you must have a strong knowledge of Oracle and SQL*Plus.
Consider having an Oracle DBA participate in the activities. For additional details, consult your Oracle
documentation.
Create database users

Follow the instructions in this section if you have an Oracle instance (SID) and tablespace created and
you want to create users for the JDA Platform schemas. JDA provides scripts to assist you. You can use
the scripts if you are migrating or creating a new database. Alternatively, you can automatically create
the database users as part of the JDA Platform installation.
For products based on JDA Platform, the JDA Platform and JDA applications schemas must be owned
by different Oracle users with unique default tablespaces. For products based on JDA ABPP, the
application schema is added to the ABPP schema. If using the Interface Generation Program (IGP), JDA
recommends using a separate schema (typically IGPMGR).
Create JDA Platform database users

JDA provides scripts to create your database users with the required permissions. The user name
should match entries made during the JDA Platform installation. You must know the password for the
Oracle system user before running the script, which prompts for the user password to be assigned.
Alternatively, you can have the JDA Platform installation create the database users at the end of the
installation
To create all of the JDA Platform users (JDA_SYSTEM, Foundation, and ABPP):
1. Run the runPostInstallTask script through command prompt in the ..\config\bin\platform

directory.
2. When prompted, enter the Oracle System password. This value will not be stored to the file
system.
3. When prompted, enter the password you want to assign to the JDA_SYSTEM user (this user will be
created by the script)
4. When prompted, enter the password for the JDA Foundation schema owner. This should match the
value entered during the installation.
5. When prompted, enter the password for the JDA ABPP schema owner. This should match the value
you entered during the installation.
6. If you installed Monitor, when prompted, enter the password for the JDA Monitor schema owner.
This should match the value you entered during the installation.

7. When prompted for a task, enter create_users and press enter.
Notes:
When you run the post installation script, system also prompts for the create Platform
database option. Enter create_platform_database, if you want to create the JDA Platform
schema objects. For more information, see "Create the Platform schema objects" (on page
66).
When you run the post installation script, it also invokes the Platform database patch scripts
automatically and upgrades the Platform database to the latest database patch level. If the
post installation task is completed successfully, do not run the standalone database patch
scripts.
The system creates the users and assigns the specified passwords to the users. Review the file
platform_db_creation.log in the same directory for errors.
Alternatively, individual SQL scripts are available in the ..\config\database\setup directory to

create the individual database users. If you are running the scripts individually, ensure that you have
the following environment variables set:
PATH: Includes the full path to the \bin directory for the correct version of Oracle. The bin
directory for the supported Oracle version must be before the bin directory for any other version of
Oracle on the computer. For more information on the supported version, see System requirements
(on page 11).
ORACLE_SID: The database instance on the server. If you have multiple instances, set the
ORACLE_SID to the correct instance.
The following scripts can be executed to create the various database users:
cr_fdn_user.sql
cr_abpp_user.sql
create_jda_system.sql
cr_ema_user.sql
Each script prompts for the user password as a variable in the script and logs to the
platform_db_creation.log in the current directory.
Create the Platform schema objects

Follow the directions in this section to create a new Foundation and ABPP schema objects. Before
proceeding, you must have an Oracle instance (SID), user, and tablespace. If you created the
database schema objects using the post-install tasks as part of the installation, then you can skip this
section.
You must create the required database tables, indexes, keys, and other objects. The Foundation
schema includes tables for Security, metadata, service runtime environment, user preference, and
other tables. Create the Foundation schema before creating other JDA applications schemas. The
Foundation schema creation also includes predefined JDA Platform resources, roles, and user accounts.
Starting with release 7.8, ManugisticsPkg is no longer housed in the System schema, and is moved
to the JDA System schema. The JDA System schema should be created before you create a new
schema or before you migrate an existing schema from a version earlier than 7.8 to version 2016.1.
The specific name of the JDA System schema owner is specified during installation (the default is
JDA_SYSTEM). JDA provides the script create_jda_system.sql to create the schema, based on the
JDA System username that you entered during installation.

By default, the JDA System user is granted only the specific permissions that are needed in order to
support ManugisticsPkg in order to run the JDA applications. By default, the JDA System user does
not have sufficient permissions to run all JDA SQL scripts, especially those that grant permissions to
other users or tables (for example, enroll_app_schema.sql or enroll_igp_schema.sql). Many of
the instructions on migration or database setup direct users to use the System user to run scripts. You
will need to use the Oracle System user to run enroll_app_schema.sql and related scripts.
For additional variables to support special characters, see "Set environment variables for
internationalization" (on page 63).
Prerequisites:
The following users should be created in the Oracle database:
JDA Platform user (by default WWFMGR)
The ABPP user (by default ABPPMGR)
The JDA System user (by default JDA_SYSTEM)
The JDA Monitor user, if different from the JDA Platform user
Make sure that the Oracle bin directory is in your PATH environment variable.
If running scripts individually using SQL*Plus, make sure that the ORACLE_SID is set correctly or
that you append the password with the TNS name for the database (for example, sqlplus
wwfmgr/wwfmgr @NWsample
If the above users are not created, see the section Create database users (on page 65).
To create the JDA Platform schema objects:
1. Run the runPostInstallTask script from the <install_dir>\config\bin\platform directory.
2. When prompted, enter the Oracle System password. This value will not be stored to the file
system.
3. When prompted, enter the password for the JDA_SYSTEM user
4. When prompted, enter the password for the JDA Foundation schema owner.
5. When prompted, enter the password for the JDA ABPP schema owner.
6. If you installed Monitor, when prompted, enter the password for the JDA Monitor schema owner.
7. When prompted for a task, enter create_platform_database and press enter.
Notes:
When you run the post installation script, system also prompts for the create users option.
Enter create _users, if you want to create the JDA Platform users. For more information, see
"Create JDA Platform database users" (on page 65).
When you run the post installation script, it also invokes the Platform database patch scripts
automatically and upgrades the Platform database to the latest database patch level. If the
post installation task is completed successfully, do not run the standalone database patch
scripts.
The system will create the database objects for all of the JDA Platform users and grant the
required permissions to the users. Review the file platform_db_creation.log in the same
directory for errors.

Alternatively, you can run the following scripts in the order specified using SQL*Plus:
Step Script Run as schema owner Description

1. ManugisticsPkg.sql In directory <install_dir>\config\database\platform,
jda_system run this script as the jda_system user.
This package expects an argument which is Foundation
Schema Name.
The script is an unwrapped package that provides automatic
features necessary for the service runtime environment.
The script creates one table in the jda_system schema.
For example:
sqlplus jda_system/jda_system @ManugisticsPkg.sql wwfmgr
2. create_webworks_schema.s In directory <install_dir>\config\database\platform,
ql run this script as the Foundation schema owner. For
Foundation (wwfmgr) example:
sqlplus wwfmgr/wwfmgr @create_webworks_schema.sql
Review the file create_webworks_schema.log for errors.
Verify the schema creation by running the following query
as the Foundation schema owner:
SELECT VALUE FROM csm_schema_log WHERE
name=DATABASE_VERSION;
The value should return the value 2016.1.0.x.
3. grants_jda_system.sql In <install_dir>\config\database\setup, run this script

as the system user to grant and assign the required
system privileges to the jda_system user for the system objects in
the database:
sqlplus system/manager @grants_jda_system.sql
4. createAbppSchema In directory <install_dir>\config\database\platform,
(Windows) review the file createAbppSchema.log for errors.
or
createAbppSchema.sh (UNIX)
5. import_translated_metadata In directory <install_dir>\config\database\platform,
run this batch (Windows) or shell (UNIX) script as the
Foundation database user. Specify the Oracle TNS name
(SID) for your database. For example:
UNIX: import_translated_metadata.sh wwfmgr wwfmgr
nwsample
Windows: import_translated_metadata.bat wwfmgr
wwfmgr nwsample
This script loads metadata logical data types in the
Foundation schema.
If Monitor is also installed, create the Monitor schema using the steps below


6. ema_create_database.sql In directory
JDA Monitor (emamgr) or <install_dir>\config\database\monitor\scripts, run
Foundation (wwfmgr) this script.
For example:
sqlplus emamgr/emamgr @ema_create_database.sql
JDA Monitor database tables have an EMA_ prefix to
distinguish them from other tables in the schema.
7. enroll_app_schema.sql Change to <install_dir>\config\database\platform
system (only required if not Only required if creating the Monitor tables in a schema
creating the Monitor objects in other than the Foundation schema. This script grants
the Foundation schema) privileges to the Foundation schema owner.
For example:
sqlplus system/manager @enroll_app_schema.sql EMAMGR
8. ema_populate_wwf.sql In <install_dir>\config\database\monitor\scripts, run

Foundation (wwfmgr) this script to populate the Foundation database schema with
JDA Monitor metadata.
For example:
sqlplus wwfmgr/wwfmgr @ema_populate_wwf.sql
9. Application scripts Follow the instructions from the applications that use
Monitor user (emamgr or Monitor to run application scripts in the
wwfmgr) <install_dir>\config\database\monitor\scripts\appscr
ipts directory
The database initialization creates a system administrator account called System that has a default
password of password. Use this user name and password to log in to the application the first time.
You should change the password for this account after logging in the first time.
IMPORTANT: Do not delete the System user.
Upgrade the Foundation schema

This section describes the high-level steps necessary to upgrade to Foundation version 2016.1.0.x.
Check the documentation for the JDA applications you plan to use for information on how to migrate
application schemas with the Foundation schema.
1. Back up the Foundation schema and all JDA application schemas. If you are migrating from a pre-
7.2 database, see "Notes on migrating a database for a new character set" (on page 93).
2. Ensure that you have the supported version of Oracle installed and that the JDA schemas are
imported into an Oracle instance that is created at the supported version.
3. Migrate the Foundation schema using the instructions in Migrate the Foundation schema.
Follow the steps in this section if you are upgrading Foundation. You can upgrade to version
2016.1.0.x from earlier versions. The migration preserves user information, which includes the
Security Manager, user preferences, and other tables.
IMPORTANT: Migrate the JDA Foundation schema before migrating additional JDA application schemas.
In documentation examples, wwfmgr owns the Foundation schema. Your schema name may be
different.

Starting with release 7.8, ManugisticsPkg is no longer housed in the System schema, and is moved
to the JDA System schema. The JDA System schema should be created before you migrate an existing
schema to version 2016.1. The specific name of the JDA System schema owner is specified during
installation (the default is JDA_SYSTEM). JDA provides the script create_jda_system.sql to create
the user, based on the JDA System username that you entered during installation.
By default, the JDA System user is granted only the specific permissions that are needed in order to
support ManugisticsPkg in order to run the JDA applications. By default, the JDA System user does
not have sufficient permissions to run all JDA SQL scripts, especially those that grant permissions to
other users or tables (for example, enroll_app_schema.sql or enroll_igp_schema.sql). Many of
the instructions on migration or database setup direct users to use the System user to run scripts. You
will need to use the Oracle System user to run enroll_app_schema.sql and related scripts.
Gather database statistics

JDA provides a generic script to gather schema-level Oracle statistics during and following database
migration. However, some JDA application database tables will benefit from locking of statistics,
deletion of column statistics, or additional gathering of statistics at various points during processing.
In general, it is best to run with stable and reliable statistics as opposed to new, frequently updated, or
unknown statistics. Statistics will need to be refreshed if there are major changes in data volume. For
volatile tables (typically JDA process tables), statistics must typically be gathered at the high volume
mark. An experienced DBA should monitor the database and evaluate any required updates to the
database statistics to optimize performance.
Migrate the Foundation schema on Oracle

Follow these instructions to migrate the Foundation Schema to 2016.1. Migrate the Foundation schema
to version 2016.1 before migrating other JDA schemas. The migration must be accomplished in
sequence; do not skip steps. If you have modified the Foundation schema, then the migration may fail.
Begin the migration based on your current Foundation schema version level.
"Migrate Foundation schema from 7.1 to 7.1.1 on Oracle" (on page 71)
"Migrate Foundation schema from 7.1.1 to 7.2 on Oracle" (on page 71)
"Migrate Foundation schema from 7.2 to 7.2.1 on Oracle" (on page 75)
"Migrate Foundation schema from 7.2.1 to 7.2.1.1 on Oracle" (on page 78)
"Migrate Foundation schema from 7.2.1.1 to 7.2.2 on Oracle" (on page 81)
"Migrate Foundation schema from 7.2.2 or 7.2.3 to 7.3 on Oracle" (on page 80)
"Migrate Foundation schema from 7.3 to 7.3.0.1 on Oracle" (on page 81)
"Migrate Foundation schema from 7.3.0.1 to 7.4 on Oracle" (on page 83)
Migrate Foundation schema from 7.4 to 7.4.1 on Oracle (on page 85)
Migrate Foundation schema from 7.4.1 to 7.4.2 on Oracle (on page 87)
Migrate Foundation schema from 7.4.2 or higher to 2016.1 (on page 88)
If you are not sure what version the Foundation schema is, query the csm_schema_log table for the
current version using the following query:
SELECT VALUE FROM csm_schema_log WHERE name= 'DATABASE_VERSION'

Migrate the JDA Monitor schema

To migrate the JDA Monitor schema from a previous version to version 2016.1, perform the migration
for each version in sequence. Do not skip a version. Make sure that you migrate the JDA Platform
schema to the same version prior to migrating the JDA Monitor schema for that version.
For example, to migrate from version 7.1 to 7.2.1, you must first migrate the Foundation schema to
version 7.2, then migrate the Monitor schema to 7.2 and then migrating Foundation and Monitor
schema to version 7.2.1, in that order.
Migrate Foundation schema from 7.1 to 7.1.1 on Oracle

1. Back up the database.
2. Open a command-line prompt.
3. Using SQL*Plus, verify the Foundation schema by entering the following query:
SELECT VALUE FROM csm_schema_log WHERE name='DATABASE_VERSION';
The query should return 7.1 as the VALUE.
5. Using SQL*Plus, run the script migrate_webworks_71_to_711.sql as the owner of the Foundation
schema. For example:
sqlplus wwfmgr/wwfmgr @<NetServiceName> @migrate_webworks_71_to_711.sql
6. Verify the database migration to 7.1.1. Enter the following SQL query:
The query can return more than one row. Look for the following:
migrate_webworks_71_to_711.sql
7.1.1
7. Continue with "Migrate Foundation schema from 7.1.1 to 7.2 on Oracle".
Migrate Foundation schema from 7.1.1 to 7.2 on Oracle

Before proceeding with this section, you must know the password for the Oracle system user. Back up
your database before migration.
1. Run the following scripts in the specified order using SQL*Plus.

Step Script Description

Run as schema owner
1 verify_webworks_711_d In directory <install_dir>\config\database\platform, run this
atabase.sql script as the Foundation schema owner. The script verifies that
Foundation (wwfmgr) the schema can be migrated to version 7.2.
sqlplus wwfmgr/wwfmgr
@verify_webworks_711_database.sql
If the database is on a remote server, then specify the Oracle
Net Service Name after an @ sign.
sqlplus wwfmgr/wwfmgr @<NetServiceName>
@verify_webworks_711_database.sql
Examine the console or log file for any errors. Correct any errors.
You may be told to run script drop_FE_table.sql to drop
Flexible Editor tables from the Foundation schema. After running
drop_FE_table.sql, re-run
verify_webworks_711_database.sql.
The verify_webworks_711_database.sql script identifies
database object names that are longer than 30 characters. You
must correct the names before proceeding with the migration. If
you installed JDA Transport, run the script
<install_dir>\config\JDADomain\database\PreMigrateTran
sportCSM721.sql before proceeding to modify column names
that exceed 30 characters. Run this script as the Foundation
schema owner. For example:
sqlplus wwfmgr/wwfmgr @PreMigrateTransportCSM721.sql
2 migrate_webworks711_t In directory <install_dir>\config\database\platform, run this
o_72.sql script as the Foundation schema owner. For example:
Foundation (wwfmgr) sqlplus wwfmgr/wwfmgr @migrate_webworks711_to_72.sql
Review migrate_webworks711_to_72.log for errors.
3 reset_wwf_privileges.sql In directory <install_dir>\config\database\platform\util,

system run this script to revoke the dba privilege from the Foundation
schema owner. The script also grants the necessary privileges to
the Foundation schema owner. Run this script as the Oracle
system user. For example:
sqlplus system/manager @reset_wwf_privileges.sql
2. Verify the database migration to 7.2. Type the following SQL query:
3. Continue with "Migrate Foundation schema from 7.2 to 7.2.1 on Oracle" (on page 75).
Migrate Monitor schema 7.1 to 7.2 on Oracle

Notes:
Migrate the Foundation schema to 7.2 before migrating Monitor schema to 7.2. For detailed
instruction, see JDA Platform Installation/Administration Guide.

Because of extensive enhancements, data comparison rules are not migrated. Redefine all data
comparison rules after migration.
In Monitor schema version 7.2, the number of notification template formats has been reduced
from five to two: (high) HTML and (high) Text. The migration script will update rules using the
former High HTML and High Text with the appropriate new template file. If the implementation
uses template files other than the new (high) HTML or (high) Text templates, copy the
template files from the 7.1 template directory to the 7.2 template directory. For more
information about e-mail templates, see "Configure the server" (on page 230).
1. Make notes of the previously-defined data comparison rules to enable re-creation of the rules after
migration.
2. Back up the database. Also note the value of the URL column for Monitor in the CSM_APPLICATION
table.

1 grant_ema_priv_to_wwf.sql Change to
Monitor (emamgr) <install_dir>\config\database\monitor\migration\v
71to72.
Run this script to grant all privileges on EMA objects to
Foundation user. The script prompts for the name of the
Foundation schema owner.
For example:
sqlplus emamgr/emamgr @grant_ema_priv_to_wwf.sql
If the database is on another server, use the at sign (@)
followed by the Oracle Net Service Name following the
user name/password.
For example:
sqlplus emamgr/emamgr@<Monitor_NetServiceName>
@grant_ema_priv_to_wwf.sql <wwfmgr>
2 ema_database_synonyms.sql Change to
Foundation (wwfmgr) <install_dir>\config\database\monitor\migration\v
71to72.
If the Foundation and Monitor schemas are located in the
same schema, then skip this step. If the Foundation and
Monitor schemas are located in different schemas, run
this script to create EMA synonyms in the Foundation
schema.
For example:
sqlplus wwfmgr/wwfmgr @ema_database_synonyms.sql
emamgr emamgr
where emamgr is the Oracle user and password for the
EMA schema owner.


3 verify_monitor_database.sql Change to
Foundation (wwfmgr) <install_dir>\config\database\monitor\migration\v
71to72.
Run this script to verify the current version of the JDA
Monitor database.
For example:
sqlplus wwfmgr/wwfmgr @verify_monitor_database.sql
The response should indicate an incorrect version,
perform the necessary tasks before continuing.
4 migrate_wwf_data_owned_by_ Remain in
ema.sql <install_dir>\config\database\monitor\migration\v
Foundation (wwfmgr) 71to72.
Run this script to migrate the Monitor data in the
Foundation schema from version 7.1 to 7.2.
For example:
@migrate_wwf_data_owned_by_ema.sql
5 migrate_monitor_71_to_72.sql Remain in
71to72.
Run this script to migrate the Monitor data in the Monitor
schema from version 7.1 to 7.2.
For example:
sqlplus emamgr/emamgr @migrate_monitor_71_to_72.sql
6 enroll_app_schema.sql Change to <install_dir>\config\database\platform.
system Run this script to grant privileges to the EMA schema
owner. The script prompts for the name of the EMA
schema owner.
For example:
sqlplus system/manager @enroll_app_schema.sql
5. In the previous version, the URL column in the Foundation schema table CSM_APPLICATION
required an absolute path. In versions 7.2 or later, the URL column uses a relative path. When the
application is started, the relative path is appended to the application URL prefix specified by the
value applicationUrlPrefix in the file <install_dir>\config\properties\monitor_config.xml.
Verify that the value of the applicationUrlPrefix is correct. The value of the applicationUrlPrefix
plus the value of the CSM_APPLICATION.URL column should be the same as the value noted in
Step 2.
After migrating the database, migrate the business rules.
Migrate business rules

Perform the steps in this section after creating the Monitor schema and after migrating the Monitor
database to version 7.2. This migration process uses XSL files to read and convert XML data in the
EMA_BUSINESS_RULE table. Use the batch command NWMigrateBusinessRule.cmd (Windows) or shell
script NWMigrateBusinessRule (UNIX).
1. Back up the Monitor database table EMA_BUSINESS_RULE.

2. Change to directory <install_dir>\config\database\monitor\migration\v71to72.
3. Using a text editor, open NWMigrateBusinessRule_config.xml. Review the settings in this file.
Property Description Default
Tracing/Logging Settings
traceFileDirectory The path to the trace file directory. Current directory.

Use forward slashes for Windows and
UNIX.
traceFileName The file name of the trace file. NWMigrateBusinessRule.log
traceLevel The amount of trace information in the verbose

trace file:
off - No trace information
terse - Minimal trace
information
verbose - All information
Migration Settings
migrationDirectory The full path to the directory <install_dir>/config/database/mo

containing the XSLT file used to nitor/migration/v71to72/xmlscri
migrate business rules. pts
4. Save and exit NWMigrateBusinessRule_config.xml.
Run the migration process by opening a command-line prompt. Enter:

NWMigrateBusinessRule
Notes:
After migrating the business rules, be sure to redefine all data comparison business rules. If
the rules use templates other than HTML (high) or Text (high), copy those templates from the
previous version of JDA Monitor.
Because of the extensive changes made to the JDA Monitor Database Comparison rule for
Monitor version 7.2, previously existing data comparison rules are not migrated. When
migrating to Monitor 7.2, all data comparison rules must be redefined.

3. Using SQL*Plus, run the script migrate_webworks_72_to_721.sql as the owner of the

Foundation schema. For example:
sqlplus wwfmgr/wwfmgr @migrate_webworks_72_to_721.sql
Review migrate_webworks_72_to_721.log for errors.

4. Verify the database migration to 7.2.1. Enter the following SQL query:
The query should return 7.2.1 as the VALUE.
5. Continue with "Migrate Foundation schema from 7.2.1 to 7.2.1.1 on Oracle".
Migrate Monitor schema 7.2 to 7.2.1 on Oracle


Monitor (emamgr) <install_dir>\config\database\monitor\migration\
v72to721.
For example:
If the database is on another server, use the at sign
(@) followed by the Oracle Net Service Name following
the user name/password.
For example:
2 verify_monitor_database.sql Verify the following before migration:
Foundation (wwfmgr) 1. Foundation schema must be v7.2.1 or v7.2.1.1.
2. JDA Monitor schema must be v7.2.
Change to
<install_dir>\config\database\monitor\migration\
v72to721.
Monitor database.
For example:
If the response indicates an incorrect version, perform
the necessary tasks before continuing.
3 migrate_wwf_data_owned_by_ Remain in
ema.sql <install_dir>\config\database\monitor\migration\
Foundation (wwfmgr) v72to721.
Run this script to migrate the Monitor data within the
Foundation schema from version 7.2 to 7.2.1.
For example:
@migrate_wwf_data_owned_by_ema.sql


4 migrate_monitor_72_to_721.sql Remain in
Monitor (emamgr) <install_dir>\config\database\monitor\migration\
v72to721.
Run this script to migrate the Monitor data in the
Monitor schema from version 7.2 to 7.2.1.
For example:
5 enroll_app_schema.sql Change to <install_dir>\config\database\platform.
system Run this script to grant privileges to the EMA schema
owner. The script prompts for the name of the EMA
schema owner.
For example:
sqlplus system/manager @enroll_app_schema.sql
After migrating the database, migrate the business rules.
Migrate business rules to version 7.2.1

database to version 7.2.1. This migration process uses XSL files to read and convert XML data in the
1. Back up the JDA Monitor database table EMA_BUSINESS_RULE.

2. Change to <install_dir>\config\database\monitor\migration\v72to721.
3. Using a text editor, open NWMigrateBusinessRule_config.xml. Review the settings in this file.

Use forward slashes for Windows and
UNIX.
traceLevel The amount of trace information in the verbose

trace file:
terse - Minimal trace information
Migration Settings
migrationDirectory The full path to the directory containing <install_dir>/config/database/mo

the XSL file used to migrate business nitor/migration/v72to721/xmlsc
rules. ripts
Note: If the database settings specified during installation (including the SID, port, host, and
user/password) must be changed, edit the following files:
<install_dir>\config\properties\dbconnections.properties
<install_dir>\config\JDADomain\config.xml

5. Open a command-line prompt to run the migration process. Enter:

NWMigrateBusinessRule
6. After migrating the business rules, reconfigure the notification e-mail templates.
Reconfigure e-mail templates

Perform these steps after migrating the Monitor business rules to version 7.2.1. In Monitor 7.2.1, the
translatable, fixed-content of e-mail templates is replaced by resource lookup tags. This allows the
content of templates to be retrieved from language-specific application resource files. Language-
specific e-mail template files are no longer required or supported.
To reconfigure the e-mail template files, update the e-mail templates and copy them to the
appropriate directories. For more information, see "Change e-mail templates" (on page 230).
Migrate Foundation schema from 7.2.1 to 7.2.1.1 on Oracle

The query should return 7.2.1 as the VALUE.
2. Run the following script using SQL*Plus.

1 migrate_webworks_721_to_7211.sql In directory
Foundation (wwfmgr) <install_dir>\config\database\platform, run
this script as the Foundation schema owner. For
example:
@migrate_webworks_721_to_7211.sql
Review migrate_webworks_721_to_7211.log
for errors.
3. Verify the database migration to 7.2.1.1. Enter the following SQL query:
The query should return 7.2.1.1 as the VALUE.
4. Continue with "Migrate Foundation schema from 7.2.1.1 to 7.2.2 on Oracle".
Migrate Foundation schema from 7.2.1.1 to 7.2.2 on Oracle

2. Run the following SQL scripts, in the specified order:


Foundation (wwfmgr) <install_dir>\config\database\platform, run
this script as the Foundation schema owner. For
example:
Review migrate_webworks_7211_to_722.log
for errors.
3. Verify the database migration to 7.2.2. Type the following SQL query:
4. Continue with "Migrate Foundation schema from 7.2.2 to 7.3. on Oracle".
Note: While running the migration script, if the following errors display, ignore them.
ORA-01418: specified index does not exist

ORA-02443: Cannot drop constraint - nonexistent constraint
Migrate Monitor schema 7.2.1 to 7.2.2 on Oracle


Monitor (emamgr) <install_dir>\config\database\monitor\migration\v721
to722.
For example:
followed by the Oracle Net Service Name following the user
name/password.
For example:


Foundation (wwfmgr) 1. Foundation schema must be v7.2.2.
2. Monitor schema must be v7.2.1.
Change to
<install_dir>\config\database\monitor\migration\v721
to722.
Monitor database.
For example:
If the response indicates an incorrect version, perform the
necessary tasks before continuing.
3 migrate_monitor_721_to_7 Change to
22.sql <install_dir>\config\database\monitor\migration\v721
Monitor (emamgr) to722.
schema from version 7.2.1 to 7.2.2.
For example:
Migrate Foundation schema from 7.2.2 or 7.2.3 to 7.3. on Oracle

Before proceeding with this section, you must know the password for the Oracle user. Back up your
database before migration.
Note: JDA Foundation 7.2.3 uses the same schema as that of JDA Foundation7.2.2, hence you have to
create JDA Foundation 7.2.2 schema for Foundation 7.2.3
2. Run the following SQL script:

Foundation (wwfmgr) <install_dir>\config\database\platform, run this
script as the Foundation schema owner. For
example:
Review migrate_webworks_722_to_73.log for
errors.
3. Verify the database migration to 7.3.0.0 Type the following SQL query:
4. Continue with "Migrate Foundation schema from 7.3 to 7.3.0.1 on Oracle".

Migrate Monitor schema 7.2.2 to 7.3 on Oracle


2to73.
For example:
name/password.
For example:
Foundation (wwfmgr) 1. Foundation schema must be v7.3.0.0.
2. Monitor schema must be v7.2.2.
Change to
2to73.
Monitor database.
For example:
.sql <install_dir>\config\database\monitor\migration\v72
Monitor (emamgr) 2to73.
schema from version 7.2.2 to 7.3.
For example:
Migrate Foundation schema from 7.3 to 7.3.0.1 on Oracle



example:
errors.
3. Verify the database migration to 7.3.0.1 by entering the following SQL query:

4. Continue with "Migrate Foundation schema from 7.3.0.1 to 7.4. on Oracle".
Migrate Monitor schema 7.3 to 7.3.0.1 on Oracle

73to7301.
For example:
user name/password.
For example:


Change to
<install_dir>\config\database\monitor\migration\v
73to7301.
Run this script to verify the current version of the Monitor
database.
For example:
3 migrate_monitor_73_to_7301. Change to
sql <install_dir>\config\database\monitor\migration\v
schema from version 7.3 to 7.3.0.1.
For example:
Migrate Foundation schema from 7.3.0.1 to 7.4. on Oracle


example:
errors.
3. Verify the database migration to 7.4. by entering the following SQL query:
4. Continue with "Migrate Foundation schema from 7.4 to 7.4.1 on Oracle".

Migrate Monitor schema 7.3.0.1 to 7.4 on Oracle


7301to74.
For example:
user name/password.
For example:
Foundation (wwfmgr) 1. Foundation schema must be v7.4.
2. JDA Monitor schema must be v7.3.0.1.
Change to
<install_dir>\config\database\monitor\migration\v
7301to74.
Monitor database.
For example:
3 migrate_monitor_7301_to_74. Change to
sql <install_dir>\config\database\monitor\migration\v
schema from version 7.3.0.1 to 7.4.
For example:
4 migrate_csm_data_owned_by_ Change to
ema.sql <install_dir>\config\database\monitor\migration\v
Foundation (wwfmgr) 7301to74.
Run this script to migrate the Security Manager data.
For example:
@migrate_csm_data_owned_by_ema.sql


2. Run the following SQL scripts in the specified order:

1 verify_ds_tables.sql Run this script to verify if you have any invalid
Foundation (wwfmgr) searches in the Foundation schema. If you have
invalid data then you must run the
cleanse_ds_tables SQL script.
In directory
<install_dir>\config\database\platform, run this
example:
sqlplus wwfmgr/wwfmgr @verify_ds_tables.sql
2 cleanse_ds_tables.sql Run this script to clean up invalid searches in
Foundation (wwfmgr) Foundation schema.
In directory
<install_dir>\config\database\platform, run this
script as the Foundation schema owner.
This script can be run with two options:
L - Use this option to list the invalid searches. For
example:
@cleanse_ds_tables.sql L
D - Use this option to delete the invalid searches.
For example:
@cleanse_ds_tables.sql D
example:
errors.
3. Verify the database migration to 7.4.1 Type the following SQL query:
4. Continue with "Migrate Foundation schema from 7.4.1 to 7.4.2 on Oracle".

Migrate Monitor schema 7.4 to 7.4.1 on Oracle


Monitor (emamgr) <install_dir>\config\database\monitor\migration\v74t
o741.
For example:
name/password.
For example:
Change to
<install_dir>\config\database\monitor\migration\v74t
o741.
database.
For example:
.sql <install_dir>\config\database\monitor\migration\v74t
Monitor (emamgr) o741.
schema from version 7.4 to 7.4.1.
For example:
Migrate business rules

database to version 7.4.1. This migration process uses XSL files to read and convert XML data in the
1. Back up the Monitor database table EMA_BUSINESS_RULE.

2. Change to directory <install_dir>\config\database\monitor\migration\v74to741.
Using a text editor, open NWMigrateBusinessRule_config.xml. Review the settings in this file.

Use forward slashes for Windows
and UNIX.
traceLevel The amount of trace information in Verbose
the trace file:
terse - Minimal trace information
Migration Settings
migrationDirectory The full path to the directory <install_dir>/config/database/
containing the XSLT file used to monitor/migration/v74to741/
migrate business rules. xmlscripts
4. Run the migration process by opening a command-line prompt and enter:

NWMigrateBusinessRule.cmd -B"Monitor" -T"DataComparison"
Migrate Foundation Schema from 7.4.1 to 7.4.2 on Oracle

2. Run the following SQL scripts in the specified order:
1 migrate_webworks_741_to_742. In directory
sql <install_dir>\config\webworks\database\oracle,
Foundation (wwfmgr) run this script as the Foundation schema owner. For
example:
errors.
3. Verify the database migration to 7.4.2. Type the following SQL query:
4. Continue with "Migrate Foundation schema from 7.4.1 to 7.4.2 on Oracle".

Migrate Monitor schema 7.4.1 to 7.4.2 on Oracle


to742.
For example:
name/password.
For example:
2. JDA Monitor schema must be v7.4.2
Change to
to 742.
database.
For example:
42.sql <install_dir>\config\database\monitor\migration\v741
Monitor (emamgr) to742.
schema from version 7.4.1 to 7.4.2.
For example:
Migrate Foundation schema from 7.4.2 or higher to 2016.1

If your JDA Foundation schema is at version 7.4.2 or higher, you can migrate the schema to 2016.1
with a single set of scripts. Prior to migration:
Create the JDA System user and the ManugisticsPkg table in the JDA System schema
create_jda_system.sql (in <install_dir>config\database\setup)

ManugisticsPkg.sql (in <install_dir>\config\database\platform)
In version 2016.1, the csm_user.email column is required. JDA recommends that you populate
this field for all users prior to migration. If you do not, the field will be filled with a single space,
but you will not be able to send emails to users.
If you are using the JDA Platform database for authentication (that is, you are not using LDAP or
some other form of external authentication), the password encryption is changed in the 8.0
release. As a result, all user passwords in the database will be invalidated and will need to be
reset. JDA provides a utility to generate a new password (see Generate an encrypted password for
batch (on page 170) for more information on this utility). Alternatively, you can generate a new
password using the genPasswordHash and update the CSM_USER table with the updated
password. If your database is 8.0 or later, you do not need to reset the users passwords.
During migration, the administrative user (System) is added to the database if it does not already
exist, with a default password of password. You should log in and change the password for this
user after the migration is complete.
During migration, a reference schema is created in a new schema called WWFREFOSM. This serves
as a reference to update the JDA Foundation schema to the current version. In the instructions
below, <wwf_target_schemaname> refers to the schema that you are migrating.
Ensure that the Oracle BIN directory that is defined in the PATH environment variable is same as
ORACLE_HOME. The ORACLE_HOME is defined in the installer.properties file in the directory
<Install_dir>\install. After migration process is completed, the Oracle BIN directory can be reset
to the original setting to ensure that the applications that are dependent on this Oracle client do
not fail.
To migrate a version 7.4 or higher database:
1. Back up your database.
3. Change to directory <install_dir>/config/database/platform/migration and run the pre-

migration script as shown below.
Windows:
premigrate_webworks <wwftarget_pwd> <system_user> <system_pwd> <[IsRerun_flag>
UNIX:
premigrate_webworks <wwftarget_pwd> <system_user> <system_pwd> <[IsRerun_flag>
For example:
premigrate_webworks wwfmgr system manager
Use the IsRerun_flag if you have already run the pre-migration and the reference schema already
exists.
4. Review the premigrate.log file. If any errors are reported in the log file, you must fix them before
migration and run the pre-migration script until it states that the schema can be safely migrated.
You may find that the log file may include listings on unsupported cardinalities. You should
recreate the filters listed in the log file or delete (if filters are not going to be used) from the
version you have initiated the migration process. Filters creation criteria are as follows:

Unsupported cardinalities in the CSM table filters and extended CSM table filters: The
premigrate.log file contains the table filter and extended table filter records from the
CSM_FILTER table. These filters list the RELATION_NAMEs with unsupported cardinalities in the
MD_TABLE_RELATION table.
The unsupported cardinality values for table filters are 1 (one-to-many) and 3 (many-to-
many).
The unsupported cardinality values for extended table filters are 2 (many-to-one) and 3
(many-to-many).
Unsupported cardinality in the extended CSM entity filter: The premigrate.log file contains
the entity extended filter records from the CSM_FILTER table. This filter lists the
RELATION_NAMEs with unsupported cardinalities in the MD_TABLE_RELATION table.
The unsupported cardinality values for entity extended filters are 2 (many-to-one) and 3
(many-to-many).
If you find these errors in the premigrate.log file, modify filters and run the pre-migration script
until it states that the schema can be safely migrated.
5. Run migrate_webworks.cmd to migrate the database to the version 2016.1. Verify the log files
for ORA- errors once the execution is completed (the logs are saved in migrate_webworks.log).
Windows:
migrate_webworks <wwftarget_pwd> <system_user> <system_pwd> <[IsRerun_flag]>
UNIX:
migrate_webworks <wwftarget_pwd> <system_user> <system_pwd> <[IsRerun_flag]>
For example:
migrate_webworks wwfmgr system manager
Parameter:
<[IsRerun_flag]>: Indicates whether the reference schemas have to be created or not. If

the required reference schema already exists from a previous run of pre migrate or migrate,
the value of this flag must be Y. In this case migration reuses the existing reference schemas.
If not, the flag must be N so that the reference schemas are re-created. Default value is N.
Notes:
Foundation migration creates WWFREFOSM reference schema. Ensure that the same schema
name is not already in use as migration drops and re-creates the schema. You must not make
changes to the reference schema. If you make any changes, you must set IsRerun_flag to N
and run the above scripts.
Foundation migration creates back-up tables (*JBAK or *JBAK1), when a column in a table or a
table itself is dropped or truncated. The back-up tables are created for you to refer to the
tables/columns that are dropped during migration. For example: You may need to refer to the
back-up tables in order to re-create the hierarchies or searches in the new paradigm.
6. Create or update the ABPP schema:
If upgrading from version 7.7 or lower:
run cr_abpp_user.sql from the <install_dir>\database\setup folder to create the ABPP

database user.

Run the script createABPPschema from the <install_dir>\database\platform folder to

create the ABPP schema.
If upgrading from 7.8 or higher version, run the following steps:
1. Ensure the grants specified in the cr_abpp_user.sql script (located in the

<install_dir>\database\setup folder) are available to the ABPP schema owner.
2. Update the ABPP schema using the script updateAbppSchema coreServices.
Migrate Monitor schema from 7.4.2 or higher to 2016.1.0.x

If your JDA Monitor schema is at version 7.4.2 or higher, you can migrate the schema to 2016.1.0.x
with a single set of scripts. To migrate a version 7.4.2 or higher database:
1. Back up your database.
3. Change to directory <install_dir>/config/database/monitor/migration and run the pre-

migration script as shown below.
Windows:
premigrate_monitor <monitortarget_pwd> <wwftarget_pwd> <system_user> <system_pwd>
<[IsRerun_flag]>
UNIX:
premigrate_monitor <monitortarget_pwd> <wwftarget_pwd> <system_user> <system_pwd>
<[IsRerun_flag]>
4. Review the log file premigrate.log. If any errors are reported in the log file, you must fix them
before migration and run the premigrate step until it states that the schema can be safely
migrated.
5. Run migrate_ monitor.cmd to migrate the database to the version 2016.1. Verify the log files for
ORA- errors once the execution is completed (the logs are saved to migrate_ monitor.log).
Windows:
migrate_monitor <monitortarget_pwd> <wwftarget_pwd> <system_user> <system_pwd>
<[IsRerun_flag]>
UNIX:
migrate_monitor <monitortarget_pwd> <wwftarget_pwd> <system_user> <system_pwd>
<[IsRerun_flag]>
Parameter:
<[IsRerun_flag]>: Indicates whether the reference schemas have to be created or not. If

the required reference schema already exists from a previous run of pre migrate or migrate,
the value of this flag must be Y. In this case migration reuses the existing reference schemas.
If not, the flag must be N so that the reference schemas are re-created. Default value is N.
Note: Monitor migration creates EMAWWFREFOSM and EMAREFOSM reference schemas.

Ensure that the same schema name is not already in use as migration drops and re-creates the
schema. You must not make changes to the reference schema. If you make any changes, you
must set IsRerun_flag to N and run the above scripts.

Additional database scripts

JDA Platform provides additional scripts in directory <install_dir>\config\database\platform. It is
not necessary to run these scripts unless specified in documentation for the JDA Platform-based
applications that you are using. The scripts are described for reference only.
Script Description
update_app_synonyms.sql Run this script as documented for JDA applications. Generally,

you should run this script before you run the
change_schema_name.sql. Run this script as the system
user.
If you change the Foundation schema name for your database,
ensure that you grant execute permission on
ManugisticsPkg.sql to the new owner.
IMPORTANT: If you are changing the Foundation schema owner,
then update_app_synonyms.sql needs to be run for the
Foundation schema before you run change_schema_name.sql.
change_schema_name.sql Run this script as documented for JDA applications. Generally,

you should run this script before migrating an application
schema to 2016.1 where you have changed the schema name,
for example, if the 7.1.x schema name was stsc and the 2016.1
schema name is scpomgr. Run this script as the system user.
For jda_system user, run this script with the default privileges.
If you change the Foundation schema name for your database
between versions 7.2.x and 2016.1, ensure that you grant
execute permission on ManugisticsPkg.sql to the new owner.
IMPORTANT: If you are changing the Foundation schema owner,
then change_schema_name.sql needs to be run for the
Foundation schema before you migrate to 2016.1.
convert_to_char_semantic.sql Run this script as documented if your database schemas have

VARCHAR2 columns that do not use CHAR semantics. This script
converts all varchar2 and char column types to NLS character
length semantic. Run this script as the system user. Run this
script only after Foundation schema has been migrated to the
target level and all the packages and procedures in Foundation
schema are compiled.
You must provide schema name, to which this conversion is
applied, as an argument for this script.
Usage: sqlplus system/manager @convert_to_char_semantic.sql
<schema_name>
For example: sqlplus system/manager
@convert_to_char_semantic.sql wwfmgr
Note: This script is generally required only for databases
migrated from 7.1 and earlier. Databases from 7.2 or later are
assumed to be in CHAR semantics.

Script Description
enroll_app_schema.sql Run this script as documented for JDA applications. The script
sets up application schema permissions as well as permissions
between the application schema and the Foundation schema. Do
not run this script for the Foundation schema. You can run this
script as the system user.
If the script displays an error message regarding invalid stored
procedures or compiled views, recompile the procedures using
Oracle. For SCPO, it is necessary to recompile only if you receive
an error on the last run of enroll_app_schema.sql. Refer to the
Oracle documentation for procedures.
Note: You should not run this script against non-JDA application
schemas.
enroll_igp_schema.sql This script must be run if the IGP interface tables are in a
separate Oracle schema. Run the script after creating the
Foundation schema and the IGP schema owner. In directory
<install_dir>\config\database\platform, run this script as
the system user.
For example:
sqlplus system/manager @enroll_igp_schema.sql
The script prompts for the IGP schema owner, for example,
igpmgr. The script grants permissions to the IGP schema owner.
Note: You should not run this script against non-JDA application
schemas.
csm_expire_all_passwords Run this script as the Foundation schema owner to expire all
passwords. This forces users to change their passwords the next
time they log on. Generally, you would run this script only after
making changes to password properties.
create_default_fe_instances.sql In directory <install_dir>\config\database\platform, run this
Foundation (wwfmgr) script to create default Flexible Editor (FE) Instances. This script
takes one argument:
Note: This script is supported only
for creating default flexible editor Owner for the FE Instance (Mandatory). Owner refers to a
instances in an empty database. valid JDA Platform User.
By default, all the FE Instances will be of Public scope. If an FE

Instance already exists for a Specific Listing Name & Primary
Table, than this script will not create another FE Instance.
Usage: sqlplus wwfuser/wwfpassword
@create_default_fe_instances.sql <owner_name>
For example: sqlplus wwfmgr/wwfmgr
@create_default_fe_instances.sql SuperUser
Review the file create_default_fe_instances.log for errors.
Notes on migrating a database for a new character set

Follow the steps in this section if you are migrating JDA Platform from version 7.1.x or earlier. The
current version of JDA Platform requires a UTF8-based database encoding. This means that you can
store, process, and retrieve data in multiple supported languages using a single character set. You
must use character set AL32UTF8, which conforms to Unicode 3.1.

Note: If you already migrated the character set in Foundation version 7.2, then skip this section. Go
to "Migrate the Foundation schema on Oracle" (on page 70).
When you migrate an earlier database to the supported version of Oracle, you can convert to another
character set using Oracles import utility. Examples of earlier JDA databases are version 6.x or 7.1.2.
During conversion, Oracle encodes the data as specified by the environment variable NLS_LANG. This
variable has three components: language, territory, and character set. They must be set correctly for
both import and export.
If the NLS_LANG setting equals the database character set on the database being imported, then
no conversion or validation occurs. The resulting import could contain corrupt or truncated data if
the database character set is actually different.
If the NLS_LANG is different from the database character set on the database being imported, then
Oracle converts the data to the NLS_LANG setting.
CAUTION: The conversion can take place during import or export, but conversion can occur
only once.
Example of migrating a database for a character set

Follow the steps in this example to get your data into a new Oracle database at the supported level
using AL32UTF8 character set. These instructions apply only to databases that do not contain extended
ASCII characters. Note that many common characters (such as the Euro and common western
European characters such as , , or ) are multibyte in unicode. If you have data in your database
that is not standard ASCII, see "Migrate databases with extended ASCII and multibyte data" (on page
95).
1. Back up the original database on the older version of Oracle.
2. Run Oracles Character Set Scanner. This process finds exceptions with the database. For details,
see Oracle documentation.
3. Determine the NLS parameters of the original database using the following SQL queries:
select * from nls_database_parameters where parameter='NLS_LANGUAGE';
select * from nls_database_parameters where parameter='NLS_TERRITORY';
select * from nls_database_parameters where parameter='NLS_CHARACTERSET';
4. On the machine hosting the original database, check the value for variable NLS_LANG.
If the NLS_LANG is different from the original database, do not change it.
If the NLS_LANG is not set, then set it to the same format as that of the original database. Use
the following format:
<NLS_LANGUAGE>_<NLS_TERRITORY>.<NLS_CHARACTERSET>
For example, on UNIX enter the following:

export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
5. Complete the full export of the database using Data Pump utility expdp. Data Pump is server-
based, and not client-based. Dump files, log files, and SQL files are accessed relative to 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.

6. Before you run Data Pump Export, a directory object must be created by a DBA or by any user with
CREATE ANY DIRECTORY privilege. While exporting the dump using expdp utility, you must specify
the directory object with the DIRECTORY parameter. For example:
Unix:
CREATE DIRECTORY dumpdir AS '/oradev/dumps';
Windows:
CREATE DIRECTORY dumpdir AS 'd:\dumps';

expdp system/manager schemas=schema1,schema2 directory=dumpdir dumpfile=backup.dmp
logfile=backup_exp.log
If the export is performed by a user with dba privileges, then the import must be performed by a
user with dba privileges. For more details on using Datapump export, see Oracle documentation.
7. Create a new database instance using JDA scripts after installing JDA Platform. Your database
character set should be AL32UTF8. To create the instance using JDA scripts, see "Create an Oracle
database" (on page 22).
8. On the target machine, set the NLS_LANG to the same value that was used to create the export
(dmp) file. For example, on Unix,
export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
9. Import the dmp file from step 5. For example,

impdp system/manager schemas= schema1,schema2 directory=dumpdir
dumpfile=backup.dmp logfile=backup_imp.log
10. Migrate the Foundation schema using instructions "Migrate the Foundation schema on Oracle" (on
page 70).
Migrate databases with extended ASCII and multibyte data

Follow these instructions for databases that contain extended ASCII and multibyte data. In previous
releases, many applications supported a native database encoding, such as JA16SJIS for Japanese,
Big5 for Chinese, or WE8ISO8859P15 for Western European characters. In this version only a unicode
database (AL32UTF8) is supported for all languages. Because of the disparate length semantics of
extended ASCII and multibyte characters, you must follow these special instructions to get your data
into a new Oracle 12c database using the AL32UTF8 character set.
1. Set the NLS_LANG based on the encoding of the source database. For example:
set NLS_LANG=JAPANESE_JAPAN.JA16SJIS
2. Use Oracle's export utility and create a dump file of your data for your existing source database.
3. Create a new destination Oracle database at the supported level with character set AL32UTF8. You
can use JDA scripts. Edit the character set in file createDB.sql. To create the instance using JDA
scripts, see "Create an Oracle database" (on page 22).
4. On the target machine, set the NLS_LANG to the same value that was used to create the export
(dmp) file. For example:
set NLS_LANG=JAPANESE_JAPAN.JA16SJIS
5. Import only table and object definitions using the following command-line options. For example:
impdp system/manager schemas=wwfmgr,scpomgr directory=testdir dumpfile=source-
ja16sjis.dmp exclude=constraint content=metadata_only logfile=source-
ja16sjis_imp.log

In this example, wwfmgr owns the Foundation schema and scpomgr owns the SCPO schema used
by SCPO.
6. Using SQL*Plus, run the JDA script convert_to_char_semantic.sql in directory

<install_dir>\config\database\platform as the system user:
sqlplus system/manager @convert_to_char_semantic.sql <schema_name>
7. Disable all triggers by creating a script, dis_triggers.sql. In the following example, scpomgr and
wwfmgr are the schema owners in the dump file. Use the following statements in SQL*Plus to
create the SQL file:
SET linesize 130;
SET pagesize 0;
SET head off;
SET echo off;
SET pagesize 0;
SET feedback off;
COLUMN trigger_name format a30;
SPOOL dis_triggers.sql;
SELECT 'ALTER TRIGGER ' || owner ||'. ' || trigger_name ||' DISABLE; ' "ALTER
Statement"
FROM dba_triggers
WHERE owner IN ('SCPOMGR', 'WWFMGR')
/
SPOOL off;
8. Using SQL*Plus, run dis_triggers.sql as the Oracle system user.
9. Import the data with the following options. For example:

impdp system/manager schemas=wwfmgr,scpomgr directory=testdir dumpfile=source-
ja16sjis.dmp tables_exists_action=append content=all logfile=source.log
This imports the data along with constraints, triggers, and indexes. The triggers are re-enabled.
10. Migrate the Foundation schema using instructions "Migrate the Foundation schema on Oracle" (on
page 70).
Configure JDA Platform Server

After you install JDA Platform, you can change many of the configuration parameters. Some
parameters are set during installation while many others have default values. These parameters affect
the JDA Platform Server, but they are not specific to any single JDA application. Generally, you can
change the configuration parameters before or after you install JDA Platform-based applications. For
detailed information on application-specific settings, see the Installation/Administration Guide for that
application.
After you install JDA Platform and all JDA Platform-based applications, you must configure the server
before it can be started.

To configure the server:
Weblogic
Change to the <install_dir>\config\bin\platform directory and run

configureJDAServer
WebSphere
Change to the <install_dir>/config/bin/platform folder, and run

configureJDAServer <WAS_admin_user> <password> <profile_bootstrap_address>
For example, if the profile bootstrap address is 4170, the admin user is appAdmin and the
password is password, use the following:
configureJDAServer appAdmin password 4170
You can find the bootstrap address in the

$WAS_HOME/profiles/<profilename>/properties/portdef.props file.
Note: When setting up your server, you must run the configureJDAServer script after all JDA
Platform-based JDA applications are installed. If you subsequently remove an application or if you
install an additional application into the JDA Platform directory, you must run the script again to
recreate the server configuration.
Start and stop the JDA Platform Server

The JDA Platform installation includes the file startWebworksServer to start the JDA Platform
Server. The file is located in directory <install_dir>\config\bin\platform. When you start the JDA
Platform Server, make sure the JDA Platform database and other applications database(s) are already
started.
Starting the Platform server
The JDA Weblogic application server(s) can be setup in two modes:
As a cluster of 'n' nodes along with an admin server OR
As a standalone server.
The standalone server itself is configured as a combination of an admin server (AdminServer) and a
managed server (JDAServer). Each server can be started independently using the
startWebworksAdminServer and startManagedWebworksServer commands. These commands
are true for both standalone and cluster modes. The servers can also be setup as services on a
windows environment.
The managed server depends on the presence of an admin server for downloading Weblogic
configuration information, executing server stop commands and so on. Immediately after
configureJDAServer is completed, the managed server is not aware of its configuration. This
information is downloaded from the admin server during the time the managed server is first started.
The admin server must be up and running at the first time (and also at the time when you run stop
commands to shut down the servers).

After the managed servers are up, there is no requirement to keep the admin server running. At
subsequent attempts, the managed server(s) are capable of starting up in MSI (Managed Server
Independence) mode even when the admin servers are down. In addition to saving memory, in some
cases server startup time improves when it does not have to sync with admin server. However, you
may choose to keep the admin server running at all times.
Start JDA Platform Server on Windows

Configure the JDA Platform server as a Windows service by typing the following from a command
prompt in the <install_dir>\config\bin\platform directory:
Startwebworksserver ConfigureService IncludeCIS
Start the Platform server by typing:
Startwebworksserver StartAll
Note: When you start the Webworks server for the first time, start the admin server and managed
server individually using the following commands (or by starting the services one after another). Also
wait for the admin server to start before starting the managed server. This ensures that the
configuration information is in sync.
startWebworksAdminServer
startManagedWebworksServer JDAServer t3://yourAdminHost:yourAdminPort
When you configure a Windows service, the following four services are created:
JDA_CIS_2016.1_Agent_<CIS Agent Port>
JDA_CIS_2016.1_SSOServer_<CIS Agent Port>
JDA-AdminServer-<Environment Name>
JDA-JDAServer-<Environment Name>
The Environment name is configured based on the environment name entered during installation.
The CIS services are automatically configured as dependent services for the JDA AdminServer.
If you have dependent services other than CIS, then you can configure them in the
StartWLSServer.cmd file in the <install_dir>\config\bin\platform directory by setting:
set DEPENDENT_SERVICES=<dependent service name>
Separate multiple service entries with a comma. You can also specify a delay during which
time the service status is Starting, not Started. This may be useful in a cluster where the
managed server(s) cannot start until the administration server is started. For example, specify
the number of milliseconds to wait. (1000 milliseconds = 1 second). During the delay period,
the WebWORKS service status is Starting, not Started.
set DELAY_MILLIS=180000
If starting the server from the command line:
1. Open a command-line prompt and navigate to directory <install_dir>\CIS\CIS-SDK\bin and enter

the following:
a. To start the CISAgent

launch runCISAgent.py
b. To start the SSOServer

launch runSSOServer.py

2. Open a command-line prompt and navigate to directory <install_dir>\config\bin\platform and

enter the following:
startWebworksServer
Start JDA Platform Server on UNIX

1. Open a shell-prompt and navigate to directory <install_dir>/cis/cis-sdk/bin and enter the
following to start the CIS Agent:
a. To start the CISAgent

./launch.sh runCISAgent.py
b. To start the SSOServer

./launch.sh runSSOServer.py
2. Open a shell-prompt and navigate to directory <install_dir>/config/bin/platform and enter the

following:
./startWebworksServer
Note: When you start the Webworks server for the first time, start the admin server and managed
server individually using the following commands. Also wait for the admin server to start before
starting the managed server. This ensures that the configuration information is in sync.
startManagedWebworksServer JDAServer t3://yourAdminHost:yourAdminPort
Use the -StartAll argument to start the Admin, Managed, CIS, and SSO servers. At a shell -
prompt, enter the following:
./startWebworksServer -StartAll
Reading the console during startup on a WebLogic platform

On a WebLogic platform, start the JDA Platform Server. Text similar to the following displays when the
server is started:
<Oct 20, 2011 4:52:19 AM GMT> <Notice> <WebLogicServer> <BEA-000365> <Server state
changed to RUNNING>
<Oct 20, 2007 4:52:19 AM GMT> <Notice> <WebLogicServer> <BEA-000360> <Server started in
RUNNING mode>
The server also writes information to the console and to log files in directories
<install_dir>\config\logs and <install_dir>\config\JDADomain\servers\JDAServer\logs.
The JDA Platform Server runs in Greenwich Mean Time (GMT), and all log files use GMT. The
startWebworksServer script has a time zone property set to GMT. You must not change this setting
because JDA Platform-based applications can fail and data can be corrupted. Data is stored in GMT as
users are often located across time zones. Users can select a default time zone in which to view data,
and the software performs time conversion automatically.
JDA Platform configures WebLogic to start using the password of password1, but you should change
the password before moving to a production environment. See "Change the WebLogic admin
password" (on page 171).
If the server fails to start, see Troubleshoot the JDA Platform Server (on page 264).

Reading the console during startup on a WebSphere platform

On a WebSphere platform, the following message displays in the console when you start the JDA
Platform Server.
ADMU0116I: Tool information is being logged in file

/usr/local/IBM/WebSphere/AppServer/profiles/AppProfile/logs/WebWORKS/startServer.log
ADMU0128I: Starting tool with the demand2 profile
ADMU3100I: Reading configuration for server: WebWORKS
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebWORKS open for e-business; process id is 504062
Logs are written to $WAS_HOME/profiles/<profile_name>/logs/<server_name>/
Shut down the JDA Platform Server

On Windows, to shut down the server use one of the following methods:
If started from the command line:
a. Open a command-line prompt and change to directory <install_dir>\config\bin\platform

and enter the following:
shutdownWebworksServer AdminURL <weblogic admin user> <password>
For example: shutdownWebworksServer t3://localhost:7001 weblogic weblogic1
b. Open a command-line prompt and change to the directory <install_dir>\cis\cis-sdk\bin and

enter the following to stop the SSO server:
launch stopAdapter.py -p webSessionCoordinator -i <host_domain_name>
For example:
launch stopAdapter.py -p webSessionCoordinator -i host1_dev_corp_local
c. Enter the following to stop the CIS Agent:

launch stopCISAgent.py
If you started the JDA Platform Server as a Windows service, then shut down the service in the
following order:
a. CISAgent
b. CIS SSOServer
c. Managed Server
d. Admin Server
On UNIX, to shut down the server do the following:
1. Change to the <install_dir>/config/bin/platform directory and enter the following:
Weblogic: shutdownWebworksServer AdminURL <weblogic admin user> <password>
For example, shutdownWebworksServer t3://localhost:7001 weblogic weblogic1
IBM Websphere: shutdownWebworksServer <websphere admin user> <password>
For example, shutdownWebworksServer appAdmin password

2. Open a shell prompt and change to the directory <install_dir>/cis/cis-sdk/bin and enter the
following to stop the SSO server:
launch.sh stopAdapter.py -p webSessionCoordinator -i <host_domain_name>
For example:
launch.sh stopAdapter.py -p webSessionCoordinator -i host1_dev_corp_local
3. Enter the following to stop the CIS Agent:

launch.sh stopCISAgent.py
Stop all servers

Use the -StopAll parameter to shut down the Managed, Admin, CIS agent, and SSO server.
If started from the command line:
Open a command-line prompt and change to directory <install_dir>\config\bin\platform and

WebLogic
shutdownWebworksServer AdminURL <weblogic admin user> <password>[-StopAll]
For example: shutdownWebworksServer t3://localhost:7001 weblogic weblogic1 [-StopAll]
WebSphere
shutdownWebworksServer <WAS admin user> <password> [-StopAll]
For example: shutdownWebworksServer appAdmin password [-StopAll]
Note: You can use this argument to shut down the Managed, Admin, CIS agent, and SSO server even
if they are configured as windows services.
Remove all windows services

On Windows, you can use the RemoveCIS argument along with Startwebworksserver to remove
the CIS, SSO, Managed, and Admin services at a time.
Open a command-line prompt and change to directory <install_dir>\config\bin\platform and

startWebworksServer.cmd -RemoveService -RemoveCIS
This command removes all the four services.
Configure a cluster on WebLogic

This chapter provides an overview of configuring a cluster on WebLogic. A cluster is a group of JDA
Platform Servers functioning together and using the same database. Clustering provides the
opportunity for increased availability, better performance, and load balancing when using a front-end
Web Server or load director. The Web Server tier is suggested, but not required. JDA Platform cluster
does not support http session or session EJB failover.
Note that where multiple JDA Platform Servers use the same Foundation schema, a cluster
configuration is the only supported configuration. Specifically, each server must be a member of the
same WebLogic cluster, and each server instance must have the same JDA applications installed. Using
a non-clustered configuration can cause data inconsistency and data access problems.

Although the cluster configuration can vary widely based on your requirements, the following graphic
depicts a typical cluster. The cluster has several components. Machines 1 and 2 each have two
instances of JDA Platform. Each instance is called a managed server. A Web Server at the front end of
the cluster distributes requests to the managed servers in a round-robin method. In addition, the
cluster requires a WebLogic administration server, hosted on machine 4. The admin server can be
configured on a separate, less powerful machine. The cluster uses a common database server for JDA
application schemas, located on machine 3.
Before you configure a cluster, you should plan the architecture based on your anticipated or actual
load requirements. Consider creating the cluster in a test environment before deploying it to a
production environment. You should have a strong knowledge of your network, operating system, and
WebLogic. For additional information, see the WebLogic documentation on the Oracle website.
JD A C luster
O ptional W eb JD A P latform
H T T P /H T T P S C IS A gent S erver 1 A B P P schem a
requests
load S erver
director T ier A pplication schem a
JD A P latform F oundation schem a

S S O A gent S erver 2
Cluster components
A cluster configuration comprises of the following:
A single administration server (admin server), which can be configured on a separate machine.
As an alternative, the admin server can be run from the same instance as a managed server. The
admin server identifies all managed servers in the cluster, and the cluster uses the config.xml file
on the admin server. Logging also occurs on the admin server. An administration server requires
JDA Platform, WebLogic or WebSphere, and any JDA applications necessary for your environment.
One or more managed servers, each of which represents an instance of the JDA Platform Server.
The names are WebWORKS1, WebWORKS2, and so forth. For each managed server, you must
install JDA Platform and all JDA applications once. For example, if you plan two managed servers
on a single machine, you must install JDA Platform and all applications twice.
Note: Ensure that the two servers are configured identically.
A Web Server tier that forwards requests to WebLogic or WebSphere. Examples of Web Servers
are Sun Java System, Netscape Enterprise Server, Microsoft IIS, and Apache HTTP.
A database server hosting the application schemas. All administration and managed servers use
the same JDA application schemas. The database server could be on the same machine as the
managed or admin server. However, for failover, consider using a separate machine as shown in
graphic.
In a large cluster, an optional load director that could distribute requests across a collection of
Web Servers. The load director can be configured to forward requests directly to WebLogic or
WebSphere. For more information on how to configure cluster see JDA Platform Installation
Administration Guide.

Configure IP addresses
Configure each machine in the cluster with a static IP address. Multiple IP addresses (multi-homing)
are not necessary. Multiple managed servers on a single machine can listen on the same IP address as
long as each managed server on that machine has a different listen port. Multi-homed servers are still
supported, in which case the same listen port can be used. The recommended configuration is a single
IP address with different listen ports. When using static IP addresses, you must disable dynamic
addressing. For detailed instructions, see documentation for your operating system.
1. Configure each machine in the cluster with a static IP address.
2. Confirm the changes. At a command-line prompt enter the following:

nslookup <server_name>
where <server_name> is the name of the server. The output is similar to the following:
Server: mydns01.company.com
Address: 10.0.0.80
Name: jdasrv.technology.company.com
Address: 10.0.100.10
In this example, the static IP address 10.0.100.10 is assigned to the server jdasrv.
3. Continue with "Install WebLogic for a cluster" (on page 103).
Install WebLogic for a cluster

Install WebLogic Platform once on each machine in the cluster. Even if you plan more than one
managed server on a machine, install WebLogic Platform only once. For detailed instructions on
installing WebLogic, see Install Weblogic Server (64-bit). After installation, continue with Install JDA
Platform for a cluster (on page 49).
IMPORTANT: Select Complete when installing WebLogic Platform on all machines in the cluster. Do not
use a Custom installation.
Install JDA Platform for a cluster

Install JDA Platform once for each managed server. If you plan two managed servers on a machine,
then install JDA Platform twice to different directories. For example,
Each JDA Platform installation is referred to as a managed server. When installing the JDA Platform
multiple times on the same machine, enter the same information in all fields, with the following
exceptions:
In Choose Install Folder dialog box, enter a unique path for each installation.
In Choose Shortcut Folder dialog box, select a new Program Group for each installation or do
not create icons (Windows).
In Server Configuration dialog box, enter a different port number for each installation when
using a static IP address. For example, 7001, 8001. If the machine is multi-homed with more than
one static IP address, then you can use the same port number. Do not use localhost for the
machine name when installing JDA Platform. Use the actual server name.

In the Foundation Security Model Oracle Connection and ABPP Oracle connection dialog
box, the parameters must be the same for all installations. The managed servers must share the
same Platform schema.
Install JDA applications for the cluster

Install each application on each managed server and on the admin server. For example, if you have
installed JDA Platform in two locations, then you have two managed servers and the applications must
be installed to both instances. In this example, JDA Platform is installed in two locations, and the JDA
applications must also be installed in both:
Use the same Database Settings for the same applications. After installation, create or migrate the JDA
application database schemas.
Continue with "Configure the admin server" (on page 104).
Configure the admin server

Follow these steps to configure the administration server. Each cluster must have a single admin
server. The machine hosting the admin server must have WebLogic, JDA Platform, and all JDA
Platform-based applications installed. In cluster.properties, you must identify the managed servers
in the cluster and set the port numbers. Perform these steps only on the admin server. The admin
server can be on a separate machine, or it can also be a managed server.
1. Change to directory <install_dir>\config\bin\platform.
2. Using a text editor, open cluster.properties
3. Specify the following information:
Property Name Description

Cluster Configuration information
ClusterMembers Specify the cluster members separated by a comma.

Default values are WebWORKS1,WebWORKS2.
Note: The member names are case-sensitive. Do not use
spaces between member names.
ClusterAddress Specify the name of the machines and ports for the servers
or to a DNS name that has been configured for the system.
This is the address used by clients to connect to this
cluster. This address may be either a DNS host name that
maps to multiple IP addresses or a comma separated list of
single address host names or IP addresses.
If network channels are configured, you can set the cluster
address on a per channel basis.
Managed server configuration

These variables depend on the nodes defined in ClusterMembers. If cluster members are
WebWORKS1 and WebWORKS2, replace <cluster member> with webWORKS1 and webWORKS2.
<cluster member>.listenAddress Specify the computer name or the IP address of the node
in the cluster.

Property Name Description

<cluster member>.interfaceAddress If you are using multiple NIC cards, specify the Interface
address for this node. If you are not using multiple NIC
cards, leave this blank.
<cluster member>.listenPort Specify the port number. Default is 7001.
Admin server configuration
adminServer.listenAddress Specify the computer name or the IP address of the admin

node in the cluster.
adminServer.interfaceAddress If you are using multiple NIC cards, specify the Interface
address for the admin node. If you are not using multiple
NIC cards, leave this blank.
adminServer.listenPort Specify the standard port number for the admin node.
Default is 7003.
adminServer.SSLPort Specify the secure port number for the admin node.
Default is 7004.
Note: On UNIX platforms use the fully qualified computer name or the IP address.
4. Save and exit cluster.properties.
5. On the admin server, run the command file configureJDACluster by entering the following:
configureJDACluster <firstmembername>
For example, if you are configuring WebWORKS1 as the admin server type configureJDACluster
WebWORKS1
The process takes a few seconds to complete.
Note: In a cluster, all managed servers and the administration server have their own config.xml,
but only the config.xml on the administration server is used when starting the cluster. Each
managed server has its own webworks_config.xml. Ensure that the server_instance_name
property in webworks_config.xml matches the server name in the cluster.
6. Continue with "Configure the managed servers" (on page 105).
Configure the managed servers

The steps in this section must be applied to each managed server. You must have WebLogic installed
once on each machine. For each managed server, you must install JDA Platform and all JDA Platform-
based applications in your configuration environment. Each managed server must know the location of
the admin server, and each managed server must have its unique name assigned. The names used
must match the entries made in file cluster.properties.
1. Stop the server if it is running.
3. Run the command addClusterMember <server_name>. This command creates the JDADomain
directory and modifies the config.xml file for the cluster member.
Note: Ensure that the server_instance_name property in webworks_config.xml matches the

server name in the cluster.

Configure the Web Server plug-in

You can configure a Web Server tier for your architecture. This is required for a cluster. The Web
Server tier acts as a front end to your configuration. WebLogic provides an integration point for a Web
Server. This plug-in interfaces directly with WebLogic. The Web Server provides failover and server
affinity. The Web Server is a tier between clients using browsers and WebLogic. For details on
configuring the plugins for the Web Servers supported by Oracle, see the WebLogic documentation on
the Oracle website. The example below uses Oracle iPlanet Web Server. When installing Oracle iPlanet
Web Server or another Web Server, note all installation properties that you enter.
IMPORTANT: JDA applications use and reserve the HTTP session cookie called JDA_JSESSIONID. When
using a Web Server tier as a front end to the JDA Platform Server in a cluster or non-clustered
environment, the cookie name must be specified in the Web Servers configuration file.
Web Server Configuration file Parameter

Apache HTTP httpd.conf WLCookieName
Note: If you mention 'Secure' key in
http.conf file, then the users will not be
allowed to log in through http URL.
Microsoft Internet Information Server iisproxy.ini WLCookieName

Oracle HTTP server mod_wl_ohs.conf WLCookieName
Place WLCookieName parameter within If
Module block.
Oracle iPlanet System Web obj.conf WLCookieName
Server Place WLCookieName parameter within
Object block.
When you are accessing the SSL enabled cluster URL to avoid the java script errors on login page,
update the following property in the abpp.properties file from the directory
<install_dir>\config\properties.
com.i2.ui.check-referer.whitelist=<web_server_hostname with domain_name>
Note: The <web_server_hostname with domain_name> value should be in lower case. You should
update the property on each cluster node.
Example of configuring Oracle iPlanet System plug-in

You can install the Web Server on the same machine as the admin server, managed server, or on a
separate machine. After installing Oracle iPlanet Web Server, you must configure it to work with your
cluster.
1. Change to directory \https-<server>\config where <server> is the name of the machine. For
example:
/iPlanetWS/https-jdasrv/config
In some cases, the directory includes the fully-qualified domain name. For example:
/iPlanetWS/https-jdasrv.company.comBack up file magnus.conf.
2. Using a text editor, open magnus.conf.
a. Cite the proxy file by adding the following lines at the end of the file:
Init fn="load-modules" shlib="libj2eeplugin.so"

Init fn="load-modules" funcs="wl_proxy,wl_init"

shlib="/WLS_Plugin_SPARC/lib/mod_wl.so"
Init fn="wl_init"
The following example is for AIX:

Init fn="load-modules" funcs="wl-proxy,wl-init"
shlib="/tools/weblogic1211/server/lib/aix/libproxy_61.so"
Init fn="wl-init"
Ensure that property shlib refers to the correct path for the WebLogic bin directory. This
example that WebLogic is installed on the same machine. If the application server is on a
different machine, copy the library dll (Windows) or sl (UNIX) to the WebLogic bin
directory.
IMPORTANT: In this example, three lines are depicted. In practice, try to fit each Init
statement on a single line. Do not wrap Init lines. Otherwise, Oracle iPlanet Web Server can
fail to start.
3. Save and exit file magnus.conf.
4. Back up file obj.conf.
5. Using a text editor, open obj.conf, which is located in the same directory.
For a clustered architecture, set the WebLogicCluster parameter to the static IP addresses of
the managed servers and the listen port. In this example, the cluster has two machines. Each
machine has two managed servers. Add this information at the end of file obj.conf:
<Object name="weblogic" ppath="*/*">
Service fn="wl-proxy" WebLogicCluster="10.0.100.10:7001,
10.0.100.10:8001,10.0.100.11:7001,10.0.100.11:8001" WLCookieName=
"JDA_JSESSIONID"
</Object>
A second example uses the actual machine names:

<Object name="weblogic" ppath="*/*">
Service fn="wl-proxy" WebLogicCluster="jdasrv:7001,
jdasrv:8001,jdasrv2:7001,jdasrv2:8001" WLCookieName="JDA_JSESSIONID"
</Object>
For a non-clustered architecture, use the WebLogicHost parameter and set it to the host name
or IP address of the WebLogic application server. Add this information at the end of the file:
IMPORTANT: In this example, three lines are depicted. In practice, try to fit each Init
statement on a single line. Do not wrap Init lines. Otherwise, Oracle iPlanet Web Server can
fail to start.
<Object name="weblogic" ppath="*/*"> Service fn="wl-proxy"
WebLogicHost="10.0.100.10 WebLogicPort="7001"
</Object>
IMPORTANT: If possible, keep the Service statement on a single line in the obj.conf file.
Otherwise, Oracle iPlanet Web Server can fail to start.
Note: Comment the following servlet mapping in the default-web.xml file in the directory
<install_dir>/https-<server_name>/config.



6. Save and exit obj.conf.
To verify your changes:
1. Start the Web Server.
2. Open Administer Web Server. The location varies depending on your operating system. A password
dialog displays.
3. Enter the user name/password combination specified during installation. The Server Administration
window displays.
4. Select the <server_name> and Manage. You may receive a warning dialog that some edits have
not been loaded. This is normal because you edited the two conf files.
5. Click Apply to effect changes to the files.
6. A message should display stating "The Server is Currently On." If the Web Server plug-in does not
start, check your edits in the conf files. The Web Server must be running for the cluster to function.
7. Continue with Generate an encryption key for a cluster (on page 109).
Note: You need to change the IIS 8.5 settings to allow the PUT and DELETE verbs. You need to select
the IIS site for which you want PUT and DELETE verbs. In the right pane of the WebDav Authoring
Rules available in the selected IIS site, you must select the Disable WebDav option. You should
remove the WebDav module from the available Modules and you should also remove
WebDAVHandler from HandlerMapping.
Configure SSL in Oracle iPlanet Web Server

SSL is recommended only on the front-end proxy server. Since the front-end proxy server is usually
behind the firewall, the proxy server to JDAServer(s) communication can be in HTTP. By default, the
JDAServer created as a result of running configureJDAServer and configureJDACluster have the SSL
ports disabled.
Request digitally signed certificate from a Certificate Authority, or CA.
Install the digitally signed certificate.
Create Listener with SSL Enabled and add the certificate to the Listener.
Configure application protocol

If there is a proxy or load balancer server between client and application server and both transport's
connection protocol is different, then set the app.protocol.mode property value to 'http' OR 'https' in
abpp.properties based on the connection between the proxy server and application server.

Enable WebLogic plug-in through WebLogic Admin Console

When you have a cluster, it is typically accessed through a front end proxy server (for example: IIS,
Apache, Oracle Web Server). To manage such requests, set the WLS setting "WebLogic Plug-In
Enabled" to Yes.
1. Open the WebLogic console by using the hyperlink http://<server name>:<port>/console. The
WebLogic Server Administration Console log in page is displayed.
2. Enter the admin username and password and click Log in.
3. Navigate to your server and then click Lock & Edit. The server is listed under JDA Domain >
Environment > Servers section.
4. Select Configuration > General tab.
5. Select Yes from the WebLogic Plug-In Enabled drop-down list.
6. Click Save, and then Activate Changes.
7. Restart the JDA application server.
Note: The above is true even when the WLS server(s) are "front-ended" by a load balancer instead of
a proxy web server.
Generate an encryption key for a cluster

Configure each managed server with a common encryption key. With the common key, users log in
once. When load-balancing directs them to another machine, users do not log in again. The generated
key must be distributed to each managed server and to each JDA Platform SRE instance; otherwise, a
users credentials are valid only on the managed server where the user first logged in. Without the
common key, users must log in repeatedly.
1. Shut down all managed servers if they are running. It is not necessary to shut down the Web
server or admin server.
2. On one of the managed servers, open a command line prompt and change to
<install_dir>\config\bin\platform.
3. Execute the batch file genEncryptionKey by entering the following:

genEncryptionKey
This batch file outputs a line in the console containing the encryption key. For example:
Generating a new encryption key
Generated Key: {E:AES}b61cd9349d66b84b32d15cdf1910d530
Your key will be different. Copy the key.
4. Open another command-line prompt and change to directory <install_dir>\config\properties.

5. Using a text editor, open the file webworks_config.xml.
6. Search for the following property:
<configPropertyname name="encryption.service.key">
7. Paste the key generated previously to the value element. For example,
<value>{E:AES}b61cd9349d66b84b32d15cdf1910d530</value>
8. Save webworks_config.xml the editor.

9. Repeat steps the steps on all managed servers in the cluster and on all instances of JDA Platform
SRE.

Configure the cluster as a Windows service

After you have configured the administration server and each managed server as a Windows service
follow the instructions in this section. See "Configure JDA Foundation Server as a Windows service".
1. On the administration server, add dependent services to the file

startWebworksAdminServer.cmd. An example of a dependent service is the Oracle Service. For
example,
set DEPENDENT_SERVICES=OracleServiceNWSAMPLE
2. The administration server must start before the managed servers. If managed server(s) are on the
same machine as the administration server, then add the administration server as a dependent
service in the file startManagedWebworksServer.cmd on each managed server. For example,
set DEPENDENT_SERVICES=JDA-AdminServer-Service
Note: Be sure to use the Service Name value, not the display name.
3. To ensure that the administration server is started before the managed servers, you can add
additional commands to startWebworksServer.cmd. When added to the beginning of
startWebworksServer.cmd, the sleep command delays starting the managed server.
sleep 300
In this example, the sleep command delays for 300 seconds (five minutes). This should ensure
that the administration server has already started.
Start the admin server

Always start the administration server before the managed servers. Use the file
startWebworksAdminServer.
1. On the machine hosting the administration server, open a command-line prompt.
2. Change to directory <install_dir>\config\bin\platform and enter the following:

Use the -StartAll parameter to start the Platform, CIS, and SSO servers. At a command- prompt,
startWebworksAdminServer -StartAll
Wait for the server to start. The console should display the following:
<Info> <Configuration Management> <BEA-150016> <This server is being started as the

administration server.>
<Starting WebLogic Admin Server "WebWORKSAdmin" for domain "JDADomain">
<Thread "ListenThread.Default" listening on port 7003, ip address *.*>
To start the administration server as a Windows Service, enter the following:
startWebworksAdminServer -ConfigureService
3. Continue with "Start the managed servers" (on page 111).
Note: The admin server creates log files weblogic_WebWORKSAdmin.log and

access_WebWORKSAdmin.log in directory <install_dir>\config\logs.

Start the managed servers

After starting the administration server, start each managed server. For example, if the managed
server is installed in two locations on the machine, then each must be started. Use the
startManagedWebworksServer script.
1. On the machines hosting the managed servers, open a command-line prompt.
2. Change to directory <install_dir>\config\bin\platform and enter the following:

startManagedWebworksServer <node_name> <Admin server URL>
Wait for each managed server to start. The console should display the following:
<Notice> <WebLogicServer> <BEA-000330> <Started Web
Logic Managed Server "WebWORKS1" for domain "JDADomain" running in Production Mode>
where WebWORKS1 is the name of the managed server.
To start the managed server as a Windows Service, enter the following:

startManagedWebworksServer-ConfigureService managedserver1 http://adminHost:7003
3. Repeat for each managed server in the cluster.
Access the cluster

Users should access the cluster through the Web Server address. Usually, this is the URL for the Web
Server, for example, http://jdasrv. If you receive an error page, verify the listen port for the Web
Server. It may be necessary to include the port number in the URL, for example, http://jdasrv:80. The
Web Server redirects the request to one of the managed servers. Users should not directly access the
managed servers, for example, by using http://IP1:7001.
For iPlanet Web Server on AIX and Solaris, the URL for the Web Server should include context root
that you have defined at the time of JDA Platform installation. Following should be the URL usage:
http://ServerhostName:Port/context root/shell/home
For example, http://jdasrv:80/jda/shell/home
Add a member server to a cluster

Follow these steps to add a member server to a cluster.
1. Install JDA Platform and JDA applications for the new managed server. See Install JDA Platform for
a cluster (on page 49).
2. Shut down the admin and managed servers.
3. Configure the new member server:
a. See "Configure the managed servers" (on page 105) for details.
b. Apply the same encryption.service.key in file webworks_config.xml for the new member
server. You can copy the key from another member server. For details, see "Generate an
encryption key for a cluster" (on page 109).
4. Add the member server to the Web Server configuration file. For example, if using Sun Java
System, add the member server to file obj.conf. See "Configure the Web Server plug-in" (on page
106).
5. Start the admin server, then start the managed servers.

Change the WebLogic cluster admin password

The JDA Platform installation configures the WebLogic account with the password weblogic1. This
allows the server to start immediately after installation. You should change the password for the
WebLogic system account before moving to a production environment.
1. Shutdown all the managed nodes. Keep the admin node running.
2. Change the password for the admin node. See "Change the WebLogic admin password" (on page
171)
3. Restart the admin node and make sure that it is running.
4. Modify the boot.properties to update the password on all managed nodes.
5. Start the managed nodes.
Update JNDI lookup URLs in a Weblogic 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. Stop all managed servers in the cluster, and then stop the administration server.
2. On each node in the cluster, change to directory <install_dir>\config\properties.
3. Using a text editor, open file webworks_config.xml.
4. Find the following section:


<category name="jndi" >
<configProperty name="jndi_provider_url">
<value>t3://jdasrv:7001</value>
<descriptionResourceKey>jndi_provider_url.desc</descriptionResourceKey>
<scope>local</scope>
<restartServer>true</restartServer>
</configProperty>
5. The value element identifies jdasrv1:7001 as the JDA Platform Server that the client applet
communicates with. Add a secondary JDA Platform Server in the cluster. For example:
<value>t3://jdasrv1:7001,jdasrv2:7001</value>
6. Save and exit webworks_config.xml. Ensure that you make this change on every cluster
member.
Shut down Managed Server

If a managed server is installed in two locations on the machine, then each must be shut down. Use
the shutdownManagedServer script to shut down the managed server.
3. Run the shutdownManagedServer script:

Usage: shutdownManagedServer adminURL <admin_user> <admin_password>

<MANAGED_SERVER_NAME>
Example. shutdownManagedServer t3://localhost:7003 user pwd WebWORKS1
Shut down Admin Server

Always shut down the admin server after the managed servers. Use the
shutdownWebworksAdminServer script to shut down the admin server.
3. Run the shutdownWebworksAdminServer script:
Usage: shutdownWebworksAdminServer adminURL <admin_user> <admin_password>
Example. shutdownWebworksAdminServer t3://localhost:7003 user pwd
Configure a cluster on WebSphere

This chapter provides an overview of configuring a cluster on WebSphere. A cluster is a group of JDA
Platform Servers functioning together and using the same database. Clustering provides the
opportunity for increased availability, better performance, and load balancing when using a front-end
Web Server or load director. The Web Server tier is suggested, but not required. A JDA Platform
cluster does not support http session or session EJB failover.
Note that where multiple JDA Platform Servers use the same Foundation schema, a cluster
configuration is the only supported configuration. Specifically, each server must be a member of the
same WebSphere cluster, and each server instance must have the same JDA applications installed.
Using a non-clustered configuration can cause data inconsistency and data access problems.
Although the cluster configuration can vary widely based on your requirements, the following graphic
depicts a typical cluster. The cluster has several components. Machines 1 and 2 each have two
instances of JDA Platform. Each instance is called a managed server. A Web Server at the front end of
the cluster distributes requests to the managed servers. In addition, the cluster requires a WebSphere
administration server (deployment manager), configured on the same machine as the first managed
server. The deployment manager identifies and manages all managed servers on all the nodes in your
environment. The cluster uses a common database server for JDA application schemas, located on
machine 3.
Before you configure a cluster, you should plan the architecture based on your anticipated or actual
load requirements. Consider creating the cluster in a test environment before deploying it to a
production environment. You should have a strong knowledge of your network, operating system, and
WebSphere.

JD A C luster
W eb
O ptional S erver JD A P latform
H T T P /H T T P S C IS A gent S erver 1 A B P P schem a
requests
load T ier
director ( W ebS phere A pplication schem a
plug -in )
JD A P latform F oundation schem a
S S O A gent S erver 2
Cluster components
A cluster configuration comprises the following:
A single administration server (deployment manager), which should be configured on the same
machine as the first managed server. The deployment manager identifies and manages all
managed servers on all the nodes in your environment. For more details, see "Set up an IBM
Websphere ND environment".
One or more managed servers, each of which represents an instance of the JDA Platform Server.
In the graphic, the servers named WebWORKS, are installed on the profiles: ProfileA, ProfileB and
so on. For each managed server, you must install JDA Platform and all JDA Platform-based
applications once. For example, if you plan two managed servers on a single machine, you must
install JDA Platform and all JDA applications twice.
Note: Ensure that the managed servers are configured identically, and have identical Server
Config names.
A Web Server tier that forwards requests to the application servers, for example the WebSphere
HTTP server.
A database server hosting the application schemas. All administration and managed servers use
the same JDA application schemas. The database server could be on the same machine as the
managed or admin server; however, for failover, consider using a separate machine as shown in
the graphic.
In a large cluster, an optional load director that could distribute requests across a collection of
Web Servers. The load director can be configured to forward requests directly to WebSphere, but
this configuration is not addressed in this chapter.
Configure IP addresses
Configure each machine in the cluster with a static IP address. Multiple IP addresses (multi-homing)
are not necessary. Multiple managed servers on a single machine can listen on the same IP address as
long as each managed server on that machine has a different listen port. Multi-homed servers are still
supported, in which case the same listen port can be used. The recommended configuration is a single
IP address with different listen ports. When using static IP addresses, you must disable dynamic
addressing. For detailed instructions, see documentation for your operating system.
1. Configure each machine in the cluster with a static IP address.
2. Confirm the changes. At a command-line prompt, enter the following:

nslookup <server_name>
where <server_name> is the name of the server. The output is similar to the following:
Server: mydns01.company.com
Address: 10.0.0.80
Name: jdasrv.technology.company.com
Address: 10.0.100.10
In this example, the static IP address 10.0.100.10 is assigned to the server jdasrv.
3. Continue with "Install WebSphere for a cluster" (on page 115).
Install WebSphere for a cluster

Install WebSphere Platform once on each machine in the cluster. If you do not create profiles when
you install WebSphere, or if you plan to add another node to a cluster, use the Profile Management
Tool to create profiles. See "Create WebSphere profiles for a clustered environment" (on page 31).
Prerequisites
Clustering is supported only on the Websphere ND environment. Make sure that you have WebSphere
installed along with the required service packs as noted in System requirements (on page 11).
Create the cluster

1. Install the appropriate JDA applications on the machine that holds the first node and the
deployment manager. For example, node on host1, on profile AppSrv01 (Node AppSrvNode01) is
to be part of the cluster. While installing the JDA applications, you need to pick AppSrv01 as your
profile.
a. Update the soapcredentials.properties file and change the value of soap_port and
soap_host to the values corresponding to Dmgr. In our example, the new values are:
soap_port:8879
soap_host:host1
Note: Modify the soapcredentials.properties file on each node participating in the cluster.
2. Start the Dmgr profile using the startManager.sh script from the
$WAS_HOME/profiles/dmgr/bin directory.
3. Start the Appsrv01 profiles using the startNode.sh script from the
$WAS_HOME/profiles/Appsrv01/bin directory.
4. Run the configureJDACluster file from <install_dir>/config/bin/platform directory with the

following syntax:
configureJDACluster <DmgrHost> <DmgrBootstrapPort> <NodeName> <admin_user>
<admin_password> <cluster_name>
For the previous example the command is:

configureJDACluster host1 6103 AppSrvNode01 appAdmin password JDACluster1
The command creates a cluster and adds the JDA Platform server as the first member of the
cluster.
5. Install the next JDA Platform server. This installation could be on the host2 where you already have
a federated AppSrvNode02. If this node is on the same computer (host1), ensure that you use
different set of port numbers during the installation process.

Note: In a WebSphere cluster, the SERVER_CONFIG_NAME should be the same across the cluster
members. You must use the same server config name that you used from the first server.
6. On this subsequent installation, run addClusterMember using the following syntax:

addClusterMember <DmgrHost> <DmgrBootstrapPort> <NodeName> <admin_user>
<admin_password> <clustername>
For example:
addClusterMember host1 6103 AppSrvNode02 appAdmin password JDACluster1
This command creates a clone of JDA Platform server (and the embedded JDA applications) that is
already available in the cluster and makes it available on the new node.
Note: After you create the cluster, wait until the application binaries are copied over from the
Admin server to the new node. You can go to the installedApps directory of the new node and see
that the application binaries copied over.
After a fresh installation you might be unable to start the JDA Platform server. If the logs complain
of a security error, perform the following steps:
7. Attempt to stop all node agents and the deployment manager. Restart the deployment manager
and node agents.
IMPORTANT: While stopping, always stop the node agents first. While starting, start Deployment
manager first.
8. If the node agents on any of nodes fail to start, synchronize that node with the Dmgr using the
syncNode command from your profile's bin directory. This command synchronizes the
configuration between the DMgr and the node. Once syncNode completes successfully, restart the
node agent.
9. Stop and restart the JDA Platform server.
Set up the front end proxy HTTP server

You must set up a HTTP server and configure it to front the cluster. Before configuring the HTTP server
you must configure SSL. The following sections explain setting up a IBM HTTP Server as a front-end
proxy.
Configure SSL for the front-end proxy server

SSL is recommended only on the front-end proxy server. Since the front-end proxy server is usually
behind the firewall, the proxy server to JDAServer(s) communication can be in HTTP. By default, the
JDAServer created as a result of running configureJDAServer and configureJDACluster have the SSL
ports disabled. This section explains how to add SSL on the proxy webserver.
Ensure that the directory ssl/keys exists in the <HTTP> directory and that the group UNIX user
group wasgroup has write permission to this directory. wasgroup must also have write permissions to
the <HTTP>/logs directory.
Use the IBM Key Manager to install the validation keys to enable SSL. The IBM Key Manager is
available in the bin directory of WebSphere, WebSphere application client, and IBM HTTP server
products.
When you are accessing then SSL enabled cluster URL to avoid the java script errors on login page,
update the following property in the abpp.properties file from the directory
com.i2.ui.check-referer.whitelist=<web_server_hostname with domain_name>

Note: The <web_server_hostname with domain_name> value should be in lower case. You should
update the property on each cluster node.
Create IBM HTTP Server keys

1. Launch the IBM Key Management utility by running following command from bin directory:
iKeyMan
Note: On Unix systems, you require xServer to launch the Key Managers graphical user interface.
2. Select Key Database File > New, and then enter the following information:
Key Database Type: CMS key database file
File Name: ihscert.kdb
Location: <IHS_root>/ssl/keys
3. Click OK. A password prompt displays.
4. Enter and password, reconfirm it and click OK.
Note: Optionally, you may set an expiration time in days. For example, if you specify 60 days, you
must create a new password after 60 days.
5. Verify that the following files have been copied to the <HTTP_root>/ssl/keys directory:
ihscert.kdb
ihscert.rdb
ihscert.sth
ihscert.crl
6. In the Key Management utility, select Create > New Self-signed certificate.
7. Specify the following information:
Key label: self-signed
Version: X509 V3
Key Size: 1024.00
Common Name: Enter the fully qualified host name of the HTTP server
Organization: Enter the organization name
Country: Enter the country.
Validity: Period 365 days
8. Click OK. A new self-signed certificate is created and added to the ihscert.kdb file.
9. Choose Key Database file > Exit to close the Key manager utility.
Configure front-end proxy server

From the cluster, generate a plugin-cfg.xml file. This file contains information that is used by different
HTTP servers and is copied to a location, from where it can be accessed by the HTTP server.
Note: Modify appropriately the paths of the files as existing in your setup.
In the following example, UNIX path names are used. On a Windows system modify the path names.

1. From the machine where you installed the first JDA Platform node, navigate to the
/config/bin/platform directory and run AddVirtualHost with the following parameters:
addVirtualHost Dmgr_host_name Dmgr_SOAP_port appAdmin password webserver_port
Add all the access ports (HTTP) that are used by the server. If you have two JDA Platform servers,
configured to run on HTTP ports: 7050 and 8050, run this command two times, once for each port.
For example:
addVirtualHost host1 8879 appAdmin password 7050
addVirtualHost host1 8879 appAdmin password 8050
Note: The Webserver_port is the port that you have configured the webserver to run on in
httpd.conf. You cannot run on port 80 on UNIX unless you are a root user. Generally, you run this
command twice, once with a standard port and once with an SSL port.
2. From dmmgr/bin directory, run genplugincfg.bat.
This command generates the plugin-cfg.xml file in the

$WAS_HOME/profiles/$dmgr_profile/config/cells directory.
Note: While configuring the WebSphere in AIX, update the "UseInsecure" value from false to true
in the plugin-cfg.xml file.
3. Copy plugin-cfg.xml to the computer where you have the proxy web server. For example, if you
are running Apache, copy this file to the conf directory of Apache, that is, the directory where
httpd.conf is located.
The plugin-cfg.xml generated from the Dmgr machine may contain references to c:\program
files\... folders. If your proxy server has installed the plug-in in some other folder, make the
necessary changes in the plugin-cfg.xml.
Note: The listed .kdb files originate from IBM plugin installation. You can install these from the
regular WAS 6.1 zipped archive. Once unzipped, use the plugin\install.exe (just like you
installed the WAS product from WAS\install.exe).
4. Ensure that the httpd.conf file has the following two lines at the end.
LoadModule was_ap20_module
"/usr/local/IBM/WebSphere/Plugins/bin/mod_was_ap20_http.so"
WebSpherePluginConfig "/usr/local/Apache/Apache2/conf/plugin-cfg.xml"
5. If you are implementing SSL, add the following lines to the end of the httpd.conf file:
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 7051
FileETag none
<VirtualHost host1:7051>
ServerName host1
SSLEnable
Keyfile "/usr/local/IBM/IHS/ssl/keys/ihscert.kdb"
SSLStashfile "/usr/local/IBM/IHS/ssl/keys/ihscert.sth"
ErrorLog "/usr/local/IBM/IHS/logs/keyssslerror.log"
TransferLog "/usr/local/IBM/IHS/logs/sslaccess.log"
</VirtualHost>

SSLDisable
6. Stop the JDA Platform Server, the node agents, and the deployment manager nodes. Make sure
the HTTP server is also stopped.
7. Restart the Deployment manager, the node managers, HTTP server, then the application servers.
Generate an encryption key for a cluster

Configure each managed server with a common encryption key. With the common key, users log in
once. When load-balancing directs them to another machine, users do not log in again. The generated
key must be distributed to each managed server and to each JDA Platform SRE instance; otherwise, a
users credentials are valid only on the managed server where the user first logged in. Without the
common key, users must log in repeatedly.
1. Shut down all managed servers if they are running. It is not necessary to shut down the Web
Server or the admin server.
2. On one of the managed servers, change to <install_dir>\config\bin\platform.
3. Execute the batch file genEncryptionKey by entering the following:

genEncryptionKey

7. Paste the key generated in step 3 to the value element. For example,
8. Save webworks_config.xml and exit the editor.
9. Since there is a new encryption key to be used in the applications, you need to regenerate the
default encrypted password property of soapcredentials.property. Generate a new encrypted
password using the command genEncryptedPassword. The default string to be encrypted is
password
a. Using a text editor, open the soapcredentials.properties file located in directory

/config/properties.
b. In the password property, enter the newly encrypted password from the
genEncryptedPassword command
c. Save the file and exit the editor.
10. Repeat the previous steps on all managed servers in the cluster and on all instances of JDA
Platform SRE.

Update JNDI lookup URLs in a WebSphere cluster

In a clustered configuration, you can specify that the client use any one of the servers in the cluster.
To take advantage of this feature, you must modify the servers within the cluster to specify the
primary server and any backup servers.
1. Stop all managed servers in the cluster, and then stop the administration server.
2. On each node in the cluster, change to directory <install_dir>\config\properties.
3. Using a text editor, open file webworks_config.xml.

<value>iiop://jdasrv:7001</value>
</configProperty>
5. The value element identifies the JDA Platform servers in the cluster that the client communicates
with. For example:
<value>corbaloc::jdasrv1:7005,:jdasrv2:7005</value>
Make the same change to the java.naming.provider.url specified in webworks.commn.vars.cmd (or

.sh) file. For example:
-Djava.naming.provider.url=corbaloc::jdasrv1:7005,:jdasrv2:7005
6. Save and exit webworks_config.xml. Ensure that you make this change on every cluster
member.
Start the admin server (Deployment Manager)

Always start the administration server before the managed servers. If the deployment manager is not
running, start it as explained in this section.
1. On the machine hosting the administration server, open a command-line prompt.
2. Change to directory profiles/Dmgr/bin and enter the following:

startManager.sh -user appAdmin -password password
Wait for the server to start.
3. Continue with "Starting the node agents" (on page 120).
Note: Use the command stopManager to shut down the node agent.
Start the node agents

After you have started the administration server, start the node agents for each of the managed server
profiles. For example, if you use Appsrv01 and Apprsv02, start the node agents for these profiles.

2. Change to directory $WAS_HOME/profiles/$Profilename/bin and enter the following:

startNode.sh
3. Repeat the process for each managed server in the cluster.
Note: Use the command stopNode -username <websphere user> -password <password> to shut
down the node agent.
Start the managed servers

After you start the administration server, start each managed server. For example, if the managed
server is installed in two locations on the machine, then each must be started.
2. Change to directory <install_dir>/config/bin/platform and enter the following:

startWebworksServer
3. Repeat the process for each managed server in the cluster.
Access the cluster

Users should access the cluster through the Web Server address. Usually, this is the URL for the Web
Server, for example, http://jdasrv. If you receive an error page, verify the listen port for the Web
Server. It may be necessary to include the port number in the URL, for example, http://jdasrv:80. The
Web Server redirects the request to one of the managed servers. Users should not directly access the
managed servers, for example, by using http://IP1:7001.
Add or delete cluster members

To add a cluster member, run the addClusterMember script using following syntax:
addClusterMember <DmgrHost> <DmgrBootstrapPort> <NodeName> <admin_user>
For example,
addClusterMember host1 6103 AppSrvNode02 appAdmin password JDACluster1
This command creates a clone of JDA Platform server (and the embedded JDA applications) that is
already available in the cluster and makes it available on the new node.
To delete a cluster member, run the deleteClusterMember script using following syntax:
deleteClusterMember <DmgrHost> <DmgrBootstrapPort> <NodeName> <admin_user>

For example,
deleteClusterMember host1 6103 AppSrvNode02 appAdmin password JDACluster1
Items to verify after installation

After you install and configure the cluster, check that the uploads directory was created all the cluster
members. The location of this directory is <was_home>/profiles/<SERVER_PROFILE_NAME>/.
If this action has failed run the command mkdir $WAS_HOME/profiles/$profile/uploads manually.

Delete the cluster

1. Shut down all the application servers. On the server where the Deployment manager is running,
two processes should still be running (one for Deployment manager, and one for the Node
Manager). On the server that is just a node, you should still see one process still running (the Node
Manager). There should be no other wasadmin processes running.
2. From the first server where you created the cluster, go to the
<webworks_home>/config/bin/platform directory and run deleteWASCluster: <DmgrHost>
<DmgrBootstrapPort> <admin_user> <admin_password> <cluster_name>
For example:
deleteWASCluster host1 6103 appAdmin password JDACluster1
This will delete the cluster and all of the node application servers
3. Go to the Admin console and confirm that both application servers are no longer shown in the
Admin console.
Node pool manager

Use the Basic node pool
JDA Platform provides a predefined node pool called Basic. You can start the Basic node pool on the
JDA Platform Server or on a JDA Platform SRE machine. Running the Basic node pool on a separate
machine reduces the processing burden on the machine where the JDA Platform Server is running. The
number of nodes assigned to Basic depends on the JDA applications being used. Generally, the more
applications you have installed, the more nodes Basic has.
Having Basic allows you to start a pool immediately so you can begin using SRE. You can also create,
delete, and modify other pools in Process Manager. You can customize node pools by adjusting the
number of nodes and memory allocation in Process Manager. To start a node pool, see "Start a node
pool manager" (on page 122).
IMPORTANT: The installation and migration procedures for JDA Platform and JDA applications assume
that a node pool named 'Basic' exists. Therefore, do not delete this node pool. In addition, rather than
modify node pool Basic, it is preferable that you create and modify additional node pools for use in
your environment.
Start a node pool manager

To start a node pool, use the command file startNodePoolManager on the machine where the node
pool is to run. The command starts the node pool manager. The file is included with both JDA Platform
and JDA Platform SRE. You must specify the name of the pool exactly as it is spelled in table
SRE_NODE_POOL. Use the following syntax:
startNodePoolManager [-ConfigureService | -RemoveService] <pool_name>
Option Description Required?

<pool_name> The case-sensitive name of the pool Yes, to start a pool
-ConfigureService To configure startNodePoolManager as a Windows No

service
-RemoveService To remove startNodePoolManager as a Windows No
service
-H Shows usage for startNodePoolManager No

Note: You can start node pool Basic on Windows by selecting Start > Apps > JDA 2016.1 > Start
Node Pool Manager.
1. Ensure that the JDA Platform Server and database server are running.
3. Type startNodePoolManager and the pool name. For example, to start node pool Basic, type:
startNodePoolManager Basic
If the pool name has a space, enclose it in quotation marks. On Windows, you must use double
quotation marks. For example,
startNodePoolManager "My pool"
When the node pool manager starts, it does not return a command-line prompt. You can minimize
the console, but do not close it. To shut down a node pool, see "Shut down a node pool manager"
(on page 124).
Note: Use Process Manager to view node pools, increase and decrease the number of nodes for a pool,
or stop a node.
Start a node pool manager as a Windows service

You can configure a node pool as a Windows service. This allows you to start or stop the node pool
through Windows utilities. This option adds one service per node pool manager, so you can create
multiple services for multiple node pools on the same machine.
1. Install all JDA products before configuring the service.
2. On the machine where the node pool is to run, change to the <install_dir>\config\bin\platform
directory.
3. The node pool manager cannot start unless the JDA Platform Server and Oracle database server
are running. If both are Windows services, you can add them as Windows services in file
startNodePoolManager. For example:
set DEPENDENT_SERVICES=OracleServiceNWSAMPLE
Separate multiple service entries with a comma.
4. Save startNodePoolManager and exit the editor.
5. To configure the service, open a command-line prompt and type:

startNodePoolManager -ConfigureService <pool_name>
For example, to configure node pool Basic as a Windows service enter the following:
startNodePoolManager -ConfigureService Basic
If the pool name has a space, enclose it in double quotation marks.

startNodePoolManager -ConfigureService "My pool"
The command-line prompt returns:

NodePoolManager-Basic installed.
This command adds NodePoolManager-Basic as Windows service. The startup type is automatic,
meaning that the pool starts when the machine boots. When you first install the service, you must
start the node pool.

Note: If you plan to install additional JDA applications, you should first remove the
startNodePoolManager Windows service. After installation, re-create the service.
To start a node pool manager service:
You can start a node pool service using the following methods:
Open Windows Services. Highlight the service, for example, NodePoolManager-Basic. Select
Start. The service status changes to Started. A new console window does not display.
Open a command-line prompt and type:

net start NodePoolManager-<pool_name>
For example:
net start NodePoolManager-Basic
Note: Due to a third party dependency, one of the following is required in order to start the node
pool as a Windows service:
Add <JAVA_HOME>\bin directory to the path environment variable.
Install Microsoft Visual C++ 2010 Redistributable Package (x64).
IMPORTANT: Ensure that Microsoft Visual C++ 2010 Redistributable Package (x64) is
installed in the system for the windows services to work properly on Platform. If it is not
installed already, you can download it from https://www.microsoft.com/en-
us/download/details.aspx?id=14632
Either of the above includes a require library in the patch so that the service can start
correctly.
To remove a node pool manager service:
1. On the machine where the service is configured, open a command-line prompt.
2. Change to directory <install_dir>\config\bin\platform and type:

For example, to remove node pool Basic as a Windows service enter the following:
startNodePoolManager -RemoveService Basic
Shut down a node pool manager

You can shut down a running node pool from the user interface or from the command line. From the
user interface, the shutdown option action allows the pool to finish current work. When finished, the
pool does not accept new jobs. Before shutting down a running pool from the user interface, you
should first cancel all continuous jobs using the pool. Otherwise, the job restarts itself and the pool
does not shut down. To shut down the Node Pool Manager from the command line:
2. Change to the <install_dir>\config\bin\platform directory.
3. Type shutdownNodePoolManager and the pool name. For example, to shut down BasicPool, you
would type:
shutdownNodePoolManager BasicPool
shutdownNodePoolManager -force BasicPool
If the pool name has a space, enclose it in quotation marks.

shutdownNodePoolManager "My pool"
Note: Using the -force option shuts down the pool regardless of any processes that might be running
in the pool. Using this option kills all the processes, even continuous jobs.
Add node configurations

A node configuration specifies timeouts, minimum nodes, and maximum nodes to use when running a
process. Each JDA process has a default node configuration stored in tables SRE_NODE_CONFIG and
SRE_NODE_CONFIG_PROPS. When a job runs, it uses the default node configuration for the process
unless the user specifies a different node configuration. JDA provides a procedure to help you create
node configurations.
You can modify the default node configurations and create additional node configurations. For
example, you may want to add a node configuration record that increases the minimum and maximum
nodes. This could be used for running larger jobs during non-business hours. Include values for the
following fields when creating a node configuration record in table SRE_NODE_CONFIG.
The node configuration does not specify the node pools. To associate node pools with processes, see
"Add or edit a node pool" section in the JDA Platform OnLine Expert.
Note: Use the attribute nodeConfigurationName in the process request XML file to specify a node
configuration. Depending on the process, users can specify a node configuration in user interface by
selecting Advanced Configuration.
Description of SRE_NODE_CONFIG columns

SRE_NODE_CONFIG column Description
NODE_CONFIG_NAME The unique name for the configuration record. Use a

meaningful name to distinguish them. You can use the same
node configuration name as long as each one references a
different SERVICE_NAME.
SERVICE_NAME The predefined process name. You must use a valid
SERVICE_NAME. A single SERVICE_NAME can have multiple
node configuration records.
IS_DEFAULT When using multiple configurations, you must declare a
default. (Default = 1). Only one record per process can be
the default.
MIN_NODES The minimum number of nodes required to run the process. A
job cannot start unless the available nodes are equal to or
greater than the MIN_NODES. While running a job, if the
number of nodes drops below the MIN_NODES, the job will
fail. At least one node must be started to start any job.
Default is 0.
MAX_NODES The maximum desired number of nodes for the process. A
single-action process does not take advantage of multiple
nodes. In contrast, a multi-action process does. Default is 1.
BLOCKING_INIT_TIMEOUT The maximum number of seconds for preparing actions. In

the user interface, this phase is called Preparing Job. No
other processing for the job is performed. Default is 600.
NON_BLOCKING_INIT_TIMEOUT The maximum number of seconds during which one node
divides the job into actions (units of work). Default is 600.

SRE_NODE_CONFIG column Description
BUILD_ACTIONS_TIMEOUT The maximum number of seconds that each job actions

processing should not exceed. Job actions are units of work.
Default is 600.
BLOCKING_FINISH_TIMEOUT The maximum number of seconds for this job state. One
node performs this task. Default is 600.
CLOSE_JOB_TIMEOUT The maximum number of seconds for a job to close once all
nodes are finished processing. The default is 600.
RESET_TIMEOUT The maximum number of seconds reset job state should not
exceed. This state occurs because a node failed during
blocking or nonblocking initialization. The default is 600.
IGNORE_ACTION_FAILURE_COUNT The number of action failures before the job fails. Default is
0.
COMMENTS This is an optional field. You can use it to store comments.
You can create a node configuration record by copying an existing record, and then modifying the new
record. JDA Platform provides a database procedure to help you. This method is preferred because it
ensures that the new node configuration record has the requisite fields and it copies the required node
configuration properties stored in table SRE_NODE_CONFIG_PROPS.
1. Using SQL*Plus, connect to the database as the Foundation schema owner. For example:
2. Use the procedure cloneNodeConfig to copy an existing node configuration record. Use the
following syntax:
call sre_configuration.cloneNodeConfig('<ServiceName>',
'<OldConfigRecord>', '<NewConfigRecord>');
where the <ServiceName> is the process name from SRE_SERVICE_
INFO.SERVICE_NAME, <OldConfigRecord> is the node configuration record to be copied in
SRE_NODE_CONFIG.NODE_CONFIG_NAME and <NewConfigRecord> is the new node configuration
record. For example:
call sre_configuration.cloneNodeConfig('GenSys.FlexEd.Regular',
'FERegularViewNode', 'NewFERegularViewNode');
3. In this example, the new node configuration is NewFERegularViewNode. Use Oracle utilities to edit
the new node configuration record in table SRE_NODE_CONFIG. You can set unique timeouts for the
node configuration record.
4. Commit your changes.

CIS high availability mode

Starting with release 8.0, CIS is installed with the Platform installation by default. To run the CIS in
High Availability mode, you must configure the CIS services so each instance of CIS can act as a
backup should the CIS Agent or SSO server become unavailable. If an Infrastructure Services client is
accessing a CIS Agent and it becomes unavailable, the Infrastructure Services client switches to the
next server in the list.
C IS A gent/S S O A C IS A gent/S S O B
D atabase
SSO _ATTR
SSO _M AP Backup SSO Server
Adm in
Server
JD A S erver A JD A S erver B
Configure CIS for high availability in cluster mode

The entries in cisregistry.properties need to be configured as follows in order to run in High Availability
mode.
In a clustered environment, the cisregistry.properties on each of the appservers

(config/properties/cisregistry.properties) should be modified so that the client of CIS Agent
(appserver) knows where to failover in the event the first agent listed is down. In addition, the SSO
database will contain information so that the backup SSO server can take over functionality from a
primary.
In a two node cluster environment, the following steps would be needed to configure high availability
for the CIS Agent and SSO server:
1. On each of the cluster node, use a plain text editor to open the cisregistry.properties file located
in the <install_dir>\config\properties directory.
2. Edit the cisregistry.properties file on each node as follows :
server.1=<machine1>:<port1>
server.2=<machine2>:<port2>
Note: If <port> is omitted, the default port of 5015 is used.
3. Save and close the cisregistry.properties file.
4. Import the information to each machine from the <install_dir>\cis-sdk\bin directory. From
machine1:
launch importMachine.py <machine2> <port2>
Repeat the above on each server.

5. Re-Start the foundation servers as well as CIS Agents.
As an alternative to step 4, you can use the Infrastructure Services Manager to import the machines.
Infrastructure services adapter failover and recovery

Assume that you have created two bindings files using the following instance IDs: Instance-A and
Instance-B. If an Infrastructure Services client establishes a connection to port and starts sending
messages to a stateless operation using a non-persistent connection, the messages are sent to the
first adapter [Instance-A]. If that adapter becomes unavailable, subsequent messages are sent to the
next running adapter [Instance-B] without any exceptions. If all the adapters become unavailable, the
client receives an exception when using non-persistent connections. However, if you had restarted
either of the adapters, that adapter would receive subsequent messages without any exceptions.
Set the single sign-on domain for multi-application SSO

Single sign-on that involves multiple applications does not function correctly unless all the applications
are configured to receive cookies from a common IP domain. The SSO domain is associated with the
cookie that is placed on the client browser when an SSO session is first established. When the user
visits another application, the browser returns this cookie only to those applications whose URLs
domain-match the domain associated with the cookie under the rules established in IETF RFC 2109. As
a simple example, to associate this cookie with all applications in the jda.domain, the SSO domain
should be set to .jda.com. Record the leading period in the domain setting.
The domain can be configured by setting the value of the sso.domain property in the cis-
sso.properties file that is embedded into each Web application. Some additional options for
configuring the domain are documented in the cis-sso.properties file. If the SSO domain is not
properly configured, a user may be challenged in more than one application if the applications run on
different systems. This is because the cookie established by the first application is not sent by the
browser to the second application if the domain setting on the cookie does not match to the second
system. By default, cookies are sent back only to the IP address that generated them unless a
common domain is explicitly set. The URL used to access the application must contain the fully
qualified domain name for the cookies to be sent back by the application.

Utilities and common tasks
Chapter 6. Utilities and common tasks

Use the ldapUserExport utility
Use this utility to export the users from the LDAP store and synchronize the data with the User
Manager. Run the ldapUserExport utility to export the users from the LDAP store. Exported user
information will be written to the XML file. The generated xml file can be used to import the users into
the product instance by using the userImport utility. See Import users (on page 54) for more
information.
Use the following syntax to run ldapUserExport. Ensure that you adhere to the case shown in the
syntax:
ldapUserExport -credentials <credentialPropFile> -exportFilename

<fileNameWithPath> -operationMode <DEFAULT|ONLY_CREATE|ONLY_UPDATE>
For example:
ldapUserExport.bat -user=System -password= {E:AES}b61cd9349d66b84b32d15cdf1910d530

-exportFilename ldapExport.xml

-credentials <credentials_file> The name of the credentials file containing Yes, when using
either the user name/password combination batch
or only the password for the batch user. If in authentication. No,
a different directory, then specify the when the user and
absolute path. For example, password options
credentials.properties. For more information are used.
on creating a credentials file, see Use
encrypted batch authentication (on page
169).
-exportFilename <filename> Specifies the file to which the requested
system objects are exported. This file is
represented in an XML format.
-OperationMode If the OperationMode is DEFAULT, both
<DEFAULT|ONLY_CREATE|ONLY create and update modes are enabled. If the
_UPDATE> user exists in the LDAP store and not in the
User Manager product instance, then the
user is created in the product instance. If the
user exists in both stores, the batch file
compares the user information. If there is
any mismatch, it overrides the existing value
of the product instance. The generated XML
file contains both updated and created users.
If the OperationMode is ONLY_CREATE,
create mode is enabled. If the user is not
available in the product instance, the user is
imported from LDAP to the product instance
as a new user. The generated XML file
contains newly created users.


If the OperationMode is ONLY_UPDATE,
update mode is enabled. The batch file
compares the LDAP user with the existing
user in the product instance and updates the
field values if required. The generated XML
file contains both the existing value and
updated value.
For example, to update the users:
<User>
<LOGIN_NAME Value="usr1"/>
<FIRST_NAME Value="user" oldValue="User"/>
<LAST_NAME Value="one" oldValue="One"/>
<DESIGNATION Value="" oldValue="ASST_MGR"/>
<LOCALE Value="" oldValue="en_US"/>
<EMAIL_ADDRESS Value="abc@jda.com"
oldValue="user@html.com"/>
<PHONE Value="9916739773" oldValue="99999999999"/>
<FAX Value=""/>
<COUNTRY Value="IN" oldValue="USA"/>
<STATE Value="Karnataka"/>
<CITY Value="Bangalore" oldValue="city"/>
<POSTAL_CODE Value="560068" oldValue="12"/>
<ADDRESS1 Value="My Street" oldValue="address"/>
<ADDITIONAL_ATTRIBUTES InstanceName="FoundationInstance"
UpdateIfAlreadyExist="yes" Operation="UPDATE">
<ROLE ID="110"/>
<ROLE ID="102"/>
<ROLE ID="106"/>
<ROLE ID="100"/>
<ROLE ID="112"/>
<ENTERPRISE Value="JDA"/>

</ADDITIONAL_ATTRIBUTES>
</User>
If you do not provide OperationMode, then DEFAULT will be treated meaning that xml will have
information about both users for create and update. Choosing any option other than DEFAULT will
ensure that only filtered users will be available for create or update.
Use the versionInfo utility

Run this utility to display information on installed applications and analyze files currently installed. The
information is displayed for application version, build date, build label, type of installation, and
application server.
Change to directory <install_dir>\config\bin\platform. At the command-line prompt, enter the

following:
versionInfo.bat
For example:
<install Dir>\config\bin\platform>versionInfo.bat
------------------------------------------------------------------------
JDA Solutions
------------------------------------------------------------------------
System Information
------------------------------------------------------------------------
Foundation Sample
Version 2016.1.0.0
Build Date 20160124_2037
Build Label
InstallType Full Installation
Dependency Foundation 2016.1.0.0 20160124_1915
JDA Platform/JDA Monitor
Version 2016.1.0.0
Build Date 20160124_1915
Build Label
InstallType Full Installation
AppServer weblogic
------------------------------------------------------------------------
BUILD SUCCESSFUL
Total time: 1 second

Use the genPasswordHash utility

This utility generates an encrypted password for a user based on the input of a password at the
command line.

following:
genPasswordHash
For example:
<install Dir>\config\bin\platform\genPasswordHash
The utility will prompt for the password to be encrypted
Password:
Re-enter password:
The utility will then generate an encrypted password on the command line
{a6f82e50827ca2f4}e381720a600d2c22f4d5198572f0caf69cf9a773f452fc027a4a39e90cb7cd3c
You can then substitute this password into the database password field for a particular user.
Use the pingWebworksServer utility

Run this utility to know the status of the WebWorks server. Change to directory
<install_dir>\config\bin\platform. At the command-line prompt, enter the following:
pingWebworksServer credentials credentials.properties
For example:
<install Dir>\config\bin\platform\pingWebworksServer credentials

credentials.properties
The utility will then generate the following message in the command line when the WebWorks server is
up and running:
Pinging the WebWORKS Server ....

Successfully pinged WebWORKS as user: <user_name>
Data Division Utility

The Data Division Utility (DDU) is a stored procedure that can be used to divide the rows of a source
table into approximately equal chunks for multi-threaded data extraction. The DDU determines the
number of rows in the source table, divides them by the number of threads specified, and returns field
values that can be used to specify both the lowest boundary and the highest boundary of each chunk.
All of the chunks contain approximately the same number of rows.
The DDU can be only be used with Oracle relational database management systems.
Installation
The DDU is an installed component of JDA Platform.

Create the DDU stored procedure

The DDU is implemented as an Oracle 12c stored procedure, which resides in the database after
creation. To create the stored procedure, run the DDU initialization command ddu_init.cmd. This
command calls the DDU creation script ddu.plb, which creates the DDU stored procedure, adds it to
the database, and creates an empty results table (DDU_RESULTS) to hold the stored procedures output.
Note: The DDU initialization command, ddu_init.cmd, was installed with JDA Platform in the
<install_dir>\config\bin\platform directory. The SQL script ddu.sql was installed with JDA Platform
in the <install_location>\config\database\platform directory.
Run the DDU creation script by typing the following at the command prompt:
ddu_init <username>/<password>@<database_connection>
The called SQL script creates an empty DDU_RESULTS table. If a results table already exists from an
earlier execution of ddu.sql, it is dropped and replaced with the new empty table. Then the DDU
stored procedure is then created and added to the database.
Run the DDU stored procedure

The DDU stored procedure takes the following parameters:
Parameter Type Description
Table name String Name of the source table to be divided for multi-
threading. This parameter can be prepended with a
user ID other than that of the ID for the table to be
divided. For example, the item table could be
represented as scpomgr.item to run the DDU under
the scpomgr user ID.
Key name String The field upon which to divide the source table, which
typically a primary key field. The granularity of the
division will be greater if you divide on a primary key
field, because each row will have a unique value. The
source field must be of type VARCHAR2, NUMBER,
ROWID, or DATE.
Number of chunks Integer Typically the number of threads or parallel data flows.
The valid range is 2:1024.
Job ID String Identifies the results for each execution of the DDU. If
(Not required) the parameter is missing or a single blank value is
passed, the Table name value is used. On subsequent
executions, the DDU removes any existing results that
have the same ID (using a case-sensitive match).
Additional conditions String Provides conditions that filter rows in the source table.
(Not required) The text must be in correct SQL format, for example:
Item < '000120' AND Location = 'Atlanta'
Literal strings require two single quotes. Table names
can have prepended owner IDs.
Additional tables String Provides table names needed if additional conditions
(Not required) refer to other tables. Names should be comma
delimited. For example, "item, hist". Table names can
have prepended owner IDs.

When you select a Key name, it is best to use a field that has more distinct values than the number of
chunks specified. It is also preferable to select a field in which values are uniformly distributed. The
best choice would be a primary key field, because each value is unique.
The following command, executed from SQL*PLUS, calls the DDU, and divides the hist (history) table
on the dur (duration) field into two chunks, using ID "hist2_1" and no additional conditions or table
names:
exec ddu('hist', 'dur',2, 'hist2_1', '', '');
Review the DDU_RESULTS table

The DDU_RESULTS table is populated with the DDU stored procedure output. The returned string
values can be used in the where clause of a SELECT statement to chunk the incoming data from a
source table. For example:
SELECT * from <table_name> where Key >= Low_boundary AND Key < High_boundary
An additional condition, if used, can be concatenated to the SELECT statement as an additional

where clause.
The following table represents a typical results table:
Job ID Chunk_number Low_boundary High_boundary
Job1 1 ! Denver
Text representation of ASCII
chr(33).
Job1 2 Denver Rockville
Job1 3 Rockville
Text representation of ASCII
chr(254).
Job ID contains the string that you used for the ID parameter when executing the DDU, unless
you passed in a single blank, in which case the DDU uses the Table name value. If you keep the
same ID for the next execution, the new results replace the current results. If you assign a
different ID for the next execution, the new results are appended to the current results.
Note: The ID is case sensitive. If you provide no value for ID when executing the DDU, it provides
the Table name value as the ID. If you provide the same table name in a subsequent execution,
but type it in a different case, the results are appended as if it were a different job. For example,
"hist" and "Hist" are the same table name, but two distinct IDs.
Chunk_number is the sequential number of each defined chunk. In this example, the rows in the
source table were divided into three chunks.
High_boundary is a value in the field on which you perform the division (the field name assigned
to the Key name parameter). It is the highest value in that field within the defined chunk. For
example, if each chunk has thirty rows and row 30 contains the value Denver, then Denver
becomes the high boundary for the first chunk. The only exception is the high boundary of the last
chunk (see "Lowest and highest ASCII boundaries" (on page 135)).
Low_boundary is a value in the field on which you perform the division (the field name assigned
to the Key name parameter). The low boundary of a chunk always takes the value of the high
boundary in the chunk that precedes it. The only exception is the low boundary of the first chunk
(see "Lowest and highest ASCII boundaries" (on page 135)).

Lowest and highest ASCII boundaries

The low boundary for the first chunk using an ASCII value is set to chr(33), which is the lowest value
that is valid in Oracle. The high boundary for the last chunk is set to ASCII chr(254), which is the
highest value that is valid in Oracle (ASCII chr(255) has special meaning and cannot be used). This
setup ensures that boundary checks return the lowest and highest valid values in the table.
Lowest and highest Date boundaries

The low boundary for the first chunk using a DATE value is '1900-01-01-00:00' using the expression
TO_CHAR(TO_DATE('1900', 'YYYY')), which ensures correct NLS form. The high boundary value for
the last chunk is set to "3000-01-01-00:00". The year 3000 is considered a safe enough highest date
value.
Lowest and highest Number boundaries

The low boundary for the first chunk using a NUMBER value is -(1046) + 1. For fields of type NUMBER,
the highest value for the last chunk is the largest INTEGER value that PL/SQL allows for stored
procedures. (1048) - 1.
Lowest and highest RowID boundaries

The low boundary for the first chunk using a ROWID value is the lowest value in the table. The high
boundary value for the last chunk is set to a computed value that is greater than the highest value in
the table.
Divide on two tables with a different user ID

This example assumes a second table called MY_ITEMS.
Table: MY_ITEMS
Item UOM
Args EACH
Bdfhgb EACH
Cdfhb Pounds
Cz EACH
Ddfhb EACH
Dhf EACH
In the following SQL statement, User ID TEST calls the DDU to divide table MY_SKUS, which is
owned by User ID STSC, by using STSC.MY_SKUS. The SQL statement will divide a subset of the
MY_SKUS table, where the corresponding MY_ITEMS.UOM column has a value of EACH.
Exec ddu('STSC.MY_SKUS', 'MY_ITEMS.UOM', 2, 'Id1', 'MY_SKUS.ITEM = MY_ITEMS.ITEM AND

MY_ITEMS.UOM = ''EACH'', 'STSC.MY_ITEMS');
Table: DDU_RESULTS
Id1 1 ! Denver

Id1 2 Denver
Queries using DDU_RESULTS values

The following queries could be created using the values in the DDU_RESULTS table. Notice that the
additional where clause is used.
Select * from STSC.MY_SKUS, STSC.MY_ITEMS where LOCATION >= '! ' and LOCATION <
'Denver' and MY_SKUS.Item = MY_ITEMS.Item and MY_ITEMS.UOM = 'EACH';
Select * from STSC.MY_SKUS, STSC.MY_ITEMS where LOCATION >= 'Denver' and LOCATION <=
'' and MY_SKUS.Item = MY_ITEMS.Item and MY_ITEMS.UOM = 'EACH';
Use an NLS_COMP setting other than BINARY

As explained above, if you have an NLS_COMP setting other than BINARY, the DDU stored procedure
will temporarily change the sort setting to BINARY during execution. This means that you must use a
BINARY sort when retrieving data using the DDU boundary values. You can specify BINARY sort within
the scope of the SELECT statement using the Oracle NLSSORT function. For example, following is the
first SELECT statement from the previous example, modified to use the NLSSORT function:
Select * from STSC.MY_SKUS where NLSSORT(LOCATION, 'NLS_SORT=BINARY') > NLSSORT('! ',

'NLS_SORT=BINARY') and NLSSORT(LOCATION, 'NLS_SORT=BINARY')<= NLSSORT('Denver',
'NLS_SORT=BINARY');
Optionally, you could do one of the following:
Temporarily set the NLS_COMP environment variable to BINARY, then issue the original SELECT
statement.
In SQL*PLUS, use the command,

ALTER SESSION set NLS_COMP=BINARY
then issue the original SELECT statement.
Multi-byte language support

The DDU supports multi-byte languages. However, in order for the DDU to work efficiently, it must use
a BINARY Oracle sort when ordering the input table for division. An Oracle BINARY sort compares the
binary values of each byte in the two strings. This guarantees that chr(254) is greater than any multi-
byte characters, because the first byte of unicode characters is always less than 254.
If you have multi-byte data and use an NLS_SORT setting other than BINARY, the DDU uses the ALTER
SESSION command to temporarily set NLS_SORT to BINARY during execution. As a result, you will
have to use BINARY sort order when using the DDU_RESULTS values in SELECT statements.
DDU examples
This section contains examples of tables, results, and select statements that demonstrate methods of
using the Data Division Utility.

Divide a table into two chunks

Table: MY_SKUS
Item Number Location
Args 222 Atlanta
Bdfhgb 333 Denver
Cdfhb 444 New York
Cz 555 Philadelphia
Ddfhb 777 Seattle
Dhf 888 Tokyo
After dividing MY_SKUS in two chunks using Key=Location, the following results are returned:
Table: DDU_RESULTS
Id1 1 ! New York
Id1 2 New York
Queries using DDU_RESULTS values

The following queries could be created using the values in the DDU_RESULTS table:
Select * from MY_SKUS where LOCATION >='! ' and LOCATION < 'New York';
Select * from MY_SKUS where LOCATION >= 'New York' and LOCATION < ''
Queries using DDU_RESULTS table

SQL statements can be written to query the results table simultaneously, as follows:
Select * from MY_SKUS, DDU_RESULTS where DDU_RESULTS.CHUNK_NUMBER = 1 and

DDU_RESULTS.ID='Id1' and MY_SKUS.LOCATION >= DDU_RESULTS.LOW_BOUNDARY and
MY_SKUS.LOCATION < DDU_RESULTS.HIGH_BOUNDARY;
Select * from MY_SKUS, DDU_RESULTS where DDU_RESULTS.CHUNK_NUMBER = 2 and

DDU_RESULTS.ID='Id1' and MY_SKUS.LOCATION >= DDU_RESULTS.LOW_BOUNDARY and
MY_SKUS.LOCATION < DDU_RESULTS.HIGH_BOUNDARY;
Security
Security for the DDU is not provided for by Security Manager. Since the DDU is implemented as an
Oracle stored procedure, it utilizes standard Oracle security. Specifically:
The DDU can only be executed by the Oracle User ID that is used to create the stored procedure
and results table. This is the user that is passed to the ddu_init shell script.
The Oracle User ID that executes the DDU stored procedure must have Select privileges on the
target tables.

The Oracle User ID that executes the DDU stored procedure must have been granted the
SELECT_CATALOG_ROLE.
Generate a credential file

This utility generates a credential file that is used for batch authentication and other utilities used at
the command line. This file includes user name and an encrypted password. You must provide the
credentials file name as an input parameter.

following:
genCredentials <filename>
For example:
<install Dir>\config\bin\platform>genCredentials credentials.properties

Enter the User ID:
Enter the password to encrypt:
Enter the password again for confirmation:
Configure the JDA Platform Configuration files

After you install JDA Platform, you can change many of the configuration parameters. Some
parameters are set during installation while many others have default values. These parameters affect
the JDA Platform Server, but they are not specific to any single JDA application. Generally, you can
change the configuration parameters before or after you install JDA Platform-based applications. For
detailed information on application-specific settings, see the Installation/Administration Guide for that
application.
JDA Platform technical integration points

The JDA Platform architecture provides technical integration points to configure your environment. The
integration points enable you to quickly configure JDA Platform with external software components.
This guide contains detailed documentation on the following integration points:
Lightweight Data Access Protocol (LDAP) for external authentication. See Use LDAP with JDA
Platform (on page 157).
Secure sockets layer (SSL), See "Use secure sockets layer" (on page 165).
Front-end Web Server, which is a WebLogic plug-in. See "Configure the Web Server plug-in" (on
page 106).
*Note specific to Windows server 2008: Across the guide and specifically in this chapter, there are
a number of instructions on running JDA Platform batch utilities on the servers command prompt.
These programs must be run as Administrator to complete the intended operations successfully.
Server configuration files

During installation, the software automatically configures several files necessary to start and run the
JDA Platform Server. In most cases, you can edit files after installation. You should back up
configuration files before modifying them. See the following table for a list of configuration files.
IMPORTANT: Do not edit the active configuration files while the server is running. Changes may be
lost.

JDA Platform Server configuration files

Installed file Directory Description
installerVars \config Contains variables related to the installation such as
database and connection information, as well as
parameters that can be configured for your
installation (such as application server memory).
cluster.properties \config\bin\platform WebLogic only: Used for cluster configuration.
Configure with the static IP addresses and port
numbers if using a cluster.
config.xml \config WebLogic only: Contains port numbers, database
\JDADomain\config connection information for Oracle. The JDA Platform
Server uses config.xml when it starts.
Note: If you install JDA Platform-based applications
after editing config.xml, your changes are lost
because the system overwrites them with the
original data stored in include files.
csmImport \config\bin\platform Used for batch import of CSM objects. For details,
see "Use the csmImport utility" (on page 159)
Note: Back up this file before editing it.
dbconnections.properties \config\properties Stores database connections for JDA Platform and

other Foundation-based applications configured
during installation. Generally, you should not
change this file unless you change the database
source.
The service runtime environment uses the values in
this file to establish database connections.
IGPProperty.properties \config\properties Used with Interface Generation Program (IGP) for
importing data for some Foundation-based
applications.
The system creates this file based on include files in
directory <install_dir>\install. Each time you
install a JDA Platform-based application, the system
re-creates IGPProperty.properties using include
files.
startWebworksServer \config\bin\platform Starts the JDA Platform Server. Contains settings
for several variables, including WEBWORKS_HOME,
JAVA_OPTIONS, LOC_ROOT, and CLASSPATHs. The
server does not start if these references are
incorrect.
This file also calls
startWebworksServer.includes in the same
directory. Each time you install a JDA Platform-
based application, it may write information to the
includes file. You should not change the includes
file.
IMPORTANT: Back up this file before you edit it.

Installed file Directory Description

startNodePoolMan \config\bin\platform Starts a Node Pool Manager in service runtime
ager environment.
This file also calls startNodePoolManager.includes in
the same directory. Some JDA Platform-based
applications write to the includes file. You should
not change the includes file.
IMPORTANT: Back up this file before editing it.
shutdownWebworksServer \config\bin\platform Shuts down the JDA Platform Server.
webworks.common.vars \config A common environment file that is sourced in most

JDA scripts. This file sources the installerVars script,
which contains environment variables set during
installation.
webworks_config.xml \config\properties Contains local parameters for JDA Platform Server.
The file must be properly configured for the server
to start.
Include files
The system uses include files to build several server configuration files. JDA Platform and each JDA
Platform-based application installs include files in directory <install_dir>\install. During the
installation, the system concatenates the include files and builds server configuration files. Examples of
configuration files are:
dbconnections.properties
gensys_help_configuration.xml (A help system file.)
IGPProperty.properties
Include files contain original information entered during installation. JDA Platform and each JDA
Platform-based application place include files in directory <install_dir>\install. Many include files
have a .header or .footer suffix.
When you install a JDA Platform-based application, the system re-creates server configuration files
using the include files in directory <install_dir>\install.
If you edit server configuration files before you install JDA Platform-based applications, the system
overwrites your changes with the original information in the include files.
If you edit include files after you install JDA Platform-based applications, use the utility
BuildConfiguration to rebuild the server configuration files. See "Regenerate configuration and
startup files" (on page 148).
XML files
Back up XML files (and other files) before you edit them. You can restore the original file if your
changes corrupt the file. XML files must be well-formed and valid. Otherwise, the system cannot
process them. Be careful to edit the values in XML files. Generally, you should not change the elements
and attributes.
If you edit local properties in the webworks_config.xml using a text or XML editor, observe the
following rules:
Edit only the value for the element.

Do not change the values for other elements.
Do not add or remove elements unless specifically instructed to do so.
You must restart the JDA Platform Server after changing the value.
Update server configuration

If you did not enter values into many of the fields during installation, or if you want to change your
settings at a later time, you may need to update the server configuration. The server also has utilities
for maintenance.
Use a Web Server tier

You can configure your architecture with an optional Web Server tier, sometimes called a "front end."
The Web Server is a tier between clients using browsers and WebLogic. The Web Server tier uses a
WebLogic plug-in and interfaces directly with WebLogic. The Web Server can be used in a cluster
configuration or with a single JDA Platform Server.
Examples of Web Servers are Sun Java System, Microsoft IIS, Netscape Enterprise Server, and Apache
HTTP. To install supported Web Servers, see the WebLogic documentation on the Oracle website. For
an example of configuring a Web Server, see "Configure a cluster on WebLogic" (on page 101).
IMPORTANT: JDA applications use and reserve the HTTP session cookie called JDA_JSESSIONID.
When using a Web Server tier as a front-end to the JDA Platform Server in a cluster or non-clustered
environment, the cookie name must be specified in the Web Servers configuration file.
Change the JDA Platform Server listen port for WebLogic

During installation, you assign the port number that the server listens on, for example, 7001. The new
port number must not be used by another process or else the server fails. You must shut down and
restart the JDA Platform Server for the new port assignment to take effect.
IMPORTANT: Do not edit config.xml while the server is running. Changes will be lost.
1. Open the Weblogic console by using the hyperlink http://<server name>:<port>/console. The
Weblogic Server Administration Console log in page is displayed.
2. Enter the admin username and password and click Log in. The default values are
weblogic/weblogic1.
4. Modify the listen ports, Click Save, and then Activate Changes.
5. Shut down the JDA Platform Server.
6. Using a text or XML editor, open file webworks_config.xml in directory

<install_dir>\config\properties. You must change the port number in two locations in this file.
a. Find the following element and change the port number:

Note: Even when using SSL, use http for this property.
b. Find the following element and change the port number:

<configProperty name="port">
<value>7001</value>

c. Save webworks_config.xml and exit the editor.
7. Start the JDA Platform Server and connect using the new port.
Change the JDA Admin Server listen port for WebLogic

During installation, you assign the port number that the server listens on, for example, 7003. The new
port number must not be used by another process or else the server fails. You must shut down and
restart the JDA Admin Server for the new port assignment to take effect.
IMPORTANT: Do not edit config.xml while the server is running. Changes will be lost.
weblogic/weblogic1.
4. Modify admin server listen ports, Click Save, and then Activate Changes.
5. Shut down the JDA Admin Server.
6. Using a text or XML editor, open file createJDADomain.py in directory <install_dir>\

config\weblogic\setup. You must change the port number in two locations in this file.
a. Find the following element and change the port number:

cd('Servers/AdminServer')
set('ListenAddress', ' Server Host name')
set('ListenPort', 7003)
b. Find the following element and change the port number:

t3AdminURL = "t3://<Server Host name>:7003"
c. Save createJDADomain.py and exit the editor.
7. Start the JDA Admin Server and connect using the new port.
Change the JDA Platform Server listen port for WebSphere

During installation, you assign the port number that the server listens on, for example, 7001. You can
change the port assignment by editing Serverindex.xml. The new port number must not be used by
another process or else the server fails. You must shut down and restart the JDA Platform Server for
the new port assignment to take effect.
2. Using a text or XML editor, open the file serverindex.xml file located in directory
\was61\AppServer\profiles\<yourProfileName>\config\cells\<cell
name>\nodes\<nodeName>.
a. Find the serverEntries tag for your server:
locate the SpecialEndPoints tag defaulthost tag. For example:

<specialEndpoints xmi:id="NamedEndPoint_1137500760154"
endPointName="WC_defaulthost">
In the subsequent endpoint tag set the port number. For example:
<endPoint xmi:id="EndPoint_1137500760154" host="*" port="8001"/>

b. Save the file and exit the editor.
3. Using a text or XML editor, open the file virtualhosts.xml in the directory
\was61\AppServer\profiles\<yourProfileName>\config\cells\<cell name>
a. Locate the port numbers and modify them to the new values. For example:
<aliases xmi:id="HostAlias_1179829400619" hostname="*" port="8001"/>
<aliases xmi:id="HostAlias_1179829400697" hostname="*" port="8002"/>
b. Save the file and exit the editor.
Java virtual machine tuning parameters

A Java virtual machine (JVM) is an abstract machine that supports the Java programming language.
One important tuning parameter for the JVM is the Heap Size. The JVM Heap Size is a reserved amount
of memory used for allocating Java objects during runtime. If the minimum or maximum Heap Size is
incorrectly set for your environment, it could degrade performance or prevent the server from running
at all.
Change the Heap Size parameters on Weblogic platform

2. Using a text editor, open the installerVars file located in the <install_dir>\config directory.
3. Update the following variables as required:
JVM_SERVER_MEM_ARGS="-Xms256M Xmx768M"
JVM_BATCH_MEM_ARGS="-Xms32M -Xmx64M"
JVM_MAX_PERM_SIZE="-XX:MaxPermSize=256m"
where ms denotes the minimum Heap Size and mx denotes the maximum Heap Size, both
expressed in megabytes.
4. Enter the new minimum and maximum values for the Heap Size. Make the minimum value equal to
or less than the maximum. For example, to set the application server minimum to 1024 MB and
maximum to 2048 MB on UNIX, enter:
JVM_SERVER_MEM_ARGS="-Xms1024M -Xmx2048M"
The JVM_BATCH_MEM_ARGS are used to set the memory for batch scripts. The
JVM_MAX_PERM_SIZE also affects the application server and may need to be adjusted based on
your implementation.
5. Save the installerVars file and exit the editor.
Note: If you have configured a Windows service, you must re-create the service after changing the
memory parameters.
Change the Heap Size parameters on IBM WebSphere platform

This information is set to a default value during installation and is configured in the server.xml file. To
modify the min or max parameters edit the jvmentries node in the server.xml file. The file is located
in the folder \<was_home>\AppServer\profiles\<yourProfileName>\config\cells\<cell
name>\nodes\<nodeName>\servers\WebWORKS\

Update application server database connection information

During installation, you must specify information that the server uses to connect to the database.
When the JDA Platform Server starts, it establishes the Java Database Connect (JDBC) pool for the JDA
Platform and Monitor (if installed) database. JDA Platform uses the CSM_ConnectionPool and JDA
Monitor uses the EMA_ConnectionPool. Depending on the parameters entered during installation,
these connection pools could point to the same or different database users in the same database. The
following sections provide you information on modifying the JDBC pool information for WebLogic and
WebSphere respectively.
Update database connection information on Weblogic

During installation, you must specify information that the JDA Platform Server uses to connect to the
database. When the server starts, it establishes the Java Database Connectivity (JDBC) pools for the
database. Depending on the number of JDA Platform-based applications installed, you may have
multiple connection pools stored in files jda-jdbc.xml and jda-<appname>-jdbc.xml files in the
directory <jda_install>/config/JDADomain/config/jdbc.
You can modify the Connection Pools using the WebLogic admin console, or you can manually edit the
JDBC configuration files. If using the WebLogic admin console, do not shut down the server. You can
access the console using the url http://<server_name>:<port>/console. Enter your weblogic
admin username and password. The default credentials are weblogic/weblogic1.
Note: If you run the configureJDAServer utility, the system overwrites your changes in jda-
jdbc.xml with the original information entered during installation.
To modify the JDBC information manually using an XML or text editor:
2. Change to directory <install_dir>\config\JDADomain\config\jdbc.
3. Using a text or XML editor, open the file jda-jdbc.xml.
4. Edit only the attribute values, which are displayed in bold in the following sample jda-jdbc.xml for
the Oracle Thin driver.
<?xml version="1.0" encoding="UTF-8"?>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source">
<name>CSM_ConnectionPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@//jdasrv:1521/NWSAMPLE</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>WWFMGR</value>
</property>
</properties>
<password-encrypted>{AES} ush7gumVvfZBwdL01g/RV+ZnyPqxLpm135CSEeEpaWk=
password-encrypted>
</jdbc-driver-params>

<jdbc-connection-pool-params>
<initial-capacity>5</initial-capacity>
<max-capacity>30</max-capacity>
<capacity-increment>5</capacity-increment>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbc/CSM_ConnectionPool</jndi-name>
<global-transactions-protocol>OnePhaseCommit</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>
In this file wwfmgr is the Oracle user ID, jdasrv is the server, 1521 is the Oracle listen port, and
NWSAMPLE is the Oracle SID. Notice that the Oracle password entered during installation is now
encrypted. If you need to change the Oracle password, use the encryptBeaPassword utility to
generate the password. Paste the password string generated in to the jda-jdbc.xml file.
5. Save jda-jdbc.xml and exit the editor.
If you are modifying the Oracle service name, port, or username, make sure that you also update
the dbconnections.properties file in the <install_dir>\config\properties folder. If updating the
password, use the changeDBCredentials utility to update the password across all JDA Platform
files. See for Change schema password (on page 217) more information.
Each JDBC connection pool in jda-<appname>-jdbc.xml has several parameters, including the server
name or IP address, Oracle service name, listen port, user ID, and password. See "Troubleshoot
problems with connection pools" (on page 267).
Update database connection information on IBM WebSphere

During installation, you must specify information that the JDA Platform Server uses to connect to the
database. When the server starts, it establishes the Java Database Connectivity (JDBC) pools for the
database. Depending on the number of JDA Platform-based applications installed, you may have
multiple connection pools stored in files resources.xml file in the folder The file is located in the folder
<was_install>\AppServer\profiles\<yourProfileName>\config\cells\<cell
name>\nodes\<nodeName>\servers\WebWORKS\. Shut down the JDA Platform Server before
editing the JDBC properties in the resources.xml file.
Each JDBC connection pool in resources.xml has several parameters, including the server name or IP
address, Oracle system identifier (SID), listen port, user ID, and password. See "Troubleshoot
problems with connection pools" (on page 267). Before editing connection pools, you should have a
working knowledge of XML.
2. Change to directory <was_install>\AppServer\profiles\<yourProfileName>\config\cells\<cell

name>\nodes\<nodeName>\servers\WebWORKS\.
3. Using a text or XML editor, open the file resources.xml.

4. Search for the tag that has the JNDI name set to your pool's JNDI name. This tag may be
displayed more than once if you have many JDA applications installed. Each tag has a Name
attribute that uniquely identifies the connection pool. For example, <factories
xmi:type="resources.jdbc:DataSource" xmi:id="DataSource_1137729389098"
name="CSM_ConnectionPool" jndiName="CSM_ConnectionPool" description="New JDBC
Datasource" providerType="Oracle JDBC Driver" authDataAlias="csm_login_WebWORKS"
relationalResourceAdapter="builtin_rra" statementCacheSize="10"
datasourceHelperClassname="com.ibm.websphere.rsadapter.Oracle12cDataStoreHelper">
5. Modify the DB URL (Host, SID, and Port values) in this block. For example: <resourceProperties
xmi:id="J2EEResourceProperty_1137500777626" name="URL" type="java.lang.String"
value="jdbc:oracle:thin:@server1:1521:utf812c2" description="This is a required
property. The URL indicating the database from which the Data Source will obtain
connections, such as 'jdbc:oracle:thin:@localhost:1521:sample' for thin driver and
'jdbc:oracle:oci8:@sample' for thick driver." required="true"/>
Note: The databasepassword is not stored in this file and cannot be changed directly. Use the
changeDBCredentials script under the bin/platform directory or the WebSphere console to change
the database password for WebSphere. See the comments section of the file for additional information.
If you are modifying the Oracle service name, port, or username, make sure that you also update the
dbconnections.properties file in the <install_dir>\config\properties folder. See for Change schema
password (on page 217) more information.
Log files
All log files are located in the <install_dir>\config\logs directory.
appserver.log: Use this file to analyze server activity of your JDA Platform applications. By
default, the maximum size of this file is 10MB. However, you can configure the size of the log file.
This file rolls over to a new file when the maximum size is reached and the old log file is zipped
and placed in the directory <install_dir>\config\logs\appserver. For example: appserver-09-
25-2013-1.log.gz.
Post_install_<application>.log: Information on postinstallation options that were chosen

during installation of the application.
Configure<application>.log or <application>_configure.log: Information from configuration

activities during installation. Each application writes their own configuration file during installation
(for example, collaborate_configure.log, platform_configure.log,
configureABPP.invopt.log).
Log files from the SSO server that supports single-sign on are created in the directory
<install_dir>\cis\cis-sdk\logs:
Note: When the CIS and SSO servers are configured as Windows services, logs are generated in the
<install_dir>\cis\NTServiceScripts directory.
sso.log: Logs from the CIS SSO server process.
CISAgent.log: Logs from the CIS Agent.
In addition, the JDA Platform application creates the following log files for the different utilities in the
folder <install_dir>\config\logs\directory:
pingWebworksServer.cmd: Creates the pingWebworksServer.log files
shutdownNodePoolManager.cmd: Creates the shutdownNodePoolManager.log file
NWProcessBusinessRule.cmd: Creates the NWProcessBusinessRule.log file

NWReloadServer.cmd: Creates the NWReloadServer.log file
NWWakeBackgroundProcess.cmd: Creates the NWWakeBackgroundProcess.log file
importAuditSubscription.cmd: Creates the importAuditSubscription.log file
exportAuditSubscription.cmd: Creates the exportAuditSubscription.log file
publishEvent.cmd: Creates the publishEvent.log file
SREBatchUtility.cmd: Creates the SREBatchUtility.log file
Igp.cmd: Creates the Igp.log file
Based on the profile of the installation, you can find the additional log files in the directory
<install_dir>\config\bin\<application> or <install_dir>\<application>\logs.
The log files are located for as follows:
Weblogic: <install location>\config\logs
Websphere: <Install
location>\AppServer\profiles\<profileName>\logs\<application_name>
Map locales and browser encodings

Some JDA Platform-based applications allow users to upload files to and download files from the
server. To support internationalization, the JDA Platform Server encodes the file based on the users
locale. When the user downloads a file, the JDA Platform Server encodes the file based on the users
locale. If the locale cannot be matched, the language code is used. If the language cannot be matched,
UTF-8 is used. For uploading files, the JDA Platform Server matches the users locale to read the file.
On the server, you can map the locales to browser encodings in the configuration file System
Properties. The properties are stored in file webworks_config.xml. You must also map each browser
encoding to a java encoding.
1. Open System Properties.
2. Select WebWORKS for the application. The webworks_config.xml is displayed.
3. Select Servlet Framework Browser Encoding from the Properties drop-down list.
4. Enter values for the properties.
5. Click Save.
Configure your corporate firewall

After you install the JDA applications, you may need to update your Internet configuration for your
corporate firewall. To enable communication between the client and server over the Internet, you must
configure the corporate firewall to enable the Weblogic server port configured during installation. If you
are using a web server other than WebLogic, you must configure the firewall to allow the JDA Platform
Server port through the firewall.
In addition, you must configure your firewall to enable one of the supported protocols on the Weblogic
server's port:
t3 (standard). Standard requires your firewall to allow TCP/IP access to the Weblogic server's port.

t3s (secure). These protocols require your firewall to allow TCP/IP access to the Weblogic server's
port. If you are using the SSL protocol, you need to review the WebLogic documentation for
information on obtaining and configuring permanent SSL certificates. When obtaining permanent
certificates, you must install them to the directory <install_dir>\config\JDADomain.
If you choose to change the server's port or the client-to-server protocol, you must change several
files to reflect the port and protocol choices you have made. See "Change the JDA Platform Server
listen port for WebLogic (on page 141)" and "Use secure sockets layer" (on page 165) for information
on making these changes.
If you want users to access JDA applications via a browser without entering the port number (for
example, www.jdaserv.com instead of www.jdasrv.com:7001), you can configure WebLogic to run
through port 80. To enable this on UNIX, you must set certain WebLogic properties. See WebLogic
documentation for information on performing this task.
Regenerate configuration and startup files

When installing JDA Platform and JDA Platform-based products, the installations automatically create
several configuration files, including:
application.xml
csmImport
dbconnections.properties
gensys_help_configuration.xml (A help system file.)
IGPProperty.properties
As an illustration, file application.xml must be present and correctly configured for the JDA Platform
Server to start and for JDA applications to run. Each configuration file is built from include files stored
in directory <install_dir>\install. These files contain original information entered during installation.
Installing a JDA application or running utility BuildConfiguration uses the include files to regenerate
the configuration files. File application.xml.footer is an example of an include file used to build
application.xml. The JDA Platform Server does not use the include files at runtime.
application.xml include files Process Output file
application.xml.header
BuildConfiguration
application.xml.body.bea application.xml
or
application.xml.body.scpoweb.demand ConfigureJDAServer
application.xml.footer
...
Generally, you must regenerate server configuration files if they were deleted, corrupted, or if you
made changes to the include files. When you run the BuildConfiguration utility, it overwrites the
configuration files using information in the include files located in directory <install_dir>\install. (See
"Include files" (on page 140).) These include files contain the original parameters set during
installation for all installed JDA products.
If you have made post-installation configuration changes to the server configuration files and you want
to retain those settings, two options are available:
apply those same changes to the specific include files in directory <install_dir>\install before
running BuildConfiguration

apply the changes to configuration files after running BuildConfiguration.
To regenerate server configuration files using BuildConfiguration:
3. Navigate to directory <install_dir>\config\bin\platform.
4. Run BuildConfiguration by entering:

BuildConfiguration
The console displays a series of messages similar to these:
The console also displays messages based on the applications installed. For example:
The process returns a command prompt when completed.
Configure JDA SSO service timeout

The configuration of the SSO service timeout can be done by editing the server's metadata file,
SessionCoordinatorBinding.xml, which is in the <install_dir>/cis-sdk/xml directory.
1. Open the SessionCoordinator.xml file in a text editor and search in <portType

name="webSessionCoordinator">. The following property is displayed::
<property name="sessionTimeoutMins" value="30"/>
Notes:
If the CIS SSO type is database then use the SessionCoordinatorDB.xml file.
If the CIS SSO type is memory then use SessionCoordinator.xml file.
2. Set the property sessionTimeoutMins to the desired timeout value (in minutes).
For example, to set the timeout to 60 minutes:

<property name="enableSessionCoordination" value="true"/><property
name="sessionTimeoutMins" value="60"/>
3. Restart the SSO server. After 60 minutes, you are automatically logged out of the session. You can
configure the session timeout to a suitable value for the implementation.
Note: Users can pass the following additional parameter to the SSO adapter through JVMargument:
com.i2.cis.HttpTimeout: This is the timeout value of all HTTP post requests. The default
value is 10000 ms.
com.i2.cis.AsyncHttp: This is the Boolean value flag that controls the way the HTTP post
requests are sent. The default value is false. When set to true, all HTTP post request are sent
asynchronously.
Control user access

This chapter provides reference information and procedures to control user access to the JDA Platform
Server and JDA Platform-based applications.

JDA Platform components provide security features to control access to JDA Platform-based
applications. These applications should be integrated into an organizations comprehensive security
program. After assessing security requirements, system administrators should consider additional
security measures such as firewalls, web access control servers, Secure Sockets Layer (SSL), and
other measures.
Configure and enable external authentication

There are multiple supported methods for configuring external authentication:
1. Using a generic external authentication tool, such as SiteMinder to pass an http header. Based on
the presence of the header, JDA will pass through the user to the JDA application.
2. Using the PingFederate tool
3. Using any SAML-based identity provider
4. Using LDAP
Configure external authentication with an HTTP header

Following are the steps to configure external authentication with a generic HTTP header:
1. Change to <install_dir>/config/properties directory.
2. Using a text or XML editor, open the file webworks_jaas.config and modify the
userNameHTTPHeader attribute of the HTTPHeaderLoginModule section to reflect the chosen
HTTP header name used by the secure proxy server to identify a user.
Note: The userNameHTTPHeader name is case sensitive, so you need to put proper case in the
webworks_jaas_config file.
Example: If the user is IV_USER, userNameHTTPHeader cannot be updated as iv-user.

HTTPHeaderLoginModule
{
com.i2.x2.util.cis.ExternalHTTPHeaderLoginModule required
userNameHTTPHeader="SM_USER";
};
3. Using a text or XML editor, open the file abpp.properties to switch the SSOLoginModule from
ABPPLoginModule to HTTPHeaderLoginModule.
4. Restart the CIS agent, SSO server and application server processes.
Notes:
There may be further configuration needed on the secure proxy server in order to properly
forward the web traffic.
Platform batch clients are authenticated against the Platform application server using either
the Platform database user store or LDAP, depending on the configuration.
Configure external authentication with PingFederate

Update the abpp.properties file to support PingFederate
1. Open the abpp.properties file in a text editor from the <install_dir>\config\properties.

2. Update the properties file with the following details:

SSOLoginModule=PingFederateLoginModule
shell.failed-validation.url= provide the url (example: http://www.jda.com)
shell.post-logout.url= provide the url (example: http://www.google.com)
Update webworks_jaas.config file to support PingFederate

1. Open the webworks_jaas.config file in a text editor from the <install_dir>\config\properties.
2. Update the PingFederateLoginModule section with the PingFederate configuration details.
For Example:
refIdParameterName ="REF"
refIdPickupURL="<PingFederate_Federation_Info_Base_URL>/ext/ref/pickup"
Note: The PingFederate Base URL should be an SSL URL.
refIdInstanceId="<SP_adaptor_instance_Id>"
refIdUsername="<SP_adaptor_username>"
refIdPassword="<SP_adaptor_password>"
Note: The value should be encrypted using GenPasswordHash.
refIdSubject="subject"
3. Restart the application server, CISAgent and SSOServer.
Verify PingFederate Setup

1. Access the URL
https://<PingFederateServerHostname>:9031/idp/startSSO.ping?PartnerSpId=JDA-SP.
2. Enter the required values in the Username and Password fields, and click Login.
3. Verify the JDA application Home Page.
Configure external authentication with SAML

This section provides the procedures to configure Security Assertion Markup Language (SAML) for
external authentication.
SAML uses security tokens that contain assertions to pass information about a principal (usually an end
user) between a SAML authority (that is, an identity provider), and a SAML consumer (that is, a
service provider). This is a standard protocol for communication between Identity provider (IdP) and
Service provider (SP) to resolve the queries related to authentication of users across multiple domains.
Components of SAML
Identity provider: An Identity Provider (IdP), sometimes called an Identity Service Provider or
Identity Assertion Provider, is an online service that authenticates users by means of security
tokens, one of which is SAML 2.0.
Service provider: A Service Provider (SP) is an entity (in this case the JDA application) that relies
on a trusted IdP for authentication and authorization. The SP depends on receiving assertions from
a SAML authority or asserting party, which is a SAML IdP.

Agent: Agent is an entity that requests a web resource protected by a SAML SP. Also, the SP
wants to know the identity of the requesting user, issues, and an authentication request to an IdP
through agent. For example, browser, mobile, and so on. The default value is browser.
SAML allows SPs to have a single sign on integrating with the same IdP in the context of Platform.
Platform supports SP initiated and IdP initiated login and logout.
The SAML profiles supported by JDA Platform are:
Web Browser SSO
Single Logout
The SAML bindings supported by JDA Platform are:
HTTP POST
HTTP Artifact
Note: In case of HttpArtifact binding, login is not supported if PingFederate is used as the IdP and
WebSphere as application server, because WebSphere does not support the encryption algorithm used
by PingFederate.
Authentication flow

Configure SAML properties

SAML authentication is not enabled in JDA Platform by default. Perform the following steps to configure
SAML:
Step Description Reference

1. Export the IdP metadata. For more information, see the
corresponding IdP's documentation.
2. Insert the exported IdP metadata in the end of the To make the IDP metadata file
following content: complete as per the SAML standard,
<?xml version="1.0" encoding="UTF-8" you need to create an xml with the
standalone="no"?> template given and insert the
<EntitiesDescriptor exported IdP metadata as
Name="https://platform.jda.com/metadata/ mentioned.
federation-name.xml" This file will be referred in
xmlns="urn:oasis:names:tc:SAML:2.0:metadata" saml_sp_configuration_templat
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" e.xml as a parameter.
xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">

</EntitiesDescriptor>
3. Configure the SP metadata template. For more information, see the

Configure SP metadata section.
4. Create an SP connection for the Platform SP using the
-
modified SP metadata file in IdP.
5. Review the connection in IdP. -
6. Open the saml_sp_configuration_template.xml file For more information, see the
In the <install_dir>\config\properties directory and Configure the SP configuration file
provide the information specific to the configuration. section.
7. Configure the JVM parameters in the JVM parameters:

startManagedWebworksServer file available in the
<install_dir>\config\bin\platform directory. -DsamlConfigFile: Specifies the
SP configuration file placed in the
Platform installation directory.
-DenableSaml: Specifies the flag

value as true to enable SAML.

Step Description Reference

8. Configure the parameters in the abpp.properties file. The parameters in the
abpp.properties file:
SSOLoginModule: Set the SAML

login module value to
SamlLoginModule.
BatchSSOLoginModule: Set the

batch Login module to
ABPPLoginModule, which will be
used by batch utilities.
shell.failed-validation.url:
Configure the URL to be re-
directed if the login is failed.
shell.post-logout.url: Configure
the URL with the following value
"/cas?samlAction=samlSpLogout".
Configure IdP metadata

All IdPs are bound to provide the IdP metadata file, which is usually exported from IdP. It must be
used to provide values that have to be used in the SAML implementation. For interaction with the IdP,
any SP requires certain values related to protocol, binding, and location to enable the communication.
Configure SP metadata
For any application to be an SP and for any configured IdP, there must be an SP metadata file that
holds the various configurable values, which are required to interact with IdP.
Attributes in the SP metadata file:
<EntityDescriptor entityID="platformSpxxxxxxxxxx">: Specifies the identifier for the IdP to

recognize the SP with this value.
<SPSSODescriptor AuthnRequestsSigned="false|true">: Determines if the authentication requests

sent to the IdP is signed with the private key.
<SPSSODescriptor WantAssertionsSigned="false|true">: Determines if the query or assertions

received from the IdP must be signed with the key.
<KeyDescriptor use="signing"><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

<X509Data><X509Certificate>: Specifies the value of the certificate used to encrypt or decrypt
the data sent to or received from IdP.
Note: To generate certificate text to be placed in the <X509Data> tag, see the Generate
Certificate text section.
<ArtifactResolutionServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">: Stores the

binding value used by the IdP while sending the response for artifact resolution.
<ArtifactResolutionService Location="" />: Stores the URL value accessed by IdP while sending
the response for artifact resolution.

<SingleLogoutServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">: Stores the

binding value used by IdP while initiating logout requests.
<SingleLogoutService Location="" />: Stores the URL value accessed by IdP while initiating logout
requests.
<AssertionConsumerService isDefault="true" />: Determines if this is the default service to be

used by the IdP to respond to the requests by SP.
<AssertionConsumerService Binding=" " />: Stores the value of the binding based on which this
service is used for response.
<AssertionConsumerService Location=" " />: Stores the value of the URL called upon for sending
the response for the specified binding type.
For Example:
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="http://Hostname:port/jda/shell/cas">
<SPSSODescriptor
AuthnRequestsSigned="false"
WantAssertionsSigned="false"
protocolSupportEnumeration=
"urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>

</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleLogoutService Location="http://Hostname:port/jda/shell/cas"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</NameIDFormat>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:transient

</NameIDFormat>
<AssertionConsumerService
isDefault="true"
index="0"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://Hostname:port/jda/shell/cas"/>
<AssertionConsumerService
index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="http://Hostname:port/jda/shell/cas"/>
</SPSSODescriptor>
</EntityDescriptor>
Generate Certificate text

Use the generateSamlCertificateText.bat (or .sh) script to generate the certificate text configured
in the SP Metadata.
Command Usage:
generateSamlCertificateText (filename) (KeyStore(JKS File))
(KeyStore Password) (Alias Name)
filename: Name of the file to be generated with the certificate text.
KeyStore (JKS File): Name of the configured key store file.
KeyStore Password: Password of the configured key store file.
Alias Name: Alias name of the key store.
For example:
generateSamlCertificateText Generatedfile.txt Keystorefile.jks

mypassword myalias
Configure the SP configuration file

In the directory <install_dir>\config\properties, open the saml_sp_configuration_template.xml
file and edit the following attributes.
<idpMetaDataFileName>: Path of the IdP metadata file that is exported from IdP.
<idpEntityId>: Unique identifier of the IdP used during the IdP configuration.
<acs>: Assertion consumer service URL, which is the identification of the SP.
</issuer>: Application configured to interact with the IdP as SP.
</spEntityId>: Unique identifier of the SP, which acts as the issuer to the IdP.

<preferred-binding>: Supported binding type such as POST or Artifact.
<default-page>: Context path to redirect back to the SP page.
<filter>: Web requests to be excluded as a SAML request.
<javax.net.ssl.keyStore>: Configured key store file.
<javax.net.ssl.keyStorePassword>: Password of the key store file.
Note: The value should be encrypted using genEncryptedPassword.
<javax.net.ssl.trustStore>: Configured key store file placed in the trust store.
<javax.net.ssl.trustStorePassword>: Password of the trusted key store file.
Note: The value should be encrypted using genEncryptedPassword.
<alias>: Alias name of the key store.
<keyStoreType>: Type of the Key store (current JKS is supported).
Manage SSL certificate

For artifact:
Artifact from SP: You must import SP's public key to the IdP's trust store. For example,
in WebLogic if an SSL certificate is "mycertificate" then the public key of this certificate
must be imported on the trust store of the IdP or corresponding steps must be followed to
provide SP connection specific public certificate.
Artifact from IdP: You must import IDP's public key to the SP's trust store. For example,
WebLogic as an IdP hosted at host1 has a certificate "myidpcertificate" then the public
certificate must be imported on the trust store of SP hosted in host2.
Use LDAP with JDA Platform

JDA Platform can be configured to use Lightweight Directory Access Protocol (LDAP), which means you
can manage all users based on your LDAP directory. If your organization has an LDAP service, then
you can configure JDA Platform to use the LDAP service to authenticate users. When using an LDAP
service to validate users, you must add the users from LDAP to the Foundation schema. JDA provides
an XML-based utility to assist in loading users and enterprises from LDAP.
If the LDAP User Profile information is changed, then it may not be reflected in the JDA Application
suite until the Authorization Cache (User Cache) is reloaded for the particular user.
With LDAP service enabled, JDA Platform authenticates users based on the LDAP directory. When a
user logs in, the system attempts to log in to the LDAP service using the supplied user name/password
combination. If the LDAP server is not functioning, then users cannot be authenticated. As a
consequence, users cannot access JDA applications.
JDA Platform reads LDAP attributes, but does not write to the LDAP service. For example, LDAP-
authenticated users cannot change their email addresses or other attributes in JDA Platform because
LDAP attributes have priority. Therefore, user information that maps to LDAP attributes must be
changed in LDAP.
Security administrators can change a users account status, regardless of the users status in LDAP.
This allows administrators to suspend (or activate) user access to JDA Platform-based applications
without affecting LDAP. This means that users who have valid LDAP accounts can be blocked from
accessing JDA applications. This discretionary tool is managed within JDA Platform, and does not affect
the status of the users account in LDAP or access to non-JDA applications.

Finally, you may want to load users from an LDAP service, but not enable LDAP for validating users.
The bulk loading of users from LDAP is useful when you have a large number of user accounts to
initialize in JDA Platform. See "Synchronize with LDAP".
Configure JDA Platform to use LDAP service

To enable LDAP for external authentication, you must configure the LDAP properties in the JDA
Platform System Properties, which is accessed via the user interface.. By default, LDAP is not enabled
when the JDA Platform is installed.
To access System Properties, click on Administration > System Properties, then select the LDAP Profile
section. The following fields are required:
ldap.profile.enableLDAP
ldap.profile.url
ldap.profile.principal
ldap.profile.credentials
ldap.profile.userDN
ldap.profile.userNameAttribute
Optionally, you can also map additional attributes in the LDAP section. If you are using Monitor to send
email alerts, you must set the ldap.profile.user.attribute.standard.email property. For enhanced
security, you can configure JDA Platform server to use LDAPS.
If the LDAP directory contains a large number of users, an LDAP filter can be enabled in the property
ldapEnableSearchFilter. Using an LDAP filter may improve performance.
See the "System Properties" section in the JDA Platform OnLine Expert for details on each of the LDAP
attributes.
Install LDAP server certificate when using LDAPS

To support LDAPS, the LDAP directory server must be configured with X.509 SSL server certificate. See
the documentation provided by your LDAP vendor for instructions on generating the server certificate.
The application server initiates the connection to the LDAPS server. The application server acts as an
LDAPS client, and must be persuaded to trust the LDAPS server. This is achieved by registering the
LDAPS server certificate with the application server installation.
For ORACLE WebLogic, the LDAPS server certificate can be made known to the application server by
installing the certificate into the JVM cacerts repository, using the standard JVM key management tool:
keytool.
Note: Back up the cacerts file before you attempt to modify it.
1. Navigate to the security directory using the following command:

cd <JAVA_HOME>/jre/lib/security
2. To register the certificate, from the bin directory use the command:
keytool -import -keystore cacerts -file <certificate file name>.cer -alias <LDAP
server alias> -storepass changeit
For example, to register the certificate myldapkey.cer use the following command:
keytool -import -keystore cacerts -file myldapkey.cer -alias myldapserver -
storepass changeit

For IBM WebSphere, the LDAPS server certificate can be made known to the application server by
installing the certificate into the WebSphere profile client trust store using the standard JVM key
management tool keytool.
Note: Back up the trust store file before you attempt to modify it.
3. Navigate to the security directory using the following command:

cd <WAS_HOME>/profiles/default/etc
4. To register the certificate, from the ../java/jre/bin directory use the following command:
keytool -import -keystore DummyClientTrustFile.jks -file <certificate file
name>.cer -alias <LDAP server alias> -storepass WebAS
For example, to register the certificate myldapkey.cer use the following command:
keytool -import -keystore DummyClientTrustFile.jks -file myldapkey.cer -alias
myldapserver -storepass WebAS
After you enable LDAPS and add the certificate to the application server, restart the server. Your LDAP
service must be running before you start the JDA Platform server. If the LDAP service is unavailable,
the JDA Platform server fails to start.
Use the csmImport utility

This section includes detailed steps and examples for using the batch process csmImport. The
csmImport utility is an efficient method to bulk load enterprises into the Foundation schema for
Foundation based applications such as SCPO.
Note: If you install an application that uses ABPP-based User Security (such as Sales and Operations
Planning, Supply Chain Planner, or Sequencing), use the userImport utility, not csmImport.
Use both csmImport and Security Manager to create, update, and delete enterprises in the Security
Manager database tables. Run csmImport on the JDA Platform Server when the server is running.
To use csmImport you must have:
A valid, well-formed XML input file
A user name and password with permissions to create, update, and delete enterprises.

The following graphic depicts the csmImport process at a high level. The process reads and parses an
input XML file import.xml. A different file name can be used, but it must be specified when running
csmImport. If the input file is valid, then the process creates, updates, or deletes enterprises into the
Security Manager database tables. The process also writes data to application databases where those
applications extend on certain objects. For details see Extend on JDA Platform security objects (on
page 250). When the process completes, it writes data to results.xml. The process also writes errors
to errors.xml. After fixing errors, you can rerun using the errors.xml as the input file.
import. results.
csmImport
xml xml
Application CSM
database database errors.xml
tables tables
Figure 1: Steps for synchronizing LDAP data with JDA Foundation
Rules for creating the input XML file

To import enterprises using csmImport, you must have an input XML file with the correct tags and
the mandatory and optional attributes for enterprises. You can create, update, and delete enterprises
with csmImport. Follow these rules in creating the XML input file.
The admin tag appears only once in the XML file because it is the document root.
The create, update, and delete tags can appear within the admin tag, and they can appear
multiple times.
The enterprise tag can appear within the create, update, and delete tags.
Use the enterprise tag to create, update, and delete enterprises.
The tags have required and optional attributes for which values must be supplied. See the
table in this section for the list of attributes.
When creating objects, the create tag must appear before update and delete tags. If the
enterprise already exists in Security Manager, then the process updates the object. When updating
objects, the update tag must appear before the delete tag. When updating objects, if the
enterprise does not exist in Security Manager, then the system creates the object.
IMPORTANT: Do not update objects using csmImport if LDAP is enabled. You can create and
delete objects when LDAP is enabled.
Multiple objects can appear within the create, update, and delete tags using properly nested tags.
The tags, attributes, and values are case sensitive in the input XML file.
The input XML file must be well formed with properly nested tags.
Check for and remove any byte order marks (BOMs) in XML files that are encoded in UTF-8 format,
or create the XML file using a text editor that does not insert them. Otherwise, the XML parser will
fail.

Note: The special characters (<, >, ", ', and &) are not supported directly in the XML file. However,
you can use all the mentioned special characters by using the corresponding escape characters. For
example:
For > use >
For < use <
For " use "
For ' use '
For & use &
Attribute Description of value Value Required?

max
length
enterprise
enterpriseName The name of the new enterprise. For delete 256 Yes
operations, an enterprise cannot be deleted if it is
a parent (of child enterprises).
The following special characters can be used:
!@$^_-|:;,.()
parentEnterpriseName The parent enterprise in the enterprise hierarchy. 256 No
If not supplied in the input file, the system uses
the enterprise name of the user running
csmImport for the parent enterprise. When
updating an enterprise, the parent cannot be
changed.
contactName The point of contact for the enterprise. 255 No
contactEmail The contacts email address. 255 No
telephone The contacts telephone number. 255 No
fax The contacts fax number. 255 No
address The address for the enterprise. 1024 No
city The city location for the enterprise. 255 No
locality The locality for the enterprise. For example, a 255 No

state, province, or prefecture.
zipCode The ZIP Code for the enterprise. 255 No
country The country for the enterprise. 255 No
description A description of the enterprise. 1024 No
Example 1: This example is more complex. It creates the enterprise SampleEnterprise. The parent
enterprise, which is an optional attribute, is not specified. In this case the system uses the enterprise
of the user running csmImport as the parent enterprise.
<?xml version="1.0" encoding="UTF-8" ?>

<admin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="csm_admin.xsd">

<create>

<enterprise enterpriseName="SampleEnterprise">
<contactName>Primary Contact</contactName>
<contactEmail>root@company.com</contactEmail>
<telephone>301.255.5001</telephone>
<fax>301.255.5000</fax>
<address>9715 Key West Avenue</address>
<city>Rockville</city>
<locality>Maryland</locality>
<zipCode>20850</zipCode>
<country>US</country>
<description>Sample Enterprise</description>
</enterprise>
</create>
</admin>
Example 2: To delete objects, use the delete tag. In this example, the enterprise SampleEnterprise is
deleted.

<admin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="csm_admin.xsd">
<delete>

<enterpriseKey enterpriseName="SampleEnterprise" />
</delete>
</admin>
Run csmImport.cmd (Windows) or csmImport (UNIX)

1. Start the JDA Platform Server and wait for it to accept requests. The csmImport utility connects to
the server using the value for the jndi_provider_url property in webworks_config.xml. The
csmImport utility does not function with SSL (t3s).
4. The process requires certain options. The user who runs csmImport must have create, delete, and
update privileges in CSM, and this user must be authenticated for csmImport to run. Use the
following syntax:
csmImport [-input <input file name>] [-results <result file name>]
[-errors <error file name>] [-application <application name(s)> ...]
[-user <user>] -credentials <credentials>

-user <user_name> The user name used to run csmImport. No, when using the password
This account must have create privileges option or when the specified
in its Enterprise to create users and credentials file contains the user
enterprises. name and password.
Yes, when the specified
credentials file does not include
the user name.
-credentials The name of the credentials file Yes, when using batch
<credentials_file> containing either the user authentication. No, when the user
name/password combination or only the and password options are used.
password for the batch user. To create a
credentials file, see "Use encrypted batch
authentication" (on page 169).
-input <file_name> The source XML file from which to import No. If not specified, the default
data. The default is import.xml. The input file used is import.xml in
input file can have any file extension, but the current directory. Yes, if
must contain well-formed XML. specifying a different file name or
directory.
-results <file_name> The output XML file to which to write No. If not specified, the process
data. The default is results.xml. writes results to results.xml in
the current directory. Yes, if
specifying a different file name.
-application The name of the application to import No. If not specified, the system
<application_name> data. The default application is CSM and writes to all applications that
all other applications that extend on CSM extend on CSM objects.
objects such as users and enterprises. If Otherwise, list the specific
specifying applications, then separate applications.
them with a single space. CSM is always
the default application, even when other
applications are specified.
-errors <file_name> If specified, the process writes errors to No
this file. After fixing errors, this file can
be used as the input file to rerun
csmImport. Default name is errors.xml.
The following examples illustrate csmImport.
Example 1: Run csmImport where credentials.properties stores the password for batchuser.
csmImport -user batchuser -credentials credentials.properties
Example 2: Run csmImport where credentials.properties stores only the password for batchuser. The
input file is located in directory c:\temp.
csmImport -user batchuser -credentials credentials.properties -input

c:\temp\import.xml
Example 3: Run csmImport using credentials_1.properties, which holds the user name and password.
The input file is update_enterprise.xml.

csmImport -credentials credentials_1.properties -input update_enterprise.xml
Find and correct processing errors

When csmImport processing is successful, it returns the command-line prompt. You should also verify
that the objects were added to the database. By default, the process creates the results.xml and
errors.xml file in directory <install_dir>\config\bin\platform\dataimport. When csmImport runs,
the process overwrites the results.xml and errors.xml files. If the following error displays in the
console:
Error parsing file <input_file.xml>. Check the log file.
Then check the results.xml file.
Fix the input file and run csmImport again.
Processing may also fail if the input file is not well-formed XML. Even though the input file can be a
text file, the contents must follow a logical XML structure with properly nested tags. If you receive the
following error in the results.xml file, then try displaying the import.xml file in Internet Explorer. If it
displays, then it is well-formed XML. If it does not display, then it is not well-formed.

<log>
<system>
<timestamp>2003-10-22T12:16:18Z</timestamp>
<level>Info</level>
<message>Processing Started.</message>
</system>
<parse>
<level>Fatal</level>
<line>1</line>
<column>1</column>
<message>The markup in the document preceding the root element must
be well-formed.</message>
</parse>
<system>
<level>Error</level>
<message>Error parsing file {0}. Check the log file.</message>
<exception>The markup in the document preceding the root element
must be well-formed.</exception>
</system>
</log>
In some cases, portions of the input file may process successfully, while other portions may fail. When
this occurs, the results.xml records only the failures. For example, in the following results.xml,
Enterprise05 creation failed because EnterpriseParent05 either does not exist or the user running
csmImport does not have create privileges for that enterprise. As a consequence, the child enterprise
creation failed.
<?xml version="1.0" encoding="UTF-8"?><log>

<system>
<level>Info</level>
<message>Processing Started.</message>
</system>
<processing>
<level>Error</level>
<entity>
<name>enterprise</name>
<enterpriseKey enterpriseName="Enterprise05"/>
</entity>
<operation>OperationType.CREATE</operation>
<message>com.manu.webservices.db.MissingObjectException: Object,
Enterprise.Key{enterpriseName=Unknown EnterpriseParent05}, does not
exist.</message>
</processing>
<system>
<level>Info</level>
<message>Processing Completed.</message>
</system>
<system>
<level>Info</level>
<message>Elapsed time is 0.356 seconds.</message>
</system>
<system>
<level>Info</level>
<message>Processing rate was 0.0 objects / second.</message>
</system>
</log>
Set security properties

JDA Platform provides Single Sign-On for users, which means that a users log in once to access all JDA
Platform-based applications and data without logging in repeatedly. JDA Platform also provides
centralized security administration which allows an administrator to manage security for an entire
enterprise or group of users.
Use secure sockets layer

By default, secure sockets layer (SSL) is not enabled after installing JDA Platform with Weblogic. JDA
recommends that SSL be configured at the Web Server layer, not the application server layer

If you have installed JDA Platform on IBM Websphere, then it automatically assigns the SSL port for
use. For details about port assignments on WebSphere see Port assignments for JDA Platform server
on WebSphere.
weblogic/weblogic1.
3. Navigate to your server, and click Lock & Edit. The server will be listed under JDA Domain >
4. Check SSL Listen Port enabled, and specify the port number. Click Save, and then Activate
Changes.
5. If you use the demonstration certificates, you can start the JDA Platform Server. Restart the JDA
Platform Server. Users connect to the server using the syntax https://jdasrv:7002. Users can still
connect using http://jdasrv:7001 even when SSL is enabled.
Generate an encryption key for multiple servers

JDA Platform provides an encryption key for each installation. After a user logs in successfully, the
encryption key verifies the users requests for pages, applications, and data. If your configuration has
multiple JDA Platform Servers in a non-clustered configuration, that is, each JDA Platform Server is
functioning independently, then generate a unique encryption key for each JDA Platform Server. This
prevents users from logging in to one JDA Platform Server and navigating to another. The utility
generates an encrypted key using Java Cryptography Extensions (JCE)
Note: If you have multiple JDA Platform Servers using the same JDA Platform schema, then you must
use a cluster. Use the same key on all machines in the cluster. See Generate an encryption key for a
cluster.
To generate and distribute the key:
4. Execute the batch file genEncryptionKey by typing:

genEncryptionKey

8. Paste the key generated in step 4 into the value element. For example:
9. Save and exit webworks_config.xml.

10. Repeat these steps for each JDA Platform Server. The encryption key on each server should be
different.
IMPORTANT: Although not technically required, you should copy the encryption key to the
webworks_config.xml for each instance of JDA Platform SRE (thin installation). This keeps your
environment consistent.
Set user password properties

After installation, you can set the password properties for JDA Platform users. The properties enable
administrators to set more restrictive password properties. These settings affect all users who access
JDA applications. When you change a password, the new password must conform to the rules
specified. You can set password properties in the Password Validation section of System Properties
user interface in the JDA Platform. See System Properties section in the JDA Foundation Online Expert
for more information on the password properties.
Note: The password properties set in System Properties are not used if LDAP is enabled or if using an
external authentication component.
Force new passwords for all users

After you change password properties, you can force all users to choose new passwords that comply
with the password properties. This may be useful after setting more restrictive password properties in
the section "Set user password properties" (on page 167). JDA provides a script that voids all
passwords for users in the database. The next time users log in, they must change their passwords.
IMPORTANT: Do not use this utility if LDAP is enabled or if using an external authentication
component.
2. Change to directory <install_dir>\config\database\platform\util.
3. Using SQL*Plus, run the script csm_expire_all_passwords.sql against the Foundation schema.
For example:
sqlplus wwfmgr/wwfmgr @csm_expire_all_passwords.sql
If the database is on a remote server, then specify the Net Service Name after an @ sign. For
example:
sqlplus wwfmgr/wwfmgr @<NetServiceName> @csm_expire_all_passwords.sql
Set login properties

You can change the properties that control login limits and password expiration for all users. You can
also suspend the account of a user who fails to successfully log in after a specified number of
attempts. To set these properties, use the Login Properties section of the System Properties user
interface in the JDA Platform. See System Properties section in the JDA Platform OnLine Expert for
more information on the login properties.
Notify the administrator automatically

JDA Platform can be configured to notify the administrator automatically, using an email alert if either
of these security-related events occurs:
A user exceeds the number of max_failed_logins within the login_time_window, and the
suspend_account_on_failed_login is enabled.
A user attempts to log in for the first time after the duration has elapsed for
first_login_time_window and the suspend_account_on_delayed_first_login is enabled.

To trigger an email to the administrator, enable the notify_admin_on_system_lockout in the Email

section of the System Properties user interface of the JDA Platform.
See Foundation System Properties section in the Foundation Online help for more information on email
properties.
Note: If the mail server is not available, then the system does not attempt to send the email again. A
message is logged in the log files if the email is not sent.
Record failed logins

By default, JDA Platform records all failed logins and writes them to appserver.log. Log files are
located in the <install_dir>\config\logs directory and can be viewed using a text editor.
In the following example of a log file, the authentication component denied access to the user name
user01:
2013-10-18 07:00:18,952 ERROR [[ACTIVE] ExecuteThread: '1' for queue:

'weblogic.kernel.Default (self-tuning) '] com.manu.base.common.WebworksLoginValidator
Invalid password: System [checkFailedLogins:609 {}]
com.manu.base.common.AuthException: Invalid password

'weblogic.kernel.Default (self-tuning) ']
com.manu.base.common.WebworksLoginModuleImpl Login denied due to authentication
exception [login:200 {}]
javax.security.auth.login.LoginException: The username or password is not valid.
Login information is case-sensitive.

'weblogic.kernel.Default (self-tuning)'] com.manu.base.common.WebworksLoginValidator
User account status not found: System4 [csmStoreAuthentication:469 {}]
com.manu.base.common.AuthException: Account status not found
Event Services auditing

JDA Platform Event Services audits and records events that occur in Security Manager. This includes
the creation, modification, and deletion of enterprises, users, roles, filters, resources, and
partnerships. The events are logged in table ES_AUDIT_LOG. The event records the user who initiated
the event, event type, and the date and time when the event occurred. The time is expressed in GMT.
The following event types (from ES_AUDIT_LOG.EVENT_TYPE) are recorded from Security Manager.
Event (from Description

ES_AUDIT_LOG.EVENT_TYPE)
CREATE_USER New user account created
DELETE_USER User account deleted

UPDATE_USER User account updated
UPDATE_ACCOUNT_STATUS User account status changed
UPDATE_USER_PASSWORD User password changed
INVALID_LOGIN_ATTEMPT User failed to log in

Event (from Description

ES_AUDIT_LOG.EVENT_TYPE)
USER_ACCOUNT_LOCKED User account locked. By default, a user has five login
attempts within a five minute duration. If the user
fails to log in successfully within five minutes, this
event occurs.
CREATE_USER_ROLE Role assigned to user
DELETE_USER_ROLE Role removed from user

CREATE_ROLE Role created
DELETE_ROLE Role deleted
UPDATE_ROLE Role updated
CREATE_ROLE_FILTER Filter assigned to role
DELETE_ROLE_FILTER Filter removed from role
CREATE_ENTERPRISE Enterprise created
DELETE_ENTERPRISE Enterprise deleted
CREATE_FILTER Filter created
UPDATE_FILTER Filter updated
DELETE_FILTER Filter deleted
CREATE_PARTNERSHIP Partnership created
UPDATE_PARTNERSHIP Partnership updated
DELETE_PARTNERSHIP Partnership deleted
CREATE_COLUMN_INFO Column metadata created
DELETE_COLUMN_INFO Column metadata deleted
CREATE_ACCESS_CONTROL Resource assigned to role
UPDATE_ACCESS_CONTROL Resource assigned to role was updated
DELETE_ACCESS_CONTROL Resource removed from role
Note: Only one event is recorded for a deletion with cascading deletes. For example, if a user deletes
a parent enterprise, then any child enterprises, partnerships, and roles associated with that enterprise
are also deleted. Event Services records the deletion as a single event.
Multiple events may be generated for a single action. For example, when creating a new user, Event
Services records three event types: CREATE_USER, UPDATE_USER_PASSWORD, and
CREATE_USER_ROLE.
Use encrypted authentication

This section explains setting up and using encrypted authentication. Using an encrypted password for
batch authentication is an important security feature.
JDA Platform and JDA Platform-based applications have batch processes and other scripts that must be
invoked at the command line and run on the JDA Platform Server or JDA Platform SRE instances. To
invoke batch processes, you must supply a user name/password combination. The JDA Platform Server
authenticates the user just as it authenticates users who log in using a Web browser. Encrypted batch
authentication provides the following security enhancements:
It is not necessary to type a password at the command line.
An encrypted password can be stored in a credentials file instead of passed on the command line.

The credentials file can contain either a user name/password combination or only a password.
All users must be created in or imported into Security Manager. Consider creating a user account just
for running batch processes. Create the account in User Manager. This user should have execute
permissions on the batch or other processes you plan to run. Batch log files use the batch users
locale, date, and time preferences, so you can log in as the batch user and select more detailed time
settings in User Preferences.
You must store the user name/password in a credentials file on the JDA Platform Server.
Generate an encrypted password for command-line

authentication
Use command file genEncryptedPassword to generate an encrypted password for batch
authentication. The utility generates an encrypted password using Java Cryptography Extensions
(JCE).
1. Create the user in User Manager. Remember the password for the user.
2. Open a command-line prompt on the JDA Platform Server.
3. Change to the <install_dir>\config\bin\platform directory.
4. At the command-line prompt, enter the following:

genEncryptedPassword
The console returns:
Enter the password to encrypt:
5. Enter the plain text password for the batch user. The console does not display the plain text
password as you type it. You are asked to confirm the plain text password by typing it again. The
console displays the encrypted password. For example:
Encrypted Password = {E:AES}b61cd9349d66b84b32d15cdf1910d530
6. Copy the generated password to the credentials file, see "Create credentials files".
Note: Credential file can be generated using the genCredentials utility. See Generate a credential file
(on page 138) for more information.
Invoke batch commands

Batch processes in this version use the batch authentication framework. This section explains the
syntax for invoking batch commands. For users who have upgraded from 7.2, batch processes still
support the 7.2 command-line usage.
Use the following syntax to invoke batch using the 7.4 batch authentication. Note that some batch
commands have additional options not documented here. See the product documentation for the batch
processes you plan to use.
SREBatchUtility [-validateOnly] [-user <user>] -credentials <credentials>

<requestXMLFile>

-user <user_name> The valid user name in User No, when the specified
Manager. This user must have credentials file contains the
permissions to run the batch user name and password.
process. Yes, when the specified
credentials file does not include
the user name.
-credentials <credentials_file> The name of the credentials file Yes
containing either the user
name/password combination or
only the password for the batch
user.
The following examples help illustrate batch command-line options.
Example 1: The user name batchuser must have permissions to run the batch process in
Security Manager. The credentials file is credentials_1.properties. It must contain only the
password for batchuser.
BatchCommandName -user batchuser -credentials credentials_1.properties
Example 2: The batch command is invoked specifying only the credentials file. In this case,
credentials_1.properties must contain the user name/password combination.
BatchCommandName -credentials credentials_1.properties
Example 3: This example uses the actual batch command SREBatchUtility. The user option
specifies batchuser and the credentials option specifies credentials_1.properties. In this case,
the credentials file specifies only the password for the user. The request.xml is a required option
for SREBatchUtility. Note that some JDA batch commands have additional options.
SREBatchUtility -user batchuser -credentials credentials_1.properties
request.xml
IMPORTANT: If the batch authentication fails, make sure the batch users password has not
expired in Security Manager.
Change the WebLogic admin password

The JDA Platform installation configures the WebLogic account with the password "weblogic1". This
allows the server to start immediately after installation. You should change the password for the
WebLogic system account before moving to a production environment. Restart the JDA Platform Server
to apply the password change.
2. Start a Web browser and connect to the WebLogic console using the following URL:
http://<servername>:<port>/console
For example, if the server name is jdasrv and the port is 7001, then enter:
http://jdasrv:7001/console
The login page is displayed.
3. Enter weblogic for the username and weblogic1 for the password.
4. In the left pane, select Security > Realms > myrealm > Users.
5. A list of users displays in the right pane. Select System.

Select Change.
Enter the new password in the New Password field.
Reenter the new password in the Confirm Password field.
6. Select Apply.
Note: You must also edit file boot.properties with the new password.
7. Using a text editor, open the file boot.properties located in the

<install_dir>\config\JDADomain\servers\AdminServer\security directory.
8. The password and username are encrypted if you have started the server. On Windows it looks
like:
#Sat Jan 1 13:17:51 GMT 2005
password={3DES}5SxJCRWpQI6kRpgzw2YNg\=\=
username={3DES}g792GkMCLC0GA\=
9. Type the new password in plain text. For example:

#Sat Jan 1 13:17:51 GMT 2005
password=newpassword
username={3DES}g792GkMCLC0GA\=
10. Save the file and exit the editor.
11. Shut down and restart the JDA Platform Server. To shut down the JDA Platform Server, you may
need to supply the new user name and password.
Note: If you reinstall JDA Platform, the WebLogic Console system password reverts to weblogic1.
Change the WebSphere admin user

The JDA Platform installation configures the WebSphere account with default appAdmin and
password as the user and password respectively. This allows the server to start immediately after
installation. You should change the user and password for the admin account before moving to a
production environment. Restart the JDA Platform Server to apply the password change. Use the
following commands to change the admin user and the password.
In a stand-alone environment, use the updateAdminUserND command. The updateAdminUser file

is located in the /config/bin/platform directory. This command takes four parameters, the old
username and password and the new username and password.
updateAdminUser <old_user_name> <old_password> <new_user_name> <new_password>

For example, to modify the existing appAdmin/password combination to SuperUser/password use the
following:
updateAdminUser appAdmin password SuperUser password
In a clustered environment, use the updateAdminUserND command. The updateAdminUserND file

is located in the /config/bin/platform directory. This command takes 6 parameters. In addition to
the username and passwords, you also need to specify the DMgr host and the SOAP port.
updateAdminUserND <DMgr_host> <DMgr_SOAP_port> <new_user_name> <new_password>
For example, to modify the existing appAdmin/password combination to SuperUser/password use the
following:
updateAdminUserND jdasrv 8879 appAdmin password SuperUser password

After you have updated the admin user, modify the following files:
1. Update the soapcredentials.properties:
a. Using a text editor, open the soapcredentials.properties file located in the

/config/properties directory.
b. In the user property enter the new user name.
c. In the password property, enter the encrypted password. Use genEncryptedPassword to

generate the encrypted password.
d. Save the file and exit the editor.
2. Update the was_admin_users.xml
a. Using a text or XML editor, open was_admin_users.xml file located in the

/config/properties directory.
b. Update the Admin user name.
c. Save the file and exit the editor.
JDA event auditing

The event auditing features allows the system administrators to track the activities that have
performed on the system.
To know which of the activities that are currently tracked, then run the
exportAuditSubscriptions utility.
To update the activities that you want track apart from the default list, then run the
importAuditSubscriptions utility.
You can track the following lists of activities:
COPY_FILTER
CREATE_FILTER
UPDATE_FILTER
DELETE_FILTER
CREATE_ACCESS_CONTROL
DELETE_ACCESS_CONTROL
CREATE_ROLE
UPDATE_ROLE
DELETE_ROLE
CREATE_ROLE_FILTER
DELETE_ROLE_FILTER
CREATE_USER
UPDATE_USER
DELETE_USER

CREATE_USER_ROLE
DELETE_USER_ROLE
INVALID_LOGIN_ATTEMPT
UPDATE_ACCOUNT_STATUS
UPDATE_USER_PASSWORD
USER_ACCOUNT_LOCKED
exportAuditSubscriptions utility
When you run the exportAuditSubscriptions utility, the system generates an XML file with the list of
the activities. You can use this file to analyze the event types performed by the users.
Change the directory to <install_directory>\config\bin\platform. Use the following syntax to run to

sun the exportAuditSubscriptions utility.
exportAuditSubscriptions [-user <user>] -credentials <credentials> <subscriptionsFile>
The event types are exported to an XML file. For example:

-<eventServices subscriberID="csa.audit">
<subscription eventType="COPY_FILTER" eventType="INVALID_LOGIN_ATTEMPT" event-
source="csa.audit"/> <subscription eventType="USER_ACCOUNT_LOCKED" event-
source="csa.audit"/>
</eventServices>
importAuditSubscriptions utility
Run the importAuditSubscriptions utility to import the XML after updating with missing event type
or adding a new event type or deleting an event type.
Modify the XML file with the new event types and run the importAuditSubscriptions utility from the
<install_directory>\config\bin\platform directory to import the event types to the database.
Change the directory to <install_directory>\config\bin\platform. Use the following syntax to run the
importAuditSubscriptions utility:
importAuditSubscriptions [-user <user>] -credentials <credentials>

<subscriptionsFile>
Service Runtime Environment (SRE)

Interface options for configuring SRE
JDA Platform has an user interface for managing the service runtime environment. When configuring
SRE, you can perform some tasks in the Process Manager or Process Options user interface. Other
tasks can be performed at the command-line prompt or using Oracle utilities.

SRE configuration task options

SRE configuration task Perform in:
Adjust SRE global properties Foundation schema using Oracle utilities. See "Adjust
SRE global properties" (on page 177).
Create a node pool Process Manager > Node Pool Summary
Associate application processes with a pool Process Manager > Node Pool Summary
Start a node pool manager Command-line prompt using startNodePoolManager

command. "Start a node pool manager" (on page 122)
Shut down a node pool manager Shut down a node pool using:
Command-line prompt using
shutdownNodePoolManager command. See "Shut
down a node pool manager" (on page 124)
Process Manager > Node Pool Summary

Change the number of nodes in a pool Process Manager > Node Pool Summary
Change the memory allocation for nodes in Process Manager > Node Pool Summary
a pool
Request jobs Depending on the process:
Use SREBatchUtility with a request XML file. See
"Create process request XML file" (on page 182)
Select the process in Directory

Some jobs run as background processes, and cannot
be requested through the user interface or
SREBatchUtility
Users must have permissions to run jobs for their

processes.
Cancel requested jobs Process Manager > Queue
Cancel running jobs Process Manager > Job Summary
Change priority of jobs in the queue Process Manager > Queue
Create node configuration records Foundation schema using Oracle utilities.

See "Add node configurations" (on page 125).
Configure the Foundation schema for SRE

When configuring SRE for your environment, you can add and change data in the Foundation schema.
Tables with the prefix SRE_ are used by the service runtime environment. These tables are populated
with predefined data when configuring the Foundation and JDA schemas, so you should back up the
database before changing any predefined data. For a description of SRE tables, see Table .
IMPORTANT: Back up the Foundation schema before making changes. Do not change the schema by
adding or dropping columns or tables or by removing predefined data.

JDA Platform SRE schema reference

Table Description Modify?
SRE_GLOBAL_PROPERTY Stores system configuration Yes, some properties can be

settings for SRE processing. modified for your environment.
Consider changing the settings
only after evaluating
performance. See "Adjust SRE
global properties" (on page
177).
SRE_JOB Stores jobs requested through No
Process Manager user interface
or command-line, including
continuous jobs installed.
Displays in Process Manager
Queue. Each Job has a unique
JOB_ID.
SRE_JOB_SUMMARY Stores information on running Yes, use Process Manager to
and completed jobs. These periodically remove records
jobs display in Process when they are no longer
Manager. necessary.
SRE_JOB_TRACE Stores information about the No
status of a job as it runs. The
status displays in Process
Manager Job Summary based
on the MESSAGE_RES_KEY.
SRE_NODE Stores the running node IDs No
and their associated pool
names.
SRE_NODE_CONFIG Stores configuration names Yes, to establish a different set
and the associated process of timeout parameters, min, and
name along with specific max nodes for a process. For
timeouts. The timeouts are set details, see "Add node
in seconds. configurations" (on page 125).
SRE_NODE_POOL Stores node pool names, the No, use Process Manager. See
machine it is running on, "Add or edit a node pool"
number of nodes, and section in the JDA Platform
heartbeat. OnLine Expert.
SRE_NODE_POOL_CONFIG Stores associations between No, use Process Manager. The
processes, node configurations, pool must exist in table
and node pools. SRE_NODE_POOL before
associations can be made. See
"Add or edit a node pool"
section in the JDA Platform
OnLine Expert.
SRE_OPTION_INFO Stores required and optional No, use as a reference when
options for processes. Some of creating new option sets.
the options are required for
processes to run. Some options
also have default values.

Table Description Modify?
SRE_OPTION_OVERRIDES Stores values used to override No

a value for an option set.
Configured by the user.
SRE_SERVICE_INFO Stores processes, class names, No. Portions of this table are
and maximum attempts as described in "Understand SRE
predefined by JDA applications. attempts to run a job".
SRE_SERVICE_OPTION Associates options and values No. Users can create options in
with an option set. Option sets the Process Options user
are stored in table interface for a particular
SRE_SERVICE_OPTION_SET. process.
SRE_SERVICE_OPTION_ INFO Stores processes and No. Use this table as a reference
associated options as to understand what options are
predefined by JDA applications. available for each process. You
cannot create options.
SRE_SERVICE_OPTION_SET Stores option sets associated No. Users can create option sets
with processes. Users can in the Process Options user
create and save option sets in interface for a particular
the user interface. process.
SRE_SERVICE_OPTION_SET_HIST Stores option set IDs used with No
requested jobs, regardless of
whether the job ran
successfully.
SRE_SYSTEM_ALERT Stores alerts that occur during Yes. Old records can be
processing. Alerts are often removed from this table using
caused by incorrect values Oracle utilities. If necessary
specified in the process request archive the table before deleting
XML file or the failure of a node old records. The
or node pool. Common CREATION_DATE tells when the
examples are: system generated the alert.
JOB_RESET
NODE_RESET
NODE_TIMEOUT_FAILURE
NODE_FAILED
Alerts display in Process
Manager.
Adjust SRE global properties

JDA Platform SRE uses global properties that apply to all processes. You can adjust some of the SRE
global properties. Generally, you should not change the properties without carefully evaluating
performance or consulting with JDA. Unlike node configuration or process options, global properties
apply to all processes. The properties are stored in table SRE_GLOBAL_PROPERTY.

SRE global properties

ENABLEDIAGNOSER Enables or disables SRE Diagnostics. Enter 1 to enable and 0 to

disable SRE Diagnostics. The default is 1.
EVERGREENCNT The number of jobs after which the system automatically restarts
a node. For example, after a node completes 1000 jobs, the
system shuts down the node and the node pool manager starts a
new one. The new node has a new ID. Default is 1000.
EXITIMMEDIATESECS Do not change this setting without assistance from JDA.
FINISHNODETIMEOUTSECS Set in seconds. The amount of time a node has to finish its work
on a job after the job has finished. Default is 300 (5 minutes).
GROUPMGRTIMEOUTSECS Set in seconds. The duration that a node pool manager has to
update SRE_NODE_POOL.LASTHEARTBEAT before SRE assumes
that the node pool manager and its nodes have failed. The default
is 20.
INITIALASSIGNMENTSECS Set in seconds. The duration that the system attempts to assign
nodes to a job. If a job remains unassigned after this duration,
the job is timed out. For example, a user requests a job, but no
node pools are available to run the job. The job fails because it
exceeds the initial assignment value. Default is 30 seconds.
MAINTENANCESECS Set in seconds. The maximum interval that a group of unassigned

nodes waits before one node performs a predefined list of
maintenance tasks. Default is 1.
MAINTENANCELASTUPDATE The last time an unassigned node performed maintenance. Do not
change this value.
NODEASSIGNEMENTLOCK Used by the system to execute processes. Do not change this
setting.
RESERVEDNODEMEMORY Set in MB. The memory that a node consumes for diagnostic
purposes. Default is 2 MB.
Note: You can override this setting at the Node Pool level by
adding the parameter to the Node Java Options in the following
format: -Xms32m Xmx128m-
Dsre.RESERVEDNODEMEMORY=<some_value>.
THREADHEARTBEATINTERVAL Set in seconds. The duration that a thread for a pipelined process
has to complete processing of an action. You can override this
value for a specific process by including an entry in table
SRE_NODE_CONFIG_PROPS for the node config being used with a
name of 'THREADHEARTBEATINTERVAL' and a value of the
desired interval for that process's pipeline threads.
UNASSIGNEDNODEDUR Set in seconds. The duration that the system waits for the
heartbeat from an unassigned node before stopping it and
creating a new one. If the node has seized an assignment lock,
the system recovers by killing the node and releasing the
assignment lock. Default is 30 seconds.

WAITMILLIS The node wait interval in milliseconds. When a node is idle (not
processing a job or the actions of a current job), it waits this long
before polling again for new work. In a large node configuration,
for example, 50 nodes, consider increasing this number. Default is
1000 (one second).
Configure a node pool for a cluster

A cluster is a group of JDA Platform Servers functioning together and using the same database.
Clustering provides the opportunity for increased availability, better performance, and load balancing.
When installing JDA Platform SRE, you must specify the JDA Platform Server with which it
communicates. If this primary server is unavailable, then the node pool managers running on that SRE
instance can fail.
In a clustered configuration, you can modify each JDA Platform SRE instance to use a primary JDA
Platform Server and a number of backup servers. If the primary server is unavailable, then the node
pools on that machine can communicate with the backup server. This provides failover.
JD A F oundation and
JD A A pplication installations
W ebLogic /
W ebS phere
P rim ary JD A F oundation
S erver 1
S erver
m anusrv:7001
JD A F oundation S R E m achine
1 DB
node pool A pp
2
m anager S chem as
3
JD A F oundation and
JD A A pplication installations
W ebLogic /
W ebS phere
S econdary JD A
S erver 2
F oundation S erver
m anusrv2:7001
When taking advantage of this feature, you should not use the same JDA Platform Server as the
primary for all SRE instances. Different SRE instances should use different primary and backup JDA
Platform Server instances. This provides balance for your SRE architecture, and it does not burden one
JDA Platform Server in the cluster.
Modify an SRE instance for WebLogic and WebSphere clusters

1. Stop any node pools running on the SRE machine.
2. Navigate to the <install_dir>\config\properties directory.
3. Using a text editor, open the webworks_config.xml file.


</configProperty>
5. The value element identifies jdasrv:7001 as the JDA Platform Server that this SRE instance
communicates with. Add a secondary JDA Platform Server in the cluster. For example:
<value>t3://jdasrv:7001,jdasrv2:7001</value>
7. Restart node pools on the machine.
Modify an SRE instance for a WebSphere cluster
1. Stop any node pools running on the SRE machine.
2. Change to the <install_dir>\config\properties directory.
3. Using a text editor, open the webworks_config.xml file.

<value>iiop://jdasrv:7001</value>
</configProperty>
5. The value element identifies the JDA Platform server that this SRE instance communicates with.
Add a secondary JDA Platform server in the cluster. For example:
<value>corbaloc::jdasrv1:7005,:jdasrv2:7005</value>
Make the same change to the java.naming.provider.url specified in webworks.commn.vars.cmd (or

.sh) file. For example:
-Djava.naming.provider.url=corbaloc::jdasrv1:7005,:jdasrv2:7005
7. Restart node pools on the machine.

Run processes in SRE

With your service runtime environment set up with JDA Platform Servers, JDA Platform-based
applications, JDA Platform SRE machines, and node pools, you can run processes. The processes
available depend on the JDA applications being used. Users can request processes to be run using:
SREBatchUtility command and process request XML file. See "Create process request XML file" (on
page 182).
Process Options in the user interface - Users can request to run jobs. Users can also create process
option sets. Because JDA applications provide specific options for each process, see the
documentation for your specific applications. In the user interface, each process has a unique
name.
JDA Platform processes

JDA Platform has four Flexible Editor processes. Several JDA Platform-based applications use Flexible
Editor. The processes are not continuous jobs. By default, the four processes use node pool Basic, but
you can configure them to use additional node pools. You can also configure these processes (and all
other processes) not to use Basic in Process Manager.
Gensys.FlexEd.ImportExport: Import and export processes (GUI and batch)
Gensys.FlexEd.Regular: Flexible Editor page (regular)
Gensys.FlexEd.TimeAlloc: Flexible Editor page (time-allocated)
Gensys.FlexEd.MultiCopy: Flexible Editor page (many-to-many copy)
Gensys.ParamWB.ParameterUpdate: Update Parameters process
Note: When using large data selections in Flexible Editor, increase the value for
SRE_NODE_CONFIG.BUILD_ACTIONS_TIMEOUT. A suggested range is 3600-7200. The default value is
1000 seconds.
Run Update Parameters in batch

The following information describes the supported configuration for the Update Parameters process:
Update Parameters:
Is a multi-action process, which can be executed in a parallel manner.
Can be invoked using the SRE batch facility.
Is pipelined (multi-action and multi-threaded, so the execution of one action can overlap
another).
Is not continuous that is, it is not run as a background process.
Does not use database stored procedures.
In the process request XML file:
You cannot use the simulationName attribute.
You can use the searchName attribute and the element prompt.

Create process request XML file

This section provides reference information on creating the process request XML file. Use the process
request XML file to run one or more jobs.
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.
See the following for an explanation of the process request XML elements and attributes. Example files
at the end of this section can help you create process request XML files. When editing the files, change
only the attribute and element values in quotation marks. The indentation of the elements indicates
the hierarchy for proper nesting. For example, the element processOptionSet is indented indicating
that it must be nested within element processRequest.
Request XML file schema definition

Element Description
batchjob Required element. The document root for the request XML file. Cannot
appear more than once.
Required attribute is
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Required attribute is
xsi:noNamespaceSchemaLocation="process_request.xsd"
Optional attribute is logFilePrefix.
Set to the name of the log file for the job. The process writes log
files to <install_dir>\config\logs.
Optional attribute is batchName.

Sets the name of the batch job to display in the Process Manager.
processRequest Required element. Repeat to request multiple jobs within a single XML
file.
Required attribute is processName
The name of the service to be run. Service names are predefined
and stored in table SRE_SERVICE_INFO.
Optional attribute is simulationName

Optional attribute is nodeConfigurationName
The name of a node configuration from table SRE_NODE_CONFIG. If
not specified, the default is used.
Optional attribute is batchStepName.

Sets the name of the process to display in the Process Manager.

Element Description
processOptionSet Optional element. Do not repeat within processRequest.

Required attribute is optionSetName
The name of the option set to use with this job. Set names are
stored in table SRE_SERVICE_OPTION_SET.
Optional attribute is enterpriseName

Use a valid enterprise name.
Optional attribute is isPublic

Valid value is true or false.
jobOptions Optional element. Do not repeat within processRequest.
actionGroupSetName Required element if actionLifeCycle is CREATE_AND_SAVE_ACTIONS

or USE_EXISTING_ACTIONS. Otherwise, the element is not required.
IMPORTANT: Do not run concurrent jobs using the same
actionGroupSetName.
actionLifeCycle Optional element. Cannot appear more than once. Use one of the
following values:
CREATE_AND_SAVE_ACTIONS: Creates and saves the new action.
USE_EXISTING_ACTIONS: Uses default actions from table
SRE_ACTION_GROUP_SET.
saveOptionsHistory Optional element. Cannot appear more than once. Set to true or false.
traceCategoryRange Optional element. Cannot appear more than once. Use with nested
element category described below.
category Optional element. Can be repeated. Use the following values to specify
application tracing: PROCESS_STATUS, APPLICATION_EXCEPTION,
and PROCESS_DEBUG.
searches Optional element. Use within element processRequest to specify

predefined searches in the JDA Platform database. You cannot
override predefined searches.
search Required if using element searches. Use to specify the name of a
search(es). Can be repeated.
Required attribute is searchName
Optional attribute is enterpriseName
Optional attribute is isPublic
Optional attribute is entityName
Note: The SREBatchUtility.cmd supports Public and Private searches
but not PublishTo searches.

Element Description
prompt Optional element. Can be repeated.

Required attribute is schemaName
Required attribute is tableName
Required attribute is columnName
Optional attribute is seq
promptedValue Optional element. Can be repeated within prompt.
Note: You must specify '*' in the promptedValue field to retrieve the
all search.
processOptionOverrides Optional element within processRequest. Can be repeated within

processRequest. Use to override default values associated with the
option set. The option set is specified in element processOptionSet.
Required attribute is serviceOptionsSetName
option Required. Can be repeated.
Required attribute is name. Specify the option name.
Required attribute is value. Specify the value for option.
Rules on creating the process request XML file

The element batchJob must appear once because it is the document root.
The element processRequest can appear more than once in a file, so 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.
The element processOptionSet is used to specify the option set for the job. You can use this
element and still specify overrides for particular options.
The element processOptionOverrides is used to override default values in the specified option
set.
Example 1: The following request XML file launches a single job. It includes the required element
processRequest with the required attribute to run process Supply.SupplyPlan. The option set is
Default SupplyPlan OptionSet. The searchName is Supply_SKUS belonging to enterprise JDA. This
example also uses the optional attributes batchName and batchStepName used to display
information in Process Manager.
<?xml version="1.0" ?>

<batchJob xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
logFilePrefix="SupplyPlanBatch" batchName=Supply_Plan_Batch>
<processRequest processName="Supply.SupplyPlan"
batchStepName=Supply_Plan_Batch_job>
<processOptionSet optionSetName="Default SupplyPlan OptionSet"
isPublic="true" />
<searches>
<search searchName="SUPPLY_SKUS" enterpriseName="JDA"
isPublic="true" />

</searches>
</processRequest>
</batchJob>
Example 2: The following process request XML file uses the optional element processOptionOverrides.
The overriding options are Supply.inputResult and Scope. Notice that each option has a value. When
the job runs, the two options override default values associated with option set RESOOptionSet. All
options are predefined, but you can create option sets, see "Create and use option sets".
<?xml version='1.0' encoding='UTF-8'?>

logFilePrefix="FetchBatchTest1">
<processRequest processName="Supply.RESO">
<processOptionSet optionSetName="RESOOptionSet" isPublic="true"
/>
<processOptionOverrides>
<option name="Supply.inputResult"
value="Default RESOFetch OptionSet" />
<option name="Scope" value="1" />
</processOptionOverrides>
</processRequest>
</batchJob>
Example 3: The following example specifies a node configuration Strategy2. Any single node
configuration can be used only for a single process. You can create node configurations, see "Add node
configurations" (on page 125). Using element nodeConfiguration is optional. When it is not specified,
the job runs using the default node configuration for the process.

logFilePrefix= "strategyalgbatch">
<processRequest processName="SCPOWeb.Strategy"
nodeConfigurationName="Strategy2">
<processOptionSet optionSetName="Sample" isPublic="true" />
<searches>
<search enterpriseName="JDA" searchName="ALL-SKUS"
isPublic="true" />
</searches>
</processRequest>
</batchJob>

Example 4: The following example requests two jobs using processes Supply.CostRollup and
Supply.E2ELeadTime. You can request multiple jobs within the XML file using properly nested
elements. Notice the document root batchJob appears once while element processRequest appears
twice. SRE processes the jobs sequentially. If a job fails with return code of 3 or higher, the next
job(s) do not run.

logFilePrefix="SupplyProcess">
<processRequest processName="Supply.CostRollup">
<processOptionSet optionSetName="CostRollupOptionSet"
isPublic="true" />
<searches>
isPublic="true" />
</searches>
</processRequest>
<processRequest processName="Supply.E2ELeadTime">
<processOptionSet optionSetName="E2ELeadTimeOptionSet"
isPublic="true" />
<searches>
isPublic="true" />
</searches>
</processRequest>
</batchJob>
Example 5: The following example requests the Flexible Editor Import Export utility to run an Export
in using the SRE. The parameters for the export are passed using the following XML file. The options
for the export process are mentioned in the Option tags.

xsi:noNamespaceSchemaLocation="process_request.xsd" logFilePrefix="6.01">
<processRequest processName="Gensys.FlexEd.ImportExport">
<option name="Gensys.FlexEd.InstanceName" value="ITEM" />
<option name="Gensys.FlexEd.OwnerName" value="$PUBLIC" />
<option name="Gensys.FlexEd.ListingName" value="Sample Flexible Editor" />
<option name="Gensys.ImportExport.ScenarioName" value="LIVE" />
<option name="Gensys.ImportExport.FixedWidth" value="No" />
<option name="Gensys.ImportExport.Delimiter" value="," />

<option name="Gensys.ImportExport.EnclosedBy" value=""" />

<option name="Gensys.ImportExport.IncludeHeader" value="true" />
<option name="Gensys.ImportExport.OutputFileName"
value="../../export_output/6.01.out" />
<option name="Gensys.ImportExport.IncludeSequence" value="false" />
<searches>
<search searchName="ITEM_ALL" enterpriseName="JDA" isPublic="true" />
</searches>
</processRequest>
</batchJob>
IMPORTANT: If you are migrating from the earlier versions of the software, note that the option
FixedWidth has been added to the XML file. Make the necessary changes to your legacy XML files
before running the SRE process.
Example process request XML files for the Update Parameters process
Here are two example XML files that illustrate how to run the Update Parameters process in batch.
CAUTION: If you specify the Run Date option in the input SREBatchUtility XML file for the
Update Parameters process, its format must be yyyy/MM/dd.
Example 1: Run the process with a saved set of process options
In this example, the process request XML file simply refers to a saved set of options, created on the
Update Parameters process page in the user interface. The process is run for a public search named
SKU_ALL and uses a public option set called MyOptionSet.
xsi:noNamespaceSchemaLocation="process_request.xsd">
<processRequest processName="Gensys.ParamWB.ParameterUpdate">
<searches>
<search searchName="SKU_ALL" isPublic="true"/>
</searches>
<processOptionSet optionSetName="MyOptionSet" isPublic="true"/>
</processRequest>
</batchJob>
Example 2: Specify all options directly in the XML file
In this example, the process request XML file specifies all the options that are supported in this
release. The process is run for a public search named SKU_ALL and uses the following option settings:
Base Table: SCPOMGR.SKU
Run Date: 2010/02/08
Rule Group Control: Name
Rule Group: MyGroup

Options shown in boldface are not needed if RuleGroupControl is set to ALL or NULL.
xsi:noNamespaceSchemaLocation="process_request.xsd">
<processRequest processName="Gensys.ParamWB.ParameterUpdate">
<searches>
<search searchName="SKU_ALL" isPublic="true"/>
</searches>
<option name="Gensys.ParamWB.Option.BaseSchema" value="SCPOMGR"/>
<option name="Gensys.ParamWB.Option.BaseTable" value="SKU"/>
<option name="Gensys.ParamWB.Option.RunDate" value="2010/02/08"/>
<option name="Gensys.ParamWB.Option.RuleGroupControl" value="NAME"/>
<option name="Gensys.ParamWB.Option.RuleGroup" value="MyGroup"/>
</processRequest>
</batchJob>
Run SREBatchUtility
Run SREBatchUtility from a command-line prompt to request processes in SRE. 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.
Use the following syntax to run SREBatchUtility. Ensure that you adhere to the case shown in the
syntax:
SREBatchUtility [-validateOnly] [-user <username>] -credentials <credentials_file>

<request.XML>
Options for SREBatchUtility

-user <user_name> The valid user name in Security Manager. This user No, when the specified
must have permissions to run the batch process. credentials file contains
Note: You cannot delete a user from Security the user name and
Manager if that user has current jobs. You must password.
first cancel the jobs in Process Manager, then Yes, when the specified
delete the user account. credentials file does not
include the user name.
-credentials The name of the credentials file containing either Yes

<credentials_file> the user name/password combination or only the
password for the batch user.
<request.xml> The name of the process request XML file. For Yes
details, see the section "Create process request
XML file" (on page 182).

-validateOnly Validates the process request XML file by parsing it. No

This option does not launch any processes. Use this
option to ensure that the request XML file is valid.
-H Shows usage for SREBatchUtility No
1. Open a command-line prompt. Do not use the same console where node pool manager is running.
3. Type SREBatchUtility with the appropriate options.
Example 1: Specify the credentials file containing the user and password along with the
request XML file.
SREBatchUtility -credentials credentials.properties myjob.xml
Example 2: Specify the user and the credentials file when the credentials file holds only the
password for batchuser.
SREBatchUtility -user batchuser -credentials credentials_1.properties myjob.xml
Example 3: Use the validateOnly option to validate the request XML file before submitting a
job.
SREBatchUtility -validateOnly myjob.xml
The command-line prompt returns Job Id, Service name and Node Config Name when the job
completes. Completion time depends on the job, volume of data, hardware, and other processes
contending for resources.
4. If the following error displays:

Error parsing request file ...
Fix the XML file and validate it using option validateOnly:

SREBatchUtility myjob.xml -validateOnly
If the XML file is valid, the console returns:

No errors encountered while parsing request file - myjob.xml
Try running SREBatchUtility again using the XML request file to launch the job.
Notes for users upgrading from 7.1.x to 7.4

The service runtime environment (SRE) implements several changes from 7.1.x:
The startServiceDaemon command file is no longer used. Use startNodePoolManager.
The BatchUtility command-line scripts are no longer used. Use the command file SREBatchUtility.
The batch input XML file and batchinput.dtd are no longer used. Instead, use a process request
XML file.

File comparison: 7.1 batch input XML file

The following is a sample input XML file was used in version 7.1.x:

<!DOCTYPE batch SYSTEM "file:///batchinput.dtd">

<batch>
<process name="Calculate Model">
<parameter name="PROCESS" value="CALCSET"/>
<parameter name="SELECTION" value="BDFU1"/>
<parameter name="DESKTOP" value="SCPOWEB"/>
<parameter name="OUTPUT_FILE" value="test1b.out"/>
</process>
</batch>
File comparison: 7.4 process request XML file

Using the new format in version 7.4, you could invoke the same process using the following request
XML file:
logFilePrefix="test1og">
<processRequest processName="SCPOWeb.CalcModel">
<processOptionSet optionSetName="Option2" isPublic="true" />
<searches>
<search searchName="BDFU1"/>
</searches>
</processRequest>
</batchJob>
Understand continuous jobs

Some JDA applications have processes that run in the background using the SRE framework. These are
called continuous jobs. The system assigns continuous jobs preferentially before user jobs whenever
eligible nodes are available. Continuous jobs never complete and are not timed out. Continuous jobs
require node pools to run. Similar to other JDA processes, the continuous jobs are configured by
default to use node pool Basic.
Identify a continuous job

There are two ways to identify continuous jobs: Process Manager and Database utilities.
1. Select Process Manager > Job Summary.
2. Continuous jobs have Daemon as the User.

3. To identify a continuous job using SQL*Plus:
4. Connect to the Foundation schema using SQL*Plus.
5. Query SRE_JOB.JOB_TYPE.
If set to 0 (zero), the job is not continuous.
If set to 1 (one), the job is continuous.
Work with sre_configuration package

To work with the sre_configuration packages, first connect to the Foundation schema using SQL*Plus
and then run the interfaces specifying appropriate parameters. Then commit the changes.
The following table lists the interfaces available in the sre_configuration package.
Name of the function

Parameters Description
or Procedure
serviceName [IN], configName Add a new continuous job for given
addContinuousJob [IN], optionSetName [IN], service, node configuration, service option
searchName [IN] set and search
Stop an existing, possibly running

stopContinuousJob jobID [IN] continuous job for given job id by
disablement and cancellation
Enable an existing continuous job for

enableContinuousJob jobID [IN]
given job id.
Disable an existing continuous job for
disableContinuousJob jobID [IN] given job id.
Remove all existing continuous jobs for

given service.
removeContinuousJob serviceName [IN]
Note: Jobs should be stopped prior to
removal.
Remove an existing job for given job id.
removeContinuousJob jobID [IN] Note: Job should be stopped prior to
removal.
Return the number of existing continuous
continuousJobCount serviceName [IN]
jobs for given service.
jobID [OUT], serviceName
Run a job for given service, node
[IN], configName [IN],
runJob configuration, service option set, search
optionSetName [IN],
and job type returning job id.
searchName [IN], jobType [IN]
Add service option override for given job
jobID [IN], optionName [IN],
addOptionOverride id, service option name and service option
optionValue [IN]
value.
Copy an existing node configuration for
given service and existing node
serviceName [IN], configuration name to a new node
cloneNodeConfig oldConfigName [IN], configuration for given service and new
newConfigName [IN] node configuration name.
Note: Node configuration properties also
copied.

Name of the function

Parameters Description
or Procedure
getPackageVersion Return the package version.
Initialize a possibly non-existing action
actionGroupSetId [OUT], group set for given service, action group
serviceName [IN], set name and number of groups returning
initializeActionGroupSet
actionGroupSetName [IN], the action group set id.
numberOfGroups [IN] Note: Useful when actions created
separate from a job (action pre-creation).
Finalize an existing action group set for
given action group set id.
finalizeActionGroupSet actionGroupSetId [IN]
Note: Useful when action created
separate from a job (action pre-creation).
SRE job restart

SRE works on a large job by breaking it down into smaller blocks called Actions. These actions are the
atomic work units of application logic. SRE helps run these broken-down logical tasks and finishes all
the actions before it considers the Job complete.
When applications use this infrastructure real-time, one or more of the actions may fail. This can
happen due to several reasons including database or other system issues, coding errors or data setup.
Upon Action Failure, there are number of variables that need to be evaluated including any specific
error messages, SRE Setting such as Action_Failure_Count, Action_Retrys, and SRE Time-outs. Even
under a Failed or Warning Return code, the SRE Job State will show complete. This is expected as the
Job itself is complete but may have failed actions.
SRE Job Restart feature enables users to rerun a SRE job request with only those actions that have
previously failed and therefore reduce the time required to recover from one or more failures.
The SRE Job Restart feature leverages Action Life Cycles and requires an optional update to the Batch
XML files.
Use SRE Custom processes

In addition to running standard built-in processes, you can run custom processes using JDA Platform
SRE. This feature enables you to run your command line scripts or PL/SQL stored functions using the
SRE. You can register your commonly used scripts and stored functions as a custom process, then run
them using the SRE.
IMPORTANT: Ensure that the custom process does not call the SRE batch utility which would result in
an infinite loop.
Add or edit custom process pages to directory

Before you can run a custom process, you must add it to your Directory.
1. Create a new directory entry. See JDA Platform OnLine Expert.

2. Enter the Process Name.
3. Select the type (command-line or Stored function) from the Process type drop-down list.
Note: To run a stored function as a custom process, the following conditions must be met:
Application schema owner must have CREATE PUBLIC SYNONYM privileges.

WWF schema manager must have EXECUTE privileges on the stored function.

4. Enter the External command.

5. Select the delimiter used to distinguish the parameters from the External command delimiter
drop-down list.
6. In the Process timeout field enter a time duration, in seconds, after which you want the process
to terminate.
7. Select Participate in process chains to make the custom process available to process chains.
8. Click Done.
Assign a custom process to a role

After you create a custom process and before running it, you must assign it to a role. Only users with
this role can view or run the custom process.
1. Click Edit next to the role to view or change. The Edit Role page is displayed.
2. In the Role Information area edit the role's description. Other fields in this area are read only.
3. On the Access Control List tab, review or change the type of permission the role has to various
resources. Each row in the ACL defines the role's permissions to a specific resource. To add the
custom process to the ACL:
4. Click Add. The Create Access Control window is displayed. You can select additional resources
for which to assign permissions.
5. Click Done to return to the Edit Role page.
6. Click Done.
For more information, see JDA Foundation Administration Online Expert.
Assign a custom process to a node pool

After you create a custom process and before running it, you must assign it to a node pool. See "Add
or edit a node pool" section in the JDA Foundation Online Expert.
Troubleshooting SRE
This section is intended to help diagnose and solve common problems with service runtime
environment. Each error example suggests one or more remedies.
Error: The command-line prompt returns the following when launching SREBatchUtility:
com.manu.webservices.security.batchAuthentication.CredentialsException: Credentials Property

File contains a user name. It cannot be overwritten on the command line.
The user specified on the command-line does not match the user stored in the credentials.properties
file. Verify the user name and try again.
Error authenticating user - SuperUser.
The system could not authenticate the user name/password combination specified in the
credentials.properties file. Verify the user name/password and try again.
Error occurred during initialization of VM

Could not reserve enough space for object heap

The machine may not have sufficient memory resources to run the job.
Error: If the command-line prompt returns:
Attribute "Name" must be declared for element "processRequest".

Error parsing request file -
The request XML file has an invalid attribute called Name. Correct the file and run SREBatchUtility
again.
Error: The node pool manager does not start. Check the following:
Ensure that the pool is not already running. View running pools in Process Manager. For example,
you can have only one Basic node pool across your JDA Platform SRE architecture.
The JDA Platform Server and Oracle database server are running.
The pool name is valid and unique. Pool names are stored in table SRE_NODE_POOL.
Ensure that the machine has sufficient memory resources for the Java Options. Each node pool has
associated minimum and maximum memory allocation as set in table SRE_NODE_POOL. Insufficient
memory usually fails nodes in a pool. When the node pool manager re-creates them, the nodes fail
again.
Verify the database connection pool properties in file dbconnections.properties.
Error: The following error displays in NodePoolManager-<pool_name>.log when you attempting

to start a node pool:
15:34:15|com.manu.webservices.db.ManuDBException.log|com.manu.webservices.db.ManuDB
Exception: Database exception - java.sql.SQLException: ORA-04068: existing state of
packages has been discarded
ORA-04063: package body "WWFMGR.SRE_NODECONTROL" has errors
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 1
.
SQL Exception: java.sql.SQLException: ORA-04068: existing state of packages has
been discarded
This error indicates that script ManugisticsPkg.sql has not been run. Using SQL*Plus, run
ManugisticsPkg.sql as the jda_system user. Next, run enroll_app_schema.sql as the system user
and enter the application schema owner. Run enroll_app_schema.sql once for each application
schema. Try restarting the node pool.
Error: Jobs are requested but they do not run. Check the following:
Make sure the node pool(s) are running. Check their status in Process Manager.
Verify that the node pool(s) are configured to run the process, see Process Manager or table
SRE_NODE_POOL_CONFIG.
A job may be running that is using the nodes your job needs. Therefore, your job remains in the
queue until the nodes become available. Consider creating additional pool(s) for the processes.

Make sure an earlier job of the same process was not abnormally terminated. If this occurs, SRE
cleans up residual records. The jobs can be canceled in Process Manager.
The time delta among JDA Platform SRE instances and the JDA Platform Server must not exceed
the duration for property realm.auth.token.timeout.mins set in webworks_config.xml. If it does,
login exceptions can occur.
Make sure all instances of JDA Platform SRE use the same encryption.service.key as the JDA
Platform Server(s). This key is stored in file webworks_config.xml.
Error: Users initiate import/export or many-to-many copy in Flexible Editor. The browser returns:
Operation timed out. Export Failed.
Try setting SRE_TOTAL_TIMEOUT in Foundation System Properties to a value equal to or greater than
the value for SRE_NODE_CONFIG.BUILD_ACTIONS_TIMEOUT. FE processes use a single action, so if a
node is not assigned within SRE_TOTAL_TIMEOUT, then users receive the time out error.
Error: When submitting a job using SREBatchUtility, a database exception occurs:
using <Blank> as separator
This occurs because the input XMLfile specifies a blank space as a delimiter. This system attempts to
parse the blank space as a null value. Instead, specify a delimiter uses "space" as a keyword. For
example:
<option name="Gensys.ImportExport.Delimiter" value="space" />
Similarly, when using attribute Gensys.ImportExport.IncludeHeader for exporting data, use "true",
"yes", or "1" to generate column headers. The system interprets other values as false and no header is
generated.
System alerts
If a system alert displays in Process Manager, this indicates a failure. When the failure involves a node,
the system can recover. However, a job failure cannot be recovered. The following system alert is an
example of a job failure:
The job failed because the number of assigned nodes is less than the minimum required.
In this example, the job started but not enough nodes were available to run the jobs. The minimum
number of nodes for a process is specified in SRE_NODE_CONFIG.MIN_NODES.
SRE jobs fail when specific failures exceed set tolerances:
The job fails when the number of node failures during a particular job action exceeds the value in
SRE_SERVICE_INFO.ACTION_RETRY_LIMIT. (This table contains predefined process parameters and
you should not modify them.) The system alert identifies the pool of the failed node. This helps
identify which log file to review.
The job fails when the number of failed actions for a job exceeds the value in
SRE_NODE_CONFIG.IGNORE_ACTION_FAILURE_COUNT.
A job can also fail if the failures for nodes performing blocking or non-blocking initialization exceed
values in SRE_SERVICE_INFO.MAX_INIT_RETRIES. Again, you should not modify the values in this
table.

Troubleshooting methodology
If jobs fail or the same job repeatedly fails, follow these troubleshooting steps to identify the problem.
1. Examine the system alerts in Process Manager. Each node failure creates a system alert. Examine
the individual node and NodePoolManager logs on the machine where the node(s) failed.
2. Set the Level to verbose for each logger in the log4j2.xml file in the
<install dir>/config/properties directory.
3. Stop and restart the node pool manager(s).
4. Request the job again.
5. Examine the system alerts. Note the ID of any failing node(s).
6. In the NodePoolManager log, search for the failed node ID(s). This information reveals what the
node was doing when it failed.
Run a custom process

1. Open the custom process by clicking it in the Directory page. The custom process page is
displayed.
2. Select an option set from the Choose Option set drop-down list.
3. Enter the parameter values in the fields. The names of the option fields depend on the external
command provided while creating the custom process. You must provide appropriate values. You
can also save them as an option set or run the process with these values.
4. Click Run. The Job status window displays the progress of the job and the result log information.
Example 1: Custom process for command line script

You can add a command line script as a custom process to run tasks. The following steps provide an
example to add a command line script as a custom process. This script is an example of a command
line custom process. The script customProcessSampleShellCMD is located in the
<install_dir>\config\platform\sample directory. It accepts user input, concatenates the values,
and writes the output to the specified file (custom_process_test.txt) in the directory from which the
node pool is running.
2. In the Name and Description fields, enter information about the custom process.
3. In the Type drop-down list, select Custom Processes
4. In the Access drop-down list, select an entry; for example, Private to <user>
5. In the Process name field, enter HelloShellCmdNode.
6. For Process type select Command line
7. In the External command field, enter the following information:
a. Windows: ..\sample\customProcessSampleShellCMD.cmd !manu_user_name! !job_id! !CMD

Input!
b. UNIX: Use the absolute path such as

<install_dir>/config/platform/sample/customProcessSampleShellCMD.sh !manu_user_name!
!job_id! !CMD Input!
8. For External command delimiter, select !.
9. In the Process timeout field, enter 600.

11. Click Done.
Using Security Manager, assign the HelloShellCmdNode CP resource to a user's role with all
permissions.
Using the Node Pool summary page, open the Edit pool page for an existing nodepool (for example,
Basic) and assign HelloShellCmdNode CP to the nodepool.
Open the Custom Process launch page for the custom process from the Directory then enter
descriptive text (for example, testing command line custom process). Click Run. After successful
completion of the process, check the output file custom_process_test.txt in the directory where the
nodepool started from (for example, <install_dir>/config/bin/platform). The output should be in
following format: <manu_user_name>:<job_id>:<input string>.
Note: manu_user_name and job_id, used in this example, are two reserved words and can be used
as arguments while defining a custom process. The values of these pre-defined words is substituted
with the username running the process and the job id.
Example 2: Custom process for stored function

Using the steps in this example, you can add a stored function as a custom process. This custom
process calls Teststoredfunction, which inserts data into stored_function_output table in the application
schema.
You must run customProcessSampleCreateStoredFunction.sql and

customProcessSampleCreateTable.sql located in the config\platform\sample directory before
running this sample stored function.
1. Use SQL*Plus connect to the database as system user then grant CREATE PUBLIC SYNONYM to the
application schema owner. For example, GRANT CREATE PUBLIC SYNONYM TO SCPOMGR;
2. Connect to the database as the application schema owner and run

customProcessSampleCreateTable.sql. For example, sqlplus scpomgr/scpomgr @
customProcessSampleCreateTable.sql
3. Create a public synonym for the table created. For example, CREATE OR REPLACE PUBLIC
SYNONYM STORED_FUNCTION_OUTPUT FOR STORED_FUNCTION_OUTPUT;
4. Grant permissions to Foundation schema owner: For example, GRANT SELECT, INSERT ON
STORED_FUNCTION_OUTPUT TO WWFMGR;
5. Run customProcessSampleCreateStoredFunction.sql. For example, sqlplus scpomgr/scpomgr

@customProcessSampleCreateStoredFunction.sql
6. Create a public synonym for the function created: CREATE OR REPLACE PUBLIC SYNONYM
TESTSTOREDFUNCTION FOR TESTSTOREDFUNCTION;
7. Grant run permission on the TESTSTOREDFUNCTION to Foundation user. For example, GRANT
EXECUTE ON TESTSTOREDFUNCTION TO WWFMGR;
After you have run these scripts, create a custom process using the following steps:
1. Create a new directory entry. For more information about Adding directory pages see, Adding
directory entries in the JDA Platform OnLine Expert.
2. In the Name and Description fields enter the information about the custom process.
3. In the Type drop-down list select Custom Processes
4. In the Access drop-down list select an entry, for example Private to <user>
5. In the Process name field enter HelloStoredFunctionNode

6. In the Process type choose Stored function
7. In the External command field enter testStoredFunction(!manu_user_name!, !job_id!, !FUNC

Input!)
8. From the External command delimiter choose !
9. In the Process timeout field enter 600
10. Check Participate in process chains to make the custom process available to process chains.
11. Click Done.
Using Security Manager, assign the HelloStoredFunctionNode CP resource to a user's role with all
permissions.
Using the Process Manager - Node pool summary page. Open the Edit pool page for an existing
nodepool ( for example, Basic) and assign HelloStoredFunctionNode CP to the nodepool.
Open the Custom Process launch page for the above Custom process and enter some descriptive text
(for example, testing stored function custom process) and click Run.
After successful completion of process, check the STORED_FUNCTION_OUTPUT table for the output
data. The output is in following format:
Job:<job_id> run with input:<input string>:<manu_user_name>
Note: manu_user_name and job_id, used in the example above, are two reserved words and can
be used as arguments while defining a custom process. The values of these pre-defined words are
substituted with the username running the process and the job id.
Log files for troubleshooting SRE

Use log files in the following table to analyze job activity, troubleshoot problems, and trace errors.
Note: To record more details when running jobs, set the log level to debug for the logger name
value com.manu in the log4j2.xml file.
Log file Location Description

NodePool- \config\logs Each node pool manager writes to a log file on
<pool_name>.log the machine where it is running. The file is
called NodePool-<pool_name>.log in the
directory <install_dir>\config\logs. For
example, for the node pool Basic, the log file is
called NodePool-Basic.log.
The file includes stdout and stderr messages of
the pool. Set the log level to debug for the
logger name value com.manu in the
log4j2.xml file for complete information on
the child nodes.


Node-<node_id>.log \config\logs\ NodePool- A NodePool-<pool_name> folder is created
<NodePoolName> inside the <install_dir>\config\logs directory,
where each node pool writes to a log file on the
machine where it is running. The log file is
called Node-<node_id>.log. The maximum
size of this file is 10MB. This file rolls over to a
new file when the maximum size is reached and
the old log file is zipped and placed in the
directory
<install_dir>\config\logs\NodePool-
<NodePoolName>. In the directory, multiple
log files are generated for each node in the
node pool. For example: Node-1001.log and
Node-1000.log.
jdacore_<pool_name \config\logs When an SRE process runs into a critical error,

>_<job_id>_<node_ JEA logs additional details about the conditions
id>.log causing the error in this log file. The
<pool_name> refers to the SRE Node Pool that
is serving this particular job request, the
<job_id> refers to the unique number
allocated to this job request, and the
<node_id> refers to the SRE Nodes Process ID
that is processing the job request.
Tune Oracle for SRE

JDA Platform SRE provides parallel execution of processes. The number of node pool(s) and processes
you have running could affect the Oracle database server. Specifically, the number of database
connections and open cursors can quickly accumulate and exceed the number specified in the
initialization file, init<SID>.ora. A symptom of the problem can appear to be a leak of Oracle cursors.
IMPORTANT: An Oracle DBA should participate in tuning the following parameters. If necessary, add
them or adjust the following parameters for your environment.
processes
sessions
shared_pool_size
Return codes and job states

You should examine these when running jobs. Return codes are described in the following table.
Service runtime environment return codes for batch and SRE jobs
Text Description RETURN Code in
SRE_JOB_SUMMARY
and batch utility
NORMAL The process completed normally. 0
WARNING The process completed with one or 2

more non-critical issues.
ERROR The process completed with one or 3
more critical issues.


SRE_JOB_SUMMARY
and batch utility
FATAL_ERROR The process encountered a fatal issue 4
during runtime, and failed to
complete.
USER_TERMINATED The process was terminated at the 5
users request.
GLOBAL_SHUTDOWN The process was terminated because 6
a global shutdown was invoked by a
system administrator.
UNDEFINED_RESULT_CODE An undefined error code was returned 7
by the process.
BATCH_REQUEST_TIMED_OUT The batch request timed out. 8
JOB_FAILED_PREDECESSOR_FAILURE Job did not start, as a previous job in 9

the Process Chain failed.
Job states identify the progress of a job. The job states are described in the following table. When a
job runs, the job state displays in Process Manager. The number in parentheses do not imply the
required sequence of job states.
Job states
Job state Database value Description
(SRE_JOB:JOB_STATE)
Assign Job 0 The system assigns nodes to run the job. This is a normal
job state.
Blocking 1 The initialization state where a node performs any
Initialize prerequisite actions before processing begins. An example
of an initialization action is removing old data from a
results table. The initialization actions performed depend
on the process being run. Other nodes assigned to the job
are blocked from running other jobs. This is a normal job
state.
Non-blocking 2 The job is divided into actions (units of work) among the
Initialize assigned nodes. This is a normal job state.
Processing 3 The job is processing. This is a normal job state.
Actions
Cancel Job 4 The job was canceled by a user.
Blocking Finish 5 Processing is complete. This state occurs when the job
processed successfully. This is a normal job state.
Finished 6 The job is complete. This is a normal job state.
Resetting 7 Indicates the system is trying to recover from a failure. In

the user interface, an alert displays. This state only occurs
when a job fails during Blocking Init or Non-blocking Init
states.


(SRE_JOB:JOB_STATE)
Close Job 8 Processing is complete, but the job is not yet finished. Jobs
can enter this state even when a user canceled the job or
when processing failed. All nodes must complete
processing before the job enters this state. This is a
normal job state.
Assign Wait 9 Occurs only when chaining jobs. The first job in the chain
proceeds to Assign Job. Other jobs in chain remain in this
state until the first job completes.
The job errors are described in the following table.
Job errors - This maps to ERROR_CODE in SRE_JOB_SUMMARY and RETURN_CODE

in SRE_JOB
Job error Description
0 No job error.
1 Job was not assigned to nodes. This occurs when nodes are not available. Common
causes are:
no node pool(s) running for the process
number of available nodes is less than what is required for the process
2 The number of nodes working on the job fell below the minimum required as set in table
SRE_NODE_CONFIG.
3 Job initialization failed. This can occur when the job state is in blocking initialization or
non-blocking initialization, and the node fails or is stopped by a user. The number of
attempts to initialize the job exceeds SRE_SERVICE_INFO.MAX_INIT_ATTEMPT.
4 Job process actions failed. This can occur when the job state is processing and the
nodes cannot process the actions (units of work). The number of failed actions exceeds
SRE_NODE_CONFIG.IGNORE_ACTION_
FAILURE_COUNT.
5 Job blocking finish failed. This can occur when the job has finished processing, but the
job failed in blocking finish because a node failed during that job state.
6 Job close failed. The job finished processing, but the job did not close successfully.
7 Action failures have been ignored. This warning message displays if action failures occur
but the job is completed.
Note: To view the records run a query to join the SRE_ACTION records where
percent_complete < 100 with the application specific process table. For example, in the
case of Calculate Plan this is the ProcessSku table. This join displays all SKUs that may
not have been processed.
9 Job did not start to predecessor failure.

Note: If one of the jobs in a Process Chain fails, subsequent jobs in the chain that have
not run contain this error code.

Process Manager
You use the Process Manager to manage:
Running Jobs
Completed Jobs
Node Pools
Jobs In the Queue
A job is a process with configuration and options. You can launch jobs from the Process Manager user
interface.
For more information, see the Process Manager section in the JDA Platform Online Expert.
Enterprise Change Management

Enterprise Change Management (ECM) enables you to import and export system objects. This version
of ECM enables you to import and export the following system objects:
Directory listings for:
Flexible Editor instances
Compound Workspaces instances
Reports - if JDA Reporting is installed
Thin (web) Workbenches (Refer to SCPO Installation/Administration guide for more

information)
Rich Workbenches (Workbenches that are built using the Applet technology)
Security objects
Resources
Users, including associated roles.
Roles, including associated filters and access control lists.
Searches
Service Runtime Environment (SRE) objects
Custom Processes
Node Configurations
Node Pools
Option Sets
User Defined Columns (UDCs)
Monitor
Supported Business Rules for Business Rule Type:
Monitor (Data Comparison)

WebWORKS (User Status)
Notes:
You must import all Users before importing the Business Rules.
Following parameters should be available in the target server similar with the source server
before running mcmImport utility for the monitor business rules:
Priorities
User Groups
Users
Notification Templates
Parameter Workbench definitions for:
Parameter Groups
Parameter Rules
Hierarchy Manager
Cluster Manager
Note: To import the Cluster Manager, ensure that all the UDCs are imported. There should be at
least one Cluster under the Cluster type.
Cluster Metadata Columns
Note: To import the Cluster Metadata Columns, ensure that all the UDCs and cluster managers are
imported.
Following conditions should be met before you use the export and import feature of Change
Management:
1. User name in target instance should match with the username of source instance.
2. Encryption key (encryption.service.key) of target instance should match with the encryption key
(encryption.service.key) of source instance.
You can use the import and export features of Change Management to export these system objects
from one instance of JDA Platform to another instance. For example, you can export a system object
from a test environment to the production environment after you have tested and developed the
functionality.
Additionally, you can use the export functionality to take backups of system objects. In case you
require these system objects at a later time, you can import them to your JDA instance and start using
these system objects again.
Change Management provides the following commands to export and import system objects:
mcmExport, mcmImport, and mcmReport.
Notes:
Use Change Management to export system objects between two JDA instances that are of the
same release level (same version and patch). Importing to a JDA instance that is of a different
release level than the exported system is not supported.
If you create, update, or delete user defined columns, you must restart any running node pool
manager for the changes to be effective.

The data in the exported XML file will be in the format set by the database. In order to use the
file for import, after changing any values in the exported XML output, user preferences should
not be applied and only database formats must be used.
ECM import hierarchy

You must maintain a logical integrity when importing system objects. The following flowchart
represents the hierarchy you can follow while importing objects. For example, when importing security
objects, you must import Roles before importing Users.
Notes:
You must always import Security objects before importing SRE objects. For example, importing
a Custom Process would fail if the owner of the Custom Process does not exist in the target
system.
This hierarchy is intended to guide you in importing objects through ECM. However, it is not
mandatory to follow this sequence every time. For example, if you have updated only a Node
Pool definition, you can import this object alone rather than importing all the other objects
shown in the hierarchy.
Use mcmExport
Use the mcmExport command to perform three distinct operations.
Export the specified system object
Export the list of all system objects of a type to a list file
Export system objects that are specified in a list file
The mcmExport command is secured through the MCM Export resource. The user must be assigned a
CSM Role that has execute permission enabled for this resource. The syntax of the mcmExport
command is as follows:
mcmExport [-user <user>] -credentials <credentials> -supportedTypes
mcmExport [-user <user>] -credentials <credentials> -componentType <componentType> -

listFilename <filename> [-debug <filename>]
mcmExport [-user <user>] -credentials <credentials> listFilename <filename> -

exportFilename <filename>
mcmExport command parameters

Parameter Description
-user <user> -credentials Standard JDA User credentials

<credentials>
-supportedTypes Outputs a list system object types supported by MCM.
For example; SRE Node Configuration, SRE Option Set, Directory
FE Instance.
-componentType Specifies the component type for which to output a list of all
<componentType> identifying keys.
-listFilename <filename> Specifies the name of the file to which all system object identifying
keys of a given type will be outputted to. This file is in tab
separated value format (TSV).
-debug <filename> Enables the Debug option. The debug information is written to the
specified output file.
-exportFilename <filename> Specifies the file to which the requested system objects are
exported. This file is represented in an XML format.
For example, to export a list of SRE Node Configuration objects enter the command:
mcmExport -credentials credentials.properties -componentType "SRE Node Configuration" -

listFilename SRENodeConfig.listing
Edit the SRENodeConfig.listing using a text editor so that it contains entries only for the SRE Node
Configurations that you want to export. To export the SRE Node configuration of these nodes, enter
the command:
mcmExport -credentials credentials.properties -listFilename SRENodeConfig.listing -

exportFilename SRENodeConfig.xml
The SRENodeConfig.xml file contains the key information of all the Node Configurations specified in the
list file. You can save this file and import it to another instance of JDA applications using the
mcmImport command.
Use mcmImport
Use the mcmImport command to import the system objects, that you have exported using the
mcmExport command, to a JDA instance.
The mcmImport command is secured through the MCM Import resource. The user must be assigned a
CSM Role that has execute permission enabled for this resource. The syntax of the mcmExport
command is as follows:
mcmImport [-user <user>] -credentials <credentials> -importFilename <filename> [-

upsert] [-schemaMapping <fromSchema1:toSchema1,fromSchema2:toSchema2,...>]
mcmImport command parameters
<credentials>
-importFilename <filename> Specifies the name of the file to import from.
-upsert If used, this parameter specifies whether each component in the import
file is either updated in the JDA instance or inserted if it doesnt
already exist. Without this option, existing data is not updated.

-schemaMapping This optional parameter provides a mechanism to map the schema
<mappings> names in the import file to new values that match the schema name(s)
on the destination system. The syntax of the parameter value is as
follows:
"fromSchema1:toSchema1, fromScheam2:toSchema2, "
For example;
-schemaMapping "CSMMGR:WWFMGR, STSC:SCPOMGR".
One or more schema mappings can be specified.
For example, to import SRE Node configurations from the file "SRENodeConfig.xml" use the command:
mcmExport -credentials credentials.properties importFilename SRENodeConfig.xml
Notes:
If you export a Flexible Editor instance containing a user defined column, on importing this
Flexible Editor instance to another JDA application instance where the table does not have this
user defined column no error is displayed. For Change Management to work effectively the
different application instances must be identical.
Importing SRE Custom Process component does not assign the custom process to roles and
node pools. Before you can use the Custom Process you need to assign it to roles and node
pools manually.
Importing CSM User does not change the User Account Status, if the user already exists on the
target system. For example if you use the [-upsert] option while importing CSM User objects,
all information is updated for existing users except the account status information.
When you export and import a role through mcmimport or ecmconsole whose resource ACLs
are changed, you must restart the Platform application server.
Data imported using mcm export and import are visible in the target server once the metadata
refresh is done.
Use mcmReport
Use the mcmReport command to generate a report of all successful import operations made using the
mcmImport command. You can use the mcmReport command to generate a report containing the
details of a specified import operation. The mcmReport command is secured through the MCM Import
resource. The user must be assigned a CSM Role which has execute permission enabled for this
resource. The syntax of the mcmReport command is as follows:
mcmReport [-user <user>] -credentials <credentials> reportId reportFilename

<filename>
mcmReport [-user <user>] -credentials <credentials> -history
mcmReport command parameters

<credentials>
-history Generates a listing of all successful import operations. This listing
includes the unique identifier (reportId), Component Type, User
and Timestamp for each import operation.

-ReportID Specifies the unique ID of the operation about which to retrieve

information. You can find the reportId in the MCM_REPORT
database table. The details are described in an XML formatted file.
-reportFilename <filename> Specifies the name of the file to which the report is written to.
For example, to generate a report and write it to a file named report77.xml use the command:
mcmReport -credentials credentials.properties -ReportID 77
reportFilename report77.xml
Process Manager
You use the Process Manager to manage:
Running Jobs
Completed Jobs
Node Pools
Jobs In the Queue
A job is a process with configuration and options. You can launch jobs from the Process Manager user
interface.
For more information, see Process Manager section in the JDA Foundation Online Expert.
Use SRE Custom processes

In addition to running standard built-in processes, you can run custom processes using JDA Platform
SRE. This feature enables you to run your command line scripts or PL/SQL stored functions using the
SRE. You can register your commonly used scripts and stored functions as a custom process, then run
them using the SRE.
IMPORTANT: Ensure that the custom process does not call the SRE batch utility which would result in
an infinite loop.
Add or edit custom process pages to directory

Before you can run a custom process, you must add it to your Directory.
2. Enter the Process Name.
3. Select the type (command-line or Stored function) from the Process type drop-down list.
Note: To run a stored function as a custom process, the following conditions must be met:
Application schema owner must have CREATE PUBLIC SYNONYM privileges.
WWF schema manager must have EXECUTE privileges on the stored function.
4. Enter the External command.
5. Select the delimiter used to distinguish the parameters from the External command delimiter
drop-down list.

6. In the Process timeout field enter a time duration, in seconds, after which you want the process
to terminate.
8. Click Done.
Assign a custom process to a role

After you create a custom process and before running it, you must assign it to a role. Only users with
this role can view or run the custom process.
1. Click Edit next to the role to view or change. The Edit Role page is displayed.
2. In the Role Information area edit the role's description. Other fields in this area are read only.
3. On the Access Control List tab, review or change the type of permission the role has to various
resources. Each row in the ACL defines the role's permissions to a specific resource. To add the
custom process to the ACL:
4. Click Add. The Create Access Control window is displayed. You can select additional resources
for which to assign permissions.
5. Click Done to return to the Edit Role page.
6. Click Done.
For more information, see JDA Foundation Administration Online Expert.
Assign a custom process to a node pool

After you create a custom process and before running it, you must assign it to a node pool. See "Add
or edit a node pool" section in the JDA Foundation Online Expert.
Configure alternate text

JDA Platform provides support to display an alternate text to refer to the corresponding column of a
database table on the JDA Platform application user interface. The textual representation of the
alternate text is used by the lookup component to substitute the user specified schema/table/column
with the base schema/table/column pair before performing the query to build the display list for
lookup.
You can configure the alternate text in the following ways:
Run EnrollUDT utility to enroll a user-defined table. For more information, see Enroll a user-defined
table (on page 210).
Run UpdateBaseColProps utility.
Create alternate text field using UpdateBaseColProps utility

Use SQL*Plus to configure the alternate text field.
1. The JDA Platform Server must be running.
2. Connect to the JDA application schema. For example,


5. Using a text-editor create the file BaseTableCol.properties. If you are migrating from previous
release to JDA Platform 2016.1.0.x, then open the file BaseTableCol.properties at the location
6. Update the BaseTableCol.properties file in the following format-

SCHEMA.TABLE.COLUMN(user specified)=SCHEMA.TABLE.COLUMN(Base)
For example:
WWFMGR.TEST.LOCATION= WWFMGR.LOC.LOC
7. Run utility UpdateBaseColProps using the following syntax:

UpdateBaseColProps BaseTableCol.properties_path credentials_file [logFilePath logFileName]
The process requires the following options:

BaseTableCol.properties_path The absolute path of this BaseTableCol.properties Yes
file.
<credentials_file> The name of the credentials file containing either Yes
the user name/password combination or only the
password for the batch user. If in a different
directory, then specify the absolute path. For
example, credentials.properties. For more
information on creating a credentials file, see "Use
encrypted batch authentication" (on page 169).
logFilePath The absolute path of the log file. No
logFileName The name of the log file. No
Notes:
If no logFileName is specified, then a log file is created at the logFilePath with a default name
BaseTableCol.log
If no logFilePath and logFileName is specified, then a log file is created at the

<install_dir>\config\bin\platform with a default name BaseTableCol.log.
User-defined tables
JDA Platform provides limited support for a user-defined table (UDT). A UDT is a database table
created by you, usually for custom data. The table is not predefined by a JDA application schema, so
the JDA application software cannot use a UDT. However, you can enroll the UDT with JDA Platform.
Enrolling means that you create metadata about the UDT. This metadata enables Flexible Editor, Data
Model Manager, and Searches to use the table. You should have a DBA participate in this process.
Enrolling a UDT requires restarting the JDA Platform Server.
IMPORTANT: Back up your database before proceeding.
Create a user-defined table

You can create the UDT in a JDA application schema. You can create the table after you migrate or
create the JDA application schema. Create the table using Oracle utilities. Observe the following rules
when you create the table:
Create the UDT in a JDA application schema. The table cannot be in a separate SID or schema.

The UDT can have a primary key. The UDT must have at least one Primary Key for Flexible Editor
and Compound Workspaces to work properly.
Define a default value for all columns in the UDT. Otherwise, you could corrupt your database.
Use the following Oracle data types, which can be mapped to JDA logical data types. Other data
types cannot be mapped.
Data type mapping
Oracle physical data type JDA logical type
VARCHAR2, VARCHAR, NVARCHAR2 TEXT
FLOAT, NUMBER (when scale > 0) DECIMAL
INTEGER, NUMBER (when scale = 0) INTEGER
DATE DATE
See "Additional rules for user-defined tables" (on page 213).
The following example uses SQL*Plus to create a user-defined table:
1. Connect to the JDA application schema. For example,

sqlplus scpomgr/scpomgr@<NetServiceName>
2. The table TEST has three columns: NAME, LOCATION, and UPC. NAME is the Primary Key.
create table TEST
( NAME VARCHAR2(30), LOCATION VARCHAR2(30), UPC NUMBER(6),
Primary Key (NAME)
);
3. Commit the new table.
Enroll a user-defined table

After creating the table, run enroll_app_schema.sql as the system user to grant the appropriate
access to the newly created table. Next, enroll the table by creating metadata for the table by running
JDA Platform utility EnrollUDT. The utility creates metadata based on command-line options and
generates a script.
Note: While enrolling a user-defined table you must ensure that the table name is less than 26
characters.
Before you enroll a UDT, you need to either create or identify an entity in the CSM_ENTITY_INFO table
that will be used to control the security for the table. You can use a single entity to control multiple
tables (for example, UDT), or you can create a specific entity to control the particular table. When you
run the command to enroll the UDT, you must specify the name of the entity. To create an entity,
enter the entity name in the CSM_ENTITY_INFO table and then map it to the relevant application in
the CSM_ENTITY_APP table. After you have done this, you can use the Security UI to create a resource
for the entity.

4. Run utility EnrollUDT using the following syntax.

EnrollUDT <output_file> <credentials_file> <UDT_table_name> <schema_name>
<entity_name> <application_name> [<alike_table> <alike_col> <UDT_col>
The process requires the following options:
<output_file> The primary output file name. EnrollUDT generates this file Yes
using the options specified at the command line. This file uses
SQL syntax. For example, test.sql.
EnrollUDT generates a second output file to support dynamic
navigation. This file name has a prefix of KeyTabGen_
followed by the name of the primary output file, for example,
KeyTabGen_test.sql.
<credentials_file> The name of the credentials file containing either the user Yes
name/password combination or only the password for the
batch user. If in a different directory, then specify the
absolute path. For example, credentials.properties. For more
information on creating a credentials file, see "Use encrypted
batch authentication" (on page 169)
<UDT_table_name> The name of the user-defined table for which metadata is Yes
being generated.
<schema_name> The name of the schema that owns the user-defined table. Yes
For example, scpomgr.
<entity_name> The name of the entity from which a table inherits all its Yes
permissions. This can be any of the entities already available
in Security Manager. A valid entity name that maps to the
application should be provided. You can obtain this
information from CSM_ENTITY_APP.
<application_name> The name of the application associated with the user-defined Yes
table. For example, SCPOWeb. The application name is case
sensitive. Refer to CSM_APPLICATION.APPLICATION_
NAME for a list of applications.
<alike_table> Specify a JDA application table to base relation information No

on. For example, DFU or SKU. EnrollUDT uses this table to
create relations for the user-defined table. The utility uses
values in MD_TABLE_RELATION for the information.

<alike_col> The name of the column from <alike_table> to base relation Yes, if you
information on. EnrollUDT uses this column to create relations specify
for the specified column in the user-defined table. The utility <alike_table>.
uses MD_TABLE_RELATION_JOIN for the information.
Note that you can repeat this option by specifying multiple
columns from the alike table.
IMPORTANT: You must provide a mapping between all
columns in the application table for which relations are
defined and the columns in the user-defined table using this
command option. Otherwise, you may experience errors when
running the output scripts generated by EnrollUDT.
<UDT_col> The name of the column in the user-defined table to which Yes, if you
<alike_col> corresponds. EnrollUDT generates metadata for specify
the column based on the alike column. <alike_col>.
Note that you can repeat this option. Each <alike_col> maps
to one <UDT_col>.
Example: In the following example, test.sql is the primary output file, credentials.properties contains
the user name/password combination, TEST is the user-defined table, STSC is the schema name that
owns the user-defined table, TestEntity is the entity name, SCPOWeb is the application, SKU is the JDA
application alike table, ITEM and LOC are the alike columns from the table SKU, ITEM_NEW and
LOC_NEW are the columns in the user-defined table TEST.
This example also repeats the alike column options. This means that TEST.ITEM_NEW will have the
same relations as SKU.ITEM, and TEST.LOC_NEW will have the same relations as SKU.LOC.
EnrollUDT test.sql credentials.properties TEST STSC TestEntity SCPOWeb SKU ITEM ITEM_NEW LOC
LOC_NEW
Run output scripts

After you run EnrollUDT, run the output SQL scripts to create metadata for the UDT and enable
dynamic navigation for the new table. The script names are based on the value you specified for the
<output_file> option when you ran EnrollUDT.
2. To create metadata for the UDT:

a. Connect to the database as the Foundation schema owner. For example,
b. Using SQL*Plus, run the primary output script.

@test.sql
This script loads the metadata into the Foundation schema and creates a resource for the user-
defined table.
c. Review the log file for errors. In this example, the log file is test.sql.log.
3. To enable dynamic navigation for the UDT:
a. Connect to the database as the application schema owner. For example:

sqlplus scpomgr/scpomgr

b. Using SQL*Plus, run the dynamic navigation output script. For example:
@KeyTabGen_test.sql
This script enables dynamic navigation for the user-defined table.
c. Review the log file for errors. In this example, the log file is KeyTabGen_test.sql.log.
4. After creating a table, use SQL*Plus to run enroll_app_schema.sql as the system user to grant the
appropriate access to the newly enrolled table. Enter the application schema owner when
prompted.
5. Restart the JDA Platform Server.
Assign resource for the user-defined table

After you run the output SQL files, assign the resource for the user-defined table to the appropriate
roles. Users cannot use the UDT until the resource is added to their roles. Assign the resource in
Security Manager. For example, if the user-defined table is TEST, then the resource type is Table and
the resource name is TEST. The table belongs to the SCPO Suite application if you specified SCPOWeb
as the application name for EnrollUDT.
IMPORTANT: You must restart the JDA Platform Server before users can access the table.
Additional rules for user-defined tables

The UDT cannot be time allocatable.
The EnrollUDT utility generates English display values for all languages in
MD_COLUMN_TRANS.DISPLAY_NAME. You can modify the generated SQL output file to contain the
translated values. You can also use the Data Model Manager to change the values after the UDT
has been added to metadata.
The minVal, maxVal, and default are based on the physical schema.
The UDT cannot contain a domain OPTION_NUMBER or OPTION_TEXT.
The Simulation or CPP tables are not supported.
The UDT can be viewed and edited in Data Model Manager.
Change default display properties

You can change some JDA Platform system properties that affect the user interface, including
formatting and font properties. These values should be adjusted based on the anticipated volume of
data. For font properties, consider usability factors for all users before making changes. Examine the
changes in a test environment before deploying to a production environment. In some cases, you must
restart the JDA Platform Server before the changes take effect. For more information on System
Properties, see JDA Platform System Properties topic in the JDA Foundation Online Expert.
Edit resource files for double-byte languages

In a translated release, JDA Platform and JDA applications provide resource files in several languages.
For double-byte languages such as Japanese, the files are encoded in ASCII. You can customize these
files, but you must edit them in their native encodings, which means that you must convert them from
ASCII to the native encoding. Then, edit the files, and after making edits, change the files back to
ASCII. Otherwise, they do not function on the server. Use the native2ascii utility provided by
application servers to convert the files.
1. Back up the files to be modified.

2. The native2ascii utility is located in directory <JAVA_HOME>\bin. Change to this directory or add
the directory to your path environment variable.
3. Convert the file from ASCII to the native encoding. Use the following syntax:
native2ascii -reverse -encoding <code> <inputfile> <outputfile>
where <code> is the native encoding, <inputfile> is the source file and <outputfile> is the
resulting file. For example, to convert the source file SecurityResourceBundle_ja.properties to
SecurityResourceBundle_ja.SJIS in Japanese:
native2ascii -reverse -encoding MS932 SecurityResourceBundle_ja.properties
SecurityResourceBundle_ja.SJIS
For example, in the case of Monitor, to convert the source file MonitorClientResource_ja.properties
to MonitorClientResource_ja.SJIS, enter the following:
native2ascii -reverse -encoding SJIS MonitorClientResource_ja.properties
MonitorClientResource_ja.SJIS
Use the encodings below for your double-byte language.
language encoding
Japanese MS932
Simplified Chinese MS936
Traditional Chinese MS950
4. Using a text editor, edit the output file. In this example, SecurityResourceBundle_ja.SJIS is the
output file.
Convert the edited file back to ASCII. Use the following syntax. Remember, the output file from
above is now the input file. The resulting file must match the original file name or the server does
not use it. For example,
native2ascii SecurityResourceBundle_ja.SJIS
SecurityResourceBundle_ja.properties
Change task statuses

Users can customize tasks on the Welcome page and assign a status to each task by selecting the
check box next to the task. Three default statuses are available: Not Started, In Progress, and
Completed. File vptaskstatus.xml in directory <install_dir>\config\properties stores the default
statuses and references to the images used to display the different check boxes. File
ViewPointResourceBundle.properties contains the text used in the tool tips, for example,
Completed. If you change the text displayed in the tool tip, you must restart the JDA Platform Server.
In the example, sample 3 has three tasks. The user assigned a different status to each task:
Not Started (Process Manager)
In Progress (Run Business Rules)
Completed (Search)
Change task statuses

1. Navigate to directory <install_dir>\config\resources.

2. Using a text editor, open ViewPointResourceBundle.properties.
3. Search for the following lines:

Vp.TaskStatus.Cleared=Not Started
Vp.TaskStatus.Visited=In Progress
Vp.TaskStatus.Completed=Completed
4. Change the text. For example,

Vp.TaskStatus.Completed=Finished
5. Save ViewPointResourceBundle.properties and exit the editor.
Disable task statuses

1. Change to directory <install_dir>\config\properties.
2. Using a text or XML editor, open vptaskstatus.xml.
3. Search for the following lines:

<taskStatusConfig enabled="true" resourceBundle=ViewPointResourceBundle">
4. Change value for attribute enabled to false.

<taskStatusConfig enabled="false" resourceBundle=ViewPointResourceBundle">
5. Save vptaskstatus.xml and exit the editor.
Modify server and browser properties

The installation automatically configures several properties files and resource bundles. The flexibility of
the servlet framework allows the server administrator to change the default menu text and messages
displayed both on the browser interface and the server. On the browser, this includes informational
and error messages as well as portions of the user interface. On the server, this includes informational
and error messages.
Resource bundles enable the JDA Platform Server to display Web pages in the users preferred
language. A resource bundle is a collection of files, with one file for each supported language. For
example, in a translated version, the file SecurityResourceBundle.properties has a Spanish
equivalent called SecurityResourceBundle_es.properties. If using a version that supports
translation, a user can select the preferred language from a list of supported languages. Some JDA
Platform-based applications provide additional resource bundles for their web pages. When you edit a
resource file, you should edit all resource files in that bundle. Otherwise, the changes are not available
in all languages.
Changing the properties and resource bundles affects the text displayed, but does not change how web
pages and messages are processed. Most files contain name-value pairs. If you modify the properties
files, be careful to edit the value, not the name.
JDA Platform properties files and resource bundles

Property file/resource bundle Location Description
IGPResourceBundle.properties config\resources Resource bundle for Interface
Generation Program (IGP).
ImportResourceBundle.properties config\resources Contains error codes for the
batch command csmImport.


installer.properties <install_dir>\install Contains the JDA Platform
version and original parameters
set during installation. Do not
modify this file.
webworks_config.xml config\properties Contains local settings that are
specific to the local installation.
The webworks_config.xml must
be properly configured or the
server cannot start. If you
change this file, you must
restart the JDA Platform Server.
SearchResourceBundle. properties config\resources Contains error and informational
messages associated with
querying the database.
SecurityResourceBundle. properties config\resources Contains error and informational
messages.
SecurityUIResourceBundle. properties config\resources Contains titles, text, and error
messages associated with the
Security Manager user interface.
SREResourceBundle.properties config\resources Contains service runtime
exception, status, and log
messages.
SOAPCredentials.properties config\properties This file is needed only for IBM
Websphere. It contains
information about the SOAP port
and Host.
In a clustered environment, the
soap_port and host are
deployment manager's soap
connector port and host
$WAS_HOME\profiles This file is needed only for IBM
\<profile name> Websphere.
soap.client.props \properties\ This file contains properties that
are used by the JMX SOAP
Connector Client.
ViewPointResourceBundle. config\resources Contains validation and format
properties error text; login page text; and
local information: languages,
time, and date formats.
wcif.properties config\properties Contains name/value pairs for
the WebConnect Integration
Foundation.
wcifExceptionResourceBundle.properties config\resources Contains exception messages
for WebConnect Integration
Foundation.
wcifResourceBundle.properties config\resources Contains error messages for
WebConnect Integration
Foundation.


WebServicesResourceBundle config\resources Contains exception messages.
.properties
2. Using a text editor, open the properties file that you want to modify. For example, if you want to
change the text on the login page, open ViewPointResourceBundle.properties in directory
<install_dir>\config\resources.
3. Find the specific property that you want to modify. For example, if you want to change the text for
the User Name prompt, find the vpLoginPage section:
## for vpLogin Page
vp.username=User Name
4. Type the new value for the property. For example, to change User Name to User ID, enter the new
value to the right of the equal sign:
vp.username=User ID
5. Make the same change in each ViewPointResourceBundle_<language>.properties file. For

example, ViewPointResourceBundle_en.properties.
Note: For Japanese language users, edit the files in the native encoding. See "Edit resource files
for double-byte languages" (on page 213).
6. Save the properties files and exit the editor.
Create audit baseline data

This utility supports auditing of data in Parameter workbench. The utility creates a base line of the
audit data by creating a fresh set of audit data in all parameter workbench audit tables.
In the following scenarios, you need to clean out the audit data and populate them with existing rules
and fresh set of audit data:
During the data migration from JDA Platform 7.8.0.0 to 2016.1.0.x.
Note: The migration scripts ensure that the audit data is cleaned out and populated with existing
rules and fresh set of audit data.
Any changes in column/hierarchy ranking.
Run the script pwb_bootstrap_data.sql as Foundation schema owner from the directory
<install_dir>\config\database\platform.
For example, sqlplus <wwfmgr>/<wwfmgr> @pwb_bootstrap_data.sql
Change schema name and password

This section includes detailed steps for changing the Oracle password and schema name after
installation using a change credentials utility. The utility allows you to change the Oracle schema name
and password and keep the accounts secure. The password and schema name can be changed after
installation of JDA Platform and additional JDA applications without having to uninstall or reinstall the
application.

Notes:
You do not need to re-configure the JDA server to change the password or schema name.
However, if you do need to re-configured the server, run the BuildConfiguration script to
update the passwords before configuring the JDA Server.
In an application server cluster, you must run the utility to change the password or schema for
each server node.
If you have installed a separate SRE installation, you must run the utility on every SRE
installation separately.
To run ChangeDbCredentials on Weblogic:
1. Stop the JDA Platform server.
2. Open a command line or shell prompt.
3. Change the directory to <install_dir>\config\bin\platform (windows) or

<install_dir>/config/bin/platform (UNIX).
4. Run the script ChangeDbCredentials. The usage of the command is:

ChangeDbCredentials -schema oldSchema newSchema
ChangeDbCredentials -password schemaName
Example: ChangeDbCredentials schema WWFMGROLD WWFMGRNEW
Where "WWFMGROLD" and "WWFMGRNEW" are the old schemaName and new schemaName
respectively.
Example: ChangeDbCredentials password WWFMGR
Where WWFMGR is the schemaName for which the password needs to be changed.
5. Enter the old schema and new schema names.
6. Enter the new password.
Note: Ensure that the database password matches the new password; otherwise the server
displays an invalid login or password error when it is started.
7. Renter the new password for confirmation.
8. Repeat Step 4 7 for all the schemas for which you want to change the password or schema
name. Restart the JDA Platform server.
Note: The utility encrypts the new password in dbconnections.properties by default.
To run ChangeDbCredentials on IBM Websphere:
1. Stop the JDA Platform server.
2. Ensure that the Deployment Manager and managed server WebSphere processes are running.
3. Open a shell prompt.
4. Change directory to <install_dir>/config/bin/platform.
5. Run the script ChangeDbCredentials. The usage of the command is:

ChangeDBCredentials -schema oldSchemaName newSchemaName <admin_user>
<admin_password>
ChangeDBCredentials -password schemaName <admin_user> <admin_password>

Example: ChangeDbCredentials schema WWFMGROLD WWFMGRNEW appAdmin password
Where "WWFMGROLD" and "WWFMGRNEW" are the old schemaName and new schemaName
respectively.
Example: ChangeDbCredentials password WWFMGR appAdmin password
Where WWFMGR is the schemaName for which the password needs to be changed.
6. Enter the old schema and new schema names.

7. Enter the new password.
8. Renter the new password for confirmation.
9. Repeat Step 4 - 7 for all the schemas for which you want to change the password.
10. Re-start the JDA Platform server.
Notes:
Ensure that the database password matches the new password; otherwise the server displays
invalid login or password error when it is started.
The utility encrypts the new password in dbconnections.properties by default.
Ensure that IBM profile server is running.
Infrastructure Services Launcher

The Infrastructure Services Launcher is a Java utility that contains an embedded Jython interpreter
that is used to run Python scripts independent of the platform. Python is a scripting language that is
similar to Perl, but uses much cleaner, object oriented syntax. Jython is a Java implementation of
Python. Jython already implements much of Python and its standard library except where the
limitations of Java prevent it. For additional information on the Infrastructure Services scripts that are
used to create and maintain an Infrastructure Services solution, see the View script usage information.
Configuration
Before the launcher is used, set the system properties. The launcher requires a path to run the Java
executable file. When the launcher is started, it searches for the following information in the
settings.xml file located in the <Infrastructure Services root directory>/cis-sdk/conf directory.
<i2config>

<JDK_HOME>C:/tools</JDK_HOME>
<JAVA_HOME>C:/tools/jre</JAVA_HOME>
Note: All the fields in the settings.xml file may not be used.
If the <JAVA_HOME> field in the settings.xml file or settings.xml file is not found, the JAVA_HOME
system variable is used to determine the path to the Java location. If value of JAVA_HOME is not
found, the Java executable file in the system PATH is used.
If the script fails to find the value of JAVA_HOME in the settings.xml file or from the environment,
the following warning is displayed:
No JAVA_HOME found in <Infrastructure Services root directory>\cis-

sdk\conf\settings.xml, trying environment
No java executable found at JAVA_HOME=""
Trying to use java found in PATH
Note: Every time when settings.xml is modified, you have to run configure.py.

Start the launcher

Current console mode
The script to launch the CIS launcher is located in the <Infrastructure Services root directory>/cis-
sdk/bin directory. There are several Python scripts available in this directory that can be run regardless
of the operating system used.
Start the launcher in the current console on Windows

1. Navigate to the Start > Apps > Windows System > Command Prompt.
2. Enter the <Infrastructure Services root directory>/cis-sdk/bin directory, and then press
Enter.
3. Run the launch [options] [scriptfile argc...] command.

If you run the launch [options] [scriptfile argc...] command as a script file without options, it
runs the Python script in the same console.
For example, if you want to use the Infrastructure Services Launcher to run the createBroker.py
script in the same console, run the launch brokerCreate.py cam23079 InlineBroker command.
This command creates a broker called InlineBroker on the webMethods Enterprise Server,
cam23079.
Start the launcher on Windows

1. Navigate to Start > Apps > Windows System > Command Prompt.
Enter.
3. Run launch -h command.
The following message is displayed:
Usage: launch [options] [scriptfile args...] With no arguments, runs a GUI

launcher. If scriptfile is specified, runs it with the given args in the current
console, or a gui console if -g is specified
Options:
-h This message.
-i Runs an interactive interpreter.
-g Runs scriptfile in a GUI console.
-d [addr] Java processes get run with JPDA debug flags,
listening on optional addr.
-p The python script will be run in the python
debugger.
-n The python script will be run detached (nohup).
-o Force GUI consoles to remain open when scripts
exit.
-e <string> Executes the given string in the title for GUI
windows.

-t <title> Uses the given string in the title for GUI windows.
-c <config> Uses the preferences file associated with config.
-D prop=value Sets the java system property prop to be value.
Start the launcher on UNIX

Enter.
3. Run ./launch.sh.
The following message is displayed.
Usage: launch [options] [scriptfile args...]

With no arguments, runs a GUI launcher. If scriptfile is
specified, runs it with the given args in the current console,
or a gui console if -g is specified
Options:
-h This message.
-i Runs an interactive interpreter.
-g Runs scriptfile in a GUI console.
-d [addr] Java processes get run with JPDA debug flags,
listening on optional addr.
-p The python script will be run in the python
debugger.
-n The python script will be run detached (nohup).
-o Force GUI consoles to remain open when scripts
exit.
-e <string> Executes the given string as python code.
-t <title> Uses the given string in the title for GUI windows.
-c <config> Uses the preferences file associated with config.
-D prop=value Sets the java system property prop to be value.
If you run launch.bat (or .sh) with the -c <config> option, where <config> is the name of an
Infrastructure Services Launcher properties file, the Infrastructure Services Launcher starts using that
file rather than the default file launcherProperties.xml. You can start the Infrastructure Services
Launcher with different configurations.
Edit the launcher properties file to provide the greater user interface configurability.
Add scripts to favorites

Run the runCISAgent.py script in the Favorites folder as follows:
<favorites>
<favorite name="runCISAgent.py" file="F:\jda\CIS\2016.1\cis-sdk\

bin\runCISAgent.py" />
</favorites>
Hide the scripts

You can hide a script by defining a path within the <hiddenfiles> section of the file.
<hiddenfiles>
<path>F:\jda\CIS\2016.1\cis-sdk\bin\b2bDisablePackage.py</path> </hiddenfiles>
User interface mode

The CIS Launcher user interface is displayed when the launch script is run without options, script file
names, or arguments.
Infrastructure services launcher user interface

Start the infrastructure services in user interface mode
Enter.
3. Run the launch.bat command without options, script files, or arguments. The Infrastructure
Services Launcher user interface is displayed.
Run a script
1. Locate the script that you want to run in the Launcher Scripts folder.
2. Select the Close when Complete Flag check box if you want to close the launcher console user
interface immediately after the script completes.
3. Select the Java Debug check box to enable debugging for the Java processes that you run in the
script. Use the launcher.setDebugAddress() to set an address for the debugger. This argument
suspends the Java process until the debugger attaches itself to the address.
Note: If you do not provide an address for the debugger, then it selects a random free port.
4. Select the Python Debug check box to enable debugging for the Python processes that you want
to run in the script.
5. Enter the arguments in the script argument field.
6. Select the row corresponding to the script, and click Start. The Infrastructure Services Launcher
user interface opens a new Infrastructure Services Launcher Console user interface and runs the
script.
Note: You can click Start twice to run the multiple instances of the same script.
Infrastructure Services launcher console user interface

When you run the script in the Infrastructure Services launcher user interface, Infrastructure Services
launcher console user interface is displayed. stdout (output) is displayed in black, stderr (error) in
red, and stdin (input) in blue.
The following buttons are displayed in the Infrastructure Services launcher console user interface:

Icon Description
Scroll Lock Enables the Infrastructure Services Launcher Console user
interface to follow as new text is added. When unchecked, a
static view of the text is displayed, even though more output
may be added at the bottom.
Word Wrap Enables wrapping.
Close on Exit Closes the launcher console user interface immediately after the
script finishes. This is a toggle button. The initial setting is based
on the Close on Exit flag in the Infrastructure Services Launcher.
Find Launches a search dialog box that enables you to search for text
in the Infrastructure Services Launcher Console user interface.
You can use standard wildcards or plain text. You can press
Ctrl+F to view this dialog box. You can press Ctrl+F3 to
highlight the text in the window and search for it. To find the text
again, continue to press F3.
Clear Clears the output buffer.
Kill Stops the script and processes that are running.
Infrastructure services overview

JDA Infrastructure Services (CIS) provides single sign-on management for the JDA applications
installed on Platform.
Management Services
The CIS Management Services include the following:
CIS Agent
Infrastructure Services Manager
CIS Agent
The CIS Agent manages Application Integrator adapters. It provides registry and location information
about adapters to Application Integrator clients dynamically. The CIS Agent runs as Windows or UNIX
on the system where CIS is installed to run the Application Integrator or Data Integrator. The CIS
Agent is not required to run on the Application Integrator client system. Client components may be
referred as the CIS Agent on the network. Generally, they refer to a central hub CIS Agent.
Infrastructure Services Manager

The Infrastructure Services Manager is a web user interface for managing product adapters and
scripts. It is the frontend for the CIS Agent. It displays the basic status and configuration information
and permits a number of fundamental operations, such as starting and stopping adapters. For more
information on the Infrastructure Services Manager, see Manager.
Security Services
The CIS Security Services are divided as follows:
Authentication: The standard architecture used by JDA applications and integration workflows to
authenticate end users.

Single Sign-On: The architecture enables JDA applications and workflows to share user identity
across a session, so that an end user is authenticated by an application one time in a multiple
application workflow.
Single sign-on
The authentication architecture supports single sign-on (SSO) between JDA applications and between
JDA and non-JDA applications. When a passive authentication module is used within the JDA
application, the implicit assumption is that the entire architecture operates under the control of an
external authentication regime. In such a situation, it is the responsibility of the external system to
make sure that the end user is challenged one time in a working session. The passive login modules
participate in the single sign-on protocol. The module never challenges the end user and accepts the
proof of authentication generated by the external system to establish user identity within the JDA
application.
However, when an active authentication module, such as LDAP or Delegator is used, the JDA
applications are responsible to generate the authentication challenge. To verify that in a workflow
involving more than one JDA application, a user is challenged only for the first time. JDA applications
are designed to work with a CIS Session Coordination Service, which manages the session information
across web applications. Before an application challenges the user, it verifies that a session is not
established for this user by another JDA application by examining the state of the session within the
session management service. The client-side state is managed through transient cookies stored in the
clients browser. The session management service also verifies that when a user logs out of one
application, that user is logged out of all applications. It can also be configured to manage session
timeouts in all applications.
Session coordination service

This section describes the features of the CIS SSO service that enables you to create coordinated sign-
on and sign-off across workflows that involve multiple JDA products within the enterprise. When a user
logs into one of the applications, this function creates a virtual session, which terminates when the
user logs off from one of the applications. All JDA applications that are SSOenabled can automatically
make use of the SSO service if the service is running.
This function applies only to the workflows that span web applications. SSO does not support shared
logins across web and non-web applications.
The following are the parts of function in the SSO service:
Session Management Service: This is a lightweight Front Bus service that enables single sign-on
between applications. This service is the basis of all the remaining functions described in this
section. This service enables users to access multiple applications after passing a single
authentication challenge.
Single Sign-On: The session management service supports single sign-on. When a user visits a
web application within a session under the domain of the SSO service, it first determines if a
session is established by another Web application on the SSO service. If so, it does not challenge
the user for authentication, and instead uses the authentication information already established for
this user under that session.
Single Sign-Off: The session management service supports single sign-off. When you logout from
one of the applications, and try to login the application, you are authenticated again.

Session Timeout Coordination: Each Web application in a workflow has its own HTTP session,
which has a lifecycle that is independent of all the other sessions in the workflow. It is possible that
a user might log into one of the applications in a workflow after working in another application and
discover that the local session in the application has timed out. The session coordination puts the
lifecycle of the individual session in the workflow under the control of the Infrastructure Services
SSO service. The virtual session spanning the applications times out only when none of the
applications in the virtual session have seen the activity from the user within the specified timeout
period.
Note: The CIS session management function is designed to degrade gracefully in workflows that do
not want to coordinate between services. When the session management service is not running, the
applications automatically degrade to the case of uncoordinated sign-on and require the user to log
into each application separately. If the service is running, you can configure it at the start up time to
disable single sign-off or session coordination capabilities, or both.
Manage solution navigation

Update solution navigation
You can use the UpdateSolutionNav utility to:
Import a Solution Navigation file from another environment and replace the existing Solution
Navigation.
Merge in Tasks exported from a JDA-Foundation database from a prior release (see the section on
Exporting Tasks to generate the required XML file first).
Merge in optional content provided by an application.
Export the existing Solution Navigation content.

The options for the utility are:
UpdateSolutonNav [-publicTasks <filename> [-updateNavFile]] [-privateTasks <filename>
[-keepUserTasks]] [-export <filename>] [-import <filename]
The options are described in the following table:

publicTasks Use this option to import Public Or Published To Tasks that No
were exported from a JDA Platform database. The argument
to this command is the navigation.xml that is generated
from the migrateTasks utility. This adds a top-level folder
Import to the Solution Navigation with the Tasks folder
beneath it.
updateNavFile This option can be used with the above option (publicTasks). No
This is the same as above option, but it also saves the
navigation XML generated as part of the command to the
navigation.xml file under
<install_dir>/config/platform/abpp/cfg/xserver.
privateTasks Use this option to migrate Private Tasks from a JDA Platform No
database (Tasks that are scoped as private). The argument
to this command is the privateNavigation.xml that is
generated as part of the migrateTasks command. This option
will migrate user tasks to the respective users My
Navigation. This command creates new entries or replaces
the existing entries. It will not attempt to merge.


keepUserTasks This option can be used with the above option (privateTasks). No
This option will skip over the existing users instead of
replacing them, so that it only adds new entries.
export Exports the Solution Navigation to a file. You can then use No
this file to import to another environment.
import Imports the Solution Navigation to the Database. This option No
will override all existing Solution Navigation entry in the
database.
Migrate tasks examples,
To import a file that contains Public/Published to tasks that were exported from a JDA Platform
database:
From the directory <install_dir>\config\bin\platform, run the command updateSolutionNav as

follows:
updateSolutionNav -publicTasks <install_dir>/config/bin/platform/navigation.xml
If this command is successfully run, it will merge the Tasks into the Solution Navigation in
Navigation pane.
Note: The Solution Navigation does honor security, so you will only see the tasks that you have
access to see.
To import a file that contains Private tasks that were exported from a JDA Platform database:
From the directory <install_dir>\ config\bin\platform, run the command updateSolutionNav as

follows:
updateSolutionNav -privateTasks
<install_dir>/config/bin/platform/privateNavigation.xml
If this command is successfully run, it will merge the tasks into the My Navigation in Navigation
pane.
To import Public and Private tasks that were exported from a JDA Platform database at the same
time:

follows:
updateSolutionNav -publicTasks <install_dir>/config/bin/platform /navigation.xml -
privateTasks <install_dir>/config/bin/platform/privateNavigation.xml
Export and import solution navigation between systems

You can export the Solution Navigation setup from one database to another using utility
updateSolutionNav (in ../config/bin/platform)
To export Solution Navigation from a database:

follows:
updateSolutionNav -export solution_navigation.xml
Note: This command will generate only the entries from Solution Navigation but not the entries from
My Navigation.

To import into Solution Navigation in another database:
From the directory <install_dir>\config\bin\platform on the second system, run the command
updateSolutionNav as follows:
updateSolutionNav -import solution_navigation.xml
Note: This command will import and replace the entries from Solution Navigation into the target
system. This command will not import the entries to My Navigation.
Export tasks from prior JDA Foundation versions

If you have created Tasks in the Task Manager to define your workflow in prior JDA-Foundation
releases, you must follow the steps below to migrate the tasks so that they will appear in the Solution
Navigation or My Navigation section of the Navigation pane. Tasks will be visible in the Solution
Navigation or My Navigation sections in the Navigation pane depending on the Task scope.
Steps to migrate tasks
To migrate tasks:
4. Run migrateTasks using the following syntax.
migrateTasks [-user <user>] -credentials <credentials>

<user_name> If you do not provide the username in the credentials file, then No
you must provide the user parameter to specify the name of
a valid user in the system.

<credentials_file> The name of the credentials file containing either the user Yes
name/password combination or only the password for the
batch user. If in a different directory, then specify the absolute
path. For example, credentials.properties. For more
information on creating a credentials file, see "Use encrypted
batch authentication" (on page 168).
5. This command generates the following three xml files in the directory
<install_dir>\config\bin\platform:
navigation.xml: Contains information about tasks that are scoped as Public or Published to
specific Roles or Users
privateNavigation.xml: Contains information about tasks that are scoped as Private.
taskAccessControl.xml: Contains information about the scope of tasks that were scoped as
PublishTo (role, enterprise, user). This file is for information purpose only, as you will need to
implement the security using the information in this section.
To import the file into the Solution Navigation, see Update solution navigation (on page 225).

Migration of Solution Navigation from 2016.1

During installation, most applications provide a default Solution Navigation file, which contains
common links to pages. You can use the Manage solution navigation to customize this file based on
your solution, adding and removing the links. Once customized, the Solution Navigation information is
stored in the JDA Platform database.
If you have an existing database that contains a Solution Navigation file that you have customized, the
version 2016.1 installation attempts to add new links to the existing file. However, if links have been
moved, renamed, added, or removed it is not possible to overlay folders and links into the location
specified in the default file. In this case, any new folders or links are added into an Import folder.
After installation, you can manually move these new links to the appropriate location, or remove them
entirely.
For example, if the Solution Navigation has not been customized, and the following new links were
available in 2016.1:
Administration
User Manager
And the existing Solution Navigation contained:
Administration
Security Manager
After installation of version 2016.1, you can see:
Administration
Security Manager
User Manager
However, if the Solution Navigation had been customized, you can see the following after installation
of version 2016.1:
Administration
Security Manager
Import
NavLinks-121230_111934
Administration
User Manager
You can then move the links in the Import folder to the Administration folder above, or remove it
from the Solution Navigation.
Implement security in Solution Navigation

When you create a folder in Solution Navigation, you can apply security to the folder by adding the
name of a Security Resource in the Activity field.
Note: The Resource name must start with NavGroup.
To add the necessary security resources, follow these steps:
1. Create a feature record in the CSM_FEATURE_INFO table (for example, NavGroupForecasting).
2. Create a record that maps this feature to an application in the CSM_FEATURE_APP table (for
example, SCPOWeb.Demand maps to NavGroupForecasting).

3. In the Security Manager, create a Feature Resource with the same name as the feature (for
example, NavGroupForecasting), giving the Execute permission to the resource.
4. Add the Resource to any Roles that you apply to the users whom you want to view the folder in the
Solution Navigation.
5. In the Manage Solution Navigation page, select the folder for which you want to apply security and
click the Activity box in the right-hand pane.
6. Enter N, and the list of available Resources is displayed. Select the resource you want to use and
click Apply.
Note: If you migrated Tasks to the Solution Navigation, you can use the taskAccessControl.xml file
that is generated by the MigrateTasks script as a reference to set up security for the Tasks that were
published to particular Roles or Users. Using the Activity field allows you to control who sees the
folders in the Solution Navigation.
Implement security in Solution Navigation

When you create a folder in the Solution Navigation, you can apply security to the folder by adding the
name of a Security Resource in the Activity field.
Note: The Resource name must start with NavGroup.
To add the necessary security resources, follow these steps:
1. Create a feature record in the CSM_FEATURE_INFO table (for example, NavGroupForecasting).
2. Create a record that maps this feature to an application in the CSM_FEATURE_APP table (for
example, SCPOWeb.Demand maps to NavGroupForecasting).
3. In the Security Manager, create a Feature Resource with the same name as the feature (for
example, NavGroupForecasting), giving the Execute permission to the resource.
4. Add the Resource to any Roles that you apply to the users whom you want to view the folder in the
Solution Navigation.
5. In the Manage Solution Navigation page, select the folder for which you want to apply security and
click the Activity box in the right-hand pane.
6. Enter N, and the list of available Resources is displayed. Select the resource you want to use and
click Apply.
Note: If you migrated Tasks to the Solution Navigation, you can use the taskAccessControl.xml file that
is generated by the MigrateTasks script as a reference to set up security for the Tasks that were
published to particular Roles or Users. Using the Activity field allows you to control who sees the folders
in the Solution Navigation.
Configure Tab Title for URL link

Perform the following steps to configure a tab title for URL link:
1. Go to Manage Navigation from left navigation.
2. Click Add URL Link.
3. Provide desired Label and URL and click Add.
4. Click on the newly added link.
5. On Link Details to the right hand side, Click Add in the URL Parameters section.
6. Provide name as TAB_TITLE and desired value in the Value field.

7. Click Apply.
8. Open the url link, the tab title set in the previous step should be displayed.
Configure Monitor
Enable Monitor after installation
You can configure and deploy Monitor if you are licensed for Monitor, and if you select to install Monitor
while installing Platform. However, if you do not select to install Monitor as part of the Platform
installation, you can enable Monitor after the installation using the enableMonitor utility. In this case,
the installation assumes that the Monitor database tables will be included in the Foundation schema.
To use the enableMonitor utility:
1. Shut down the Platform server
2. Run the following script from the ..\config\bin\monitor directory:

enableMonitor <TNSNAME> <WWF_PWD> <CREATE_MONITOR_DATABASE (true/false)>
true Monitor tables will be created and Foundation metadata populated
false Monitor tables will not be created, but Monitor metadata will be loaded into the
Foundation schema
3. Restart the Platform server.
For example, if you have loaded an existing Monitor schema, enter:

enableMonitor SERVER_SID WWFMGR false
To create a new Monitor schema, enter:

enableMonitor SERVER_SID WWFMGR true
Change e-mail templates

JDA Monitor uses templates to format e-mail alerts. The e-mail alerts are sent after the background
notification process is run. (See "Use batch processes" (on page 241).) Templates are stored as
follows:
JDA Monitor rule templates:

<install_dir>\config\monitor\templates\Monitor\<object_type>_<format>.template
Application-specific templates:
<install_dir>\config\monitor\templates\<App_name>\<object_type>_<format>.template
System-specific templates:
(for example, templates for comments and resolution processing)
<install_dir>\config\monitor\templates\System\<object_type>_<format>.template
Templates include the following resource lookup tags to accommodate customized text and language
translations.

Tag type Description
Reference This tag is placed at the top of the template file. Specify a tag for each resource file
to be accessed. By assigning a variable to the resource file, the resource file can be
easily changed, if needed.
Syntax:

where:
- <resource ref name> = Variable assigned to the resource file name.
- <resource file name> = Name of the resource file.
Example:

In this example, the file MonitorClientResource" is given the variable name
"Monitor". The variable "Monitor" can be used in Key reference tags (below).
Key This tag is used for fixed content, including headers, labels, and other static text.
Specify a tag for each key phrase.
Syntax:

where:
- <resource key name> = Name of the resource key.
- <resource ref name> = Variable assigned to the resource file name.
Example:

In this example, the key resource phrase "Monitor_Alert" is used. The phrase is
located in the resource file assigned to the variable "Monitor" using the Reference tag
(above).
Note: Dont be confused by the comments. The Monitor e-mail templates use HTML comments () to specify variables and keys. The comment tags were specifically selected so that any errors
would not display in HTML e-mails.
A list of available JDA Monitor replacement tags is provided below.
: The name of the enterprise associated with the exception
: The name of the application associated with the exception
: The name of the business rule associated with the exception
: The type of the business rule associated with the exception
: The priority of the exception
: The entity that the exception is for
: The category of the business rule associated with the exception
: The subject of the exception
: The time in which the exception was created
: The time in which the exception was last updated

: The URL that starts the JDA Monitor UI and
displays the group of exceptions
: The URL (in HTML format) that starts the JDA
Monitor UI and displays the group of exceptions
: The URL that starts the JDA Monitor UI and
displays the exception
: The URL (in HTML format) that starts the JDA
Monitor UI and displays the exception
: The number of exceptions generated by the business rule
execution (that the user has access to)
: Indicates that the following text should be
repeated for each exception included in the message
: Indicates the end of the text that should be repeated
: The resolution status of the exception
The system uses the language specified by the users preferences. If the user has not specified a
language, then the system uses the language of the defaultNotificationUser in the file
monitor_config.xml.
The server maintains the templates in cache. The templates can be modified. If you change the
templates, then run the batch utility NWReloadServer with the -T option. Running the batch utility
refreshes the templates in cache. For more on this utility, see "NWReloadServer" (on page 247).
Note: For Japanese, Simplified Chinese, and Traditional Chinese, edit the resource files in the native
encoding.
Modify Monitor properties

The server administrator can modify JDA Monitor properties files. This includes changing the menu text
and messages displayed to the client and server. On the client side, this includes error and
informational messages as well as the user interface. On the server side, this includes messages
resulting from batch processing. The properties affect the appearance, but not the processing of Web
pages and messages.
If you modify the properties files, be careful to edit the values, not the properties themselves. Back up
the properties files before editing them. In a multi-server configuration with different applications
running on different servers, the edited MonitorClientResource*.properties files must be copied to
the server where the Security Manager is running: otherwise, the edited resource files are not
displayed to users.
Changes do not take effect until the JDA Platform Server is restarted.
Property Location Description
monitor_config.xml \config\properties Contains JDA Monitor system settings.
MonitorBatchResource.properties \config\resources Messages resulting from batch

processes
MonitorClientResource.properties \config\resources Client interface labels, buttons, JDA
Monitor resource names, and
messages

Property Location Description
NWWakeBackgrounProcess.properties \config\properties Used for batch processes. See

"NWWakeBackgroundProcess" (on page
245).
NWProcessBusinessRule.properties \config\properties Used for batch processes. See
"NWProcessBusinessRule" (on page
242).
NWReloadServer.properties \config\properties Used for batch processes. See
"NWReloadServer" (on page 247).
To modify server and client properties:
1. Using a text editor, open the properties file to be modified. For example, if you want to change JDA
Monitor text that is displayed to users, open the file MonitorClientResource.properties.
2. Find the property that you want to modify. For example, if you want to change the menu text for
Administration, find the menus section:
#Menus
Administration=Administration
3. Type the new value for the property. For example, to change Administration to Admin Items, type
the new value to the right of the equal sign:
Administration=Admin Items
4. Repeat this step in the MonitorClientResource_<language>.properties files, including the

English file, MonitorClientResource_en.properties.
Note: For Japanese, Simplified Chinese, and Traditional Chinese, edit the files in the native
encoding. See "Edit resource files for double-byte languages".
5. Save and exit the properties files.
6. If necessary, copy the MonitorClientResource_*.properties files to the server where Security

Manager is running. In a cluster configuration, copy the properties files to all managed servers in
the cluster.
7. Restart the JDA Platform server(s).
Configure the Data Comparison rule

After installing JDA Monitor, configure the JDA Platform Server and database to create data comparison
rules with third-party applications. A JDA Monitor data comparison business rule is a user-driven
comparison rule. The rule allows a user to define rules based on a specified query and to create
exceptions based on the result of the query.
Supported Oracle data types

The Data Comparison rule supports the following Oracle data types:
CHAR
DATE
FLOAT: Both DOUBLE and REAL are represented as FLOAT.
INTEGER: SMALLINT is represented as INTEGER.
NUMBER: Both DECIMAL and NUMERIC are represented as NUMBER.

- Confidential
TIMESTAMP
VARCHAR2
Sample configuration script

The following script serves as example for configuring the data comparison rule. The sample configures
an application, TestApp, with the following database tables.
Note the following data type and cardinality information used in this example:
MD_COLUMN_INFO -> LOGICAL_DATA_TYPE_NAME
Oracle Data Type Logic Data Type
CHAR TEXT
VARCHAR2 TEXT
EMAIL_ADDRESS1
USER_NAME1
DATE DATE
TIMESTAMP DATETIME
NUMBER INTEGER
FLOAT DECIMAL
NUMERIC INTEGER

MD_COLUMN_INFO -> LOGICAL_DATA_TYPE_NAME
Oracle Data Type Logic Data Type
DOUBLE INTEGER
INTEGER INTEGER
REAL INTEGER
1 Use EMAIL_ADDRESS or USER_NAME when defining a data comparison rule with data-driven
notification. In the rule, specify whether to notify an e-mail address or user name and configure the
metadata with the corresponding data type. The metadata is defined in database column
MD_COLUMN_INFO.LOGICAL_DATA_TYPE.
See the Foundation database table MD_LOGICAL_DATA_TYPE for the complete list of available data
types.
MD_TABLE_RELATION -> Cardinality
Cardinality Value
1 -1 0
1 - Many 1
Many - 1 2
Many - Many 3
Copy and paste the following example script into a text editor and customize as necessary before
running it.
--Create the sample tables to be queried by the Data Comparison rule
Syntax for creating table COUNTRY
CREATE TABLE COUNTRY (NAME VARCHAR2(255) NOT NULL, CONTINENT VARCHAR2(255) NOT
NULL, HEMISPHERE VARCHAR2(255) NULL, CONSTRAINT PK_COUNTRY PRIMARY KEY (NAME));
Syntax for creating table STATE
CREATE TABLE STATE (NAME VARCHAR2(255) NOT NULL, COUNTRY VARCHAR2(255) NOT NULL,
ABBREVIATION VARCHAR2(10) NULL, POPULATION NUMBER(19) NULL, CONSTRAINT FK_STATE
FOREIGN KEY (COUNTRY) REFERENCES COUNTRY (NAME), CONSTRAINT PK_STATE PRIMARY KEY
(NAME, COUNTRY) );
CREATE INDEX XIF1STATE ON STATE (COUNTRY ASC);
Syntax for creating table
CREATE TABLE CITY (NAME VARCHAR2(255) NOT NULL, STATE VARCHAR2(255) NOT NULL,
COUNTRY VARCHAR2(255) NOT NULL, CAPITAL NUMBER(1) NOT NULL, POPULATION
NUMBER(19) NULL, CONSTRAINT FK_CITY FOREIGN KEY (STATE, COUNTRY) REFERENCES
STATE (NAME, COUNTRY), CONSTRAINT PK_CITY PRIMARY KEY (NAME, STATE, COUNTRY) );
CREATE INDEX XIF1CITY ON CITY (STATE ASC, COUNTRY ASC);
Syntax for creating table TAX
CREATE TABLE TAX (STATE VARCHAR2(255) NOT NULL, PERCENT FLOAT(19) NOT NULL,
CONSTRAINT PK_TAX PRIMARY KEY (STATE));
--Define the application in the JDA Security Manager

- Confidential
Syntax for CSM_APPLICATION
INSERT INTO CSM_APPLICATION (APPLICATION_NAME, DISPLAY_NAME) VALUES ('TestApp',

'Test External Application');
--Map the application to its database connection pool
Syntax for EMA_APPLICATION
INSERT INTO EMA_APPLICATION (APPLICATION_NAME, CONNECTION_POOL) VALUES ('TestApp',

'TST_ConnectionPool');
--Specify the database tables that are available for use through the JDA metadata facility
Syntax for MD_TABLE_INFO
INSERT INTO MD_TABLE_INFO (SCHEMA_NAME, TABLE_NAME, SYSTEM_TABLE, IS_USER_DEFINED,

IS_TIME_ALLOCATABLE, IS_CONFIGURED, IS_USER_UPDATEABLE, IS_MONITOR_ENABLED)
VALUES ('TST_SCHEMA', 'COUNTRY', 0, 0, 0, 1, 0, 1);

VALUES ('TST_SCHEMA', 'STATE', 0, 0, 0, 1, 0, 1);

VALUES ('TST_SCHEMA', 'CITY', 0, 0, 0, 1, 0, 1);
INSERT INTO MD_TABLE_INFO (SCHEMA_NAME,TABLE_NAME, SYSTEM_TABLE, IS_USER_DEFINED,

VALUES ('TST_SCHEMA', 'TAX', 0, 0, 0, 1, 0, 1);
--Add metadata info- table translations English
Syntax for MD_TABLE_TRANS
INSERT INTO MD_TABLE_TRANS (SCHEMA_NAME, TABLE_NAME, LANGUAGE_CODE, COUNTRY_CODE,

DISPLAY_NAME) VALUES (TST_SCHEMA, 'COUNTRY', 'en', NULL, 'Country');

DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'en', NULL, 'State');

DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'en', NULL, 'City');

DISPLAY_NAME) VALUES (TST_SCHEMA, 'TAX', 'en', NULL, 'Tax');
--Map the defined database tables to an application
Syntax for CSM_TABLE_APP
INSERT INTO CSM_TABLE_APP (TABLE_NAME, SCHEMA_NAME, APPLICATION_NAME) VALUES

('COUNTRY', 'TST_SCHEMA','TestApp');

('STATE', 'TST_SCHEMA', TestApp');

('CITY', 'TST_SCHEMA','TestApp');

- Confidential

('TAX', 'TST_SCHEMA', 'TestApp');
--Specify the database columns that are available for use through the JDA metadata facility
Syntax for MD_COLUMN_INFO
INSERT INTO MD_COLUMN_INFO (TABLE_NAME, COLUMN_NAME, SCHEMA_NAME,SUPPORTS_FILTERS,

CONFIG_CODE,IS_USER_DEFINED, IS_USER_UPDATEABLE,DOMAIN_NAME,
LOGICAL_DATA_TYPE_NAME, IS_CONFIGURED,IS_USER_REQUIRED,
IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('COUNTRY', 'NAME', 'TST_SCHEMA',
0, NULL, 0, 0, NULL,'TEXT', 1, 0, 0, 1, 0);
INSERT INTO MD_COLUMN_INFO (TABLE_NAME, COLUMN_NAME, SCHEMA_NAME,

SUPPORTS_FILTERS,CONFIG_CODE, IS_USER_DEFINED, IS_USER_UPDATEABLE,DOMAIN_NAME,
LOGICAL_DATA_TYPE_NAME,
IS_CONFIGURED,IS_USER_REQUIRED,IS_USER_INSERTABLE,IS_PK,IS_NULLABLE) VALUES
('COUNTRY', 'CONTINENT', 'TST_SCHEMA', 0, NULL, 0, 0,NULL, 'TEXT', 1, 0, 0, 0,
0);

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES('COUNTRY',
'HEMISPHERE','TST_SCHEMA', 0, NULL, 0, 0, NULL, 'TEXT', 1, 0, 0, 0, 1);

LOGICAL_DATA_TYPE_NAME, IS_CONFIGURED, IS_USER_REQUIRED,IS_USER_INSERTABLE,
IS_PK, IS_NULLABLE) VALUES ('STATE', 'NAME', 'TST_SCHEMA', 0, NULL, 0, 0,
NULL,'TEXT', 1, 0, 0, 1, 0);
INSERT INTO MD_COLUMN_INFO (TABLE_NAME, COLUMN_NAME,

SCHEMA_NAME,SUPPORTS_FILTERS,CONFIG_CODE, IS_USER_DEFINED, IS_USER_UPDATEABLE,
DOMAIN_NAME,LOGICAL_DATA_TYPE_NAME, IS_CONFIGURED,IS_USER_REQUIRED,
IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('STATE', 'COUNTRY', 'TST_SCHEMA',
0, NULL, 0, 0, NULL,'TEXT', 1, 0, 0, 1, 0);

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('STATE', 'ABBREVIATION',
'TST_SCHEMA', 0, NULL, 0, 0,NULL, 'TEXT', 1, 0, 0, 0, 1);
INSERT INTO MD_COLUMN_INFO (TABLE_NAME,COLUMN_NAME, SCHEMA_NAME,SUPPORTS_FILTERS,

LOGICAL_DATA_TYPE_NAME,IS_CONFIGURED,IS_USER_REQUIRED, IS_USER_INSERTABLE,IS_PK,
IS_NULLABLE) VALUES ('STATE', 'POPULATION', 'TST_SCHEMA', 0, NULL, 0, 0,NULL,
'INTEGER', 1, 0, 0, 0, 1);

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('CITY', 'NAME', 'TST_SCHEMA', 0,
NULL, 0, 0, NULL,'TEXT', 1, 0, 0, 1, 0);

- Confidential

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('CITY', 'STATE', 'TST_SCHEMA', 0,
NULL, 0, 0, NULL,'TEXT', 1, 0, 0, 1, 0);

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('CITY', 'COUNTRY', 'TST_SCHEMA',
0, NULL, 0, 0, NULL,'TEXT', 1, 0, 0, 1, 0);

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('CITY', 'CAPITAL', 'TST_SCHEMA',
0, NULL, 0, 0, NULL,'INTEGER', 1, 0, 0, 0, 0);

IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('CITY', 'POPULATION',
'TST_SCHEMA', 0, NULL, 0, 0, NULL,'INTEGER', 1, 0, 0, 0, 1);

LOGICAL_DATA_TYPE_NAME, IS_CONFIGURED, IS_USER_REQUIRED,
IS_USER_INSERTABLE,IS_PK, IS_NULLABLE) VALUES ('TAX', 'STATE', 'TST_SCHEMA', 0,
NULL, 0, 0, NULL,'TEXT', 1, 0, 0, 1, 0);

LOGICAL_DATA_TYPE_NAME, IS_CONFIGURED, IS_USER_REQUIRED,IS_USER_INSERTABLE,
IS_PK, IS_NULLABLE) VALUES ('TAX', 'PERCENT', 'TST_SCHEMA', 0, NULL, 0, 0,
NULL,'DECIMAL', 1, 0, 0, 0, 0);
--Add metadata info-column translations- English
Syntax for MD_COLUMN_TRANS
INSERT INTO MD_COLUMN_TRANS (SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, LANGUAGE_CODE,

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'COUNTRY', 'NAME', 'en', NULL,
'Name');

COUNTRY_CODE,DISPLAY_NAME) VALUES (TST_SCHEMA, 'COUNTRY', 'CONTINENT', 'en',
NULL, Continent');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'COUNTRY', 'HEMISPHERE', 'en',
NULL, 'Hemisphere');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'COUNTRY', 'CONTACT_USER_NAME',
'en', NULL, 'Contact User Name');

- Confidential
INSERT INTO MD_COLUMN_TRANS (SCHEMA_NAME, TABLE_NAME, COLUMN_NAME,LANGUAGE_CODE,

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'COUNTRY', 'CONTACT_EMAIL',
'en', NULL, 'Contact E-Mail Address');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'NAME', 'en', NULL,
'Name');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'COUNTRY', 'en', NULL,
'Country');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'ABBREVIATION', 'en',
NULL, 'Abbreviation');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'POPULATION', 'en',
NULL, 'Population');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'CONTACT_USER_NAME',
INSERT INTO MD_COLUMN_TRANS (SCHEMA_NAME, TABLE_NAME, COLUMN_NAME,LANGUAGE_CODE,

COUNTRY_CODE,DISPLAY_NAME) VALUES (TST_SCHEMA, 'STATE', 'CONTACT_EMAIL', 'en',
NULL, 'Contact E-Mail Address');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'NAME', 'en', NULL,
'Name');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'STATE', 'en', NULL,
'State');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'COUNTRY', 'en', NULL,
'Country');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'CAPITAL', 'en', NULL,
'Capital');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'POPULATION', 'en',
NULL, 'Population');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'CONTACT_USER_NAME',

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'CITY', 'CONTACT_EMAIL', 'en',
NULL, 'Contact E-Mail Address');

- Confidential

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'TAX', 'STATE', 'en', NULL,
'State');

COUNTRY_CODE, DISPLAY_NAME) VALUES (TST_SCHEMA, 'TAX', 'PERCENT', 'en', NULL,
'Percent');
--Specify any defined relationships between those tables. Those relationships may be
physical (foreign key constraints)or logical.
Syntax for MD_TABLE_RELATION
INSERT INTO MD_TABLE_RELATION (RELATION_NAME, FROM_SCHEMA_NAME, FROM_TABLE_NAME,

TO_SCHEMA_NAME, TO_TABLE_NAME, CARDINALITY, IS_PRIMARY_RELATION,
IS_SEARCH_RELATION) VALUES ('STATE_COUNTRY', 'TST_SCHEMA', 'STATE', 'TST_SCHEMA',
'COUNTRY', 2, 1, 0);

IS_SEARCH_RELATION) VALUES ('CITY_STATE', 'TST_SCHEMA', 'CITY', 'TST_SCHEMA',
'STATE', 2, 1, 0);

IS_SEARCH_RELATION) VALUES ('TAX_STATE','TST_SCHEMA','TAX', 'TST_SCHEMA', 'STATE',
0, 1, 0);
--Specify the join criteria for the defined relationships. The MD_TABLE_RELATION_JOIN
table does support joins that involve up to nine columns.
Syntax for MD_TABLE_RELATION_JOIN
INSERT INTO MD_TABLE_RELATION_JOIN (RELATION_NAME, JOIN_ORDER, FROM_SCHEMA_NAME,

FROM_TABLE, FROM_COLUMN_1, TO_SCHEMA_NAME, TO_TABLE, TO_COLUMN_1) VALUES
('STATE_COUNTRY', 0, 'TST_SCHEMA', 'STATE', 'COUNTRY', 'TST_SCHEMA', 'COUNTRY',
'NAME');

FROM_TABLE, FROM_COLUMN_1, FROM_COLUMN_2, TO_SCHEMA_NAME, TO_TABLE, TO_COLUMN_1,
TO_COLUMN_2) VALUES ('CITY_STATE', 0, 'TST_SCHEMA', 'CITY', 'STATE', 'COUNTRY',
'TST_SCHEMA', 'STATE', 'NAME', 'COUNTRY');

FROM_TABLE, FROM_COLUMN_1, TO_SCHEMA_NAME, TO_TABLE, TO_COLUMN_1) VALUES
('TAX_STATE', 0, 'TST_SCHEMA', 'TAX', 'STATE', 'TST_SCHEMA', 'STATE', 'NAME');
--Define a feature for the new application. Each application has a feature to represent itself.
This is then used to grant users access to the application.
Syntax for CSM_FEATURE_INFO
INSERT INTO CSM_FEATURE_INFO (FEATURE_NAME, DESCRIPTION) VALUES ('TestApp', 'Test

Application');
-- Map the feature permission to an application. All permissions must be mapped to an

application.
Syntax for CSM_FEATURE_APP

- Confidential
INSERT INTO CSM_FEATURE_APP (FEATURE_NAME, APPLICATION_NAME) VALUES ('TestApp',

'TestApp');
--Define a permission resource for the feature associated with the new application. This
permission is then assigned to user roles in order to allow access to that application's
components. With regard to JDA Monitor, it would allow this application to appear as a valid
source for the Data Comparison rule to query.
Syntax for CSM_RESOURCE
INSERT INTO CSM_RESOURCE (RESOURCE_NAME, RESOURCE_TYPE,SCHEMA_NAME, DESCRIPTION,

ENTITY_NAME, TABLE_NAME, COLUMN_NAME, FEATURE_NAME, RSRC_BUNDLE_NAME, CREATE_OP,
READ_OP, UPDATE_OP, DELETE_OP, EXECUTE_OP) VALUES ('TestApp', 'FEATURE', NULL,
NULL, NULL, NULL, NULL, 'TestApp', NULL, 0, 0, 0, 0, 1);
--Define a permission resource for each table defined in the JDA Platform metadata facility.
These permissions are then assigned to user roles in order to allow access to that table.
With regard to JDA Monitor, it would allow these tables to appear as valid tables for the
Data Comparison rule to query.
INSERT INTO CSM_RESOURCE (RESOURCE_NAME, RESOURCE_TYPE, SCHEMA_NAME, TABLE_NAME,

RSRC_BUNDLE_NAME) VALUES ('COUNTRY', 'TABLE', 'TST_SCHEMA', 'COUNTRY', NULL);

RSRC_BUNDLE_NAME) VALUES ('STATE', 'TABLE', 'TST_SCHEMA', 'STATE', NULL);
RSRC_BUNDLE_NAME) VALUES ('CITY', 'TABLE','TST_SCHEMA', 'CITY', NULL);

RSRC_BUNDLE_NAME) VALUES ('TAX', 'TABLE', 'TST_SCHEMA', 'TAX', NULL);
Use Monitor batch processes

JDA Monitor has three command-line processes. These processes are performed on the server, not on
clients. Batch processes are used for the processes described in the following table.
To do this... Use this process Location
Execute and process business "NWProcessBusinessRule" (on <install_dir>\config\bin\monitor

rules page 242)
Wake up the background "NWWakeBackgroundProcess" <install_dir>\config\bin\monitor
process for either exception (on page 245)
notification or automatic
resolution.
Refresh templates "NWReloadServer" (on page <install_dir>\config\bin\monitor
247)
Batch processing includes the following files:
A command (Windows) or shell script (UNIX) to run the process. You can create your own
scripts based on the scripts provided.
A property file that defines the properties to use when running the process. Sample property files
are shipped with the JDA products. To override the default properties, edit the properties in the
files. The command or shell script references this file.

- Confidential
A credentials file containing the encrypted password for use with the specified user. See
"Generate and work with encrypted passwords" (on page 242).
Remember the following issues when using batch processes:
Command-line instructions are case-sensitive, unless otherwise noted.
The symbol # is used to denote comment lines in property files.
Generate and work with encrypted passwords

Encrypt passwords using the GenerateEncryptedPassword utility installed with JDA Platform. For more
information, see JDA Platform Installation/Administration Guide. After an encrypted password has been
saved to a file, you can specify the encrypted password file when running a batch process using the -
user and -credentials options. The encrypted password file must be specified using a full or relative
path.
Batch process passwords (encrypted) can be specified in the following places:
On the command line using -user/-credentials (encrypted). If -user is specified on the

command line without -credentials, the system looks in the corresponding .properties file for a
password.
In a file. The password file is specified on the command line using the -credentials.
In the .properties file for the batch process. If -credentials is not specified on the command
line, the system looks in the corresponding .properties file for a password.
Note: Specifying multiple credentials causes an error. An error appears if a password is specified on
both the command line using -credentials and in the .properties file.
NWProcessBusinessRule
Use the NWProcessBusinessRule command in <install_dir>\config\bin\monitor to process
business rules defined in JDA Monitor. Run NWProcessBusinessRule from a command-line prompt on
the server. The command processes all business rules or the specified business rules in your enterprise
or specified sub-enterprises. The process detects any threshold violations for each rule.
To run the process, use the command file NWProcessBusinessRule.cmd (Windows) or shell script
NWProcessBusinessRule (UNIX). The script specifies the following required settings.
WEBWORKS_HOME: Location where JDA Platform software is installed. On Windows, set during
installation. For example, c:\JDA\JDAv74.
call %WEBWORKS_HOME% (Win) $WEBWORKS_HOME (UNIX): Location of the

webworks.common.vars.cmd (Windows) or webworks.common.vars.sh (UNIX).
NWProcessBusinessRule uses this file for several variables.
set JAVA_OPTIONS (Win) JAVA_OPTIONS (UNIX): The minimum and maximum JVM memory
settings where ms denotes minimum and mx denotes maximum.
%JAVA_CMD% (Win) $JAVA_CMD (UNIX): Specifies the class for the process. Do not change
this setting.
Configure the command properties in the file NWProcessBusinessRule.properties. Change the

defaults and settings listed in the following table.

- Confidential

traceFileDirectory The directory where output information is <install_dir>/config/logs
written when the process runs. Must specify relative or absolute
directory path. Use forward slashes
for Windows and UNIX.
traceFileName The file to which output information is NWProcessBusiness Rule.trace
written.
separatorCharacter The character used to separate multiple , (comma)
business rule names, process names, and
types.
waitInterval The number of seconds to wait for Set in seconds. Default is 30.
NWProcessBusinessRule batch process to
check if all business rules are processed.
waitTimeout The total number of seconds Set in seconds. Default is 1800 (30
NWProcessBusinessRule batch process will minutes).
wait. This setting should be large enough to
allow all business rules to process.
Run NWProcessBusinessRule
Use the NWProcessBusinessRule command for both event and nonevent-based Business Rules. The
typical syntax for running the NWProcessBusinessRule command has several possible options
depending on its use:
NWProcessBusinessRule [-B<business_process>] [-N<rule_name> | -T<rule_type>] [-A]

[-C] [-E<enterprise>] [-user <userid> -credentials <credentialsFile>]
The options for NWProcessBusinessRule are shown in the following table:
-A Process all defined business rules for the users No

enterprise. If specified, do not use with -B, -T, or -N.
-B<business_process> Process all defined business rules for the users Yes, if option -A or
enterprise and the given business process. The name -N is not used.
of the business process to process business rules. If
more than one business process is specified, separate
them with the separatorCharacter specified in the
property file. Business processes are case-sensitive.
If the business process is more than one word,
enclose it in quotation marks (""). Specify on the
command line. For example:
-BCollaborate
-C Use to process rules belonging to child enterprises. No

Use with -A and -E.
-credentials <encrypted The file containing the encrypted password for the Yes
credentials file> user specified by -user. For example:
-credentials MyEncryptedPassword
Note: Enter a blank space between the option and the

file name.

-E<enterpriseName> Use to process rules belonging to the specified No

enterprise (instead of the users enterprise). The
specified enterprise must be a child enterprise in the
users enterprise hierarchy.
-H Shows usage for the command No
-M Use to display the business rule types from the No

database. Different applications have different rule
types. No value is necessary with this option. The
output includes the rule type as it displays in the user
interface and as it must be specified at the command
line.
-N<rule_name> Use to specify the business rule name. If you specify Yes, if option -A or
more than one rule, separate them with the -B is not used. Do
separatorCharacter specified in the property file. Rule not use with -T
names are case-sensitive. If the rule is more than option.
one word, enclose it in quotation marks (""). For
example:
-NRuleName
-T<rule_type> The type of rule to process. If you specify more than Yes, if option -A or
one type, separate them with the separatorCharacter -N is not used. Do
specified in the property file. If the rule is more than not use with -N
one word, enclose it in quotation marks (""). You option.
must use -B if you use -T. However, only specify one
business process. For example:
-TComponentPublish
-user <userID for The name of a user who has permission to run Yes
encrypted credentials business rules in JDA Monitor. For example:
file> -user testuser
Note: Enter a blank space between the option and

the file name.
Example 1: To process all business rules for an enterprise.
If using an encrypted password, enter:
NWProcessBusinessRule -A -user userID -credentials EncryptPWFileName
Example 2: To process business rules for an enterprise and all of the child enterprises.
NWProcessBusinessRule -user userID -credentials EncryptPWFileName -A -C
Example 3: To process the ComponentPublish and PlanningItemChange type rules for an enterprise
for Collaborate, enter:
NWProcessBusinessRule -user userID -credentials EncryptPWFileName -BCollaborate -

T"ComponentPublish,PlanningItemChange"
In this case, the user ID and password must be in the property file.

Example 4: To list the business rule types in the database.
NWProcessBusinessRule -user userID -credentials EncryptPWFileName -M
The console displays the business rule types from the database. The name in parentheses should be
used for command-line instructions.
Collaborate Attribute Change (AttributeChange)

MarketManager Attribute Change (AttributeChange)
Example 5: To process a specific comparison-based rule for an enterprise called DeliveryRule.
NWProcessBusinessRule -user userID -credentials EncryptPWFileName -NDeliveryRule
In this example, the user and password are specified along with the rule name.
After processing business rules, a background process sends alerts to the appropriate users. The
background process runs at specified intervals. See "NWWakeBackgroundProcess" (on page 245) to
force the process to run without waiting for the specified interval to pass.
When NWProcessBusinessRule is run, one of the following return codes is generated:
0 - OK. The process completed successfully. Messages may have been written to the log file.
2 - Warning. The process completed, but with errors. See the log file for more information.
3 - Error. The process stopped without completing.
Example 6: To process business rules for a child enterprise myChild.
NWProcessBusinessRule - user userID -credentials EncryptPWFileName -EmyChild
Example 7: To process business rules for a child enterprise myChild and all of its sub-enterprises.
NWProcessBusinessRule -user userID -credentials EncryptPWFileName -EmyChild -C
Notes about processing business rules

When processing business rules, only business rules for an enterprise and sub-enterprises are
processed. Rules for other non-related enterprises cannot be processed.
If an enterprise does not use its business rules, events that belong to that enterprise will
accumulate and remain in the EMA_EVENT table. The database administrator should periodically
check the EMA_EVENT table and remove unnecessary events or delete any business rules that are
never run. Events are stored in the EMA_EVENT table if a rule exists of the same business rule
type.
NWWakeBackgroundProcess
Exception notifications (sending notifications to specified users) and automatic resolution of exceptions
are performed by background processes at specified intervals. Use NWWakeBackgroundProcess to
wake up and run either of these background processes.

Note: Running NWWakeBackgroundProcess resets the interval to run the specified process. For
example, suppose the background process runs every 5 minutes. If you run this batch file 2 minutes
after its last run, that process will not run again until after another 5 minutes.
This batch process is especially helpful when configuring and testing a new implementation. It forces
the background process to run so the results are received immediately.
Run NWWakeBackgroundProcess from the command-line prompt on the server. To run the process,
use the command file NWWakeBackgroundProcess.cmd (Windows) or shell script
NWWakeBackgroundProcess (UNIX). The script specifies the following required settings.
WEBWORKS_HOME: Location where JDA Platform software is installed. On Windows, set during
installation. For example, c:\JDA\JDAv74.

webworks.common.vars.cmd (Windows) or webworks.common.vars.sh (UNIX).
NWWakeBackgroundProcess uses this file for several variables.
settings where ms denotes minimum and mx denotes maximum
this setting.
Configure the command properties in the file NWWakeBackgroundProcess.properties. Change the

defaults and settings listed in the following table.
traceFileDirectory The location of the trace file where output <install_dir>/config/logs

information is written when the process Must specify relative or absolute
runs. directory path. Use forward slashes
for Windows and UNIX.
traceFileName The file to which output information is NWWakeBackgroundProcess.trace

written.
Run NWWakeBackgroundProcess
The syntax for running the NWWakeBackgroundProcess is:
NWWakeBackgroundProcess [-N | -R]

[-user <userid> -credentials <credentialsFile>]
-N Wake up the background process for Yes, if option -R is not used.

exception notification.
-R Wake up the background process for Yes, if option -N is not used.
automatic resolution.

-user <userID The name of a user who has permission to Yes

for encrypted run business rules in JDA Monitor. For
credentials file> example:
-user testuser
Note: Enter a blank space between the

option and the file name.
-credentials The file containing the encrypted password Yes

<encrypted for the user specified by -user. For
credentials file> example:
-credentials
MyEncryptedPassword
Note: Enter a blank space between the

option and the file name.
Example 1: To run the exception notification process.
NWWakeBackgroundProcess -N -user myuser -credentials EncryptPWFileName
Example 2: To run the automatic resolution process.
NWWakeBackgroundProcess -R -user myuser -credentials EncryptPWFileName
NWReloadServer
Use the NWReloadServer command in <install_dir>\bin\monitor to reload e-mail templates.
Note: Because server properties can be refreshed using the JDA Platform System Properties utility
(starting in version 7.2), the NWReloadServer no longer performs that process. However, the
NWReloadServer process still refreshes templates.
Using the NWReloadServer command as an alternative to restarting the JDA Platform Server. For
example, e-mail templates are cached. If a user changes the e-mail templates, the changes do not
take effect until restarting the JDA Platform Server or running NWReloadServer.
To run the process, use the command file NWReloadServer.cmd (Windows) or shell script
NWReloadServer (UNIX). The file has several properties that are set during installation. You can
change the properties after installation. The script specifies the following required settings.
WEBWORKS_HOME: Location where JDA Platform software is installed. On Windows, this value is
set during installation. For example, c:\JDA\JDAv74.

webworks.common.vars.cmd (Windows) or webworks.common.vars (UNIX). NWReloadServer
uses this file for several variables.
settings where ms denotes minimum and mx denotes maximum.
set CLASSPATH (Win) APP_JARS (UNIX): Path to JDA Monitor application JAR file. Do not
change this path.

this setting.
Configure the command properties in the property file NWReloadServer.properties in

<install_dir>\config\properties. Make changes to the defaults and settings listed in the following
table.
traceFileDirectory The location of the trace file. <install_dir>/config/logs

Must specify relative or
absolute directory path.
Use forward slashes for
Windows and UNIX.
traceFileName The file to which output information is NWReloadServer.trace

written.
Run NWReloadServer
Use the NWReloadServer command to reload e-mail templates. The syntax for running the
NWReloadServer command is:
NWReloadServer -T -X<servername> [-user <userid> -credentials <credentialsFile>]
-T Reloads email templates without having to Yes

restart the server.
-X<servername> The name of the server instance being Yes, for clustered
reloaded with e-mail templates. environment
Note: This option is applicable for clustered
environments only. The name of the server
instance is specified with the property
server_instance_name in the file
-user <userID for The name of a user who has permission to run Yes
encrypted credentials business rules in JDA Monitor. For example:
file> -user testuser
Note: Enter a blank space between the option

and the file name.
-credentials <encrypted The file containing the encrypted password for

credentials file> the user specified by -user. For example:
-credentials MyEncryptedPassword
Note: Enter a blank space between the option

and the file name.

Example 1: To reload the e-mail templates.
NWReloadServer -T -user myuser -credentials EncryptPWFileName
Set up data
After installing JDA Monitor, set up your data to use the system.
Set up JDA Monitor data and users

To set up data for JDA Monitor, create objects in JDA Monitor or Security Manager. Details on using the
applications, select Help. Following is an overview of objects used.
Object From Directory ... Notes

Enterprises Administration > Host Enterprise must create other enterprises. All users
Security must be assigned to an Enterprise.
Users Administration > A user is a valid user account used to access JDA Monitor
Security and other applications. A user can have one or more roles
assigned.
Roles Administration > A role is a definition or profile of permissions for access to
Security resources. JDA Monitor does not have default roles, but they
can be created. The JDA Monitor database creation assigns
all JDA Monitor resources to the HostAdmin and
EnterpriseHierarchyAdmin roles.
Resources Administration > Resources are named objects such as columns, tables,
Security features, or entities. Each role has a list of resources with
create, read, update, delete, and execute permissions. JDA
Monitor has a default set of resources that can be assigned
to new roles. See "Resources" (on page 250).
Partnerships Administration > Partnerships are an association between enterprises.
Security Partnerships can be associated with applications like JDA
Monitor.
Business Monitor > Create business rules.
Rules Administration >
Business Rule
Administration
Groups Monitor > Create groups (of users).
Administration > Group
Administration
Subscriptions <user_name> > Subscribe to business rules.
Settings
User <user_name> > Set up user preferences.
Preferences Settings
Priorities Monitor > Set up priorities for business rules.
Administration >
Priority Administration

Resources
JDA Monitor populates Foundation tables with a default set of Resources. Resources are assigned to
roles where they display in an Access Control List. Resources have create, read, update, delete, and
execute permissions. The display names for JDA Monitor Resources are in the file
MonitorClientResource*.properties. Resources are stored in the table CSM_RESOURCE, which is part
of the Foundation schema.
Resource Type Provides access to...
Monitor Feature JDA Monitor application
Business Rules Entity Create, read, update, delete, and execute permissions for
business rules
Groups Entity Create, read, update, and delete permissions for JDA
Monitor Group
Priorities Entity Create, read, update, and delete permissions for JDA
Monitor Priority
View Others Execution Feature View the status of rules executed by other users
Status
Business Rule Subscription Feature Subscribe to Business Rule Exceptions
Exception Resolution Feature Resolve Exceptions, including delete and dismiss

Exception Comments Entity Create and read permissions for Exception Comments
Exception Escalation Feature Exception Manual Escalation
Exception Export Feature Export business rule exception data
View Notification History Feature View Notification History
View Notification History Feature View Notification History Details
Details
Reload Notification Feature Run the batch process NWReloadServer
Templates
Extend on JDA Platform security objects

Enterprises, users, roles, filters, resources, and partnerships are stored in the database. JDA Monitor
also stores enterprises and users. For example, when a new user is created in Security Manager or
through the csmImport utility, that user is also stored in JDA Monitor. Similarly, when a user is
deleted in Security Manager, that user is removed from the JDA Monitor database. This process is
called extension and keeps data synchronized. Therefore, avoid adding or deleting users and
enterprises directly in the Foundation or JDA Monitor database tables. Synchronize the data in the
following database tables should be synchronized or problems may occur:
object JDA Platform Extended? JDA Monitor
enterprises Managed in Security Manager and csmImport Yes, Stored in table

utility. Stored in table CSM_ENTERPRISE. automatically EMA_ENTERPRISE
users Managed in Security Manager and csmImport Yes, Stored in table
utility. Stored in tables CSM_USER and automatically EMA_USER
CSM_USER_PASSWORD.

Quick business rule setup - copying enterprises in Security Manager

In a typical implementation, enterprises often include the same business rules. This is particularly true of
sub-enterprises. Therefore, setting up enterprises for an implementation includes defining the same
business rules repeatedly. To avoid having to redefine the same business rules in multiple enterprises,
define the business rules for one enterprise and then copy that enterprise using Security Manager. The
copied enterprises will include the JDA Monitor business rules defined for the original enterprise.
Notes:
The administrator performing the enterprise copy must have business rule read and create
permissions for JDA Monitor.
Business rules belonging to a child enterprise are not copied to a new enterprise. Only business rules
defined directly for an enterprise are included in a copy.
This following lists the business rule information included in a copied enterprise:
Business rule definitions

Business rule templates
Business rule escalation targets
Manual resolution option
This following lists the business rule information excluded in a copied enterprise:
Business rule user-driven (subscription) data (groups, users, and user subscriptions)
Business rule external user data
Excluded information must be redefined after an enterprise is copied.
Before copying enterprises, verify that the business rules can be copied. To do this, look at the
database. In database table EMA_BUSINESS_RULE_TYPE, the column SUPPORTS_COPY indicates
whether the business rule is included with a copied enterprise. A value of "1" indicates the business
rule is copied. A value of "0" indicates the business rule is not copied. Any business rule with a "0"
must be redefined in each copied enterprise.
The copy enterprise process may take a few minutes to complete, depending on the configuration and
the processing being performed simultaneously.
After the enterprise copying process is complete, be sure to edit the copied business rules and define the
user access/subscription data.
JDA Platform software licensing

An electronic software license file is required to run JDA Platform based applications. JDA will provide a
license file when the initial software order is fulfilled. The license file provided with the software can be
used for all installations that are performed for the company listed in the license.
Install the software license on each of the standalone or clustered instances of the JDA Platform based
software (for example, Development, QA, Production). In a clustered configuration, the license must be
installed on all nodes in the cluster.
Install a license file

1. On each JDA Platform server installation, run the installLicense command located in the
<install_dir>/config/bin/platform directory. This program should be run before starting the
application server.
installLicense <license filename>

2. Start the JDA Platform server(s).
Note: If a valid license file has not been installed, the application server will not start up correctly and an
Invalid Software License error is displayed in the log file.
Integrate English Platform OnLine Experts in different

locale
JDA applications are primarily supported with English language product documentation. If the language
you set in the user profile does not support a translated version of an OnLine Expert then the application
retrieves the English version OnLine Expert.
You cannot directly access the English version of the OnLine Expert from the foreign language locale. An
error message is displayed when you try to access the help pages from the application. To launch the
English version of OnLine Expert, integrate the English OnLine Expert in that language locale.
1. Launch the JDA Platform application.
2. Create a user and select a value from the Locale drop-down list other than English. For example,
GermanUser and Locale value as German. For more information, see the Create a user section in
the JDA Platform User OnLine Expert.
3. Close the JDA Platform application.
4. Run the following commands from the <install_directory>\config\bin\platform directory.
runWebworksTask -Dlang=de -Dnodedir=JDAServer install_help
Note: For the clustered environment, run the above command with the correct nodeDir name for
each of the cluster node.
runWebworksTask -DcombineSubsetConfigs=true -DinvokedFromPostAppInstall=false

concatenate_partials > concatHelp.log
Note: While running the command, you must select the appropriate system language. For
example, in this case, the Language is German.
Note: The system uses the language specified by the preferences set by you. If you have not specified a
language during installation, the English help files are deployed by default. If you want to install help files
in another language, run the commands mentioned above.
5. Edit the installerVars.cmd or installerVars.cmd file in the install directory and update the following
value to include de:
Windows:
Set SUPPORTED_LANGUAGES=de
UNIX:
SUPPORTED_LANGUAGES=de
Note:This ensures that other commands that you may run later picks German as a supported
language. Multiple language codes are allowed (comma separated).
6. Launch the JDA Platform application. Log into the application as GermanUser.
7. Click the Help icon in any of the application page to access the JDA Platform OnLine Expert in the
English language.

Configure server desktop in the Citrix server to access

RichUI application
This section provides information on how to access the Rich UI desktop applications in the Citrix
environment. After following these steps, you can launch the Rich UI application from your desktop.
Note: Steps and options can vary based on the application type selection.
Prerequisites:
Windows Server 2012 R2
Citrix server: Xen App 6.0
JDA Application: 2016.1.0.x
To publish the JDA application resource using the Citrix Publish Application wizard, follow these steps:
1. Launch Citrix Delivery Services Console.
2. Select Citrix Resources > XenApp > NewFarm > Application.
3. Right-click Application and select Publish application from the displayed options. The Publish
Application window is displayed.
4. Click Next. The Name window is displayed.
5. Enter the required values in the Display name and Application description fields. The Display
name value is displayed on the application window name when you access the application.
6. Click Next. The Type window is displayed.
7. Select the Server desktop option and click Next. The Servers window is displayed.
8. Click Add. The Select Servers window is displayed.
a. Select the Servers folder and click Add. The list of available servers name is displayed.
b. Select the appropriate server name.
c. Click OK.
9. Click Next. The Users window is displayed.
10. Select the Allow only configured users option. Click Next. The Shortcut presentation window is
displayed.
11. Select the icon for the application and click Next. The Publish immediately window is displayed.
12. Click Finish.
To launch the published Desktop:
1. Launch the Citrix server URL.
2. Click the Desktop tab.
3. Select the name that you have entered in the Display name field.
Configuring the application for Security

To meet enhanced security requirements, you should enable and configure SSL (Security Socket Layer)
for the application.

Configurations required for the JDA Platform Setup with Apache

front-end server
Add the following information in the httpd.conf file under ifModule block.
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Note: Ensure that the mod_header.sso module is loaded.
Configurations required for the JDA Platform setup when SSL is

enabled on front-end webserver or application server
1. Update the session-descriptor tag with the following values in the weblogic-application.xml file
from the directory <install_dir>\Platform\config\ear\META-INF.
<session-descriptor>
<cookie-name>JDA_JSESSIONID</cookie-name>
<cookie-http-only>true</cookie-http-only>
<cookie-secure>true</cookie-secure>
<url-rewriting-enabled>false</url-rewriting-enabled>
</session-descriptor>
2. Update the cis-sso.properties file with the following value from the directory
<install_dir>\Platform\config\properties
sso.useSecuredCookie=true
3. Update the webworks_config.xml file from the <install_dir>\config\properties directory with the
following properties:
secure_cookies property needs to be set to true.
Note: The cookies like windowId, scenario_cookie_key and so on will be secured over SSL
transmission.
check_referer_whitelist value need to be set with the web_server_hostname with

domain_name.
Note: The <web_server_hostname with domain_name> value should be in lower case. You
should update the property on each cluster node.
4. Save the changes and restart the application server.
Note: In case of clustered environment, configurations should be applied on each node.
In System Properties, select General User Interface, and add all the relevant cross-site scripting
characters (such as <>) in the Invalid_input_characters property.
Cross-Site Request Forgery attack control

The Cross-Site Request Forgery (CSRF) attack for the ABPP based application is handled through the
token 'SYS_ID'. This token is part of any HTML form in ABPP page as a hidden element and its value is
validated on the server side to avoid any CSRF attack.

Logging standardization
The JEA logging is a mechanism that allows you to enable the logging at runtime. You can use the options
to enable or disable the log details selectively and record the details in a log file in a uniform format. You
can control log outputs at different logging levels such as DEBUG, INFO, WARN and ERROR. This helps to
reduce the volume of logged output. You can control the log statements with a set of configuration files
log4j2.xml, log4j2-loggers.xml and log4j-appenders.xml. You can find these configuration files in
the <install_dir>/config/properties directory.
Note: For information on Log4j 2, see Apache website

(http://logging.apache.org/log4j/2.x/manual/configuration.html).
CAUTIONS:
Do not modify the log message format as it is designed to present the optimized
information and help you to analyze the logs and troubleshoot.
Do not modify the log date (timestamp) format as it is useful to map, analyze and
diagnose the logs across the clustered systems. Additionally, it also helps you to
analyze the real-time activities like login, logout and so on.
Do not modify the appenders. If you modify the log4j-appenders.xml file, it may corrupt
the logging utility.
Do not modify the jdamdc.xml file without consulting JDA Support Services. If you
modify the configuration and enable all keys, it will affect the performance of the
application.
Define the log file size

1. Open the log4j2.xml file in a text editor from the directory <install_dir>/config/properties.
2. Search for the SizeBasedTriggeringPolicy property and modify the value of the size attribute as
required. The default value is 10MB.
For example:
<appenders>
<RollingFile name="Default" fileName="${logDir}/${filePrefix}.log"
filePattern="${logDir}/${filePrefix}/${filePrefix}-%d{MM-dd-yyyy}-%i.log.gz">
<PatternLayout charset="UTF-8" pattern="%d %-5p [%t] %c %m [%M:%L %X] %n"/>
<Policies>
<SizeBasedTriggeringPolicy size="10MB"/>
</Policies>
<DefaultRolloverStrategy max="200"/>
</RollingFile>
<Console name="Console" target="SYSTEM_ERR">
<PatternLayout charset="UTF-8" pattern="%d %-5p [%t] %c %m [%M:%L %X] %n"/>
</Console>
</appenders>
3. Save and close the file.
4. Restart the JDA application server.

Add a new logger

You can define new loggers in the log4j2-loggers.xml file.
Note: Contact JDA Support Services to get the package details for debug.
1. Open the log4j2-loggers.xml file in a text editor from the directory

<install_dir>/config/properties.
2. You can perform following actions in the log4j2-loggers.xml file.
To configure a new logger in the log4j2-loggers.xml file, use the following format:
<logger name="<package_name>" level="<logging_level>" additivity="false">
<appender-ref ref="Default"/>
</logger>
<package_name>: Specifies the required package name for which the logger needs to be
configured. For example: com.manu.gensys.flexed
<logging_level>: Specifies the required logging level. For example: error, warns, info or
debug.
Notes:
If the log4j2-loggers.xml file contains any existing entries, then update the new logger
entry at the end of the file.
Ensure that the package name is unique for the newly configured logger. If duplicate
logger entries are defined in the log4j2-loggers.xml file, then the system considers the
first entry.
If you want to modify any existing logger in the log4j2-loggers.xml file, then search for the
required package name, and update the <package_name> and <logging_level> with appropriate
value.
For example:
To configure the package name as com.manu.gensys.flexed and logging level as info, use the
following format:
<logger name="com.manu.gensys.flexed" level="warn" additivity="false">
</logger>
Note: The value for logging_level> should be warn.
Modify logging level

Define the logging levels in the log4j2-loggers.xml file to enable the debugging information for
troubleshooting.
Note: Contact JDA Support Services to get the package details for debug.
1. Open the log4j2-loggers.xml file in a text editor from the directory

<install_dir>/config/properties
2. Search for the required package names in the <loggers> section.

3. Modify the level value as info.
For example:
To configure the logging level for the com.manu.gensys.flexed package to info, replace the level
attribute value as info. The default value for the level attribute is warn.
<loggers>
</logger>
</loggers>
You can also set different logging levels for multiple packages simultaneously.
For example:
To configure the logging level for the com.manu.gensys.flexed package, replace the level
attribute value for the logger as info
To configure the logging level for the com.manu.gensys.flexed.client package, replace the
level attribute value for the logger error.
<loggers>
</logger>
<logger name="com.manu.gensys.flexed.client" level="warn" additivity="false">
</logger>
</loggers>
Synchronize log configuration in cluster

Run the SyncConfigFile.cmd/.sh file through command prompt from the directory
<install_dir>/bin/platform to synchronize the logging configuration for all cluster members. Use the
following syntax:
SyncConfigFile[.cmd/.sh] <configFile> [-dbprops=dbConnections.properties] -

tags={tag1}[,{tag2}] [-restore] [-list]
<config_file> (required parameter): Specifies the configuration file to be synchronized. For this
configuration file, specify a fully qualified file name or a file located in the classpath. For example:
D:\some\directory\log4j2.xml or log4j2.xml
-dbprops (optional parameter): Overrides the default database properties specified in

dbconnections.properties for the appserver or sre. For this file, specify a fully qualified name of file
or a file located in the classpath. This file must contain the following key-value pairs as in the
dbconnections.properties file:
CSM_ConnectionFactory.DBConnect_String: The database connection URL. For example:

CSM_ConnectionFactory.DBConnect_String=jdbc:oracle:thin:@//localhost:1521/O12CR204

CSM_ConnectionFactory.UserID: The database user ID.
CSM_ConnectionFactory.Password: The encrypted database password. For example:

CSM_ConnectionFactory.Password={E:AES}0ed41369871c6725f99e4b630fff8d25
-tags (required parameter, unless the -list attribute is specified simultaneously): Enables to maintain
multiple application level configurations for the same file. Each tag must be surrounded by a set of
curly braces, like {sre}. The tags must be comma separated in case more than one tag is specified,
such as {tag2},{sre},{tag1}.
Note: Ensure that there is no space in between the two tags.
For example:
In the following table, for a single configuration file log4j2.xml, there are combination of multiple
tags exist, such as "{appserver},{sre}", "{sre},{tag1}", and so on.
In Configuration : 1102, the contents in the log4j2.xml is only applied to sre, whereas in
Configuration : 1104, the contents in the log4j2.xml is applied to both appserver and sre. These
configurations are selected based on the latest timestamp.
In the following table, the configuration for sre tag is selected from Configuration : 1200, as this
row contains the latest timestamp for sre.
Configuration : 1104 log4j2.xml 2013-12-28 09:54:30 GMT {appserver},{sre} ]
Configuration : 1300 log4j2.xml 2013-12-23 12:32:58 GMT {sre},{tag1} ]
Configuration : 1100 log4j2.xml 2013-12-22 13:16:23 GMT {tag2},{sre},{tag1} ]
Configuration : 1200 log4j2.xml 2013-12-22 13:16:24 GMT {tag2},{sre} ]
Configuration : 1102 log4j2.xml 2013-12-22 13:15:06 GMT {sre} ]
list (optional parameter): Lists the current configurations stored in the database for the
<config_file> file specified in the command line. If the -tags option is not specified then all current
configurations for the <config_file> file is listed.
restore (optional parameter): Restores the originally shipped configuration for the combination of
<config_file> and -tags specified in the command line.
Notes:
The restore operation requires a backup of the <configFile> file as <configFile>.orig in the same
location.
You cannot use the -list and restore options at the same time.
Any configuration update by the SyncConfigFile tool is synchronized across all the target
servers, by a configuration watcher.
In a Network File System, the option DdisableConfigFileWatcher=true must be used to start the
SRE Node Pool Manager.
The default run interval for the configuration watcher task is three minutes. You can configure this
using the option DconfigFileWatcherRunInterval=<time_interval>. The <time_interval> value
should be always in seconds.
SyncConfigFile utility currently supports log4j2.xml and jdamdc.xml.
SyncConfigFile utility creates logs in the <install_dir>/config/logs directory.

Log browser request details

1. Open the jdamdc.xml file in a text editor from the directory <install_dir>/config/properties
2. Search for the <tns:key> properties and modify the enabled attribute value as true. The default
value is false.
For example:
<tns:key name="jdamdc.http.request.param" enabled="false" />
<tns:key name="jdamdc.http.request.remote" enabled="false" />
<tns:key name="jdamdc.http.request.header" enabled="false" />
<tns:key name="jdamdc.http.request.header" enabled="false" />
<tns:key name="jdamdc.http.request.header.map" enabled="false" />
By default, the following properties are enabled:

<tns:key name="jdamdc.http.request" enabled="true" />
<tns:key name="jdamdc.http.request.param.map" enabled="true" />
<tns:key name="jdamdc.http.request.header.user-agent" enabled="true" />

<tns:key name="jdamdc.webworks.loginid" enabled="true" />
Identify current logging configuration

You can access the current JDA Logging Configuration by accessing Common Logging through Solution
Navigation. The configuration accessed by Common Logging, belongs to the application server you are
currently logged into. To access the Logging configuration of any other application server, you must login
to the respective application server and access the URL.
Notes:
To access Common Logging, the administrator privilege is required for a user.
You cannot retrieve the logging configuration for an SRE install by this.
You can download the displayed data in HTML format. Click the Download button to save a copy to the
local machine. Send the downloaded file to JDA Support Services for troubleshooting.
Configure custom logo

1. Explode base.war file under <Platform>\config\ear\abpp
2. Place the images (such as customer logo and banner logo) in skins\jda\images under exploded
base.war
3. Navigate to System Properties workflow in the UI
4. Select Shell in Properties for drop down.
5. Update the below properties: (Rename the file names as in step 2)
shell.customer.logo.path=skins/jda/images/<Shell_Banner_Logo.png>
login.page.customer=true

login.page.company.logo=skins/jda/images/<Login_Page_Logo.png>
6. To deploy the changes, issue the following command from <Platform>\config\bin\platform.
deployEar.cmd in Windows
deployEar.sh in Unix
7. Restart the server to view the changes in Login page and Shell Banner.
Notes:
1. The image format can be .png, .jpg etc.
2. The ideal size for Shell banner logo is 53x34 (width and height accordingly in pixels).
3. The ideal size for Login page logo is 185x45 (width and height accordingly in pixels).
Update the Java patch version post installation

1. Install the new Java patch version in your system.
2. Navigate to the directory <install_dir>\config\ and open the following:
installerVars.cmd (For Windows)
installerVars.sh (For Unix)
3. Update the variable WEBWORKS_JAVA_HOME with the new path.
4. Navigate to <install_dir>\CIS\CIS-SDK\. Open the Settings.xml file.
5. Update <JDK_HOME> and <JAVA_HOME> with the new values.
For Example:
<JDK_HOME>D:\tools\JAVA\jdk1.7.0_75\<JDK_HOME>
<JAVA_HOME>D:\tools\JAVA\jdk1.7.0_75\jre\<JAVA_HOME>
6. Navigate to <install_dir>\CIS\CIS-SDK\bin. Run the following command:
Launch.bat configure py (For Windows)
Launch.sh configure py (For Unix)
7. Start the server.
Configure time zone for ABPP in Platform setup

A new parameter, DEFAULT_ABPP_TIMEZONE is introduced to enable ABPP UI to display dates in the
local time zone. When ABPP server runs in the Platform environment its time zone is set to GMT. As a
result, even if the server is not located in GMT time zone, the dates in the UI will be in GMT. In order to
see the dates in the UI in the time zone where the server is running, set the
DEFAULT_ABPP_TIMEZONE to the local time zone. You can use any valid Java time zone ID that is
returned by TimeZone.getAvailableIDs() to set the value.
For example:
For US Central Standard Time: CST, US/Central, or GMT+6
For Indian Standard Time: GMT+05:30
DEFAULT_ABPP_TIMEZONE=GMT+05:30
You can modify the following file:
<Platform_Install>/config/properties/abpp.properties
To set the time zone for log (appserver.log), edit <Platform_Install>/config/properties/log4j2.xml

as follows:
<appenders>

<RollingFile name="Default" fileName="log/${logfile}.log"

filePattern="log/${logfile}-%i.log">
<PatternLayout charset="UTF-8" pattern="%d{DEFAULT}{IST} %-5p [%t] %c %m [%M:%L %X]
%n"/>
...
...
</RollingFile>
...
...
</appenders>
Note: You must set the value of the pattern attribute as {DEFAULT} {IST}, {DEFAULT} {CST},
{DEFAULT} {GMT}, and so on.
Concurrent login
The login mechanism provides information about the previous successful login of a user and also about
any other active sessions of the same user.
Configure last login information display

1. Navigate to System Properties workflow.
2. From the Properties for drop-down list, select Shell.
3. Update the following properties:
shell.enable.lastlogin.info=true
4. Restart the server.

After the configuration is complete:
On successful login, you can view the date and timestamp of your last active session.
If you have an active session and you try to log into another session, a notification message is
displayed. You can still proceed using the application.
When there is a session logout due to explicit user log out or timeout, the system stores the session
state to inform the last active session details.
If the server is restarted, all last login information of the users are cleared, so that no logged in
instance is available for any user.
Enable concurrent login feature in cluster environment

A service level parameter, clusterNodeID, is introduced in xserver.xml to identify each cluster node. It
must have a unique positive value for each node. For example, if there are 4 nodes in a cluster, the nodes
can have value of 1, 2, 3, and 4 respectively. In xserver.xml, the following parameter should be added as
a service parameter.
<param Name="clusterNodeID" Value="1"/>
For any cluster node, if the server is restarted, all last login information of the users are associated to this
node, while other nodes in the cluster remain unchanged.
User Activity Audit

JDA applications are often required to track information related to user activities for security reasons. JDA
Platform has the user activity auditing feature that enables you to track the user activities in the system,
such as user login, user logout, and session

Expiration. Supported Scenarios:
UI Login
Web Services Call
Rest Services Call
Batch Utilities Call (ABPP Command Servlet)
Above Mentioned Scenarios are Applicable to the following type of setup
Standalone with SSO
Standalone without SSO
Standalone with LDAP
Platform
Platform with LDAP
Platform with External Authentication
Auditing Information
Auditing information includes successful attempts of login/logout and unsuccessful login attempts.
The user activity log details are stored in the <EVENT_LOG> table and field details are as follows:
EventSource: Component of the log event. For example, LogInPage
EventLocation: IP address of the source browser.
EventCategory: Type of the event. For example, log in and log out.
EventName: Name of the event. For example, User Login successful and User Log in Failure.
EventID: Unique identifier of the event, whenever the user logs in or logs out.
UserName: User name of the logged in user.
EventDate: Time when the user logs in.
Agent: Details about the client software from where request is originated, it also contains information
related to application type, operating system, software vendor, or software revision
Session ID: It contains Session ID of established session, in case of SSO SSO Token is captured as
session ID
Additional Event Details: It contains additional details related to event, currently it contains login
failure reason
Note: EVENT_LOG table will be present under ABPPMGR schema
Sample log
The User Events workflow enables you to search and purge user events records
Notes:
User Events workflow is aligned with User Events resource

In case of Web Services Call and Batch Utilities Call (ABPP Command Servlet) there is no logout
action
Configuring Event Handlers

Handler is the one which is responsible for logging the data. The event configuration file
eventLogger.xml is used to define category wise handlers. This handler will be invoked while writing
events.
User can define multiple handlers to store events to different data bases like one handler for oracle and
another handler for Hadoop. And also user can use multiple handlers to capture extra event information
along with default event information
Following is the format of the configuration file and com.i2.x2.event.DBEventHandler is the default
handler. This Configuration can be over-ridden by keeping it in the class path.
<auditing-handlers>
<auditing-handler category=default handler=com.i2.x2.event.DBEventHandler >
</ auditing-handler >
</auditing-handlers>
The user defined handlers should implement com.i2.x2.event .EventLogger.
The following example will get the EventLogger by category:
EventLoggerlogger=EventLoggerFactory.getInstance().getEventLogger("default");
The following example writes events (to the EVENT_LOG table):
logger.logEvent(userName,eventSource, eventName, eventIP, eventCategory);
Configure maxRowsExportable parameter to a custom

value
1. Navigate to System Properties workflow and select ABPP UI Settings in the property dropdown.
2. Change com.i2.x2.util.configurability.maxRowsExportable parameter to desired value. Click
Save.
3. Restart the servers.

Troubleshooting
Chapter 7. Troubleshooting
Troubleshoot the JDA Platform Server
Problems with the server may be identified in the console or logs. The weblogic.log file in directory
<install_dir>\config\logs stores information written to the console when the server starts. In addition,
users may report problems when they use applications. This section includes troubleshooting steps,
symptoms, and some solutions. The examples in this section include java error exceptions displayed to
the user, which assumes the property errorPageExceptionDisplay is set to true in
Troubleshooting steps
This section contains common problems and resolutions.
If the server does not start, or starts and then immediately shuts down, or users receive error pages,
check the following:
In the installerVars.cmd (Windows) or installerVars.sh (UNIX), check the BEA_HOME,

WEBLOGIC_HOME, and JAVA_HOME settings to ensure they point to the correct locations on your
computer. This file is automatically configured during installation. For example, if WebLogic is installed to
the c: drive, the variables are similar to the following:
set BEA_HOME=c:\bea1221
set WEBWORKS JAVA_HOME=c:\Java\java17_75
set WEBLOGIC_HOME=c:\bea1221\wlserver_12.2.1
Note: The BEA_HOME location in the installerVars file must match the BEA_HOME location. If you
upgraded and did not uninstall earlier versions of WebLogic, more than one BEA_HOME is present on the
machine and you need to pick the correct one.
Be sure the server port assigned in the config.xml file is not already used by another process.
Verify that the databases are running.
Verify the Java Naming and Directory Information (JNDI) jndi_provider_url, hostname, and port
properties in file webworks_config.xml. These properties are set during installation.
Check the connection pool for each JDA application in the jda-jdbc.xml file. Some applications share
a common pool. Verify the user name/password to access the database. Check the database server
name, Oracle SID, and listen port. Make sure the database(s) is running.
Confirm that the config.xml is well-formed XML, especially if you have made modifications. To test
this, try displaying the config.xml in Microsoft Internet Explorer. If it fully displays in the browser, it
is well-formed XML. If it does not display correctly, then you can rebuild config.xml file using a JDA
Platform utility. See "Regenerate configuration and startup files" (on page 148).
Common error messages and remedies

Error: The JDA Platform Server fails to start and displays the following error message in the console:
<Jan 1, 2005 9:17:14 PM GMT> <Error> <JDBC> <BEA-001150> <Connection Pool

"CSM_Connection_Pool" deployment failed with the following error: 0:
Could not connect to oracle.jdbc.driver.OracleDriver.
The returned message is: ORA-01017: invalid username/password; logon denied

Troubleshooting
Verify the Oracle user name and password in xml files in the config/JDADomain/config/jdbc
folder, for the connection pools. In this example, the failed connection pool is CSM_Connection_Pool.
The password is encrypted in jda-jdbc.xml. You can enter the correct user name and password in the
file, and the server encrypts the password on startup. Restart the JDA Platform Server.
Error: The JDA Platform Server fails to start and displays the following error message in the console:
<Jan 1, 2005 1:32:09 PM GMT> <Critical> <Security> <BEA-090402> <Authentication denied:

Boot identity not valid; The user name and/or password from the boot identity file (boot.properties)
is not valid. The boot identity may have been changed since the boot identity file was created.
Please edit and update the boot identity file with the proper values of username and password. The
first time the updated boot identity file is used to start the server, these new values are encrypted.>
This means that the WebLogic system password is not set in file boot.properties. For more
information, see "Change the WebLogic admin password" (on page 171).
Error: The server displays an error in the console before shutting down.
The connection pool for the application may have incorrect settings. In the jda-jdbc.xml file, check
the Oracle server name, listen port, and instance (SID). Also, verify the Oracle user name and
password used to connect to the database.
Error: The server starts and listens for requests. Users log in successfully but they receive an error when
they select an application.
The JDBC connection pool(s) in the jda-jdbc.xml file may have incorrect values set for Oracle. The
error page includes the application name; the example above uses JDA Monitor. Verify the database
user name, password, and instance (SID) for the application. Also, verify that the database is
running.
Error: The following error displays in the console when starting the JDA Platform Server:
java.lang.OutofMemory
Check the JAVA_OPTIONS variable in file startWLSServer:
set JAVA_OPTIONS=%JAVA_OPTIONS% %DEBUG_OPTIONS% -Xms256m -Xmx1024m
where m is megabytes. Try appending JAVA_OPTIONS with MaxPermSize:
set JAVA_OPTIONS=%JAVA_OPTIONS% %DEBUG_OPTIONS% -Xms256m -Xmx1024m -

XX:MaxPermSize=128M
For additional help with memory errors on UNIX consider adjusting the kernel parameters. In some
cases, they may be too low for WebLogic. If you change the settings, you must restart the JDA
Platform Server
Error: The JDA Platform Server fails to start, or starts and displays the following error message:
com.manu.webservices.metadata.SchemaException: System Exception occurred: ORA-00942: table or

view does not exist
The error occurs because the Foundation schema owner does not have access to an external table.
Users can refer to external (non-JDA) database tables in table MD_LIST_DOMAIN. The JDA Platform
Server records an error that the external table does not exist. Run the following SQL command as the
Oracle system user or as the schema owner of the external table:
grant select on <schema>.<table_name> to <wwfmgr>;
If you need more information, use the following queries to list tables/views that contain data for
external tables:

Troubleshooting
select ref_table_schema_name, ref_table from md_list_domain where

has_ref_table='1';
select ref_trans_table_schema_name, ref_trans_table from md_list_domain where
has_ref_table='1';
Error: The JDA Platform Server running on IBM WebSphere fails to start, and displays the following error
in the systemout.log file
java.lang.NoClassDefFoundError: com/manu/webservices/db/ConnectionPool
Note: The cause of this error is listed in the appserver.log file. This error is caused by wrong entries
for either the host or the port entry in soapcredentials.properties file. Check the settings and try
starting the server again.
CAUTION: The following warning displays in the console. Note that the application name,
OrderPromising, is an example. You may see the same warning for different applications.
####<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Sep 15,

2005 6:57:45 PM GMT> <Warning> <EJB> <sun040> <WebWORKS> <main> <<WLS Kernel>> <>
<BEA-010001> <While deploying EJB 'OPromPE', class com.manu.scpoweb.OrderPromising.ejb.OPromPE
was loaded from the system classpath. As a result, this class cannot be reloaded while the server is
running. To prevent this behavior in the future, make sure the class is not located in the server
classpath.>
The warning requires no corrective action, and it can be ignored.
CAUTION: The following warning is displayed in the console.
####<Sep 15, 2005 6:59:50 PM GMT> <Warning> <HTTP Session> <sun040> <WebWORKS>
<ExecuteThread: '22' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-100061> <Web
application: ServletContext(id=12003460,name=vplogin,context-path=) tried to place a non-serializable
attribute: _vpWebServicesResourceBundle into the session:
BIRlppgoVyK7xVfwaF5d7wvfrBPGdzB0vUB272MDoh3lAv7tSqu4!-51982794!1095274789867. This
attribute will be lost upon redeployment. This message is logged only once per session.>
This harmless warning requires no corrective action.
Error: The JDA Platform Server starts, but the following error occurs when a user requests a page.
classdef not found
Another symptom of the same problem occurs when attempting to start a node pool. The node pool
log states:
parameter list too long
This error occurs because JDA Platform is installed in a long directory path on AIX. The Java Server
Page compilation fails because the classpath is too long. Use one of the following remedies:
Do not install JDA Platform in a long directory path. This requires a reinstallation.
If reinstalling is not an option, create a symbolic (soft) link to the long directory. Create the link at
the top of a directory structure. For example,
ln -s /longpath/jda/WebWORKS_Foundation /path
If neither options are practical, then change the arglist limit using the AIX ncargs attribute.
First check the current value:
lsattr -E -l sys0 -a ncargs
The default value is usually 6. A higher number may be required depending on the number of
characters in the long path. The following example sets the value to 12.

Troubleshooting
chdev -l sys0 -a ncargs=12

It is not necessary to restart the JDA Platform Server.
Error: The following error occurs when using LDAP for authentication and the credentials are incorrect.
Exception during invocation from home:

com.manu.webservices.security.ejb.DirectoryServiceBean_papk9w_HomeImpl@2af53419 threw
exception: javax.ejb.EJBException - with nested exception:
[javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09030F,
comment: AcceptSecurityContext error, data 525, vece ]]>
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09030F,
comment: AcceptSecurityContext error, data 525, vece ]
This problem indicates the credentials are not valid. Check the LDAP properties in JDA Platform
System Properties.
Troubleshoot problems with connection pools

Database connection pools are configured during installation, and stored in the jda-jdbc.xml and jda-
<application name>-jdbc.xml files.
By default, each connection pool has a default refresh rate of 10 minutes. If you have restarted the
database while the server is running, it may take up to 10 minutes before the JDA Platform Server
establishes the database connections.
Gather diagnostic information using garbage collection

WebLogic: You can enable JVM garbage collection (GC) messages by adding -verbose:gc to variable
JAVA_OPTIONS in file startWebworksServer. Garbage collection reuses allocated heap memory that
cannot be used again. It also provides information on when and for how long GC is running. To add the
GC, edit file startWLSServer, for example:
set JAVA_OPTIONS=%JAVA_OPTIONS% %DEBUG_OPTIONS% -Xms256m -Xmx256m -verbose:gc -

XX:MaxPermSize=128M
WebSphere: This information is configured in the server.xml file. To enable garbage collection, edit the
jvmentries node in this file. The file is located in the folder
\<was_home>\AppServer\profiles\<yourProfileName>\config\cells\<cell
name>\nodes\<nodeName>\servers\WebWORKS\
When the server starts, the information is displayed on the console, but not written to log files or to a
separate file. You may see messages similar to the following:
[Full GC 17941K-><10370K(130112K), 0.9338299 secs]

[GC 18498K->10870K(130112K), 0.1002756 secs]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor51]
Gather information for JDA

You may be told to gather log files and other information so that you can send them to JDA. Product
Support or a JDA consultant may recommend this. JDA provides a utility to gather the information.
3. Run the command runWebworksTask with one option:
runWebworksTask collect_debug_data
The utility gathers log, properties, and cmd/sh files and then compresses them in a zip file called
debug_data.zip. Look for the file in the <install_dir>\config\logs directory.

Troubleshooting
4. Send the zip file to JDA.
Troubleshoot enterprise hierarchy

Users log in successfully and attempt to use Security Manager, but receive the following error:
java.lang.NullPointerException at
com.manu.webservices.security.ejb.EnterpriseServiceBean.getVEnterpriseHierarchy(Enterp
riseServiceBean.java:693)at
com.manu.webservices.security.ejb.EnterpriseServiceBean_tjruo0_EOImpl.getVEnterpriseHi
erarchy(EnterpriseServiceBean_tjruo0_EOImpl.java:213) at
com.manu.webservices.security.ejb.EnterpriseServiceBean_tjruo0_EOImpl_WLSkel.invoke(Un
known Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
The Host Enterprise may not have been migrated correctly. See "Notes on migrating enterprise
hierarchy to version 7.0.x".
Troubleshooting SRE
This section is intended to help diagnose and solve common problems with service runtime environment.
Each error example suggests one or more remedies.
com.manu.webservices.security.batchAuthentication.CredentialsException: Credentials Property

File contains a user name. It cannot be overwritten on the command line.
The user specified on the command-line does not match the user stored in the credentials.properties file.
Verify the user name and try again.
Error authenticating user - SuperUser.
The system could not authenticate the user name/password combination specified in the
credentials.properties file. Verify the user name/password and try again.
Error occurred during initialization of VM

Could not reserve enough space for object heap
The machine may not have sufficient memory resources to run the job.
Error: If the command-line prompt returns:
Attribute "Name" must be declared for element "processRequest".

Error parsing request file -
The request XML file has an invalid attribute called Name. Correct the file and run SREBatchUtility again.
Error: The node pool manager does not start. Check the following:
Ensure that the pool is not already running. View running pools in Process Manager. For example, you
can have only one Basic node pool across your JDA Platform SRE architecture.
The JDA Platform Server and Oracle database server are running.
The pool name is valid and unique. Pool names are stored in table SRE_NODE_POOL.

Troubleshooting
Ensure that the machine has sufficient memory resources for the Java Options. Each node pool has
associated minimum and maximum memory allocation as set in table SRE_NODE_POOL. Insufficient
memory usually fails nodes in a pool. When the node pool manager re-creates them, the nodes fail
again.
Verify the database connection pool properties in file dbconnections.properties.
Error: The following error displays in NodePoolManager-<pool_name>.log when you attempting to

start a node pool:
15:34:15|com.manu.webservices.db.ManuDBException.log|com.manu.webservices.db.ManuDBExc
eption: Database exception - java.sql.SQLException: ORA-04068: existing state of
packages has been discarded
.
SQL Exception: java.sql.SQLException: ORA-04068: existing state of packages has been
discarded
This error indicates that script ManugisticsPkg.sql has not been run. Using SQL*Plus, run
ManugisticsPkg.sql as the jda_system user. Next, run enroll_app_schema.sql as the system user and
enter the application schema owner. Run enroll_app_schema.sql once for each application schema. Try
restarting the node pool.
Error: Jobs are requested but they do not run. Check the following:
Make sure the node pool(s) are running. Check their status in Process Manager.
Verify that the node pool(s) are configured to run the process, see Process Manager or table
SRE_NODE_POOL_CONFIG.
A job may be running that is using the nodes your job needs. Therefore, your job remains in the
queue until the nodes become available. Consider creating additional pool(s) for the processes.
Make sure an earlier job of the same process was not abnormally terminated. If this occurs, SRE
cleans up residual records. The jobs can be canceled in Process Manager.
The time delta among JDA Platform SRE instances and the JDA Platform Server must not exceed the
duration for property realm.auth.token.timeout.mins set in webworks_config.xml. If it does, login
exceptions can occur.
Make sure all instances of JDA Platform SRE use the same encryption.service.key as the JDA Platform
Server(s). This key is stored in file webworks_config.xml.
Error: Users initiate import/export or many-to-many copy in Flexible Editor. The browser returns:
Operation timed out. Export Failed.
Try setting SRE_TOTAL_TIMEOUT in Foundation System Properties to a value equal to or greater than the
value for SRE_NODE_CONFIG.BUILD_ACTIONS_TIMEOUT. FE processes use a single action, so if a node is
not assigned within SRE_TOTAL_TIMEOUT, then users receive the time out error.

Troubleshooting
Error: When submitting a job using SREBatchUtility, a database exception occurs:
using <Blank> as separator
This occurs because the input XMLfile specifies a blank space as a delimiter. This system attempts to
parse the blank space as a null value. Instead, specify a delimiter uses "space" as a keyword. For
example:
<option name="Gensys.ImportExport.Delimiter" value="space" />
Similarly, when using attribute Gensys.ImportExport.IncludeHeader for exporting data, use "true", "yes",
or "1" to generate column headers. The system interprets other values as false and no header is
generated.
System alerts
If a system alert displays in Process Manager, this indicates a failure. When the failure involves a node,
the system can recover. However, a job failure cannot be recovered. The following system alert is an
example of a job failure:
The job failed because the number of assigned nodes is less than the minimum required.
In this example, the job started but not enough nodes were available to run the jobs. The minimum
number of nodes for a process is specified in SRE_NODE_CONFIG.MIN_NODES.
SRE jobs fail when specific failures exceed set tolerances:
The job fails when the number of node failures during a particular job action exceeds the value in
SRE_SERVICE_INFO.ACTION_RETRY_LIMIT. (This table contains predefined process parameters and
you should not modify them.) The system alert identifies the pool of the failed node. This helps
identify which log file to review.
The job fails when the number of failed actions for a job exceeds the value in
SRE_NODE_CONFIG.IGNORE_ACTION_FAILURE_COUNT.
A job can also fail if the failures for nodes performing blocking or non-blocking initialization exceed
values in SRE_SERVICE_INFO.MAX_INIT_RETRIES. Again, you should not modify the values in this
table.
Troubleshooting methodology
If jobs fail or the same job repeatedly fails, follow these troubleshooting steps to identify the problem.
1. Examine the system alerts in Process Manager. Each node failure creates a system alert. Examine the
individual node and NodePoolManager logs on the machine where the node(s) failed.
2. Set the Level to verbose for each logger in the log4j2.xml file in the
<install dir>/config/properties directory.
3. Stop and restart the node pool manager(s).
4. Request the job again.
5. Examine the system alerts. Note the ID of any failing node(s).
6. In the NodePoolManager log, search for the failed node ID(s). This information reveals what the node
was doing when it failed.
Run a custom process

1. Open the custom process by clicking it in the Directory page. The custom process page is displayed.

Troubleshooting
2. Select an option set from the Choose Option set drop-down list.
3. Enter the parameter values in the fields. The names of the option fields depend on the external
command provided while creating the custom process. You must provide appropriate values. You can
also save them as an option set or run the process with these values.
4. Click Run. The Job status window displays the progress of the job and the result log information.
Example 1: Custom process for command line script

You can add a command line script as a custom process to run tasks. The following steps provide an
example to add a command line script as a custom process. This script is an example of a command line
custom process. The script customProcessSampleShellCMD is located in the
<install_dir>\config\platform\sample directory. It accepts user input, concatenates the values, and
writes the output to the specified file (custom_process_test.txt) in the directory from which the node
pool is running.
2. In the Name and Description fields, enter information about the custom process.
3. In the Type drop-down list, select Custom Processes.
4. In the Access drop-down list, select an entry; for example, Private to <user>
5. In the Process name field, enter HelloShellCmdNode.
6. For Process type select Command line.
7. In the External command field, enter the following information:
a. Windows: ..\sample\customProcessSampleShellCMD.cmd !manu_user_name! !job_id! !CMD

Input!
b. UNIX: Use the absolute path such as

<install_dir>/config/platform/sample/customProcessSampleShellCMD.sh !manu_user_name!
!job_id! !CMD Input!
8. For External command delimiter, select !.
9. In the Process timeout field, enter 600.
11. Click Done.
Using Security Manager, assign the HelloShellCmdNode CP resource to a user's role with all permissions.
Using the Node Pool summary page, open the Edit pool page for an existing nodepool (for example, Basic)
and assign HelloShellCmdNode CP to the nodepool.
Open the Custom Process launch page for the custom process from the Directory then enter descriptive
text (for example, testing command line custom process). Click Run. After successful completion of the
process, check the output file custom_process_test.txt in the directory where the nodepool started
from (for example, <install_dir>/config/bin/platform). The output should be in following format:
<manu_user_name>:<job_id>:<input string>.
Note: manu_user_name and job_id, used in this example, are two reserved words and can be used as
arguments while defining a custom process. The values of these pre-defined words is substituted with the
username running the process and the job id.
Example 2: Custom process for stored function

Using the steps in this example, you can add a stored function as a custom process. This custom process
calls Teststoredfunction, which inserts data into stored_function_output table in the application schema.

Troubleshooting
You must run customProcessSampleCreateStoredFunction.sql and

customProcessSampleCreateTable.sql located in the config\platform\sample directory before
running this sample stored function.
1. Use SQL*Plus connect to the database as system user then grant CREATE PUBLIC SYNONYM to the
application schema owner. For example, GRANT CREATE PUBLIC SYNONYM TO SCPOMGR;
2. Connect to the database as the application schema owner and run

customProcessSampleCreateTable.sql. For example, sqlplus scpomgr/scpomgr @
customProcessSampleCreateTable.sql
3. Create a public synonym for the table created. For example, CREATE OR REPLACE PUBLIC SYNONYM
STORED_FUNCTION_OUTPUT FOR STORED_FUNCTION_OUTPUT;
4. Grant permissions to Foundation schema owner: For example, GRANT SELECT, INSERT ON
STORED_FUNCTION_OUTPUT TO WWFMGR;
5. Run customProcessSampleCreateStoredFunction.sql. For example, sqlplus scpomgr/scpomgr

@customProcessSampleCreateStoredFunction.sql
6. Create a public synonym for the function created: CREATE OR REPLACE PUBLIC SYNONYM
TESTSTOREDFUNCTION FOR TESTSTOREDFUNCTION;
7. Grant run permission on the TESTSTOREDFUNCTION to Foundation user. For example, GRANT
EXECUTE ON TESTSTOREDFUNCTION TO WWFMGR;
After you have run these scripts, create a custom process using the following steps:
1. Create a new directory entry. For more information about Adding directory pages see, Adding
directory entries in the JDA Platform OnLine Expert.
2. In the Name and Description fields enter the information about the custom process.
3. In the Type drop-down list select Custom Processes
4. In the Access drop-down list select an entry, for example Private to <user>
5. In the Process name field enter HelloStoredFunctionNode
6. In the Process type choose Stored function
7. In the External command field enter testStoredFunction(!manu_user_name!, !job_id!, !FUNC

Input!)
8. From the External command delimiter choose !
9. In the Process timeout field enter 600
10. Check Participate in process chains to make the custom process available to process chains.
11. Click Done.
Using Security Manager, assign the HelloStoredFunctionNode CP resource to a user's role with all
permissions.
Using the Process Manager - Node pool summary page. Open the Edit pool page for an existing nodepool
( for example, Basic) and assign HelloStoredFunctionNode CP to the nodepool.
Open the Custom Process launch page for the above Custom process and enter some descriptive text (for
example, testing stored function custom process) and click Run.
After successful completion of process, check the STORED_FUNCTION_OUTPUT table for the output data.
The output is in following format:
Job:<job_id> run with input:<input string>:<manu_user_name>

Troubleshooting
Note: manu_user_name and job_id, used in the example above, are two reserved words and can be
used as arguments while defining a custom process. The values of these pre-defined words are
substituted with the username running the process and the job id.
Log files for troubleshooting SRE

Use log files in the following table to analyze job activity, troubleshoot problems, and trace errors.
Note: To record more details when running jobs, set the log level to debug for the logger name value
com.manu in the log4j2.xml file.

NodePool-<pool_name>.log \config\logs Each node pool manager writes to a log
file on the machine where it is running.
The file is called NodePool-
<pool_name>.log in the directory
<install_dir>\config\logs. For example,
for the node pool Basic, the log file is
called NodePool-Basic.log.
The file includes stdout and stderr
messages of the pool. Set the log level to
debug for the logger name value
com.manu in the log4j2.xml file for
complete information on the child nodes.
Node-<node_id>.log \config\logs\ NodePool- A NodePool-<pool_name> folder is
<NodePoolName> created inside the
<install_dir>\config\logs directory,
where each node pool writes to a log file
on the machine where it is running. The
log file is called Node-<node_id>.log.
The maximum size of this file is 10MB.
This file rolls over to a new file when the
maximum size is reached and the old log
file is zipped and placed in the directory
<install_dir>\config\logs\NodePool-
<NodePoolName>. In the directory,
multiple log files are generated for each
node in the node pool. For example:
Node-1001.log and Node-1000.log.
jdacore_<pool_name>_<job \config\logs When an SRE process runs into a critical

_id>_<node_id>.log error, JEA logs additional details about
the conditions causing the error in this
log file. The <pool_name> refers to the
SRE Node Pool that is serving this
particular job request, the <job_id>
refers to the unique number allocated to
this job request, and the <node_id>
refers to the SRE Nodes Process ID that
is processing the job request.

Troubleshooting
Tune Oracle for SRE

JDA Platform SRE provides parallel execution of processes. The number of node pool(s) and processes
you have running could affect the Oracle database server. Specifically, the number of database
connections and open cursors can quickly accumulate and exceed the number specified in the initialization
file, init<SID>.ora. A symptom of the problem can appear to be a leak of Oracle cursors.
IMPORTANT: An Oracle DBA should participate in tuning the following parameters. If necessary, add
them or adjust the following parameters for your environment.
processes
sessions
shared_pool_size
Return codes and job states

You should examine these when running jobs. Return codes are described in the following table.
Service runtime environment return codes for batch and SRE jobs
SRE_JOB_SUMMARY
and batch utility
NORMAL The process completed normally. 0
WARNING The process completed with one or more 2

non-critical issues.
ERROR The process completed with one or more 3
critical issues.
FATAL_ERROR The process encountered a fatal issue 4
during runtime, and failed to complete.
USER_TERMINATED The process was terminated at the users 5
request.
GLOBAL_SHUTDOWN The process was terminated because a 6
global shutdown was invoked by a
system administrator.
UNDEFINED_RESULT_CODE An undefined error code was returned by 7
the process.
BATCH_REQUEST_TIMED_OUT The batch request timed out. 8
JOB_FAILED_PREDECESSOR_FAILURE Job did not start, as a previous job in the 9

Process Chain failed.
Job states identify the progress of a job. The job states are described in the following table. When a job
runs, the job state displays in Process Manager. The number in parentheses do not imply the required
sequence of job states.
Job states
(SRE_JOB:JOB_STATE)
Assign Job 0 The system assigns nodes to run the job. This is a normal
job state.

Troubleshooting

(SRE_JOB:JOB_STATE)
Blocking 1 The initialization state where a node performs any
Initialize prerequisite actions before processing begins. An example of
an initialization action is removing old data from a results
table. The initialization actions performed depend on the
process being run. Other nodes assigned to the job are
blocked from running other jobs. This is a normal job state.
Non-blocking 2 The job is divided into actions (units of work) among the
Initialize assigned nodes. This is a normal job state.
Processing 3 The job is processing. This is a normal job state.
Actions
Cancel Job 4 The job was canceled by a user.
Blocking Finish 5 Processing is complete. This state occurs when the job
processed successfully. This is a normal job state.
Finished 6 The job is complete. This is a normal job state.
Resetting 7 Indicates the system is trying to recover from a failure. In

the user interface, an alert displays. This state only occurs
when a job fails during Blocking Init or Non-blocking Init
states.
Close Job 8 Processing is complete, but the job is not yet finished. Jobs
can enter this state even when a user canceled the job or
when processing failed. All nodes must complete processing
before the job enters this state. This is a normal job state.
Assign Wait 9 Occurs only when chaining jobs. The first job in the chain
proceeds to Assign Job. Other jobs in chain remain in this
state until the first job completes.
The job errors are described in the following table.
Job errors - This maps to ERROR_CODE in SRE_JOB_SUMMARY and RETURN_CODE in

SRE_JOB
0 No job error.
1 Job was not assigned to nodes. This occurs when nodes are not available. Common
causes are:
no node pool(s) running for the process
number of available nodes is less than what is required for the process
2 The number of nodes working on the job fell below the minimum required as set in
table SRE_NODE_CONFIG.

Troubleshooting
3 Job initialization failed. This can occur when the job state is in blocking initialization or
non-blocking initialization, and the node fails or is stopped by a user. The number of
attempts to initialize the job exceeds SRE_SERVICE_INFO.MAX_INIT_ATTEMPT.
4 Job process actions failed. This can occur when the job state is processing and the
nodes cannot process the actions (units of work). The number of failed actions exceeds
SRE_NODE_CONFIG.IGNORE_ACTION_
FAILURE_COUNT.
5 Job blocking finish failed. This can occur when the job has finished processing, but the
job failed in blocking finish because a node failed during that job state.
6 Job close failed. The job finished processing, but the job did not close successfully.
7 Action failures have been ignored. This warning message displays if action failures
occur but the job is completed.
Note: To view the records run a query to join the SRE_ACTION records where
percent_complete < 100 with the application specific process table. For example, in the
case of Calculate Plan this is the ProcessSku table. This join displays all SKUs that may
not have been processed.
9 Job did not start to predecessor failure.

Note: If one of the jobs in a Process Chain fails, subsequent jobs in the chain that have
not run contain this error code.
DDU error codes

Following is a list of DDU error codes and their associated messages:
-20000, WCIF: Error Message Table invalid so cannot lookup error code.
-20001, WCIF: Couldn't find text for error code.
-20002, DDU: The Tablename parameter cannot be empty.
-20003, DDU: The Key parameter cannot be empty.
-20004, DDU: The Number of Chunks parameter must be in the range of 2 through 256.
-20005, DDU: Failed to retrieve number of rows while parsing statement for Table.
-20006, DDU: Failed to retrieve number of rows while executing statement on Table.
-20007, DDU: Failed to delete DDU_RESULTS table rows for ID.
-20008, DDU: Failed to retrieve type while parsing statement for following Key and Table:
-20009, DDU: Failed to retrieve type while executing statement for following Key and Table:
-20010, DDU: Failed to retrieve type while fetching rows from cursor for Key and Table:
-20011, DDU: The Key field must be of type DATE, NUMBER or VARCHAR2.
-20012, DDU: Failed to insert results into DDU_RESULTS table.
-20013, DDU: Failed to parse the following cursor:
-20014, DDU: Failed to execute the following statement:

Troubleshooting
-20015, DDU: Failed to retrieve number of rows for table:
Troubleshoot CIS in JDA Platform Server

CIS Issues when SSL is involved
The use of SSL is governed by the following two settings in the cis-sso.properties file.
Client Side Configuration

# Use Local URL for SSO session management callback.
sso.useLocalURL = true
# Assume Local HTTP URL for SSO session management callback.
sso.useLocalHttpURL = true
useLocalURL is almost always set to true.
useLocalHttpURL is false only when your actual WebWORKS server is setup to use HTTPS.
For example, an apache HTTPS frontend proxying to a regular HTTP WebWORKS/Weblogic server, the
above entry will still be true .
Note that, usually only the front end proxy (Apache for example) is on SSL. And, the proxy communicates
to the backend WebWORKS using basic HTTP. This communication is often behind the firewall and a SSL
is not really required. Out of the box, the Weblogic/WebSphere servers (set up by configureJDAServer
script) do not have the HTTPS ports turned on. In case any customer insists on having SSL on the actual
Weblogic/WebSphere servers, it is up to them to follow the instructions provided by Oracle/IBM to setup
SSL.
In addition, if you are adding HTTPS to the actual application server (instead of adding SSL only to the
proxy), the following steps need to be performed. Note that this configuration is not something that has
gone through extensive QA.
Navigate to <Platform_Install>/cis/cis-sdk/xml/SessionCoordinatorBindingDB.xml, open it

and add the below tag inside <binding><RMI>...</RMI>
<SSL mode="true">
<keyStore>path of keystore</keyStore>
<keyStorePassword>password</keyStorePassword>
<trustStore>Path truststore</trustStore>
<trustStorePassword> password </trustStorePassword>
< /SSL>
Navigate to <Platform_Install>/config/bin/platform/startWLSServer (in older versions of JDA) or
setWLSstartupVars.cmd and under JAVA_OPTIONS set the following:
set JAVA_OPTIONS=%JAVA_OPTIONS% -Djavax.net.ssl.keyStore=<keystore> -

Djavax.net.ssl.keyStorePassword=<Keystorepassword> -Djavax.net.ssl.trustStore=<truststore
cert > -Djavax.net.ssl.trustStorePassword=< trust storepassword>
How to spot session stickiness issues

Our logs will contain lines like the below where the session id is tracked. A session id of notavailable
(jdamdc.http.request.sessionid=notavailable) almost always means that the load balancer is not
honoring sessions. Unexplained UI issues will follow as a result. However, the log snippet shown below is
an exception to the rule. Here, we also see LaunchParm=Initialize. This is the only time session that
can be recorded as notavailable.

Troubleshooting
Other times, you must see a good session value.
Sample:
jdamdc.http.request.sessionid=8g8taZ4UMsJsEvbMvyqpnQRxXQOl80KOv_7280eL6cnGztqxXKA!2008237
436!1456755829989)
2016022317:35:45,123 ERROR [[ACTIVE] ExecuteThread: '10' for queue:
'weblogic.kernel.Default (selftuning)']
com.manu.webservices.servlet.framework.ControllerServlet Could not find frame:
[/ClickOnce/JDASoftware.application?AssemblyShortName=JDA.SCPO.Fulfill
ment.LoadManagerWorkbenchModule] [execute:377
jdamdc.http.request.contextpath=/jda/home,jdamdc.http.request.method=GET,jdamdc.http.requ
est.param.map=[Instance=Load Manager Workbench,LAUNCH_TYPE=DotNetApp,
LaunchParm=Initialize
,Listing=LoadManagerWorkbench,Owner=$PUBLIC,TypeName=JDA.SCPO.Fulfillment.LoadManagerWork
benchModule.InitModule.Controllers.WorkbenchTabController,frame=/ClickOnce/JDASoftware.ap
plication?AssemblyShortName=JDA.SCPO.Fulfillment.LoadManagerWorkbenchModule],jdamdc.http.
request.querystring=frame=/ClickOnce/JDASoftware.application?AssemblyShortName=JDA.SCPO.F
ulfillment.LoadManagerWorkbenchModule&TypeName=JDA.SCPO.Fulfillment.LoadManagerWorkbenchM
odule.InitModule.Controllers.WorkbenchTabController&Listing=LoadManagerWorkbench&Instance
=Load+Manager+Workbench&Owner=%24PUBLIC&LaunchParm=Initialize&LAUNCH_TYPE=DotNetApp,
jdamdc.http.request.scheme=https,jdamdc.http.request.server.name=scpoprd.XXXXX.corp,
jdamdc.http.request.server.port=443,
jdamdc.http.request.sessionid=notavailable,
jdamdc.http.request.uri=/jda/home/VP,
jdamdc.http.request.url=https://scpoprd.XXXXX.corp:443/jda/home/VP,
jdamdc.webworks.loginid=CCCC}]
How many CIS agents/servers are active in a cluster?

In a cluster, you can have multiple CIS agents/servers running to ensure high availability. The point to
remember here is that the setup always uses first one of n and not any one of n.
For example, if Apple, Banana and Cherry were the machines were you have CIS setup running, the
cisregistry.properties file for each of these 3 setups are going to look exactly the same. (The different
port numbers are for illustrative purpose only)
server.1=Apple:9310
server.2=Banana:9320
server.3=Cherry:9340
The above only indicates that the CIS on the machine named Apple will be the default CIS for all
WebWORKS servers in the cluster. If and when Apple is down, the control switches to the next element in
the list, in this case the CIS install on the machine called Banana. In addition to the above, you must
import (using launch.bat importMachine.py <machine><port> command) appropriate machine info.
You must import Banana and Cherry into Apple.
You must import Cherry into Banana.
No imports on Cherry.
Features not working when SSO is enabled using Siteminder and

lot of database server related exceptions in SSO logs
Check for special/illegal characters defined in the filter roles for the user. Check for special characters on
the user`s profile names. This might be causing the middleware that translates JDA Profiles to PCS
Profiles to get lost. The solution is to review all the JDA Profiles and assure there are no more special
characters. Check for special characters where JDA calls the pages on Apache. (This configuration has to
be done on the WebWORKS side.)

Troubleshooting
Regarding the database exceptions, the reason could be network connectivity issues between SSO server
and database OR the database server is down or restarted.
External Authentication issues when the parameter is other than

SM_USER for ex.XX_USER
Follow instructions in section Configure and enable external authentication in Platform Install Admin
guide. Check if the header name is case sensitive.
To setup external authentication on WebSphere application server, apart from the files mentioned in the
install guide (abpp.properties and webworks_jaas.config), make sure that correct header is set by
editing security.xml in the profile as mentioned below:
<options xmi:id="Property_1442484365183" name="userNameHTTPHeader" value="XX_USER"/>
Some of the pages are not showing up properly and refreshes back to home page. Sometimes, when they
log out and log back in, it works.
Use Local URL for SSO session management callback. sso.useLocalURL = true
Assume Local HTTP URL for SSO session management callback. sso.useLocalHttpURL = true
Check if it is cluster setup with multiple instances. If we configure separate CIS Server for each node then
SSO will not work. All the applications/nodes have to point to single CIS. If a session is registered in CIS1
server and 2nd request comes to CIS2 server via different managed node then user will be challenged for
user/password.
Make SSO to Application Server communication multi-threaded. This can be done by passing JVM args in
runSSOServer.py script:
run.runRMIServer(metadataFile,["-Dlog4j.configurationFile=log4j2-sso.xml"," -
Dcom.i2.cis.AsyncHttp=true"])
No Configuration was registered that can handle the

configuration named HTTPHeaderLoginModule error when SSO
with external authentication is configured
Verify if SSOLoginModule=HTTPHeaderLoginModule entry is there in abpp.properties. Ensure there
are no spaces and special characters are present in the entry. Also, ensure if ssoEnabled property is set
to true in abpp.properties under <Platform_Install>/config/properties.
Broken login page is displayed when SSL is configured in

webserver
Verify if trusted server host names are mentioned in com.i2.ui.check-referer.whitelist property in the
abpp.properties file under <Platform_Install>/config/properties. Verify if the webserver is configured
to accept /jda requests along with any other request types like /xxx.

Troubleshooting
User tries to access the URL and it gives the error "SSO server not
started"
Verify the details in cisregistry.properties under <Platform_Install>/config/properties. The value of
the parameter "server" should be correctly set to the server host name (not localhost) and CIS agent
port as provided during installation. Also, it is recommended to provide server host name during Platform
installation (for both Platform as well as CIS server details).
Users redirected to home page when SSL is configured with

WebSphere setup
Perform the following steps to overcome this issue:
1. Follow the below steps to create your own java.security file, since the default java.security file
might already be in use and not recommended to change.
a. Copy and paste existing java.security file in JRE_HOME/lib/security folder.
b. Rename the copied file as java.cis.security
c. Keep original java.security file unchanged in same location.
d. Make the following changes in the java.cis.security file:
ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl
WebSphere socket factories (in cryptosf.jar)
#ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory
#ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory
2. Inject certificate into jre/lib/security/cacerts
The expectation here is that the certificate is extracted from WAS side and inject that into the
jre/lib/security/cacerts file. You can use iKeyMan to do this.
3. Follow the below steps to configure the java.cis.security file

a. Stop the SSO adapter.
b. Open the <CIS>/cis-sdk/bin/runSSOServer.py file.
c. In last line please change as below:
From:
run.runRMIServer(metadataFile,["-Dlog4j.configurationFile=log4j2-sso.xml"])
TO:
run.runRMIServer(metadataFile,["-Dlog4j.configurationFile=log4j2-sso.xml",
"-Djava.security.properties=/tools/java/jre/security/java.cis.security"])
4. Import certificates to the plugins data store:
a. Add the certificates that you extracted to the key data store. The key data store file is located on
the machine where youre running the proxy server. The location details can be found from the
following tags in the plugin xml file. For example,

Troubleshooting
<Property Name="keyring" Value="/usr/local/IBM/WebSphere/Plugins/etc/plugin-

key.kdb"/>
b. Using IBM Key Manager, open the .kdb file.
c. From the Key Database Content drop-down list, select Signer Certificates.
d. Click Add to import the certificate for the node. When prompted, assign a name for the certificate
(for example, DemandNode01).
e. Repeat the previous step for all the nodes in the cluster. Assign unique names to each certificate.
f. Save the changes and exit IBM Key Manager.
Configuration required for postAbpprequest when https is

enabled
Add the following to JVM_OPTIONS:
-Djava.security.properties=<Websphere
Install>/AppServer/java_1.7.1_64/jre/lib/security/java.cis.security"
Note: The above step is only for Websphere installations.
Navigate to <Install Dir>\config\platform\bin and uncomment below java options in the

setupAbppEnv.bat /sh. Change SSL_DIR as per environment .
Unix:
export SSL_DIR=/usr/local/SSL
export JAVA_OPTIONS=$JAVA_OPTIONS -Djavax.net.ssl.keyStore=$SSL_DIR/identity.jks -
Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=$SSL_DIR/trust.jks -
Djavax.net.ssl.trustStorePassword=password
Windows:
set SSL_DIR=D:\SSL
set JAVA_OPTIONS=%JAVA_OPTIONS% -Djavax.net.ssl.keyStore=%SSL_DIR%\identity.jks -
Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=%SSL_DIR%\trust.jks -
Djavax.net.ssl.trustStorePassword=password

Apply patch
Appendix A. Apply patch

Patch Overview
JDA applications based on JDA Platform 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 as per 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 whether a partial patch can be applied.
Partial patches are applied via a command-line interface in the JDA installation. In addition to this,
there may be manual steps to be followed in some situations in order to complete the patch
installation. All patches are cumulative, whether the fix is a partial patch or a full installation.
Limitations of partial patches

A partial patch does not support the following situations:
Changes to database migration scripts. If you require a patch to a migration script, you need to
use a full installation.
Changes or additions to configuration files. If a change is needed to a configuration file, you must
apply that change manually after applying the partial patch.
Updates to your database. If incremental changes are needed to your database as part of a patch,
you need to apply those changes manually after the patch has been applied. Each application
provides incremental patch scripts to update the database, if needed.
Installing Full Installation on existing Partial Patch Environments is not supported.
Patch Type
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.
JDA Platform provides additional database patches scripts in th

<install_dir>\config\database\platform directory. It is not necessary to run this script unless
specified in documentation for the JDA Platform-based applications that you are using. The script is
described for reference only.

Apply patch
Script Description
[Windows] apply_db_patches <foundation_pw> This utility runs all the Platform and Monitor
[<monitor_pw>] database patches respectively. If the current
database patch is not the latest, then it will
[UNIX] apply_db_patches.sh <foundation_pw>
apply database patches to get the database
[<monitor_pw>]
to the latest patch.
Here <foundation_pw> [<monitor_pw>] is the Notes: apply_db_patches utility should run
foundation database schemas password and monitor only if applydbpatches parameter is passed
database schemas password respectively. while running the installPatch command.
See the patch_readme.txt after installing the patch. It also updates the ABPP schema.
Note: <monitor_pw> is an optional parameter, After successful application of the patches, it
required only if monitor is installed. records an entry in CSM_SCHEMA_LOG.
Partial Patch
Partial patches are delivered in Zip format. Separate ZIP files are delivered for the following types of
installations:
Server - Used to patch the application server(s) in your configuration.
SRE - Used to patch the SRE installations in your configuration.
Help - Used to patch non-English Help in the application server (if the application is translated).
Unlike a full patch installation where the new patch is installed along with all other applications into a
new directory, partial patch installations are performed on the existing installation. Therefore, a partial
patch must be applied carefully.
Note: When you apply the Help patch, the browser cache needs to be refreshed.
To query for the patch details (type of patch, patch label and patch build date) for a partial patch file,
run the following command from the <Install_Dir>/config/bin/platform directory.
[Windows] installPatch.cmd <patch_file_name> -info
[Unix]installPatch.sh <patch_file_name> -info
For UNIX machines, the .sh extension is not provided for Server installations but provided for SRE
installations. You can also use the history option to see the current list of patches applied (if any) on
you installation.
Note: 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.
The command above will specify the patch information on the command prompt.
For example:
D:\JDA\v2016\config\bin\platform>installpatch
patch_7.5.1.P15001_0101_1700_webworks_weblogic.zip -info
***************************************************
******** Patch Information ***************************
***************************************************
Patch Type : Server
Current Installed Version : 7.5.1

Apply patch
Installing Version : 7.5.1.P15001_0101_1700

Build Date : 20090101_1748
Application Server : weblogic
BUILD SUCCESSFULL
Total time: 4 seconds
The patch ZIP file also contains a version file and patch properties file that details information on the
patch.
Apply Partial Patches

This chapter describes applying partial patches to either an application server or SRE installation.
When you apply a patch on an installation, the Partial patch script does the following:
Analyzes the patch manifest (patch manifest: ChangedFiles.xml)
Backs up the files listed in the patch manifest, along with the relative folder structures.
Creates a compressed archive, which you can use to restore the installation to the pre-patch level.
Extracts and copies the files within the patch compressed into the installed folder structure.
Before you begin
Ensure you have valid installations (application server or SRE) of the JDA applications.
Verify that you have received the right patch in .zip format for your application server.
Set sufficient privileges for the OS users on the installed directories. This is required as the partial
patch framework creates staging directories and users must have the necessary write permissions
on the folders; otherwise, the patch cannot be installed correctly.
Stop the application server. If installing in a clustered installation, make sure you stop all nodes in
the cluster.
Stop all the node pools.
Ensure that you have backed up any files that you will have to change manually. All the changes
that need to be manually performed after applying the patch are contained in the
<Install_Dir>/ManualPPTask folder.
Ensure that you do not have any log files open in the installation directory in any editor.
Apply Partial Patch on Application Server through silent

installation
1. Copy the application server patch file (a ZIP file) to the <Install_Dir>/config/bin/platform
directory.
Note: If the patch contains translated help changes, you must copy both application server ZIP
and help zip files and apply both patches to your application server.
2. Open the installPatch.properties file in a text editor and enter the following values:
APPLY_DB_PATCHES:
Specify yes, if you want to install database patches as part of partial patch installation

Apply patch
Specify no, if you do not want to install database patches as part of partial patch
installation
PATCH_FILE: Specify the patch zip file name and the full path to the patch file.
3. Save and exit installPatch.properties.
4. Open a command-line prompt and change to the directory containing the installPatch.properties
and InstallPatch executable or binary. Enter the following command:
InstallPatch file installPatch.properties
5. Verify that:
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. A patch revert file is
created in the <Install_Dir>/backup directory. The revert file is named:
revert_<type>_<PATCH_NUMBER>_<application>_<APPSERVER>.zip. For more
information on using this file, see "Reverting Patches" (on page 288). There is no revert file
created when translated patch is applied.
If the application server is clustered, install the partial patch on all nodes in the cluster.
If the partial patch contains any local property file changes (for example, changes to
webworks_config.xml, monitor_config.xml, collabsvs_config.xml, scpo_config.xml), these
changes will need to be applied using any instructions in the patch readme file. This file is
located in <Install_Dir>/config/doc folder.
6. To deploy the patch, issue the following command from the config/bin/platform directory:
For a non-clustered installation (WebSphere):

deployEar <admin_user> <admin_password> <server1s_bootstrap_address>
For a non-clustered installation (Weblogic):

deployEar
For a clustered Weblogic installation (run from each node in the cluster):
deployEarToCluster
For a clustered WebSphere installation (run from the deployment manager node):
deployEarToCluster <DmgrHost> <DmgrBootstrapPort> <admin_user> <admin_password>
<cluster_name>
Note: For WebSphere, provide sufficient time for the deployEarToCluster to work. This may take
10 minutes or so as the Deployment manager pushes the application components (various WAR
and EJB modules) to the individual nodes. After sufficient delay, run the following command from
all the nodes:
postDeployConfiguration
7. Start the Server instance. Ensure it is started successfully. If a clustered installation, start all nodes
in the cluster.
8. If running the node pool from the application server installation, start the Node pool.
9. Start the server and verify the patch type, label and the build date in the About page of the
application.

Apply patch
Apply Partial Patch on Application Server Installations

1. Copy the application server patch file (a ZIP file) to the <Install_Dir>/config/bin/platform
directory.
Note: If the patch contains translated help changes, you must copy both application server ZIP
and help zip files and apply both patches to your application server.
2. Open a command or shell prompt, and navigate to the <Install_Dir >/config/bin/platform

directory
3. Install the patch using the command:
Windows
installPatch [patchFileLocation] -apply [-prompt(y,n)] [-applydbpatches]
UNIX
installPatch [patchFileLocation] -apply [-prompt(y,n)] [-applydbpatches]
Notes:
Use -applydbpatches parameter only if you want to install dbpatches as part of partial
patch installation.
Use -prompt parameter only if you want to install the patch without being prompted, enter
n.
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 spaces in between.
If you are applying translated help in addition to the application server patch, you will need
to run the following command for the help after you have applied the application server
patch.
[Windows] installPatch.cmd <specify_patch_file_name_with_entire_path> -apply [-prompt
(y,n)]
[Unix] installPatch <specify_patch_file_name_with_entire_path> -apply [-prompt (y,n)]
You will be prompted to continue the installation. Type "Y", for the patch installation to
continue. If you type "N", the patch installation is aborted.
4. Verify that:
The file patchInstall_<type>_<application>_<patch_number>_<appserver>.log has

no errors. This file is located in the <Install_Dir>/install directory. A patch revert file is
created in the <Install_Dir>/backup directory. The revert file is named:
revert_<type>_<PATCH_NUMBER>_<application>_<APPSERVER>.zip. For more
information on using this file, see "Reverting Patches" (on page 288). There is no revert file
created when translated patch is applied.
If the application server is clustered, install the partial patch on all nodes in the cluster.
If the partial patch contains any local property file changes (for example, changes to
webworks_config.xml, monitor_config.xml, collabsvs_config.xml, scpo_config.xml),
these changes will need to be applied using any instructions in the patch readme file. This file
is located in <Install_Dir>/config/doc folder.

Apply patch
5. To deploy the patch, issue the following command from the config/bin/platform directory:
For a non-clustered installation (WebSphere):

deployEar <admin_user> <admin_password> <server1s_bootstrap_address>
For a non-clustered installation (Weblogic):

deployEar
For a clustered Weblogic installation (run from each node in the cluster):
deployEarToCluster
For a clustered WebSphere installation (run from the deployment manager node):
deployEarToCluster <DmgrHost> <DmgrBootstrapPort> <admin_user> <admin_password>
<cluster_name>
Note: For WebSphere, provide sufficient time for the deployEarToCluster to work. This may take
10 minutes or so as the Deployment manager pushes the application components (various WAR
and EJB modules) to the individual nodes. After sufficient delay, run the following command from
all the nodes:
postDeployConfiguration
6. Start the Server instance. Ensure it is started successfully. If a clustered installation, start all nodes
in the cluster.
7. If running the node pool from the application server installation, start the Node pool.
application.
Apply Partial Patch on SRE Installations

To apply patches on SRE Installations of JDA applications,
1. Copy the SRE patch file (a ZIP file) to the <Install_Dir>/config/bin/platform directory.
2. Stop any node pools running from the SRE installation directory.
3. Close any logs files that may be open.
4. Navigate to <Install_Dir >/config/bin/platform directory
5. Install the patch using the command:
[Windows] installPatch.cmd <patch_file_name> -apply [-prompt (y,n)]
[Unix]installPatch.sh <patch_file_name> -apply [-prompt (y,n)]
Note:
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.
-applydbpatches parameter is not supported for SRE patch installations.
6. Verify that:
The patch command ran successfully with a Build Successful message displayed at the
command prompt.

Apply patch
The file patchInstall_<type>_<application>_<patch_number_appserver>.log has no

errors.
Note: This file is located under <JDA_Install_Dir>/install directory
That the patch revert file is created at the <Install_Dir>/backup directory.
The revert file is named:

revert_<type>_<PATCH_NUMBER>_<application>_<appserver>.zip. For more
information on using this file, see "Reverting Patches" (on page 288).
7. If the partial patch contains any property file changes (for example, webworks_config.xml,
monitor_config.xml, collabsvs_config.xml, scpo_config.xml), these changes will need to be applied
using any instructions in the specific patch documentation.
8. Start the Node pool.
Revert Patches
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>_<aapserver>.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. 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 Platform provides required scripts to roll back the database patches in the directory
<install_dir>\config\database\platform. It is not necessary to run this script unless specified in
documentation for the JDA Platform-based applications that you are using. The script is described for
reference only.
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.

Apply patch
Script Description
[Windows] rollback_db_patches <foundation_pw> This utility rollback all Platform and Monitor
[<monitor_pw>] [<override>][UNIX] database patches respectively.After successful
rollback_db_patches.sh <foundation_pw> rollback of the patches, it removes the patch
[<monitor_pw>] [<override>] entries from the CSM_SCHEMA_LOG.
Here, <foundation_pw> [<monitor_pw>] is the
foundation database schemas password and monitor
database schemas password respectively.
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.
Note: <monitor_pw> is an optional parameter,
required only if monitor is installed.
Note: If any validation message is displayed, then check the dbpatch_rlbk_prevalidation.html file
in the <Install_Dir>/config/database/platform directory. This file provides information on the list of
records that are modified after the applying patch. The listed record should be verified and patch
rollback should be run with override option.
2. Install the appropriate full patch using the installation image. For more information, see "Full
patch" (on page 282).
3. Run the postrollbackdbpatches script from the same installer that you have used in the step 2.
Script Description
[Windows] post_rollback_db_patches This utility can be used to compile all the
<foundation_pw> [<monitor_pw>] stored objects like packages, procedures,
[UNIX] post_rollback_db_patches.sh triggers and views after the patch rollback
<foundation_pw> [<monitor_pw>] process.
Here <foundation_pw> [<monitor_pw>] is the

foundation database schemas password and monitor
database schemas password respectively.
Note: <monitor_pw> is an optional parameter,
required only if monitor is installed.
4. Run the updateAbppSchema script from the same installation that you have used in the step 2.
Rollback partial patch

The patch roll back feature allows you to roll back the patch in the application and database level.
When running the script to revert a patch, you will be prompted whether you want to continue the
installation. If you type "Y", then the patch is reverted to the prior patch. If you type "N", the patch is
not reverted. Also note that it is important to take a secondary backup (example: to a disk) of these
revert files. Having a secondary backup is helpful in case the revert files in <Install_Dir>/backup are
accidentally deleted.
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>_<aapserver>.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

Apply patch
3. Run the following script:
Windows
installPatch <patch_file_location> -apply [-prompt(y,n)] [-rollbackdbpatches [-
override]]
UNIX
installPatch <patch_file_location> -apply [-prompt(y,n)] [-rollbackdbpatches [-
override]]
Parameters:
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 spaces in between.
4. Verify that:
If any validation message is displayed, then check the dbpatch_rlbk_prevalidation.html file

in the <Install_Dir>/config/database/platform directory. This file provides information on
the list of records that are modified after the applying patch. The listed record should be
verified and patch rollback should be run with override option.
The file patchInstall_<type>_<application>_<patch_number>_<appserver>.log has no

errors. This file is located in the <Install_Dir>/install directory.
application.

Send a database to JDA
Appendix B. Send a database to JDA

If you are experiencing problems with your system, JDA Support Services staff may ask you to send
your database to them. For instructions on sending the database to JDA, access the following link:
https://support.jda.com/articles/Question/How-to-send-files-to-JDA-Support?
Alternatively, you can search for the article "000030892" in the support knowledge base by
navigating to
Get Support > Search Knowledgebase

Index
Oracle Thin Driverdatabase co 144, 145
cookie 51, 106
creating
B DDU stored procedure 133
BEA WebLogic password 112, 171 JDA group, UNIX 20
boot.properties 171 JDA user, UNIX 20
browser csmImport 138
enabling JavaScript 52 csmImport.includes 138
browser encodings 147 customer support 9
BuildConfiguration utility 148 D
buildWebsphereConfig
Data Division Utility (DDU) 132
installing additional applications 61
database connection information
C updating 144, 145
Change Management 202 dbconnections.properties 138, 193
changing DDU
combo box 213 Chunk_number 134
default table size 213 creating DDU stored procedure 133
font style 213 ddu_init.cmd 133
Chunk_number (DDU) 134 dividing a table into two chunks 137
classes12.jar 144, 145 dividing on two tables with a different user ID 135
classpath error codes 276
problems on AIX 264 High_boundary 134
cluster Low_boundary 134
configuring 101, 113 lowest and highest ASCII boundaries 135
cluster.properties 138 lowest and highest Date boundaries 135
communications protocol lowest and highest Number boundaries 135
updating 165 lowest and highest RowID boundaries 135
component files 138 multi-byte language support 136
regenerating 148 queries using DDU_RESULTS table 137
config.xml 138 queries using DDU_RESULTS values 136, 137
connection pools 145 security 137
JDBC pools 145 SELECT_CATALOG_ROLE required 137
configuration files 138 using an NLS_COMP setting other than BINARY 136
configuring DDU creation script ddu.plb 133
.profile 61 DDU examples 136
firewall 147 DDU_RESULTS table 133, 134
password properties 167 debug_data.zip 267
server 96 default value
server cluster 101, 113 for UDT columns 210
to use LDAP 157 deleteWebsphereConfig
connection pools installing additional applications 61
refreshing 267 directory structure
testing 267 JDA Foundation 50
troubleshooting 267 dividing a table into two chunks (DDU) 137
connection poolsconnection pools dividing on two tables with a different user ID (DDU) 135

drop_FE_table.sql 71 creating on UNIX 20
dummy.txt 50 JDA user
creating on UNIX 20
E
JDA_JSESSIONID 106
EAR file deployment 97 jdamgr 20
EnrollUDT utility 210 job
environment variables for internationalization 63 errors 199
error codes (DDU) 276 states 199
event services 168 JVM
F garbage collection 267
heap size 143
failed logins
tuning 143
notifying the administration 167
recorded in log files 168 L
firewall LANG 21, 63
configuring 147 LC_ALL 21
first time login window 167 LDAP
G configuring with CSM 157
errors with 264
garbage collection 267
locale 21
gathering
mapping to browser encodings 147
log files for JDA 267
log files 146
genEncryptedPassword command file 170
in SRE 198
genEncryptionKey
login properties 167
for cluster 109, 119
login time window 167
for multiple servers 166
Low_boundary (DDU) 134
H lowest and highest ASCII boundaries (DDU) 135
Heap Size 143 lowest and highest Date boundaries (DDU) 135
help lowest and highest Number boundaries (DDU) 135
getting 9 lowest and highest RowID boundaries (DDU) 135
High_boundary (DDU) 134 M
https 165
ManugisticsPkg.sql 66
I max failed logins 167
installed directory structure 50 max nodes 125
installing MCM 202
preparing for on Windows 16 min nodes 125
installWebWORKS_SRE.properties 47 multi-byte language support (DDU) 136
integration points 138 N
internationalization 63
native2ascii utility 213
J NLS_LANG 63
Java Database Connectivity 144, 145 node configuration 125
Java virtual machine 143 node pool
JDA Foundation configuring to use a cluster 179
environment variables 61 starting 122
JDA group Windows service 123

NodePoolManager.log 198 migrate_webworks_7301_to_74.sql 83
migrate_webworks_74_to_741.sql 85
O
migrate_webworks711_to_72.sql 71
ojdbc14.jar 144, 145 reset_wwf_privileges.sql 71
operating system variables, setting 63 verify_ds_tables.sql 85
Oracle verify_webworks_711_database.sql 71
setting up 21 security
tuning for SRE 199 using an encrypted password for batch authentication
Oracle Thin driver 169
using 21 security (DD) 137
OutofMemory error 264 security (DDU) 137
sending log files to JDA 267
P
server
password expiration 167
changing port 141
password properties 167
configuring 96
port for server, changing 141
setting up for for UNIX 20
Process Manager 202
setting up for Windows 19
properties files 215
updating configuration 141
Q server port
changing 141
queries using DDU_RESULTS table (DDU) 137
setting
queries using DDU_RESULTS values (DDU) 136, 137
operating system variables 63
R setting up
recording security events 168 UNIX server 20
regenerating config.xml 148 Windows server 19
reserved cookie 106 shutdownWebworksServer 100, 138
resource bundles 215 shutting down the server 100
retrieveSigners 46 silent installation
runWebworksTask 267 WebSphere 39
WebWORKS 39
S
WebWORKS SRE 47
scripts software requirements
change_schema_name.sql 92 UNIX 20
cleanse_ds_tables.sql 85 Windows 19
convert_to_char_semantic.sql 71 SRE 202
create_webworks7211_schema.sql 66 global properties 177
csm_expire_all_passwords.sql 92, 167 job states 199
enroll_app_schema.sql 92 node configuration 125
enroll_igp_schema.sql 92 request XML file 182
import_translated_metadata 66, 78 starting node pools 122
ManugisticsPkg.sql 66, 71, 78 system alerts 195
migrate_webworks_71_to_711.sql 71 SRE tables
migrate_webworks_72_to_721.sql 75 SRE_CONNECTION 175
migrate_webworks_721_to_7211.sql 78 SRE_GLOBAL_PROPERTY 175
migrate_webworks_7211_to_722.sql 78 SRE_JOB 175
migrate_webworks_722_to_73.sql 80 SRE_JOB_SUMMARY 175
migrate_webworks_73_to_7301.sql 81

SRE_JOB_TRACE 175 setting up a server 20
SRE_NODE 175 updating
SRE_NODE_CONFIG 175 communications protocol 165
SRE_NODE_POOL 175 database connection information 144, 145
SRE_NODE_POOL_CONFIG 175 server configuration 141
SRE_OPTION_INFO 175 server configuration 141
SRE_OPTION_OVERRIDES 175 Updating the AppClient trust store 46
SRE_SERVICE_INFO 175 user-defined tables
SRE_SERVICE_OPTION 175 creating 209
SRE_SERVICE_OPTION_ INFO 175 creating metadata for 210
SRE_SERVICE_OPTION_SET 175 rules 210, 213
SRE_SERVICE_OPTION_SET_HIST 175 using an NLS_COMP setting other than BINARY (DDU)
SRE_SYSTEM_ALERT 175 136
SREBatchUtility 181, 188 Using mcmExport 204
SSL 165 Using mcmImport 205
startNodePoolManager Using mcmReport 206
startNodePoolManager.includes 138 V
startWebworksServer 97, 138
validateOnly 188
startWebworksServer.includes 138
vptaskstatus.xml 214, 215
suspending account on first login 167
system alert W
for job failure 195 wcif.properties 215
T webworks.common.vars 138
webworks_config.xml 138, 215
task statuses
Windows
changing text 214
setting up a server 19
disabling 214
Windows service
timeouts 125
starting node pool 123
timezone 99
starting servers in a cluster 110
trace level
in SRE 182
troubleshooting 264
troubleshooting SRE 193
tuning Oracle parameters for SRE 199
U
UDT
creating 209
creating metadata for 210
rules 210, 213
uninstalling
DDU and IGP 57
WebWORKS Foundation 58
UNIX
creating JDA group 20
creating JDA user 20
environment variables 61

Platform Installadmin en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Platform Installadmin en

Uploaded by

Copyright:

Available Formats

Installation/Administration Guide

Chapter 2. Pre-requisites ............................................................................................... 11

Chapter 3. Pre-installation tasks ................................................................................... 19

Chapter 4. Installation ................................................................................................... 33

Chapter 5. Post-installation tasks .................................................................................. 61

Chapter 6. Utilities and common tasks ........................................................................ 129

Chapter 7. Troubleshooting ......................................................................................... 264

Appendix A. Apply patch .............................................................................................. 282

Appendix B. Send a database to JDA ........................................................................... 291

Index ........................................................................................................................... 292

Task Description Required

JDA Platform Installation/Administration Guide 7

Task Description Required

Architecture and concepts

Contents of the installation media

JDA Platform Installation/Administration Guide

JDA Platform Common Concepts Reference Guide

JDA Interface Generation Program Reference Guide

JDA Platform Release Notes

JDA Platform Installation/Administration Guide 8

German (Software only)

Portuguese (Software Only)

Italian (Software Only)

Get additional help from JDA

Note: The services provided may vary by application and implementation.

JDA Support Services

Defined service levels and proactive escalation paths

Special Interest Group (SIG) membership

Access to new software releases

Access to the JDA Customer Support website (http://support.jda.com/), which provides:

Self-service user administration

JDA Platform Installation/Administration Guide 9

JDA Consulting Services

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

Process definition and improvement

Program and project management

Functional and technical consulting

JDA Cloud Services

Solution availability management

Optimization and analytics management

JDA Platform Installation/Administration Guide 10

Microsoft Windows Server or UNIX, including setting environment variables

The Oracle database management system

OS Hardware JDK Application Oracle

JDA Platform Installation/Administration Guide 11

OS Hardware JDK Application Oracle

Solaris 11.2 Sun SPARC WebLogic: WebLogic 12.2.1 Oracle

Windows Server 2012 R2 x86 WebLogic: WebLogic 12.2.1 Oracle

Red Hat Enterprise Linux 7 x86_64 WebLogic: WebLogic 12.2.1 Oracle

Solaris Oracle iPlanet version 7.x (WebLogic Server Plug-in 12c )

JDA Platform Installation/Administration Guide 12

WebSphere: IBM HTTP Server version 8.5.5.7

Windows Internet Information Server 8.5

RedHat Enterprise Apache HTTP Server 2.4.4+

Open-Source Component Source Organization

Apache Axis2/C & Axis2/Java Apache

backport-util-concurrent Public Domain

Jakarta Regexp Library Apache

Java Mail API Sun Microsystems

JavaService BSD or GNU

Rolling File Trace Listener

wsit Sun Microsystems or GNU

Oracle database server