JDE Development Cycle


Legendary Poster
First, let me start by saying, I do understand why there should be a no mod
policy... But, even in a No Mod World, new objects are copied/created and
underlying business objects change when ESUs are applied....

We all live in the real world... so, I need some suggestions about the real
world JDE development cycle. So, here goes...

In a typical development cycle there should be three environments
(Development - where the programmers play, Prototype - where the users test
what the programmers played with & Production - where the programmers can't

Now comes, that little monster I fear so much, ESUs.
During an Ideal development cycle, ESUs might be applied to the Dev
Environment, tested and played with by Programmers - and verified that their
created/modified objects work with the ESU. If the ESU doesn't work in DEV,
it should be backed out. But that is not real world, because ESUs require
the dozen programmers to check in what they are playing with (overriding the
environment's objects/circumventing why we have a SAVE environment)...
Programmers are, by nature, going to forget to check in objects and not want
to place a 'work in progress' to anything other than SAVE...

"- anyone got Merge Working with ESU, correctly???"

Once the ESU is tested (we are still talking dream world, here) and accepted
by the Programmer staff, It would be applied to the Prototype environment,
for the users to test... oh, but wait... wasn't it tested with checked in '
work in progress' objects in DEV (something to think about/OUCH). Once the
Users have OK'd it, the ESU gets pushed to Production...

There are so many issues / concerns regarding the Development Cycle with
ESU, I am getting sort of frightened... give me back a green screen and the
RPG cheat sheet...

Does anyone have their hands on some SOPs for the JDE Development Cycle? I
am looking for anything out there that would cover ... which environment
objects get check out from (even if they are to be copies) to what
environment ESUs should get applied to.

I am willing to do some big hike work to build a white-paper and throw it
back to the list... any helps you can provide will go an enormous way!


Daniel Bohner
[email protected]
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x


Legendary Poster

ESU's are a killer. They step all over work in process items as well as objects customized, tested, and working well in production.
We install them to address 1 issue and they cause 3 new ones.

At least in the days of paper fixes we could apply fixes with a fine edged scalpel - an ESU is a two handed broadsword in comparison ...

Anyway, our development process is still a-birthing in this brave new world, but the approach we have elected to follow is as follows:

1. Environments
Since we are a small I.T. shop (2 developers) with only minor customizations (Changes to forms, reports, and code fixes that JDE couldn't make in a timely manner) we saw no need to have 3 environments for a full development life cycle. Rather we both code and test in ProtoType and then Promote to Production. We still have the "Development Environment" as well as a "Save" environment/path, but we don't use Development in the manner envisioned by JDE. This is because the traditional OW life cycle has no means of rolling back changes made to the production environment should a problem or flaw in an object(s) be detected at that late stage in the game. So instead we use Development as a "Backup" environment. Before any object(s) are promoted to Production the current "in Production" version of the object(s) are copied to the "Development" environment.
Should a problem then be detected in Production we have some confidence in our ability to roll things back to the way they were.

2. ESUs Application
Since we/I have absolutely no trust in the Spec Merge Process, as well as no trust in the quality of the changes embedded in the ESU (of which we usually are only looking for 1 specific fix), we only apply ESUs to the JD/Pristine environment. We then paw thru the objects/code to find the specific code fix we are looking for, and then apply the code fix ourselves within our proType Environment as described above. This approach is basically the one described by Jon Steel (AltQuark) and so far has worked well, although I can envision situations where we will have difficulty identifying the specific changes. We'll work through those situations as they occur.

Since our (I.T.'s) goal here is to first provide a stable, working environment this is the best of the broth of bad choices we were faced with.

This approach wouldn't work in some shops - but I believe it will here.

Pardon my lengthy reply.


Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials


Hi Daniel,

Personally I would never touch PRIST. It is invaluable for testing functionality that you have never tried before to see if there is functionality that may add value to your company. Creating another Path Code would solve your problem. Create a path code for ESU733, copy all PRIST objects into there, then apply ESUs to ESU733. This allows you, if you ever found the need, to compare the codes.

More importantly is that having this path code makes retrofitting modified objects much easier. When an object has been ESU'd and you have a custom mod against it, simply do a code diff between your code and the PRIST code, then apply those changes to the ESU object.

One other thing I find helpful is that we modify SIMSAR in F9861 so that we can quickly tell whether the object was part of an ESU at some point. After applying an ESU, we take the object list from the access database and put a SQL script together to modify this field.

Good luck,

Paul Areano
One World B7.3.3.2 SP 15_007 Intel NT Oracle
CNC/Applications/Etc. etc. etc.