This is an excel issue @Banderson not an Epicor one. Excel requires that the data sources use SSL.
2 Likes
Alas, no this won’t help you with ssl. This is more about making it easier to write custom apps that’ll let you log in to epicor without having to write your own login ui.
Strict SSL requirements are going to remain I’d expect they will get more strict over time. Starting in July chrome (for example) is going to report all non-ssl (http) websites as insecure.
That said we know that ssl setup and cert distribution as well as exposing your rest services outside of your network are challenging for many of you. We made a first pass at generating and distributing certs for you in 10.2.100 and are likely to return to that to try and improve it further.
Would any of you be interested in a service where we provide a way to expose your on premise rest services on our saas (a proxy) where we take care of all the ssl certificates, security setup, ddos protection, etc for you? The idea being a way to just turn on “expose rest over the internet” and we set up a tunnel automatically?
Simplified Authentication - $5
API Keys - $30
Interactive documentation - $10
Adding context info - $5
Webhooks - $40
Other (Improved Error Handling or more verbose/descriptive messages) - $10
Let’s Encrypt is ya’lls friend 
1 Like
lets encrypt is great (and they take donations folks!) but last we looked they still only issue public domain certs so it’s trickier to use with internal domains. Still using a public ca makes life a lot easier if you can get over that hurdle.
1 Like
Is it possible to have the API include existing Business Logic? Example: Post to the ERP.BO.JobEntrySvs/JobMtls requires fields such as Description. Ideally the Part Number of an activated part should be accept the default of the description. Similar but more complicated issue when it comes to the EstUnitCost and other required fields.
Simplified Authentication - $15
API Keys - $10
OData4 - $0
OData expanded $metadata - $10
Open API 3 - $0
Interactive documentation - $0
Adding context info - $10
Webhooks - $55
Other - $0
Internal apps it’s easy to get it to ignore the SSL errors, External you just would NEVER want to do that. We happen to have a GoDaddy SSL cert but if someone didn’t want to pony up for it but still make use of the API over WAN it’s at least possible
the API hits the BOs so all terms and conditions should already apply. BPMs will work too.
I don’t want to hijack the thread troubleshooting this if it already exists. Here is a new thread → REST API - Job Entry Add Material default fields - ERP 10 - Epicor User Help Forum
Hi!,
Simplified Authentication - $40
API Keys - $15
OData4 - $15
OData expanded $metadata - $0
Open API 3 - $0
Interactive documentation - $0
Adding context info - $0
Webhooks - $30
Other - $0
carlosqt
PSE
Not sure if this is relevant request or how it would work but it would be nice to be able to get/run reports.
1 Like
Thanks! I see that service doesn’t exist in the landing page(at least for 10.1.600.8) as an option but specifically using the URL got me there. I see that there are only custom methods, no oData methods? Maybe they aren’t necessary just an observation.
Only ‘Full’ BO services can support OData - those services with UpdateExt / GetRows / GetByID. Custom Methods apply to everything.
Unfortunately the ‘Table of Contents’ Help Page is done against the Full BO / OData Services, not everything.
Ok yes i didn’t put this one on my list to ask you all about, but there’s an item on the must-do list that says - the docs need to actually cover all services that are available. Sorry we messed up a bit there leaving non bo things hidden ¯_(ツ)_/¯ and want to do a whole new revision with a much better interface as well for the interactive docs.
Also on this point… another thing not on my list of questions to you all and further down the maybe eventually list is exposing services for reports like we do for BAQ where there’s a service per-report and you odata against it to get access to the output data. Or call a method on it of course to execute the real report. Not on the board for vNext at this point, but something we’ve debated a bit.
Been meaning to swing back by here and say thank you for all the helpful feedback.
Thanks! This kind of feedback is pure gold to us.
1 Like
Hey all I wanted to revive this topic to give you all a heads up on what we’re now planning over the next (most likely 2) major releases for REST services enhancements.
- API Keys
We’re now planning api keys to roll out starting with simple keys for just tracking which application is using rest, then expanding to include keys that can also have authentication built in (they key is your login) and security claims to lock use of the key to specific actions only (key includes a set of specific claims like “can read sales orders” and you can’t do anything that’s not in the key’s allowed set of actions). Keys will eventually become required for all rest and you’ll be able to create them yourself for your applications & integrations. We think this is going to make api → api integrations like jitterbit ↔ erp much simpler and safer as well as give us all a way to see more clearly how the services are used and what applications are using what services.
- OData4 + Expanded $metadata
We’ll be adding odata v4 compatibility and extending metadata to include as much additional information as possible like captions, numeric formatting info, etc. Additional minor changes such as enabling context information in the url (company, site, workstation, employee, etc) will come along for the ride even though they’re not all strictly odata v4 requirements. This won’t be that dramatic a change from what you are used to now, a few new $x capabilities and much better metadata.
So that’s the plan for the moment, if there’s anything in there which is alarming or disappointing please let me know. As these features start to light up i’ll be looking for some feedback from you rest consumers so stay tuned.
ps. no, we are not deprecating any rest capabilities in .400 so odata v3 will continue to work, etc. Eventually requiring the use of api keys is the only breaking change we have planned currently.
4 Likes
Both of those are exciting to hear about.
Do you have any information you can share on how those rights/claims will be setup within the GUI?
Lack of context is a semi-frequent issue that I have to workaround with my implementations. Thanks for including this even though it isn’t specific to odata v4!
We’re just beginning to design the key management user experience now and security keys is a second phase so nothing to share yet. You can however guess from my use of the word claims if you know what those are that we’re thinking on how to improve our overall security lockdown setup user experience and not just for keys.
2 Likes