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
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.
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.
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
Essa função retorna true ou false. E no gateway eu só chamo a função e decido o caminho a ser tomado.
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.
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
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.
@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.
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?
