This section discusses:
Building and testing packages provides a method to create a package, to define and build a package, to deploy packages to both servers and workstations, and to troubleshoot the packages. These features use a step-by-step director process and include package assembly, package build, and package deployment.
Package build is used to set up a workstation or server with Release 9.1 software. Examples scenarios include:
Setting up a new workstation.
Deploying custom solutions to all or to selected users.
Creating a new pathcode for development.
Deploying a fix.
Changing the package from a full to a partial package on some workstations.
There are options to define three different package types, to build and define packages with custom solutions, and to distribute them through two different deployment options. These options are available to a single server, to a workstation or user, or to selected machines, groups, or individual users. These options can be delivered using just-in-time or scheduled installation methods.
You must define, build, and deploy a custom package in order to include any modifications (changed or added business functions or applications) into a package for deployment to workstations (for example, DV910FA or DV910PA).
The system administrator is required to build and test packages at the server level. An installer may complete the process for the workstations. These processes can take several hours, depending on the scope of your business. The procedures take place on the Deployment Server in the deployment environment as user JDE. Release 9.1 installation must be completed on the Enterprise Server before building and testing packages. The time required to build packages to the workstation varies depending on the database being used.
The package build and assembly process includes many critical tasks that must be successfully completed to install the packages correctly. This section includes a list of known issues associated with the package build, assembly, and deployment process and gives instructions for avoiding them. Before building a package, review these instructions to successfully complete this process.
Package Build in the JD Edwards EnterpriseOne Tools Package Management Guide for information about how to build and deploy packages.
JD Edwards EnterpriseOne Tools Development Standards for Business Function Programming Guide for information on how to convert business functions to support Unicode text strings.
You must have a specific JDK\JRE on the Deployment Server in order to build packages. You can obtain the requisite JDK\JRE from Sun.
For the supported version of the JDK\JRE, refer to Accessing Minimum Technical Requirements (Certifications) in Understanding JD Edwards EnterpriseOne of this guide.
Before you build packages, you should install all application fixes relevant to your business. Application fixes include maintenance packs, ESU bundles, and individual fixes. You should use Change Assistant to find relevant application fixes for system codes associated with the functionality you are using.
Change Assistant is a java-based tool that centralizes and economizes the process of searching, identifying, downloading, and deploying many types of software fixes such as ESUs and Tools Releases. It is available free of charge for maintenance paying customers, and can be downloaded from the Update Center.
Tests conducted in the Oracle labs on EnterpriseOne have shown that the use of this tool results in a significant reduction in elapsed time as well as a considerable reduction in manual steps - when compared to current search, download, and deploy processes.
For instructions on using Change Assistant, refer to Using the Change Assistant in the JD Edwards EnterpriseOne Software Update Guide.
Check the following items before building packages in order to minimize errors during package builds. Perform each of the relevant tasks on the machine where the package will be built.
This section discusses:
Package Deployment will copy the Central Objects tables in your server database to a new set of Metadata Specifications tables in the same database.
You must verify that there is enough space available in your DB2\UDB tablespaces for this extra copy.
Note the space used by your Central Objects tables and their indexes. The new set of Metadata Specifications tables will use additional space approximately the same size (for a full package) as your current Central Objects tables plus indexes. Those tables are:
If you do not have enough free space to accommodate these tables, you must increase the size of your tablespaces or drop the metadata specifications tables for old packages no longer in use.
To verify that specific UBEs are mapped locally:
Open the Object Configuration Manager (OCM).
Find each of the following UBEs and make sure each is mapped locally and is active: R9621, R9622, R98825C, and R98825D.
To verify the
JDE.INI settings on the Enterprise Server:
JDE.INI on the Enterprise Server.
Verify that the BuildArea setting in the [BSFN BUILD] section points to the PACKAGES directory on the Enterprise Server.
Verify that the following LinkFlags settings are correct:
Ensure that the path to the system\bin32 directory on the Enterprise Server is valid.
Ensure that LinkFlags references the path where Release 9.1 is installed.
To ensure that simultaneous builds run properly on your Enterprise Server.
JDE.INI on the Enterprise Server.
In the [BSFN BUILD] section, change the SimultaneousBuilds setting to 5 or less (the default is zero, which enables unlimited builds)
Note:On the UNIX Enterprise Server, the number of simultaneous builds should not exceed the number of compiler licenses.
If you are running with security server turned on, you must add a security override so that the package build process can create the metadata repository tables in Central Objects. Adding a security override must be done by a security administrator. To add a security override, you must first add a system user for the Central Objects data source owner, and then add an override for the EnterpriseOne user who will run the package build.
Refer to the Package Management Guide for further details on setting up security overrides for package build.
If you are upgrading from Xe and you have modified any applications or UBEs with NERs and which are language-enabled, you must ensure this setting is in your
jde.ini of the build machine on which you build the NERs, and also on the Deployment Server on which you are running the upgrade processes:
[INSTALL] Unicode Conversion Codepage=code_page_value
where code_page_value is a valid value for the code page of the language-enabled application with NERs. For example, for Korean language the value would be:
[INSTALL] Unicode Conversion Codepage=ksc-5601
Note:If you are a language customer but have never added NER to your applications, then you are not required to have this setting.
Also note that the
LocalCodeSet= value is no longer used in releases subsequent to Xe.
The following troubleshooting tips are designed to help avoid known issues with the package build, assembly, and deployment process. Review these tips when working through the process.
When naming your packages, do not use these names:
Verify the assemble and build processes completed.
After entering the package information on both the Assembly and Build forms, click the End icon to save the information.
Verify setting on the package definition screen.
When selecting servers on the Build Definition form, ensure that a check mark appears next to each server selected. If no check mark appears, highlight the server in the grid and click Select.
Recompress the parent packages.
After building an update package that updates the parent package, you must recompress the parent package. This step does not occur automatically.
Verify the location of server packages.
When building an update server package, the specified parent package must be stored under the package directory on the server. If the parent package is not under the package directory, the update package does not build.
A package represents a copy of the central objects at a point in time. It contains replicated objects that Release 9.1 reads at run-time. If custom modifications or text overrides have been made at the time that a software upgrade is performed or to deploy development changes, including a specific language, to a local workstation, build a package and specify which language or languages to include in that package. This action involves the following considerations:
Before beginning to build a language package, verify that the language installation is complete. To build the language package, first define the package. Building the package can take several hours, depending on the size of the package and the number of languages used. This task is completed on the Deployment Server, logged on as user JDE in DEP910.
To include language specifications in your package, specify the language in the package definition. The package build process then uses the language preference code. This code is specified as a parameter when building the package. It uses the relational database tables to build the form design aid text and report design aid text specifications. A language package can be a full, update, or partial package.
Caution:When building the client package with translated processing option text, run the build using Microsoft Windows with the system locale set to the appropriate language. If the system locale on the operating system does not match the installed language, the translated text in processing options (POTEXT) will be corrupted.
Building server packages that include languages other than English requires that the LocalCodeSet value of the Release 9.1 client matches the LocalCodeSet value of the
JDE.INI on the Enterprise Server. If the LocalCodeSet value on the local client differs from the one specified on the Enterprise Server, the server package build fails and errors are logged in the
JDE.LOG on the Enterprise Server.
A translated package cannot be deployed to a workstation if the appropriate character set is not installed on that workstation. For example, if creating a package containing Japanese text, the workstation must be loaded with Japanese Microsoft Windows to view the Japanese data correctly.
Caution:To transfer translated objects to a server, complete the server package installation procedures. Define each object you have modified for languages. Therefore, track the objects you changed to include them in a package.
Note:To move all objects, call Global Customer Support for assistance.
JD Edwards EnterpriseOne Tools Package Management Guide for more information about transferring objects to the server.
To assemble a Business Services package:
Navigate to the processing options for Package Assembly from to the Package and Deployment Tools menu by right-clicking the Package Assembly application (P9601), and selecting prompt for values.
Set the processing option entitled Business Services to a value of 1.
Note:This processing option is blank by default.
To begin the assembly process, refer to the chapter entitled Assembling Packages in the JD Edwards EnterpriseOne Package Management Guide.
Building a Package with Published Business Services in the JD Edwards EnterpriseOne Package Management Guide.
Deploying the Package to the Business Services Server in the JD Edwards EnterpriseOne Package Management Guide.