Esplorando PDND Interoperabilità: Segnali di variazione (Signal Hub)
Processo di distribuzione dei segnali di variazione (Signal Hub)
Il Signal Hub è l’integrazione di PDND Interoperabilità che permette agli aderenti di rimanere aggiornati se cambia un dato di loro interesse in una base dati della quale sono fruitori.
In questo webinar vedremo una presentazione del funzionamento di Signal Hub ad alto livello, e un approfondimento sull'invio e la ricezione dei segnali, che comprenderà anche una dimostrazione pratica.
Ospiti
Salvatore Borgesi
Junior Frontend Engineer
Paolo Manca
Senior Software Engineer
Le risposte alle vostre domande
C’è un periodo di retention dei segnali?
Si, di 30 giorni
Durante la fase di creazione di un e-service, è obbligatorio attivare SH ?
No, è assolutamente opzionale
Ma l’abilitazione di SH è legata ad uno specifico descrittore?
No, il servizio non fa riferimento ad uno specifico descrittore ma bensì all’ E-service.
Cosa succede se SH viene disabilitato in un secondo momento?
In questo caso non sarà possibile ne per l’erogatore depositare nuovi segnali, ne per il fruitore recuperare i segnali
Qual’è può essere un approccio per cui si resta in ascolto dell’API per il recupero dei segnali?
Si raccomanda di una frequenza minima di una richiesta al giorno in modo da non “accumulare” segnali.
Tutti le tipologie dati dovranno essere pseudonimizzate?
No, è necessario solo per i dati personali
Sono necessari altri passaggi oltre alla richiesta di fruizione e all’analisi del rischio?
No, basta avere una richiesta di fruizione in stato ACTIVE, e una analisi del rischio associata
Come fa un fruitore a ricevere un segnale? Deve interrogare delle API per sapere se sono stati depositati segnali per lui? o li riceve in automatico in altra maniera (tipo un servizio lato fruitore che recepisce i segnali)?
Il fruitore deve interrogare attivamente le API (“short/long polling“)del servizio di recupero segnali (API /pull) ; ciascun fruitore deve implementarlo per ogni e-service per cui vuole ricevere aggiornamenti. Al momento non esiste un servizio a disposizione del fruitore che recepisce i segnali.
objectid (pseudonimizzato), quindi, deve essere presente anche nella banca dati oggetto di aggiornamento: come dichiaro qual è l'identificativo prescelto?
Si, l’objectId deve essere presente
Sembra che il fruitore possa effettuare una verifica di dati aggiornati SOLO in modo puntuale, ovvero partendo da un record specifico di suo interesse. Non può "sfogliare" tutti gli eventi arrivati e allinearli tutti nel db locale?
Il fruitore può sfogliare gli eventi usando il signalId e dimensionando la riposta con il parametro size: Come recuperare i segnali | Manuale Operativo Signal Hub | PDND Interoperabilità | DevPortal
In generale un fruitore non dovrebbe trattenere un dato che si è recuperato per una certa finalità in un certo istante. Quindi in quale realtà si può calare il signal-hub? ci sono diverse retention possibili?
Al momento è prevista una retention dei segnali fissata a 30 giorni calcolati dal momento in cui il segnale entra nel sistema (quando l’erogatore lo invia).
Il fruitore, una volta recuperato il segnale, sa solo che è occorso un evento per un certo identificativo.
Come si fa a capire se l'aggiornamento di un dato è più recente rispetto all'ultimo scarico dei dati?
L’erogatore ordina i segnali per signalId crescente; il segnale con signalId maggiore è quello più recente.
Chi sta utilizzando i servizi SEND per le notifiche digitali, ha necessità di implementare questo recupero di segnali? In caso, che tipo di variazioni possiamo aspettarci?
Al momento non è pianificata nessuna integrazione tra SEND e Signal Hub.
Quando viene recepito un segnale, questo viene cancellato su signal-hub?
Il segnale viene cancellato solo dopo 30 giorni a partire dal momento in cui è stato depositato dall’erogatore.
Il fruitore può leggerlo più di una volta, se necessario.
Il processi di calcolo del ObjectID è descritto di volta in volta dall'erogatore e come viene condiviso con il fruitore ?
Il processo di calcolo dell'ObjectID deve essere descritto dall’erogatore nella documentazione dell’e-service; il calcolo deve essere conforme alle indicazioni presenti nella documentazione di Signal Hub e nell’allegato 4 delle evoluzione delle LL GG di Interoperabilità.
Come funziona la pseudonimizzazione e l'aggiornamento del SEED?
Rimandiamo alla guida, per informazioni relativa al funzionamento
SH è già in funzione? Ci sono erogatori che espongono Endpoint?
Signal Hub è in fase di sperimentazione, al momento non ci sono erogatori che lo espongano ufficialmente.
Ad ogni scarico dei segnali di un eservice posso escludere quelli che ho già elaborato?
Certamente. Nella lettura dei segnali è necessario che il fruitore sappia a quale signalId è arrivato; per evitare di rileggere segnali già elaborati dovrebbe salvare un dato “lastSignalIdProcessed” (per esempio) e partire da quello per le letture successive
L'endpoint esposto dall'erogatore per condividere algoritmo di HASH e seme si somma agli altri endpoint già esposti per lo specifico e-service ?
Esatto. In questo modo il fruitore troverà sia i dati sia i criteri (hash, seme) per ottenere i segnali di variazione relativi agli stessi dati.
L'ObjectID viene calcolato in real time al momento dell'invio del segnale?
L’erogatore ha convenienza nel calcolarlo nel momento dell’invio del segnale, supponendo che i dati soggetti a variazione siano sempre minori dei dati totali. Potrebbe anche pre-calcolarlo in batch o secondo tempistiche proprie, adeguate al proprio caso d’uso.