Creating a Data Source in BI Portal looks like a two-minute form, but the type you select is permanent: it decides where data comes from, whether Live fetch is even an option, and which tabs — selection filters, file upload — appear on the detail screen afterward. Picking the wrong type means recreating the source later, not "fixing" it.
The five source types
- PostgreSQL / SQL Server — connects to a registered database and a table, view, or custom SQL; supports Live
- Lakehouse / Warehouse — connects to Microsoft Fabric OneLake; supports Live
- IDATA SAP API — connects to an iDataEngine outbound SAP service; supports Live, and is usually the right choice when you are "moving an SAP report into BI"
- Web API — connects to any registered Web API service; supports Live
- JSON / Excel / CSV — an uploaded file; cache only, no Live mode, refreshed by re-uploading
Typical creation flow
- For database or Fabric sources: select the connection, then a table/view or SQL, preview roughly 100 rows, fill the Object ID (
DT_...) and name - For IDATA SAP API: select the service, preview columns, save — then immediately fill in Filters (Selection Fields) on the detail screen, otherwise the first sync can pull an unfiltered, very large result
- For Web API: select the service, run Test API & Save Columns, save
- For files: upload — columns are detected automatically; there is no Live mode, so a stale file means a manual re-upload, not a broken connection
Why it matters
Teams that treat "create a data source" as a generic step end up with SAP data sitting in a file-type source with no refresh path, or two separate SAP systems awkwardly forced into one source instead of a Flow. Getting the type right on day one is the cheapest decision in the whole BI Portal chain — and the most expensive one to undo later.