@NickTu are you trying to write a C# integration against the REST APIs?
Because the whole point of REST is that you do not HAVE to make dll references against the dotNet assemblies. In fact you cannot in all cases - we have C#, VB, C++, Perl, Php, Go and even Cobol clients talking to this. And many different OS and even devices that don’t have much more than a http stack.
Adding a dll reference to Erp.Contracts.BO.SalesOrder.dll to get the C# type CAN be done in Windows and dotNet but …
CAN you do that? Obviously the list above shows scenarios where it is not a possibility.
Do you WANT to? If those dlls change with a patch or a version change, you need to manually deploy and possibly recompile your integration depending on scenario.
So, a little more context and we can give better options
Thanks for the explanation. I’m just trying to follow the sample code from tkoch (above) where he updates a sales order, but also instantiate and use the SalesOrderTableset object. It does make a lot more sense to not have to reference any dll or WCF service.
That’s the real emphasis I am trying to make. During V8/E9/E10 I worry that we have been doing internal development a certain way and our customization is currently the same way and examples have historically been rather dictatorial - “Do it our way and on Windows”. That’s not what integrators are forced to do. You should have more flexibility in how you consume ERP data and dictate to us what you want and how you want it.
At the same time, I respect that giving no guard rails can be more than a little intimidating and worries about guidance and support … where are you going to get it? Unfortunately that’s kind of the trade off we all face in IT.
Is this a thing that’s coming (or exists) with E-10? I’m looking at productivity platforms right now and bring in some basic status information from E-10 may be an interesting idea in the future. (and I always dream big)
Safe Harbor, forward looking, yada yada
Webhooks in general are an interesting and valuable approach. I have hacked something similar into a coded BPM with off the shelf E10 to play with the idea. SignalR is already used in several areas in E10 (e.g. Social) and gives another interesting architectural tool.
Take a look at what is happening in Mobile CRM and Active Home Page and you can assume we are looking at options. Not breaking the heck out of existing customers is of course a priority but adding value for more interesting integrations ana capabilities is always being reviewed.
Sometimes they fail for a variety of reasons, sometimes they make it into the product and evolve. Vantage 6 to dotnet front end in V8/E9 to dotnet server v10 anyone?
Keeps the ideas coming, I’ll comment as I can reasonably do so
Does the rest help functions not work in firefox? When I click on this button in firefox, nothing happens. If I do in chrome I get the help info to pop up. Or do you think it’s something to do with my personal settings?
We ended the preview discussion board near the beginning of this year since we’re now in our second GA release of rest services and the preview was mostly for gathering feedback before we went officially GA. So that project is ended, but we may bring something similar back later this year as we’re looking at doing a vNext set of rest capabilities and are interested in your feedback.
Regardless you can always send me bconner at epicor dot com any feedback you have about the rest services.
Apologies, I hit delete a bit hastily. I’m hoping to expose only a select few services over REST to limit the business impact, and sort of ‘pilot’ the new REST interface (over the WCF foundation). With that, I don’t want to go exposing all the business objects, just a few (for example, only Customer and Territory). I’m assuming the “Enable RESTful services” checkbox is an overarching enable, and the only way to limit access is via a custom gateway that directs calls down to Epicor?
As far as I know you can only enable all or nothing, but there is no business impact to doing so. The REST interface is merely a facade to the existing WCF Services. There is no downside to exposing them all
Ahh awesome, thank you for clarifying that Jose. I thought as such, and this was actually going to be my next question but you’ve read my mind in regards to it being a facade for the WCF.
Jose is correct on implementation. The Method Security is probably the way to go. That is done at the BO level so will cover you no matter which way someone accesses the BO. If we locked down just the REST endpoints, you are just making the minimum code to do damage two lines of code instead of an HTTP URL.
If you need to lock down a service, I’d tackle it there.
If you REALLY think you JUST need to lock down REST but leave a security hole a semi can drive through in WCF, you could look at a firewall solution with content filtering. I have not played in that area of IT Hardware in awhile so I’d defer to someone with more current domain expertise and available approaches / devices.
Has anyone been able to figure out how to get odata to return the list of all BAQ’s? Not in the browser, but to an application like Excel so you can choose.
If you connect to a SQL data source in Excel, you can pick the table(s) you want.
It seems with odata and epicor, you have to explicitly know the syntax of the one baq you want to retrieve.
If you take that address from the swagger page, and use that to in the from web section in excel, it will walk you through loading a file that will list all of the BAQ’s. It looks like you can refresh that list too. It’s not Odata, it’s XML, but if I could figure it out, it must not be too hard. Not knowing your end goal, I don’t know if this does what you want or not, but it’s possible to get a list in excel.
