Heildarmynd

Þrír aðilar — dk, DataCentral, Azure-stakkur — vinna saman á einum stað. Notandinn sér aðeins dk-framendann.

UPPSPRETTA
dk+ REST API
GL · viðskiptavinir · birgjar · reikningar · greiðslur · áætlanir
FLUTNINGUR + GEYMSLA
ADF + Azure SQL
raw · staging · gold
MÓDEL
Power BI semantic
dk Financial Overview · dynamic RLS
AFHENDING
DataCentral broker
Mínar síður (innfellt) · sjálfstæður portal
→ HTTP poll
→ ELT
→ DirectQuery / Import
→ embed token

Lögin fjögur

Hvert lag hefur eitt hlutverk og skýrar mörk gegn næsta lagi. Þetta heldur arkitektúrnum endurnýtanlegum og auðveldar að skipta út hluta án þess að allt brotni.

Lag 1 · Uppspretta

dk+ REST API

Endapunktar sem dk veitir fyrir bókhaldsgögn. dk Insights er read-only neytandi — engar breytingar fara til baka.

  • Aðgangur stýrður með API-leyklum eða OAuth scope.
  • Lyklar geymdir í Azure Key Vault.
  • Pagination og rate-limit tekið með í pipeline.
Lag 2 · Flutningur + geymsla

Azure Data Factory + Azure SQL

Metadata-driven pipeline keyrir á tímaáætlun, sækir öll svæði fyrir alla virka tilraunaviðskiptavini, skrifar í raw, breytir í staging, byggir gold.

  • control.entities · control.tenants · control.sync_runs.
  • Watermarks fyrir incremental hleðslu.
  • Re-run er idempotent.
Lag 3 · Módel

Power BI semantic (PBIP)

Eitt módel — dk Financial Overview — þjónar öllum tilrauna­viðskiptavinum. Stjörnu­skema með FactGL, FactAR, FactAP, FactCash og víddum: DimCompany, DimAccount, DimDate, DimCounterparty.

  • Versionerað í Git (PBIP format).
  • Dynamic RLS á CompanyKey.
  • DAX measures eru sameiginleg eign.
Lag 4 · Afhending

DataCentral broker → dk-framendi

DataCentral er sá staður sem ákvarðar hver má sjá hvað. Server-to-server samtal við dk-bakenda; embed-token aldrei búinn til í vafra.

  • Embed Session API · short-lived tokens.
  • Aðgangsréttindi og RLS — bæði.
  • Audit log á öllum sessions.

Gagnaflutningur

Pipeline er metadata-driven: ein kjarna­pipeline les control.entities og keyrir per-entity copy. Bæta við endapunkti = bæta við einni línu í control-töflu.

SkrefHvað geristÁbyrgð
1 · TriggerADF schedule trigger eða manual runADF
2 · Read controlSækir lista af virkum entities × tenantsADF lookup
3 · For-eachPer entity/tenant: ná í lykla úr Key Vault, kalla á dk+, raw writeADF copy + REST
4 · Staging transformSQL stored procedures normalize, parse, type-castAzure SQL
5 · Gold buildStjörnu­skema fact + dim töflur uppfærðarAzure SQL
6 · Model refreshPower BI dataset refresh kallað gegnum RESTPower BI Service
7 · LogSkrá í control.sync_runs; villur til Azure MonitorADF + Log Analytics

Vöruhús og módel

Þrjú lög í Azure SQL — raw, staging, gold — og eitt Power BI módel.

raw

Eins og kemur

JSON-payload úr API skrifaður beint, með ingestion timestamp. Engin breytni.

staging

Útflöttur og hreinsaður

Eitt-til-eitt töflur með typed columns, lykill á (TenantKey, EntityKey, NaturalKey).

gold

Stjörnu­skema

FactGL, FactAR, FactAP, FactCash + víddir. Þetta er það sem módelið les.

Reikningskortlagning

