Erro 409 na primitiva UPLOADFILE

[Thymóteo Martins]

# 3 anos, 10 meses atrás

Bom dia pessoal,

Estou utilizando a primitiva “/actions/uploadFile”, conforme orientado no tutorial, como parte da nossa solução integrada à plataforma Senior X. Porém após algumas utilizações estão tendo o erro abaixo para qualquer arquivo que tentamos registrar. Conto com o apoio o quanto antes pois esta rotina esta sendo utilizada como parte da nossa solução integrada à plataforma.

code: 409 – Error: Conflict

{
“message”: “area already exists”,
“errorCode”: “uploadFileResponse”,
“reason”: “CONFLICT”,
“domain”: “platform”,
“service”: “blob_service”
}

Este erro diz respeito ao parametro areaSecret? Este parâmetro é utilizado para criar a área de transferência, quando não existente, porém se já existir deveria retornar este erro?

Segue um exemplo do payload de entrada enviado:

{
“domainName”: “custom”,
“serviceName”: “gestao_rochas”,
“areaSecret”: “senior-es-dev-gestao_rochas”,
“targetObjectId”: “teste”,
“fileName”: “teste”,
“requirements”: [
“Open”
],
“supportedProtocols”: [
“File”
]
}

[roque.possamai]

# 3 anos, 10 meses atrás

Olá Thymóteo, tudo bem?

O parâmetro areaSecret é para que você consiga aplicar um certo nível de segurança em uma determinada área de transferência. Com isso, evitaríamos que um serviço diferente, inadvertidamente, sobrescrevesse ou excluísse arquivos que não são do seu \”domínio\”.

Fazendo uma analogia com um sistema de arquivos comum, os domainName e serviceName formam uma espécie de diretório. Quando eles são criados, eles ficam associados com o valor do areaSecret que você informou naquela primeira chamada.
Uma vez definido, não é mais possível alterá-lo. Então, para todas as chamadas subsequentes, você precisará informar o mesmo areaSecret, caso contrário, ele irá tentar criar uma nova área, mas ela já existe.

Desta forma, a hipótese mais provável é que você está tentando gravar dados em um domínio/serviço informando um valor de areaSecret diferente.

Em algum momento você utilizou um valor diferente para o parâmetro areaSecret? Se sim, tente informar este valor original na chamada da API.
E, caso vc queria utilizar um outro areaSecret, precisará informa, ao menos, um domainNameou serviceName diferente.

Espero ter ajudado.
Roque Possamai.

[Thymóteo Martins]

# 3 anos, 10 meses atrás

Bom dia Roque, muito obrigado pela explicação. Ficou bem claro agora. Eu havia imaginado o areaSecret como uma ‘pasta’ dentro do domain/service. Então, realmente, na regra de negócio que montamos ja foi passado um valor diferente para este parâmetro.

Vou revisar a lógica montamos para passarmos esta variação para o domainName ou Service/Name.

Novamente, obrigado pelo apoio.

[roque.possamai]

# 3 anos, 10 meses atrás

Bom dia Thymóteo.

Quem bom que pudemos ajudar.
Em sequência, será criado um ticket interno para complementarmos o tutorial a fim de deixar este comportamento mais claro.

Até mais.
Roque Possamai.

[Thymóteo Martins]

# 3 anos, 10 meses atrás

Roque,

Avaliando agora este cenário, entendo que o conjunto Domain + Service + areaSecret ja esteja sendo aplicado de forma individual a cada tenant de cliente certo?

Neste sentido eu poderia ter essa combinação para qualquer tenant que eles continuariam a ser válidos, certo?

“domainName”: “custom”,
“serviceName”: “gestao_rochas”,
“areaSecret”: “tenant-do-cliente” (desde que no mesmo tenant ele nao mude)

[roque.possamai]

# 3 anos, 10 meses atrás

Olá Thymóteo,

Avaliando agora este cenário, entendo que o conjunto Domain + Service + areaSecret ja esteja sendo aplicado de forma individual a cada tenant de cliente certo?

Sim, a verificação/validação do atributo areaSecret é por tenant.

Então, não há a necessidade de você criar diferentes secrets para o mesmo serviço em tenant diferentes. Apesar de ser possível utilizar este formato, isto pode aumentar a complexidade do seu código sem necessidade. O recomendado é que cada conjunto de domainName+serviceName utilizem areaSecrets diferentes para evitar um serviço interfira nos arquivos de outro serviço inadvertidamente.

Att,
Roque

[Thymóteo Martins]

# 3 anos, 10 meses atrás

Perfeito, Roque.

Agradeço novamente!