REST API moving from 10.1.400 to 10.2.300


So I have an API I was working on using express.js and mssql in node.js to run queries that get orders, shiptos, users, customers, and what not with multiple app.gets using /epicor/orders, /epicor/users, etc. going directly to the SQL db to get the necessary information then being treated before being sent to a mobile/web app built using React Native for out shipping department that drivers can use to map their routes and has built in GPS integration and for customers to be able to track where their orders are at.

Things are still in testing phases and I am using a static DB that I refresh every so often to pull in new orders so I have not moved it into a live production environment and probably won’t be at that point until the next 3-4 months. We are currently on 10.1.400.38 and are in the process of moving to 10.2.300 sometime this year. I know that there is REST services that were introduced in 10.1.600 and want to know how to best go about transitioning what I currently have into something that works best for the new version of Epicor while keeping some of my same original API.

If I have to do a full rewrite using c# to take full advantage I don’t mind (as I’m dying inside) as my current DB is in Azure and to my knowledge we cannot use (aka not approved) an Azure SQL DB in an official Epicor production environment.

REST is REST you can use with whatever framework or language you want. There are a TON of posts on here about REST and how to get started on them including a very through one by @Bart_Elia

It doesn’t have to be in C# though there are some helper libraries that some of us have written for .net and Epicor REST specifically. But that’s the beauty of REST you don’t need to write it in any particular language.

I was looking through that a little earlier today and need to take some time to sit and read it.

What are in these helper libraries? I am assuming this is the one that you created? I saw it on NuGet.

Yeh there’s a nuget and a few other helpers around here look in github

I’ll have to play around with those when I get a chance.

We contracted the dev of the mobile app to a third party so I can get away with using a static Azure SQL db until we move it into our Azure environment so I’ll have to see what some users here have come across.


Also one quick question.

I was looking over the REST documentation and the url calls can get pretty out of hand with filters if you only want certain columns. A lot of my current calls i.e. use queries that are coded into the js file that I can add or remove fields from and have joins for order headers, details, lines, etc. with usually about 15-20 columns of data, and not have to worry about changing the url call.

I am assuming the urls are static and can’t be adjusted unless I create multiple BAQs and just use those as my url calls instead? One of the main reasons, besides being on 10.1.400, that I went with using node.js was the ease of being able to add and remove fields from my queries in the code and redeploy easily.

Yeah columns are passed in in the URL with baqs you can get only the columns you want as you mentioned.
Frankly I do 99% of my REST with baqs and ubaqs

1 Like

This is the one of the best pieces of advice that I have gotten from Jose. The benefits:

  • Keeps business logic out of the UI
  • Improves upgrade path by abstracting away signature changes in Business Objects
  • Reduces wire traffic by doing joins and selecting columns at the server