Tabella dei contenuti
Lettura degli eventi di uno stream
Questa pagina descrive la procedura operativa per la lattura e consumo di uno stream
I dati registrati dallo stream possono essere letti tramite l'API di consumo degli eventi registrati dallo stream. La lettura degli eventi avviene a blocchi di massimo 50 elementi. Per consumare gli elementi successivi a quelli di una lettura precedente è necessario specificare il lastEventId come descritto nei paragrafi sottostanti.
Lettura degli eventi tramite comando CURL
Prima interrogazione
La prima interrogazione dello stream permetterà di ricevere i primi 50 eventi registrati dallo stream. E' importante lanciare la curl con il --verbose che permetterà di visualizzare nell'header della response il valore "retry-after" utile per la prossima chiamata.
Lanciare il seguente comando:
Lanciare il seguente comando:
1curl --location 'https://<baseurlAmbiente>/delivery-progresses/v2.8/streams/<streamId>/events' \
2--header 'Accept: application/json' \
3--header 'x-api-key: <apiKey>' \
4--header 'Authorization: Bearer <PDNDVoucher>' \
5--verbose
6NOTA: sostituire i seguenti:
- <baseurlAmbiente>: inserire la url dell'ambiente di riferimento, nel caso di UAT è il seguente: https://api.uat.notifichedigitali.it
- <apiKey>: inserire la apiKey dell'Ente di riferimento, precedentemente generata su PND
- <PDNDVoucher>: inserire inserire il Voucher generato su PDND Interoperabilità, assicurandosi che non sia scaduto
- <streamId>: inserire l'id dello stream che si vuole interrogare
Nella response di questo servizio, si otterrà il seguente payload che rappresenta tutti gli eventi:
1{
2 "eventId": "00000000000000000000000000000000000001",
3 "timestamp": "<timestamp>",
4 "notificationRequestId": "<notificationRequestId>",
5 "iun": "<iun>",
6 "newStatus": "<newStatus>",
7 "timelineEventCategory": "<timelineEventCategory>",
8 "recipientIndex": "<recipientIndex>",
9 "analogCost": <analogCost>,
10 "channel": "<channel>",
11 "legalfactIds": ["<legalfactIds>"],
12 "validationErrors": <validationErrors>
13},
14[... altri eventi...]
15{
16 "eventId": "00000000000000000000000000000000000049",
17 "timestamp": "<timestamp>",
18 "notificationRequestId": "<notificationRequestId>",
19 "iun": "<iun>",
20 "newStatus": "<newStatus>",
21 "timelineEventCategory": "<timelineEventCategory>",
22 "recipientIndex": "<recipientIndex>",
23 "analogCost": <analogCost>,
24 "channel": "<channel>",
25 "legalfactIds": ["<legalfactIds>"],
26 "validationErrors": <validationErrors>
27},
28Gli eventi ottenuti dovranno essere memorizzati dal client poichè nelle successive chiamate i risultati ottenuti verranno consumati e cancellati dallo stream per lasciare il posto agli eventi successivi.
NOTA: nell'header della response ottenuta fare attenzione al campo "retry-after" che deve essere memorizzato per le successive chiamate:
- seretryAfter = 0 è possibile richiamare immediatamente il servizio per ottenere gli eventi successivi se invece
- seretryAfter ≠ 0 è necessario attendere la quantità di tempo (espressa in millisecondi) del valore restituito, prima di richiamare di nuovo il servizio
E' quindi fondamentale rispettare la logica che viene rappresentata dal campo retry-after il quale fornisce l'indicazione al client su quando richiamare il servizio; pertanto si sconsiglia di creare dei processi di batch che effettuino la chiamata in un momento fisso e/o ripetuto nei giorni.
Lettura dello stream successive alla prima
Dalle interrogazioni successive alla prima dello stream, si otterranno i 50 eventi successivi a quello del lastEventId (l'eventId dell'ultimo evento ottenuto nelle precedenti chiamate).
Anche in questo caso è importante lanciare la curl con il --verbose che permetterà di visualizzare nell'header della response il valore "retry-after" utile per le chiamate successive.
Lanciare il seguente comando:
Anche in questo caso è importante lanciare la curl con il --verbose che permetterà di visualizzare nell'header della response il valore "retry-after" utile per le chiamate successive.
Lanciare il seguente comando:
1curl --location 'https://<baseurlAmbiente>/delivery-progresses/v2.8/streams/<streamId>/events?lastEventId=<lastEventId>' \
2--header 'Accept: application/json' \
3--header 'x-api-key: <api-key>' \
4--header 'Authorization: Bearer <PDNDVoucher>' \
5--verbose
6NOTA: sostituire i seguenti:
- <baseurlAmbiente>: inserire la url dell'ambiente di riferimento, nel caso di UAT è il seguente: https://api.uat.notifichedigitali.it
- <apiKey>: inserire la apiKey dell'Ente di riferimento, precedentemente generata su PND
- <PDNDVoucher>: inserire inserire il Voucher generato su PDND Interoperabilità, assicurandosi che non sia scaduto
- <streamId>: inserire l'id dello stream che si vuole interrogare
- <lastEventId>: inserire l'eventId dell'ultimo evento ottenuto nella precedente chiamata
Gli eventi ottenuti dovranno essere memorizzati dal client poichè nelle successive chiamate i risultati ottenuti verranno consumati e cancellati dallo stream per lasciare il posto agli eventi successivi.
NOTA: nella response ottenuta fare attenzione al campo "retry-after" che deve essere memorizzato per le successive chiamate:
- seretryAfter = 0 è possibile richiamare immediatamente il servizio per ottenere gli eventi successivi se invece
- seretryAfter ≠ 0 è necessario attendere la quantità di tempo (espressa in millisecondi) del valore restituito, prima di richiamare di nuovo il servizio
E' quindi fondamentale rispettare la logica che viene rappresentata dal campo "retry-after" il quale fornisce l'indicazione al client su quando richiamare il servizio; pertanto si sconsiglia di creare dei processi di batch che effettuino la chiamata in un momento fisso e/o ripetuto nei giorni.
Lettura degli eventi tramite comando CURL
Prima lettura dello stream
La prima interrogazione dello stream permetterà di ricevere i primi 50 eventi registrati dallo stream.
Aprire la scheda Leggi progressi notifiche e riprodurre questa configurazione:
Aprire la scheda Leggi progressi notifiche e riprodurre questa configurazione:
.png)
NOTA: sostituire i seguenti:
- <baseurl>: inserire la url dell'ambiente di riferimento, nel caso di UAT è il seguente: https://api.uat.notifichedigitali.it
- <streamId>: inserire l'id dello stream che si vuole interrogare
Nella response di questo servizio, si otterrà il seguente payload che rappresenta tutti gli eventi:
.png)
Gli eventi ottenuti dovranno essere memorizzati dal client poichè nelle successive chiamate i risultati ottenuti verranno consumati e cancellati dallo stream per lasciare il posto agli eventi successivi.
E' poi necessario selezionare il tab Headers della response per visualizzare i valori ottenuti:
E' poi necessario selezionare il tab Headers della response per visualizzare i valori ottenuti:
.png)
NOTA: nell'header della response ottenuta fare attenzione al campo retry-after che deve essere memorizzato per le successive chiamate:
- seretryAfter = 0 è possibile richiamare immediatamente il servizio per ottenere gli eventi successivi se invece
- seretryAfter ≠ 0 è necessario attendere la quantità di tempo (espressa in millisecondi) del valore restituito, prima di richiamare di nuovo il servizio
E' quindi fondamentale rispettare la logica che viene rappresentata dal campo "retry-after" il quale fornisce l'indicazione al client su quando richiamare il servizio; pertanto si sconsiglia di creare dei processi di batch che effettuino la chiamata in un momento fisso e/o ripetuto nei giorni.
Letture dello stream successive alla prima
Dalle interrogazioni successive alla prima dello stream, si otterranno i 50 eventi successivi a quello del lastEventId (l'eventId dell'ultimo evento ottenuto nelle precedenti chiamate).
Aprire la scheda Leggi progressi notifiche e riprodurre questa configurazione:
Aprire la scheda Leggi progressi notifiche e riprodurre questa configurazione:
.png)
NOTA: sostituire i seguenti:
- <baseurlAmbiente>: inserire la url dell'ambiente di riferimento, nel caso di UAT è il seguente: https://api.uat.notifichedigitali.it
- <streamId>: inserire l'id dello stream che si vuole interrogare
- <lastEventId>: inserire l'eventId dell'ultimo evento ottenuto nella precedente chiamata
Gli eventi ottenuti dovranno essere memorizzati dal client poichè nelle successive chiamate i risultati ottenuti verranno consumati e cancellati dallo stream per lasciare il posto agli eventi successivi.
NOTA: nella response ottenuta fare attenzione al campo "retry-after" che deve essere memorizzato per le successive chiamate:
- seretryAfter = 0 è possibile richiamare immediatamente il servizio per ottenere gli eventi successivi se invece
- seretryAfter ≠ 0 è necessario attendere la quantità di tempo (espressa in millisecondi) del valore restituito, prima di richiamare di nuovo il servizio
E' quindi fondamentale rispettare la logica che viene rappresentata dal campo "retry-after" il quale fornisce l'indicazione al client su quando richiamare il servizio; pertanto si sconsiglia di creare dei processi di batch che effettuino la chiamata in un momento fisso e/o ripetuto nei giorni.