Usar serviço ou script condicional?

Galera tô com uma dúvida e gostaria de ouvir sugestões

Tenho um processo onde em determinado momento preciso consultar um dataset, esse dataset pode retornar algo ou vazio.

Se retornar vazio, deverá seguir para caminho A, se retornar algo, deverá seguir para caminho B.

O q vc sugerem. Uso um serviço para consultar e se der vazio retorno throw e mando para caminho A ou se achar retorno True e mando para o caminho B?

Ou então, um script condicional para gravar um campo e retorno True para as duas opções e uso um gateway pra consultar esse campo.
Pergunto isso, pq nao é mais recomendado usar o hapi.setautomaticdecision

O que recomendariam?

Wasley bom dia.

Vou te responder o que eu faria, não por ser a melhor opção, mas porque é a que tenho maior familiaridade.
Eu gravaria um campo e utilizaria um “gateway”. A vantagem de gravar um campo é que você saberia que naquele momento da decisão no processo, o retorno do seu “dataset” tinha aquela informação específica. Não sei como está estruturado seu processo, mas se de repente a informação de retorno do seu “dataset” em um outro momento fosse modificada, você teria um, vamos dizer assim, histórico do que estava no momento da decisão do caminho A ou caminho B.
Não sei se consegui ser claro na minha explicação.
Espero ter de alguma forma ajudado.

2 curtidas

Wasley, bom dia, ambas as soluções atendem perfeitamente, é necessário uma atividade automática. Acho que para definir qual dos componentes deve utilizar você deve responder a seguinte pergunta: a informação que vem do dataset é referente ao entendimento do processo (diagrama)? Se sim, acredito que deve utilizar um gateway, ou seja, se estamos falando de tomar decisão o componente mais indicado é o gateway já que ele confere esse sentido ao processo. Se o intuito é processar alguma informação, chamar integrações, alterar algum registro ou qualquer outra coisa que seja fora do processo, aí deve utilizar uma atividade de serviço. É sempre necessário lembrar que ao desenvolver um fluxo não estamos simplesmente fazendo algo que funcione, o diagrama também precisa conferir sentido, lógica e intuitividade ao processo, já que essa é a proposta do BPMN.

Espero ter contribuído, Wasley!

2 curtidas

Essa ideia do @Cassius de gravar em um campo pra ver o histórico de modificações do retorno do dataset é muito válida. Mas se você estiver usando essa verificação somente uma vez durante o workflow eu acho desnecessário. Eu já utilizei essa solução várias vezes. No beforeTaskSave antes do gateway eu fazia o cálculo e salvava em um campo qual a atividade de destino que o gateway precisava assumir e fazia o gateway consultar esse campo pra tomar a decisão.

Agora eu faço diferente. Eu não preciso criar um campo só pra guardar uma informação que eu vou usar só uma vez. Eu crio um script de evento workflow e dou um nome pra função. Custei a descobrir que eu posso fazer dessa forma :joy:

image
image

Essa função retorna true ou false. E no gateway eu só chamo a função e decido o caminho a ser tomado.

image

Espero ter ajudado.

7 curtidas

M O D U L A R I Z A R :smiley:

1 curtida

Nossa cara, também não imaginava que seria possível isso. Acho que isso claramente vai expressar o que eu quero fazer. Eu aprendi recentemente que posso fazer essa modularização mas nunca pensei que ela funcionava dentro do gateway.

1 curtida

Muito boa essa sua solução.
Já tinha usado esses eventos de processo em gateway, mas não dessa forma.
Muito bom!
Mais uma pra biblioteca de ideias :smiley:

1 curtida

:ok_hand:

google ta em dia!

1 curtida

@victorcastro

Essa era a minha resposta e era assim que fazíamos a maioria das funções de processo no by you ECM 3.0

TOP!

1 curtida

Genial cara, não imaginava que também dava pra fazer dessa forma. Agora não precisarei mais percorrer uma tabela Pai e Filho e guardar o total em um campo apenas para usar no gateway

1 curtida

Wikipedia, parceiro! Kkkkkkk mentira, autor: minha própria cabeça!

1 curtida

Eu descobri que dava pra fazer assim, de criar um arquivo compartilhado no processo, só porque fui estudar um processo que uma “filial” tinha isso nele.

Na documentação não tem falando isso e nos cursos (nem da academia fluig nem o presencial da totvs) sequer comentaram essa possibilidade.

2 curtidas

Pois é Bruno, eu sempre fico imaginando a quantidade de coisas que a gente não sabe, exatamente por não ter em lugar algum.

@Bruno_Gasparetto como é esse lance de “arquivo compartilhado”?

@Cassius , é um arquivo “compartilhado”, mas na verdade é mais pra ter uma função comum a todo um processo.

Se você olhar o post do VictorCastro vai ver no print que ele tem um processo chamado “SESMT02”. Aí ele criou um “evento” chamado validateNumIncidente pra esse processo.

O que o Eclipse/Fluig faz é criar um arquivo chamado SESMT02.validateNumIncidente.js e dentro desse arquivo tem a função validateNumIncidente.

Essa função você pode chamar em qualquer evento do processo e também utilizá-la numa expressão dentro dos Gateways BPM.

Então dá pra reaproveitar ao menos as funções dentro do mesmo processo.

2 curtidas

Existe um outro jeito de compartilhar funções entre processos, mas é um pouco menos elegante - armazená-las em datasets e fazer um eval() no resgate da função - nunca usei e me soa pouco prático…mas acredito que funcione perfeitamente!

O ideal era ter a possibilidade de ter um repositório comum no backend, não acham?

1 curtida

@daniel.cabral eu uso pacotes em forma de widgets com js dentro dele.
Fica comum a todos os formulários pelo menos.

2 curtidas