Official partner
Data from SAP modules (FI, CO, SD, MM) in Power BI and Azure
SAP modules (FI, CO, SD, MM) without complex middleware
Yres has no separate connector per SAP module. You reach FI, CO, SD, MM or any other module through the OData services that belong to it, which your SAP administrator activates in the SAP Gateway. You connect each service in Yres as an OData source; the entities in that service become tables in an Azure SQL database in your own Azure tenant. Yres ships no fixed list of services: what you can load depends on what your SAP landscape exposes. The modules come together in the data warehouse for Power BI.
At a glance
- How you reach a module
- Through that module's OData services in the SAP Gateway. There is no separate connector per module and no bundled list of services
- One source per service
- The address you enter is the service root of a single service: https://<host>:<port>/sap/opu/odata/<namespace>/<service_name>/
- Inspecting the data model
- Append /$metadata to the service root to see the entities and fields of a service
- Incremental loading
- Per entity, with a delta column on a reliable changed-on field. If an entity has none, you load it in full
- History
- FULL and RELOAD keep history (SCD2); only OVERWRITE removes it
- Extra headers
- If a service requires an additional HTTP header, you pass it as a header/value pair
- Permissions and secrets
- The SAP user needs read authorization on the underlying data; the password is stored in your own Azure Key Vault
What you arrange yourself
- 1Decide with the process owners which data you need per module and ask your SAP administrator which OData services deliver it.
- 2Have those services activated in the SAP Gateway (transaction /IWFND/MAINT_SERVICE) and check that the status is Active.
- 3Make sure the SAP (communication) user has read authorization on the data of every module you want to load.
- 4Review the data model of each service through /$metadata and note which entities have a changed-on field.
- 5Add one OData source per service in Yres, select the entities and choose the load type per entity.
When you need this — and when you don't
A standalone connector is enough if…
If your question concerns a single module and the standard reports in SAP already answer it, there is no need to move the data.
Yres adds value if…
Yres earns its place when a report has to connect several modules, for example sales orders from SD with postings from FI and stock from MM, and those figures also have to sit next to non-SAP sources. The modules then end up as tables in one database, where you can join them.
Frequently asked questions: SAP modules
Does Yres have ready-made extractions for FI, CO, SD or MM?
No. Yres does not ship a fixed list of SAP services or tables. You load the OData services your SAP administrator activates; Yres reads the data model of each service and you choose which entities to load.
How do I see which fields an SAP OData service contains?
Append /$metadata to the service root of the service. That document describes the entities and fields. Yres also retrieves this metadata itself, and supports gzip-compressed metadata, which SAP services require.
Do I connect all modules at once or per service?
Per service. The address of an OData source is the service root of a single service, so every service you want to load becomes its own source in Yres. The SAP user you enter needs read authorization on the data behind that service.
Can I load large transaction tables from a module incrementally?
Yes, if the entity has a reliable changed-on field. You set it as the delta column, after which Yres fetches only new and changed rows. Entities without such a field are loaded in full; in both cases paging runs through the OData next link.
Full technical description in the knowledge base →·Last reviewed:
Data warehouse automation that runs in your own Azure
Built for organisations on Azure and Power BI. Yres connects your sources, keeps the history and promotes changes in a controlled way, without manual work.