Using REST in an integration

What is the best method for using REST in an integration (using an integration tool - possibly Boomi)? Or would the WCF Svcs be better? I’m going to be inserting/updating Sales orders, contacts, customers, UD tables, etc. If using REST, can I get away with just using Odata or do I need to use the methods and do a GetNewOrderHed, ChangeCurrencyCode, Update for example? I thought I was told that I might be able to get away with just doing a POST. Is this true? I’m just trying an example in API page, but an getting a Request is invalid error. I don’t have an order number, but should it just create one without doing a specific GetNewOrderHed?

I’ll also need to pull data from Epicor based on the changed date that we now have in almost all tables. I’m not being successful filtering on a date. What would the format be for that?

Thank you!

Not sure where to start with this. REST is an architecture style. In this case, it’s an architectural layer built on top of the Epicor WCF services. If you’re doing integrations over different networks or platforms, using the RESTful style integration approach is probably easier. It’s important to understand that they are fundamentally the same thing; they go after the same business objects.

As far as which methods you need to use (custom vs. OData), that’s entirely dependent on the task at hand.
Another approach to consider is using the BAQsvc and basically have custom endpoints where the schema is maintained via BAQ. These can also be used to kick off custom code to perform any task in the system.

1 Like

Hi, Aaron.

Thanks for your response. So, with the example I included, would I need to use custom and call each service separately or could I get away with a general Sales Order Post? What tasks lend themselves to one vs the other? I’m not looking to have to write a bunch of custom code in Epicor if I can avoid it.


As @Aaron_Moreng mentioned, if you talk about your business case, it helps to answer your questions. Are you tying into an e-commerce site? Are these orders only coming in from your internal network? How many? Under what username? Do you have BPMs on your Sales Orders today? etc. These help determine the best way to handle things.

Mark W.

If you are simply doing CRUD on basic setup tables and business objects, odata is the way to go. But if it’s a business object, like SalesOrder(which is a beast), that has a lot of “OnChange…” or “Change…” methods (the methods that update other fields based on another field) calling those methods is probably the way to go.

For example, if you need the Business Logic to update the Unit Price based off a Price List, you’ll need to call, oh let’s say, ChangeSellingQuantity method. Now, if you have all that information in your odata payload and call, then you are fine but you won’t get anything but the basic UpdateExt validation.

From what I’ve played around with, the odata methods don’t call any additional business logic other than UpdateExt, GetByID, GetRows methods.

You might be able to get away with a PreProcessing BPM with some custom logic to determine where the data came from and apply any additional Business Logic there prior to sending it to the base method…but that can get complicated quick.

We are learning how to use it with Microsoft Flow and Azure Logic Apps. I’ve gone back and forth between the two.

My first accomplishment with REST was to create a Microsoft Flow that updates an environment that was restored from our production environment. We update Company information, Workstations, Scheduled tasks, ect. so we don’t confuse ourselves which environment we are in after the restore. All happens in less than 30 seconds and few drop downs.

On a side note of your Orders integeration, Epicor had a cool method called SubmitNewOrder on the SalesOrderSvc, that did the basic OnChangeMethods that got me 95% of what needed to be done, but it failed to update any UD fields that were specified in the payload. Pretty disappointing. Great idea…poor execution.

As far as adding a SalesOrder using a odata POST, I couldn’t get it to work either. They still have some limitations as @Bart_Elia will tell you. They say they are “working” on it though. :grinning:



You should share that environment refresh program on the experts corner here, if you’re feeling like it!

