10 Setting Up Multitier Deployment

This chapter contains the following topics:

• Understanding Multitier Deployment

• Defining Deployment Servers

• Distributing Software to Deployment Locations

• Deploying Server Packages in a Multitier Network

Understanding Multitier Deployment

This section discusses:

• Overview of multitier deployment.

• Multitier deployment terminology.

• Multitier deployment features.

• Multitier implementation.

• Multitier deployment case study.

Overview of Multitier Deployment

JD Edwards EnterpriseOne software is normally distributed to workstations from a centralized location. In many cases, you can minimize the affect on the performance of a single deployment server by using systematic scheduling for software installations. For example, if your site has more than 50 workstations that require a package installation but you release software only four times a year, you can mitigate performance problems by scheduling the installations over a weekend, at night, or during off-peak hours.

While this distribution method is the simplest approach for software deployment, network capacity constrains configurations that have either multiple remote sites or large numbers of users at a single site. For example, software installations to workstations that are connected to the centralized deployment location by a 56 KB circuit can take 4 to 6 hours to run.

Multitier deployment provides sites the flexibility of installing packages on workstations and servers from more than one deployment location and more than one deployment server. These additional deployment locations and servers are called deployment tiers. Specifically, instead of installing multiple workstations across a wide area network (WAN) circuit, multitier deployment enables you to transfer a compressed package from the centralized location to the remote workgroup server, which acts as a second deployment tier. Multitier deployment means deploying from more than one deployment tier.

For example, you might have one deployment server at the main location and a second deployment server for a remote location. Because the server at the remote location is responsible for deploying to workstations and servers at that location, you do not need to deploy packages from the main deployment server across a WAN, as you would in a single-tier deployment configuration.

Workgroup servers can also be used as second-tier deployment locations in a local area network (LAN) environment, where large numbers of workstations need to install software concurrently. It is recommended that you implement multitier deployment if your site has more than 50 workstations receiving multiple installations per day.

The primary function of multitier deployment is to reduce network traffic (and the delays that result from heavy traffic) by enabling enterprises with more than one geographic location to deploy from a secondary deployment server at the remote site. Instead of installing packages across the WAN from the deployment server to workstations at a remote location, you can copy the package and the package.inf file from the deployment server at the primary location to the deployment server at the remote location. The server at the remote location can then deploy the package to the workstations and servers at that location.

Consider implementing a multitier deployment configuration when either of these situations applies:

• Too many workstations are installing packages from the same location, causing server and network performance to suffer.

• Workstations are remotely connected to the deployment server over a WAN, which requires unacceptably long installation times.

Normally, you decide whether to implement multitier deployment during Configurable Network Computing (CNC) implementation. Although you can enable this function at any time, you typically set it up after you have installed the software and are preparing the production sites to go live.

To set up multitier deployment, you must define the machines (and their associated path codes) that are used for deployment. In addition, you can use a scheduler function to define when software should be pushed to the tiered deployment location.

You must also define individual user characteristics for multitier deployment. Normally, you do this by modifying the user profiles to indicate the deployment location from which a user pulls a package.

Multitier Deployment Terminology

This table lists and describes multitier deployment terms:

Term	Description
Primary Deployment Location (tier 1)	The primary or base deployment location is the location in which the package to be deployed to secondary or remote locations is built. The system requires at least one deployment server for installing and maintaining the software. The server at the primary deployment location should be dedicated solely to deploying and operating JD Edwards EnterpriseOne products, and should not be used for any other purposes in your company.
Tier Deployment Location (tier 2)	Tier deployment locations (also known as remote or secondary locations) have one or more deployment servers that enable you to install the software on the workstations at that location. These servers receive their packages from the deployment server at the primary or base location. Machines at the tier deployment locations cannot use Object Librarian functions such as object check-in and check-out. These machines are designed for deployment use only and are not designed to be used for remote development. The number of tiered locations that you can have depends on the network and server capacity.
Tier Workstations	Tier workstations are workstations that connect to a tier deployment location for software installation. The number of workstations per deployment location depends on the network and machine load. All tiered workstations must also have a Microsoft Windows domain connection that enables them to connect to, read, and copy files from the shared drives of their respective deployment locations.

See Also:

• JD Edwards EnterpriseOne Application Release 9.0 Installation Guide.

Multitier Deployment Features

Multitier deployment offers these features:

• You can deploy workstations from any number of deployment servers.

• You can easily add deployment locations, and the deployment machine does not need to be a server; it can be a Microsoft Windows workstation.

• Setup and administration are straightforward tasks.

