Integrazioni degli allarmi

Collega una struttura al modello di un partner di monitoraggio e gestisce tale connessione: salvataggio (modello, numero di conto, mappa delle zone, eventi, campi della struttura), rimozione, richiesta di approvazione, invio di un segnale di test, attivazione dopo un test riuscito ed eliminazione di una modifica in sospeso.

Una connessione live (active o failing) cambia solo con applyMode: staged mantiene gli allarmi sulle impostazioni live finché un test della modifica in sospeso non riesce e la attivi; immediate applica subito. I campi segreti vengono accettati ma mai restituiti. Richiede External Integrations presso la struttura. Leggi prima con alarm_integrations_read connections.

Azioni:

• save: Salva una connessione. templateId è necessario per una nuova connessione. fields imposta i campi della struttura per chiave (null ne cancella uno; i segreti vengono sigillati). Su una connessione live passa applyMode, altrimenti la chiamata fallisce con apply-mode-required. Richiede partnerId. Chiede conferma.
• remove: Rimuovi una connessione. Rimuove la connessione della struttura al partner, insieme a eventuali modifiche in sospeso; da qui gli allarmi non vengono più inviati a quella centrale di monitoraggio. Richiede partnerId. Chiede conferma.
• request_approval: Richiedi l'approvazione. Chiede alla centrale di monitoraggio di approvare la connessione o di assegnare un numero di conto (modelli con approvazione del partner). Richiede partnerId.
• send_test_signal: Invia un segnale di test. Mette in coda un segnale di test reale verso la centrale di monitoraggio; interroga test_signal_status. staged: true testa la modifica in sospeso invece delle impostazioni live. Richiede partnerId. Chiede conferma.
• activate: Attiva una connessione o una modifica. Rende live una connessione in attesa, promuove una modifica in sospeso o conferma una non testata. L'attivazione richiede il requestId di un test riuscito dopo l'ultima modifica: un test della modifica in sospeso (staged: true) promuove una modifica in sospeso, un test live ne conferma una non testata. Richiede partnerId, requestId. Chiede conferma.
• discard_pending_change: Elimina una modifica in sospeso. Scarta la modifica in sospeso; le impostazioni live restano invariate. discarded è false quando non c'era nulla in sospeso. Richiede partnerId. Chiede conferma.

Aggiunge, modifica, elimina e attiva come test le destinazioni di allarme personalizzate: il tuo ricevitore di monitoraggio, una scheda relè, SMS, chiamata vocale, email, webhook, chat del team o un servizio di reperibilità (l'elenco dei canali), a livello di struttura (predefinito), brand o organizzazione.

Le impostazioni non segrete vanno in config; i segreti (password, URL di webhook, chiavi) vanno in fields per percorso dell'impostazione e vengono sigillati, mai restituiti. Le destinazioni abilitate richiedono una config completa. Le destinazioni della struttura richiedono External Integrations o Duress Configuration presso di essa; quelle di brand e organizzazione richiedono l'accesso a livello di organizzazione. Leggi prima con alarm_integrations_read destinations.

Azioni:

• save: Salva una destinazione. Senza connectionId ne aggiunge una (servono channel e name); con connectionId ne modifica una (il canale resta invariato). config, se inviato, sostituisce le impostazioni non segrete; i segreti omessi da fields vengono mantenuti. Chiede conferma.
• remove: Elimina una destinazione. Elimina la destinazione; un relè della struttura smette anche di azionare il relè di allarme. Richiede connectionId. Chiede conferma.
• send_test_signal: Invia un test a una destinazione. Mette in coda un messaggio di test reale verso la destinazione; interroga alarm_integrations_read test_signal_status con la struttura. Le destinazioni di brand e organizzazione vengono testate da facilityId. Richiede connectionId. Chiede conferma.

Legge dove vanno gli allarmi Duress di una struttura al di fuori di Performance Hub: le sue connessioni alle centrali di monitoraggio (partner, modello, numero di conto, mappa delle zone, stato, requisiti mancanti, modifiche in sospeso), le destinazioni personalizzate (ricevitori di monitoraggio, relè, SMS, chiamate vocali, email, webhook, chat, servizi di reperibilità) della struttura, del suo brand e dell'organizzazione, un'anteprima dell'instradamento, il registro delle consegne e gli esiti dei segnali di test.

Richiede External Integrations o Duress Configuration presso la struttura. Segreti e valori sigillati non vengono mai mostrati, solo { key, secret, hasValue }; numeri e indirizzi delle persone vengono oscurati da instradamento e consegne. Gli orari sono in formato ISO. Modificali con alarm_integrations_connections_write e alarm_integrations_destinations_write.

Azioni:

• connections: Connessioni alle centrali di monitoraggio. Le connessioni ai partner della struttura: modello, numero di conto (linkingIdentifier), mappa delle zone, eventi, connectionStatus, missing (cosa impedisce di andare live), pendingChange (in sospeso, non ancora live) e untestedChange. canEdit: External Integrations qui.
• destinations: Destinazioni personalizzate. Le destinazioni che possono attivarsi per la struttura (le sue, quelle del suo brand e dell'organizzazione, ciascuna con canEdit), oppure con ownerScope quelle di un solo ambito. Impostazioni in config; segreti come fields { key, secret, hasValue }.
• routing: Anteprima dell'instradamento. Dove andrebbe un allarme in questo momento (solo impostazioni live), come lo risolve universal-api: destinazioni con lane, eventi e config senza segreti, problems che spiegano ciò che è stato escluso e pendingChanges non ancora instradate. eventType mantiene solo ciò che riceve quell'evento.
• deliveries: Registro delle consegne. Consegne degli allarmi dalla più recente (stato, canale, ricevitore, latenza, testo pubblico dell'errore). Una pagina filtrata può essere corta e avere comunque nextCursor. Gli avvisi dei dispositivi compaiono come kind alert.
• test_signal_status: Esito del segnale di test. queued finché universal-api non registra un tentativo, poi succeeded (un ricevitore ha confermato o è stato inviato) oppure failed, con le righe di consegna. Usa la struttura da cui è stato inviato il test. Richiede requestId.