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.

Expandindo o entendimento com diagrama de fluxo¶