Teknik
Data Lake och Compass
Senast verifierad
Frågan bakom den här sidan är oftast "hur får vi ut M3-data till Power BI eller vårt datalager". Den dokumenterade vägen har tre steg (publicering, lagring, uttag) och de beskrivs i två olika doc-set med olika versionsserier. Här är stegen, med sidorna som faktiskt beskriver dem.
Steg 1: M3 publicerar via Event Hub
Publiceringen konfigureras i Data Lake Publisher under M3:s administrationsverktyg, och kräver rollen M3-DLSubscriptionAdmin. När en tabell väljs för publicering skapas Event Hub-prenumerationer, och databashändelserna för tabellen skickas till Infor Data Fabric, via streaming ingestion eller ION Messaging Service. Det är alltså händelser per tabell som flödar, inte batchexporter: valet av tabeller är designbeslutet, och det görs på M3-sidan, inte i analysverktyget.
→ Data Lake Publisher administration tasks · m3core 2025.x · verifierad 2026-08-29
Historiken följer inte med av sig själv: en tabell som börjar publiceras i dag behöver en initial load för det som redan står i databasen. Den klassiska metoden kör API-programmet EVS002MI med transaktionen Initiate, per tabell och med datum- och tidsintervall. Läs sidan för parametrarna men notera vad den själv säger: den klassiska metoden är inte längre den rekommenderade vägen.
→ Performing the classic method of initial load using APIs · m3core 2025.x · verifierad 2026-08-29
Steg 2: vad Data Lake är, och inte är
Data Lake är objektlagring i Infor OS: datat lagras i sin ursprungliga form, som BOD:ar, JSON eller avgränsade format som CSV, TSV och PSV. Det är inte en relationsdatabas och inte en kopia av M3:s databas. Det är en ström av tabellhändelser som lagrats. Objekt hämtas enligt dokumentationen via API-metoder i API Gateway eller via JDBC; lagringen är krypterad med AES-256 och transporten med TLS 1.2, vilket är svaren på de två första frågorna en säkerhetsgranskning ställer.
→ Data Lake · inforos 2025.x · verifierad 2026-08-29
Steg 3: tre dokumenterade uttagsvägar, samma frågespråk
Compass är frågemotorn över Data Lake. Den läser radavgränsad JSON och DSV-objekt och klarar joins mellan dem. Samma frågesyntax gäller i tre gränssnitt: Compass-editorn i Data Fabric, Compass-API:erna och Compass JDBC-drivrutin. Det är en egenskap värd att utnyttja metodiskt: bygg och verifiera frågan i editorn, och flytta den sedan oförändrad till API-anropet eller JDBC-anslutningen.
→ Compass JDBC driver · inforos 2025.x · verifierad 2026-08-29
→ Data Lake Compass queries · inforos 2025.x · verifierad 2026-08-29
För ett Power BI- eller Azure-uttag betyder det två realistiska mönster. Ett verktyg som talar JDBC ansluter med Compass-drivrutinen. Ett verktyg som inte gör det, och Power BI hör dit, hämtar i stället via Compass-API:erna genom ION API-gatewayen, vilket innebär OAuth 2.0 med Bearer-token och tokenförnyelse, samma krav som för alla anrop genom gatewayen. De granskade sidorna dokumenterar editor, API och JDBC som frågevägarna; en ODBC-drivrutin förekommer inte i dem, och en plan som förutsätter en bör därför verifiera det påståendet först.
Valet mellan vägarna är ett driftbeslut, inte ett smakbeslut: JDBC-vägen ger analysverktyget en direkt beroendekedja till Data Lake, API-vägen lägger uttaget bakom samma gateway, behörighetsmodell och övervakning som resten av integrationslandskapet. Den som redan har en Azure-pipeline med hemlighets- och tokenhantering återanvänder den hellre än att införa en andra åtkomstväg.
Den transaktionella vägen in i M3 (MI-anrop och BOD:ar) är ett annat beslut med andra villkor, se API och MI-program och ION och BOD. Att ett datalager läser ur Data Lake säger ingenting om hur ordrar ska skrivas tillbaka.