Best Practices - Modifying Objects

[Frosty the Coder]

A coworker and I got into a discussion concerning making mods.
In _this_ particular case, to P4210 (Sales Order Entry).

I had been trained to _not_ mod the vanilla.
I was taught to create a "55" and beat up on that.
HOWEVER, P4210 is HARDCODED called from many places w/in JDE.
Trying to find them all, and point at a "55" has proven unreliable, so our "new" method is to mod the vanilla.

(This is an "old dog, new tricks" point for me, and I'm finding it both difficult and distasteful to be changing vanilla.)

What happens to those mods w/ESU's and Upgrades?

I had been told that the (er) mods would be commented out and "sink" to the bottom of the code.
My co worker says that the mods (_all_ mods) are lost w/the ESU/Upgrade.

Is this the way it works?
We (developers) don't play w/the CNC stuff, so we don't know for sure.
Is there a "merge" that is being missed/skipped that would have "saved" our changes?

What about documentating the mods?
Typically, I put in a large "MODS HERE" block stating
what/where/when/why/for whom/etc.
This only works _well_ for ER mods.
Screen changes, DDs, overrides, etc, I've been listing (in great detail) in an .xls

My coworker suggested creating a "56" to save the original vanilla, and a "57" saving the _completed_ mods.
This would ensure visibility before and after the fact.
However, this means DELETING the "57" (and perhaps "56") each times mods are reapplied (and having to package the project to have the delete take hold).

How are others approaching mods?
Are there any KG docs that address this?
What else could I do to make this process more efficient?

TIA

Gene

PS - I'm going back and reviewing the "change management" threads that have already been posted in this forum.
I wanted to start this conversation independently of that search.

 

[Pon]

Gene,

I found myself in the same position as you earlier this year. I had a client who wanted to make dozens of changes to P4210. Because we found the same issues as you (regarding making a P55 version) we decided to mod the vanilla (Yuk!) After one month of development work my client decided that they want to do an Upgrade as well (from Update 4 to 6). I was told that the Upgrade would comment my code (Event Rules) and move it to the bottom. This didn't happen (I'm not sure why as I am not a CNC guy either). Fortunately, I saved a copy of my code in the Save location (as well as on another Fat Client PC). I was then able to use the ER compare tool (between the new Update 6 version of P4210 and the one in the save location) to put all of my ER back. However, this tool does not account for any form changes (i.e., grid columns or form controls added).

I believe that the proper way to do this would be to copy the P4210 application. However, I only know of one person who has successfully done this in OW.

 

[wlachenal]

I had to make the switch from creating "55" objects to modifying vanilla objects myself.

I worked on World for 3 years then switched to OW at release B731.

I have found that updating the Vanilla objects has its advantages and disadvantages. The biggest advantage is the use of ER Compare when performing retrofits. The disadvantage is the retrofit process.

For form and grid modifications, nothing beats having good documentation that will allow the person(s) doing the retrofits the ability to do them accurately.

Of course, ER compare makes life easier now than in it was in B731.

 

[Pon]

I tend to agree with Bill. With the World Software it was simple to make copies of the vanilla. With OneWorld it seems to be just as perplexing to make a copy as it is to retrofit everytime there's an upgrade.

Best advice is to just not mod the software. But, if changes are necessary, try not to make them too devastating. I found that by adding my logic to custom NERs that I was able to limit my ER changes in the vanilla (i.e., one line added to vanilla ER that calls my NER). Of course, this isn't always possible.

 

[wlachenal]

Pon

Great advice regarding the NER. I tend to use that method when ever possible.

 

[Larry_Jones]

Hi Gene,

Check out the thread "When is an R55xxx UBE needed for inclusion in an upgrade?" dated 11/07/2002 for a discussion on why modifying the vanilla may be preferable in most cases.

Regards,

 

[Loslo]

I'm agree with PON : modifing the standard is source of many problems with upgrade. In addition you coud generate interferences with standard...

 

[cdawes]

I'm not going to take a position for or against. I'll simply state that
there are cases when it's better to modify the original or 'vanilla'.

For example:
(1) There is a problem with the 'vanilla'. JDE comes out with a correcting
ESU. ESU's can not be applied to custom or '55' objects.
(2) The 'vanilla' is often hard coded in other applications so if you use a
copy of the vanilla then you also have to now modify the 'vanilla' of other
objects or copy those in turn......a very wicked spiral.

As for when to make a copy of the original? Well if the app is really simple
and other apps don't hard code the 'vanilla' version then a copy works well.

You shouldn't be afraid of changing the original. From my experiences
OneWorld ALWAYS (okay ~95%) preserves your code when you merge specs (ESU's,
Upgrades) if you do it properly. As a general rule if you add something
entirely new then OneWorld keeps it. If you change something or add code to
an area where there was already code well one of two things happen: (1) You
loose your code or (2) Your code gets commented out and moved to the bottom
of the section.

