Copy Prod Data to DV environment

List,
We are on XE/Oracle. Our IT team tells me that they can't copy the prod data to dv because of the custom objects that have been created during the last couple of years and this will take couple of weeks to copy the data back to DV environmebt. Every time we have to test the objects in PROD as we do not have the latest data. This is killing us. I really do not understand why the data can't be copied to DV. Can some body advice...

JDE OneWorld XE/Oracle

Your group is mixing metaphors...data tables consist of Control Tables and Business Data; objects are Central Objects and Versions, etc. You refresh an environment's data without touching objects, just as you update objects (via package builds) without touching the underlying data of an environment. We have oodles of custom reports and screens, but we also perform data refreshes often.
I have no idea what your folks are talking about...

This should be relatively easy to accomplish - though it might take some time (and usually is required to be performed while production is offline or based on an offline backup). There is no reason why you cannot copy data from PD to any other environment.

As for their argument - its completely bogus even if they were talking about objects ! Objects are promoted from DV ->PY ->PD - therefore any object in PD is naturally in DV as well, UNLESS they've done something very naughty and modified objects directly in Production (so why even HAVE a DV/PY environment if they've done that !)

You need to replace your IT team with people that actually help the business - not people that try to hinder it....

I'm glad Jon (one of the big CNC guns in this space) weighed in on this. Normally I do not take up the thread on purely technical issues such as this because there are many who are more qualified to respond; however, the line of hooey that you were being fed was so off base that I had to respond.
As Jon said, unless the boys (?) in the back REALLY bollixed things up, data and objects are separate parts in the JDE box. There are a lot of things we don't know here, but this does not smell right...

Really can't be any easier than restoring from your latest full backup, thi s way it only impacts development folks who really want it anyway and will likely pay any price to get it. Clear your DV Data library; Clear your DV CTL library. Restore your PD CTL to the cleared DV Library; Restore your P D Data to your cleared DV Data Library. The only impact is on any menu dev elopment that may be going on since that resides in DV CTL. Go into the DV menus and tweak the headings to reflect the fact that they are now DV and you're done. This is for an iSeries platform and other platform procedures may vary but the concept is the same. It's already been said most eloquen tly; Data and Applications are separate animals and one does not have to im pede the other. Developers should not test with old data, most unforgivabl e. Just takes time, coordination, and cooperation!


From: [email protected] [mailto:[email protected]] On B ehalf Of jdee108
Sent: Thursday, January 03, 2008 11:10 AM
To: [email protected]
Subject: Copy Prod Data to DV environment

List,
We are on XE/Oracle. Our IT team tells me that they can't copy the prod dat a to dv because of the custom objects that have been created during the las t couple of years and this will take couple of weeks to copy the data back to DV environmebt. Every time we have to test the objects in PROD as we do not have the latest data. This is killing us. I really do not understand wh y the data can't be copied to DV. Can some body advice...

JDE OneWorld XE/Oracle

Hogwash! We refresh business data to our PY environments regularily. I see a whole mess of bad practices listed in your post, as imposed on you by your IT staff.

“Our IT team tells me that they can't copy the prod data to dv because of the custom objects”

Business data has nothing to do with application code. They are in totally different tables and databases. CNC 101, an environment = business data + application path code. You can have multiple environments sharing the same application code but different business data. In my shop, we have 21 environments, 11 of which are different variants of PY, all with different business data.

“this will take couple of weeks to copy the data back to DV environmebt.”

Several weeks? All they have to do is make a copy of business data prod (which should be happening nightly as part of your backup) and use that to replace business data DV or business data PY. Yes, they will need to change the database owners when they do that, but any DBA worth their salt can do that in their sleep with one mouse tied behind their pocket protector. Our data refreshes take less than a day.

“Every time we have to test the objects in PROD as we do not have the latest data”

You’re testing objects against Prod? Bad practice. The developers should be doing the first round of testing in DV. Then promoting the objects to PY. You should do your testing in PY, and then the code should be advanced to PROD. If that methodology is not being followed, then your IT people need totally revamp your JDE infrastructure.

Please don’t take this as a personal flame, but your post raised a whole lot of red flags.

Gregg Larkin

Thanks a lot guys. I appreciate your replies. I have verified with my IT team and it looks like they have created a lot of 55 objects and made some changes directly in few objects in PROD. That means, the objects that are in PROD are not in DV/PY or not same in DV/PY. This is big concern and we have to deal with this. Now We need to get all the objects and Data from PROD and replace DV with those. I am not sure how big that effort is going to be. Can you please advice..
Thanks a ton in advance..

You should be able to assemble a list of objects that have been modified in OMW. Look in the projects, do a visual ER compare on specs in DV compared to PD, where the specs are correct in PD, do an advanced get from PD to DV; after all objects match in DV and PD, do a full package build in DV, and copy your PD data to DV. Your specs and data should be aligned.

Nothing like using production as your test environment. Wouldn't this mean that you also have suspect PD data?

After you clean up this mess, don't allow developers to log into PY or PD. Follow the software development life cycle that is out of the box EnterpriseOne. Who let a developer go into PD and then allowed those objects to be built in PD? Who is running your shop?

Yuck, they just boxed themselves into a corner. They need to clean that up. All of the objects that were modified directly in PD need to be demoted to DV. They probably created versions directly in PD. Those will need to be demoted as well.

