Understanding how the JD Edwards EnterpriseOne check-in process works across different Tools Releases is important for CNC administrators and developers. Over time, Oracle changed how specifications and artifacts are stored, managed, and deployed.
This article explains the differences in the check-in process from older releases through Tools 9.2.5.x and higher.
Tools Prior to 9.2.1
In releases prior to Tools 9.2.1, the check-in process was straightforward and relied heavily on the Deployment Server file system.
Specs
Specifications were copied:
-
From the Development Workstation
-
To the Central Objects tables (
F987*)
These specification records were stored in the Central Objects database.
Artifacts
Artifacts such as:
-
Source files
-
Include files
-
Java files
-
Resource (
.res) files
were copied from the Development Workstation directly to the Deployment Server pathcode folders.
Architecture Overview
Development Workstation
|
|---- Specs ----> Central Objects (F987*)
|
|---- Artifacts ----> Deployment Server Pathcode Folder
Tools 9.2.1.x to 9.2.4.x
Oracle gradually introduced the Repository tables (F98780R and F98780H) and changed how artifacts were handled.
Tools 9.2.1.x
Specs
Specifications continued to be copied:
-
From Development Workstation
-
To Central Objects (
F987*) tables
Artifacts
Artifacts were copied to two locations:
Deployment Server Pathcode Folder
Artifacts copied included:
-
Source
-
Include
-
Java
-
Resource files
Repository Tables
Artifacts were also stored in:
This was the beginning of repository-based artifact management.
Architecture Overview
Development Workstation
|
|---- Specs ----> Central Objects (F987*)
|
|---- Artifacts ----> Deployment Server Pathcode Folder
|
|---- Artifacts ----> F98780R / F98780H
Tools 9.2.3.x
Tools 9.2.3 introduced major changes for NER and TER object handling.
Specs
Specifications still copied to:
-
Central Objects (
F987*) tables
Artifacts
Deployment Server
The following continued to copy to Deployment Server:
-
Source
-
Include
-
Java
-
Resource files
However:
-
NER artifacts were no longer copied
-
TER artifacts were no longer copied
Repository Tables
Artifacts copied to:
But:
-
NER and TER artifacts were not stored in Repository tables
-
BSFN artifacts continued to be stored
Build-Time Generation
NER and TER artifacts (.c and .h) started being generated during package build time instead of being stored directly.
Key Change
This reduced dependency on storing generated NER and TER C source files in the Deployment Server and Repository.
Architecture Overview
Development Workstation
|
|---- Specs ----> Central Objects (F987*)
|
|---- BSFN Artifacts ----> Deployment Server
|
|---- BSFN Artifacts ----> F98780R / F98780H
|
|---- NER/TER .c and .h generated during build
Tools 9.2.4.x
Tools 9.2.4 further modernized artifact handling and reduced dependency on the Deployment Server.
Specs
Specifications continued to be copied to:
-
Central Objects (
F987*) tables
Artifacts
Artifacts such as:
-
Source
-
Include
-
Java
-
Resource files
were copied only to:
Deployment Server Changes
The following were no longer copied to the Deployment Server:
-
BSFN artifacts
-
NER artifacts
-
TER artifacts
Repository Behavior
BSFN
BSFN artifacts continued to be stored in:
NER and TER
NER and TER artifacts were not stored in Repository tables.
Instead:
files were generated dynamically during build time.
Key Improvement
This release significantly reduced file-system dependency on the Deployment Server and moved EnterpriseOne closer to repository-centric object management.
Architecture Overview
Development Workstation
|
|---- Specs ----> Central Objects (F987*)
|
|---- BSFN Artifacts ----> F98780R / F98780H
|
|---- NER/TER generated during build
Tools 9.2.5.x and Higher
Tools 9.2.5 introduced another major architectural change.
E1Local Database Removed
The E1Local database was removed from the architecture.
This simplified the development and check-in process.
Specs
Specifications are copied:
-
From User Spec Tables (
F98xxxUS)
-
To Central Objects Check-in location tables (
F987xxx)
Artifacts
Artifacts including:
-
Source
-
Include
-
Java
-
Resource files
are copied directly into:
No Deployment Server artifact dependency exists for check-in processing.
Architecture Overview
Development Workstation
|
|---- User Spec Tables (F98xxxUS)
| |
| ---> Central Objects (F987*)
|
|---- Artifacts ----> F98780R / F98780H
Final Thoughts
The JD Edwards EnterpriseOne check-in architecture has evolved significantly over time:
-
Older releases depended heavily on Deployment Server file systems.
-
Mid releases introduced Repository tables.
-
Modern releases rely primarily on Repository storage and build-time artifact generation.
Understanding these changes helps CNC administrators troubleshoot:
-
Check-in failures
-
Missing artifacts
-
Package build issues
-
Repository synchronization problems
-
Object promotion inconsistencies
It also helps explain why older troubleshooting methods may not apply to newer Tools Releases.
Specs - Copied from the User Spec Tables (F98xxxUS) to the Central Objects (F987xxx) Check-in location tables.
Artifacts -> From Dev WorkStation source, include, java, res copied to Repository F98780R and F98780H
