Select your language
- Details
-
By Vincenzo Caserta - Category: Object Management Workbench
Most JDE teams treat Object Management WorkbenchJD Edwards' change management and source control tool used to track, modify, and promote objects across environments. as nothing more than a source control UI with check-in and check-out buttons. In reality, managing the JD Edwards OMW project lifecycle from development to promotion means orchestrating a relational state machine across token holds, central objectsThe central database repository storing master object specifications and metadata for an environment. spec modifications, and pathcodeA JD Edwards environment definition (such as DV920, PY920, or PD920) pointing to specific specifications and business data. synchronization across F98220 and F98222 control tables. Treating it casually is why roughly 15% to 20% of custom promotion failures stem directly from orphan tokens, uncommitted C BSFNBusiness Function: Encapsulated business logic written in C or Event Rules to perform specific processing. header files, or silent local spec drift.
- Details
- By Vincenzo Caserta
- Category: Retrofitting Standard Code
Every JD Edwards system that has been running for a few years carries an unanswered question: how many of the custom objects developed over time are still fundamentally identical to the Oracle standard from which they derive, and how many have evolved to the point of becoming something entirely different? This question becomes urgent when facing an upgrade, a migration or a customisation audit. In most cases, the answer does not exist — because no one has ever sought it systematically. In this article, I describe how I approach this problem in my work, and the proprietary tool I developed to solve it.
Page 16 of 16