In Oracle JD Edwards EnterpriseOne, Software Updates play a critical role in keeping environments stable, secure, and up to date. Two key components of this update mechanism are:
- ESU (Electronic Software Update)
- ASU (Application Software Update)
A common question for administrators and developers is:
How does JDE decide whether an object should be added, replaced, or skipped during an ESU/ASU installation?
This blog explains the internal logic behind that decision and how the system uses key tables such as F96400 and F9672.
What are ESU and ASU?
ESU (Electronic Software Update)
ESU delivers fixes or enhancements for specific objects in JD Edwards applications.
ASU (Application Software Update)
ASU is a broader update mechanism that may include multiple ESUs and object-level changes.
Both follow similar object comparison logic during installation.
Key Tables Used in Decision Making
JD Edwards uses two important tables during the ESU/ASU process:
1. F96400 (SGESUDM)
- Stores ESU object metadata
- Contains update date for the incoming ESU object
- Field of interest: SGESUDM
2. F9672 (SUSUDATE)
- Stores software update history
- Tracks previously applied objects in the environment
- Field of interest: SUSUDATE
Core Decision Logic
The system determines whether an object should be:
- Added
- Replaced
- Merged (legacy only, removed in 64-bit systems)
Decision Rule:
If SGESUDM > SUSUDATE → Object is REPLACED
In simple terms:
- If the incoming ESU object is newer → Replace existing object
- If the dates are equal or older → No replacement or conditional handling
Important Notes
1. F9861 is NOT used
The ESU installation process does not check F9861 to decide object installation.
2. MERGE Option Removed in 64-bit
In modern JD Edwards environments:
- Only ADD and REPLACE are supported
- MERGE functionality has been removed
SQL to Identify All Objects That Will Be Replaced
Before applying an ESU (example: UN9), you can identify impacted objects using:
SELECT
T1.SGOBNM,
T1.SGESUP,
T1.SGESUDM,
T2.SUOBNM,
T2.SUPKGNAME,
T2.SUSUDATE,
T2.SUPATHCD
FROM JDESY920.F96400 T1
JOIN JDESY920.F9672 T2
ON T1.SGOBNM = T2.SUOBNM
WHERE T1.SGESUP = 'UN9'
AND T2.SUPATHCD = 'PD920'
AND T1.SGESUDM > (
SELECT MAX(T3.SUSUDATE)
FROM JDESY920.F9672 T3
WHERE T3.SUOBNM = T1.SGOBNM
AND T3.SUPATHCD = 'PD920'
);
What this shows:
- Objects that will be REPLACED
- New ESU objects not yet applied
- Impact scope before deployment
Object-Level Comparison Example
Example 1 – Replace Scenario
SELECT SUOBNM, SUPKGNAME, SUSUDATE, SUPATHCD
FROM JDESY920.F9672
WHERE SUPATHCD = 'DV920'
AND SUOBNM = 'B9600186';
SELECT SGOBNM, SGESUP, SGESUDM
FROM JDESY920.F96400
WHERE SGESUP = 'UN9'
AND SGOBNM = 'B9600186';
Interpretation:
If:
SGESUDM > SUSUDATE
👉 Object will be REPLACED
Why This Logic Matters
Understanding ESU decision logic helps:
- Avoid unexpected object overwrites
- Predict deployment impact
- Reduce downtime during ESU application
- Improve change management planning
- Support audit and compliance requirements
Common Use Case Before Applying ESU (UN9 Example)
Before installing ESU package like UN9, administrators should:
- Extract ESU package
- Install in Planner Environment
- Run comparison SQL
-
Identify:
- Objects to be replaced
- New objects to be added
- No-change objects
Reference Oracle Support Documents
- E1: ESU Install Process Under the Covers (Doc ID: 2388199.2)
- How to Force Merge or Re-Merge Objects (Doc ID: 790705.1)
- Why Objects Are Merged vs Replaced (Doc ID: 660444.1)
- Net Change Functionality of Software Updates (Doc ID: 651812.1)
Final Thoughts
The ESU/ASU process in Oracle JD Edwards EnterpriseOne is driven by a simple but powerful rule set based on object metadata comparison.
At the core:
SGESUDM (incoming ESU) vs SUSUDATE (existing system)
Understanding this logic allows technical teams to:
- Predict update impact accurately
- Avoid production surprises
- Improve deployment confidence
