Another enhancement update

Wow, you can tell that I went on leave for too long, I’m only starting to understand the massive changes that have been completed with the new package build and deploy processes.  They seem to be good (although we are having some issues with updating PS910 on the server).

My good friend Shae pointed me in the direction of this document.  This was a great find to explain some of the changes to the package build process.

I’ve added my comments in RED.

Changes to the Enterprise Server Package Build Process

Numerous changes have been made to the Enterprise Server for both full packages and update package.

Full Package Build Changes

The following changes have been made to the enterprise server for full packages:

• R9621S is a new UBE that runs first and initiates the server package build.
• The system copies all of the business functions’ .c and .h files to the enterprise server from the deployment server check-in location. This is done to preserve a snapshot of the .c and .h files at the time of the build.
• The system generates the C code from the NER on the Enterprise Server. These .c and .h files will be compiled with the rest of the business functions on the enterprise server so the generation is now done on the enterprise server.   Enterprise server does NER gen!
• Before the generation of NER(named event rules), the system will lock all processes, delete ddict, ddtext, glbtbl .xdb and ddb. It will unlock the processes and continue with the Generation.   WHAT? Why?
• The system builds the specs directly from Central Objects, putting the results in the package’s spec tables (<tablename>_<packagename>, for example, F98710_DV910FA) in the database. The client package’s local specs are no longer used to build the server spec tables in the database. Building the specs happens on the enterprise server; whereas before this enhancement, it happened on the build (client or deployment server) machine. How are the specs kept in sync?
• The Package Definition application now has an option to compress the server package and/or the client package. The jde.ini setting is no longer valid.
• The system moves the server log, svrpkgbuild.log, from each server to the deployment server. Also, the files located under the text directory on the enterprise server are moved to the deployment server.
• You can now view the server package build logs in the Build History application when using the View Logs option. However, if the client was not built, the client logs do not appear.

Update Package Build Changes

The following changes have been made to the Enterprise server for update packages:

• R9621S is a new UBE that runs first and initiates the server package build.
• The update package business functions’ .c and .h files are transferred to the enterprise server.
• The Generation of NERs’ .c and .h files occurs on the enterprise server.
• Before the generation of NER, if the update package includes NER, the system will lock all processes, delete ddict, ddtext, glbtbl .xdb and ddb. It will unlock the processes and continue with the Generation. This only happens if there are NER in the update package.
• The specs are built from the Central Objects and put in the package’s spec tables (<tablename>_<packagename>, for example, F98710_DV910UP) in the database. Update packages NOW have their own spec tables in CO
• The system moves the server log, svrpkgbuild.log, from each server to the deployment server. Also, the files located under the text directory on the enterprise server are moved to the deployment server.
• You can now view the server package build logs in the Build History application when using the View logs option. However, if the client was not built, the client logs do not appear.

 

Changes to the Client Package Build Process

Numerous changes have also been made to the client build for both full packages and update packages.

Full Package Build Changes

The following changes have been made to the full package client build.

If Building a Server and Client Package

• R9621S is a new UBE that runs first and initiates the server package build.
• R9622C is a new UBE that runs next and initiates the client package build. The client build only occurs if it was selected in the application.
• All of the business functions’ .c and .h files are moved from the enterprise server to the package’s directory on the deployment server.
• There is no generation of NERs’ .c and .h files on the client.
• The system compiles the .c and .h files.
• The specs are built from the package’s spec tables (<tablename>_<packagename>, for example, F98710_DV910FA) in the database and put into the package’s local spec database.  See how this has been reversed!  Clever!  We used to do this the other way, build the DB on the DEP server and the copy this back to CO.

If Building a Client-Only Package

• R9622C is a new UBE that runs and initiates the client package build.
• The build behaves the same as before the enhancement.
• The business functions’ .c and .h files are retrieved from the deployment server.
• The NERs’ .c and .h files are generated on the client.
• Business functions are compiled.
• The specs are built from Central Objects into the package’s local specs.
• If the user adds a server after building a client-only package, the package will build assuming that the client was not built first. This will cause the system to overwrite the package’s business functions’ .c and .h files on the deployment server with those from the enterprise server. Also, all specs will be rebuilt.