In JD Edwards Object Management Workbench (OMW), Check-Out and Check-In are crucial processes for managing development objects within the JD Edwards EnterpriseOne development environment. 

Check-In Process in JD Edwards OMW 

Once modifications are complete, the object must be checked in to make it available for further processing or promotion. 

Check-Out Process in JD Edwards OMW   

When a developer needs to modify an object, they must first check out the object. This locks the object for editing and prevents conflicts with other developers. 

Managing specifications and artifacts in JD Edwards EnterpriseOne varies based on the Tools Release version. Understanding how these elements move from the Development Workstation to the Central Objects Table, Deployment Server, and Repository is crucial for maintaining a streamlined development and deployment process. 

Below is a breakdown of the check-in process for different Tools Releases. The Check-out process works in reverse order of check-in. 

Prior to Tools 9.2.1 

• Specifications (Specs): Transferred from Development Workstation to Central Objects (F987*) Table. 

• Artifacts: 

• • From Dev Workstation: source, include, java, and res files are copied to the Deployment Server path code respective folder. 

Tools 9.2.1 to 9.2.4.x 

Tools 9.2.1.x  

• Specifications (Specs): Copied from Dev Workstation to Central Objects (F987) Table*. 

• Artifacts: 

• • From Dev Workstation: source, include, java, and res files are copied to the Deployment Server path code respective folder  

• • Also copied to Repository (F98780R and F98780H). 

Tools 9.2.3.x 

• Specifications (Specs): Copied from Dev Workstation to Central Objects (F987) Table*. 

• Artifacts: 

• • From Dev Workstation: source, include, java, and res files are copied to the Deployment Server path code respective folder  

• • Copied to Repository (F98780R and F98780H). 

🔹 Exceptions: 

• NER (Named Event Rules) and TER (Table Event Rules) artifacts are not copied to the Deployment Server or Repository. 

• BSFN (Business Function) and BSSV Artifacts: 

• Continue to be copied to the Deployment Server Path Code folder. 

• Copied to Repository (F98780R and F98780H). 

• NER and TER Artifacts (.c and .h) are generated at build time. 

Tools 9.2.4.x 

• Specs: Copied from Dev Workstation to Central Objects (F987) Table*. 

• Artifacts: 

• • Copied only to Repository (F98780R and F98780H). 

🔹 Changes: 

• BSFN, NER, and TER Artifacts are NOT copied to the Deployment Server. 

• NER and TER Artifacts are NOT copied to Repository F98780R and F98780H. 

• BSFN Artifacts continue to be copied to Repository F98780R and F98780H. 

• NER and TER Artifacts (.c and .h) are generated at build time. 

Tools 9.2.5.x or Higher 

🔹 Major Change: The E1Local Database is Removed 

• Specs: 

• • Copied from the User Spec Tables (F98xxxUS) to the Central Objects (F987xxx) Check-in Location Tables. 

• Artifacts: 

• • Copied from Dev Workstation to Repository (F98780R and F98780H). 

Key Takeaways 

• Tools 9.2.1 introduced artifact storage in the repository (F98780R and F98780H). 

• Tools 9.2.3 stopped copying NER and TER artifacts to the Deployment Server and Repository. 

• Tools 9.2.4 streamlined artifact management by removing Deployment Server copies. 

• Tools 9.2.5 removed E1Local and changed how specs are stored. 

Understanding these changes ensures smoother development, deployment, and upgrade process within JD Edwards EnterpriseOne.