The REST API has two definitions, OData and custom methods. Can anyone explain when is it makes sense to use OData? Can I trust that if something is possible with OData, that it ultimately does the same things as if I traced in Epicor? If not, when would I know I could use it safely?
I will be working with Erp.BO.JobEntrySvc. If I want to change the JobReleased field on JobHead, one way would be to use the OData JobEntries patch. I set the JobReleased to true and send the patch up. Another way would be to trace it, and recreate the custom calls. I know both will end up with the field updated as I have done them both, but Iām curious if the OData will do the same thing as the trace behind the scenes.
To be more specific, ChangeJobHeadJobReleased is one custom method called in the trace for JobReleased. Swagger says
āThis method potentially updates the JobHead.JobEngineered field and the ttJobHead.EnableJobFirm
This method should run when the JobHead.JobReleased field changes.ā
Does OData call this in the background if I update JobReleased? I will be updating other properties like quantity and cell so the same question applies. We did a server trace and OData called UpdateExt but that leaves me with the same question, just a layer deeper.
OData uses UpdateExt which in theory should do things right.
In my experience UpdateExt is a hot mess in some of the more complex BOs. So take that as you may, I donāt use oData methods for Updating unless its a very basic BO like a UDXX table
I tend to instead use Functions and call the standard trace BOs within it.
What he does is not treat REST as a remote procedure call but puts all the logic in an Epicor function and then calls that Epicor Function via REST. Why pollute your client with Kinetic details? Create a proper function to do the work and simplify your client access.
I tend to use oData seldom and usually just for Retrievals. Again, your mileage may vary but using a function instead on the REST side and having the function call the trace (traditional) methods
Usually yields a more reliable product, also it ensures that any BPMs hanging on those methods fire. OData / UpdateExt (Generally) do not respect those intermediate methods / bpms.
Job entry is one of the most complex. Other than the Inventory transfer BO (which is a hot mess) this is what I feel like is the next most complicated BO. Well, maybe not complicated, but problematic.
@Mark_Wonsil@josecgomez Just to clarify, are you both recommending to create an epicor function that the api calls rather than multiple rest calls? Is this the general consensus recommendation (not sure of what group)?
I should be faster if you can do it that way. If you can send in one call, and all of the stuff happens server side, and you get one response back, itās simpler. You donāt have to go back and forth sending information over the wire.
Itās not always possible, but when it is, it makes it a lot easier.
Simpler API calls that you can customize to your specific needs.
You can customize the payload. Pare it down to the essentials, or combine multiple tables and BOās into one call.
You can make fewer calls to get the same results.
Everything stays within Epicor. Upgrading? Copy DB to the new server, run the upgrade, and run test scripts in postman. No need to involve the outside system. Nice and clean.
There are only two ways we let outside apps talk to Epicor: a) functions b) BAQ REST service, which is good if you just need data.
Correct, much more efficient and quicker to manage, less messy. Also you dont want to have to keep up with DataSet intermediate state in the client yuck
Thanks all, we will try the Epicor function route calling traced methods!
That does give me a couple uncertainties to iron out though. We have two epicor environments, for targeting live or test data. I imagine I can build on the test server, and then import into the live server? Not sure what the modifying/deploying process will look like yet. Any bookmarks would be appreciated
To add a little to that, the upgrade runs conversion workbench which disables Functions that have outdated method signatures. So it finds the problems itself. Itās great.
Like this. Finally had to break down and do one step directly.