Production engineering

Modern Report Engine

Cómo las aplicaciones, las interfaces y las API interactúan con los datos analíticos.

Un motor de informes se sitúa entre las aplicaciones y la plataforma de datos. Valida solicitudes, aplica reglas de seguridad y de inquilino, decide entre datos en caché o en vivo, ejecuta consultas y devuelve resultados JSON, CSV o archivos descargables.

Esta sección explora cómo diseñar ese sistema para rendimiento, seguridad, escala y observabilidad.

El contenido técnico está disponible actualmente en inglés.

  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
Every client goes through the same governed path: the gateway admits the request, the Report Engine applies the rules and chooses between a cached output and a live Fabric query, then returns the result.

¿Qué es un motor de informes?

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.

Arquitectura

Un diseño de producción en Azure y Microsoft Fabric: quién llama al motor, qué comprueba, dónde viven los datos y los resultados en caché, cómo salen los resultados y qué se supervisa.

Las etiquetas de los diagramas están en inglés.

1 Consumers

Web UIDashboards, filters, downloads
External API clientsPartners and integrations

2 Edge

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

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

4 Microsoft Fabric

Fabric WarehouseMicrosoft FabricCurated serving tables
Lakehouse SQL endpointMicrosoft FabricRead-only T-SQL over Delta tables

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.

Ciclo de vida de una solicitud

Qué le ocurre a una solicitud, paso a paso, y qué componente hace el trabajo.

  1. API Management

    Step 1: Receive request

    Assign a request ID, accept a correlation ID

  2. Report Engine

    Step 2: Validate request

    Report, format, date range, row and byte limits

  3. Report Engine

    Step 3: Resolve tenant & security

    Tenant from trusted claims; authorize report and filters

  4. Storage account

    Step 4: Check cache

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

  5. Microsoft Fabric

    Step 5: Query Fabric if needed

    Approved template, bound parameters, timeout

    Only on a cache miss

  6. Report Engine

    Step 6: Build result

    Shape rows into JSON, CSV or Parquet

  7. Storage account

    Step 7: Store output / cache result

    Write to the tenant’s folder with a TTL

  8. Report Engine

    Step 8: 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.

Caché: acierto o fallo

Cómo decide el motor entre un resultado almacenado y una consulta en vivo a Fabric, sin compartir nunca resultados entre inquilinos.

  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.

Aprender

Referencia

Ver referencia de arquitectura →

Construir

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

Ver proyecto →

Supervisar el motor de informes

Temas planificados

View the complete editorial roadmap →