ESUs and Retrofitting custom code

[johndanter]

Hi guys,

Can someone give me the standard process for applying an ESU to an already changed base object. It's ok for PY, but we come into issues when we try and go higher

I do the following:
1) Save the changed code.
2) Apply the ESU to DV.
3) Retrofit out code back in
4) Apply the ESU in PY
5) Promote my OMW out to DV and up to PY

The issue I am facing is I want the F9671 tables to be updated with the application of the ESU however when we apply the ESU in a higher environment, E1 is changing the last modified date.
So when the code comes up from my OMW project, the dates prevent the OMW change from applying.

Is there any way to update F9671/72 etc but not actually change the OMW last change date.

We are told we need to check out/in the object of interest after we apply the ESU to a higher environment. Makes sense to change the date, but I've never had to do this anywhere before.

Is it the spec merge option I need to do this correctly?

I did post the question here:
http://www.jdelist.com/vb4/showthread.php/50532-Retro-fitting-mods-to-base-objects-after-taking-ESU

Thanks

John

 

[David Robertson]

We only apply ESU's to DV, retrofit and surface test, then promote to PY, build, deploy and test, etc.

1) Save the changed code.
2) Apply the ESU to DV.
3) Retrofit out code back in
4) Promote up to PY

EDIT: by that I mean, we find it better to utilize our standard change control, and apply the ESU to DV, and then promote the ESU through the pathcodes as a normal mod/fix. In this way, you can refit any mods without having to game the system, and test properly.

Alternatively, you would need to check-out your code at a time after the ESU was applied to PY, and go into edit and do something to enable the save button. Checking out and in doesn't update the last changed time stamp for OL objects, unless a save was done.

 

[adeel]

We do apply ESUs to each environments, the main reason is that if you perform object promotion method from DV and so on, the non object librarian will not be updated. e.g below:

Data dictionary items
User defined code items
Workflow objects

So here I would suggest. I don't know why you save your code there might be a design layout change in the object with condition etc.

1. Apply ESU in DV (make sure take ESU objects, no merge).
2. retrofit your code in DV.
3. Once you tested.
4. Apply ESU in PY.
5. promote your objects from DV and PY

Thanks
AD

 

[johndanter]

Thanks guys but the issue is as the object in PY after applying the ESU now has a greater changed date than my retrofitted DV object

....OMW will not make a spec change.

What are you guys doing differently to our CNC support that enables you do what you explain above. As that IS exactly what I do here.

As when we go to PD, We do that at 4 am. I'll be in bed. I can't wake up and checkout save checkin.

There must be a simpler way or something they are missing

 

[DBohner-(db)]

I've always been a fan of the process you are using, John.

My question - are those dates a real problem, or just something that's hesitating our focus?

When you follow the predefined process, go into OMW, Select and Object and you look on the Right side of the screen's "News Status" tab - what dates are displayed? Are the dates that the ESU was applied, the date that the object was promoted or? I've always thought they were the dates from the F9861 - Last Changed Date. If I'm correct - where does the importance of the F9671/2 tables come into perspective?

The F9671/2, I thought, are the ESU tables - they maintain the dates the ESUs were applied - not the last update to the object (Please, as always - SCHOOL me when I am Errant)....

Thoughts?

(db)

 

[altquark]

The HTML is driven off the Object Librarian tables (ie, F9861 etc). But the F9671/2 are the tables behind the "Software Updates" application. So - you are correct.

However, a promotion (DV -> PY) compares the Last Changed Date in the F9861 from the PY to the DV - WHICH, if the ESU is applied in PY just prior to a promotion from DV to PY would be a greater date, hence the need to checkout/checkin in DV to force the date to be the latest date.

There really is no easy way to achieve what you want here. The CNC is doing the right thing in this example, because the company wants the F9671/2 tables to be correct to show that ESU's have been correctly applied to all of the environments. Doing this early in the implementation is easy, but once you have code that you're retrofitting, then it becomes more difficult. The only other way is to "spoof" the F9671/2 tables, ie SQL them to reflect that the ESU was really applied through a promotion from DV to PY.

