Tabella dei contenuti
Indicatori di qualità per i soggetti aderenti
Tempo di risposta
Il grafico seguente descrive i tempi di attraversamento della piattaforma pagoPA
- il Tempo Elaborazione rappresenta quanto indicato in Livelli di servizio dei metodi degli ec;
- il Timeout Nodo rappresenta quanto indicato in Gestione dei timeout verso gli ec o Gestione dei timeout verso i psp, a seconda della natura del Chiamato Nodo;
- il Timeout Chiamante Nodo rappresenta quanto indicato in Gestione dei timeout del nodo per i metodi sincroni.
Il grafico seguente descrive i tempi nel caso in cui la piattaforma pagoPA agisca da server nel caso di metodi non sincroni
.png)
- il Timeout Chiamante Nodo rappresenta quanto indicato in Gestione dei timeout del nodo per i metodi non sincroni.
Il grafico seguente descrive i tempi nel caso in cui la piattaforma pagoPA agisca da client
- il Tempo Elaborazione rappresenta quanto indicato in Livelli di servizio dei metodi degli ec o Livelli di servizio dei metodi dei psp, a seconda della natura del Chiamato Nodo;
- il Timeout Nodo rappresenta quanto indicato in Gestione dei timeout verso gli ec o Gestione dei timeout verso i psp, a seconda della natura del Chiamato Nodo.
Processi di retry
Nei casi di timeout dovranno essere attivati dei processi di retry per le seguenti primitive:
I processi di retry dovranno adottare per il calcolo del tempo di attesa una logica di backoff esponenziale a partire dalla rilevazione del timeout
$$tempo di attesa = slot time * (2^k - 1)$$
con K che è il numero del tentativo (primo tentativo = 1) e slottime è uguale al tempo massimo di attesa del chiamante originale.
Il processo di retry deve prevedere il numero massimo di 5 tentativi, devono essere predisposte delle funzionalità per consultare ed azzerare il contatore dei tentativi, così che il processo possa essere riavviato in caso di necessità.
Nei casi di timeout per le seguenti primitive:
non è necessario un processo di retry automatico, ma qualora sia necessaria una nuova invocazione il tempo di attesa minimo prima di effettuare un nuovo tentativo deve rispettare la logica di backoff esponenziale sopra esposta.
Gestione dei timeout del Nodo
Il timeout rappresenta un periodo di tempo predeterminato trascorso il quale una data operazione può essere considerata conclusa da EC e PSP.
Nella tabella seguente sono riportati per ciascuna primitiva
- i tempi minimi di attesa per i metodi sincroni
- i tempi suggeriti di attesa per i metodi non sincroni
della response del Nodo
da parte degli EC
| Primitiva | Timeout in secondi | Sincrona |
|---|---|---|
| nodoChiediElencoFlussiRendicontazione | 15 | |
| nodoChiediFlussoRendicontazione | 60 |
da parte dei PSP
| Primitiva | Timeout in secondi | Sincrona |
|---|---|---|
| activatePaymentNotice | 12 | |
| demandPaymentNotice | 12 | |
| nodoChiediCatalogoServizi | 15 | |
| nodoChiediInformativaPA | 15 | |
| nodoChiediTemplateInformativaPSP | 15 | |
| nodoInviaFlussoRendicontazione | 60 | |
| sendPaymentOutcome | 15 | |
| verificaBollettino | 12 | |
| verifyPaymentNotice | 12 |
Tempo di risoluzione di un evento critico
Al verificarsi di un evento critico l’Ente Creditore o il PSP entro 5 minuti devono prendere in carico il problema e quindi inviare via e-mail al Tavolo Operativo del NodoSPC le indicazioni circa la pianificazione di massima che adotteranno per la risoluzione del problema in questione, articolata in funzione della complessità del problema stesso (ad es.: bug fixing immediato, eventuale soluzione transitoria, chiusura dell’evento).
Dicci cosa ne pensi
Per chiarimenti sulle specifiche d’implementazione, come SACI e SANP, puoi aprire una segnalazione su GitHub