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.

  1. Gestione di pagamenti spontanei

  2. Gestione di pagamenti con bilancio

  3. Gestione della notifica dello stato del pagamento da parte dell'IdP - se disponibile - o del polling se non è disponibile la notifica

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

  5. Gestione delle configurazioni a livello di Tenant e di Servizio

Requisiti normativi

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

MetricaLabelsDescrizione

oc_payment_validation_errors_total

cluster, env, app_name

la metrica deve misurare gli errori di validazione sull'evento letto (es. l'importo è una stringa invece che un float)

oc_api_requests_total

cluster, env, method, app_name, status_code

la metrica deve monitorare le chiamate http indicandone lo status code

oc_payment_success_events_total

cluster, env, app_name

la metrica deve misurare solo gli eventi per cui il proxy ha una configurazione e che stati processati con successo

oc_payment_failed_events_total

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)

oc_payment_provider_errors_total

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

oc_payment_internal_errors_total

cluster, env, app_name

la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing per errori interni al codice

oc_payment_provider_latency_bucket

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

Logo

Documentazione Opencity Italia