Guia de Tratamento de Erros
Esta guia tem um conjunto de filtros em que você precisa especificar a regra de resposta. Se houver uma correspondência, a transação será considerada incorreta e um texto de erro personalizado também será gerado.
Você pode criar vários blocos separados de uma vez. Cada bloco pode ter seu próprio texto de erro. O bloco consiste em grupos de filtros e é acionado apenas se todos os filtros forem completamente correspondentes.
Assim, podem ser criados diversos blocos com condições de filtro e textos de erro específicos, ou um bloco com várias opções de filtro.
Para a definição do tipo de erro, os seguintes valores estão disponíveis:
Default - erro padrão. Se os dados corresponderem ao filtro, a transação é considerada inválida.
InvalidCredential - as condições que estão escritas neste tipo de erro indicam que o usuário está com problemas na conexão que é usada no bundle. Ou seja, os dados de autorização não estão mais válidos.
ExpiredToken - nesse tipo de erro, você precisa especificar no filtro o texto da resposta, o que significa que o token de acesso expirou e precisa ser atualizado. Se for usada a autorização, na qual você precisa atualizar o token de acesso após a expiração, esse tipo de erro é necessário. Quando as condições de um bloco com este tipo coincidirem, o aplicativo fará uma solicitação para atualizar o token (configurado na autorização) e o salvará na conexão. Em seguida, será feita uma tentativa de solicitação novamente com um novo token de acesso (após a atualização). Se o erro persistir mesmo após a tentativa de atualização, a transação será considerada incorreta e o texto do erro será exibido de acordo com o mapeamento.
Neste campo, é escrito o texto que será exibido no log do bundle se ocorrer um erro. No campo, você pode inserir um valor estático ou atribuir um mapeamento à variável de resposta, cujo valor será exibido. O mapeamento deve ser escrito entre duas chaves {{ }}. No início você precisa escrever data., se a variável necessária estiver no corpo da resposta, ou headers., se a variável estiver nos cabeçalhos da resposta.
Veja o exemplo do texto de resposta com a seguinte descrição:
Nesse caso, o mapeamento deve ser especificado da seguinte forma: {{ data.response.error }}
Consiste na configuração das condições que indicam ao aplicativo que a solicitação é considerada inválida.
No campo esquerdo, escreva o mapeamento para a chave da variável que você deseja seguir (o mapeamento também deve começar com data. ou headers.). Selecione um operador de condição e, no campo à direita, especifique um valor de variável que indica um erro.
Você também pode definir o valor headers.http-code no campo esquerdo. Esta chave irá monitorar o código de resposta HTTP e você pode escrever 400 no valor, por exemplo.
Dentro de um bloco, é possível criar um número ilimitado de condições, definindo o operador entre as condições (E/OU). Cada condição também pode ser convertida em um grupo de condições para uma definição mais precisa. Por exemplo: status = erro 1 (result = mensagem1 OU result = mensagem2) ( status = erro E (result = erro1 OU result = erro2))
Vamos pegar o JSON do exemplo de mapeamento de erro. Se o JSON aparecer neste formato apenas quando houver um erro, após solicitações bem-sucedidas, e a variável response.error estiver ausente, é possível preencher o filtro para que ele responda ao fato de que o campo apareceu na resposta. Neste caso, à esquerda, escreva o mapeamento data.response.error, defina o operador "Igual" e, no valor, selecione na lista do sistema o parâmetro "Valor vazio".
Assim, se na resposta não houver campo, a solicitação não é considerada errônea. Contudo, assim que esta variável aparecer na resposta e for preenchida com algo (mesmo por uma linha vazia ““), a transação será considerada inválida.
Neste caso, vamos considerar que a resposta vem com uma variável que indica claramente que ocorreu um erro:
No mapeamento da mensagem é especificado o caminho para a variável com o texto de erro {{ data.reason }} e no filtro é colocado data.status = error.
Você pode criar vários blocos separados de uma vez. Cada bloco pode ter seu próprio texto de erro. O bloco consiste em grupos de filtros e é acionado apenas se todos os filtros forem completamente correspondentes.
Assim, podem ser criados diversos blocos com condições de filtro e textos de erro específicos, ou um bloco com várias opções de filtro.
Tipos de erros
Para a definição do tipo de erro, os seguintes valores estão disponíveis:
Default - erro padrão. Se os dados corresponderem ao filtro, a transação é considerada inválida.
InvalidCredential - as condições que estão escritas neste tipo de erro indicam que o usuário está com problemas na conexão que é usada no bundle. Ou seja, os dados de autorização não estão mais válidos.
ExpiredToken - nesse tipo de erro, você precisa especificar no filtro o texto da resposta, o que significa que o token de acesso expirou e precisa ser atualizado. Se for usada a autorização, na qual você precisa atualizar o token de acesso após a expiração, esse tipo de erro é necessário. Quando as condições de um bloco com este tipo coincidirem, o aplicativo fará uma solicitação para atualizar o token (configurado na autorização) e o salvará na conexão. Em seguida, será feita uma tentativa de solicitação novamente com um novo token de acesso (após a atualização). Se o erro persistir mesmo após a tentativa de atualização, a transação será considerada incorreta e o texto do erro será exibido de acordo com o mapeamento.
Mapeamento de mensagem de erro
Neste campo, é escrito o texto que será exibido no log do bundle se ocorrer um erro. No campo, você pode inserir um valor estático ou atribuir um mapeamento à variável de resposta, cujo valor será exibido. O mapeamento deve ser escrito entre duas chaves {{ }}. No início você precisa escrever data., se a variável necessária estiver no corpo da resposta, ou headers., se a variável estiver nos cabeçalhos da resposta.
Veja o exemplo do texto de resposta com a seguinte descrição:
{"response":{ "error":"token invalido" }}Nesse caso, o mapeamento deve ser especificado da seguinte forma: {{ data.response.error }}
Filtro de condições
Consiste na configuração das condições que indicam ao aplicativo que a solicitação é considerada inválida.
No campo esquerdo, escreva o mapeamento para a chave da variável que você deseja seguir (o mapeamento também deve começar com data. ou headers.). Selecione um operador de condição e, no campo à direita, especifique um valor de variável que indica um erro.
Você também pode definir o valor headers.http-code no campo esquerdo. Esta chave irá monitorar o código de resposta HTTP e você pode escrever 400 no valor, por exemplo.
Dentro de um bloco, é possível criar um número ilimitado de condições, definindo o operador entre as condições (E/OU). Cada condição também pode ser convertida em um grupo de condições para uma definição mais precisa. Por exemplo: status = erro 1 (result = mensagem1 OU result = mensagem2) ( status = erro E (result = erro1 OU result = erro2))
Exemplos
Exemplo 1
Vamos pegar o JSON do exemplo de mapeamento de erro. Se o JSON aparecer neste formato apenas quando houver um erro, após solicitações bem-sucedidas, e a variável response.error estiver ausente, é possível preencher o filtro para que ele responda ao fato de que o campo apareceu na resposta. Neste caso, à esquerda, escreva o mapeamento data.response.error, defina o operador "Igual" e, no valor, selecione na lista do sistema o parâmetro "Valor vazio".
Assim, se na resposta não houver campo, a solicitação não é considerada errônea. Contudo, assim que esta variável aparecer na resposta e for preenchida com algo (mesmo por uma linha vazia ““), a transação será considerada inválida.
Exemplo 2
Neste caso, vamos considerar que a resposta vem com uma variável que indica claramente que ocorreu um erro:
{"status":"error","reason":"Token expirou"}No mapeamento da mensagem é especificado o caminho para a variável com o texto de erro {{ data.reason }} e no filtro é colocado data.status = error.
Atualizado em: 01/12/2022
Obrigado!