Skip to main content
Reporter genera informes financieros, presentaciones regulatorias y exportaciones de datos personalizadas a partir de los datos del ledger de Midaz. Ejecuta un manager y un worker para que la generación de informes escale aparte de la API. El nombre del chart es reporter-helm.

​
Qué instala el chart

El chart instala dos cargas de trabajo:
  • Manager: el servicio de API que almacena las plantillas y orquesta la generación de informes. Recibe un Deployment, un Service, un ConfigMap, un Secret, un ServiceAccount, un ClusterRole, un HorizontalPodAutoscaler, un PodDisruptionBudget y un Ingress opcional.
  • Worker: el procesador en segundo plano que renderiza los informes. Se ejecuta como un ScaledJob de KEDA y escala según la profundidad de la cola.
El manager publica un job en RabbitMQ. El worker lo consume, lee los datos del ledger, renderiza el documento y escribe el resultado en el almacenamiento de objetos. El chart incluye KEDA, un almacén de objetos compatible con S3, MongoDB, RabbitMQ y Valkey, y habilita cada uno de forma predeterminada. Deshabilita cualquiera de ellos para usar en su lugar un servicio administrado externamente. Define keda.external: true cuando ya se ejecuta un operador de KEDA en el cluster.

​
Prerrequisitos

  • Un despliegue de Midaz en ejecución con endpoints de API alcanzables y una réplica de base de datos legible.
  • Una storage class que admita aprovisionamiento dinámico, para MongoDB, RabbitMQ y el almacén de objetos.
  • Helm 3.8 o posterior para la compatibilidad con registries OCI.

​
Instalación

Lee primero la versión actual del chart y luego instala:

​
Values que debes definir

Define estas claves en el bloque secrets de nivel superior, o proporciona tu propio Secret: Deja MONGO_PASSWORD vacío mientras el subchart de MongoDB incluido esté habilitado. El subchart genera la contraseña en su propio Secret, y los servicios la leen de ahí.

​
Fuente de datos de CRM opcional

El chart 4.3.0 de Reporter no habilita CRM de forma predeterminada, pero pasa las claves bajo common.configmap y secrets a ambas cargas de trabajo de Reporter. Cuando una plantilla de informe usa plugin_crm, combina los siguientes values en tu archivo de values existente. Reemplaza cada placeholder mediante tu proceso aprobado de configuración y gestión de secretos.
Mantén DATASOURCE_CRED_ENC_KEY sin cambios en el mismo Secret. Las claves criptográficas de CRM deben coincidir con las claves que CRM ya usa; no generes claves sustitutas. Cuando usas un Secret de Kubernetes existente, pon estas claves exactas en ese Secret y configura el mismo Secret para manager y worker (useExistingSecret: true y existingSecretName). En un despliegue single-tenant, Manager procesa este bloque al arrancar y puede completar un metadata.midazOrganizationId ausente o vacío en la entrada reservada del registro plugin_crm. Nunca reemplaza un ID de organización persistido que no esté vacío. No crees ni hagas PATCH de plugin_crm a través de la API de fuentes de datos habitual: ese nombre está reservado. El Manager multi-tenant omite esta siembra; usa la ruta de aprovisionamiento específica del tenant en lugar de aplicar este ejemplo como solución alternativa. Después de un despliegue de configuración aprobado, valida más que una carga exitosa: importa o guarda una plantilla que mapee plugin_crm, genera un informe, confirma que los campos de CRM se descifran y verifica que los resultados pertenecen solo a la organización de Midaz configurada. Consulta Variables de entorno y Solución de problemas de RPT-0075.

​
Actualización y desinstalación

Desinstalar elimina los recursos de Kubernetes. Deja en su lugar los PersistentVolumeClaims y los informes generados. Bórralos por separado cuando quieras recuperar el almacenamiento.

​
Recursos