Contesto: Rilascio di una nuova versione di servizio PDND, ad esempio passando da una v3 ad una v4, con relative modifiche di tracciato e campi normativi.
Sul portale PDND, un utente amministrativo può vedere che è disponibile una nuova versione di un e-service (di cui è sottoscrittore), consultare la documentazione e poi decidere quando fare richiesta di fruizione per la nuova versione.
Problema: Quando l’utente utilizza l’apposito tasto “Aggiorna” e procede con la richiesta di “Aggiornamento Richiesta di Fruizione”, il sistema abilita automaticamente la sottoscrizione alla nuova versione (marcata come “attivo”) andando però a disabilitare (contestualmente) l’utilizzo della vecchia (marcata come “archiviato”).
Andando di fatto a migrare (massivamente!!) l’aggancio all’ e-service per tutti i client e tutte le finalità registrate sul portale, invece che più semplicemente abilitarli alla versione nuova senza rimuoverli/disabilitarli sulla “vecchia”. Senza alcuna possibilità da parte dell’utente di scegliere cosa agganciare subito alla versione nuova e cosa lasciare (temporaneamente) ancora sulla versione precedente.
Spiegazione della richiesta: Quando è disponibile una nuova versione di e-service, come da standard API la nuova versione viene marcata come attiva mentre quella precedente come deprecata. Questo step viene fatto dal sistema, che in fase di gestione PDND indica il servizio vecchio come deprecato.
Tuttavia, poi all’atto pratico di gestione delle sottoscrizioni, il portale poi non permette ad un Ente di utilizzare entrambe le versioni per dare tempo (async) di adattare i suoi sistemi interni e quindi procedere con una migrazione di servizio controllata. L’Ente risulta obbligato in modo del tutto sincrono a decidere se “tutto” utilizza una o l’altra versione.
Non vi è quindi possibilità per l’Ente di continuare ad usare la versione deprecata (fosse anche solo per 3gg) se anche solo uno dei suoi applicativi deve utilizzare l’ultima versione fin da subito. L’Ente è quindi forzato a lavorare in modo super-sincrono su tutti gli applicativi interni che usano il servizio, magari con finalità diverse, perdendo di fatto il vantaggio di avere delle API di disaccoppiamento versionate nel mezzo con una API che, sebbene deprecata, risulti ancora disponibile e richiamabile durante le attività di riadattamento.
Richiesta: Possibilità di far scegliere all’utente/Ente se procedere con una migrazione (massiva) di tutto alla nuova versione, come funziona ora. Oppure passare alla nuova versione solo per specifiche finalità (-> maggiore granularità e flessibilità). Oppure più semplicemente lasciare abilitata sia la nuova versione che quella deprecata dell’e-service, passando ad uno stato “archiviata” solo in un secondo momento quando tutti gli applicativi dell’Ente saranno stati migrati alla release più recente.