Let’s go through the process of adding complexity to the software.
Will show you how to create a library for a source. This source can be something other than a CSV just using for simplicity. This could be a secondary API we are trying to integrate with. Will show you how to split that code so it makes more sense both from layout and usability perspective. Each bit of code will be housed in its section and that code will be reusable if we want to go from using Acumatica and ZOHO or swap out with another source. It makes it easy because all code that stays in the Acumatica library can stay there and all the code with the source model can stay in its section.
Now let’s build our source model. This will be an object which contains all the columns featured from our CSV file. Account number, description, acct class,type, active or not flag, and post option. From there we can add the code that actually reads the file and take it out of our Acumatica client code and move it to somewhere it makes more sense from organizational and usability stand point. Once we have the source model we can go into the main UI and add reference back to the source library which lets the different projects talk to each other. Now add the method that actually reads the file and stores into a list we can use later in our UI code to talk to the Acumatica library and in that code, we can view our conversion.
We can now flip over and look at the UI controller which is the class for the simple UI that is the main driver or controller of our models. Here we will add a reference to our source model class and method we were calling and created to read the file. We are no longer doing this in the client load list, we are separating out the code to be more modular and reusable for us. Now we will add a simple use statement, so we are reference back to the source library just like the reference. This was one of our prerequisites being able to use the modular technology functionality. In our UI we will add a conversion method to convert from source model to destination model which is Acumatica. We could be going the other way around and we can still do that in this modular code with Acumatica being the source and another system being the destination.
Lastly, we override the load list method creating a second type of method that allows us to input a list account and will perform the same function before. We need to add some code to call our converted method to put in our list of accounts. We will call it load list and set equal to the output of our conversion method. Little bit of cleanup to use the overridden method.
To recap: we have 3 modules. Our source library, simple UI,and Acumatica library and each is playing its part in module fashion. Acumatica client is focused on putting data into Acumatica, logging in, logging off, logging error messages. The UI controller is playing in between of the source model and Acumatica library.
View the Other Videos in This Series