• You maintain central control over files and data that are transferred to remote deployment locations.

• You can easily schedule software for deployment to remote sites.

• Multitier deployment is integrated into Oracle's JD Edwards EnterpriseOne Deployment Director, so the process for deploying is essentially the same as the process for deploying in a single-tiered setup.

Example: Two-Tier Deployment Strategy

This diagram illustrates a typical two-tier deployment strategy:

Figure 10-1 Example of a two-tier deployment strategy

Description of "Figure 10-1 Example of a two-tier deployment strategy"

Multitier Implementation

Packages are always built on the deployment server at the primary location. After you build the package that you want to deploy to remote locations, you must follow these steps to implement multitier deployment:

1. Define deployment locations.

   You must define each physical location to which you want to deploy. For example, if the main office is in Denver and you want to deploy to the branch office in Seattle, you must define the Seattle deployment location.

2. Create deployment server definitions.

   You must define the deployment server at each remote location.

   Note:

   This step is not necessary if you used Oracle's JD Edwards EnterpriseOne Remote Location Workbench to create deployment server definitions when you installed the software.

3. Schedule the package.

   Use the JD Edwards EnterpriseOne Deployment Director program (P9631) to schedule the package for deployment. The process of scheduling a package for multitier deployment is identical to the process for scheduling any other package.

4. Deploy the package to workstations.

   After you deploy the package to the deployment server at the remote location, that server can deploy to the workstations at that location.

Multitier Deployment Case Study

This case study is for a two-tier deployment environment. As this case study demonstrates, deploying packages to workstations using WAN connections is generally not efficient. Instead, you should deploy from a primary deployment server to tier deployment locations. After that, you can install packages to LAN-attached workstations from each local deployment location.

For package installations, a remote deployment location functions as a file server. You cannot build packages at a remote deployment location; packages must be built at the primary deployment location.

While locally attached workstations can pull packages from the tier deployment location, these workstations still require enterprise server and database server connectivity.

This diagram illustrates this case study:

Figure 10-2 Multitier Deployment Strategy

Description of "Figure 10-2 Multitier Deployment Strategy"

This table describes the assumptions used by the Tier 1 Denver location in this case study:

Characteristic	Setting
Characteristic	Setting
Enterprise server name	HOME1
Deployment server name	Denver: DENSVR1 Atlanta: ATLSVR1 Chicago: CHISVR1
Prototype workstations	Denver: 15 Atlanta: 0 Chicago: 15
Production workstations	Denver: 0 Atlanta: 15 Chicago: 15
JD Edwards EnterpriseOne release	E900
Deployment tier	Denver: 1 Atlanta: 2 Chicago: 2
Path codes	Denver: PD900, PY900 Atlanta: PD900 Chicago: PD900, PY900

Multitier Deployment Configuration Steps for the Case Study

These steps summarize the steps necessary to configure the system for multitier deployment:

1. Define the deployment locations.

   Define the deployment locations on the deployment server (DENSVR1 in this example). Use Oracle's JD Edwards EnterpriseOne Deployment Locations Application program (P9654A) to define all deployment locations.

   For this case study, complete these fields to define three locations, one for each deployment location in Denver, Atlanta, and Chicago:

   Field	Value
   Location	Enter the name of the deployment location. In this case study, you assign these names for each physical deployment location: Denver, Atlanta, and Chicago.
   Description	Enter a description (any value up to 30 characters) for each deployment location; for example: Denver: Denver - Tier 1 Atlanta: Atlanta - Tier 2 Chicago: Chicago - Tier 2
   Location Code	Enter the current location for deployment; for example, DEN.
   Parent Location	Enter the name of the parent location for the location that you are adding; for example, Corporate.

   
   

2. Create deployment server definitions.

   Use the JD Edwards EnterpriseOne Deployment Locations Application program (P9654A) to create a definition for each deployment server at the deployment locations that you created. For this case study, you need to define a deployment server for Atlanta and Chicago. The deployment server in Denver is already defined because it is the primary (tier 1) server.

   For this case study, complete the fields on the Deployment Server Revisions form as described in this table:

   Field	Value
   Machine Name	Enter the name of the physical machine. In this case study, enter these values: Denver: DENSVR1 Atlanta: ATLSVR1 Chicago: CHISVR1
   Description	Enter a description (any value up to 30 characters). For example, Multitier Deployment - Denver.
   Release	Enter the number of the release. For example, E900.
   Primary User	Enter the primary user for the machine that you entered.
   Server Share Path	Enter the name of the shared directory for the path code in which system files and other files reside. For example, \E900.

   
   

