After the conference I learned about the REST API and was very excited to try it out. We followed the REST Implementation Documentation from Epicor Help along with the REST Overview Novel that Bart put together.
When trying to access the first example https://YourServer/YourShare/api/v1/Erp.BO.SalesOrderSvc/SalesOrders
I got a 404 error - File or Directory not Found and I didn’t receive a prompt for credentials. So one by one I started taking out parts of the URL string and received 404 errors until I got down to just https://YourServer/YourShare/
Here I get a 401 error - invalid credentials, still with no prompt for credentials. (I am changing “YourServer”, “YourShare” to our server and the valid application by the way).
When we drilled into our connections on the management portal we noticed that there is no API folder, does that have anything to do with it?
Hi! Have you checked if you have rest services enabled? I don’t remember if it is available in 10.1 but there is a window called Company Configuration and License tracker something like that. In there you should find if you have rest services enabled.
Sorry for the late response we’ve been swamped the past two days and haven’t had a chance to play with this again.
We are accessing from the server and
Here is our current bindings
Then after we set our bindings we configured SSL Settings on the ERP Application Server per Epicor Help - Rest Implementation - Activate and Configure REST
there should not be api folder, it is ASP.NET routing in the code only.
You have some configuration problem. For example, we saw that error when web.config with wrong handler order was located in the Default web site root folder, like c:\inetpub\wwwroot.
Olga is referring to my problem which we solved last week. There was a rogue web.config file in my web root that switched the order of the handlers. “StaticFile” was given precedence over ASP.NET, so IIS was just looking for a /api folder which doesn’t exist. The result is a simple 404 error like any other bad URL and nothing logged in the Event Viewer. It’s really frustrating to track that down when your error messages have no context.
It’s actually an interesting conversation on deployment options. The default most folks are used to doing is that classic add a new app under the default web site
So for example, I have three instances on this VM:
But one rogue web.config as mentioned above can mess things up. Additionally, with the ability to bind many different DNS names to a single box via Site Binding, it is making me start to look at an ERP instance per site a lot more.
Example:
That’s it. We’re not sure how it got there but we were fairly confident that it didn’t belong there. Upon inspecting the file, we noticed that the order of the handlers was causing the problem. In a typical setup, this file doesn’t even exist in that location (web root for Default Website in IIS).
You can manage things manually as it’s just iis app 101 but there be dragons. To keep it as simple as reasonable, default website is what is supported in the tooling.