Da strumento interno a SaaS: automatizzare il download degli estratti conto
Abbiamo creato uno script per scaricare automaticamente i nostri estratti conto Wise. È un lavoro da un pomeriggio. La domanda più interessante, a cui abbiamo impiegato molto più tempo a rispondere, era se lo stesso strumento potesse servire altre aziende con lo stesso problema e cosa occorresse per compiere quel passaggio in modo responsabile. Il percorso da uno script CLI sul portatile di uno sviluppatore a un servizio in container con notifiche email ha fatto emergere decisioni che vale la pena documentare, soprattutto per i team che valutano se trasformare un’automazione interna in un prodotto.
Il problema iniziale
Wise offre un’API per accedere ai dati degli account, ma per la maggior parte dei team amministrativi la procedura abituale è accedere all’interfaccia web e scaricare manualmente un estratto conto CSV alla fine di ogni mese. Per un solo account con una sola valuta, bastano due minuti. Per attività che gestiscono più valute su più account Wise, uno scenario comune nelle aziende con flussi di pagamento regionali, diventa un onere ricorrente: qualcuno deve ricordarsene, eseguire il lavoro con regolarità e archiviare correttamente i file.
L’API Wise espone gli endpoint necessari. Puoi recuperare un elenco di profili, ottenere i saldi per valuta e richiedere esportazioni degli estratti conto in formato CSV o PDF per qualsiasi intervallo di date. L’autenticazione avviene tramite un token di accesso personale generato nella dashboard per sviluppatori di Wise. Se configurato con l’ambito corretto, il token consente soltanto la lettura dei dati dell’account: può quindi essere conservato e utilizzato senza il profilo di rischio di un token capace di avviare trasferimenti.
La nostra prima implementazione contava circa 80 righe di Python. Leggeva le credenziali dalle variabili d’ambiente, scorreva i profili e i saldi per valuta, costruiva le richieste di estratti conto per il mese precedente e scriveva i file in una directory locale. Veniva eseguita manualmente. All’epoca era sufficiente per le nostre esigenze.
Dallo script al servizio pianificato
Il passaggio dall’esecuzione manuale a quella automatica introduce problemi di natura diversa. Un errore silenzioso in uno script eseguito manualmente viene notato subito. Uno script pianificato che fallisce silenziosamente il primo di ogni mese può passare inosservato per diversi mesi, lasciando nell’archivio degli estratti conto una lacuna che emerge durante un audit.
Abbiamo trasferito lo script in un container Docker con un semplice entrypoint e aggiunto un wrapper che invia una notifica email al termine, sia in caso di successo sia in caso di errore. L’email riepiloga gli account e le valute elaborati, il numero di file scaricati e le loro dimensioni. In caso di errore, include il relativo output. È un investimento minimo nell’osservabilità, ma cambia l’impegno operativo: l’automazione viene ora monitorata anche se funziona senza intervento diretto.
La pianificazione è gestita da GitHub Actions, anziché da cron all’interno del container. Usiamo un trigger pianificato su un flusso di lavoro che viene eseguito all’inizio di ogni mese; una pianificazione cron da sola non consente di selezionare i giorni lavorativi, quindi per saltare i fine settimana e i giorni festivi serve un controllo aggiuntivo della data nel flusso di lavoro. Il flusso di lavoro esegue il checkout del repository, costruisce l’immagine Docker se è cambiata, avvia il container con i segreti forniti da GitHub Secrets e carica i file di output come artefatti del flusso di lavoro. Gli artefatti vengono conservati per 90 giorni e costituiscono un archivio recuperabile indipendente da qualsiasi archiviazione locale.
GitHub Actions ha un vantaggio pratico rispetto a un job cron su un server: la visibilità. La cronologia mostra ogni esecuzione, la sua durata, il codice di uscita e gli artefatti prodotti. Un job cron su un server genera log facili da trascurare e dipende dalla disponibilità del server. Per un’attività mensile, una cronologia verificabile delle esecuzioni, con una definizione del flusso di lavoro sotto controllo di versione, vale il piccolo onere di configurazione.
Cosa richiede davvero un servizio multi-tenant
Dopo diversi mesi di funzionamento affidabile della versione in container, colleghi di altre aziende ci hanno chiesto se potessero usarla. La domanda sembra semplice: altre persone possono eseguire il tuo strumento? In realtà, questa possibilità comprende molti modelli operativi, con implicazioni assai diverse.
Il modello più semplice consiste nel condividere il repository e la documentazione: gli altri eseguono lo strumento nel proprio ambiente GitHub Actions o Docker, senza assistenza da parte tua. È una distribuzione open source, non un prodotto SaaS. L’onere operativo ricade interamente sull’utente.
Il passo successivo consiste nell’ospitare lo strumento e lasciare che gli utenti forniscano i propri token API Wise tramite un’interfaccia di configurazione. A quel punto custodisci credenziali. Questo crea immediatamente obblighi di sicurezza e conformità di natura diversa rispetto a un’automazione personale. Devi chiarire come vengono conservate le credenziali, chi può accedervi, cosa succede se l’archivio viene compromesso e quale responsabilità hai se qualcuno accede all’account Wise di un utente tramite la tua piattaforma.
Il passo ancora successivo comprende fatturazione, assistenza, impegni sui livelli di servizio e l’onere operativo di gestire un’infrastruttura per più utenti. Nessuno di questi aspetti è insormontabile, ma ciascuno richiede una decisione sull’investimento tecnico da sostenere e sul costo operativo ricorrente che sei disposto ad assumere.
La valutazione dell’opzione SaaS
Abbiamo valutato l’opzione elencando i requisiti di una versione multi-tenant minima e stimando con realismo il costo di ciascuno. La sola gestione delle credenziali, cioè archiviare in sicurezza i token API Wise, fornire un’interfaccia per gestirli e implementare controlli che impediscano l’accesso ai dati di altri tenant, richiede una settimana di lavoro tecnico prima ancora di affrontare il download degli estratti conto. Aggiungendo autenticazione degli utenti, fatturazione, un servizio di invio email con gestione delle disiscrizioni e monitoraggio degli errori dei job per ciascun tenant, ottieni un prodotto che richiede investimenti continuativi per essere mantenuto in sicurezza.
Anche il mercato di questo specifico strumento è limitato. Le aziende abbastanza grandi da voler automatizzare il download degli estratti conto spesso dispongono già di software contabili integrati direttamente con Wise, oppure di team amministrativi che hanno risolto il problema autonomamente. Il mercato potenziale è nella fascia intermedia: aziende abbastanza grandi da avvertire il problema, ma che non usano ancora sistemi contabili integrati.
Abbiamo concluso che, nella fase attuale, lo strumento non fosse un buon candidato SaaS per il nostro team. Il potenziale di ricavo non giustificava l’investimento tecnico e operativo. La distribuzione open source soddisfa l’esigenza concreta senza creare obblighi che non possiamo sostenere.
Cosa abbiamo mantenuto e cosa abbiamo cambiato
Lo strumento interno è ancora in funzione. Nel tempo lo abbiamo esteso per supportare l’output PDF oltre al CSV, inviare gli estratti conto direttamente a un indirizzo email invece di affidarsi al recupero degli artefatti e consentire intervalli di date configurabili. Può così essere avviato manualmente per richieste occasionali senza modificare l’esecuzione mensile pianificata.
Il flusso di lavoro GitHub Actions è diventato il meccanismo di distribuzione di riferimento. Lo documentiamo nel README del repository con dettagli sufficienti perché chi non usa lo strumento da sei mesi possa capire cosa fa e come gestirlo. È una disciplina utile per ogni automazione interna: tratta gli strumenti interni come se dovessi affidarli a qualcun altro, perché prima o poi succederà.
La lezione più duratura riguarda la distanza tra «funziona per noi» e «funziona per altri». Gli strumenti interni sono adattati ai tuoi vincoli specifici: gestione delle credenziali, convenzioni di archiviazione dei file, infrastruttura email. Renderli abbastanza generici da poter essere usati da altri non significa soltanto aggiungere un file di configurazione. Richiede di eliminare assunzioni implicite di cui non ti eri accorto finché qualcun altro non ha provato lo strumento e si è scontrato con esse.