Por que o Fluig não tem esta funcionalidade?

Por qual motivo a plataforma não disponibiliza o recurso de N para N? Como você implementa este tipo de solução?

Por que o Fluig não tem esta funcionalidade?
Photo by Firmbee.com / Unsplash

O desenvolvimento diário de processos no TOTVS Fluig revela diversas necessidades da plataforma. Ao criar soluções de sistemas, o foco geralmente recai sobre como os dados serão armazenados. Uma abordagem voltada para dados estruturados não apenas facilita o armazenamento, mas também proporciona resultados futuros que agregarão valor aos processos de análise e automação.

O Fluig é uma plataforma excepcional para a gestão de processos, permitindo que analistas de negócios implementem soluções de gerenciamento de atividades com fluxos definidos, integrando toda a corporação em um único processo. Com a prática, os analistas de sistemas desenvolvem habilidades para visualizar os processos e compreender como conectá-los de forma eficaz na plataforma.

Outro recurso interessante do Fluig é a capacidade de manter versões dos processos, permitindo a modificação do fluxo operacional sem afetar as atividades que já estão em andamento. Essa funcionalidade garante a continuidade das operações, ao mesmo tempo em que possibilita melhorias e adaptações nas práticas de gerenciamento.

Recurso: Um para Muitos

Em resumo, ao planejar um banco de dados, a relação 1 para N (um para muitos) ilustra a dependência que uma tabela possui em relação a outra. Esse tipo de relacionamento é fundamental para organizar dados de forma hierárquica e eficiente. No contexto do TOTVS Fluig, essa relação pode ser implementada utilizando o recurso de pai e filho, que facilita a estruturação e a gestão das interações entre diferentes entidades, permitindo um fluxo de informações mais claro e integrado.

Quando se trata de um pedido de venda, ele possui diversas características, como Valor Total, Data da Compra, Fornecedor, entre outras informações relevantes que tornam os registros únicos. No entanto, à medida que essas informações começam a se repetir, surge a necessidade de separar os dados redundantes em uma nova tabela. Por exemplo, no contexto de um pedido e seu respectivo envio, essa separação pode ser crucial para uma melhor organização e gerenciamento dos dados.

Um pedido pode estar associado a múltiplos envios ou a uma sequência de envios, o que resulta em um fluxo que inclui informações como origem, destino e data. Essa estrutura permite um melhor controle e acompanhamento das movimentações do pedido ao longo do tempo, facilitando a gestão logística e garantindo a eficiência no atendimento ao cliente.

O mesmo raciocínio se aplica aos itens de um pedido. Enquanto um pedido contém dados únicos, os itens associados frequentemente apresentam características repetitivas e, portanto, devem ser armazenados em tabelas adicionais. Essa abordagem não apenas evita a redundância, mas também facilita a organização e o gerenciamento das informações, permitindo um acesso mais eficiente aos dados relacionados a cada item do pedido.

Exemplo de relacionamentos entre tabelas de bancos de dados.

Recurso Muitos para Muitos

O desenvolvimento na plataforma FLUIG que requer a estruturação de dados no formato Muitos para Muitos pode ser uma tarefa desafiadora. Essa complexidade surge da necessidade de gerenciar as interações entre diferentes entidades, exigindo um planejamento cuidadoso para garantir que as relações sejam adequadamente definidas e acessíveis dentro do sistema.

Existem diversas abordagens que podem ser utilizadas, que seriam:

  • Utilizar um base de dados secundária: Uma técnica que pode ser utilizada é utilizar uma base de dados secundária como o ERP para armazenar as informações e tratar as informaçõe apenas em frontend. Neste cenário eu não vejo uma possibilidade de armazenar os dados originais no Fluig, para ser o fator gerador da informação e deixa-lo registrado de forma histórica. Também se alguém optar por esta abordagem o uso do Fluig não faz sentido, visto que é possível desenvolver o mesmo recurso apenas com tecnologias de Frontend, uma delas é o POUI da própria TOTVS.
  • Armazenar 'filhos dos filhos' de forma estruturada ( objetos ): Esta abordagem pode ser funcional, mas não é eficiente.
  • Armazenar Filhos dos Filhos em Tabelas Adicionais: Dentro do TOTVS FLUIG é possível criar estrutura de tabelas PAI X FILHO, uma abordagem a ser tomada é criando duas tabelas PAI X FILHO e de algum modo co-relacionar as duas. A desvantagem deste processo é a complexidade do desenvolvimento e também pode gerar um processamento exponencial, fazendo o sistema perder o desempenho caso atinja um nível de itens elevados.
  • Outra forma: Existem diversas formas de resolver o problema, mas nenhum de forma eficiente como se houvesse a possibilidade de criar de forma nativa a opção que seria semelhante a 'Pai x Filho x Neto'.

Conclusão.

Em suma, o Fluig oferece aos analistas a capacidade de desenvolver soluções robustas e integradas, com fluxos bem definidos.

No entanto, em certos momentos, a criatividade se torna essencial, o que pode resultar em um aumento significativo nos custos operacionais, tornando o desenvolvimento mais complexo.

A implementação de uma abordagem otimizada que contemple, ao menos, até a terceira forma normal poderia simplificar e resolver uma série de desafios cotidianos de maneira eficiente.

Deixe o seu comentário e nos auxilie com alguma dica de desenvolvimento na plataforma.