Promote vs. Apply ESU to Production

Suni

Active Member
I have always just applied ESU's to our production after testing in PY7334. However, this time I have SEVERAL ESU's that need to go at once, as well as some other update packages. I understand there is a way that I can just promote the packages and ESU's to production and then run a table merge and apply the special instructions to PD.
Are these the proper steps?
What about my customizations? I'm assuming this is the best way to get them promoted properly, correct?
Where can I look to find the proper procedures for doing this?
And then, how best to apply all these to the JAS server? Once all is promoted, should I just build a full package to deploy?
Thanks very much in advance!!!
 
Suni,

If you have multiple ESUs and other updates, I would suggest building a full package. Our standard practice is full package builds. Our rule of thumb is if more than 10 objects changed, build a full package.

Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
Yes, but I guess my question really is, how do I get my packages and ESU's to production?
 
Hi Suni,

If you install the ESU in PD, it will merge objects
"as they come from Denver".
If you modified those same objects in DV, then the DV
object will be different to the PD one.
This can mean only one thing : big problem approaching!
That's why it's better to install ESUs in DV : you
install them there, do any custom, retrofit or
corrections you need; then you promote your ESU with
all of the work you've done on it to PY and PD.
The only reason I see to install an ESU "as-is" in
PD would be for Planner ESUs, or to install them on JD.

My regards from sunny tropical Ottawa,

Sebastian Sajaroff
 
Apply them to the environment. I believe that promoting an ESU using OMW ruins the Net Change functionality for those objects.

For an explanation of Net Change functionality take a look at the attached document.
 

Attachments

  • 95187-Net Change.doc
    465.5 KB · Views: 1,083
I prefer to install the ESUs into all environments vs. promote to PD. I do DV
and PY first for testing and retrofitting. Then use OMW to promote any
retrofitted objects from DV to PY for final testing. Then install the ESU
into PD and only promote the retrofitted objects from PY to PD via OMW.
Package build.. and deploy.

The benefit being, I have historical records telling me what ESUs were loaded
into what pathcodes without have to use the OMW logs to give me the same
information if I used the other method.
 
Ooh, I like that approach. It sounds like the best of all worlds.
Thanks to everyone for responding so quickly! I want to do this this weekend, and am rather late in my planning...
 
Suni,

Treat the ESUs just like the normal development life cycle Apply them
to DV. Build a full package, test. Then do the same for PY, get
users to test. Then apply the ESUs to PD.

If your company has made any mods to the objects, then you will have to be
a bit more careful. In our case, we have an ESU pathcode. The ESU
pathcode is pristine with ESUs applied. We apply the ESU to that
pathcode. The developers do an ER compare. We take the new change,
add in our mods and work out the bugs in DV. The developers promote
the object to PY, I build a full package and users test. If everything
is good, the developers advance the objects to PD. I build a full
package and do the web gen.


Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
Suni,

I highly recommend that you contact the Oracle Global Support Center to obtain the abbreviated process for applying ESUs and ASUs to your system properly. ESUs and ASUs that contain control table merges and/or table conversions need to be applied directly to non-development environments to insure that these path codes receive the appropriate changes from the update.

The steps to apply ESUs or ASUs to non-development path codes without the running spec merge are very specific. We have been told that it is not important that the spec merge is not run. (Sorry for the double negative) The only advantage is the time saved by not running the process in the non-development path codes. If you do run spec merge, the objects you retrofitted with your modifications in your development environment may still be promoted through the normal OMW project promotion and will overwrite the unmodified objects in your non-development environments. In other words, by promoting the objects, you do not have to do the modifications again.
 
Ok, I hear everyone saying basically the same thing. Don't take the shortcut - do the full ESU applications to PD and then promote my custom applications and then build a full package. This will preserve the history within OW and ensure that everything gets done "properly". It works for me! I just wish there was a way to moosh all the ESU's into one big one and do it all at once.. ah well, I can live with this. Thanks again to everyone for the wisdom of your experience.
 
That is correct! I have to say that it is a very bad practice to "promote" projects to production this way. It is also not a good general practice to 'cherry pick' objects from an ESU unless you really know what you are doing and have the necessary skills and knowledge to test all affected areas. Oracle can supply a paper-fix for specific issues, but even those are not guaranteed to work...they recommend applying the ESU. In our case, we have more than one JDE data dictionary. If the ESU contains new or changed dd items, you could run into trouble if you missed those on promotion.

If you have custom code, it should be documented. I know that in Xe with ESU JD16916 and beyond, when you download the ESU you can run the Impact Analysis report against the included XML file. This report will tell you which objects are actually added, merged and replaced. You can also see at the bottom of the report the number of 'custom' objects affected by the ESU. If you select enough detail on the processing options for the report, you should also be able to see which control files are included in the ESU as well. Follow your ESU application up with a project which contains the retrofitted objects (if it is necessary - sometimes an ESU will include a SAR that makes your custom code change a duplicative effort.)

The Impact Analysis tool is actually quite handy. It stores the output in tables for later review and there is a nice 'Risk Ratings' tool which allows you to assign the appropriate level of risk to any given ESU, preferably before you apply the ESU to that particular environment.
 
Thanks for the Net Change document; it does clarify things a bit. By reading between the lines, I think it would be good practice to verify my customized specs get moved to production after I promote my customized project, after I apply all the ESU's to PD, before I build my full package, JUST IN CASE some date is wacko or out of sync somewhere along the line.
Ok, I'm ready now! Thanks!
 
I disagree. Spec Merges are probably the achilles heal of esu's and the only time spec merges are done is when applying esu's. Applying the esu with spec merge to Dev and then promoting the objects through to crp, testing and then promoting to production is my preferred method. If you have customized/changed objects being delivered, you should replace the object in dev, then do your retrofit on the object. The retrofitted object is delivered through OMW promotion.
 
So what would be the steps to apply the ESU to the next environment, if I did not do the spec merge? Would it be the same as applying it to the original env (DEV) but somehow excluding the spec merge?
Could you please list the steps?
Thanks!
 
You want to know how to apply an ESU to an environment without the spec merge running.

There is an option in the advanced form exit to turn off the spec merge. I had made a screen shot of this sometime back, so go thru the attachment
 

Attachments

  • 95368-Apply ESU without Spec Merge.doc
    87.5 KB · Views: 141
If an ESU/ASU is not applied to PD, it would have no chance to apply UDC's, create new TBLE's or indexes. This would make the system inconsistent.

It's not really a matter of preference - the ESU's must be applied to all Environments.

If there's any reason, i.e.: any affected objects were retrofitted in DV after the ESU's application, then such (or all, if you wish) objects can be promoted _after_ the ESU had been applied in PY and PD, but not instead.
 
Alex is correct. If you run the spec merge in your development environment and then promote the objects to non-development environments, you may apply the ESU to non-development environments without running the spec merge. That is the ONLY step you may skip. Unless you KNOW there are no tasks in addition to the spec merge, an unlikely scenario, you MUST apply the ESU to all non-development environments.
 
Back
Top