Basic REST Query


Trying again to start learning REST. I’ve got the Integration Examples that Bart provided, and I can get it to return some data to the console. I’m trying to combine what’s in the example with a demo that Dele gave at the UK EUG event this week.

            //Stand up which service to call
        HttpRequestMessage request = new HttpRequestMessage(
        ServiceUrl + "/Erp.BO.CustomerSvc/GetByID");

        //Add the json payload
        request.Content =
            new StringContent(
                        custNum = 3

That is the code from Bart’s example, which returns every column for CustNum = 3. I am trying to be more selective, and only get CustID and Name. I tried the following, but get the error below it:

HttpRequestMessage request = new HttpRequestMessage(
ServiceUrl + “/Erp.BO.CustomerSvc/Customers(BVD,3)?%24select=CustID”);

Epicor.RESTApi.ErrorHandling.ApiException: Request is not supported. Method: POST, Path : https://epicortest01.bvdairy.local/ERP101600ChillStore/api/v1/Erp.BO.CustomerSvc/Customers(BVD,3)?$select=CustID,Name

Using the URL in Firefox works as expected, and only returns those 2 columns.

Please point me in the right direction :slight_smile:

Many Thanks

1 Like

Do you understand the difference between the OData endpoints and the ‘legacy’ Custom Methods?

This can be kind of confusing as the OData ‘simplifications’ call back into the ‘custom’ methods. In other words there is a custom ‘GetByID’ method that is the same thing called by the adapters or over WCF. Then there is an OData method which treats the Entity (Customer) as the first class citizen instead of the method (GetByID).

If you ask for an explicit Customer over OData it would Customer(‘Some Identifying stuff’). That’s the OData query style.

If you want to retrieve a customer in the legacy way it would be CustomerSvc.GetByID(‘Parameters’)

The legacy methods are all done via POST - kind of the least common denominator.

The OData method uses the appropriate method based on the need of the Entity.
Get (for retrieve)
Post (For Upsert)
Delete (duh)

So first consider how you want to tackle the interaction.
Are simple queries and updates (Odata)enough? It’s an easier model if you don’t need the ‘Change this, Approve that’ kind of custom methods on the legacy API. We are trying to make the API more simple and flexible and hide the custom methods behind UpdateExt. All that goo in the client transaction.cs? Yea that should have been copied to UpdateExt intercepts on the server and are in the process of ensuring UpdateExt is as full featured as the client form. So expect you might run into a bug or two and have to fall back to custom. We’ll get there.

If you need the granularity of the custom methods, then all your querying will be via POST and the payload drives everything. This is very similar to what we do today when calling the server - Service.DoSomething(Blob of data). The blob is just in json for REST.

So why all that review?
It looks like you have a mix in your query. You are specifying the payload and explicit method like you want to use the custom method GetByID. But the signatures you are trying to use are OData syntax with the select, etc on the query string.

Which do you want? :slight_smile:

1 Like

At this point, the only thing that I want is to learn and I’m doing that by playing with examples. I have a few things that I would like to do with customisations, so trying to prepare for that.

I understand everything that you’ve said below, and it makes complete sense. In your examples that you posted previously, you’ve gone for the “custom” methods then from what you’ve written below. You’d used GetByID on the CustomerSvc, then supplied it with CustNum.

One of the things that you’ve said, and Dele said the other day too is about reducing the bloat on the wire. The GetByID seems to send every column, including that of child tables. Can that be customised by supplying additional parameters in the same block that CustNum is specified or not? Does GetByID always return that fixed dataset? If so, it seems that the OData way to go is more optimal?

Correct on odata allowing more custom data retrieval.
I used custom in the example only for apples to apples with wcf or impl based. We are seeing more use of odata on internal new products like mobilecrm, active home page, more to be announced.

Hi @Bart_Elia & @josecgomez
please forgive my intruding and ignorance,

reading through posted REST Technical information is blasting my mind, i am just searching any available data to understand the basic concepts, possible functionality.

my company launched a new project (Industry 4.0) last month. the project simply represent an important step toward smart factory environment, the drafted functional plan basically require to integrate our machine controller software into our ERP system (Epicor), to be able to remotely monitor/identify/analyse/and display live machine data in terms of Epicor parameters, the designed functional spec. aims to minimise manual data entering (MES) to the possible lower level -which I imagine will be passing some identified Epicor BO method parameters- by building a logical algorithm using machine signals and operator interacting to trigger alerts and/or actions based on Epicor custom BO/BPM’s to replace the need of using MES manually for these purposes.

searching this Epicor protocol (REST), found out -please correct me if i am wrong- that it needs to be on 10.1.600. and upward, so decision has been made to upgrade our Epicor from our 10.1.400.20 to 10.2.300.xx and scheduled ASAP, i have seen few examples to export data from Epicor using REST, and found here some code examples of calling Epicor BO from third party software such VS2017.

so my question is will calling Epicor BO method from a third party app, can handle UD fields, BPM forms, BPM Exceptions, and BPM CallContext variables etc, the reason i am askin is that we have done many developments around Labor production area i.e Start Production,Setup,Rework, Indirect, logging DownTime, and Ending Activity, 90% of theses development is Pre-processing method directive on Labor BO, and can not see on REST Technical guide any referring to this ? what i am missing here??

Thanks in advanced

Congrats on the Industry 4.0 initiative. We are doing a lot of conversations around that domain so looking forward to you presenting at Insights or a local EUG meeting :wink:

10.1.600 was the first official release of REST. We cleaned up a couple of things each release since but the basics are there from 600 forward. We always have a few new toys in the pipeline and all the previous issues had workaround so you should be fine no matter the choice.

To your asks:
UD fields
Yes - UD Fields come across in the tables as you see in the client datasets.

BPM forms
The data to open the forms is available to you but since REST has no client, it would be up to you to implement a UI to act upon the data presented to the client. Currently in WCF (and in REST where we leverage BPM data), the clients look at the message header data that is returned from a server call and react. It could be popping a BPM Form as you mention. REST like WCF before it is just a mechanism to call across the network - a pipeline. How it is received by a client is not known by the pipe. A more concrete example - we are taking calls from connected devices on the factory floor. These little $1 devices send telemetry to E10 Machine A has been running for 1000 hours, create a preventive maintenance ticket or Temp on Machine B is over limits, send repair ASAP. They use a REST call. There is no UI. It’s a dumb IoT device with a http stack and not much else.

BPM Exceptions, BPM CallContext variables
Yes with caveats as above. You will receive an error (not a 200) or extra information in the response headers. How you react will be up to your client you build.

One thing I will add. All the BPM process changes and all the existing security, data filtering and masking, etc is all active. The same BOs and security framework are in use. If you have a BPM on Sales Order in the rich client form or over SOAP, it will be active and used in REST.


infinite thanks to you @Bart_Elia, your reply straight to the point, clear, and informative, very appreciated,

and yes of course, it will be a presentation at some point, we all praying to Zeus to make that work:smile:

the third party software (machine control app) called ‘Mazatrol’ developed in C++, Mazak (the lead CNC machine manufacturer around the world) keen to cooperate with us to achieve the project objective as no one in Uk has done this yet.

Has anyone reached out to you from the Connected Factory team?

i attended their IoT session last week at EUG conference, very interesting, i had a chat with Jos and Aieat before and after, they have done a good job, however still using MES DataCollection UI to trigger labor activity, then using REST to export Epicor and Machine data to the cloud-Base app ‘Connected Factory’ to analys, monitor and live display, my design is a bit different as i explained i would like to customized our app UI to trigger Epicor labor activity based on an algorithm to read machine data and ask operator to enter needed parameters for each type of activity, this is my draft functional plan, i have asked Peter Black to kindly schedule a ‘VEW session’ to discuss the project requirement and show them our environment, i do know yet technically how we are going to do that :):thinking:

1 Like

If you reached Aieat, you have the correct contact. Lots of fun in that space in the industry right now so glad you two connected.


We are looking for some customers for an advisory panel on IoT and Connected Factory aspects - please reach out to George Peters who is the product manager over MES/Mattec/CF and other aspects if you would like to get involved.

1 Like

Hi @Edge,
thanks for your input, we are open to all suggestions, if George Peters and you do not mind, please send his email to me via DM and i will contact him, however i have highlighted my requirement EUG/UK just gone to Epicor CEO Steve and been told to contact ‘Value exchange Workshops Program’ people, and the BOERS&CO team.

With regard to Mattec, I have searched this module in depth, and the outcome decision was until this module replace the need of using the existed manual MES/Data collection UI, it is not suitable for what we hope to achieve.

Sure will send you his email