This chapter contains the following topics:
Typically, both consultants and customers participate in an implementation. Consultants perform these roles:
CNC consultant.
Custom solution consultant.
Application consultant.
Hardware, network, and third-party software consultant.
Customers perform these roles, which parallel the consultant roles:
CNC administrator.
Application developer.
Application project leader.
Hardware, network, and third-party software administrator.
After the implementation, the consultants typically have fewer responsibilities. Therefore, customers must receive adequate training for the roles that they fill.
The CNC consultant and CNC administrator install JD Edwards EnterpriseOne and set up environments, users, security, and distributed processing. They also are responsible for setting up version control and testing various CNC configurations. The CNC consultant and CNC administrator control the deployment of JD Edwards EnterpriseOne software throughout the company.
Custom solution consultants resolve business issues by developing applications. Their primary responsibilities include designing the modifications with upgrades in mind and developing, testing, and introducing the configured software. While the CNC administrator performs the version control functions that build and deploy software, the customer solution consultant must help develop the internal procedures that document the application development cycle for your business.
After JD Edwards EnterpriseOne software is installed, configured, and deployed, the application consultants continue in their role as product experts, where they might be called on to troubleshoot problems that arise. Although application consultants do not implement the CNC configurations, they must understand how JD Edwards EnterpriseOne handles distributed processing, environments, and so on, because these application issues influence the CNC decisions.
Implementing JD Edwards EnterpriseOne includes many tasks that are outside the scope of Oracle services. Third-party consultants provide these services. They might also work as CNC consultants, network architects, custom modification consultants, and so on.
The purpose of a package is to group software modifications so that they can be deployed to enterprise servers, web servers, and workstations. A package defines and contains the components to deploy. A package can contain everything that is needed to run the software (as in an initial installation for a new workstation), or only updates or changes to existing applications.
As applications, business functions, and other objects change, you need to make those changes available to users within your enterprise. You might also need to set up a new workstation with JD Edwards EnterpriseOne software.
Packages enable you to deploy software changes and new applications to your users, or to install the software on a workstation for the first time. After you have defined and built a package, you can deploy it using Oracle's JD Edwards EnterpriseOne Client Workstation Installation application or Deployment Director application (P9631).
You might need to update or set up a workstation or an enterprise, logic, or application server with JD Edwards EnterpriseOne software for a variety of reasons, such as:
You want to set up a workstation for a new user or role.
You need to deploy custom solutions to all users or only to selected users.
You have created a new path code for development purposes, and you need to deploy it.
You need to rapidly deploy a software fix to a selected group of affected users.
Disk space is getting low on some of the workstations, and you need to create a minimum configuration.
You need to update the servers with custom modifications that you have developed using the toolset.
JD Edwards EnterpriseOne provides solutions to meet all of these needs. First, the system enables you to create a package that defines and contains the location of the components that need to be distributed. To deploy these components, you must define and build a package.
You can build these types of packages:
Full client
Full server
Update client
Update server
Full packages are static, point-in-time snapshots of the central objects for the path code on which the package is based. A full package contains everything that developers need to run in order to develop in JD Edwards EnterpriseOne software. Specifically, a full package includes a full set of specifications (specs), a full set of business function dlls, source files, object files, header files, bitmaps, an INF file that defines where the foundation, data, and features are located, as well as other information about the package. The package specs are stored in an Oracle Enterprise Edition (OEE) repository and the specification data is in a platform-independent XML format. Use this package type when you want to create a full workstation configuration.
In a full package, every application for which users are licensed is available to them. Because specs reside on the workstation, information is processed locally, which eliminates network traffic. When you deploy a full package, a few specs and tables might be installed just-in-time, but the impact on network performance is insignificant.
Full packages are primarily for initial installations and are normally deployed using the JD Edwards EnterpriseOne Client Workstation Installation application. You can also use Oracle's JD Edwards EnterpriseOne Deployment Director application to install a full package on a computer on which JD Edwards EnterpriseOne is already installed.
Full server packages are the same as client packages except that:
The server package does not include client-specific business functions.
The server package does not include features or local data.
During the server package build process, the spec repository is built under the database data source, Central Objects - <pathcode>.
This repository can be shared by several enterprise and web servers. The specs are built in a platform-independent XML format. The spec repository is portable across dissimilar servers.
The update package enables you to update, add to, or refresh the existing full package with changed objects. You can deploy an update package only to a workstation that already has JD Edwards EnterpriseOne installed on it. The objects in the update package replace those objects on the workstation. All other objects on the workstation are left unchanged. The advantage of this type of package is that you can quickly deploy software changes or enhancements.
Unless a package includes applications that do not have specs, the update package is a point-in-time copy of the central objects for a particular path code. The specs for the update package are built in XML/TAM format, not XML/RDBMS format.
When a user signs into JD Edwards EnterpriseOne after receiving one or more update packages, a form that lists the available update packages appears. If the user decides to take one or more of these packages, the system loads the user's workstation with all objects in the package. The objects in an update package replace those same objects on the workstation. All other objects on the workstation remain the same.
Like full packages, update packages can include development objects such as business function source files, object specs, and header files. Update package recipients can load the development objects at deployment time.
All update packages require a full package on which the update package is based. This full package is called the parent package. By default, the parent package is updated by the update package. When this occurs, all objects in the update package are merged into the parent package.
Note:
The jde.ini file on the client includes a setting called UpdateParentPackage that determines whether the parent is updated. If this setting is not present or set to Y, the parent package is updated by the update package. If this setting is N, the parent is not updated.Note:
Specs are always in XML format. However, they are stored in a TAM file for update packages and in an RDBMS for a full package. Hence, full package specs are in XML/RDBMS format and update package specs are in XML/TAM format.Business function objects in the update package are linked to the corresponding objects in the parent package, and new DLLs are created. Similarly, specs from the update package are merged into the specs in the parent package.
The parent package concept applies to both workstations and servers. Parent packages for workstations reside on the deployment server, while server parent packages are kept in the build area for the enterprise server.
Update server packages are the same as update client packages, with these exceptions:
Update server packages include only the objects that were described previously for full server packages.
When you are building an update server package, enterprise servers are automatically selected based on the parent package. Update packages can be deployed only to the enterprise and web servers that have the parent package deployed.
Update packages must be parented to live full packages for them to be deployed.
Specs are built in the database data source, Central Objects - <pathcode>.
When developers install a full package, they must select the option to install development objects. When they install the development objects with a full package, these objects will be automatically updated when developers later install an update package. Developers receive source code, header files, libraries, and DLLs.
Managing modifications requires a practical version control plan for tracking changed objects. You can avoid many software problems by tracking changed objects.
To more easily plan and track development and to simplify version control, you should build and deploy packages only as often as necessary. If you perform many development changes, you should build and deploy packages on a set schedule to ensure that everyone involved knows when objects are due to be completed and when you are going to build and deploy the package.
Implementing version control might require a staff of information technology professionals. For example, a company has several hundred developers and a complex CNC configuration. To manage version control for multiple developers, the product version control group consists of:
One manager to oversee coordination within the department.
One supervisor to coordinate the package builds, coordinate object transfers, and troubleshoot problems.
Two server specialists to build server packages.
Four technical specialists to build workstation packages, perform object transfers, and run automated testing before releasing the package to Quality Assurance.
One night operator to build workstation packages, build server packages, and clear build errors.
If you are not planning any development projects, you need only three path codes (sets of central objects): PY900, PD900, and PS900. If you plan to modify the software extensively, you also should create a development path code (DV900).
Because each path code requires version control maintenance, you should create only the path codes that you really need. Even when you make extensive software modifications, you should have only these four path codes:
The path code that you use for routine development. After successfully testing the objects that you develop, transfer them to the PY900 path code using the Object Transfer application, and distribute them to the users using the package build and deployment process.
A path code that contains a practice set of objects that you test during the conference room pilot before you transfer objects to production. Use this path code to deploy quick corrections or make minor modifications to objects that you will transfer to production. You also can use this path code to test modifications that were made in the development path code before you transfer the objects to the production path code.
The production path code from which just-in-time installations and production server objects are deployed. After you test software changes in PY900, transfer them to PD900, and then deploy the changes to the enterprise servers and workstations.
The set of pristine objects that is included with the software. You should not make changes to this path code other than to apply documented Oracle changes. Use this path code to compare standard software to any custom software that you have implemented in other path codes. You should keep a copy of this path code so that you have an unchanged copy of JD Edwards EnterpriseOne in case you need to undo any of the changes.
All path codes share the same Object Librarian tables, the same system data source, and usually, the same data dictionary. The only tables that are distinct for each path code are the central objects and specifications tables (tables that begin with F987), the F983051 table, the F98306 table, and the F98950 table.
You should maintain two versions of each package, an A and a B version, so that you can alternate between these versions when you build packages. The advantage of this approach is that users always have a package available to them, even when you are building the latest version of that package. For example, package PRODB would be available to users while you are building PRODA. Then, after you release PRODA, you would build the next package into PRODB, and so on. This setup gives you two full packages (A and B) for production, as illustrated in this table:
| Package Name | Description |
|---|---|
| PD900FA | Standard Production Full A |
| PD900FB | Standard Production Full B |
Update packages might be named with the path code followed by "UA" or "UB" as shown:
| Update Package Name | Description |
|---|---|
| PD900UA | Production Update Package 1 |
| PD900UB | Production Update Package 2 |
| PD900UA | Production Update Package 3 |
| PD900UB | Production Update Package 4 |
A deployed server package cannot be revised, rebuilt, or deleted. It must be replaced with another package first. For this reason, you must have at least two server packages available so that you can alternate between them.
Note:
The maximum length for a package name is eight characters.As soon as you transfer objects into the PD900 path code, end users can access the changes. Therefore, you should test the modified objects before you transfer them to the production path code.
After you transfer objects to the production path code, they are immediately deployed to end users under these circumstances:
When a user is set up for just-in-time installation (JITI), the system automatically deploys the object to the user's workstation the first time that the user attempts to access the object.
See Deployment Methods.
When you build an update package that includes a business function build for that package, the system builds the business function and then globally links it with all other business functions in the parent package.
Do not transfer business functions into the production path code until you are ready to deploy because during a package build, a global build of business functions automatically includes the new business functions. When you transfer changes into the production path code, they will not be available to users until you build a full or update package.
These lists provide an overview of how you should perform the normal development cycle.
In the DV900 path code, complete these tasks:
Make modifications.
Test the modifications.
Transfer the objects to PY900.
In the PY900 path code, complete these tasks:
Build the package.
Deploy server objects to the PY900 path code on the enterprise server, and then test the objects.
Test the modifications.
Schedule the package.
Transfer the objects to PD900.
In the PD900 path code, complete these tasks:
Build the package.
Schedule the package.
Deploy the server objects to the PD900 path code on the enterprise server, and then test the objects.
The following steps are a typical process for modifying objects and deploying them through successive path codes and into the production environment.
Check out the objects from the DV900 path code, modify them, test them, and check them back in.
Use an incident-tracking system or any numbering system to track changes.
Always use an incident number when you check in the objects.
If the objects need to reside on the logic server, transfer them to the DV900 path code on that server.
Test the objects by comparing them to the objects on the server.
Use an incident number with Object Transfer to transfer the objects to the PY900 path code.
Use the checkout log to confirm the transfer (optional). The objects are not in production, but they are now available for you to build a test package in the PY900 path code.
Build a full or update package.
Test the newly built, unreleased package in the PY900 path code.
You test the package only by comparing it to workstation processes, not to server processes. Although the name of this package will probably be PY900U1 (update package number 1 for the PY path code), it is a test package because you have not released it to the users.
Schedule the update package to deploy to a test machine and test it in an environment that contains PY objects with PY data.
Deploy server objects to the PY900 path code on the enterprise server and test them.
If you prefer, you can build the server package and schedule the deployment at the same time that you build and schedule the workstation package. Building these packages simultaneously can save you time, although this method puts a greater load on the server.
Schedule the new package to deploy to PY users.
Use an incident number with Object Transfer to transfer the object to the PD900 path code.
Use the checkout log to confirm the transfer (optional). The objects are now in the production environment and are available for you to build a package in the PD900 path code.
Build a full or update package for client workstations.
Perform a server package build.
You can transfer the server package now or wait until it has been tested on a workstation.
Schedule the new package to deploy to end-user workstations.
Deploy the server objects to the PD900 path code on the enterprise server and test them.
If you prefer, you can build the server package and schedule the deployment at the same time that you build and schedule the workstation package.
Sometimes you need to make a simple change to an application that is undergoing major enhancement work in the DV900 path code. When an object has been modified in the DV900 path code, you might get unexpected results if you make a simple change and quickly deploy it. Therefore, you should make the change in both the PY900 and the DV900 path codes, and deploy the change using the PY900 path code. This method enables you to deploy the change quickly to users without interfering with the major enhancement work in the DV900 path code.
After you have made software changes, the method that you use to deploy those changes to the workstations on the enterprise depends on factors such as the type of package that you typically build and the needs of the users.
JD Edwards EnterpriseOne offers several deployment applications, each with its own specific purpose and advantages. The method that you select depends mainly on the type of package that you want to deploy.
This section discusses:
Package deployment.
Multitier deployment.
Cumulative and noncumulative update packages.
Comparing deployment methods.
Deploying various types of modifications.
Just-In-Time Installation.
Recommendations for sites using full packages with JITI.
Disabling just-in-time installation.
The JD Edwards EnterpriseOne Deployment Director application enables an administrator to deploy a built package to users, groups, locations, or enterprise servers. For WIN32 clients, the administrator can specify the date and time when the package is made available and whether the package is mandatory or optional.
Users who receive a mandatory package will not be able to access JD Edwards EnterpriseOne until they install the package. Users who receive an optional package can install the package or decline it.
No option is available to schedule a server package for future deployment. The package is immediately deployed.
Multitier deployment enables workstations to install software from more than one deployment location and more than one deployment server. You should consider multitier deployment if your site has more than 50 workstations performing software installations per day, or if you are deploying JD Edwards EnterpriseOne software across a WAN connection.
When you use a cumulative update strategy for deploying packages, you have one package that you add to, rebuild, and re-release to users. You do not create a new package each time you have a modification that you want to deploy. To use a cumulative package, follow these steps:
Change the package assembly status to Inactive.
Go to the Package Revisions form.
Add the changed or new objects to the package.
Rebuild the package.
Redeploy the package.
When you use a noncumulative update strategy, you create and deploy a different package each time you add or change an object. For example, if you deploy one modification a week for 10 weeks, you would have 10 different packages, each containing only the software change for that week.
Each deployment method has strengths and limitations. To help you decide which method is right for your needs, here are important points about the different methods:
A new user loading a new machine should use the Install Manager to load a full package, plus any update packages that you have instructed users to load since the last package build.
Therefore, you need a manual tracking system to track which update packages must be applied after installing a particular package.
All update packages must use the JD Edwards EnterpriseOne Deployment Director application to be scheduled to workstations.
Full packages can also use JD Edwards EnterpriseOne Deployment Director if JD Edwards EnterpriseOne is already loaded on a machine.
Use Oracle's JD Edwards EnterpriseOne Silent Installation application to submit a workstation installation request through command line arguments.
Do not use this application for an initial installation.
Use Oracle's JD Edwards EnterpriseOne Multitier Deployment process to install from more than one deployment location.
You should consider this method if you have more than 50 workstations performing software installations per day or if you have users on a WAN.
Use the JD Edwards EnterpriseOne Deployment Director application when you need to push objects in a server package to enterprise servers.
An understanding of which types of objects, and therefore modifications, can be deployed through each package type will help you select the appropriate package for the changes that you deploy.
This table shows which types of changes are installed with a full package, an update package with specs, and an update package with no specs.
| Modification | Full Package | Update Package with Specs, Business Functions, and Named Event Rules (NERs) | Update Package with Business Functions and NERs but no Specs |
|---|---|---|---|
| Applications | |||
| Imbedded event rules | X | X | |
| Vocabulary overrides (FDA text) | X | X | |
| Data structure | X | X | |
| Processing options (report) | X | X | |
| Business Functions | |||
| C Language source/include/object (if a compiler exists) | X | X | X |
| Consolidated business function DLLs | X | X | X |
| Data structure | X | X | |
| Table event rules | X | X | X |
| Named event rules | X | X | X |
| Batch Applications | |||
| Report | X | X | |
| Imbedded event rules in a report | X | X | |
| Report data structure | X | X | |
| Report vocabulary overrides | X | X | |
| Report processing options | X | X | |
| Versions and processing option values (depends on processing options) | X | X | |
| Imbedded event rules in versions | X | X | |
| Processing option templates | X | X | |
| Business Views | |||
| Added or changed fields | X | X | |
| Tables | |||
| Structure (specifications) | X | X | |
| Indexes | X | X | |
| Joins | X | X | |
| Generic text data structure | X | X | |
| Data dictionary items | |||
| Foundation code (required for full packages, optional for update packages) | X | X | X |
| Foreign languages | X | X | |
| Non-Oracle objects (custom items must be defined in the JD Edwards EnterpriseOne Central Objects database, and can be deployed through any package type) | X | X | |
| Replicated local data (required for full packages, optional for update packages) | X | X | X |
| New icons | X | X |
For an update package with JITI, these changes are installed:
Applications.
Imbedded ER.
Vocabulary overrides (FDA text).
Data structure.
Processing options (report).
Batch applications.
Report.
Imbedded ER in a report.
Report data structure.
Report vocabulary overrides.
Report processing options.
Versions and processing option values (depends on processing options).
Imbedded ER in versions.
Business Views.
Added or changed fields.
Miscellaneous.
Foundation code (required for full packages, optional for update packages).
Foreign languages.
Non-Oracle objects (custom items can be deployed through any package type).
Replicated local data (required for full packages, optional for update packages).
This is an overview of the steps for creating and deploying a package:
Assemble the package.
During this step, you specify the type of package that you are building and provide a name, path code, and package description. Next, you assemble the package by specifying the objects, data, foundation, features, and so on that you want to include in the package. If you are building an update package, you can specify individual objects to include.
To simplify the process of assembling a package, Oracle's JD Edwards EnterpriseOne Package Assembly application (P9601) includes the Package Assembly Director, which displays a series of forms that guide you through the steps of naming the package and adding the objects that you want to include in the package.
Define the package build.
After you assemble the package, you must define the build before you can deploy the package to the workstations and servers. In this step, you specify:
Build options.
Build specification options.
Business functions build options.
Compression options.
Build features options.
You also need to specify whether the package is for a workstation, a server, or both. If the package is for servers, you must specify the servers for which the package should be built and select the spec database data source.
To simplify the build process, Oracle's JD Edwards EnterpriseOne Package Build Director application (P9621) includes the Package Build Definition Director, which displays a series of forms that guide you through the steps of specifying where to build the package, whether to include specifications, whether to compress or build business functions, and so on.
Build the package.
During the actual build process, the system takes the information that you provided when you assembled and defined the package and copies and converts central objects to the package. It also globally builds the business functions that are included in the package and then compresses the package.
Schedule the package for deployment.
After you have defined and built the package, it is ready for distribution. Depending on the package type, you can deploy packages through JD Edwards EnterpriseOne Client Workstation Installation application or Deployment Director application.
JD Edwards EnterpriseOne Deployment Director enables you to specify the workstations and servers that receive the package, as well as when the package is made available. Packages can be deployed to all computers within the enterprise, a select group of computers, or individual computers.
When you schedule the package, you can indicate whether package installation is mandatory or optional.
Deploy the package to deployment, enterprise, and web servers.
Use the JD Edwards EnterpriseOne Deployment Director application to move any changed objects to the enterprise server.
If you specify a server during the package build definition process, the system automatically creates a corresponding server package in the correct format. If you do not specify a server and define only a workstation package, you should create a corresponding server package. The process is nearly identical to creating a workstation package.
Web servers automatically retrieve the package information from their configured business function logic servers.