Come recuperare i segnali

Si assume che il consumatore sia un aderente fruitore, che possa accedere a un e-service abilitato a Signal Hub, che abbia un client api (vedi i requisiti per l'uso di Signal Hub).

Si assume che il consumatore di segnali abbia acquisito i dati relativi alle modalità di pseudonimizzazione (vedi come ottenere le informazioni crittografiche) e che si trovi ad esempio:

Si assume che il consumatore di segnali abbia calcolato gli id pseudonimizzati e sia in grado di associarli agli identificativi in chiaro dei soggetti, ad esempio:

Si assume che il consumatore di segnali sia in grado di calcolare gli id pseudonimizzati e sia in grado di associarli agli identificativi in chiaro dei soggetti, ad esempio:

Il segnale depositato su Signal Hub ha un retention period (vedi sezione specifica) e oltre questo periodo non sarà più disponibile in lettura. Di conseguenza non potranno essere recuperati segnali che superano il retention period. Vedere la sezione relativa per le regole di polling verso le API di recupero del segnale senza perdere gli aggiornamenti.

Il consumatore ottiene il voucher api da PDND (vedi documentazione):

Il fruitore legge i segnali invocando il servizio di recupero segnali:

Nella richiesta al servizio dovranno essere presenti le seguenti informazioni (fare riferimento al documento OpenAPI per i valori di default, min, max)

Nella risposta sono presenti:

Se poniamo a 10 il numero totale di segnali presenti, relativi a un e-service

Richiesta n. 1

Risposta n. 1
Http Status 206

Lo Http Status 206 indica che esistono ancora dei segnali; quindi, il consumatore creerà una nuova richiesta impostando il query param signalId uguale al valore di lastSignalId presente nella risposta:

Richiesta n. 2

Risposta n. 2
Http Status 200

Lo Http Status 200 indica che, nello stato attuale, non ci sono più segnali da leggere: oltre il "lastSignalId": 10 non esiste un signalId successivo.

In un’ottica di long polling verso il servizio, la nuova richiesta da effettuare sarà:

che otterrebbe questo risultato:
Http Status 200

fino a che la risposta non cambierà (Http Status 206, signals e lastSignalId valorizzati) , cioè fino a quando non ci saranno nuovi segnali.

Se poniamo a 4 il numero totale di segnali presenti, relativi a un e-service

Richiesta n. 1

Risposta n. 1
Http Status 200

Lo Http Status 200 indica che, nello stato attuale, non ci sono più segnali da leggere: oltre il "lastSignalId": 4 non esiste un signalId successivo.

In un’ottica di long polling verso il servizio, la nuova richiesta da effettuare sarà:

Otterrebbe questo risultato:

fino a che la risposta non cambierà (signals e lastSignalId valorizzati) , cioè fino a quando non ci saranno nuovi segnali.

Il consumatore di segnali deve tenere traccia del valore del lastSignalId presente nella risposta dell’API di recupero segnali. Il lastSignalId consente di ottenere i segnali successivi a partire dal valore specificato. Vedi sezione “Esempio richiesta che non esaurisce i segnali in una chiamata”.

Una volta recuperata la lista dei segnali dal servizio, il consumatore la elabora attraverso il proprio stato interno per stabilire se un segnale è rilevante oppure no.

Ponendo che il consumatore abbia una propria base dati di questo tipo, capace di associare a un identificativo in chiaro (da usare per interrogare l’e-service) a un identificativo pseudonimizzato.

Ponendo che il consumatore sia capace di associare un identificativo in chiaro (da usare per interrogare l’e-service) a un identificativo pseudonimizzato, ad esempio:

Ponendo che il consumatore abbia ricevuto questa lista di segnali:

Il consumatore potrà individuare come rilevante il segnale con signalId = 3, dato che è in grado di associarlo a un proprio identificato pseudonimizzato. Gli altri messaggi saranno ignorati in quanto non rilevanti, relativi a soggetti per cui il consumatore non ha procedimenti amministrativi in corso.

Il consumatore ottiene così una lista degli identificativi in chiaro dei dati soggetti a variazione:

A partire da questa lista il consumatore invocherà l’e-service con gli identificativi in chiaro, richiedendo per ciascun soggetto il dato aggiornato. Il consumatore potrà attivare, se necessario, ulteriori processi interni dovuti alla variazione dello stato del dato.

Nel caso di segnale di tipo seedUpdate, in base al signalId, il fruitore potrà dedurre che tutti i segnali con signalId maggiore del signalId del seedUpdate saranno impattati dalla modifica al criterio di calcolo dell'objectId. Vedi sezione relativa al deposito segnale di aggiornamento delle informazioni crittografiche.

Ad esempio, in questa sequenza il consumatore di segnali, dopo avere letto il messaggio con signald = 3 dovrà interrogare nuovamente l’e-service per ottenere le informazioni crittografiche, e una volta ottenute ricalcolare tutti gli id pseudonimizzati (vedi come ottenere le informazioni crittografiche).

\