Interface: a practical example
The interface is a structure introduced in the AL language that can help us in certain situations. But if we read the official documentation their functioning may be unclear.
In this post I want to show you a practical example of their use.
I created a small app, which I normally develop in my Advanced AL Course and which manages the delivery of courses. The app provides an invoicing procedure which is launched from an action on a page.
Now, suppose we want to implement two alternative invoicing procedures: one, which we will call Simple, and the other, which we will call Complex. The difference between the two invoicing logics does not interest us at the moment, they could be of any kind, such as the way in which the lines of each invoice are filled in, eg. grouped or not.
Finally, suppose we want to give the user the opportunity to choose one or the other method when launching invoicing through a choice menu
Classically the solution to this problem consists in creating two alternative codeunits and launching one or the other depending on the choice. By operating in this way, however, if those who purchase our app want to create their own procedure making the user choose it as an alternative to the standard ones, they should find and subscribe one of the available events, or create an additional action on the page that launches one of the three coduenits, hiding the original one.
By using an interface instead, we achieve the same result, but in a more flexible way.
Let's see how.
An interface it's just a structure in which we declare empty procedures.
In this specific case, the procedure is called InvoiceCourse and takes the edition to be invoiced as an incoming parameter. The procedures defined in the interface then require their implementation through codeunits that define them through the implements statement.
In our case, I wrote the invoicing procedure in two different codeunits.
As you can see, these implement the InvoiceCourse procedure defined in the interface through the implements statement, in two different ways (in this case with a simple message to the user).
To manage the choice between the two procedures we must define an enum that contains the two alternatives
We can insert this enum within the procedure, or for example in a setup table, in which the user defines what type of procedure he wants to use to invoice his courses. In our case we decided to let the user decide the procedure at the time of its launch. The figure below shows the solution.
The action of the page calls a procedure that takes the reference interface as parameter, asks the user which invoicing procedure to run by setting with his choice a global variable that points to the enum defined above which is then assigned to the interface before calling its function.
Certainly this solution seems like a complex way of solving a simple problem, but beyond the specific example which may not be very indicative, we must think of interfaces as a way to make Business Central completely customizable in individual procedures, such as that of calculating the price of an item, in which everyone can implement it according to their own logic without having to modify too much the existing code.