True. What we haven’t benchmarked is what happens if you send a payload in one go to a function and use UpdateExt there as well.
Also, you don’t have to send the entire dataset back when using the function.
this is an interesting thought, how much time are we waiting for a return dataset as a client.
That is true! That may be beyond the scope of what I could get away with on work time, until we’re live at least.
That’s why I was thanking you for what you have contributed and for responding to Jose with something.
Have you checked the before and after of the dataset? to see what is being set?
That can help determine the need of using the BO. We have done that as well with success.
I barely fed anything into UpdateExt, that’s part of the appeal, it fills in the blanks in the Ds obj. The return is extensive enough to see what it’s setting. But like I said, that’s only what it’s telling us it’s setting. My worry is that it’s doing something (mega simplified) like this:
var incomingDsFromApi = //incoming object from API
//the big chonky slowdown object
var greatBigOrderDs = GetAllTheOrderData(); //pulls in the entire order ds. header, dtl, rel, tax...etc
if(incomingDsFromApi.OrderDtl.RowMod == "A")
{
//use greatBigOrderDs to fill in blanks and... whatever it does with that
//create a new dtl record
//create rel 1
//ALSO DO SOMETHING IN PARTTRANS
//ALSO CREATE A RECORD IN SOME TABLE THAT IS REFERENCED BY ALLOCATION LATER
//ETC...
Db.SaveChanges();
}
var pullOrderDsAgainForReturn = GetAllTheOrderData();
return pullOrderDsAgainForReturn;
Like none. The size of data is rather small to transfer.
Look at this way, a BAQ that returns 5,000 rows takes less than 100ms to run.
BAQSvc is much faster than complicated business objects. It has one dataset that is a single table. Compare SalesOrder.GetById() with 1000 lines with its multiple datasets to verify the difference. Maybe someone (@cormsby) with a large sales order can look in Swagger or DevTools to see how long it takes to return that object.
Can attest that GetByID is slow as molasses for the purpose of querying a large order. I tried this recently when I was feeling too lazy to create a made for purpose BAQ to get some simple order data. The swagger just spun and I gave up before it finished. I imagine the BAQsvc is offloading most of the work to SQL where it can return a nice flat response, and the BO stuff has to execute multiple checks and queries to create a complex nested object, for better or worse.
Thats the swagger. I wouldnt recommend using it for testing speed of anything. The display components they use choke on displaying a lot of text.
I just watch the network tab of the dev console for the response. It will register it even if it kills browser page. For clarity!
Nice find!
Like kinetic grids choke on large datasets.
UpdateEXT is used by Automation Studio… but it is also now being incorporated into DMT usage as well. Historically DMT did one record update at a time, which has to wait for a complete round trip to the server before proceeding with the next record… but since UpdateEXT supports multiple record updates, you can send many records at once. We found that by having DMT call UpdateEXT, and sending about 150 records, we can speed up imports substantially. For those that we have converted, you get one extra question in DMT that asks how many records per page to import… some tables might be good with 250 records, some might be good at 100. I have experimented, and found that updating a single field in the Part table that 180 is optimal with my database.
OH… you can also DELETE with UpdateExT… just set the key fields, and RowMod = D.
Is there a time frame-ish when we will ALL get converted? This seems like a nifty feature…
Many of the heavy hitters have been converted. DMT for Parts, BOMs, (and I think cusotmers & Orders) have been moved. not sure of the exact progress… but smaller tables (Terms codes) are not as important to resolve this way.
This is not a simple fix… we have to do his uplift to UpdateEXT one table at a time.
Last I looked 2025.2 iirc, Customer wasn’t upgraded to do multiple. I’ll have to check it out in 26.100. Will be nice next time we have to update a ton of customers.
Awesome! I have two new projects starting on 2026.100, it will be interesting to see how their data gets loaded.
Thanks Tim!