Skip to content

MX Fuels Reporting App

The MX Fuels Reporting dashboard is the primary user-facing product in this repo — a Next.js application (apps/mx_fuels_reporting_app/apps/web) that reports fuel volume/balance data and handles document workflows for MX Fuels compliance.

  • Framework: Next.js (T3-style app), deployed as a standalone Azure Container App
  • Auth: WorkOS sealed sessions (single org / single role policy)
  • Secrets: Azure Key Vault (visory-dev-scus-web-kv), loaded via named loaders in src/lib/keyVault.ts
  • Database: PostgreSQL Flexible Server, Azure AD authentication (read-only access to reporting views, e.g. v_conservation_of_mass)
  • Other integrations: Azure Storage Blob (report file upload/output), Azure Service Bus (triggers Airflow DAGs), Databricks SQL Warehouse (not yet used by any route), Microsoft Graph/SharePoint (VDR document access)

The tracked ReporteVolumenes schema is based on the CNE API Masivos QA documentation: Swagger UI and its OpenAPI document. The document identifies the API as ApiMasivos | v1 and reports version 1.0.0. The Swagger contract also exposes GET /api/Pruebas/GetJSonScheme, which provides the schema endpoint. Update orchestration/include/assets/ReporteVolumenes.schema.json from that CNE source when the contract changes, and record the new source version in this section.

JSON report jobs use generation-only mode by default. This mode creates and uploads the JSON artifact without a REST request to CNE. When an operator clears this setting, Airflow submits the validated artifact through the CNE Masivos QA ReporteObligacion endpoint after report persistence. The submission task has no retries and has a two-minute execution limit. It records SUBMITTED before its request because the CNE contract has no idempotency key. This prevents a task retry from sending the same report again. The DAG keeps acknowledgment content out of logs and XCom.

Do not clear generation-only mode outside QA until the deferred submission test pull request passes. See Migration and Rollout for the rollout gate.

The dashboard uses a single-identity architecture: its production UAMI or local developer Azure CLI identity reads the web vault and writes only to the dedicated CNE credential vault. See Architecture → Identity & Security for the full model, and RBAC & Identity on this page for the exact permissions each integration needs.

Pushes to main trigger the Container Apps deploy workflow. The workflow also supports manual runs — see Architecture → CI/CD.

The workflow sets WEB_KEY_VAULT_URL and CNE_CREDENTIALS_KEY_VAULT_URL as non-secret Container App runtime variables. The Container App’s UAMI authenticates to both vaults with its assigned data-plane roles.