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/P9601W), Package Build Director (P9621/P9601W), and Deployment Director (P9631) programs.

After you schedule a server package for deployment, to deploy to the servers, you must complete an additional step to launch the batch program that you use on the client or deployment server. For web packages, you must use the Deploy button at the bottom of the page. You must perform these tasks whenever you deploy a package to an Enterprise Server or Deployment Server.

Note: Starting with Tools Release 9.2.6.0, when you deploy a full server package, no locks are placed on the processes that are running. Any ongoing UBE processing will continue to process using the old package specs. When a new UBE is submitted, it will use the current package that is deployed. Also, web users will continue to be logged in to their session using the old package. If they sign off and sign back in, they will switch to the current package.You can deploy update packages that contain 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 of the update package. Instead, the system queues any UBE jobs that are submitted to the enterprise server that are in the package and runs them as soon as the installation finishes.
Note: Starting with Release 9.2.7.0, after the package is deployed, the process will submit the Table Conversion UBE R98405W that runs on the server. This UBE runs the table conversions for full and update package. For a full package build, the TC UBE converts all tables listed in the F98405 table. For update packages, table conversion runs only if objects in the package are tables.

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 using the applications on the client workstation or deployment server, select Deploy from the Row menu on the Work with Package Deployment form.

When you select Deploy from the Row menu, the system determines the batch programs to call based on what is currently selected on the Work with Package Deployment form.

  • 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 for deployment..

  • 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 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 an update package that is UBE-only, APP-only, or UBE/APP-only package to an enterprise server, the batch process:

  1. Verifies that the enterprise server deployment location is the same as the Windows client submitting the package.

  2. Changes the enterprise server status to Pre Deploy.

    This is done by changing the MDMCHRCDNM column to 50 in the F9651 table.

  3. 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.

  4. Sends lock messages to the metadata kernel for the UBEs in the package on each selected enterprise server.

  5. 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.

  6. Updates the specifications in the database.

  7. Sends unlock messages to all the enterprise servers to unlock the UBEs that were in the package.

  8. Marks the servers as available.

    This is done by changing the MDMCHRCDNM column to 30 in the F9651 table.

  9. 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 update package with Business functions, NER and tables, and other type objects to an enterprise server, the batch process:

  1. Verifies that the enterprise server deployment location is the same as the Microsoft Windows client submitting the package.

  2. Changes the enterprise server status to Pre Deploy.

    This is done by changing the MDMCHRCDNM column to 50 in the F9651 table.

  3. Waits for five minutes.

  4. Sends lock messages to all the selected enterprise servers.

  5. 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.

  6. Copies the BSFN executables from the package location to the live path code location.

  7. Sets the spec.ini file to the new package and spec data source.

  8. Sends unlock messages to all the enterprise servers.

  9. Marks the servers as available.

    This is done by changing the MDMCHRCDNM column to 30 in the F9651 table.

  10. Updates the F96511 table with the new package and spec data source information.

    This information is used by the web servers.

  11. (Release 9.2.7.0) Checks if there are tables in the package.
  12. If there are tables in the package, the system calls B98405WS which then submits R98405W UBE to run on the server.
  13. The R98405W UBE checks if any tables are in update package which is listed in the F98405 table for Table Conversions.
  14. If tables are listed in the F98405 table, then the process runs the table conversion for each table.
Note: A deployed package can be deployed multiple times to the same or different servers.
Starting with Tools Release 9.2.6.0, when the system launches the batch program to deploy a full package to the Enterprise Server, the process:
  1. Sets the F9651 field to mdmchrcdnm= 50 to prepare the server for deployment..
  2. Opens the <pathcode>/spec.ini file and changes the <pathcode>_Package setting to the new package name: DV920_Package=DV920FA.
  3. Sends a broadcast message that a package change was performed.
  4. Sets the F9651 field to mdmchrcdnm= 30 to indicate that deployment is completed.
  5. Updates the record in the F96511 table with the Enterprise Server information, port number, pathcode, package name, and type 30 to indicate that this is the deployed package.
  6. (Starting with Tools Release 9.2.5.0) If the package is also a client package, insert a record in the F98825 table with these details:

    MKEY=”CLIENT" UPJDEPKGNM=<package name> UPPATHCOD=<pathcode> UPINPKST=’20’ Date and time

  7. For the previously deployed package with the details MKEY= CLIENT and UPINPKST=20, update the status to UPINPKST=30.
  8. (Release 9.2.7.0) Checks if it is a full package build. If yes, the system submits TC UBE R98405W to run on the server.
  9. The R98405W UBE checks if any tables are listed in the F98405 table to convert.
  10. If tables are listed in the F98405 table, the process initiates the table conversion on each table.
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.

(Prior to Tools Release 9.2.6.0) 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.

(Prior to Tools Release 9.2.6.0) For IBM i, the BSFN objects in PY920 are copied into the $PY920 library. For Microsoft Windows and UNIX, the BSFN and spec objects in PY920 are copied to the PY920_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.

(Starting with Tools Release 9.2.6.0 ) During the package build, the deploy folders are set up under <pathcode>\bin64\<packagename and <pathcode>\spec\<packagename> and are populated with the files needed. The deployment of the package, only changes the <pathcode>\spec\ spec.ini to the current package and no other process is carried out.