I would pretty much consider your PY and DV environments to be garbage. I would uniformly push everything in Prod down to DV. When that is done rebuild your DV package (full package, not an update) and get that out to the developers. Then promote everything up to PY, rebuild that package. Then promote everything up to Prod, and rebuild that package. That will bring you back in synch.

There are some ways to make that code change happen in bulk, but those methods are not documented well and require a lot of expertise. No offense, but if you have that expertise in house, you probably wouldn't have had the mess. You may want to look for an outside consultant to assist you with that. I know that some guys specialize in cleaning up JDE systems. Yours is in bad shape.

You will need a stronger change control process put in place to make sure that this mess doesn't happen again. Your IT manager and developers need a wake up call. They created a mess that is going to be expensive to clean up.

I will suggest these to the IT team and escalate the issue asap. Thanks a agaian lot!!!

Whilst it seems that you have resolved your issue can I interject one caveat. PD and DV (and PY) may in some cases be different in ways that will not help a copy of data from PD to DV even when people are behaving properly. If you are in the process of a change that modifies an existing custom object (or in a less controlled shop a standard object) and that change hasn't made it from DV through PY to PD then the objects will differ causing potential problems in or after a data copy. This will also apply if you copy UDCs from PD to DV and you have extra values in DV for in hand developments.

That aside we reasonably routinely copy from PD to PY using the standard UBE R98403. A DB level data copy is faster but requires a DBA to intervene rather than CNC.

This is exactly has happened. Objects were changed in PD directly and they are not in DV. The current DV environment objects are not the same as PD. This is making us to test and validate in PD.Please advice if we need to take any other precautions.
Thanks again..

There are documents on the Knowledge Garden that go through the steps of refreshing entire path codes. That may be quicker to get all your objects back in sync between the path codes.

Are you firing your CNC team ? Because obviously they totally allowed developers to walk over themselves and allowed production to become development. Hopefully justice will weigh in and someone will be fired from your organization.

Not to rub this in - but almost every single client I have ever worked with has at some point suggested a "quick fix" by just modifying something "small" in production. Well, this post just highlights what happens when you do that. I know it seems obvious in hindsight - but you wouldn't believe the battles I have had to fight with developers and business analysts in the past - my guess is that your CNC guy is a "yes man" or woman - and are allowing the business to ride roughshot over the architecture...

Just demote the objects from PD to DV - sod the developers who are modifying crap in DV (its their fault anyway) - and restore the data from PD to DV. Shouldn't take more than a day's work - certainly not "2 weeks".

All your inputs are going to help me. I am not going to ask the top management to take action on anybody. I believe there must be reasons why the CNC did like this. As everyone suggested, I am going to enforce the change management strictly from now on and get the developers hands out of PROD immediately. I am going to get a list of all the modifications that are done in PROD and demote them to DV and build a full package in DV and promte to PY and build a full package in PY and then promte to PD. My greatest worry is, what if they miss out any object that is modified in PD. When the objects are promted to PD, it will be replaced with incorrect code and the business will be in trouble. Is there any fool proof way that we can make sure to do this right. I know I am asking too much. But this will help us a lot..I appreciate your advice.

I have searched the knowledge garden and unable to find the documents related to refreshing the path code. Coudl you direct me the link..I appreciate your help..
Thanks

"My greatest worry is, what if they miss out any object that is modified in PD. When the objects are promted to PD, it will be replaced with incorrect code and the business will be in trouble. Is there any fool proof way that we can make sure to do this right. I know I am asking too much."

No, you are not asking too much. I think that the list pundents have pointed out that allowing changes to be made directly in Production, and forcing users to test new code in Production is a bad practice. We have given you your ammunition to fix the issue.

I can't give a fool proof method, but I would advise that it is far better to err on the side of caution. Don't be shy about pushing code down to Dev. You want foolproof? If it's a 55 object, push it down. If it's a modified version, push it down. If your developers have modified Oracle objects, push it down.

By the way, have you asked that question? Have they modified core objects, or did they make a copy first, and then make a 55 object out of it? That's a question worth asking.

Gregg Larkin
North American CNC, Praxair, Inc.

Thanks again. I already have checked with the IT team and they have done both.
1. Modified few standard objects
2. Copied the standards objects to 55 objects and made changes in that.
I have asked them to prepare a list of objects that are modified and document it. so that at least in future it would be useful.

I don't have anything to add to what has already been said, but I thought it would be a good idea to summarize it here.

The first thing to do is stop the madness - don't allow changes to be made outside of the DV > PY > PD process any longer. This might be easier said than done, but it's time to start doing it right.

Then get an idea of how big this problem is. It sounds like your already doing that. Everyone needs to understand how the objects are conflicting in these environments.

Make a plan for correcting the problem. Is it only a few objects, then maybe it can be corrected manually. Otherwise, a complete rebuild of DV and PY from PD might be the best approach. Personally, I prefer knowing for sure and would refresh the DV and PY environments (path and data).

Then prepare to execute (the plan not the staff). Development will have to be temporarily halted or it will be lost. But then, the developers will probably just ask to make their changes in PD so they won't have to stop and they will be copied during the refresh

Hope it goes well.

I'm for executing the staff...