@vpanchenko I don’t have access to the Ideas area anymore so I can’t check it, but, while you’re implementing OData 4 for Generic Inquiries, if you have the opportunity to slip in an enhancement, I have one that I’ve encountered several times and I was just talking with @awilcheck about it today. The idea is to be able to set values for Generic Inquiry Parameters in the $filter part of an OData URL. Regular field names are referenced normally (eg. RefNbr), but maybe Parameter names could be referenced as something like #MyParameter in the OData URL after $filter, just like filtering on regular fields. The reason for this is that it’s cumbersome to create complex filtering logic in OData filters. It’s a lot simpler to add complex filtering logic to the CONDITIONS tab of a Generic Inquiry and use Parameters on the CONDITIONS tab as a way to interact with the filter logic which could be as simple as a drop-down with a few options that turns logic on/off. We just don’t have a way to set P
@tim I’m sorry for the late response since typically we investigate such cases as support cases.I measured querying the same Generic Inquiries with and without $select option on 2022R2, and the query with the $select options works almost x2 faster, not slower. I used Developer Tools in Chrome to measure the time. My suspicion is that the slowness is attributed to the client, that’s why The Hazen Method helps.
I haven’t gotten into OData and generic inquiries much in Acumatica yet. My understanding is that this allows end users to create their own queries on system data, and then OData can be used to synchronize those queries with 3rd party systems. Your understanding is correct for the GI-based OData endpoint: you create a generic inquiry or take an existing one and then consume it in 3rd party systems/tools like Microsoft Power BI, Tableau, various ISV solutions, or even in Excel.With the DAC-based endpoint, This seems generally very useful and powerful. However, is there the potential for end users to drag system performance down by creating extremely expensive inquiries? Has anyone seen this happen out in the wild? We have a special subsystem in place that monitors all the queries to avoid such issues as much as possible. I think at some point Acumatica should consider creating a data warehouse attachment to the main database with an eye towards scalability concerns with GI’s, etc. Thi
Vladimir, all of the ISV solutions that I was dealing with that using OData were using v3 and plain json. Unfortunately it is not too common interface that used almost explicitly for BI type of solutions, as most integrations require to push data back to Acumatica at some point, so choice is for CB API. If v3 is getting out of support, I guess we have to face it, but frankly I don’t think that we always would be able to build OData v4 request as complex as some GIs could be. If there will be a good way to work this around, that would be great. Don’t get me wrong, we're not considering to remove OData v3 as an endpoint, we’re just discussing the possibility of upgrading it to the OData v4 protocol.We need to separate the logical model (GI-based, DAC-based) and the protocol version (v3, v4); these are two completely unrelated concepts so we can bump up the GI-based endpoint from v3 to v4 without changing its base model.
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.