I am setting up a user defined table to hold a simple resource for an automation project. This resource essentially has a “bin number” that uniquely identifies it as well as a few other simple fields. I store the bin number in Key1 and the rest in normal fields.
It seems that all user defined tables come with five “keys” that you must use. My resource really only has one field that could logically be a key so I have been leaving the rest empty (as in an empty string). However, I noticed that these fields are “required” in the Swagger interface and there seems to be no way to enter an empty string and I can’t send the request. This seems like a common use case where Swagger (which has been an exceptional tool) can’t function as expected.
This all works fine over Postman where I can easily use ‘’ as empty string in the URL and ultimately I will be able to deal with it in my application code so this isn’t a show stopper.
I created this topic because I figured either this might be a bug / feature request for the Epicor Swagger or I am missing some best practices when implementing UD tables.
Do people remove the unneeded Key columns somehow? If not, is an empty string a reasonable place holder?
I just checked and you’re right. It looks like the Swagger page is adding the apostrophes to the input strings automatically, but the Swagger UI is requiring you type something into those fields. I wonder if this is a bug with how Epicor set up the Swagger page or with Swagger itself.
For what it’s worth, I use empty Key2,3,4,5 fields in the UD tables all the time. There’s no (supported) way to remove them.
This is one of the benefits of using Epicor Functions since you can declare your inputs as nullable and handle them appropriately in the function. Again, 10.2.500+…
Thanks @Mark_Wonsil . I’ve read the topic that was recently posted here. Trying to wrap my head around epicor functions. Do you see any other benefits in this senario?
Some background:
I am implementing an automated system at a very small organization (~20 people, ~5 who interact with Epicor regularly), so I am trying to consider the cost/benefit of introducing extra complexity/configuration into Epicor that needs to be maintained etc… I may be implementing up to 10 UD tables / resources in the near future. In all cases these resources are very simple (one or two Keys, a few fields, resources are only consumed by one instance of an application, very limited tie in to other Epicor features). This data was stored in a local database but an effort is being made to consolidate data. As cool as they sound, I am hesitant to add maintenance of 10 Epicor Functions to the mix, any advice or words of encouragement?
I like the idea of consolidating data. If you’re just reading/writing to UD tables, those interfaces tend not to change from release to release, but who knows? There might be a way to create new tables in the future instead of using UD##, UDXXX(A) tables in the future.
To me, a major advantage of EFx is that you’re keeping your logic in the function and not in each of your apps. You define your input/output signatures and keep the code centralized. You may even be able to reuse some of that code for the various calls based on an input variable. That’s up to you.
What is the nature of your workflow? What event triggers a write? What’s the shape of your data?
