1 Understanding JD Edwards EnterpriseOne

This chapter discusses:

1.1 Understanding This Guide

This guide is designed to direct you through a basic JD Edwards EnterpriseOne upgrade. It is not a substitute for the database administration manuals provided by your Relational Database Management System (RDBMS) vendor, the network administration manuals provided by your network vendor, or the installation and configuration manuals for third-party products used with JD Edwards EnterpriseOne.


You should always check My Oracle Support for revisions to this guide subsequent to the initial release, which coincides with the General Availability of Release 9.1. Generally, this document is republished in its entirety only for the next major applications release of JD Edwards EnterpriseOne.

The book contains only the procedures required for a typical base upgrade with predefined typical environments and databases. However, the upgrade is flexible enough to enable you to:

  • Select specific components to upgrade from multiple predefined environments and databases.

  • Install the Platform Pack to either of these machine combinations:

    • Enterprise Server and Database Server on one machine and one drive - the Installer runs once.

    • Enterprise Server and Database Server on separate machines (or different drives in the same machine) - the Installer runs twice, once for each server.

This guide is designed for management information system (MIS) managers and installers. It outlines the procedures for upgrading to Release 9.1.

To successfully upgrade to Release 9.1, you must understand:

  • Hardware and software requirements

  • Database setup and management

  • Enterprise platforms and operating systems

  • JD Edwards EnterpriseOne Tools Foundation Guide

  • JD Edwards EnterpriseOne Configurable Network Computing Implementation Guide

  • JD Edwards EnterpriseOne Tools System Administration Guide

  • JD Edwards EnterpriseOne Tools Package Management Guide

  • JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide

  • JD Edwards EnterpriseOne Tools Security Administration Guide

At a minimum, review these guides before beginning:

In addition, it is recommended to complete the database product courses that your database vendors provide.

1.2 Understanding the Upgrade Process

This documentation explains the process used to upgrade Release 9.1 software using the upgrade process, which consists of these steps:

  • Install the Deployment Server (see Concurrent Installation below for concurrent operations)

  • Install the Platform Pack (see Concurrent Installation below for concurrent operations)

  • Set up the installation plan by running Installation Planner

  • Run the Installation Workbench

  • Install the HTML Web Server


    A JD Edwards EnterpriseOne HTML Web Server is mandatory to run web-enabled JD Edwards EnterpriseOne applications, which includes all end-user applications and selected tools applications. This guide only describes the definition of the HTML Web Server in regards to the Installation Planner and the Installation Workbench. The installation of the HTML Web Server itself is not covered by this guide. Separate guides describe the separate installation process for the HTML Web Server on the supported platforms using Server Manager. Topics relating to the HTML Web Server other than installation using Server Manager are covered in platform-specific reference guides. Such topics include the installation and configuration of the underlying application servers.

    Refer to these Tools Release guides which are available on the JD Edwards EnterpriseOne Documentation library. This library is located on the Oracle Technology Network, which can be accessed at this link:


  • Install the workstations for developers and system administrators

Concurrent Installation

You can concurrently install the Deployment Server, the Platform Pack, and the HTML Web Server assuming the installation programs are run on different machines (not recommended for VM environments). This can decrease the overall time it takes to complete the upgrade.

Recommended Configurations

You can set up your Release 9.1 configuration in many ways. You should follow the typical setup and naming conventions whenever possible, unless there is a strong business case that supports the need to change.

See Also

Typical Customer Configuration in the JD Edwards EnterpriseOne Configurable Network Computing Implementation Guide for more information about the typical customer configuration provided with Release 9.1.


JD Edwards EnterpriseOne Release 9.1 does not support coexistence.

This section discusses:

1.2.1 What an Upgrade Preserves and Replaces

If custom modifications are required, follow the rules listed below to ensure a smooth and predictable upgrade. These rules describe which modifications the upgrade process preserves and which modifications the upgrade replaces.

Preserve means during an upgrade the custom modifications are not lost during the automatic and visual merges of the new applications shipped with the upgrade. If there is a direct conflict between your specifications and those in the upgrade, the upgrade process uses yours. When there is no direct conflict between the two, the upgrade process merges the two specifications.