3. Schedule the package.

   Schedule the package to be deployed from the tier 1 deployment server to the tier 2 deployment servers through the JD Edwards EnterpriseOne Deployment Director program (P9631) or Multi Tier Deployment batch program (R98825C).

See Also:

• Defining Deployment Parameters.

Defining Deployment Servers

This section provides an overview of defining deployment servers, lists prerequisites, and discusses how to:

• Define a new deployment server.

• Revise an existing deployment server.

Understanding Defining Deployment Servers

The JD Edwards EnterpriseOne Deployment Locations Application program (P9654A) enables you to either add a new deployment server definition or modify an existing definition. When you add a new deployment server definition, the system creates a record in the F9654 table for each deployment location. Each server at each deployment location must be defined.

Typically, the table contains one record for the primary deployment server and one record per deployment location for each release. If you have multiple releases, you must create multiple records for the servers at each deployment location.

If you used Oracle's JD Edwards EnterpriseOne Remote Location Workbench to create deployment server definitions when you installed the software, you do not need to define deployment servers again.

In many situations, you might need to modify the definition for a deployment server that you already defined. For example, you would need to change the definition if the server share path or release changes, or if you want to designate a different server as the primary deployment server. The process for revising an existing deployment server definition is similar to the process for adding a new definition.

See Also:

• Working with Installation Workbench in the JD Edwards EnterpriseOne Application Release 9.0 Installation Guide.

Prerequisites

Before you complete the tasks in this section:

• Ensure that you understand the CNC concepts that enable you to define and implement packages, workstation installations, path codes, central objects, replicated objects, and user profiles.

• Ensure that adequate disk space exists on the disk drive for the machine that you will be using as a tier deployment location.

  Each full package that you deploy adds approximately 1.4 GB. The amount of required disk space varies, depending on the amount of data that you replicate to a Supported Local Database.

• If you are adding a new definition for a deployment server at a remote location, you first need to define that location.

  Note:

  It is recommended that you do not define deployment locations with a DEV path code. The DEV path code is normally associated with developers who are not located at remote locations.

  See Defining Locations.

Form Used to Define a Deployment Server

Form Name	FormID	Navigation	Usage
Deployment Server Revisions	W9654AC	Package and Deployment Tools (GH9083), Machine Identification Find the location where the deployment server resides and expand the tree, if necessary, to display the different machine types. Select the Deployment Server heading and then click Add, or find the existing deployment server you want to modify and click Select.	Define a new deployment server or revise an existing deployment server for multitier deployment.

Defining a New Deployment Server

Access the Deployment Server Revisions form.

1. Enter the name of the machine on the network in the Machine Name field.

   Because you are entering a definition for a server other than the primary deployment server, the Primary Deployment Server field is not available. You can enter this field only if you first delete the definition for the current primary deployment server.

2. Enter the release number as defined in the release master in the Release field.

3. Enter the primary user for the listed machine in the Primary User field.

4. Enter the shared directory for the path code in the Server Share Path field.

   The objects that are stored on a file server will be found in this path.

5. Select Path Code from the Form menu.

6. On the Machine Path Code Revisions form, enter the path code for the primary or base location from which the secondary location will receive the package.

   When you enter the path code, the server share path will use the base server share path as the default for that machine.

   Note:

   You must specify the path code for each deployment server at all secondary locations. If you do not indicate the path code, multitier deployment may not work.

7. If the package includes a user-defined foundation or data, specify those items by selecting Foundation or Data from the Form menu.

8. On the Deployment Server Revisions form, click OK.

Revising an Existing Deployment Server

Access the Deployment Server Revisions form.

1. Modify any of these fields:

   • Description

   • Release

   • Primary User

   • Server Share Path

   • Primary Deployment Server

     If you are modifying the primary deployment server, you can also change the primary deployment server. For any other server, you cannot change the value in this field. Enter 1 to indicate that the deployment server is the primary deployment server. You can have only one primary deployment server.

2. Select Path Code from the Form menu.

3. On the Machine Path Code Revisions form, enter the path code for the primary or base location from which the secondary location receives the package.

   When you enter the path code, the system displays the default server share path, which is the base server share path for that machine.

   Note:

   You must specify the path code for each deployment server at all secondary locations. If you do not indicate the path code, multitier deployment might not work.

4. If the package includes a user-defined foundation or data, specify those items by selecting Foundation or Data from the Form menu.

5. On the Deployment Server Revisions form, click OK.

See Also:

• Defining Deployment Parameters.

