Eines
Un pont entre plataformes d'aprenentatge
Migrar i sincronitzar usuaris i cursos entre una plataforma vella i una
2 min de lectura
Tenia diversos WordPress amb LearnDash —cursos en diverses instal·lacions— i calia portar-ho tot a un únic Moodle. No era una migració puntual: a més de migrar, s'havia de continuar sincronitzant. D'aquesta necessitat en va sortir un pont entre les dues plataformes, i el projecte més seriós que he fet per compte propi.
El problema de veritat no eren els cursos
Migrar cursos és mecànic. El problema eren les persones: el mateix alumne existia en varies instal·lacions amb el mateix correu, i si no ho tractaves bé acabaves duplicant comptes o, pitjor, perdent el progrés que ja tenia. Per això la decisió central del projecte és que el correu és la identitat única, i la deduplicació (esbrinar quan dues fitxes són la mateixa persona) es fa en un sistema canònic propi: el WordPress és l'origen de dades, el pont és el sistema canònic, i el Moodle és la plataforma final de formació.
Com està fet
Un plugin propi de WordPress (un complement que l'amplia) exposa les dades de LearnDash per REST, una manera estàndard de demanar dades a un altre programa: cursos, usuaris, matrícules i progrés, amb paginació i filtres per data per a la sincronització incremental (només el que ha canviat des de l'última volta). Les matrícules es detecten tres vegades per no perdre cap: les ordres de WooCommerce, les natives de LearnDash i la taula d'activitat. Al mig, un panell de control amb FastAPI, React i PostgreSQL, i Celery amb Redis (una cua de tasques) perquè les operacions llargues corrin en segon pla: la API mai es bloqueja, i cada execució queda registrada amb els seus registres i es pot repetir si ha fallat. Moure dades entre sistemes no em era nou —ja havia automatitzat documents entre Excel i XML, com vaig contar a Automatització de documents: Excel i XML— però aquesta era una altra escala.
Lliçons que vaig aprenc per les males
La primera: idempotència o mort. Repetir una importació no ha de generar mai duplicats (idempotència: repetir l'operació no canvia el resultat), perquè a la pràctica sempre es repeteix. La segona: mai confiar en l'ordre de les coses; el mapeig és per slug o per ID, mai per posició. I la tercera: dry-run abans d'escriure (simular sense tocar res). Tot canvi contra el Moodle de producció es simula primer, es valida al panell i només llavors s'aplica. Quan treballes amb el progrés real d'alumnes, la simulació no és una opinió de disseny: és la diferència entre un incident i una feina tranquil·la.
Què faria diferent avui
Començaria pel pla de fases, que vaig anar escrivint a mesura que el projecte creixia, i seria més estricte tancant l'abast inicial: les subscripcions i el SSO (un sol inici de sessió per a tots els sistemes) els vaig deixar fora per una bona raó i hauria estat més honest encara. I posaria proves d'integració contra un Moodle de proves des del primer dia, perquè la API oficial també et fa sorpreses.