I just spent quite a bit of time troubleshooting an updatable BAQ that essentially adds/updates Price List Parts and Breaks.
The Designer gives you two options.
So I choose Erp.PriceLstParts because the query actually matches pretty logical to the DataSet. I get everthing mapped, run/edit and click update. And then the BO error comes up “Can not Create” or “Can not Update”. So I go to the BL tester to see if I can get it to work there. Same Errors. I go to the REST page and try it there, same errors. If finally decompile the darn thing to see what the heck was going on. Come to find out that the service will throw a BO Exception for Add, Update and Delete! Yet it still has and visible public Update and UpdateExt Methods!
I guess my point is, why does Epicor expose those methods and let us choose it if you can’t actually do anything with it?!?
I hear you on this, Caleb. There’s a cool document available on EpicWeb called ERP_BO_Ref.chm that contains a breakout of all the methods with descriptions. Some of the method descriptions say things like “this is obsolete, do not use it”… some are very nice and detailed… However, the descriptions are by and large incomplete (for instance, pricelist has no descriptions). I’d like to see Epicor update this very diligently and then offer this up as the developer bible.
I’ve certainly wasted a lot of time trying to use obsolete methods or methods that do things they shouldn’t do, but I get that Epicor may leave them in there as to not break legacy customization setups at the point of compiling. If you want to compile something during an update and the file isn’t there at all, it leaves you in a different layer of troubleshooting the problem.
That pain is well felt internally as more teams are building on new clients to E10 - Consider Social, Search, Infoworker, ECC, FSA, Mobile CRM, etc. All have had the same need you have so a lot of discussion around this has been occurring.
The first efforts in this area are being targeted at our partners and they are giving us some feedback on areas so docs and simplified APIs have been getting tried. No roadmap but the pain points are well understood. As new Kinetic apps come online over the next months and years, I’d hope we have a more coherent approach on this.
No delivery vehicle to announce but the intent is clear on need.
Designer just shows objects with suitable dataset automatically.
It does not know if update is suppressed internally in the code and not intended to be used.
I think that it is frustrating to know that there is a disconnect between UI and BO. I’m surprised there isn’t some metadata/attributes that can be used.
Also out of curiosity, why doesn’t the designer let us choose what Method we want to use? I’m guessing it’s because of the dataset/tableset UpdateExt returns?
The reason I bring this up is because I was looking for a workaround for the UpdateExt method and saw the additional BO. As parts are added to a Price List, the performance of UpdateExt on the Erp.PriceLst BO degrades significantly. First 100 update/add will take 2 mins, next 1000 update/add takes 20 mins. adding another 1000 takes 180mins and so on. I have a ticket into Epicor and the Application Group is supposedly looking into it. (I don’t know how much traction we’ll get as it doesn’t affect the Price List UI) These are international Price List so their cost can change often and at this point it takes 5 mins to update 2 records on a Price List using the UpdateExt method. If we update a significant number of prices, we’ll be in trouble with our current SC workflow.
Now if you run the same scenario with the Update method on the same BO, you don’t see the issue. Hence the question.
I’d be interested to know the details of what you’re trying to do with PriceLst and UpdateExt. We’ve worked through quite a few issues with Price Lists with dynamic queries and SC workflows and it does work for us.
The point about UpdateExt if you’re using it efficiently is that you don’t need to include every record, only the ones you want to actually update.
Our problems were slightly different, then. Until a re-architecture of our pricing model we had several million price records, although (crucially) split between a vast number of price lists so none of them had more than about 4000 each. But those did update in around 10 seconds on average, I think.
Not to distract from your original documentation point, which i wholeheartedly agree with! It’s just that any mention of Epicor Price Lists makes me jump these days.
I think the best documentation which I have seen in the past at a company is owning the SDK and actually understanding what each BO method does and how Epicor uses it within their Base Customizations. That is the only reason I would ever own the SDK; very good documentation if you know how to read code. But beyond that its using .NET Reflector or dotPeek and the .chm’s Epicor provides.