Well the integration I did I only used GET, and I used Jquery and Javascript. Something like this
//Server Path
var urlBase = “https://yourserver”;
//Access to the API and the BAQ Service
var urlType = “/api/v1/BaqSvc”;
var urlBaq = “/BAQID”;
var userNa = ‘username:password’;
var auth = window.btoa(userNa);
//Coded string to be sent by the Ajax Call
var header = {‘Authorization’:'Basic ’ + auth};

function callFunction(url,methodType,callback) {
async: ‘true’,
url: url,
method: methodType,
headers: header,
success: callback,

for(var i =0; i< respJson.value.length; i++){
//Do some cool stuff with the info

I believe as you mentioned that POST could work.

As far as Odata I have some examples with requesting BAQ with parameters.

1 Like

I will try to post something on Monday. It didn’t look like I could post a new topic there so we’ll have to see. The Flow does requires, I believe, a license with premium connectors and a On-Premise Gateway to be installed. Neither are to difficult to overcome.

I’m sure the mods would let you post a showcase like that where you’re leveraging the Epicor API

One slight correction. The published Rest APIs are webapi not wcf. A common misunderstanding since wcf does have a flavor of rest that is used by social and ecc.

Good to know, thank you!

I think Calebs description is pretty spot on.

OData is a nice abstraction if possible. It’s certainly the model we are looking at for many things going forward. If you tore apart Mobile CRM or Active Home Page you would see a lot of OData BAQ and OData Service work going on.

The one thing tarnishing a bunch of conversations around the OData end points is the leveraging of UpdateExt under the covers for OData Updates. UpdateExt is a wonderful abstraction with a rightly deserved bad reputation we are trying to correct so appreciate all help from the community in forcing us to correct it.

UpdateExt is a ‘partial graph’ update API. When updating a row, you don’t need to fill in all 400 columns with data to do an update with it. If you need to update 3 columns, provide the 3 columns and the PK to the record - voila update. This is the foundation to the update processing in OData. Unfortunately, anyone spelunking through an API like SalesOrder.MasterUpdate() will know, some forms do some complex logic - sometimes a process of several server calls - to accomplish an ‘Update’ for the form.

Historically, UpdateExt was not used in heads down app updates. It’s a bit heavier than the vanilla Update as it does more for you. Do to this lack of dog fooding we missed having the same fidelity on the server UpdateEXT and the ‘client update flow’ that would entail several methods referenced by the others - changex, sety, etc type server calls. Those efforts were not added to the ‘UpdateExt server intercepts’ in all our modules. This is what is quickly changing.

Since MobileCRM, Active Home Page, EDD, some mumble, mumble new products and features are starting to use REST in general and OData specifically, we are finding these issue before you and also instituting better automated testing in this area as we recognized the pain points and pattern problem.

Perfect? I hope and wish. I assume we will still have gaps and hence the patience comment and request for some enthusiastic feedback if you find an issue with UpdateExt. Hopefully someone looking at this thread in a year or two will be going - what’s the big deal, I’ve never had an issue with UpdateExt or OData Update

Absolutely post it here and we will move it there


Thanks, Caleb. That’s very helpful!

We have lots of UD fields (used them all in E9 without extending) on the SO, so I guess SubmitNewOrder won’t work for us, unless we followed up with an update for the UD fields. Did you try that? Any negatives with that idea?

no… UD fields should ride along with the underlying update server call. If you make a second call either call can fail and you are left with data corruption. Did you mean fields or tables?

fyi - I don’t think I have a whitepaper on User defined columns in an update scenario but they are in the tableset being updated. Send them in a single call and the ICE framework will pull them apart and update the db.

We also use some of the pre-populated UD field such as Character01 from E9. I would guess that the method worked in E9 because that field was part of the System Table.

I think you could definitely use an Update call after using SubmitNewOrder. We, unfortunately, couldn’t/didn’t want to do that. We added a UD column that we could check against to make sure that we didn’t duplicate the order that was coming in from any external service using their unique transactionId. So we added a Data Directive BPM on the OrderHed table, to prevent that. We wanted to make sure, whatever BO was adding the order, it would keep it from adding it. Maybe overkill, but that’s the approach we took, right or wrong I guess.

Also SubmitNewOrder will not add Misc Charges(at least at the OrderHed level). You’ll have to do that in a separate call even if you pass it along.

The UpdateExistingOrder method looked promising too but that exhibits all the same issues( and also doesn’t return a response payload). If you can’t tell already, I’ve been playing around trying to find the quickest method to add an order that would look like it came from the Order Entry UI without having to make all the calls it makes.

Here is the zip file of Microsoft Flow (don’t open and modify it directly or it won’t import). It’s tailored to our dev/test environments so bear in mind it will need adjustments. You’ll need a Flow Plan 1 or greater and the On-Premise Gateway installed on a server. Or you can rework it to use the standard HTTP connector and call your App server(s) directly if you have them exposed externally.

When you import, it will ask you to update the Connection Properties or add new ones.

I believe you can get free trial to use the Premium Connectors (maybe someday Epicor will have some connectors in this category).

If anybody gets it to work, let me know. This is the first time I’ve exported and not imported into our company environment, so I’m curious how it works for others. (6.4 KB)