The issue is, of course is that the F9671/2 tables don't REALLY identify if an ESU has been applied - they're just an audit. When an ESU gets installed into DV, then the table identifies that fact, but if the ESU is promoted up using OMW, then the tables don't identify that the code IS in PY or PD.

Now, some will say "aha, you SHOULD install the ESU 'properly' because you want DD and UDC's" - but thats not really true. Those should also be promoted as part of any project - if a DD or UDC is missing, then it should be captured in testing at least. Just because the code comes from JDE, doesn't mean you shouldn't fully test the code in your implementation.

So. There are several ways to do this.

1. Install the ESU into each pathcode prior to each promotion, and check-out/check-in the retrofitted object to ensure the last date is the latest date and will guarantee to overwrite the destination (which I believe your CNC is already doing). This results in correct records in the F9671/2 and correct objects in each pathcode
2. Install the ESU only to DV, then retrofit and then promote. This will ensure the ESU is in further pathcodes, but the F9671/2 are not updated, and will require a direct update (like SQL) to ensure they reflect the ESU has been installed
3. SAVE the original object. Install the ESU directly to DV, PY and PD. RESTORE the original object in PY and PD. Retrofit DV and promote. This will mark the F9671/2 correctly, and then the retrofitted code will correctly promote up. There is a slight increased risk with this option, in that there may be objects that are inserted into PD that may not be SAVED ! Be VERY careful !

Hope that helps !

 

[DBohner-(db)]

So, the problem is - that the Dates of the F9861 are more-recent than the dates of the objects being promoted into that environment. Now that it is re-explained, I do recall the issue.

I'd rather push that as a bug, to Oracle - and let them find a solution to this "Old Problem"...

With the more-recent ESU processes - are some of the Special Instructions accomplished by the application of the ESU? If yes - then it is best to apply the ESU to each environment (as is in the original steps). Right?

Sorry to hijack - but knowledge is food!

 

[altquark]

The REAL reason here is why oh why is it that JDE had to put into their code "if the destination date is newer than the origin date, then write to the logs the error and skip the promotion". There are SO many times when this can happen - ESPECIALLY if some developer has their workstation date set incorrectly ! PLUS it LOOKS as if the code got promoted from OMW - only when you look at the code (and the audit logs) do you find out that the code DIDN'T get promoted ! If the CNC is trying to promote from one place to another, then why perform this redundant "stoopid" check? ! Someone at JDE back in the late 90's thought this might be a good little check - that person would probably be the first individual i'd put against the wall when the JDE revolution comes....THOUSANDS if not MILLIONS of lost testing hours, redeployments and repackaging because of that stoopid check over all the customers over the past 15 years...

Anyhows. If they got rid of that one little check when projects were promoted - or made it configurable - then there would not be an issue. Thats the only thing that needs to be fixed. Who wants to co-sponsor a Quest bug ticket ?

 

[adeel]

We use change assistant for ESU and most of the special instruction is taken care.

Check in and Check out the object will help to promote the object in your situation as stated above, my understanding was that when you change the status of the project from 21-26 or whatever the setup you have will do the job. example you apply ESU in PY on May 19, 2015 and change the status on the project DV to PY on May 20, 2015 which will update all the objects date which it does. I guess this need to report to Oracle. (Good to know).

I never encounter this situation as we have small customization and we do the retrofit when the ESU go to PD.

Thanks
AD

 

[BOster]

Anyhows. If they got rid of that one little check when projects were promoted - or made it configurable - then there would not be an issue. Thats the only thing that needs to be fixed. Who wants to co-sponsor a Quest bug ticket ?

Better yet would be to quite using the damn date/time as a "version" number. Just have an internal counter for every object that is the version number. This number would get incremented every single time an object is saved (make it a 64 or 128 bit unsigned integer if you think an object may be saved more than 4 billion times). This version number would be part of the object specs just like any other object property so that it would be incremented locally and get checked in with the rest of the specs when the object is checked in.

