DevPortalPagoPA



Tabella dei contenuti

Soglie e approvazioni

Quando un erogatore crea una nuova versione di e-service, imposta due soglie di tolleranza per la propria infrastruttura:
  • il numero massimo di chiamate API/giorno consentite al singolo fruitore;
  • il numero massimo totale di chiamate API/giorno sommate su tutti i fruitori.
Queste soglie, previste dalle Linee Guida, favoriscono il corretto dimensionamento del servizio e la continuità operativa.

Considerazioni amministrative e di privacy

Le soglie e le stime di carico sono strumenti tecnici a supporto dell’operatività. Quando si trattano dati personali, la quantità di dati estratti e le relative motivazioni vanno indicate nell’analisi del rischio, che include la domanda:
“Indicare se si conosce la quantità di dati personali di cui si entrerà in possesso attraverso la fruizione del presente e-service.”
Eventuali giustificazioni sono riportate in quella sede.

Approvazione manuale

Un fruitore con una richiesta di fruizione attiva può dichiarare nuove finalità fino al raggiungimento di una delle due soglie. Al superamento di una soglia, le nuove finalità entrano in stato in attesa di approvazione.
L’erogatore verifica la stima dichiarata e può attivare manualmente le finalità. Se la richiesta supera la capacità dichiarata, l’erogatore contatta il fruitore o comunica una data stimata per l’adeguamento dell’infrastruttura.

Aggiornamento delle soglie

L’erogatore può aggiornare le soglie in qualsiasi momento senza creare una nuova versione dell’e-service. L’aggiornamento si applica immediatamente e riguarda solo le finalità ricevute dopo la modifica.
Le finalità che risultavano in attesa di approvazione prima della modifica vanno approvate manualmente.

Esempi pratici

Soglia per fruitore

  1. Versione 1 di “E-service esempio”: 2.000 chiamate API/giorno per fruitore e 50.000 totali.
  2. Ente B si iscrive e la richiesta viene attivata.
  3. Ente B crea tre finalità: 1.000, 1.000 e 1 chiamata/giorno.
La terza finalità è in attesa di approvazione (somma = 2.001 > 2.000 per fruitore). L’erogatore può approvare manualmente o innalzare la soglia per fruitore.

Soglia totale

  1. Versione 1 di “E-service esempio”: 5.000 chiamate API/giorno per fruitore e 10.000 totali.
  2. Ente B, C e D si iscrivono e le richieste vengono attivate.
  3. Ente B e Ente C creano una finalità ciascuno da 5.000 chiamate/giorno, e raggiungono 10.000 chiamate/giorno complessive.
  4. Ente D crea una finalità da 1 chiamata/giorno.
La finalità di Ente D va in attesa di approvazione. L’erogatore può approvare manualmente o innalzare la soglia totale.

Aggiornamento della stima di carico di una finalità

  • Ente B passa una finalità da 1.000 a 5.000 chiamate/giorno.
  • La finalità resta attiva a 1.000 e in attesa di approvazione a 5.000.
    → Il fruitore continua a operare con la vecchia stima fino all’approvazione della nuova.
    Se la nuova stima rimane sotto entrambe le soglie, viene attivata automaticamente.

Aggiornamento di una soglia dell'e-service

  1. La versione 1 dell'e-service E-service esempio erogato da Ente A prevede 5.000 chiamate API/giorno per fruitore e 10.000 chiamate API/giorno totali;
  2. Ente B si iscrive come fruitore; la richiesta di fruizione viene attivata;
  3. Ente B crea e inoltra una finalità per E-service esempio, Finalità 1, con 5.000 chiamate API/giorno;
  4. la finalità viene attivata automaticamente dalla piattaforma;
  5. Ente C si iscrive come fruitore; la richiesta di fruizione viene attivata;
  6. Ente C crea e inoltra una finalità per E-service esempio, Finalità 1, con 5.000 chiamate API/giorno;
  7. la finalità viene attivata automaticamente dalla piattaforma;
  8. Ente D si iscrive come fruitore; la richiesta di fruizione viene attivata;
  9. Ente D crea e inoltra una finalità per E-service esempio, Finalità 1, con 1 chiamata API/giorno;
  10. l'erogatore, Ente A, innalza la soglia totale a 15.000 chiamate API/giorno.
In questo caso, la finalità Finalità 1 di Ente D rimane In attesa di approvazione e dovrà essere approvata manualmente dall'erogatore.
Se però un qualsiasi ente iscritto all'e-service dovesse creare nuove finalità che, sommate, rimangano sotto alla nuova disponibilità, quell'ente si troverà le finalità direttamente Attive. La nuova disponibilità è di 5.000 chiamate API/giorno (originariamente 10.000, innalzata a 15.000).

Gestione dei picchi di chiamate

Il modello di soglie è pensato per la pianificazione del carico nel tempo; i picchi (es. “click day”) e la gestione real time vanno gestiti con strumenti di monitoraggio e controllo dell’erogatore.

Best practice per evitare i picchi

  • preferire invii distribuiti nel tempo rispetto a chiamate sincrone simultanee;
  • utilizzare code e processi asincroni interni per diluire il carico;
  • definire finestre orarie e priorità per gestire volumi elevati.

Monitoraggio

Gli erogatori e i fruitori conservano la traccia di tutte le chiamate API ricevute, come previsto nel MoDI, così da:
  • analizzare l’andamento del carico;
  • identificare pattern ricorrenti (es. picchi in finestre orarie specifiche);
  • confrontare stima dichiarata e traffico effettivo.
Maggiori informazioni nella sezione dedicata.

Pagina successiva → Portachiavi

Hai bisogno di aiuto?

Apri un ticket utilizzando l’apposita funzione all’interno della tua Area Riservata

Dicci cosa ne pensi

Per segnalare problemi o dare feedback, puoi aprire una segnalazione su Github