Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Shape the future of the Fabric Community! Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions. Take survey.

Reply
DouweMeer
Post Prodigy
Post Prodigy

Layers between on-premise ERP and Power BI?

I've been always rather ignorant working with Power BI. Having IT establish my data connection once and then me just replicating their trick for new reports. But now I've worked quite some years with Power BI, I'm starting to no longer indulge myself to be ignorant. 

 

I was wondering, which steps are there between an SQL based on-premise ERP and Power BI? Who can you expect to ask about those topics in an enterprise company? I presume the layout by departments and roles are mostly similar. An IT guy (generalizing here) or an Data Analyst/ Data Engineer are quite universally in different companies I presume. 

 

  • There's an API and there are Servers. I presume here you have the database team.
  • Then I remember there are IP addresses. Are they fixed, or do they change? I presume here it can be just but normal IT who's first line support on-site.
  • Then there's a fire wall, something with whitelists but different than whitelisting websites in a browser. 
  • I also have some intermediary software between Oracle and Power BI as Power BI doens't connect natively to it. Those contain IPs as well? I forgot where it is. 

I don't how it be, but I expect something like 

 

  1. API 
  2. Server
  3. IP address
  4. Fire wall
  5. Pbix? 

I presume there's also a shell of governance that sits within the Admin roles on Service that takes care of things I'm not even aware of. 

 

Would someone be able to tell me step by step how data flows from an ERP to my Power BI report? I'd like to see the big picture and stop being ignorant :). 

4 REPLIES 4
christinepayton
Super User
Super User

If I am understanding the gist of your question, what you are missing is the Power BI Gateway - the gateway is what lets Power BI in the service "talk to" your on-premise sources. In the case of Oracle, if you're using ODBC you'll need drivers to connect to it in addition to that. 

 

https://learn.microsoft.com/en-us/data-integration/gateway/service-gateway-install

That's probably the gist indeed. I'm just a chemist from education, so I do see labels flying past like ODBC and I roughly know in which context it is spoken, but I have no visualization what it does or what it tries to solve. And from Power BI's perspective, what it can break :).  

 

I also asked this question on other platforms, like ChatGPT. But from my side, not idea on ODBC or who manges it, Network Infrastructure, Security, etc, no idea who to go to. I just have no expectation on it. All I know, it is not me :). 

 

Like:

Power BI -> ODBC -> API -> Server -> XML -> Network Infrastructure -> Security -> Gateway -> Power Query -> JSON -> Power BI data model -> DAX -> Visualization?

 

Or am I missing steps? Or did I misplace them?

 

ChatGPT's answer:

 

The process of transferring data from an on-premise database to an analytical tool on your computer typically involves several components and technologies. While the specific implementation may vary depending on the systems involved, here are some common elements and considerations:

 

  1. Database Connectivity: You need a mechanism to establish a connection between your computer and the on-premise database. This can be achieved through database-specific drivers, protocols, or APIs (Application Programming Interfaces). For example, if you're using a relational database like MySQL or Oracle, you might use ODBC (Open Database Connectivity) or JDBC (Java Database Connectivity) drivers to connect.
  2. Network Infrastructure: The data transfer relies on the underlying network infrastructure. IP addresses play a crucial role in routing data packets between your computer and the on-premise database. Firewalls, routers, switches, and other networking components ensure secure and reliable communication between the systems.
  3. Security Measures: To protect the data during transfer, various security measures come into play. This may include encryption techniques like SSL/TLS (Secure Sockets Layer/Transport Layer Security) to establish a secure connection, VPNs (Virtual Private Networks) for secure remote access, or authentication mechanisms such as username/password or API keys.
  4. Data Extraction: Once the connection is established, you need a method to extract data from the on-premise database. This can involve writing SQL queries or using specific database tools to fetch the required data. Some databases also provide APIs or export functionalities to retrieve data in a structured format like JSON or CSV.
  5. Data Transformation: Depending on the requirements of the analytical tool, you may need to transform the data into a compatible format. This could involve data cleaning, aggregation, filtering, or joining operations. Extract, Transform, Load (ETL) processes or data integration platforms are often used to perform these transformations.
  6. Data Transfer: Once the data is extracted and transformed, it needs to be transferred to your computer. This can be achieved using various methods such as HTTP(S) requests, file transfer protocols (FTP), or specialized data transfer protocols like WebSocket or AMQP (Advanced Message Queuing Protocol).
  7. Data Ingestion: On your computer, you would have an analytical tool or software that can consume the data. This tool could be a standalone application, a web-based platform, or a programming library. The data is ingested into the analytical tool for further analysis, visualization, or processing.

 

It's important to note that the specific implementation and technologies used may vary depending on the database, analytical tool, and network infrastructure in use. Organizations often have their own customized setups and configurations to ensure data flows securely and efficiently from an on-premise database to an analytical tool.

Yeah, it's not really linear is the thing - I'm not a data engineer, so my understanding is limited, but as I understand it the gateway is what bridges the gap between the web and local, so it gets you through the firewall. It's installed on a local server and handles the communication between the two. 

 

The drivers (I think) give the framework of the language that the database and the gateway need to talk to each other... so Power BI says "I need xyz" and that has to be translated to something the local data server can understand. Obviously since MS SQL is a Microsoft product, it's easier for Power BI to talk to it, so no extra drivers are needed - but Oracle has some proprietary extra bits, hence the need for the drivers. All of the data flows through the gateway on the way to the web app. 

 

The security config is in the connection settings in the web app end of gateway - there's a connection per on-prem data source with the credentials and auth type... it passes those to the on-prem source when it requests data. Usually you use service accounts for the credentials in the connections. Users need permissions on both the gateway and the connection in order to use it successfully when scheduling refresh. 

 

 

This week I was hit with a "misdirected request - 421" which threw a spanner in the works where Power BI Admins stated it is the API and developers said it Power BI. Eventually nothing was done and "suddenly" it works again. 

 

I always feel like it is fixed by those who are not spoken to, just hear the commotion and be like "Ah... perhaps I should have done what I done yesterday. Let's undo that and hope no one notices it was me". 

Helpful resources

Announcements
November Carousel

Fabric Community Update - November 2024

Find out what's new and trending in the Fabric Community.

Dec Fabric Community Survey

We want your feedback!

Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions.