Is there a way to get a REST trace log similar to the Client trace log? I know I can do the server trace, but it does not show you the data that is being passed. I was hoping to see the data so I can build BPMs correctly.
Usually people use tools like Postman or a Visual Studio Code extension to see the parameter passing.
Can I use it to catch the REST call from another application?
If you’re trying to build BPMs correctly, the first place to start is with a client trace to understand the calls being made. The Epicor REST API is simply another layer on top of the underlying business objects and their services, so without understanding that, analyzing API traffic is going to be useless
2 Likes
Be like Aaron. Don’t call the Epicor APIs through REST. Create a function, use your BPM skills to get the job done, then expose an interface with REST. This hides all the epi-magic from your client and makes testing/upgrading so much easier.
2 Likes
Correct me if I am wrong, but I don’t think I can use the functions as we are not on 600 (when the functions in REST became available) and our REST is not V2.
I have a 3rd party who built a REST interface to Epicor and they are using the UpdateExt instead of Update. I was trying to figure out what might be different between the two as my customization works in the UI but is not working through REST.
You’ll still need to look at the Client Trace and analyze the dataset and what fields are changing with the method. The integration method you described is valid and I’ve done that too, it’s just much harder (in my opinion). You probably don’t need to pass all the fields, but you’ll want to pass key fields, changed fields, and a row mod = “U” to get some traction.
1 Like
But I can’t look at the Client trace because the client is calling Update, not UpdateExt. That is why I was trying to capture the REST call like a Client trace.
Update vs. UpdateExt: update will be more stringent typically than update ext, but they both perform an update. UpdateExt was designed for less chatty updates, I believe.
I guess I don’t understand your question. For REST, you are sending a payload in the body of the call. In a client trace, you are analyzing the dataset. You will want to consider what in the client trace is being sent, and mimic that in the body of the REST call. The Epicor Swagger page for your API will show an example payload for that method. You just want to send enough info to identify the record and update the right fields.
2 Likes
We’re on 10.2.500 and use functions, and we have v2. Maybe yours was disabled?
1 Like
I think 600 ships with a client side RestClient helper class to call them internally, that’s the big difference as far as I can tell
I don’t have access to the REST call as it is coming from a 3rd party. I am not creating it as I would use Update.
What I was hoping to do was see the data so I could see if there was anything that was being called different and could adjust my BPMs.
My understanding is that the UpdateExt eventually calls Update, but is the data still considered “added”? Or is the RowMod different which would affect the BPM that I made as I am looking for “added” rows.
Yes, Functions are available in 500, but I did not think you could call them through REST until 600.
Yes, V2 is available but we are not set up for it, so I am constrained to V1 for the near future. Also, I believe you have to be running V2 to call functions through REST.
I could be wrong on all accounts, but that is my understanding at this point in time.
I think you’ll need to get an example from the developers of the third party app to see what they are sending. This should be no problem for them to give you an example.
RowMod should be “U” for updating records, “A” for adding records (such as in a GetNew call), etc.
V1 vs V2 refers to the Epicor REST API, but both are called via an HTTP Client regardless of where that emanates from.
V1 uses basic auth, v2 uses basic auth + API Keys
I’ve only used REST with functions. The only business object I have used with REST is the BAQSvc and that was before functions existed.
Yes, functions only work with REST v2. What’s the obstacle to v2? It has a better security model than v1
2 Likes
New implementation ongoing. No internal IT help. I’m the first Epicor resource ever hired (and they have been on Epcior since 1998). Extremely poor use of the system currently.
4 Likes
Hang in there Buddy!
1 Like
We are here to help my man
3 Likes
I just want to clarify - any authentication type we have works with REST, not only Basic 
For client library it will take currently used auth.
2 Likes
Thanks Olga, good point. I have only uses basic auth so this is a good point to illustrate.
AARON MORENG
JRF ORTHO
IT MANAGER
1 Like