Desvio de fluxo de processo¶

Resumo¶

É uma interferência no ciclo de vida de um processo padrão, manipulando suas fases e tomadas de decisão.

Objetivo¶

Orientar sobre a técnica de extensão em processos nos serviços SaaS, utilizando status intermediário no produto padrão, que permitirá o desvio do fluxo padrão, com serviços de frontend e backend externos, reagindo a eventos da plataforma via Reactive Webhook

Onde aplicar¶

Aplica-se o Estado Intermediário para adicionar uma etapa externa de um processo do sistema padrão, onde regras customizadas poderão ser executadas, sem a necessidade desse sistema conhecer ou executar o código específico. Nesse modelo, o processo do sistema padrão entra em estado de Aguardo, até que um sistema externo solicite o avanço do Estado do Processo, utilizando um Identificador, previamente recebido via Eventos emitidos pela plataforma, como PedidoCriado ou PedidoAguardandoProcessoExterno.

Considerações¶

Antes de iniciar a implementação da técnica, você deve ter em mente que:

Não é possível alterar diretamente o estado armazenado de entidades. Alterações de estado serão sempre efetuadas via API REST disponibilizada pelo produto.
Entrar ou sair do Estado Intermediário, também conhecido por Aguardando Processo Externo, se dará apenas por API REST disponibilizada pelo produto.
O intuito do Estado Intermediário é o desvio de um fluxo padrão de um processo com identidade. Portanto, não é possível bloquear a criação de uma instância do processo, entretanto, é permitido iniciá-lo com o estado Aguardando Processo Externo, ou, ser criado com o estado padrão e então alterado para Aguardando Processo Externo, caso produto implemente tal comportamento.

Conhecimento necessário¶

Invocação de API REST
Criação de API REST
Assinatura e recebimento de mensagens via Reactive Webhook

Requerimentos em produção¶

Deploy de aplicação backend em nuvem pública, para integração com Reactive Webhook
Deploy de aplicação frontend acessível ao usuário final, para integração com botão de extensão de interface do produto padrão.

Exemplo ponta-a-ponta¶

Caso de uso simplificado:

O produto controla quais Itens com Características serão enviados para Beneficiamento utilizando um Pedido de Produção.
No Tipo de Produção, são configuradas Características de Itens, definindo quais Itens serão enviados automaticamente para Beneficiamento.
O processo Pedido de Produção possuí alguns estados: Criado, Pronto para Produção, Em Produção, Concluído, Cancelado. Ao estar Pronto para Produção, não é mais permitido a escolha, seja automática ou manual, de quais Itens serão enviados para Beneficiamento. Só é possível adicionar ou remover Itens enquanto Criado.

Requisito do cliente:

Quando Itens com Características A, B e C estiverem no mesmo Pedido de Produção, é necessário entrar em contato com o fornecedor, que possuí um prazo para responder se atenderá ou não o Beneficiamento. Enquanto isso não ocorre, não poderão ser alterados os Itens do Pedido de Produção.

Sugestão de construção:

Combinar contratos:

É necessário definir e conhecer quais apis e eventos serão utilizados para a construção da extensão.

PedidoDeProducaoCriadoEvent:

  {
    "id": "uuid",
    "tipoPedido": "string",
    "items": [
        {
          "sequencia": "string",
          "caracteristicas": ["string"]
        }
    ]
  }

ProcessoExternoDoPedidoEmAguardoEvent:

  {
    "id": "uuid",
    "items": [
        {
          "sequencia": "string",
          "caracteristicas": ["string"]
        }
    ]
  }

Nos serviços do específico:
- É realizado o deploy dos endpoints: POST /basic/pedido-producao-criado e POST /basic/pedido-producao-externo em nuvem pública, ambos recebendo JSON como corpo. Para permitir um teste da comunicação ponta-a-ponta, sugere-se liberar uma versão que apenas registra via log o conteúdo recebido.
  - É recomendado aplicar nos endpoints a segurança Basic, a autenticação suportada pelo Reactive WebHook.
  - Utilizar o prefixo /basic é opcional, entretanto recomendado, pois facilita ao configurar segurança por path.
- Ao receber o evento PedidoDeProducaoCriadoEvent, verifica se o Pedido de Produção Possuí processo externo? e se Possuí items A,B,C? e então armazena o pedido para consulta nas interfaces Tela de pedidos aguardando processo externo e Tela de um pedido
- (Opcional) Ao receber o evento ProcessoExternoDoPedidoEmAguardoEvent, verifica se o Pedido de Produção Possuí items A,B,C?. Caso não seja atendido, invoca o comando Liberar do processo externo, dando continuidade ao Pedido de Produção
- Disponibilizar api específica Informar atendimento do beneficiamento, que interage com os Pedidos de Produção registrados no banco de dados do específico e invocar o comando Liberar do processo externo através da API REST PUT /api/v1/pedidos-producao/{id}/liberar-externo.
  - É recomendado aplicar no endpoint a segurança OAuth2 com JWT, a autenticação suportada pela TOTVS. Para uma experiência Single Sign On, é recomendado que o endpoint esteja configurado com a mesma segurança OAuth2 com JWT aplicada no produto padrão.
- Criar interface para o usuário final interagir com os Pedidos de Produção, invocando a API REST Informar atendimento do beneficiamento, com quaisquer dados que sejam necessários para o procedimento específico.

No produto padrão:
- Nova opção no Tipo de Produção: Possuí processo externo?
- Novo estado Aguardando Processo Externo para o Pedido de Produção, quando Tipo de Produção for configurado para Possuí processo externo
- Reação ao evento PedidoDeProducaoCriadoEvent, para avaliar a mudança para o novo estado Aguardando Processo Externo
- Novo evento públicado ProcessoExternoDoPedidoEmAguardoEvent
- Nova api Liberar do processo externo, para dar segmento ao processo.
- Adição da extensão de interface Ações, permitindo que a tela de pedidos direcione para o frontend do específico.