Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

A atividade serviço é utilizada quando se há a necessidade de um script a parte que execute uma integração com um determinado serviço, servindo para realizar a integração com este serviço em específico, porém pode ser utilizado para basicamente qualquer objetivo que envolva a integração de um script a parte com um processo workflow. Existem dois modos de configuração para esta atividade:

 

  • Execução ImediataAutomatizada

É o modelo de execução síncrona, onde seu script executa logo após o evento afterStateEntry da solicitação Workflow. Em caso de erro, este modelo simplesmente irá retornar o erro encontrado para o usuário caso não tratado e cancelará a movimentação, exigindo nova interação do usuário ou averiguação dos erros de imediato. Não iremos nos ater a este modo de configuração, pois ele executa apenas de modo síncrono, o que não traduz o objetivo deste documento.

 

  • Execução PosteriorManual


É o modelo de execução assíncrona. Quando uma solicitação entra na atividade de serviço configurada como Posterior Manual, uma requisição é enviada de maneira assíncrona para o servidor onde se manterá em uma fila para execução. No momento que o servidor capturar esta requisição o script associado a atividade será executado e, em caso de sucesso, a atividade será movimentada automaticamente para a próxima atividade, caso contrário ela será movimentada  para o fluxo de erro, indicado pelo Evento Intermediário de Captura de Erro, onde pode ser configurada uma atividade nova para que o usuário possa averiguar seus erros e enviar de volta a atividade de serviço ou então seguir um outro fluxo caso desejado.

Vamos nos ater, neste documento, a este tipo de atividade, já que ele representa bem o objetivo deste em desenvolver conhecimento sobre como realizar integrações assíncronas por meio de processos Workflow, portanto a partir deste momento toda informação dada neste tópico irá referenciar a atividade de serviço como configurada como execução PosteriorManual.

 

Configurando atividade de serviço com execução

...

Manual

Para realizar a configuração de uma atividade de serviço posterior Manual primeiramente é preciso, dentro de um processo Workflow, adicionar uma atividade de serviço. Ao clicar sobre a atividade aparecerá algumas opções para configuração.

...

  1. Código: É pré-fixado, sendo o código da atividade. É com base nesta nomenclatura (servicetask9) que o Script e a função do serviço devem ser criadas.
  2. Nome: É o nome da atividade, ou seja, a label que aparecerá na exibição do diagrama ou na seleção de atividades para movimentar.
  3. Execução: É a configuração que indica se o Script terá execução imediata Automatizada ou posterior Manual a movimentação. Para configurar uma atividade de serviço como assíncrona a opção selecionada deve ser POSTERIORManual.
  4. Tentativas: É a quantidade de vezes que o servidor tentará executar o Script caso ocorram erros durante a execução. Caso essa quantidade for excedida, a atividade de serviço será movimentada para o fluxo de erro. A cada tentativa com problemas o script irá gerar um novo complemento no histórico da solicitação informando a tentativa e o erro causado.
  5. Mensagem: Mensagem que será gravada no complemento do histórico caso haja sucesso na execução da atividade.
  6. Serviço: Serviço base que será chamado pelo Script da atividade. Ao lado deste parâmetro há o link Editar Script da Tarefa que, ao ser clicado, irá gerar um Script JS já com seu nome configurado e um Snippet gerado para iniciar o desenvolvimento com base no serviço selecionado neste combo.

...

É a partir deste Script que a customização necessária deve ser customizada. Note que existem dois parâmetros na função que o Script chama que são exclusivos para atividades de serviço configuradas como execução posteriorManual. Estas são:

 

  1. Attempts: Número da tentativa atual, oscilando entre 1 e N, sendo N um número de 1 a 20 configurado nas opções da atividade de serviço no parâmetro Tentativas.
  2. Message: Última mensagem de erro desta atividade. Na primeira execução, este parâmetro é null. Ele serve para que o modelador possa tratar mensagens específicas de erro nas execuções subsequentes a primeira.

...

Realizado os moldes do Script, é então hora de definir os fluxos da atividade de serviço com execução posteriorManual. Por regra, essa atividade permite apenas um fluxo de saída, que é para onde a solicitação será movimentada caso o Script retorne com sucesso. Para o caso de erro é necessário anexar a atividade um Evento Intermediário de Captura de Erro, para tal, basta selecionar o evento em questão e arrastá-lo para cima da atividade de serviço. Uma vez lá, ele demandará um fluxo saindo a partir dele para uma outra atividade qualquer, que será a atividade cuja solicitação será movimentada caso a quantidade de vezes que o Script foi rodado exceda o número de tentativas configuradas pelo usuário. O fluxo, portanto, ficaria semelhante ao abaixo em um modelo básico.

...

É altamente recomendado que tanto a atividade após a atividade de serviço e a configurada no fluxo de erro possuam mecanismos de atribuição configurados, pois, como é uma atividade que será concluída automaticamente, o usuário atribuído será o primeiro da lista recuperada caso não haja tal configuração.

 

Executando atividade de serviço com execução

...

Manual

 

Ao ser executada, a atividade de serviço de execução posterior Manual fica parada e o usuário a quem a mesma está atribuída fica como System:Auto, o mesmo utilizado no caso de Gateways. Ela ficará aguardando a conclusão do script relacionado para então ser movimentada ou para o fluxo de sucesso ou para o de erro dependendo do resultado das tentativas de execução do script. É importante ressaltar que caso haja um gestor configurado para a solicitação o mesmo somente poderá movimentar a atividade sem que haja a conclusão da tarefa de serviços para o fluxo de sucesso, pois a atividade de serviço não possui um fluxo direto com o evento intermediário de captura de erro, sendo que apenas o script, atualmente, poderá ser responsável por movimentar a solicitação para o fluxo de erro.

...