EMERALDCUBE BLOG

E1 Package Compression: To Use or Not to Use?


What is package compression and why do you care if it is used?

I spent my first 7 years as a consultant building packages for one particular client.  I built packages for 3 environments two times per day.  I discovered three issues in the area of package management: disk space, time, and keeping development clients up to date.

A package consists of both server and client components.  For this discussion, compression is the zipping up of the client components, the package directories found on the deployment server for a full package build.  The package directories contain the code, specs, and database necessary to install or update the development client.

Package compression takes the client package directories, zips them up into *.CAB files, and then uses these compressed files to transfer the installation code to the development client over the network.   The compressed CAB files are smaller in size than all of the uncompressed files and folders, resulting in quicker installs to development clients over slow networks.

Why Compression Was Used

Back in 1990’s when this package process was being devised, networks were slow and EVERYONE used a fat client instead of a web client, so when packages were installed, it put a heavy load on an already slow network to install them all, and package compression used to reduce the amount of network traffic load caused by the installation to fat clients.

In 2001, I worked at a small company where we would build a full package and then spend the weekend loading the new full package on 200 PC’s. It would take 8 hours to build.   It took about 15 minutes to load a package on a PC.  Four of us would each have a couple of PC’s loading the package simultaneously.  It took us about 4-6 hours.  We could feel the load of data going across the network!

Today the main client is the web client.  Most companies have less than 10 development clients.  One person can now load new full packages on all 10 PC’s in less than 2 hours, whether-or-not the package is compressed.

In addition, on today’s networks, the package install takes the same amount of time whether the full package has been compressed or not, whether you are transferring all of the directories of a package or just the compressed files.

Keeping Client PC’s up to date

The most important drawback to using compression is that the compressed files created during a full package build do not get updated when you perform an update package build.  After deploying the next full package to a Development Client, you will not get the update packages built against that full package without deploying each of the updates out to the PC.

A snippet taken from an Oracle solution describes the package build process:

When an update package is built, a parent package is specified, and this parent will receive the updates that are included from the objects chosen by the user during the update package assembly. The updates are done to the directory files in the parent package, but the ‘install files’ (compressed cab files) are not automatically updated. For a new install of the parent package to include all of the update package changes, a recompression of the full parent package needs to be performed or all of the update packages need to be installed after the full package installation.”

In other words, during an update package build, the changes in the update package are copied over to the full package directories, but the compressed files are not updated.   You must perform a procedure called “package recompression” in order to update these compressed files so that new installations of the full package will include the updates.  Without the package recompression, after you have built an update package, if you take the option to load the full package on a fat client, then the specs you are loading do not include the updates.  The update packages each must be installed in order to fully update the PC.

The latest releases of EnterpriseOne were tested to confirm this behavior is still current, and update package builds and deployments with new tools releases still must be re-compressed to include the specs for those package builds in the parent package.  The update package files are only copied to the full package directories, not updated to the compressed CAB files unless this re-compress process is completed.

If you did NOT compress the directories in the initial build of the full package, then during the data transfer for installing a full package to a development client, the updated full package directories are transferred to the client.  Therefore, without compression, the most recent files from the full are always installed on the client.

Disk Space

The compression of the directories adds to the size of the package directory.  Uncompressed packages do not contain the zipped *.CAB files.

An example of package sizes in a tools release 9.1 environment:
Package directory structure for package that was NOT compressed uses 5.21 GB.
Package directory structure of package that IS compressed uses 7.33 GB.

2 GB more disk is used per full package for the compressed files than the package that was not compressed.  For companies with the standard setup of DV, PY, PD environments, this comes to a whopping 6 GB X 2 full packages/path code = 12GB more disk used on the deployment server.  If the disk is physical and not expandable you may need to think about 12GB.

Time

The time it takes to build the client package before compression on current servers is approximately ½ hour, with compression it takes an hour.  It used to take a lot longer.  With the Windows 2003 servers running on older, less advanced hardware it would take hours.

Summary

To conclude, I make it a practice to always build full packages without using client package compression.  It saves time, disk space, and confusion over what updates are applied to a PC during an installation.

In order to NOT compress directories for a full package build, when adding the package build information, select the Compression tab and unselect the Compress Package option.

If you DO use the compression option, you want to think about following the procedure to recompress the full package on a regular basis or build full packages more often.

Procedure for Package Recompression

In case you already have some full packages with compressed directories and lots of updates, you will want to recompress the updated full package directories and then delete the update packages.

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=jyp1r636x_9&_afrLoop=546565932481795#R18

The process for Application version 8.12 and above:

  1. From Package Build History application (P9622), inquire on the full package, select the Client/Compression options.
  2. Select each BSFN/Reset Row exit, change the status for both “Spec Build Status” and “Pack Build Status” to 01 – Not Build. Press the Reset button.
  3. Select Client/ Row exit Resubmit Build.
    1. When prompted to regenerate NER select Cancel.

The process for Application version 8.11 and below: (On older hardware this may take a couple of hours)

  1. On Package Build application, select the full package/Row exit Advanced/Reset button.
  2. Deactivate the build, select row exit Build Revisions .
    1. Unselect the ‘Build Specifications Options’ checkbox from the Specifications tab.
    2. Unselect the ‘Generate NER’ and ‘Build Functions Options’ checkbox from the Business Functions tab.
    3. Select Compression options and ensure that the Compress Directories checkbox is checked.
    4. Press OK.
  3. Activate and submit the build.
    1. If asked to delete the directories, choose No.
    2. If asked to regenerate NER, press Cancel.

How to build a full package without compressing directories

In order to NOT compress directories for a full package build, when entering the Build information, select the Compression tab and unselect the Compress Package option.