Javi on DataData • AI • Cloud Engineering

Sujets populaires

↑↓ pour naviguer↵ pour ouvrirEsc pour fermer

Production engineering

Modern Report Engine

Comment les applications, les interfaces et les API interagissent avec les données analytiques.

Un moteur de rapports se situe entre les applications et la plateforme de données. Il valide les requêtes, applique les règles de sécurité et de locataire, choisit les données en cache ou en direct, exécute les requêtes nécessaires et retourne des résultats JSON, CSV ou téléchargeables.

Cette section présente la conception de ce système pour la performance, la sécurité, l’échelle et l’observabilité.

Le contenu technique est actuellement disponible en anglais.

  1. ClientsWeb UI · Mobile · External API
  2. API GatewayAzure API Management
  3. Report EngineApp Service or Azure FunctionsAuth · validation · tenant rules
  4. CacheAzure StorageHit: reuse the stored output
    FabricWarehouse · SQL endpointMiss: run the query
  5. ResultJSON · CSV · File

Qu’est-ce qu’un moteur de rapports ?

A Report Engine is a backend service responsible for turning a validated report request into data. It can serve web UIs, mobile applications, external APIs, scheduled exports and downloadable reports.

It centralizes request validation, authorization, tenant isolation, controlled query execution, caching, formatting, monitoring and auditing. The frontend sends intent; it should not build database queries directly.

Architecture

Une conception de production sur Azure et Microsoft Fabric : qui appelle le moteur, ce qu’il vérifie, où se trouvent les données et les résultats en cache, comment les résultats sont livrés et ce qui est supervisé.

Les libellés des diagrammes sont en anglais.

1 Consumers

Web UIDashboards, filters, downloads
External API clientsPartners and integrations
HTTPS · Entra ID token

2 Edge

API ManagementAzure API ManagementToken validation · rate limits · routing · correlation ID
Admitted request

3 Report Engine

Report EngineApp Service or Azure Functions
  1. 1Authenticate & authorizeCaller, report and format allowed
  2. 2Validate requestRanges, filters, row and byte limits
  3. 3Tenant rulesTenant from trusted claims only
  4. 4Cache lookupKey: tenant · report · params · format · version
  5. 5Query builderApproved templates, bound parameters
  6. 6Result builderJSON · CSV · Parquet
Cache miss: parameterized T-SQL

4 Microsoft Fabric

Fabric WarehouseMicrosoft FabricCurated serving tables
Lakehouse SQL endpointMicrosoft FabricRead-only T-SQL over Delta tables
Cache lookup · write outputs

Cached and generated outputs

Report cacheAzure Storage AccountRead on cache lookup, written by the result builder
  • Azure Storage Account · private endpoint, encryption at rest
    • report-cacheBlob container for report outputs
      • {tenant}Tenant boundary: access and cache keys start here
        • {report-name}One folder per report definition
          • {yyyy}/{mm}/{dd}Date partitions; lifecycle rules expire old outputs
            • {request-id}.{format}One output per request: json · csv · parquet

Example report-cache/contoso/sales-by-region/2026/10/03/7f3c9a1e.csv

Output path

  1. Small, bounded result

    1. Result builder
    2. JSON in the response
    3. Web UI or API client

  2. Large result or file

    1. Result builder
    2. CSV / Parquet written to Storage
    3. Short-lived download link
    4. Client downloads

  3. Long-running request (asynchronous)

    1. POST /reports
    2. 202 Accepted + request ID
    3. GET /reports/{id} status
    4. Download link when succeeded

    Status: queued · running · succeeded · failed · expired

Monitoring Azure Monitor · Application Insights

  • Request and correlation IDs
  • Latency per step
  • Cache hit rate per tenant
  • Fabric query duration
  • Failures, throttling and retries
Report Engine on Azure and Microsoft Fabric. Requests pass API Management and the engine’s checks; cache hits are served from the tenant’s folder in the Storage account, misses query Fabric. Small results return as JSON, larger files are written to Storage and delivered through a short-lived link. Every step reports to monitoring.

Cycle de vie d’une requête

Ce qui arrive à une requête, étape par étape, et quel composant fait le travail.

  1. API Management

    Receive request

    Assign a request ID, accept a correlation ID

  2. Report Engine

    Validate request

    Report, format, date range, row and byte limits

  3. Report Engine

    Resolve tenant & security

    Tenant from trusted claims; authorize report and filters

  4. Storage account

    Check cache

    Tenant-aware key; fresh output → skip to step 6 or 8

  5. Microsoft Fabric

    Query Fabric if needed

    Approved template, bound parameters, timeout

    Only on a cache miss

  6. Report Engine

    Build result

    Shape rows into JSON, CSV or Parquet

  7. Storage account

    Store output / cache result

    Write to the tenant’s folder with a TTL

  8. Report Engine

    Return response

    JSON body or short-lived download link

The lifecycle of one report request. Steps 1–4 always run; step 5 runs only on a cache miss; every request ends with a stored or reused output and a response that carries its request ID.

Cache : succès ou échec

Comment le moteur choisit entre un résultat stocké et une requête Fabric en direct, sans jamais partager de résultats entre locataires.

  1. RequestValidated, tenant resolved
  2. Cache keytenantreportparametersformatversion
  3. Look upIn report-cache, under{tenant}/{report}/…
  4. Cached and fresh?Within the report’s TTL

Yes Cache hit

  1. Authorize again for this caller
  2. Read the stored output
  3. Return result

No Cache miss

  1. Query Fabric (approved template)
  2. Build output: JSON, CSV or Parquet
  3. Store under the tenant’s path, with a TTL
  4. Return result

Tenant-aware: same report, same parameters, different tenants

  • contosocontoso · sales-by-region · 2026-09 · csv · v3report-cache/contoso/sales-by-region/…
  • fabrikamfabrikam · sales-by-region · 2026-09 · csv · v3report-cache/fabrikam/sales-by-region/…

Two keys, two folders: never shared.

Cache hit or miss. The tenant is the first part of the cache key and of the storage path, so two tenants asking for the same report with the same parameters never share an entry. A hit is still authorized; a miss queries Fabric and stores the new output for the next request.

Apprendre

Référence

DiagrammeCloud & AutomationEn anglais

Report Engine Architecture Reference

A concise reference for report request validation, cache decisions, Fabric queries, asynchronous delivery and observability.

Trace UI and API requests through a secure report engine, tenant-aware cache or query path, result construction, asynchronous delivery, and monitoring.

  • Data Architecture
  • API
  • Reporting
  • Caching
  • +3

Voir la référence d’architecture →

Construire

The planned project will become the executable reference implementation for this architecture.

Voir le projet →

Superviser le moteur de rapports

Sujets planifiés

Performance & Caching

API & Delivery

Security

Architecture

Governance & Evolution

View the complete editorial roadmap →