Índice

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 Workflowworkflow. Para tal, é necessário conhecimento prévio em determinados pontos, sendo estes: 

• Visão geral sobre o produto 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. 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 Automatizada
  

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

...

Após configurar todas as opções e clicar em Editar Script da Tarefa, um Script será gerado para que a customização 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.

...

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

...

Recurso	Descrição
hAPI	Recurso para manipulação de formulários e Workflow. Para maiores informações acessar: Desenvolvimento de Workflow.
docAPI	Recurso para manipulação de documentos. Para maiores informações acessar: Desenvolvimento de Workflow.
log	Recurso para log no console do sistema.
ServiceManager	Recurso para acesso via WebService SOAP. Para maiores informações acessar: Integração Com Aplicativos Externos.
datasetManager	Objeto que permite carregar datasets entro das customizações.
DatasetFactory	Serve como "porta de entrada" para o acesso a qualquer Dataset. Maiores detalhes sobre este item se encontram no artigo sobre construção de datasets.
DatasetBuilder	É semelhante ao DatasetFactory, servindo ao propósito de construir o objeto de datasets. Maiores detalhes sobre este item se encontram no artigo sobre construção de datasets.
ConstraintType	Determina o tipo de constraint a ser utilizada em uma condição do dataset. Maiores detalhes sobre este item se encontram no artigo sobre construção de datasets.
notifier	Permite realizar notificações extras em eventos e scripts. Para maiores informações acessar: Personalização de e-mail.
WKParams	Coleção de parâmetros que podem ser utilizados dentro dos scripts como o WKCompany e WKUser. Para maiores informações acessar: Desenvolvimento de processos workflow. As variáveis suportadas neste script são: WKCurrentState WKNumState WKDef WKNumProces WKVersDef WKCompany WKIdentityCompany WKUser WKCompletTask WKCardId WKFormId WKNextState
fluigAPI	Recurso que consome classes infernas internas do fluig e prepara métodos utilitários diversos. Para maiores informações acessar: Fluig API.
oauthUtil	Recurso que serve para utilizar autenticação OAuth. Para maiores informações acessar: Consumo da API Pública em Eventos.

Nota

IMPORTANTE: A transação inicia no momento em que o script começa a ser executado e somente acaba após o script ser finalizado e retornar para o produto. Sendo assim, por padrão, o script deve rodar durante cinco minutos ou então irá dar erro indicando que o tempo de transação excedeu. Outro comentário importante é que qualquer exceção durante a execução do script que chegue ao código do produto irá efetuar Rollback da transação, ou seja, todos os dados salvos até então na base do fluig serão perdidos como, por exemplo, campos de formulário alterados com hAPI.setCardValue.