Price Adjustment Schedule Problem

[kanga]

We are running in 'Coexistence' on an AS/400. Entering a small Sales Order using the World application takes 5-10 seconds. The same order in One World takes 20 minutes. We have been told that it is due to the way our Price Adjustment Schedule has been setup. We have one Schedule with many Adjustments. Keep in mind that both applications (World/OW) are accessing the same database. Monitoring the I/O's shows extensive activity over the 'Adjustment' tables. Has anyone had a similar experience or heard anything about these huge differences occuring in performance using the two different applications over the same database?

Thanks

 

[kanga]

More info...A consultant has told us that we need to break our one large Adjustment Schedule down into many smaller schedules. The interesting thing is that we don't have any problems with the application on the World side, only the One World side...and we are sharing the same database (being Coexistent). So the question arises, even though the database is the same are the applications so vastly different as to cause these enormous performance issues?

 

[Craig_Potter]

Bob,

Suggest that you enter an order with a price and compare the time taken to an order calculating pricing via Advanced Pricing or create a schedule with 1 adjustment definition and compare the times. That will at lease flush out whether Advanced Pricing is the cause.

If Advanced Pricing is the cause (or even if it is not) I suggest that you have a system issue, not an advanced pricing schedule issue. I have worked with clients with up to 50 Price Adjustment definitions in their schedule and I can assure you that they were still achieving times in the seconds NOT minutes.

Either you do not have your OneWorld Indexes built (different to A7.3 logicals) or I vaguely remember that one co-existent site found a setting (I think to do with unicode?) that was triggering the system to work overtime in oneworld (maybe there is something in your logs to indicate this?). Sorry I can't be more specific as to what it was - hopefully someone else I the list remembers or try GSS?

Hope this helps.

 

[Larry_Jones]

Yes.

 

[kanga]

Thanks guys

We'll work down that path
I'll let you know the results
when we get to the bottom of it

Bob

 

[WhippingBoy]

I wrote the Advanced Price server for World and I lead the redesign for E1. The algorithms are generally the same, but the technology behind the two database connections are vastly different.

That being said, you should not be experiencing the huge disparity in performance that you are. I would expect E1 to be slower, but only in terms of seconds, not minutes. I'd have to see your setup to make a better guess, but my first inclination is that the logicals are not correct for the E1 'select'.

Do you know for certain that Pricing is the cause? Preferences have also been a cause for performance problems, for instance.

Feel free to contact me if you'd like to discuss letting me take a closer look.

 

[gonugs]

I can confirm that WhippingBoy did all that he claims to have done, because I sat in a nearby cubicle and occasionally chucked wadded up notebook paper at his head while he did it.

Basically, Advanced Pricing (and Preferences) is/are written to do exhaustive searches based on your defined Hierarchy.

One of the things that I've seen over and over again is an adjustment schedule that is set up with about 10 adjustments and no single sales line will receive more than 1 of those. So you're guaranteeing 9 exhaustive misses for every 1 hit. That's bad.

I also agree that usually E1 takes longer to price a line, but not on the magnitude that you're seeing. There is probably some sort of setup/config problem. But like Whip says, it's hard to tell without looking at it.

 

[Chan Rana]

Hi,
This seems to be interesting. Let us know the resolution once you find the cause.

Thanks,

 

[windhorse]

I've heard of this happening in World but not One World. It could be an issue if you are using Advanced Pricing and have more than 25 price adjustments loaded on the schedule. Although JDE claims an unlimited number can be on a schedule, generally, you should limit it to four or five, which is usually more than plenty for most companies. I'm a former ERP pricing analyst and have implemented SAP, JDE, and PS Order Management/Pricing, so I do have some experience in this matter.

 

[kanga]

OK here is the latest...
Once again, remember that we are in a coexsitence environment on an AS/400. One of our guys discovered a number of logicals on the AS/400 that are exclusively used by One World XE that were missing.

Here were just two of them:
F4094_1
F4094_2

Apparently it goes something like this... the indexes could not be built originally on the One World side because the files on the AS400 were not defined as unique. 1) Recreate the files as unique - make sure you save the data first. 2) Create the required indexes in OMW. 3) One World XE then creates the logical files for you on the AS/400 for use by the O/W applications. You can identify the One World created logicals by the 'underscore' plus 'numeral' i.e. F4094_1

When tested, a one line Sales Order has gone from 20 mins down to 40 seconds...Still not acceptable - but way better

We are now looking for other missing logicals then we will look at our Adjustment setup.

Without the proper indexes the application was reading way too many, or all of the records in the Adjustments files...

Thanks very much to all who helped for putting us on the right track!

Bob

 

[kanga]

HOLD THE BUS!

HOLD THE BUS!

The latest test results were not correct! Apparently our developer performed his first test on our CITRIX server which is in the computer room next to the AS/400. When he tried it on a fat client (we are remote on a T1 line) it bogged down again...even after all of the index builds mentioned previously...

However, our results are not indicative of a slow connection (a one line sales order on a T1 line should not take 20 minutes)

So we are still investigating

 

[kanga]

Just a follow up. Things were not as they seemed. Strange how that works...Rebuilding the indexes didn't help. One of our developers tests was on a remote fat client the other was on a local CITRIX server. Hence the reason for the huge discrepancies.

The end result was 20 minutes on the remote fat client vs 45-80 seconds on the CITRIX server for the same order. Indexes or no indexes...

However splitting up the schedule (in test) got us down to subsecond response times on the CITRIX server. But the way we split it will be a maintenance nightmare.

So we asked Whipping Boy to look at our system. He quickly analyzed our Price Adjustment Schedule setup and has already mentioned some areas of concern and some opportunities for improvement. He will be documenting his findings for us.