Skip to main content
O Reporter gera relatórios financeiros, envios regulatórios e exportações de dados personalizadas a partir dos dados do ledger do Midaz. Ele roda um manager e um worker para que a geração de relatórios escale separada da API. O nome do chart é reporter-helm.

​
O que o chart instala

O chart instala duas cargas de trabalho:
  • Manager: o serviço de API que armazena os templates e orquestra a geração de relatórios. Ele recebe um Deployment, um Service, um ConfigMap, um Secret, uma ServiceAccount, um ClusterRole, um HorizontalPodAutoscaler, um PodDisruptionBudget e um Ingress opcional.
  • Worker: o processador em segundo plano que renderiza os relatórios. Ele roda como um ScaledJob do KEDA e escala pela profundidade da fila.
O manager publica um job no RabbitMQ. O worker o consome, lê os dados do ledger, renderiza o documento e grava o resultado no armazenamento de objetos. O chart empacota KEDA, um armazenamento de objetos compatível com S3, MongoDB, RabbitMQ e Valkey, e habilita cada um deles por padrão. Desabilite qualquer um deles para usar um serviço gerenciado externamente no lugar. Defina keda.external: true quando um operador KEDA já roda no cluster.

​
Pré-requisitos

  • Um deploy do Midaz em execução com endpoints de API alcançáveis e uma réplica de banco de dados legível.
  • Uma storage class que aceita provisionamento dinâmico, para o MongoDB, o RabbitMQ e o armazenamento de objetos.
  • Helm 3.8 ou posterior para o suporte a registry OCI.

​
Instalação

Leia primeiro a versão atual do chart e depois instale:

​
Values que você deve definir

Defina estas chaves no bloco secrets de nível superior, ou forneça o seu próprio Secret: Deixe MONGO_PASSWORD vazio enquanto o subchart MongoDB empacotado estiver habilitado. O subchart gera a senha no próprio Secret, e os serviços a leem de lá.

​
Fonte de dados de CRM opcional

O chart 4.3.0 do Reporter não habilita o CRM por padrão, mas passa as chaves de common.configmap e secrets para as duas cargas de trabalho do Reporter. Quando um template de relatório usa plugin_crm, mescle os values a seguir no seu arquivo de values existente. Substitua cada placeholder pelo seu processo aprovado de configuração e gestão de secrets.
Mantenha DATASOURCE_CRED_ENC_KEY sem alteração no mesmo Secret. As chaves de criptografia do CRM devem casar com as chaves que o CRM já usa; não gere chaves substitutas. Quando você usa um Secret existente do Kubernetes, coloque essas chaves exatas nesse Secret e configure o mesmo Secret para manager e worker (useExistingSecret: true e existingSecretName). Em um deploy single-tenant, o Manager processa este bloco na inicialização e pode preencher um metadata.midazOrganizationId ausente ou vazio na entrada reservada plugin_crm do registro. Ele nunca substitui um ID de organização persistido e não vazio. Não crie nem faça PATCH em plugin_crm pela API comum de fontes de dados: esse nome é reservado. O Manager multi-tenant pula essa carga inicial; use o caminho de provisionamento específico do tenant em vez de aplicar este exemplo como contorno. Depois de um rollout de configuração aprovado, valide mais do que um upload bem-sucedido: importe ou salve um template que mapeia plugin_crm, gere um relatório, confirme que os campos do CRM são descriptografados e verifique que os resultados pertencem apenas à organização Midaz configurada. Veja Variáveis de ambiente e Solução de problemas do RPT-0075.

​
Upgrade e desinstalação

A desinstalação remove os recursos do Kubernetes. Ela deixa os PersistentVolumeClaims e os relatórios gerados no lugar. Apague-os separadamente quando você quiser recuperar o armazenamento.

​
Recursos