Yes that would be amazing, count me in. I’d love to try and work together with them to speed things up for large volume order processing. I’m sure you and I aren’t the only ones with this issue.
All the people on the thread that talks about “Ready to Calculate” may be candidates too. @klincecum originally helped me track the performance difference.
Although strictly speaking, 5000 releases is (currently) an outlier use case, the need for more and better automation of “administrative” tasks such as this is only going to increase. In a later post @josecgomez talks about how this BO involves the Bookings BO and then updates totals in other tables (even though, in this case, those totals aren’t changing).
All that “overhead” is what makes Epicor data safe.
I don’t think Salesforce is a valid comparison here, nobody is doing corporate-level financials there. It’s not a database issue either, since going directly to stored procedures works.
How do other mid- or up-market ERPs do this? I’m pretty confident discussions like this happen at ALL software manufacturers, and at SOME POINT the powers that be gotta decide to pull the trigger. Here, inside the collective, what kind of PRACTICAL additions could we make to those discussions?
(p.s. @Mark_Wonsil we already know, highly value, and probably unanimously agree on the DevOps side as you champion it… my goal here is to look at the more mundane DailyOps side of things)
Ernie, there’s gotta be a way to make it “safe” and still allow manufacturers to make move, and sell at the speed their customers need. That’s all I’m searching for ( Sales Order with thousands of Releases - Epicor ERP 10 - Epicor User Help Forum)
And it’s not just 5,000+… just get up to 100+ releases and you’re already going to get into an administrative nightmare.
@Ernie it’s this thread that was less than 5000 releases: What does “Ready to Process” mean? Make SURE you understand! - Kinetic ERP - Epicor User Help Forum
EDIT: sorry this: Sales Order Testing - Adding Bulk Releases - Kinetic ERP - Epicor User Help Forum
The software, as it is written today, updates ONE record at a time. It completes the update of that record, does whatever other business that update also affects, and then moves to the next record.
If there is a second dirty row on the same BO/dataset, it pukes.
Dreaming here… could there be a way to cache multiple dirty rows on the same BO/dataset, pre-process them as a group, THEN update and move on?
Yes, please.
In the meantime, perhaps when this doesn’t need the whole ds…
…optionally enable supress GetByID in the middle.
Why not process this with a function?
Function picks up file of data and builds ds. Mark each release open and U. call .Update one time. You could do it in batches of 100 releases or something.
And herein lies the bigger issue, we are focusing on sales order entry… as we have heard, it’s everything that follows that grows in complexity and time processing later on… anything linked to that order.
Unfortunatelly the UpdateExt call just calls openRelease() wihich still takes 45+ seconds per call.
So even if I did this, it would just take 45 * 100 to process each batch this particular call is just crappy.
I think the BO in general is bad but I’m 99% sure that OPenRelease is just aprticularly bad after looking at the code.
Right and that’s just that BO in the entire process. Now we look at Order Job Wizard, MRP, ShipDtl, Mass Ship, all the things that follow.
Would replacing the entire order be an option?
I bet we could get it down to a few hours or less.
Process the changes offline. Create new order and releases with ready to process off, and then turn it back on at the end.
Nah too many shipments already against this order, I doubt it would help.
In case I missed it, I apologize, but did you try direct server side calls from like a function?
I imagine it’s still bad, but might be a lot better.
Ish we did direct server side calls to the BO but yeah I don’t think it would be any better. Marginally perhaps.
Agreed that Salesforce is not a valid comparison. That is a Platform as a Service and you can do whatever table updates you like. One is not restricted to the business object model that Epicor has carried forward since V8.
Au contraire. Certinia, formerly Financeforce, has been doing this for at least ten years now.
DevOps is a methodology for developing, testing, deploying, and monitoring software solutions. I would put this issue in the architectural camp. As you correctly state, Kinetic updates one business object at a time. As @chaddb mentioned, Salesforce provides a batch update endpoint that is tuned for that purpose. I use batch endpoints in HubSpot as well. Would it be possible for Epicor to add an UpdateBatch endpoint specifically this case? 
@josecgomez What kind of updates are you making to these releases?
I may run some tests later on as a brain break. Kineticizing stuff is killing my soul.
Jose, you’re the goat, so this may not be helpful, but specific to DMT, helps to break down the files to smaller sizes. 5000 may take a long time, but if you do under 1000 or even 100 the processing times speeds up. I suppose that is why they created the ability to split? But 5 days is ridiculous.
WE tried splitting it just multiplied out to the same runing timem
Tried Server Processing with DMT? For the tables that support it I’ve seen crazy speed increases using it.
Well it probably has to individually insert a PartDtl record for each one. In addition to all the updates that have to be done on the order line and order header. RBAR ftw. But, I would still bet money a function would run faster than the DMT.