E10 REST API Method Descriptions

Hello folks,

We have a fully implemented custom REST API implementation in place that integrates with our ecommerce storefronts. We’re trying to modify and implement the Counter Sale feature into the integration when creating sales orders, but are needing information on what some of the methods shown in the trace logs do and how they behave.

Is there any documentation that describe what these API endpoint methods do?

For example, CheckSellingQty vs. CheckSellingQtyMaster seems like the later is the only way to have Epicor report back to be a problem with a counter sale that the line item is out of stock (negInvTest) – but unsure. That’s important because you can’t sell something that is out of stock at the time of a “point of sale at the counter” order – eg. there’s nothing to put in the bag.

That’s just an example where it would be nice to be able to read a description of what the methods do and when/why I should call them.

Any tips?

I haven’t gotten into REST yet, but it looks like the endpoints are practically the same as BO methods.

image

So if you do find some documents on this, I’d love to have them. As I only know which BO methods to use in a BPM, based on Traces and Trial & Error (mostly the later).

Swagger is somewhat helpful in that you can see all the method signatures (both in and output params). However, the parameters are vague as well… So. :face_with_raised_eyebrow:

For example, logging in as a valid Epicor user:
https://centralusdtXXXXX.epicorsaas.com/saasXXXX/api/help/v1/

REST methods are the same as BO methods. It is just another way to call the BO.
Swagger shows XML comments for the methods from .xml files in the server directory. Unfortunately, not all methods have proper comments.

1 Like

I’ve never seen anything that was helpful in the Erp.BO space inside of swagger. Is there some other place I can find help here?

In my particular case, I’m trying to get the counter sale to report back that the part is neg inv (or out of stock) so I can abort the counter sale.

The trace log flows like this, and the client UI will reply with a warning box, but I can’t get these to throw a warning back to me via the API – even tho I’m following the trace log methods the same way.

For example:
ChangeSellingQtyMaster has a boolean parameter “negInvTest”. When I call the method and pass a true value, I never get any response values of a problem.

Following the trace log further, I call ValidateInvQty which also does not return any messaging (all empty strings).

… for the record, I don’t want someone to write this for me, I just want to see some reference material so I can make the appropriate calls to solve this problem.

Any advise?

Your other option is to create your own API with Epicor Functions in 10.2.500+. It’s still REST but you control the signature. All the work is done in a BPM like interface. You reduce the network chatter too.

Thanks Mark.

Yeah, I really don’t want to duplicate all the processes that go into order creation, especially in light of knowing we already have some custom BPMs that tie into the data directives for how our company processes exceptions during the SO creation process.

I guess that’s a work-around, but it sure seems like having access to documentation is the easiest solution. I don’t want to hire a consultant/developer to answer this – as cloud customers, I don’t feel like we should have to pay for access to documentation.

1 Like

Mmmm. I don’t think this is a work-around. This is the future of Epicor. I’m pretty sure we’ll find as Epicor continues its move to Kinetic, they will be using Epicor Functions to do their REST calls from Angular instead of multiple calls from a client. Since they are calling the regular BOs, all your regular BPMs will work just fine. They work with mobile, web, and Rich Client. IMHO, It’s better to keep all your logic in one place and not clients all around the organization. And Epicor functions are free to use for both cloud and on-prem users.

Documentation has always been sparse REST or otherwise. The only way most of us know what happens is through tracing. :frowning:

2 Likes

I just mean it’s not a viable work-around for us given all the existing investment in what we have in place now, and in the interest of time.

Besides, I feel like I’d be in the exact same position in Functions as I am here… LOL

Perhaps I should be asking the community how to do what I’m trying to do specifically and see if I can get some suggestions. Is the best approach in these forums to start a new thread?

Thoughts?

Fair enough. If the performance is poor, you now know a path for your next design.

I’m afraid so. The tried and true way is tracing. :man_shrugging:

Absolutely. If you’re having an issue with a particular transaction - especially following a trace, I would post a new thread. Don’t forget about the Trace Helper Utility.

1 Like

It would be great if there was some sort of user wiki for BOs to share our hard won knowledge.

2 Likes

I think GitHub/GitLab is the new code Wiki these days…

There should be an EpiUsers code repos, no?

cough cough

2 Likes