Implementazione di un proxy
Molti aspetti implementativi dipendono più dalla normativa che da nostre scelte progettuali, in questa pagina si evidenziano gli uni e le altre.
Requisiti funzionali
Sono requisiti che dipendono da nostre scelte implementative, possono cambiare man mano che evolviamo la piattaforma, per supportare nuovi casi d'uso (pagamento dei dovuti) oppure perché ci accorgiamo che abbiamo commesso qualche errore nella progettazione.
Gestione di pagamenti spontanei
Gestione di pagamenti con bilancio
Gestione della notifica dello stato del pagamento da parte dell'IdP - se disponibile - o del polling se non è disponibile la notifica
Se è implementato il polling, questo deve avvenire con un back-off esponenziale che assicuri alcuni check nel giro di pochi minuti e poi si diradi fino a un massimo di un check al giorno fino alla scadenza del pagamento o 1 anno se la scadenza è inferiore.
Gestione delle configurazioni a livello di Tenant e di Servizio
Requisiti normativi
Avere una specifica in formato OpenAPI v3
Rispettare la Linee Guida di interoperabilità: in particolare per quanto riguarda
il formato dei dati (4.2)
raccomandazioni sul naming (4.3) optando per la scelta di
snake_case
per i nomi degli attributilogging (4.4)
risultare valido nel validatore ufficiale OA3
Requisiti per l'ambiente di produzione
Sappiamo che in molti topic ci sono diversi eventi mal formati, per vari errori e assenza di uno schema registry, quindi è necessario validare gli eventi in input e opzionalmente in output (lo fanno le nostre prime implementazioni in python, ma è un requisito?)
Ci aspettiamo che se di dovesse aggiornare il formato dell'evento nel topic
payments
gestiremo eventi anche in parallelo con versioni distinte, quindi ogni proxy deve Interpretare solo gli eventi che riportano il formato più recente dell'evento nel topic payments:event_version: 2.0
Integrarsi con sentry per la gestione degli errori
Esporre metriche di monitoraggio in formato prometheus, in particolare:
counter sul numero di pagamenti creati
counter sul numero di errori durante il processamento di pagamenti, differenziando gli errori interni (errori di formato dati in ingresso o validazione) da errori esterni (errori di dialogo con l'IdP)
latenza delle chiamate fatte all'IdP
Di seguito la tabella contenente le specifiche di ogni metrica
Metrica | Labels | Descrizione |
---|---|---|
| cluster, env, app_name | la metrica deve misurare gli errori di validazione sull'evento letto (es. l'importo è una stringa invece che un float) |
| cluster, env, method, app_name, status_code | la metrica deve monitorare le chiamate http indicandone lo status code |
| cluster, env, app_name | la metrica deve misurare solo gli eventi per cui il proxy ha una configurazione e che stati processati con successo |
| cluster, env, app_name | la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing per qualsiasi motivo (escluso il caso in cui non esiste una configurazione per esso) |
| cluster, env, app_name | la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing a causa di un errore sul provider |
| cluster, env, app_name | la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing per errori interni al codice |
| cluster, env, app_name | istogramma che mostra la distribuzione di latenza delle risposte del provider |
Inoltre il servizio deve rispettare gli standard della piattaforma in particolare per quanto riguarda la gestione dello storage: non possiamo avere vendor-lockin sulle tecnologie, quindi dobbiamo essere compatibili con file-system posix tradizionale, NFS share e almeno i due cloud-storage più diffusi S3 e Azure Blob.
Documentazione API di Esempio - Swagger
Esempi di proxy da cui si può prendere spunto
EFIL: http://gitlab.com/opencontent/stanza-del-cittadino/efil-payment-proxy
IRIS: http://gitlab.com/opencontent/stanza-del-cittadino/iris-payment-proxy
MYPAY: http://gitlab.com/opencontent/stanza-del-cittadino/mypay-payment-proxy
PMPAY: http://gitlab.com/opencontent/stanza-del-cittadino/pmpay-payment-proxy
Questi proxy condividono alcune scelte implementative grazie a un apposito python-sdk sviluppato in parallelo ai proxy stessi:
le configurazioni sono salvate su disco locale o s3 secondo un albero ben definito tenant->servizio
i singoli pagamenti vengono salvati su storage fino a che il pagamento è pendente, così da poter fare il polling in autonomia.
Altri riferimenti utili
Last updated