As CNC professionals, we were shielded from the numerous functional changes that JD Edwards made to EnterpriseOne Xe and all releases up to the 8.11 level. However, EnterpriseOne 8.12 contains important architectural changes that will affect our management of the system.
In all previous EnterpriseOne releases, the specifications we use were stored in several locations: on the “SPEC” directory on the deployment server; on standalone machines with a “fat” or “thick” client in the “SPEC” directory, as well as in the RDBMS repository after check in; and on the Java application server (JAS) generation machine. The deployment server databases were either MS Access or MS SQL Server, depending on your release. But we all knew that the spec files were where the changes were contained.
Now, if you are installing or upgrading to EnterpriseOne 8.12, why is the spec directory empty?
Specs are no longer stored in Table Access Method (TAM) files. As we are all aware, the TAM files contained our modifications to the system. They were created by a proprietary process that took the instructions from the C++ code and the specs in Central Objects to create the “runable” spec files. Electronic Software Updates (ESUs), updates, and modifications from developers were merged in any installation or upgrade, to the spec files in the specific path code of the targeted area on the deployment server.
With EnterpriseOne 8.12, however, these changes are handled in an MSDE database on the deployment server and in the corresponding tables in the RDBMS. In other words, spec files are no longer used. This is a movement to remove traditional “fat clients” from the spectrum. The specs are now stored in the Central Object tables on your RDBMS. All you will see when you look in “SPEC” will be the spec files that we have always refreshed: the Global Table and Data Dictionary specs. When developers now check in changes, or ESUs or Updates or Upgrades are performed, the metadata is now changed in the local MSDE database on the deployment server and in Central objects.
This means that package builds will proceed in a different sequence than we (technology professionals) are all used to. The building of specs will occur in the RDBMS, not on the deployment server. This cuts down on server build times (other than on IBM’s System i, which still needs to perform BUSBUILD) as well as spec build times, as there are no specs (other than the table and data dictionary specs for developer workstations) to be built.
These changes, however, alter the way that we create new environments, not to mention the tools we need to manage our systems. It also changes the way we, as technology professionals deal with the “code” that runs our EnterpriseOne systems. The method of creating new path codes and refreshing them has changed.
As for JAS generation…if you are upgrading to EnterpriseOne 8.12 you will ultimately need to use an EnterpriseOne Tools 8.96 release. That involves the auto-generation of specs, which brings us to another blog article I’m writing…how to handle the web-only functionality of EnterpriseOne 8.12. As I’ll discuss in the article, letting the system automatically create specs is wonderful from an administration standpoint, but it slows the system down. We’ll explore whether or not that is a good thing for our users.
See you next time, and good luck with your management of EnterpriseOne!
© Jim Stuebgen, Sr. Solution Architect, Global Systems Integration, Inc. (GSI) 2007