DevPortalPagoPA


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:
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
6
NOTA: 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},
28
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: 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
  • seretryAfter0 è 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:
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
6
NOTA: 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
  • seretryAfter0 è 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:
An image
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:
An image
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:
An image
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
  • seretryAfter0 è 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:
An image
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
  • seretryAfter0 è 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.

Hai bisogno di aiuto?

Invia una richiesta di supporto utilizzando SEND - Supporto Enti