Replace means the upgrade does not merge your custom modifications into the new release. Custom modifications must be redone after the upgrade is completed.

Customization Considerations

If possible, transfer all modifications to one pathcode. Do this only after testing and approving all modifications or if the modifications are only in development. Having only one environment to upgrade significantly shortens the process.

Refer to the JD Edwards EnterpriseOne Tools Package Management Guide for more information about custom modifications and how they are affected by the upgrade process. Interactive Application Rules

Do not delete controls, grid columns, or hyperitems on existing software applications; instead, hide or disable them. JD Edwards EnterpriseOne might use these for calculations or as variables. Deleting them might disable major functionality. Modified JD Edwards EnterpriseOne applications are ignored by batch merge. All changes must be retrofit via Visual FDA\ER Merge.

An upgrade preserves custom changes to:

  • New applications (batch merge).

  • New objects on existing forms using Visual FDA Merge, including:

    • New hyperitems.

    • New controls.

    • New grid columns.

    • Any style changes, such as fonts and colors.

  • Any code-generator overrides.

  • Data dictionary overrides.

  • Location and size changes for controls.

  • Sequence changes for tabs or columns.

Custom forms on existing JD Edwards EnterpriseOne applications are not preserved. A set of visual merge tools have been provided to assist in retrofitting custom modifications.

Refer to the JD Edwards EnterpriseOne Tools Development Tools: Form Design Aid Guide for more information on Visual Merge Tools and FDA Compare. Report Rules

These rules apply to report specifications that were created using Report Design Aid (all are batch merges).

An upgrade preserves these changes:

  • New reports

  • New elements to existing JD Edwards EnterpriseOne reports, including:

    • Constants.

    • Alpha variables.

    • Numeric variables.

    • Data variables.

    • Runtime variables.

    • Database variables.

    • Dictionary variables.

    • Any style changes, such as fonts and colors.

  • Location and size changes for objects.

  • Data dictionary overrides.

Custom sections in existing JD Edwards EnterpriseOne reports are not preserved. Application Text Changes

An upgrade does not automatically preserve overrides done in Form Design Aid or Interactive Vocabulary Overrides. They must be retrofit using FDA Visual Merge. UBE Text Changes

An upgrade automatically preserves overrides done in Report Design Aid or Batch Vocabulary Overrides. Table Specification Rules

An upgrade merges your custom table specifications from one release level to the next.

An upgrade preserves these changes:

  • New tables.

  • New indexes on JD Edwards EnterpriseOne tables.

An upgrade replaces columns added or removed from existing JD Edwards EnterpriseOne tables, including changing field length, field type, and decimal position.

Instead of adding a new column to an existing table, use a tag file with product codes 55 through 59. For custom tag files, be aware of data item changes in the data dictionary. From one release to the next, JD Edwards EnterpriseOne might change certain data item attributes, such as data item size, which can affect data integrity and how data is stored in the database.

For this reason, use the Table Conversion tool to convert the custom tag file data to the new release level. For base files, the upgrade process takes care of the data dictionary changes by upgrading the previous database. An upgrade preserves custom indices over the custom tag files. Control Table Rules

An upgrade merges your control table data, not JD Edwards EnterpriseOne tables, from one release level to the next using the Change Table process as the basis to do the data merge.

An upgrade preserves these changes:

  • Data dictionary custom changes.

    These include such as changes to row, column, and glossary text. The upgrade process uses your data dictionary as the base.

  • User-defined codes.

    The upgrade process merges any new hard-coded values. (These values are system 90 and above, and H90 and above.)

  • Solution Explorer Tasks.

    Consider these affects on the customization of Solution Explorer Tasks:

    1. During an upgrade, your custom changes on any JD Edwards EnterpriseOne base task overrides any new changes from JD Edwards EnterpriseOne.

    2. If any new custom task (TASKNM) has been added that conflicts with a new JD Edwards EnterpriseOne base task, the custom task will be replaced.

See Also

Chapter 9, "Performing Merges" for more information about merges. Business View Rules

Do not remove columns from existing business views. Changing business views that applications use can cause unpredictable results when running the application. Hide columns at the application design level using either Form Design Aid or Report Design. Performance is not gained by deleting a few columns from a business view.

