Modern Report Engine

Problem

Applications often grow separate query logic in a web frontend, API controller, export job, and support script. Validation drifts, tenant rules become inconsistent, and expensive requests reach the analytical platform without a shared workload policy. This planned project will demonstrate one report engine that accepts intent and owns the governed path to results.

Architecture

Web, mobile, and external API clients call Azure API Management or another gateway. A report-engine service may be implemented with .NET or Python after the project evaluates team skills and runtime constraints. Azure App Service and Azure Functions remain deployment options rather than a premature final choice.

The engine authenticates and authorizes, derives tenant identity from trusted claims, validates the report model, applies rate and concurrency limits, and performs a tenant-aware cache lookup. Cache misses use approved parameterized queries against Fabric Warehouse or a Lakehouse SQL endpoint. A result builder produces paged JSON or stored CSV, Parquet, and other allowed formats.

API contract

The planned contract distinguishes small synchronous requests from large asynchronous work. Typed parameters cover report name, date range, allowed dimensions such as Date, Site, or Merchant, approved filters, format, paging, and version. The engine rejects raw SQL, query fragments, excessive ranges, unsupported dimensions, and tenant identifiers that conflict with authenticated identity.

Large requests can use POST /reports, status polling by reportRequestId, and an authorized download endpoint. Idempotency prevents duplicate submissions from creating duplicate work.

Cache model

The cache key will include tenant, report type, normalized date range, dimensions, filters, format, and report definition version. Entries carry creation time, source freshness, expiration, size, and access scope. The reference will demonstrate time-based and refresh-driven invalidation while documenting cases where live execution is safer.

Multi-tenancy and query layer

Tenant identity flows from authentication into authorization, cache keys, query parameters, result storage paths, and audit events. The browser is never the sole authority for tenant_id. Query templates are allow-listed and parameterized. Row and byte limits protect both Fabric and the application process.

Monitoring

Every request records request and correlation IDs, tenant and client identifiers, report name, timestamps, total and query duration, cache outcome, rows, bytes, status, and error code. Dashboards will separate interactive and export workloads and connect to the Data Platform Monitoring and Observability series.

Future custom reports

A metadata model may allow versioned custom report definitions without granting arbitrary SQL. Future work includes approval workflow, safe dimensions and measures, schema compatibility, definition testing, auditing, and migration. No repository, demo URL, or implementation language is claimed until those choices and artifacts exist.