Indicatori di qualità per i soggetti aderenti

pageLivelli di Servizio Enti CreditoripageLivelli di Servizio PSP

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

• 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:

• nodoInviaFlussoRendicontazione

• sendPaymentOutcome

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:

• activatePaymentNotice

• demandPaymentNotice

• nodoChiediElencoFlussiRendicontazione

• nodoChiediFlussoRendicontazione

• nodoChiediInformativaPA

• nodoChiediTemplateInformativaPSP

• nodoChiediCatalogoServizi

• verificaBollettino

• verifyPaymentNotice

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).