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 workstations, web servers, and enterprise servers. 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 the workstations. To deploy these components, you must define and build a package.
You can build these types of packages:
Full client
Full server
Full mobile
Update client
Update server
Update mobile
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) or SQL Server Express (SSE) 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.
During the package build process, you can select to build only the runtime system code on a server package.
The administrator cannot select a different system code.
The server package does not include features or local data.
During the package build process, you can specify the database data source in which to build the spec repository.
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.
Full mobile packages are similar to full packages but contain only a subset of the specs that are delivered with a full package. A mobile package includes all business functions, tables, table event rules (ERs), client-only named ERs, mobile applications, and mobile batch applications (UBEs). The system administrator must flag all required mobile applications and UBEs as mobile within Oracle's JD Edwards EnterpriseOne Object Management Workbench.
A full mobile package can be built only if the JD Edwards EnterpriseOne client has at least one environment marked as mobile in the path code for which the package is being built. During the package build, MSDE databases are built as a mirror image of the mobile environment's tables based on the mobile environment's Object Configuration Manager (OCM). The MSDE databases are then deployed to a JD Edwards EnterpriseOne mobile workstation on a Microsoft WIN32 client. Only one mobile environment can exist per path code.
When full mobile packages are deployed to workstations, the OCM is changed to point locally to the deployed MSDE database. Users can then access JD Edwards EnterpriseOne mobile applications and perform tasks while disconnected from the network. The data within the local MSDE repository is synchronized with the corporate RDBMS database when the user connects to the network and initiates a synchronization.
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. If the update package contains an application without specs, the system copies the required specs directly from the central objects data source at runtime.
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.
Because of the way that just-in-time installation works, performance across a wide area network (WAN) might be slow if the update package contains only applications without specs. To improve performance on the WAN, include specs for each application in the package.
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 only on the deployment server.
They are merged directly into the spec repository at deployment time only.
Specs are built in XML/TAM format and not in XML/RDBMS format.
An update mobile package is an update package that is used to update mobile clients. An update mobile package is automatically built when the parent package is a marked as mobile.
Package build parses the list of objects in an update package and creates a separate set of specs for those objects that are marked as mobile, so a deployed mobile update package contains everything an update client package does except it has a smaller set of specs.
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:
| Path Code | Description |
|---|---|
| DV900 | 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. |
| PY900 | 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. |
| PD900 | 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. |
| PS900 | 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 in the following way:
| 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.
Note:
JITI affects users who received an update package containing an application without specs.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.
To ensure that the modifications that you transfer to the production path code are not immediately available to end users, avoid using update packages that contain applications with no specs. Also, 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 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.
Test the modifications.
Deploy server objects to the CRP path code on the enterprise server, and then test the objects.
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 CRP 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 CRP objects with CRP 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 CRP 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.
Note:
If just-in-time installation is enabled, users can access the objects immediately.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 unless you are using the Push Installation feature.
Full packages can also use JD Edwards EnterpriseOne Deployment Director if JD Edwards EnterpriseOne is already loaded on a machine.
You can use Oracle's JD Edwards EnterpriseOne Push Installation feature to deploy to a machine that does not have JD Edwards EnterpriseOne installed.
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).
Just-in-Time Installation (JITI) occurs when the system retrieves an application at runtime and loads it on the workstation the first time that you select that application from the menu. Loading happens only once; the next time that you select the same application, it is still loaded on the workstation. JITI applies only to applications. Business functions cannot be installed through JITI.
JITI works when the workstation receives an update package that does not contain specs. Update packages that contain specs do not require the JITI process.
When you receive an update package that contains a changed application without the new specs, the system first determines whether specs for the application reside on the workstation. If so, it deletes from the workstation old versions of that application. Then, the next time that you select that application from the menu, the system loads the new version of that application.
JITI can be used in remote locations that are using multitier deployment to install packages. However, you might find that performance time for the JITI is unacceptable. In this case, you can initially install full packages and use update packages to deploy software changes.
When a package includes applications without specifications, at the time of execution only these related objects are deployed:
Interactive or batch application specifications.
Embedded event rules for the application.
Processing option templates, data structures, and related business views.
The listed objects are not deployed and, therefore, must be included in the package if they have been modified:
Business functions and their data structures.
Generic text data structures.
Table event rules, which are included with tables.
Named event rules.
New icons.
For sites that use full packages with JITI, you should adopt a cumulative update package strategy. Each week that you need to deploy a change, add that object to the existing update package, and then rebuild and schedule the package.
The advantage of this strategy is that you do not need to rebuild the full package each week. By using this strategy to deploy packages to a new workstation (or to completely refresh any workstation), you must install the full package and then install one cumulative update package.
The disadvantage of this strategy is that the update package might become so large that the deployment time increases. You must determine when to rebuild the full package for new workstations and enable existing users to install the new update package.
Select one of these methods to disable JITI:
Use Oracle's JD Edwards EnterpriseOne Work with Environments application (P0094) to disable JITI for the environment.
When JITI is disabled, users who sign on to that environment can access only those applications for which they have specifications. You should use this method during the cumulative installation process when you update the production central objects with new changes.
Use application security to disable JITI for a particular application, for an end user, or for a role profile.
When a user accesses an application for which the specifications do not reside on the user's workstation, the system first reviews P0094 to determine whether JITI is disabled for the entire environment. If JITI is on for the environment, the system determines whether application security prevents the user from using JITI. Application security has a field called not allowed to install.
Although you can disable JITI for an environment, the system still uses JITI to copy data dictionary items to the global tables and data dictionary tables. The structure of the data dictionary prevents you from disabling JITI for it.
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. You can schedule a package to be pushed from the deployment server to workstations. Push installation requires no interaction with the workstation users.
When you schedule the package, you can indicate whether package installation is mandatory or optional. At this same time, you can specify whether you want the package to be deployed using push installation, which requires no interaction with the package recipient.
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.