Understanding Server Package Deployment

The process for deploying a server package is nearly identical to that for deploying a package to a workstation. In both cases, you need to assemble, define, build, and schedule the package for deployment by using the JD Edwards EnterpriseOne Package Assembly (P9601), Package Build Director (P9621), and Deployment Director (P9631) programs.

After you schedule a server package for deployment, you must complete an additional step to launch the batch program that enables you to deploy to servers. You must perform this task whenever you deploy a package to an enterprise server or deployment server.

Important: You can deploy UBE-only, APP-only, or UBE/APP-only packages at any time. Their deployment does not affect any UBEs that are currently running or those that are submitted. All other types of server packages should be deployed only when necessary, because the enterprise server is not available to process business applications and batch processes during the installation process. The enterprise server does not actually shut down during package installation. Instead, the system queues any jobs that are submitted to the enterprise server and runs them as soon as the installation finishes. For this reason, you should schedule these server packages to be deployed after hours in order to minimize impact on users. Before you deploy a package to an enterprise server, verify that the services have been started and that no UBEs are active.

To further minimize impact on the network and users, if the development environment is on the same enterprise server as the production environment, consider preventing developers from moving their own objects through server packages. Instead, require that an administrator perform this function.

To deploy a server package, select Deploy from the Row menu on the Work with Package Deployment form. This is the same function that you use to deploy packages to deployment servers during multitier deployment.

The system determines which of the batch programs to call, based on what is currently selected on the Work with Package Deployment form when you select Deploy from the Row menu:

If a specific deployment server is selected, the system launches the Multi Tier Deployment batch program (R98825C).
If the deployment server folder is selected, the system launches the Multi Tier Deployment batch program for every deployment server that has a package scheduled.
If a specific enterprise server is selected, the system launches the Enterprise Server Deployment batch program (R98825D).
If the Enterprise Server folder is selected, the system launches the Enterprise Server Deployment batch program for every enterprise server that has a package scheduled.
If a specific package is selected, the system launches the Multi Tier Deployment batch program, and then the Enterprise Server Deployment batch program for the selected package.
If you sort by packages and the Deployment folder is selected, the system launches both the Multi Tier Deployment batch program and Enterprise Server Deployment batch programs for all packages.
If a specific workstation or the Workstations folder is selected, the Deploy option is unavailable.

When the system launches a batch program for all servers or all packages, deployment does not occur unless the package has been previously scheduled for a specific server. A full package can be deployed to all servers. However, an update package can be deployed only to servers that already have the parent package deployed. Also, update packages cannot be deployed if the parent package is an inactive or not-deployed full package.

When the system launches the batch program to deploy a UBE-only, APP-only, or UBE/APP-only package to an enterprise server, the batch process:

Verifies that the enterprise server deployment location is the same as the Windows client submitting the package.
Changes the enterprise server status to Pre Deploy.
This is done by changing the MDMCHRCDNM column to 50 in the F9651 table.
If this is an APP-only or UBE/APP-only package, then it waits one minute for the HTML server to find the deployment record.
Sends lock messages to the metadata kernel for the UBEs in the package on each selected enterprise server.
Once the package is being deployed, the UBEs in the package cannot be submitted.
This is done by changing the MDMCHRCDNM column to 10 in the F9651 table.
Updates the specifications in the database.
Sends unlock messages to all the enterprise servers to unlock the UBEs that were in the package.
Marks the servers as available.
This is done by changing the MDMCHRCDNM column to 30 in the F9651 table.
Updates the F96511 table with the new package and spec data source information.
This information is used by the web servers.

Note: A deployed package can be deployed multiple times to the same or different servers.

When the system launches the batch program to deploy all other packages to an enterprise server, the batch process:

Verifies that the enterprise server deployment location is the same as the Microsoft Windows client submitting the package.
Changes the enterprise server status to Pre Deploy.
This is done by changing the MDMCHRCDNM column to 50 in the F9651 table.
Waits for five minutes.
Sends lock messages to all the selected enterprise servers.
Once the servers are locked, the batch process marks them as unavailable.
This is done by changing the MDMCHRCDNM column to 10 in the F9651 table.
Copies the BSFN executables from the package location to the live path code location.
Sets the spec.ini file to the new package and spec data source.
Sends unlock messages to all the enterprise servers.
Marks the servers as available.
This is done by changing the MDMCHRCDNM column to 30 in the F9651 table.
Updates the F96511 table with the new package and spec data source information.
This information is used by the web servers.

Note: A deployed package can be deployed multiple times to the same or different servers.

A server package with the specs built in a shared mode can be deployed to a web server. This process of deploying to the web server is automatic and does not require any end user intervention. The web servers pool the package information from the JD Edwards EnterpriseOne logic server. It compares the package manifest from the spec tables to the one in its serialized database and makes the necessary updates.

During server package deployment, the business function (BSFN) dll's, SRVPGMs, .so objects, or .sl objects of the live package are replaced by the objects from the built package. However, if a deployment fails, you may have a mismatched set of BSFNs and specs. With 8.96 JD Edwards EnterpriseOne clients, you can back up the existing BSFN objects. If the deployment fails, you can restore the BSFN objects. The option to back up the live BSFN objects before deployment can be enabled through the Build Settings within Server Manager.

For IBM i, the BSFN objects in PY900 are copied into the $PY900 library. For Microsoft Windows and UNIX, the BSFN and spec objects in PY900 are copied to the PY900_BACK folder. Clients can restore BSFN objects by copying the objects from the backup location to the live folder. They can restore the specs by changing the package name to the previous package in the spec.ini file.