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.
No as far as I know. But you don’t have to use it for everything. What’s the use case?
-Jose
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.
Thanks. I probably worded that poorly. I’m not looking for the list of BAQ’s to show up in the excel grid. Rather the Import data screen, when connected to an ODBC or SQL data source will show you the list of ‘tables’ in your database, and then you can select one or more to pull into either excel or the query manager.
But with rest, it seems, you can only directly retrieve the one BAQ and you have to know the URL in advance.
Correct, the scenario you are describing is more of a data mining type scenario. You may want to look at the EDD product to see what I mean. That gives you the flexibility you mention but with a level of security in mind.
Excel or any product going directly to the db is not encouraged. Not banned, but you should go in with eyes wide open since you are bypassing all security and calculated columns when going directly to sql. That’s why the design of the feature is to package up your query in BAQ and then consume it in Excel or other clients.
My ultimate problem is that I’m using a Data Warehouse automation product (TimeXtender) that lets you pull in SQL tables and it builds the data warehouse and the SSAS Cubes.
However, if I want to build this to work with Epicor SaaS that allows no direct access to SQL but does allow Odata access, I need to use a 3rd party Odata ODBC driver. However, like other ODBC sources, it connects to the ‘source’ and then you specify the ‘table’.
I guess I’ll have to work with the ODBC driver folks to figure out how to make this work.
If tools are only dealing with SQL today, those tool companies are going to have a very smaller customer base in the near future.
OData or Graph QL are becoming bare minimum features
@Bart_Elia Epicor needs to join the Open Data Initiative https://www.microsoft.com/en-us/open-data-initiative and map their data to the Common Data Model https://github.com/Microsoft/CDM
@mchinsky check out the new PowerBI release. They added the ability to ETL from a REST API to a hosted SSAS instance. They are also adding XMLA endpoints to the PoweBI models so you can query the data from any app that supports it (Excel, SSMS, PowerBI, EDD if they add it). https://www.jamesserra.com/archive/2018/08/power-bi-dataflows/
I was playing around with Data Flows myself. I think this is a key move because it separates the ETL that was embedded into your PowerBI document, into a standalone function that creates governed simplified data that is accessible to all PowerBI users.
The problem I found is the PowerQuery in PowerBI online has significantly reduced functionality from the desktop version. For example, I couldn’t find any way (without writing your own M code) to simply tell it a column that comes over as Text is actually a number (because of the totally broken way Epicor has configured BAQ’s in both the V1 & V2 implementations). All data from the BAQ’s comes over as text and you have to use the Powerquery tools to convert into numbers, dates etc.
The only workaround I found was to do all the work on PowerBI desktop. Then go into the ‘advanced mode’ that shows the ‘M’ that gets created. Then literally copy and paste that into PowerBI Data Flows advanced editor.
Epicor still needs to fix the way they publish BAQ’s in order to not have to create a separate connection for each query which is slow and clunky for projects you create. You should be able to establish one connection (like you do with SQL Server) and then pick the ‘tables’ which should be each individual BAQ.
@Bart_Elia I agree with your statement about needing to move from SQL to Odata as a tools company. But Epicor needs to actually comply with the Odata standard.
As far as I know, and please correct me if I’m wrong, there is no way to connect to the BAQ Service, and then pick off the BAQ’s you want to use in Excel or any other odata consumer. You have to establish a separate login & connection for each and every BAQ you want to consume.
The BAQ’s should appear the same way, for example, the Sales Order Service does where you see all the ‘tables’ of data the sales order provides.
We were looking at options on BAQ but BAQ service is not the resource - the baq itself it the resource. That means the tables are specific to the individual BAQ as a service. If you read that as a cop out, I’ll take that abuse. 
We need to support a baq hierarchy as a service to deliver what I think a lot of folks desire. We did this for Electronic Compliance for example - https://www.epiusers.help/t/ssrs-psa-on-filtering-subreports-performance-fixing/55699/12
If we treated BAQ itself as an end point, the meta on that would take out a few datacenters trying to generate the meta. The generators out there like Swagger are just not built for large data that would be visible under all the BAQs visible to a user. We’ve scanned more than a few generators and scoped what it would take to create an incremental loading mechanism for all the meta (open Customer and you’ll see the need as well).
It’s an open question and the PO over REST @bconner has looked at this a few times. There are some other activities underway they are ahead of this on the delivery train atm but it is an interesting problem we wish to tackle.
One option would be a check box on the BAQ setup such as ‘enable REST Access’. Then a company would only check this on the BAQ’s they need to provide external access to which is likely far fewer (less than 50) than total BAQ’s in the system.
When you generate the BAQ hierarchy you would do so for just those with REST Access enabled
You should look at the BAQ security added in … ?10.2.300? and the Access Scope feature added to 10.2.400.
Both were added to manage security on BAQ and REST services.
REST is the basis of everything going forward so definitely start thinking of how to apply it.
