...

Considerações Gerais

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:

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

...

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.

...

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:

...

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

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 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 Manual. 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 Manual. 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 Manual

...

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

...