How to apply ESU's

altquark

altquark

Legendary Poster
How to apply ESU\'s

I know many people have been asking of a method for implementing ESU's in a Development Environment - therefore I have published on my website a new whitepaper explaining a good method of configuring OMW rulesets to allow for easy integration of ESU's without affecting development.

I look forward to (constructive) criticism - please feel free to distribute the document to whomever you wish - but please understand it is only one way to run a development environment.....it may not suit your company !

http://www.erpsourcing.com <-- under RESEARCH and WHITEPAPERS....

Jon Steel
erpSOURCING LLC


ERP Sourcing
http://www.erpsourcing.com
[email protected]
 
Re: How to apply ESU\'s

Jon,

Thank you for your very interesting paper on applying ESU's. We are testing OW XE currently, and are having quite a discussion about applying ESU's and major XE Updates (e.g. Update 1 & 2).
Our concerns are as follows:

1. What is required by JDE for support? Will JDE require us to apply an ESU or Update in whole in order to provide us with support? Given the complexity of OneWorld, you can see how having all customers apply full ESU's and Updates would appeal to their support staff -- fewer permutations to deal with -- less complexity.

2. Need to minimize the amount of retrofitting of code with customizations. Every time we apply an ESU or Update, we dread having to go back and reapply all our customizations and fixes to JDE's delivered code. In cases where it has made sense, we've either created new applications or copied JDE's objects to system 55 objects. However, in several cases, we have no choice but to modify JDE objects themselves.

3. Need to minimize introduction of unneeded, undocumented, or undesirable changes in application behavior. Say, for instance, we want to have a problem fixed in Sales Order Entry (P4210), and the fix is included in ESU #XYZ. However, ESU #XYZ also includes modifications to P4310 (Purchase Order Entry), which may or may not cause the application to behave as we have come to expect. This is where the old paper fix solution from JD Edwards would shine.

Your solution to apply ESU's only to Pristine, and then copy to other pathcodes brings us back to paper fixes about as far as is possible currently; I appreciate your insight that went into this. However, it also makes Pristine no longer truly "Pristine" (i.e. comprised of the original objects as originally delivered to us by JDE). Also, if you choose to promote a specific object from Pristine to other environments, what if that object was modified in that ESU/Update to fix several problems? You could end up with an "orphaned" fix, some of whose associated object fixes may not have been promoted.

I can't believe that other companies are not having these same types of issues dealing with ESU's, Updates, and OMW. Has anyone else come up with a different and/or better solution?


Don Sauve
Wagstaff, Inc.
Production: OW B733.1 & SP11.3, HP-UX 11.0, Oracle 8.1.6
Prototype: OW XE & SP15
 
Re: How to apply ESU\'s

Hi Don,

Sorry its taken me a couple of days to get back to you - I've been busy for a go-live prior to Focus !

To answer your questions in order :

1. I cannot answer this question entirely - since I no longer work for JDE myself - but I can make a half-hearted guess at their approach.

From reading the documentation with all of the updates - it is not necessary from JD Edwards perspective to implement any of the ESU's - in fact, they have certainly made statements to prevent implementation of ESU's if they do not directly address an issue in your implementation. Therefore this can be interpreted a number of ways. Primarily, and with common sense - JDE do not want to foul up your nice reliable implementation of OneWorld just because some Advanced Transportation function is not correctly working at a single customer in Iceland - they will provide a fix on the ESU to address the issue - and if you have the same issue, then you will probably be instructed to implement the ESU. However, the BAD thing about ESU's is the fact that JDE have started combining different support issues in a single ESU release. This means that although you have an issue, for example, with a Sales Update report not working - you may be instructed to install an ESU that "Fixes" the above islandic issue - but that inadvertantly fouls up a Financial application that you were working on. My opinion is that JDE support (because they do not truthfully understand how every customers implementation works) would like to see fewer permutations by "forcing" customers to implement updates - but the reality is that every customer uses the software differently, both from a data perspective and an application perspective.

If I modify a JD Edwards interactive application like P4210 - does that automatically mean that JDE will not support issues in the B4200310 function that the interactive app calls ? In theory JDE should support any issue as far as they can in their software - no matter how that software is being used - but I know that reality is far from perfect.

2. By following the directions in the guide - this becomes easier since you can use Visual ER Compare to compare an ESU code-fix against Development. It is good practice to only modify JDE code as a last resort.

3. see above. Solution is for JDE to stop combining SAR's that are unrelated. This is going to cause them (and has) more issues than the older system - hence they need to work out their direction here.

4. I personally do not see an issue in the way of implementing the ESU's to pristine. After all, the standard JD Edwards installation routines directly go against pristine as it is. If there is a drop-dead issue at a customer site - and JDE really, really want to test in a "pure" pristine environment - I don't think there is an issue because you don't build packages in pristine ! As long as the packages do not get built, then the central objects do not affect the runtime.

Thank you for the complement by the way. I am surprised at the lack of response for this thread - it seemed to me that I might have been going off at a tangent by creating this whitepaper and addressing something that may not have been an issue ! However, I have seen a large number of downloads on my website - so I believe that more people have the issue and less want to discuss it !

I hope all is going well - if you have any questions, please don't hesitate to contact me !

Jon Steel
Xe Upgrade Specialist
erpSOURCING LLC



ERP Sourcing
http://www.erpsourcing.com
[email protected]
 
RE: How to apply ESU\'s

JDE Support once told me that I should test a Pristine that had some ESUs in
it. I hollered back at them that they had an interesting definition of
"pristine"... Seems to me that ESUs would "soil" your pristine state.
They sent back an official looking paragraph that gave the JDE official
definition of pristine and it is a JDE environment with no custom code
modifications at all - but it can have ESUs in it.

So your chance of duplicating the environment that JDE decides to test your
issue with is similar to that of being struck by lightning seven times (you
know some guy in the forest service holds the record with that - he carries
around a pail of water just in case he has to dowse himself).



AS400 V4R4, XE+XU1+15ESUs, SP14.2, NT-SQL7 for CO
 
Re: RE: How to apply ESU\'s

I have found it to be most advantageous to download ESUs into their own environment and then transfer objects as needed.

We were getting terrible support from JDE in trying to resolve problems introduced with ESU's. We never intend to touch PRIST for a number of reasons, but certainly didn't want to corrupt any environment with large ESUs until we had a chance to evaluate.

We load all ESUs into ESU733 and test using ESU code against the BIKE data. If we find problems, we can easily have someone in Denver reproduce the environment. They can simply reinstall a fresh PRIST, then install all the ESUs we have installed, and have them reproduce the bug. Its worked well for us here.

We also use F9861.SIMSAR to flag which objects have no custom mods to them but have been modified by an ESU.

Paul

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