Distributing Software to Deployment Locations

This section provides an overview of the multitier software distribution process and discusses how to:

• Distribute software through package deployment.

• Schedule packages for multitier deployment.

• Distribute software through the multitier deployment batch process.

• Copy workstation installation programs to deployment locations.

Understanding the Multitier Software Distribution Process

You use the JD Edwards EnterpriseOne Deployment Director program (P9631) or Multi Tier Deployment batch program (R98825C) to distribute software to deployment locations and schedule them for deployment. Use the JD Edwards EnterpriseOne Deployment Director program to define the scheduling parameters or to deploy the package immediately. Otherwise, use a version of Oracle's JD Edwards EnterpriseOne Multi Tier Deployment batch application to distribute the software to deployment locations.

Whether you push or pull the software depends on the machine on which you run the deployment function or batch program for the scheduling program. You push the software if you run the program or report on the primary deployment server or from a workstation. Conversely, you pull the software if you run the program from a workstation at the tier deployment location. In either case, execute the application on the primary deployment server machine for push installation or the destination deployment location for pull installation.

Important:

If you push the software, you must have full read and write privileges for both deployment servers (that is, the primary deployment server and the tier deployment location or destination machine), even if you do not run the batch application. If you do not have read and write authority on both servers, the deployment will fail.

After the package software is distributed through the JD Edwards EnterpriseOne Deployment Director program or Multi Tier Deployment batch program, you must manually copy the workstation installation programs from the primary deployment server to the tier deployment location. These programs are located in the client portion of the base installation directory.

Form Used to Distribute Software to Deployment Locations

Form Name	FormID	Navigation	Usage
Work with Package Deployment	W9631J	System Administration Tools, Package and Deployment Tools, Package Deployment	Distribute software that was previously defined and scheduled through the Deployment Director program (P9631).

Distributing Software Through Package Deployment

Use this method when you want to distribute software immediately after you define a deployment schedule. If you select this option, the software is distributed immediately, regardless of the timing parameters that you specify in the scheduling fields.

Access the Work with Package Deployment form.

1. Select the Machines option, and then click Find.

2. Select the deployment server to which you want to deploy.

   If you have scheduled to deploy packages to more than one deployment server, you can select the Deployment Server folder to deploy to all applicable servers rather than deploying to each individual server.

3. Select the deployment server name to deploy all packages that are listed under the server name.

   Alternatively, select only the package that you want to deploy.

4. From the Row menu, select Deploy.

   This option launches Oracle's JD Edwards EnterpriseOne Multi Tier Deployment batch program (R98825C), which enables you to deploy to deployment servers.

   You can also use this option to launch a batch application that deploys enterprise server packages. Therefore, if you select an enterprise server name or the Enterprise Server folder on the Work With Package Deployment form, Oracle's JD Edwards EnterpriseOne Enterprise Server Deployment batch program (R98825D)—not the Multi Tier Deployment batch program—launches. When you select a workstation, the Deploy option is not available.

Scheduling Packages for Multitier Deployment

After you create the server package that you want to deploy using multitier deployment, you can use the JD Edwards EnterpriseOne Deployment Director program (P9631) to schedule that package to a server at the same location or a remote location. Verify that the server package is compressed because, unlike client packages, you cannot deploy the server package using multitier deployment unless it is compressed.

Also, before you can deploy a server package with server multitier deployment, the package status must be either 50 (Build Completed Successfully) or 70 (Build Completed with Errors). If the package does not have a status of 50 or 70, it will be unavailable when you schedule the deployment.

See Scheduling a Package for Deployment.

Note:

When you create a distribution schedule, remember that you cannot schedule multiple packages to deploy at the same time.

Distributing Software Through the Multitier Deployment Batch Process

Access the Work with Batch Versions - Available Versions form.

1. Enter R98825C in the Batch Application field and click Find.

2. Select the Multi Tier Deployment version that you want to use.

3. On Version Prompting, click Submit.

4. On Report Output Destination, select one of these options and click OK:

   • On Screen

   • Printer

Copying Workstation Installation Programs to Deployment Locations

These steps ensure that the system runs the JD Edwards EnterpriseOne Client Workstation Installation program locally at the deployment location. If you do not complete these steps, the system searches the base location for the JD Edwards EnterpriseOne Client Workstation Installation program and its associated files, and copies the files across the WAN to the deployment location.

1. Connect to each deployment location and use Microsoft Windows Explorer to drag this client directory to the tier 2 workstation:

   \\Tier1DeploymentServerName\E900\OneWorld Client Install 
   

