Estou precisando alimentar um formulário a partir de uma widget. Estou iniciando no Fluig e não sei quais dos serviços SOAP usar
Você pode usar o ECMCardService.
Nesse SOAP tem vários métodos pra manipular os dados de formulário. Já usei o updateCardData para alterar os dados salvos no formulário.
Segue uma função que utilizo pra atualizar os dados por uma widget:
/**
* Salva os dados no formulário
*
* @param {number} cardDocumentId Id do formulário
* @param {object} data Dados a serem persistidos no formulário
*/
function saveCardData(cardDocumentId, data) {
const items = Object.entries(data).reduce(
(acc, item) => acc + `<item><field>${item[0]}</field><value>${item[1]}</value></item>`
, ""
);
const xml = `<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://ws.dm.ecm.technology.totvs.com/">
<soapenv:Header/>
<soapenv:Body>
<ws:updateCardData>
<companyId>${WCMAPI.organizationId}</companyId>
<username>${fluigUsername}</username>
<password>${fluigPassword}</password>
<cardId>${cardDocumentId}</cardId>
<cardData>
${items}
</cardData>
</ws:updateCardData>
</soapenv:Body>
</soapenv:Envelope>`;
return fetch(
`${WCMAPI.serverURL}/webdesk/ECMCardService?wsdl`,
{
method: "POST",
redirect: "follow",
credentials: "omit",
headers: {
"Content-Type": "text/xml;charset=utf-8"
},
body: xml
})
.then(response => response.text())
.then(xmlText => (new DOMParser()).parseFromString(xmlText, "text/xml"))
.then(function (response) {
const message = response.getElementsByTagName("webServiceMessage")[0].textContent;
if (message != "ok") {
throw message;
}
return response;
});
}
1 curtida
Boa gaspareto,
Vale para página publica tb?
Porque ai da para usar como uma middleWare essas rotinas
@Daniel_Sales , dá sim. Até fazendo a chamada pelo SoapUI funciona de boa. É uma chamada normal SOAP. Só precisa avaliar o risco mesmo.
O problema de fazer chamada SOAP pelo JS assim é que a gente precisa colocar o usuário e senha do usuário no XML e o Fluig nem aceita isso na tag header, passando senha em base64, vai direto no campo usuário e senha.
Se alguém inspecionar o JS vai achar essa informação. Mesmo que faça igual a mim, que guardo em formulário e puxo a informação por dataset, basta inspecionar as chamadas ao Fluig pra conseguir pegar o usuário e senha.
Em uma página com usuário logado talvez a API REST melhore a segurança (acho que a Form Management ) talvez atenda. Mas até agora não usei muito a API REST por ser muito fraca de opções quando comparada com a SOAP.
Em uma página pública, com mais tipos de usuários acessando, o risco aumentaria bastante. Talvez o ideal seja realmente fazer um middleware pra não exibir a senha e garantir a segurança.
1 curtida
aonde que eu vejo o cardId do meu documento?
@Lucas_Maciel_dos_San , quando você consulta um dataset que é de um formulário ele normalmente tem o metadata#id e/ou o documentid, que representam o id do dado do formulário.
Então antes de tentar atualizar os dados do formulário você precisa antes pegar esse ID, seja pesquisando por algum campo específico, ou de uma lista, etc.
1 curtida
Dou preferencia sempre a api rest por ser mais facil de usar?
Funciona bem mas em pagin publica não uso pois tem que expor as chaves rest o mesmo problema do soap passando usuario e senha. Vou tentar usar a passagem de parametro via url talves deum pouco mais de segurança.
Você é monstro kkkkk.
nesse caso eu estaria atualizando os dados de um formulário existente ou criando um formulário com os dados na qual eu quero? ( eu preciso guardar as informações escritas na widget em formulário ).
@Lucas_Maciel_dos_San , já que é criação e numa widget veja a possibilidade de usar a chamada REST Form Management. Se não me engano ela já utiliza a sessão do usuário logado. Mas se for usar a SOAP é o método create.
O documentid, já que é uma criação, acredito que seja o ID da “pasta” do formulário. Mas como nunca corri atrás de criação de registro, sempre fui nas alterações, não tenho certeza. Esse ID você acha no GED do Fluig. Um formulário é representado como se fosse uma pasta.
1 curtida
@Daniel_Sales, até uso a REST em algumas coisas, mas no geral ela dá muito menos opções do que a SOAP.
A parte boa da REST é que pra página privada ela já pega a sessão do usuário logado, então é uma segurança a mais.
Eu ainda penso em fazer algumas modificações nas widgets que temos pra chamar datasets que fazam as chamadas aos WS ao invés de deixar usuário e senha sendo enviados pro navegador. Mas como por enquanto só usamos em páginas privadas acabei não correndo com essa melhoria.
