Better Performance a problem for JDE?

JMast

Reputable Poster
Hello All,

We upgraded from SQL 2000 SP23_K to SQL 2005 SP_ZA1 in February. I posted earlier about a issue we are seeing in SO Entry. I am not interested in rehashing that in this post, but I will give you some background for the real question.

The failure is on the Customer Master MBF when it pulls open invoices for the Sold To for a credit check. It is particularly odd since it only seems to be affecting one customer and only about 10% of their orders. The only other similar error is occasional failures of R42118 which allocates material to Sales Orders. Our focus has been on the SO issue since that is most disruptive. I started the case with the Service Pack group who flipped it to the Distribution group. Oracle has an ESU on the Customer Master MBF proposed as the solution.

My colleagues here are having a hard time comprehending how a significant upgrade in performance at the service pack and DB levels could cause a failure in an MBF that did not change.

So, the question to the experts: Does this often happen in JDE where a problem is created by a technical upgrade and the fix is to the application code? Any high level explanation why?

One reason this is so important is that this system is very stable but really has not been maintained from an ESU point of view, so applying the small ESU proposed by Oracle will require baseline ESUs in the Distribution module requiring much testing and redoing of some mods.

Thanks for any insight,

Jer
 
Hi.

We also had major stability problems in the past because a bad ESU application policy and also har to reaplicate several ESUs included all baselines forcing the replacement of all objects to have the system stable again.

So I advise you to make this clean up one time and be sure that from since then you apply ESus in a consistent way.

We aonly apply them when a problem arises, and only upgrade planner or apply service packs if a SAR that we need to fix an error mandate this, but we now apply always the full ESU affected objects and not only the SAR related ones like our initial consultants (from JD Edwards itself) told us to do.

Hope this helps
 
Hi Jer,

The problem does sound data related - if it only occurs for 1 customer and only on 10% of their orders. The good news is that it seems to be easily replicated. In answer to the questions from your colleagues the only response I can give is that a service pack/db upgrade can sometimes lead to different result sets being returned which may or may not be the issue. It sounds like it may be a known issue if Oracle are suggesting you take an ESU, or it might be they just want you to try the ESU to rule that out.

Are you able to a) easily repeat the problem and b) produce a debug log for it? I know with it being a bsfn these can be difficult to catch logs for. An alternative would be to run a SQL Profiler trace to try and identify anything on the DB that might have changed, would your DBAs be comfortable running a profiler trace?

Sorry I can't be more specific than that.

Jack.
 
Jer,

to answer your question.

Yes, service packs may affect application behavior. This is true of any software / vendor. Whether it be Oracle, Microsoft, or Joe's Software house.

Almost all software today is built like a house of cards. Upper layers are VERY dependant on lower layers.

Any layer of software is dependant upon successive lower layers behaving in a expected and consistent manner. Any time change is introduced at a lower level, whether it is an Oracle/JDE Service Pack or a firmware upgrade to your server's disk controller, there is a potential risk of negative impact to software operating above that level.

To be more specific to JDE. Yes, Service Packs, Tools Releases, whatever you call them sometimes affect application behavior. We can argue that if the software change was properly done there would be no negative impact. However this is akin to arguing that logically - software should have no bugs.

Anyway, this is why you should always test critical processes against a new SP or TR in a separate sandbox before applying to production.

Regards,
 
Not a direct answer to your question but there are SARs for this issue and it has reportedly been fixed.
B4200420 CreditCheckProcessing taking a large portion of the total processing time.
The 2 SARS are
8.12 SAR:8736258
9.0 SAR:8743036.

Thanks,
Matt
 
clmates,

Thanks for the reply. Yep, we are in that situation. The previous theory has been "if it ain't broke, don't fix it". My approach would be similar to yours and periodically take baseline ESUs. So, we will likely have to go through a "mini" upgrade to get everything up to speed. Hopefully, some of our mods and nusiances will go away...ok, I can dream can't I?

Jer
 
Jack,

Thanks for the advice. Unfortunately, it is not reproducible. In fact, the vast majority of them go successfully after JDE is restarted on the computer. Catching a debug is not feasible since there is no way to tell what order will blow. All the orders that I have debugged have been successful the first time.

SQL Profiler was how I figured out the problem. I have a profile from a blown order, the profile from the same order successful and a debug log for that order successful. I matched up the code in the traces to find the spot where it blew. I then matched the time stamps on the successful trace and successful log to find the JDE MBF.

There is no rhyme or reason I can find in order size, ship to....in the data.

Jer
 
Larry,

I like your point that this is not just a JDE thing. I will use that. I think mostly people want to avoid the massive work to apply the ESUs and are hoping that going to Service Pack 24 will take care of the problem. It might, but then again, it might open other holes if we don't get our application code (from 2002) current.

