Does anybody know if calls to the /List methods are supposed to return nulls in all the Extended UD fields? I am able to apply an oData filter on UD fields and get results back but the payload returns nulls in those UD fields.
The standard /GetList call doesn’t even return UD fields at all.
I like how light weight the /List payload is (specifically a SalesOrder where I don’t care about the child tables) but if isn’t going to return our UD information, it won’t be very useful for us.
The payload does return the UD fields but with nulls. It’s seems like it should either populate the fields or don’t return the fields at all. GetRows is fine with the select paramater but that’s just more “stuff” I would have to control. I like the idea of having the lightweight payload, especially if it returned our UD fields, which are usually more important than some of the otherfields.
There is a bug out there to not return the UD schema at all. What version are you on?
That was the original issue in the core GetList method where it would appended the schema placeholders to the List tablesets though nothing would ever populate them - by design. List is supposed to be lightning quick and UD slow things down substantially. I thought we did get that fixed - I know we had to add a UI workaround for grids but I thought we fixed the core issue some time ago?
FYI - If you need UDs in a List scenario, please consider BAQs.
We are on 10.2.200.6. We have 10.2.200.9 environment that exhibits the same issue.
Yeah, I’m kinda of being lazy and don’t want to maintain them but I’ll probably have to do it. GetRows as so much more information. I would say in most cases we just need the basic information that’s listed in the Detail Pages of the UI along with our own UD information(We’ve obviously taken the time to add and populate them so it should be important information). Don’t return the fields like Rpt1, Rpt2… that are never used. To add a BAQ to every BO that has UD fields so that we have a lightweight payload and UD fields seems a little off, in my opinion.
Is that something that you are working on making faster?
But it’s not just limiting your payload. It’s also insulating you from changes in the BO. People on this forum were burnt when some .GetList columns were eliminated during one of the upgrades. That won’t happen with a BAQ unless a field is renamed, and then it’s a problem for both solutions. That BAQ can easily be sorted and filtered dynamically.
We have a few things under consideration for UD like improvements but never intend to include them in GetList. I hear a common request for them in the search windows but that is why we have BAQ searches there. GetList has other uses beyond that search so adding UD to them is not on the roadmap.
Fair enough. I don’t like to get burned but I also like to embrace what Epicor has developed out of the box to keep our dependency on customizations low.
That’s the point of BAQs in general and BAQ Search specifically as we understand that concern. More to the point on getting bit during patches and upgrades is why we are moving towards REST> It’s not ideal and the RESTafarian in me wants more but I don’t like the idea of going dark for a couple of years on new functionality or breaking all existing customers who’ll riot with torches and pitchforks. It’s a balance I hope we are maintaining - we are certainly trying to and listening to folks comments in 1 on 1s, and forums like EUG and E10Help.
Keep the enthusiastic feedback coming and we’ll try to keep filling in the conversation between the help topics in forums and user group meetings…
Have you ever seen when you add a new _c field to lets say CashHead, the UD Columns don’t show up when someone calls lets say “GetNewCashHeadType”. But If I make a POST BPM and populate the field to something other then null it shows-up in the GetNewCashHeadType call/BO/Rest Tracing, but not when its null.
However in Swagger it shows up in the “example return”, but not in the actual return.