Domande Frequenti (FAQs)

Esigenza di business: è necessario supportare più modalità di sottoscrizione per soddisfare le diverse esigenze degli utenti 1. Sono supportate tre modalità di sottoscrizione: - Sottoscrizione globale: si sottoscrivono gli eventi di tutte le risorse correlate. Dopo che l'account principale si è sottoscritto, tutti gli account secondari vengono sottoscritti automaticamente per impostazione predefinita - Sottoscrizione per utente: è necessario fornire specifici object_ids, cioè gli ID degli utenti - Sottoscrizione per questionario: è necessario fornire specifici object_ids, cioè gli ID dei questionari 2. Regole di configurazione: - Ad eccezione della sottoscrizione globale, tutte le altre modalità di sottoscrizione devono includere i corrispondenti object_ids - Quando ci si sottoscrive per utente, l'evento di creazione del questionario non necessita di object_ids - Quando ci si sottoscrive per questionario, l'evento di creazione del questionario non può essere incluso

Domanda di business: è necessario chiarire i tipi di eventi supportati e il loro ambito specifico 1. Supporta 7 tipi di eventi: - Creazione del sondaggio - Modifica del sondaggio (solo modifiche alle domande, escluse le modifiche alle impostazioni del sondaggio) - Eliminazione del sondaggio - Risposta completata - Risposta aggiornata - Risposta eliminata - Risposta non valida (restituisce il motivo dell'invalidità)

Problema aziendale: la lunghezza del campo di autorizzazione deve essere controllata per garantire la sicurezza Regola aziendale: - La lunghezza del campo di autorizzazione è limitata a 0-512 caratteri

Problema aziendale: è necessario garantire l'affidabilità delle callback webhook Regole di business: 1. Ritentare fino a 5 volte 2. Intervalli di ritentativo: - 1° ritentativo: 10 secondi - 2° ritentativo: 1 minuto - 3° ritentativo: 5 minuti - 4° ritentativo: 30 minuti (inviare un'email di promemoria sul fallimento dell'invio) - 5° ritentativo: 1 giorno (inviare un'email di promemoria che l'invio è stato disabilitato)

Problema aziendale: devi gestire i fallimenti consecutivi e notificare l'utente Regole aziendali: 1. Il sistema disattiva automaticamente tutti i webhook con lo stesso URL 2. Invia una notifica via email all'utente (l'email verrà inviata all'account principale) 3. Salva i record dei fallimenti in una coda separata con l'id del webhook come chiave (conservati per 7 giorni) 4. Consente all'utente di recuperare i dati entro 7 giorni

Problema operativo: gli eventi devono essere gestiti durante il periodo in cui il webhook è disattivato 1. I record degli eventi entro 7 giorni dalla disattivazione vengono archiviati in una coda separata 2. Se il numero di disattivazioni supera 1, contattare l'assistenza tecnica 3. Dopo la riattivazione, i dati in coda verranno inviati automaticamente

Domanda di business: i log delle chiamate webhook devono essere registrati per la risoluzione dei problemi Regole di business: - Il callback deve includere i record di log di Alibaba Cloud in formato JSON

Problema di business: è necessario impedire configurazioni webhook duplicate Regole di business: 1. La seguente combinazione di campi deve essere univoca: - subscription_model (modalità di sottoscrizione) - event_type (tipo di evento) - object_ids (ID oggetto) - url_subscription (URL di sottoscrizione) 2. Eccezione: l'uso dello stesso url_subscription per eventi diversi non è soggetto a restrizioni

Domanda di business: è richiesto un formato orario unificato, insieme a un link di accesso alla risorsa. Regole di business: 1. L'ora dell'evento restituisce un timestamp in millisecondi. 2. I parametri di invio includono un URL di accesso alla risorsa.

Domanda di business: è necessario chiarire i tipi di stato del webhook e il loro impatto Regole di business: lo stato del webhook è suddiviso in quattro tipi: 1. Dati storici (status=0) 2. Disponibile (status=1) 3. Non disponibile (status=2, nessun invio) 4. Disabilitato dal sistema (status=3, più errori di callback)