Da un po' di tempo nel linguaggio AL sono state introdotte le interface, una struttura che può venirci in aiuto in determinate situazioni. Leggendo la documentazione ufficiale, però, può risultare poco chiaro il loro funzionamento.
In questo post voglio mostrarvi un esempio pratico del loro utilizzo.
Lo scenario
Ho creato una piccola app, che faccio sviluppare da zero nel mio corso di AL avanzato e che gestisce l'erogazione dei corsi. La app prevede un processo di fatturazione che è stato erogato che viene lanciato da una voce di menu dell'edizione.
Ora, supponiamo di volere implementare due procedure di fatturazione alternative: una, che chiameremo Simple, e l'altra, che chiameremo Complex. La differenza tra le due logiche di fatturazione al momento non ci interessa, potrebbero essere di qualsiasi genere, come ad esempio la modalità di compilazione delle righe di ciascuna fattura, accorpate oppure no.
Supponiamo infine di voler dare la possibilità all'utente di scegliere l'una o l'altra modalità al momento del lancio della fatturazione attraverso un menu di scelta
Classicamente la soluzione a questo problema consiste nel crearsi due codeunit alternative e lanciare l'una o l'altra a seconda della scelta. Operando in questo modo, però, se chi acquista la nostra app volesse creare una propria procedura facendola scegliere all'utente come alternativa a quelle standard, dovrebbe intervenire in uno degli eventi a disposizione, oppure creare una action aggiuntiva nella pagina che faccia lanciare una delle tre coduenit a scelta, nascondendo la action originale.
Utilizzando invece un'interface, otteniamo lo stesso risultato, ma in modo più flessibile.
Vediamo come.
Definizione di un'interface
Un'interface non è altro che una struttura all'interno della quale dichiariamo delle procedure vuote.
Nel caso specifico, la procedura si chiama InvoiceCourse e vuole come parametro in entrata l'edizione da fatturare. Le procedure definite nell'interface richiedono poi la loro implementazione attraverso codeunit che le definiscano attraverso l'istruzione implements.
Nel nostro caso, ho scritto la procedura di fatturazione in due codeunit diverse.
Come si nota, queste implementano la procedura InvoiceCourse definita nell'interfaccia attraverso l'istruzione implements, in due modi diversi (in questo caso con un banale messaggio all'utente).
Quale delle due?
Per fare funzionare il meccanismo di scelta di una o dell'altra dobbiamo definire un'enum che contenga le due alternative
Questa enum possiamo inserirla all'interno della procedura, oppure ad esempio in una tabella di setup, in cui l'utente definisce che tipo di procedura intende usare per fatturare i propri corsi. Nel nostro caso abbiamo deciso di far scegliere la procedura al momento del suo lancio. La figura sotto mostra la soluzione.
L'action della pagina richiama una procedure che vuole come parametro l'interface di riferimento, chiede all'utente quale procedura di fatturazione adottare impostando con la sua scelta una variabile globale che punta all'enum definito sopra, che viene a sua volta assegnato all'interface prima di richiamarne la funzione.
Conclusioni
Certamente a vederlo così sembra un modo complesso di risolvere un problema semplice, ma al di là dell'esempio specifico, che può essere poco indicativo, si deve pensare alle interface come a un modo per rendere Business Central completamente personalizzabile nelle singole procedure, come ad esempio quella del calcolo del listino di un prodotto, in cui ognuno può implementarlo secondo la sua logica senza dover intervenire troppo nel codice esistente.