An upgrade preserves these changes:

  • New custom business views.

  • New columns or joins to the existing business views.

An upgrade replaces columns removed from business views. Rules for Event Rules

An upgrade preserves these changes:

  • For APPL, all retrofitting is done using the Visual FDA\ER Merge tools.

  • Custom event rules on a new custom control field.

  • For reports, tables, and business function events that do not have any event rules attached to the same event.

  • An upgrade replaces modifications to applications, reports, tables, and business functions events that have existing event rules.

    Use the Visual ER tools to restore custom event rules. Data Structure Rules

An upgrade preserves all of these custom data structures:

  • Forms

  • Processing options

  • Reports

  • Business functions

  • Generic text

An upgrade replaces all custom modifications to JD Edwards EnterpriseOne data structures. No changes to JD Edwards EnterpriseOne structures are preserved. Business Function Rules

For any newly created custom business functions, create a new parent DLL directory to store them.

An upgrade preserves new custom business function objects, including custom BSSV objects.

An upgrade replaces modifications made to existing business functions and any business functions added to existing business function objects. Refer to the JD Edwards EnterpriseOne Tools Development Tools: APIs and Business Functions Guide. Versions

For XJDE versions, nothing carries forward. The user JDE owns specifications and processing option data.

For ZJDE versions, specifications do not carry forward while processing option data changes do carry forward.

All other custom versions should have processing option data and specifications carried forward.

1.2.2 Understanding the Deployment Server Installation

The Deployment Server is the focus of the Release 9.1 upgrade process. The upgrade program for the Deployment Server copies the Release 9.1 software from the installation images to the Deployment Server. From the Deployment Server, the Release 9.1 software is distributed to one or more Enterprise Servers and workstations.

The Deployment Server installation program updates the Microsoft Windows registry with information about the Release 9.1 installation and languages, if applicable.

1.2.3 Understanding the Platform Pack Installation

Rather than transferring all the software from the Deployment Server, the Platform Pack installs the code and database directly to the Enterprise Server. This more direct installation method increases performance during this part of the process. It is especially beneficial in situations in which the Enterprise Server is connected to the Deployment Server using a wide area network (WAN). Since the Deployment Server and Platform Pack have separate Installers, they can be running concurrently which decreases the overall installation time (assuming the Installers are run on different machines).

1.2.4 Understanding the Installation Planner

Installation Planner is an application that runs as a stand-alone program on the Deployment Server. Installation Planner configures the environments for all machines within the enterprise. It also is a system administration tool that stores all information about the installation plan in a set of preloaded tables in the Planner data source. Installation Planner guides you through setting up the installation plan step-by-step based on options you choose.

Installation Planner manages these processes:

  • Language setup

  • Location setup

  • Deployment Server setup

  • Enterprise Server setup

  • HTML Web Server

  • Additional server setup

    This includes setup to servers such as a Database Server.

  • Data source setup

    This includes setup for both Enterprise Server-specific and shared environment data sources.

Some data sources remain the same between releases:

  • Business data

  • Control tables

Other data sources are release specific:

  • System and data dictionary

  • Server map

    The server map is machine-specific and release-specific if separate environments are maintained.

  • Environment setup

    This includes all environments for a typical customer configuration, and creation of a new environment, such as PD910. This process ensures that the Object Configuration Manager (OCM) mappings are correct and the new environments point to the correct path codes. This could include creating custom environments and path codes.

  • Control table merges

    The control table planner program offers these merges for customers upgrading to Release 9.1 from a previous release:

    • Data Dictionary Merge (R989200P).

    • User Defined Code Merge (R9600042).

    • Solution Explorer Merge (R9690002).

    • Favorites Merge (R96911002).

    • Report Director Templates Merge (R96914002).

    • Tips of the Day Merge (R96915002).

  • Table conversions

    You can convert all tables for which JD Edwards EnterpriseOne has made database changes, including technical, specification, and vertical tables.

  • Specification table merges

    You can use the upgrade process to merge custom modifications with JD Edwards EnterpriseOne applications. A single batch application merges changes to these objects:

    • Tables

    • Business views

    • Data structures (only new are added)

    • Interactive applications (no changes are merge, just new objects are added)

    • Batch applications

    • Business functions (only new are added)

    See Modifications Rules in the JD Edwards EnterpriseOne Tools Package Management Guide for information about changes that merge or overlay former data.

  • Package Workbench

    You use Installation Planner to perform on environment-level operations that deal primarily with processing activity on the Enterprise Server platforms. You use it to set up user profiles and workstation installations after installing the Enterprise Server.

