OData vs custom methods in REST?

Epicor ERP 10
, ,
1

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.

Thanks!

1 Like
2

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.

4 Likes
3

When do you use OData methods then? Create/delete?

And do you consider JobEntry to be a more complex BO?

Iā€™m getting into Epicor more and donā€™t yet have the experience to know when OData be useful or what kinds of issues it can cause

This may be related?

4

Jose is using your EpiUser name instead of OData. :thinking:

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.

5

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

bo.GetNew
bo.ChangeX
bo.ChangeY
bo.ChangeZ
bo.Update

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.

6

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.

1 Like
7

@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)?

8

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.

1 Like
9

Also recommending the function route:

  1. Simpler API calls that you can customize to your specific needs.
  2. You can customize the payload. Pare it down to the essentials, or combine multiple tables and BOā€™s into one call.
  3. You can make fewer calls to get the same results.
  4. 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.

3 Likes
10

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

11

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 :slight_smile:

I do have this to read through

12

Build on Dev / Test and when you are happy with it just use Solution Workbench to move your functions over.

13

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.

Never did write up that postā€¦