2. Open the package.inf file and locate the [FileLocations] section.

   Change the PackageInfs line to reflect the machine name of the deployment server and the environment at the deployment location; for example:

   PackageInfs=\\machine name\environment\ENVIRON\Evapps\appl_pgf\package_inf
   

3. Save your changes by selecting Save from the File menu.

4. Select Exit from the File menu.

In the case of multitier deployment, the client installation program resides on the tier deployment location in the client subdirectory that is subordinate to the base installation directory. The workstation that is attached to the deployment location must have read access to this directory on the deployment location to install the workstation package.

See Also:

• Installing the Workstations for Developers and System Administrators in the JD Edwards EnterpriseOne Application Release 9.0 Installation Guide.

Deploying Server Packages in a Multitier Network

This section provides an overview of multitier deployment of server packages and discusses how to schedule a server package for multitier deployment.

Understanding Multitier Deployment of Server Packages

Server multitier deployment lets you automatically deploy a server package from one deployment server to another. The target deployment server to which you are deploying the package can be either in the same location as the source deployment server that sends the package or in one or more remote locations.

You typically build packages on the primary deployment server at the base location, but using a different server for installations from the base location might have advantages. In some situations, you might prefer to deploy a server package to a server at a remote location rather than require remote users to access the server package over a WAN.

Server package multitier deployment enables users to select which package builds they want to deploy. For example, if you are building a Prod package for multiple server platforms, you can select the build for the platform that has been successfully built. The benefit of having the ability to select builds is that users are no longer required to wait to install a new client package.

You use the JD Edwards EnterpriseOne Deployment Director program (P98631) for server multitier deployment. When you deploy a server package, the system copies these components:

• Foundation and data.

• Subdirectories of the package name directory:

  • bin32

  • include

  • lib32

  • obj

  • source

  • spec

• Subdirectories of the server build directories:

  • bin32

  • spec

  • obj

  • lib32

• ServerPackage.inf file in the server build directories:

  • The package.inf file.

  • The pack directory that is subordinate to the package name directory.

When server-only builds are deployed without client builds, only the pack subdirectory is copied.

This table describes where major package components are copied from and to during the deployment process; the server share path is derived from the F9651 table:

Package Component	Copied From	Copied To
Package	The path indicated in the SrcDirs section of the package.inf file.	<server share path>\<path code>\<package name> on the destination deployment server.
Foundation and data	The path indicated in the SrcDirs section of the package.inf file.	<server share path>\systemcomp on the destination deployment server if the default location is selected.
Package.inf file	The path indicated in the F00942 table if the source deployment server is the primary deployment server in the base location. Otherwise, the path to the package.inf file in the F9651 table.	<server share path>\package_inf on the destination deployment server.

Smart Deployment

Server multitier deployment incorporates the smart deployment feature, which makes available only the server packages that match the available servers for the package destination. For example, if server packages exist at the base location for the HP9000 and the iSeries but the destination location has only an HP9000, only the HP9000 package is made available for deployment to that location. You cannot deploy a server package unless the package destination supports that server platform.

Even if you have multiple locations, smart deployment ensures that only the server packages that match the destination platform are available.

Automatic Package.inf File Updating

When you deploy a server package to a remote location, these sections of the package.inf file are updated:

• SrcDirs

• Attributes

• DeploymentServerName

• Location

The package.inf file is not copied when you deploy to a deployment server in the base location.

Prerequisite

Assemble and build the server package.

Form Used to Schedule a Server Package for Multitier Deployment

Form Name	FormID	Navigation	Usage
Package Deployment Targets	W9631B	Package and Deployment Tools (GH9083), Package Deployment Click Add to launch the Deployment Director, and then click Next.	Select a package to deploy.

Scheduling a Server Package for Multitier Deployment

Access the Package Deployment Targets form.

1. Select the Deployment Server option.

2. On the Package Deployment Attributes form, enter the deployment date and time, and select deployment options.

3. On the Deployment Server Selection form, enter the machine name to which you want to deploy the server package.

   Select the machine by double-clicking the row header.

4. On the Build Selection form, select the build (or version) of the package that you want to deploy by double-clicking the row header.

   Because of the Smart Deployment feature, the system enables you to select only the package builds that match the configuration at the destination location. For example, if package builds exist for an iSeries and an HP 9000 but the destination location has only an HP9000, you cannot select the iSeries build.

5. Click Close to exit the Build Selection form.

6. On the Work With Package Deployment form, click End to finish the server package scheduling process.

See Also:

• Distributing Software to Deployment Locations.