When an ESU is applied it would re-set the version number for any modified pristine objects just like it copies over the rest of the specs. The act of retrofitting mods to the object would start to increment the version number as the object was saved and ultimately checked in. Then when the object is promoted, the retrofitted object would have a higher version number than the ESU version and would over-write the ESU object. In this way you can keep the check in place but the version number is not tied to a date/time stamp which has proven to be problematic. If this would done it would pretty much require that ESUs be applied to all environments instead of just applying to DV and promoting etc. That is unless there was some way on check-in or developer controlled way to "set version to 1 higher than all known path codes" or something like that. Probably other problems as well, but I think in the end it would be better than date/time.

 

[DBohner-(db)]

Anyone brave enough to submit this thread to Oracle Development, through Quest ;-)

 

[altquark]

Better yet would be to quite using the damn date/time as a "version" number...... Probably other problems as well, but I think in the end it would be better than date/time.

This is an interesting idea. In effect, a single repository for all objects (no matter whether they're DV, PY, PD or whatever). When P550101 is saved the first time - its entirety is saved as, say, P550101_01. The developer can then check-out Version 01, and save it again (which point it becomes P550101_02). Developer 3 checks out the object and saves it as P550101_03. If there are issues with testing versions 02 or 03, then 01 can be restored.

Now, as for promotion, any object can be "promoted" - but instead of the entire code being transported from one place to another, instead a "pointer" is written, identifying what is the correct "version" that should be used. So, in our example, P550101_01 might be promoted to PY and PD, but P550101_03 is "current" in DV.

The only drawback is that the single spec database ends up with every version of every object ever modified. However, I personally believe that it would still be a lot smaller than the current situation where every object is stored n times, where n = the number of pathcodes (currently a minimum of 4 !)

This entire method would not be that big of a step for JDE to accomplish. It would dramatically reduce times for promotion and, I believe, package builds. It would also provide a proper method for version control, since any object can be "restored" to any point in time. I also think that applying ESU's and even upgrading would be substantially easier and more efficient with a single central object repository. Imagine just "synchronizing" your object stack with the "release" version that is available from JDE - certainly a LOT more efficient than applying "fix current" by installing thousands of individual ESU's.

Lots of ideas in this thread revolving around this....

 

[johndanter]

Wow, thanks for all the replies guys.

I'll have a better 'note taking' read later

Glad I'm not the only one.

 

[Chan Rana]

I have normally seen it applied in DV like normal projects, perform the impact analysis,retrofit etc. and then promoted to other environments for testing before moving to PD.

 

[johndanter]

I've now read all the replies, thanks guys!

I've been thinking about some of the approaches suggested here.

One of them is to save the modded object off apply the ESU to ALL Envs, retrofit the modded code back on top and then promote the OMW Proj.

Now that would work.
However.......PROD will have a period of time where our custom code is not in PROD. Depending on the change, this could be catastrophic.

In future, I'll see if this approach can be used, but I feel it's not suitable for every custom mod we may have.
Frequently called EDI UBEs for example. We can't afford 1 minute of our custom code not being used in PD.

Thanks all for the replies. Keep them coming if a light bulb goes off

 

[SKH]

John,

We're upgrading to 9.1 currently. Our strategy for our 9.1 meant we created an ESU environment where all ESUs are installed. Changes are retrofitted into Dev, where the ESU affects modified objects and the changes promoted up. Possibly overkill but works well for us.

Regards,

Sanjeev

I've now read all the replies, thanks guys!

I've been thinking about some of the approaches suggested here.

One of them is to save the modded object off apply the ESU to ALL Envs, retrofit the modded code back on top and then promote the OMW Proj.

Now that would work.
However.......PROD will have a period of time where our custom code is not in PROD. Depending on the change, this could be catastrophic.

In future, I'll see if this approach can be used, but I feel it's not suitable for every custom mod we may have.
Frequently called EDI UBEs for example. We can't afford 1 minute of our custom code not being used in PD.

Thanks all for the replies. Keep them coming if a light bulb goes off