1.2.5 Understanding Installation Workbench

Installation Workbench runs the plan created during Installation Planner. It functions as a central point for all the processes required to install environments. Some of the processes that install environments might require procedures to be performed manually. However, Installation Workbench assures that procedures are performed in the proper order, and insulates you as much as possible from platform-specific environment setup.

1.2.6 Understanding the Workstation Installation

The JD Edwards EnterpriseOne Development Client (also known as a Web Development Client, "Fat" Client, Administrative Client, Windows client, or Workstation) contains components that run as standard Microsoft Windows applications (for example, Active Console, Forms Design Aid (FDA), and Report Design Aid (RDA)) and components that run in a web browser.


This document uses the following terminology when discussing JD Edwards EnterpriseOne clients:
  • Web Client

    Components that run in a web browser.

  • Development Client

    Composed of standard Windows components and Web Client.

The Web Client part of the Development Client runs inside an Application Server. The supported Application Servers are:

  • Oracle Application Server (OAS)

  • IBM WebSphere Application Server (WAS) Express or WebSphere Application Server for Developers.

The Oracle Application Server is included as part of the JD Edwards EnterpriseOne system code and is automatically configured to work with the Web Client when you install the Web Client for OAS. This version of the Web Client is known by any of the following names:

  • Oracle Containers for Java HTML for Applications,

  • OC4J for H4A, or simply

  • OH4A.

Although OAS is included with JD Edwards EnterpriseOne system code, you can choose to use WAS Express or WAS for Developers as the Application Server for the EnterpriseOne Web Client. Both products are similar; either one may be manually installed before installing the Web Client for WAS. Whereas WAS Express requires a licensing fee to IBM, WAS for Developers is free. The version of the Web Client that is installed on either WAS product is referred to by either of these names:

  • HTML for Applications or

  • H4Ax (where the "x" denotes the version of WAS Express or WAS for Developers; currently, the supported version is 7).

This guide describes how to install Web Clients for both Application Servers: OH4A and H4A7. In addition, it covers the installation of WAS 7 Express or WAS 7 for Developers.

The first time setup of the JD Edwards EnterpriseOne Development Client installer and installation package on an EnterpriseOne Deployment Server is described in a separate guide entitled: JD Edwards EnterpriseOne Deployment Server Reference Guide. This setup on the Deployment Server must be done before a user can install a JD Edwards EnterpriseOne Development Client on a workstation. The installation package specifies the components to install and may or may not include the Web Client.

1.3 Considering Additional Factors

This section discusses:

1.3.1 Accessing Minimum Technical Requirements (Certifications)

Customers must conform to the supported platforms for the release as detailed in the JD Edwards EnterpriseOne Minimum Technical Requirements. In addition, JD Edwards EnterpriseOne may integrate, interface, or work in conjunction with other Oracle products. Refer to the following link for cross-reference material in the Program Documentation for Program prerequisites and version cross-reference documents to assure compatibility of various Oracle products.