It may seem that option (1) is pretty bad but this is what you want in a
number of cases. For example if there were major application changes from
the spec merge (ESU, etc.) then you may decide to just redo it or merge it
using the Visual Event Rule Compare tool. Also sometimes the change is so
simple that it's often just easier to redo it.. In order for option (2) to
succeed someone has to tell OneWorld that the object has been modified. In
99.9% of all cases where someone 'looses' there code this is the step that
was forgotten.

JDEdwards in their ESU process defines one of the first step to applying an
ESU as marking changed objects or 'setting spec merge options'. Since the
CNC generally has no idea what has changed this step is often forgotten and
woops, bye bye $50,000 modification. I would suggest that this is a step
that developers could assist with. After you (the developer) change an
object go into the P98401 (Spec Merge Selection) and mark that object as
changed. This way if the CNC just happens to apply an ESU to this object the
code will be merged and not replaced.

Also look at P98881, P98700 and R9840D. It should be a shared responsibility
between developers and CNC/System Admins to ensure that all modified objects
are flagged and that no one looses code.

As for keeping a copy of the vanilla....it's already there - PRISTINE. One
thing that I do even after I flag all my objects is to reset the flag in
DV7333, apply the ESU and replace the object completely. I then use VER to
move my custom code from PY7333 to the updated vanilla object in DV7333.

The whole process works great for ER, hyper exits, etc. Unfortunately I
can't say the same thing about new custom form controls. If JDE added some
controls in their ESU I generally end up with a screen that's unreadable.


Colin






Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2

 

[BBritain]

I too have had the joy of re-incorporating mods in the P4210 for a particular client through 5 separate upgrades. The two biggest helps - well documented changes and ER compare tool.

One trick you might try - New buttons are not supposed to be commented out or overwritten. Try having a button that will never be seen or used and copy your code into the events of the button. If you lose the ER from the other events you could still perform a simple copy from the code in the button.

I know this is not a perfect solution, but it might help.

Ben again

 

[Frosty the Coder]

Colin (and others),

Thanks for the replies. We _had_ already come to the realization the we now mod vanilla. I guess that, with time, I will become accustomed to it (after all, I did learn how to drink beer, and that didn't taste good at first....).

Colin, I'm not having luck finding P98401 (Spec Merge Selection) to investigate this. Where is it found?

TIA

Gene

 

[Frosty the Coder]

Ben,

Nifty trick. I will try this and see if "supposed to" actually happens.

Thanks (again)

Gene

 

[Pon]

Now that's the best advice I've heard yet...drink beer. Yes, you'll need plenty of beer everytime "Upgrade Season" is upon you.

 

[michelle_perrin]

Another option is to
1) Copy P4210 to P554210 and make the changes that are required.
2) Change the original (P4210) so that it a) Calls P554210 in the Dialog is Initialised then b) Then Presses the Cancel button

We have done this with P4310 and it saved us changing all of the places that P4310 is called.

 

[Pon]

That's a great idea Michelle! However, you're still stuck with retrofitting JDE's mods into your new P554210 program during an upgrade. Not an enviable task.

 

[Frosty the Coder]

Did you have to create a complete set of versions of P4310?

Gene

 

[michelle_perrin]

Yes it appears as though we did have to create a complete set of versions for P4310. I didn't actually do the changes, however I imagine that existing code that calls P4310 is also setup to call specific versions

 

[cdawes]

Gene,

You should be able to fast path to the P98401. See if your CNC locked you
out of the P98401. Try to UTB to F9860 and see if 'P98401' exists under
SIOBNM.

Colin





Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2

 

[Loslo]

What Value did you pass to master BSFN like XT4311Z1I in the field "ProgramId" ? Because if you pass "P554310", for me you have a risk : in some BSFN, this field is hardcoded : if this is not "P4310", for exemple, the BSFN may not do some tasks... And when happen,it seems to be no reasons...

In add, some BSFN search processing options value from the P4310 (for some integration batch for exemple, which use the interactive like a reference)... Do you maintain the P554310 versions AND P4310 versions for this problem ?

In other hand, how do you retrofit JDE standards modifications to your specific program ?

 

[Frosty the Coder]

Nope. I had failed to consider FASTPATH.

Thanks again.

Gene

 

[michelle_perrin]

Loslo,

1) We pass 'EP4310" as the Program ID to F4311 Begin Doc
2) From my investigation it appears as though we don't have any versions
for P554310
3) We haven't retrofitted any JDE modifications into this application.

Michelle



Michelle Perrin
WEL Networks Ltd
Hamilton, New Zealand

[email protected]

B7333 SP11_3, SQL 2000