Índice

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.

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:

• Execução Automatizada

É o modelo de execução assíncrona. Quando uma solicitação entra na atividade de serviço configurada como Automatizada, 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, 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 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 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 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 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 Imediata. 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 Imediada. 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 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: