Question about deploying an ESU and package build/deploy

We are on E1 9.0, tools 8.98.42 and are deploying our ESU for 1099s for this year.

Not a lot of ESU experience, but we have at this point downloaded the 1099 ESU for this year, 22130, and have deployed it to DV900 using the ESU app on GH9612. So these changes are now installed on our DV900 environment. We do not have to actually build a package and deploy it beyond what we have already done, at least as far as DV900 is concerned, is that correct?

Then after we have tested, we would just deploy to the other environments as well using the ESU App on GH9612. There would be no need to actually go in and build a package in Package Assembly, and then deploy it. Am I understanding this correctly?

Any input would be appreciated.

The ESU install process merges the code to central objects but you still need to build and deploy those changes to your server for that environment that you installed to.

Thanks, undestand. However, a couple of futher questions. Now that we have applied the ESU to our DV900 environment, I see an OMW project JL22130 in OMW. This has all of the items form the ESU.

What is the standard practice here. Would someone typically create their own OMW project. Add the items that are on the ESU project to their OMW project and build and promote from then on?

Or can the OMW project created for the ESU, JL22130, be used. If so, then I do not appear to be able to move the status of the project from 11 to anything. Not sure what is preventing me from advacning the status.

We use the Project created when we install the ESU. Then we test and promote the same way we do any other OMW project.

(note we do not use HR so this isn't in reference to the 1099 ESU in particular)

Tom

That makes sense, thanks. However, for the OMW project that was created in this case. JL22130. It is at status 11 and does not seem to want me to be able to advance the proejct to 21, and from there we would move it to 26.

When I highlight the project, the Advance project button is not available. ANy thoughts?

If you're not really making any changes to the objects, just apply the ESU to Prototype and/or Production and skip the promotion process. What we do is apply the ESU to PS, DV, and PY. We have a form change so we checkout the one object in a Project called 1099s and make our changes and advance the 1099s project to PY. Build package in PY using the ESUs assembly test. If it passes testing, we then apply the ESU to PD, advance the one object to Production, then build the PD package.

Thanks, MagarG, thats what I thought too. But when I talked to Oracle/JDE support they were very specific that when you applied the ESU, it was just like moving the objects to the check in location. But they said you still needed to build and deploy a package to the different envrionments. I not sure I know enough to disagree with them. But your suggestion makes sense too.

I would definitely apply the ESU to your DV environment, and when you have tested it out, then apply the ESU to your PY and the PD environments. The reason to apply the ESU is that it may do other things to your environment besides merging object specs -- it may perform some inserts or updates to control tables (like UDC's or menu's).

jimmymac,

You will have to add the person doing the promoting to the project. This should be done using your normal promotion process. For example we have only one group that can promote to 38 (in prod).

Tom

Thanks for your input Dsauve and Tom. But it still seems unclear to me as to whether or not I need to build and deploy a DEV package in addition to what I've already done, which is apply the ESU to DV900 using the ESU app on GH9612. Then to promote that package onto PY and PD.

My recollection last year which was the only time I've done this, we only did the step to deploy the ESU to DV900, PY900, and PD900. We never actually moved the OMW project with those changes. Is that required also, or is just deploying the ESU from the GH9612 app or Change Assistant sufficient enough.

As long as you don't change any of the ESU's objects in DV, then applying the ESU to PY and PD will give you the same set of objects as if you had just promoted the project; HOWEVER, applying the ESU will make sure any other updates (like control table updates) are done in PY and PD, too.

Don't forget to build an update package with the changed objects (or a full package if you prefer).

The project created by installing the ESU is optional (you can tell it not to create this project, which is what we do).

One other note is that if you apply the ESU to each environment, you need to make sure that have no mods in anything touched by the ESU.

I'll admit not being at work, I forgot that we do do the special instructions when we promote the ESU.

Tom
Tom

[ QUOTE ]
Thanks, MagarG, thats what I thought too. But when I talked to Oracle/JDE support they were very specific that when you applied the ESU, it was just like moving the objects to the check in location. But they said you still needed to build and deploy a package to the different envrionments. I not sure I know enough to disagree with them. But your suggestion makes sense too.

[/ QUOTE ]

Yes, you still need to build a package. I looked back at this years 1099 ESU. There are a couple of other things to do post install.

1) ASI - Automated Special Instructions. This will apply any DD Glossary and UDC descriptions for you using the P96472. This is an xml file that gets put on your deployment server (ours is in \E900\SpecialInstructions) when you apply the ESU. I sign in on the DS and then sign in to DEP, DV, PS, PY, and PD and accept the changes.

Others - is this correct method? Seems convoluted that you have to log into each environment.

2) Do any Special Instructions - SAR 8966150 we already completed from previous years. This year we had to do SAR 17573005 and generate the F04514WF table. The other SAR, 17987820 was for BI Publisher that we don't use.

Make sure to check the reports for Processing Option changes. Sometimes they add a new field, etc to the PO template.

Jimmymac

The standard process that I use for deploying ESUs is:

1) Download the ESU with change assistant.
2) Save the ESU is a consistent, organized set of folders on the deployment server. We always set up a JDE Software updates folder, and then set up sub folders within.
3) Extract the ESU
4) Run Software update impact analysis to check for any objects that have been modified
5) Send off the reports to the customer to inform them of the impact of the change.
6) Apply the ESU to pathcodes in this order:
PS, DV, PY, PD
7) Build a package for each pathcode. Our general practice is to build a full. ESUs often contain data dictionary changes that may have impact above and beyond the objects within the ESU.
8) Depending on the client (live client vs pre-go-live) we will add in various testing checkpoints
9) Change Management - there is always a change management step before the esus are applied

- Gregg Larkin