In fact, would I be correct in thinking that SP 24 could cause more problems given the architecture changes that begin to show up in 24 even though it is "backward compatible"?

We did do testing in our Development environment which had the upgraded DB and SP, we just may not have tested that customer and we didn't have the same vloume of activity on the server. Even if we did, a 10% failure rate could have slipped through quite easily.

The trick here is that we can't simply "roll back" to a lower SP since we have moved from SQL 2000 to SQL 2005, so it looks like we are left with moving forward with ESUs.


Thanks for the thoughts,

Jer
 
Matt,

Oracle has recommended a paper fix which I think is similar to those SARs. We are on ERP 8.0, so those numbers don't apply. They seem to revolve around larger systems than ours, but we would definitely try the fix.

Thanks for the tip,

Jer
 
Hi

[ QUOTE ]
clmates,

Thanks for the reply. Yep, we are in that situation. The previous theory has been "if it ain't broke, don't fix it". My approach would be similar to yours and periodically take baseline ESUs. So, we will likely have to go through a "mini" upgrade to get everything up to speed. Hopefully, some of our mods and nusiances will go away...ok, I can dream can't I?

Jer

[/ QUOTE ]

Yes, you can dream :-D, but be sure to check not only this problem before you get all to production, check out the entire application flows that you use in Financials, Sales, Purchasing, Manufacturing, etc. This procedure will be as you said a mini upgrade, and all your processes could be affected.

Also is a good procedure to check for open SARs regarding the main objects you use P4210, P4310, R42565, etc to see if there is any critical bug still open for your version that you'll need to check specifically to your process


Regarding modified objects, we had a folder for modified objects each with its own document explaining changes, with screen captures (if we changed any graphical element in forms), and with al the code changes (code listing of all event rules affected and highlighted the changes), so when we need to apply an ESU, the first is to mark in the ESU paper the changed objects then apply the ESU to our DV environment and reapply changes using ER compare when possible and if not by hand.

Is not as hard as we think when told to do this, the only complicated object for us is R42565 that we had changed and also had 2 copies (delivery notes and sales order and quotes print)

also we don't take ESUS all days only when something broke, the difference is that now we apply the full ESU affected objects and not only the ones related to the SAR we need.

Good Luck
 
If only we were that organized. No one in IT here had JDE or coding experience before I came so there are no standards for documentation of mods. Also, we have many versions of UBEs where overrides were turned on whether needed or not, so this is going to truly be a time sucking upgrade process. Hopefully, this will be incentive to organize. I will take your suggestions and use them.

I hear you about not taking every ESU that comes along. I also agree that we should apply ESUs and get current in all the modules.

Thanks for the advice.
 
Hi.


[ QUOTE ]
If only we were that organized. No one in IT here had JDE or coding experience before I came so there are no standards for documentation of mods. Also, we have many versions of UBEs where overrides were turned on whether needed or not, so this is going to truly be a time sucking upgrade process. Hopefully, this will be incentive to organize. I will take your suggestions and use them.


[/ QUOTE ]

I face a similar situation with the objects customized by our implementation consultants we had to print Even Rules and search for any comments and also use ER compare to find differences between standard objects.

I some of them we forced the replacement of objects instead of merging to be able to reapply the development in a more robust and controlled way

[ QUOTE ]

I hear you about not taking every ESU that comes along. I also agree that we should apply ESUs and get current in all the modules.


[/ QUOTE ]

Yes, is a good rule not to apply any ESU if you don't need it, ie nothing to fix or no new enhancement or legal upgrade required.
 
[ QUOTE ]
objects customized by our implementation consultants

[/ QUOTE ]

This precisely hits the nail on the head for the absolute NUMBER ONE annoyance to sharp, energetic, knowledgeable experts when they start a new job as a Business Systems Analyst or CNC Administrator in a company. You know that they brought you in to fix "it" and you discover that "it" has been morphed into a new species by someone with JDE textbook skills only, no operations background, and was never taught that modifying source code is just plain bad.
tongue.gif
lol
 
"and was never taught that modifying source code is just plain bad"

different strokes for different folks Terry.

We've made numerous customizations to E1 for ease of use and business process flows which in large part enabled our company to double in revenue while adding relatively few employees.

I'm fully aware of the issues and costs related to customizations. Its just that in some cases the benefits out weigh those costs.

Just my 2 cents
 
Please do not get me wrong. I may preach that sermon but have plenty of times been forced to not practice what I preach when the need arises. Customization is a necessary evil when business processes and system functionalities cannot be brought close enough to each other for seamless fit. But the development must be done correctly, easily identifiable, and very well documented so as to you insure that they do not come back to haunt when ESU or upgrade times come along.
smile.gif


All too often are unnecessary modifications done in haste when modifying business processes is deemed only inconvenient and/or when they are designed, they are done sloppily and insufficiently documented without thorough testing.
frown.gif
 
Back
Top