This chapter discusses:
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.
Note:
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.
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
Note:
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:
http://www.oracle.com/technetwork/documentation/jdedent-098169.html
Install the workstations for developers and system administrators
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.
Installations of Depoyment Server and Enterprise Server on the Same Machine
Installations of the Deployment Server and Enterprise Server on the same machine, which are commonly referred to as combo boxes, are not supported in production environments.
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.
Note:
JD Edwards EnterpriseOne Release 9.1 does not support coexistence.This section discusses:
Section 1.2.2, "Understanding the Deployment Server Installation"
Section 1.2.3, "Understanding the Platform Pack Installation"
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.
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.
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.
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.
An upgrade does not automatically preserve overrides done in Form Design Aid or Interactive Vocabulary Overrides. They must be retrofit using FDA Visual Merge.
An upgrade automatically preserves overrides done in Report Design Aid or Batch Vocabulary Overrides.
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.
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:
During an upgrade, your custom changes on any JD Edwards EnterpriseOne base task overrides any new changes from JD Edwards EnterpriseOne.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
Note:
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.
This section discusses:
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.
http:\\www.oracle.com\corporate\contracts\index.html
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)
https://support.oracle.com/epmos/faces/DocumentDisplay?id=745831.1
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.
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.
This section explains these typographic and design conventions used throughout this documentation.
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
This documentation contains tips containing information that can make the JD Edwards EnterpriseOne setup process easier. Tips information is helpful but optional.
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.
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:
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
Production users have a tested and released package on their system. Batch applications can run on the Enterprise Server.
Additional considerations include:
When using cluster software, additional issues exist that must be taken into consideration before installing Release 9.1.
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.
Note:
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 21, "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
Section 5.4, "Running the Installation Planner for an Upgrade"
Chapter 21, "Creating a Language-Only Installation Plan" for the tasks that must be completed when choosing to install an alternate language after completing the base installation.
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.
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.
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.
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.
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 1.6.3.1, "Single-Byte and Double-Byte Considerations" to determine the LocalCodeSet and code page settings for your database machine environment.
Unicode specifies that the data stored in the data source is in Unicode format. For installs, all data sources default to Unicode.
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.
You should use the code page settings in this guide. The correct code page should be set when the database is created.
Both the NLS_characterset and NLS_LANG environment variables need to be set correctly.
Additionally, the Oracle character set for the database needs to be set correctly depending on the language used as listed in this table:
| Tier | Language | Code Page Setting |
|---|---|---|
| 1 | English | WE8MSWIN1252 |
| 1 | French | WE8MSWIN1252 |
| 1 | German | WE8MSWIN1252 |
| 1 | Italian | WE8MSWIN1252 |
| 1 | Spanish | WE8MSWIN1252 |
| 1 | Portuguese | WE8MSWIN1252 |
| 1 | Japanese | JA16SJIS |
| 2 | Danish | WE8MSWIN1252 |
| 2 | Dutch | WE8MSWIN1252 |
| 2 | Finnish | WE8MSWIN1252 |
| 2 | Norwegian | WE8MSWIN1252 |
| 2 | Swedish | WE8MSWIN1252 |
| 2 | Korean | KO16MSWIN949 |
| 2 | Traditional Chinese | ZHT16MSWIN950 |
| 2 | Simplified Chinese | ZHS16GBK |
| 3 | Arabic | AR8MSWIN1256 |
| 3 | Czech | EE8MSWIN1250 |
| 3 | Hungarian | EE8MSWIN1250 |
| 3 | Polish | EE8MSWIN1250 |
| 3 | Greek | EL8MSWIN1253 |
| 3 | Russian | CL8MSWIN1251 |
| 3 | Turkish | TR8MSWIN1254 |
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.
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 |
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 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.