Desenvolvi um serviço que utiliza da nova API do Fluig, para atualizar alguns campos do formulario, após sua finalização dentro do Fluig.
Até ai tudo certo, o serviço está funcionando normalmente, porém ao fazer a requisição de update, não importa para qual campo do formulario, o Fluig simplesmente está apagando todas as childrens salvas no meu formulario, segue exemplo:
Primeira requisição GET, antes de realizar o PUT, a API ainda me retorna as childrens salvas no formulario.
Também apaga os registros dentro do fluig, como se não tivessem nem sido inseridos.
Já realizei o teste utilizando o serviço em NodeJS que desenvolvi, e também diretamente via API da Totvs, em ambos os casos aconteceu o mesmo problema.
Inclusive os exemplos mostrados, foram feitos utilizando diretamente a API da Totvs.
Tente fazer um GET antes, pegar as informações, altera-las e fazer um PUT com os dados alterados. Acredito que o Fluig entenda que os dados não informados foram excluídos, por isso ele está apagando.
Fiz conforme você disse, mas continuo com o mesmo problema, após o PUT ele apaga todas as childrens, mesmo eu passando o array populado com as childrens na requisição.
Ao menos no SOAP existem operações que se não informar todos os campos o Fluig considera nulo e apaga o que já existia. Mas também existem operações que se não mandar o campo o Fluig ignora e só altera o que foi informado. É um comportamento estranho. Mas com Pai x Filho acho que faz isso porque a “deleção” de uma linha é não informar essa linha.
Bom, não basta informar os campos da linha colocando o nomecampo___indice. Precisa indicar de qual tabela Pai x Filho e índice é o campo.
Exemplo que tenho no SOAP (operação updateCardData do ECMCardService):
No REST funciona um pouco diferente, o endpoint que captura / atualiza os dados do formulario, não me retorna nenhuma children no array de childrens (mesmo que o formulario possua registros pai x filho).
já testei popular diretamente esse array antes do update, mas não adianta, pois a API possui os endpoints exclusivos para capturar / inserir childrens.
O que eu teria que fazer então é toda vez q eu fosse alterar um simples campo do formulario, capturar todas as childrens antes, via endpoint exclusivo e inserir elas novamente via outro endpoint exclusivo.
Porém ai vem outro problema, o endpoint para inserir childrens não aceita um array de objetos, apenas um DTO por vez, o que me levaria a ter que fazer 50 requisições caso o formulario tivesse 50 childrens, o que fica completamente inviavel.
O que é bem triste é um endpoint que seria somente para fazer o update de um campo informado no body, apagar campos que nem foram mencionados na requisição, lamentavel essa API da TOTVS…
Mas enfim, vou verificar alguma outra forma ou abortar essa ideia.
É bem absurdo, mas consegui usar esse endpoint sem apagar as children.
Fiz uma chamada GET ao endpoint /ecm-forms/api/v2/cardindex/{documentId}/cards/{cardId}/childrens
Aí peguei os valores retornados e coloquei junto no body do PUT ao /ecm-forms/api/v2/cardindex/{documentId}/cards/{cardId}
O mais incrível é que o GET em /ecm-forms/api/v2/cardindex/{documentId}/cards/{cardId} ou o retorno do PUT em /ecm-forms/api/v2/cardindex/{documentId}/cards/{cardId} não retorna absolutamente nada no campo children.
A única coisa “boa” desse endpoint é que não precisa preencher todos os campos do formulário. Ele só vai alterar o que indicar no body da requisição. Mas incrivelmente apaga todos os filhos que não forem informados.
Sinceramente acho que vale a pena abrir um ticket na TOTVS reclamando disso e pedindo uma correção. Realmente não faz sentido ter uma URL para editar os campos de um formulário e isso influenciar nas children.
E vale a pena outro ticket pedindo pra que o serviço de adicionar children permita enviar vários de uma vez.
Na época que reclamei a explicação da TOTVS foi que quando se atualiza se modifica a versão do formulário e com isso a referencia da tabela pai x filho muda (observe que o retorno da versão vai aumentando), pois para localiza-la precisa-se da versao (lembra da consulta no dataset para localizar pai x filho), por isso para edita via rest se faz necessário enviar novamente a pai x filho por completo para criar na nova versão.
Se for para fazer incrimento na pai x filho pode se usar o metodo POST ele não apaga e não precisa informar o campo no formato ___. Ele sempre vai adicionar desde que seja item a item no json, caso contrario, precisa ter o ___x.
Caso deseje mesmo editar o pai x filho pode ser usado também o SOAP updateCard pois ele faz update e incrimento, o unico problema que precisa recuperar o __ da tabela pai x filho para saber a sequencia. Se o campo ___ ja existir ele atualiza,se não existir ele cria
