Perguntas Frequentes (FAQs)

Requisito de negócio: é necessário oferecer suporte a vários modos de assinatura para atender às diferentes necessidades dos usuários 1. Há suporte para três modos de assinatura: - Assinatura global: assina eventos de todos os recursos relacionados. Após a conta principal se inscrever, todas as subcontas são assinadas automaticamente por padrão - Assinatura por usuário: é necessário fornecer object_ids específicos, ou seja, os IDs dos usuários - Assinatura por questionário: é necessário fornecer object_ids específicos, ou seja, os IDs dos questionários 2. Regras de configuração: - Exceto pela assinatura global, todos os outros modos de assinatura devem incluir os object_ids correspondentes - Ao assinar por usuário, o evento de criação de questionário não precisa de object_ids - Ao assinar por questionário, o evento de criação de questionário não pode ser incluído

Pergunta de negócio: é necessário esclarecer os tipos de eventos suportados e seu escopo específico 1. Suporta 7 tipos de eventos: - Criar pesquisa - Modificar pesquisa (apenas edições nas perguntas, excluindo alterações nas configurações da pesquisa) - Excluir pesquisa - Resposta concluída - Resposta atualizada - Resposta excluída - Resposta inválida (retorna o motivo da invalidez)

Problema de negócio: O comprimento do campo de autorização precisa ser controlado para garantir a segurança Regra de negócio: - O comprimento do campo de autorização é limitado a 0-512 caracteres

Problema de negócio: é necessário garantir a confiabilidade dos callbacks de webhook Regras de negócio: 1. Repetir até 5 vezes 2. Intervalos de repetição: - 1ª repetição: 10 segundos - 2ª repetição: 1 minuto - 3ª repetição: 5 minutos - 4ª repetição: 30 minutos (enviar um e-mail de lembrete sobre a falha no envio) - 5ª repetição: 1 dia (enviar um e-mail de lembrete sobre o envio ter sido desativado)

Problema de negócio: Você precisa lidar com falhas consecutivas e notificar o usuário Regras de negócio: 1. O sistema define automaticamente todos os webhooks com a mesma URL como desativados 2. Envia uma notificação por e-mail ao usuário (o e-mail será enviado para a conta principal) 3. Salva os registros de falha em uma fila separada com o id do webhook como chave (retidos por 7 dias) 4. Permite que o usuário faça o backfill dos dados em até 7 dias

Problema de negócio: os eventos precisam ser tratados durante o período em que o webhook está desativado 1. Os registros de eventos dentro de 7 dias após a desativação são armazenados em uma fila separada 2. Se o número de desativações exceder 1, entre em contato com o suporte técnico 3. Depois que ele for reativado, os dados enfileirados serão enviados proativamente

Pergunta de negócio: os logs de chamadas de webhook precisam ser registrados para solução de problemas Regras de negócio: - O callback precisa incluir registros de logs da Alibaba Cloud em formato JSON

Problema de negócio: deve ser evitada a duplicação de configurações de webhook Regras de negócio: 1. A seguinte combinação de campos deve ser única: - subscription_model (modo de assinatura) - event_type (tipo de evento) - object_ids (IDs do objeto) - url_subscription (URL de assinatura) 2. Exceção: o uso do mesmo url_subscription para eventos diferentes não é restrito

Pergunta de negócio: É आवश्यक um formato de hora unificado, juntamente com um link de acesso ao recurso. Regras de negócio: 1. O horário do evento retorna um timestamp em nível de milissegundos. 2. Os parâmetros de envio incluem uma URL de acesso ao recurso.

Pergunta de negócio: É necessário esclarecer os tipos de status do webhook e seu impacto Regras de negócio: o status do webhook é dividido em quatro tipos: 1. Dados históricos (status=0) 2. Disponível (status=1) 3. Indisponível (status=2, sem envio) 4. Desativado pelo sistema (status=3, várias falhas de callback)