GL → staðlaðir flokkar

Reikningar viðskiptavinarins eru kortlagðir á staðlaðan dk-flokk (Tekjur, Kostnaður seldra vara, Rekstrarkostnaður, o.s.frv.). Ókortlagðir reikningar birtast í gagna­gæða­skýrslu — viðskiptavinurinn (eða bókari) klárar kortlagninguna í gegnum DataCentral admin.

Afhending og embed

Tvær leiðir, einn broker. Hvort sem notandinn er staddur í Mínum síðum eða DataCentral portal, þá er sama embed-flæðið undir.

Innfellt

Mínar síður

  1. Notandi auðkenndur í dk portal.
  2. dk-framendi spyr dk-bakenda: "hvaða skýrslur?".
  3. dk-bakendi server-to-server til DataCentral.
  4. DataCentral býr til embed session með RLS claim.
  5. Token skilað til dk-framenda.
  6. Skýrslan birtist innfelld í iframe.
Sjálfstætt

DataCentral portal

  1. Notandi auðkenndur með Microsoft Entra External ID.
  2. Portal sækir leyfi notanda.
  3. DataCentral býr til embed session með sömu RLS claim.
  4. Skýrsla birtist í portal-vefnum.

Öryggi og RLS

Tvöfalt aðhald: aðgangsréttindi ákvarða hvaða skýrslu notandi sér, RLS ákvarðar hvaða línur hún skilar. Hvorugt eitt og sér er nóg.

Aðgangsréttindi

Hvaða skýrslu má opna

DataCentral metur leyfi notanda áður en embed session er búin til. Engin token = enginn iframe.

RLS

Hvaða gögn módelið skilar

Dynamic RLS á CompanyKey; userprincipalname → CompanyKey-listi gegnum bridge töflu. Power BI síar fact-töflur sjálfkrafa.

Sjálfvirk próf

RLS test pack

Áður en módel er gefið út keyra prófar með ólíkum notendum og félags­samsetningum. Niðurstöður skjalfestar í CI.

Audit

Hver sá hvað hvenær

Allar embed sessions, RLS claims og skýrslu­sýnir skráðar í audit.session_log. Geymt í 12 mánuði.

Rekstur og eftirlit

Hvað gerist þegar pipeline brotnar klukkan 03:00? Sjálfkrafa endurkall, runbook, og skýr eign hver bregst við.

  • Azure Monitor + Log Analytics safna ADF run logs, SQL audit, Power BI refresh logs.
  • Azure Alerts á: bilaðar pipeline runs, refresh failures, SQL DTU spikes, abnormal embed token rate.
  • Runbook fyrir hvert venjulegt bilunarmynstur: 401 frá API, time-out, schema drift, ókortlagðir reikningar, RLS test failure.
  • GitHub Actions deilir IaC, ADF artifacts, SQL migrations og PBIP módelum til þróunar/prófunar/framleiðslu.

Lykilákvarðanir

Fjórar ákvarðanir sem skilgreina arkitektúrinn. Sjá nálgun fyrir heildarlistann (12 ákvarðanir).

A · Geymsla

Azure SQL fyrir MVP

Endurmeta þegar volume vex; hugsanlega Synapse eða Fabric í v2.

B · Multi-tenancy

Sameiginlegt módel + dynamic RLS

Stærri viðskiptavinir geta kallað á dedicated workspace síðar.

C · Embed eign

DataCentral er broker

dk-framendi býr aldrei til BI tokens. Skýr ábyrgð.

D · Refresh tíðni

Daglega í MVP

Margfaldur refresh á dag og nálægt-rauntíma metið eftir notenda­endur­gjöf.

Næst

Skýrslugjafarammi

Hvernig staðlað skýrslulag þjónar mörgum gerðum viðskiptavina — frá smáfyrirtæki upp í bókhaldsstofu.

Næst: Skýrslugjafarammi Skoða mockup