iGRPIGRP 3.0Documentation

Stack de processos

process/ — Process Management e Process Studio (APIs e UIs) no workspace local, como ativar e arrancar, clientes OAuth, rotas e verificação.

A stack Process acrescenta à plataforma os serviços de processos BPMN. Corre contra o mesmo Access Management que a stack principal e os projetos, e arranca sempre depois dela.

Modo KeycloakModo Autentika
Composeprocess/igrp-process-compose.yamlprocess/igrp-process-autentika-compose.yaml
Ambienteprocess/.env_processprocess/.env_process_autentika

Serviços

Todas as imagens em 0.2.0-beta (registry.nosi.cv/igrp/…).

ServiçoRotaVerificação nos logs
<slug>-process-management-api/gateway-api/<slug>-process-management-apiResource synchronization completed.
<slug>-process-studio-api/gateway-api/<slug>-process-studio-apiidem
igrp-process-management/apps/igrp-process-managementApplication IGRP_PROCESS_MANAGEMENT metadata synced successfully.
igrp-process-studio/apps/igrp-process-studioApplication IGRP_PROCESS_STUDIO metadata synced successfully.

Cada API tem a sua base de dados, criada por uma tarefa *-db-prepare. No catálogo do Access Management ficam as aplicações IGRP_PROCESS_MANAGEMENT e IGRP_PROCESS_STUDIO.

Ativar e arrancar

Escolhe Process ao criar o workspace, ou acrescenta-a depois em Serviços → Docker → Add Stack → Process Stack. A partir daí, arranca e para pelo grupo Process em Serviços → Visão Geral.

Clientes OAuth

Quatro clientes client_credentials, sem redirectUris — as APIs por serem backends, as UIs porque o login OIDC usa o cliente semeado, a quem a tarefa -oauth-client-uri-sync já regista os callbacks.

clientIdUsado como
igrp-process-management-apiSPRING_APPLICATION_NAME + M2M da API
igrp-process-studio-apiidem
igrp-process-management-uiIGRP_SERVICE_ID + M2M da UI
igrp-process-studio-uiidem

O registo é automático, pela tarefa -oauth-clients da stack principal. Os segredos são escritos em process/.env_process e process/.env_process_autentika, como PROCESS_{MANAGEMENT,STUDIO}_{API,UI}_M2M_CLIENT_SECRET.

O segredo do cliente semeado tem de coincidir

O ACCESS_MANAGEMENT_OAUTH_CLIENT_SECRET dos env-files da Process tem de ser igual ao do .env / .igrp-autentika.env — senão o login das UIs falha. O template já traz o mesmo valor em todos.

Rota e client ID são coisas diferentes

São três nomes, e só dois estão obrigatoriamente acoplados:

O que éQuem obriga
clientIdnome do resource criado ao registar o clienteo Access Management
spring.application.namenome com que a aplicação procura esse resource no arranquea biblioteca — se divergir, 404 IGRP_AUTH_RESOURCE_NOT_FOUND_BY_NAME
nome no Eureka = /gateway-api/<id>a rotaninguém: por defeito igual a spring.application.name

clientId == spring.application.name é obrigatório, mas a rota pode seguir a convenção de prefixo do workspace (<slug>-process-management-api), como o próprio Access Management faz. Desacoplar exige três variáveis — só EUREKA_INSTANCE_APPNAME não chega, porque o gateway resolve lb://<APP> pelo virtual host:

- SPRING_APPLICATION_NAME=${PROCESS_MANAGEMENT_API_M2M_CLIENT_ID}   # = clientId
- EUREKA_INSTANCE_APPNAME=${PROCESS_MANAGEMENT_API_SERVICE_NAME}
- EUREKA_INSTANCE_VIRTUAL_HOST_NAME=${PROCESS_MANAGEMENT_API_SERVICE_NAME}
- EUREKA_INSTANCE_SECURE_VIRTUAL_HOST_NAME=${PROCESS_MANAGEMENT_API_SERVICE_NAME}

Todas as referências /gateway-api/<...> — o API_GATEWAY das UIs, SPRINGDOC_SWAGGER_UI_*, OPENAPI_SERVER_API, IGRP_PROCESS_ENGINE_BASE_URL — usam o nome da rota, não o do cliente.

Verificar

curl http://<slug>:<porta>/apps/igrp-process-management
curl http://<slug>:<porta>/gateway-api/<slug>-process-studio-api/v3/api-docs

Nos logs das APIs tem de aparecer Resource synchronization completed. e o registo no Eureka (registration status: 204); nos das UIs, metadata synced successfully e Access Management sync completed.

Respostas que parecem erro mas não são

  • O process-studio-api não expõe /actuator: um 404 aí vem da aplicação, não do gateway — testa o routing com /v3/api-docs.
  • O process-management-api devolve 401 em /actuator/health: o actuator está protegido. Um 401 prova que a rota existe; um 404 do gateway seria rota ausente.
  • Um toast "An error occurred in the Server Components render" em páginas como Gestão de Tarefas, com HTTP Error: 404 nos logs da UI, indica rota desalinhada; a cache de rotas do gateway leva até ~2 minutos a acompanhar uma mudança.
How is this guide?

Última atualização: