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 insrc/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)
CNE schema provenance
Section titled “CNE schema provenance”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 mode
Section titled “JSON report mode”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.
Identity model
Section titled “Identity model”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.
Deploy
Section titled “Deploy”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.
In this section
Section titled “In this section”- Postgres Setup — local + production database connection
- RBAC & Identity — exact permissions and grant commands
- Testing — verifying a local build/credential setup
- Migration and Rollout — canonical migration status and rollout checklist
- Compliance — reporting rules and roadmap