Access the current Minimum Technical Requirements (MTR) from My Oracle Support (https://support.oracle.com) by searching for this document:

745831.1 (JD Edwards EnterpriseOne Minimum Technical Requirements Reference)


1.3.2 Understanding Machine Names

Due to underlying requirements in the machine name tables, you must ensure that all machines names in the JD Edwards EnterpriseOne environment conform to specific rules. Whenever you manually enter a machine name in JD Edwards EnterpriseOne, or whenever a machine name is programmatically determined, it is important to note that the machine name:

  • Is case-sensitive

  • Cannot exceed 15 characters

  • Must be alphanumeric only and cannot contain any special characters, such as underscores or hyphens

Any machine whose name does not conform to these rules cannot be used in the JD Edwards EnterpriseOne environment.

1.3.3 Using JD Edwards EnterpriseOne Support

Use My Oracle Support to access customer support functions and information including issues, Software Action Requests (SARs), and to access the Oracle JD Edwards Update Center. Through the Update Center, you can research and download Service Packs, Electronic Software Updates (ESUs), view SARs and objects, and documentation.

If you need further assistance with Release 9.1 upgrade, contact Oracle customer support by phone, fax, or e-mail. For questions about operating systems, databases, and other software products, contact the appropriate vendor.

1.3.4 Understanding Documentation Conventions

This section explains these typographic and design conventions used throughout this documentation. Documentation Updates

The Oracle Technology Network for JD Edwards Documentation always contains the most recent documentation, which may include document updates and other information about installing and upgrade JD Edwards EnterpriseOne. You can use this link to access the Oracle Technology Network for JD Edwards Documentation:

http://www.oracle.com/technetwork/documentation/jdedent-098169.html Tips

This documentation contains tips containing information that can make the JD Edwards EnterpriseOne setup process easier. Tips information is helpful but optional. Fonts and Type Styles

Special fonts and type styles are used in this guide. Nearly all of the commands in this guide are case sensitive. Enter them exactly as written. In addition, all of the commands described illustrate the recommended directory structure. If your machine's directory structure is different, modify the commands to match your directory structure.

Italic type style designates variables used in the guide. For example, for the variable deployment_server in a command, substitute the actual name of your Deployment Server. Also, the names of other JD Edwards EnterpriseOne guides are in italic type style. For example, JD Edwards EnterpriseOne Tools Package Management Guide.

Courier font indicates explicit file names, commands, or other information that must be typed into the system. For example, a common file name used by JD Edwards EnterpriseOne is an initialization file called the JDE.INI.

1.4 Working With the Customer Checklist

The Release 9.1 support structure consists of components such as databases, operating systems, and hardware. To upgrade Release 9.1 successfully, set up the support structure before starting the installation process.

The tasks in this section are designed to prepare the customer's system for the installation process. Some of the tasks, such as checking that the appropriate hardware and software are available, can take some time to complete. Other tasks are quick and easy.

This checklist helps to organize the required upgrade preparation:

  • Review Section 1.5, "Environments Overview".

  • If the installation involves a secondary language, review Section 1.6, "Language Process Overview" in this chapter.

  • Assess the network.

  • Back up the Deployment Server.

  • Back up the existing language package directory (for language clients only).

  • Back up the Enterprise Server.

  • Back up the databases.

  • Prepare the prototype environment.

  • Prepare the development environment.

  • Check media object queues.

  • Check modification and merge flags.

  • Prepare environments for upgrade.

  • Refresh the business data (optional).

  • Refresh the control tables.

  • Verify custom changes in master control tables.

  • Verify third-party hardware and software.

  • Verify that the Deployment Server hardware and software meet minimum technical requirements.

  • Verify that the Enterprise Server hardware and software meet minimum technical requirements.

  • Verify that the workstation hardware and software meet minimum technical requirements.

  • Verify that HTML Web Server hardware and software meet minimum technical requirements.

  • Verify that the Deployment Server disk space meets minimum technical requirements.

  • Verify that the Enterprise Server disk space meets minimum technical requirements.

1.5 Environments Overview

The HTML Web Server (J) environments have the same mappings as the regular environments with the exception of logic, all of which is mapped to run on the Enterprise Server.

Each environment shipped with Release 9.1 has a specific use. The following sections explain each environment in more detail.

1.5.1 Understanding Environments

The Release 9.1 software includes several environments that represent the typical customer configuration as defined in the JD Edwards EnterpriseOne Configurable Network Computing Implementation Guide. These environments are preset to make the installation process as easy as possible. This section contains additional information about these environments and their role in the installation and upgrade process.

Follow the setup recommendations and naming standards described in this guide to minimize confusion when communicating with those outside of your implementation team. In addition, future upgrades are simpler if you use JD Edwards EnterpriseOne naming conventions. If you customize your configurations during the process, you should change only the descriptions provided with the typical setup.

JD Edwards EnterpriseOne provides the following preset environments:

  • Deployment (DEP910)

  • Planner (JDEPLAN)

  • Prototype (PY910)

  • Pristine (PS910)

  • Development (DV910)

  • Production (PD910)

  • HTML Web Server (J)

1.5.2 Planner Environment (JDEPLAN)

The software installation and upgrade process includes a planning stage called the planner environment. Using this approach you can define the main components of your software configuration without affecting the production environment.

Every environment must have an associated pathcode and a set of OCM mappings. The planner environment uses a planner pathcode, which is shipped with the software, and a set of OCM mappings, which point to a planner database. All pathcodes share a complete set of runtime central objects on the Deployment Server. Planner Pathcode

Release 9.1 provides a full set of runtime objects, which are used during the installation process. The software stores these objects on the Deployment Server in the planner directory. The planner pathcode contains the only complete set of runtime central objects on the Deployment Server, which are shared by all pathcodes.

The planner pathcode includes preloaded packages used during the update specification merge process. A package indicates the necessary objects for a workstation, a point-in-time snapshot of the central objects on the Deployment Server, and where the installation program finds them. Planner Database

All information created and updated during the planning stage is saved in these Oracle tablespaces:

  • JDEPlan910

  • JDECTL910

  • JDEDD910

  • JDSYS910

  • JDEVL910

  • JDEOL910

  • JDEData910

When using the planner environment to change your configuration:

  • Planner database tables are updated with the change.

  • A plan is defined and run to move the change to the production environment.

When using the deployment or production environment to change your configuration after finishing the process:

  • Production environment tables in the System pathcode are updated in real-time.

  • Planner database tables are not updated.

For the deployment and production environments, OCM and data source information comes from the planner database.

You should use the production environment system (technical) tables to make changes to environments, pathcodes, packages, and OCM.

1.5.3 Pristine Environment (PS910)

Use the pristine environment (PS910) to test pristine (un-customized) objects with JD Edwards EnterpriseOne demonstration data or for training classes. The pristine environment is also used to run Table Conversion processes during an upgrade. This environment is required to compare modified objects to pristine objects. When encountering a software problem that JD Edwards EnterpriseOne Global Support cannot duplicate, they will ask you to sign on to the pristine environment to duplicate the problem. Routinely, either monthly or quarterly, refresh the data for this environment from the JDEPLAN environment on the Deployment Server.

You should apply all software updates, ESUs, and Service Packs to the Pristine environment.

1.5.4 Deployment Environment (DEP910)

Use the deployment environment to run packages builds on the Deployment Server. The deployment environment uses the planner pathcode and has OCM mappings to the production environment system tables and local data. Only one deployment environment is required because all environments created by the installation process share common data sources.

The deployment environment uses system information, such as environments, packages, and user profiles. The OCM mappings and data source information are supplied by the planner database.

1.5.5 Development Environment (DV910)

The development environment is for development objects (DV910 pathcode). Log on to this environment to modify and test objects before transferring them to the prototype environment (PY910) pathcode. After transferring the objects into PY910, build and install a full or partial prototype package (for example, PY910FA or PY910PA), and then log on to the prototype environment for additional testing. The Development environment is delivered with JD Edwards EnterpriseOne Demonstration data.

1.5.6 Prototype Environment (PY910)

The prototype environment is the staging environment for production. Constants tables and master tables, such as company constants, fiscal date patterns, and item master are populated with production data during the prototype process. Copy the tables to the production environment before going live.

1.5.7 Production Environment (PD910)

Production users have a tested and released package on their system. Batch applications can run on the Enterprise Server.

1.5.8 Additional Considerations

Additional considerations include: Cluster Software Options

When using cluster software, additional issues exist that must be taken into consideration before installing Release 9.1. Web-Based Options

The HTML Web Server installation enables the use of Web-enabled functions in Release 9.1.

See Also

HTML Web Server, Java Server, or JAS in the JD Edwards EnterpriseOne Tools HTML Web Server Installation Guide for more information about Web-based options.

1.5.9 Release History

This version of JD Edwards EnterpriseOne is Release 9.1. The following list shows the currently supported previous releases of JD Edwards EnterpriseOne:

  • Release 9.0

  • Release 8.12

  • ERP8, 8.11, and 8.11 SP1 (8.11 and 8.11 SP1 are on extended support only)

  • OneWorld Xe

1.6 Language Process Overview


Languages are installed using the Installation Planner. The Language installation image is required to implement this functionality. If you install additional languages, you will perform the procedures after you have executed the initial installation described in this guide. For additional details, refer to the chapter Chapter 22, "Creating a Language-Only Installation Plan" in this guide.

This section is provided in this guide for references purposes. The language installation process automatically copies the text from a language database to the production Release 9.1 database and merges the alternate language text with the original English base. These automated processes are described throughout this guide. When installing language for the first time, a language-only plan may be chosen after completing the initial plan.

See Also

1.6.1 Language Architecture

The software language architecture incorporates multinational language functionality for international customers. The software specifies the language preference for forms and reports. For example, users who share the same environment may want to view the same text in multiple languages, such as French, Spanish, and English. All language text is stored in a central location and deployed to the individual workstation.

JD Edwards EnterpriseOne provides all software with a base language of English. The package build process enables the building of packages for multiple languages. Multiple languages can be installed using the processes outlined in this guide. Language text is accessed by the language preference code settings in the user profile associated with the alternate language installed. Base Language

Release 9.1 language support works in conjunction with the English base language. The base release contains English and must be installed before creating custom modifications to include changes or additions to the translated text. All control files must also have an English record prior to adding an alternate language text record. Alternate Language Components

An alternative language component is not included in this release; you must build the language package.

An alternate language includes major components whereby language text is stored in the Central Objects, System, Control Table, and Data Dictionary data sources. The data is loaded to the Deployment Server during the installation and copied to the Central Objects and the other data sources through the language installation process.

For Release 9.1, JD Edwards EnterpriseOne is shipped with 21 languages. Single-byte languages run on single-byte or double-byte operating systems, but double-byte languages must run on double-byte operating systems.

Instructions in this guide explain how to set up these features.

See Also

Package Build in the JD Edwards EnterpriseOne Tools Package Management Guide for more details on how to build a language package. Language Preference Codes

The language preference codes are the standard language codes used throughout the software. The Language Preference Code field, located in the Release 9.1 user profile, determines which language is displayed on forms or reports. All users are assigned a language preference code within the user profile.

A blank language preference code specifies the base language of English. Alternate language records always have a value in the language preference code.

The alternate language text tables contain language preference codes. The tables contain several records for each item, such as a user defined code value as well as possible multiple records for a code value, with each code representing a different language.

If the language preference code does not have a corresponding translated language record, the base English record is the default record.

Certain database tables, such as the Business Unit Master, AAIs, Account Master, and Item Master, also contain the language preference code in an additional description table. This information is not translated in the JD Edwards EnterpriseOne demonstration data.

Release 9.1 applications support the use of languages. Refer to the individual applications to set up and use multiple languages.

1.6.2 Database Character Set and Code Page Considerations

Data within a database is defined by a set of parameters. Each character within the database is identified by a specific language preference code value. A collection of characters within a defined database is called a character set or code page. A character set or code page setting is a scheme for encoding character data. Every character is defined by a unique hexadecimal value. These values can change between databases and languages. Every language is represented by at least one character set. Some character sets may contain multiple languages.

For example, the Western European character set contains all characters common to the Western European languages (Aa - Zz) and all special characters unique to specific languages, such as ', ', ', and '. Asian character sets are specific to one language.

The software uses code page conversions to control the consistent or desired display of data. A code page conversion adjusts the hexadecimal values of different characters so that the appearance of text on the desktop is the same with different code pages.

When installing or upgrading the database, set up the code page for the language before loading your language specifics for Release 9.1.

See Also

Section, "Single-Byte and Double-Byte Considerations" to determine the LocalCodeSet and code page settings for your database machine environment. Unicode

Unicode specifies that the data stored in the data source is in Unicode format. For installs, all data sources default to Unicode.

For DB2 UDB, Unicode is required for Central Objects data sources and any other data sources using the same database as Central Objects.

Note that the code page still must be set to the correct value even though the data sources may all be Unicode. The Unicode flag only indicates what column type is used to store character data in a Unicode database.

See Also

JD Edwards EnterpriseOne Unicode Data Conversion Guide for information on how to convert data to Unicode.

JD Edwards EnterpriseOne Tools Development Standards for Business Function Programming Guide for information on how to convert Business Functions to support Unicode text strings.

JD Edwards EnterpriseOne Flat File Conversion Guide for information on how to convert Flat Files to Unicode. Code Page Settings

You should use the code page settings in this guide. The correct code page should be set when the database is created. DB2 UDB

The IBM code-set of the database and OS Locale needs to be set correctly for the language used as listed in this table:

Tier Language DB2 UDB Code-Set
1 English 1252
1 French


1 German


1 Italian


1 Spanish


1 Portuguese 1252
1 Japanese IBM-943
2 Danish 1252
2 Dutch 1252
2 Finnish 1252
2 Norwegian 1252
2 Swedish 1252
2 Korean 1363
2 Traditional Chinese big5
2 Simplified Chinese GBK
3 Arabic 1256
3 Czech 1250
3 Hungarian 1250
3 Polish 1250
3 Greek 1253
3 Russian 1251
3 Turkish 1254 Workstations and Deployment Server

Code page settings for individual languages are specified in Microsoft Windows System locale. Verify that the Deployment Server code page is set correctly prior to upgrade.

1.6.3 National Language Support

National Language Support (NLS) is a set of common standards that enable data to be entered, displayed, stored, retrieved, and printed in multiple languages, in different databases, and on different platforms.

NLS is information that requires the set up of code pages and the JDE.INI for the Enterprise Server and JDE.INI for the web development workstations. By using NLS standards, JD Edwards EnterpriseOne maintains consistent data within all databases and hardware platforms. The same database can store alternate language text, relying on NLS standards to manage the text storage and retrieval. JD Edwards EnterpriseOne uses NLS, on all supported platforms, to interact with any computer system (hardware and software) within your own environment.

For the workstation to reflect the language installed on the Deployment Server, perform the tasks for both the Enterprise Server and workstations to verify and modify the JDE.INI settings. These procedures are described throughout this guide. Single-Byte and Double-Byte Considerations

Many single-byte languages support either national code pages or multinational code pages. The double-byte languages support specific individual national code pages by language.

Single-byte character sets use a collection of phonetic characters that require one byte to create a single character. Conversely, the double-byte character sets use ideographic characters and require two bytes to create a single character.

Single-byte languages can generally be run on single-byte or double-byte systems. Double-byte languages, such as Japanese, Chinese, and Korean, must run on machines configured to support a double-byte system. For example, a double-byte SQL Server or Oracle database is required for Chinese and Japanese languages.

The software can perform a Query By Example (QBE) on any character. However, when using a double-byte language, this process may not necessarily use an understandable collating sequence, although it can still use QBE for any double-byte column.

The following table shows the languages that the software supports and the LocalCodeSet values set in the JDE.INI for each platform:

Tier Language Language Code LocalCodeSet Value
1 English E WE_ISO88591
1 French F WE_ISO88591
1 German G WE_ISO88591
1 Italian I WE_ISO88591
1 Spanish S WE_ISO88591
1 Portuguese P WE_ISO88591
1 Japanese J JA_SJIS
2 Danish DN WE_ISO88591
2 Dutch DU WE_ISO88591
2 Finnish FN WE_ISO88591
2 Norwegian NO WE_ISO88591
2 Swedish W WE_ISO88591
2 Korean KO KO_KSC
2 Traditional Chinese CT TC_BIG5
2 Simplified Chinese CS SC_GB
3 Arabic AR AR_CP1256
3 Czech C EECP1250
3 Hungarian HU EECP1250
3 Polish PO EECP1250
3 Greek GR GR_CP1253
3 Russian RU RS_CP1251
3 Turkish TR TK_CP1254 Font Considerations

JD Edwards EnterpriseOne includes standard language fonts in a separate file. Some languages (such as double-byte) require special fonts to display and print correctly. The software stores the font settings in files according to language. Individual users can choose fonts by language for forms, grids, and reports. User Display Preferences

User display preferences are individually defined sets of Release 9.1 characteristics that are stored in the user profile. The software uses these preferences to determine how menus and forms are presented to individual users and where language is to be used in Release 9.1 for that user. After user display preferences are set up for a given user, the values remain the same on any workstation that the user accesses. Refer to the JD Edwards EnterpriseOne Tools System Administration Guide for information about modifying user profiles.