...

...

Objetivo

...

As informações neste documento são destinadas a auxiliar e informar o usuário sobre os modos de realizar processamentos assíncronos por meio de solicitações workflow. Para tal, é necessário conhecimento prévio em determinados pontos, sendo estes:

...

...

Neste documento serão apresentados conceitos relacionados a modelagem de processos utilizando-se de atividades que são executadas pelo servidor para que a integração necessária seja transparente para o usuário que esteja movimentando a atividade.

...

Pré-requisitos

...

Conhecimento prévio em determinados pontos, sendo estes:

• Visão geral sobre a plataforma Fluig
• Visão geral sobre integração de sistemas
• Conhecimento sobre modelagem de processos
• JavaScript

Visão Geral

...

Em vários casos, o usuário pode encontrar situações em suas regras de negócio ou necessidades do dia a dia em que uma solicitação Workflow deve executar alguma integração ou processamento em que o próprio usuário inicial não precise ficar esperando para receber a resposta do servidor, sendo que estas atividades devem ser executadas em paralelo ao uso cotidiano do sistema e apenas ser movimentada ao fim do mesmo.

Para este tipo de situação existem atividades que auxiliam nestas configurações, possibilitando que uma solicitação fique aguardando a execução de um processamento programado ou que tenha meios de recuperação de erros na execução de um evento assíncrono para que o usuário tenha como modelar alternativas no caso de falha. Estes procedimentos serão melhor detalhados neste documento, explicando meios de como realizar modelar tais atividades e em quais tipos de situações elas podem ser úteis. 

Atividade de Serviço

...

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:

...

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

• Execução ManualExecução Imediata

É o modelo de execução síncrona, onde seu script executa logo após o evento afterStateEntry da solicitação Workflow. Em caso de sucesso,a movimentação irá passar da atividade imediata direto para a atividade seguinte, dando sequência ao fluxo. 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 uma nova interação do usuário ou averiguação dos erros de imediato. Este tipo de execução não é recomendado pelo fluig e está disponível como recurso para suportar workflows elaborados em atualizações anteriores ao fluig 1.5.9, a partir desta atualização recomenda-se a utilização da execução automatizada.

está disponível a partir da versão 1.6.5

Configurando atividade de serviço com execução Automatizada

Para realizar a configuração de uma atividade de serviço Automatizada 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 Automatizada ou Manual a Imediata a movimentação. Para configurar uma atividade de serviço como assíncrona a opção selecionada deve ser Automatizada.
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.

Após configurar todas as opções e clicar em Editar Script da Tarefa, um Script será gerado para que a personalização necessária possa ser feita, sendo que este Script deve ser programado em JavaScript puro e suporta todas as bibliotecas convencionais que são utilizadas durante os eventos de Workflow. Como base, teremos um Script semelhante a este:

function servicetask("Número da atividade")  (attempt, message) {
 try {
	 var Service = ServiceManager.getService('ServiceID');
	 var serviceHelper = Service.getBean();
  //var serviceLocator = serviceHelper.instantiate('classe.locator');
 } catch(error) { 
	log.error(error);
	throw error;
 }
}

...

É 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 ManualImediata. 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 ManualImediada. 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.

Note que neste caso o fluxo de erro está programado para seguir a uma atividade extra (sub processo) que será utilizada para que o usuário possa visualizar o problema, corrigir e então reenviar a atividade de serviço para uma nova execução, que é o modelo padrão, porém essa atividade também pode ser utilizada para que o processo siga um fluxo completamente diferente caso o modelo de negócio exija de tal forma.

É 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

...

Imediata

Ao ser executada, a atividade de serviço de execução Manual fica Imediata 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.

Para o desenvolvimento do script da atividade de serviços os seguintes recursos estão ativos: 

<!-- Hotjar Tracking Code for http://tdn.totvs.com/display/fb -->
<script>
    (function(h,o,t,j,a,r){
        h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
        h._hjSettings={hjid:5776551280165,hjsv:56};
        a=o.getElementsByTagName('head')[0];
        r=o.createElement('script');r.async=1;
        r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
        a.appendChild(r);
    })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
</script>