Today I continue the review of the updated developer training material provided by Acumatica to provide personal insight and key take-aways for the T200 Maintenance Forms training material.
This training shows two ways to create forms. The maintenance form for the services provided are shown via the customization project editor and evolves into Visual Studio code as an Extension Library. The second part of the course shows how to define the graph and screen directly in Visual Studio and then import into the customization project.
While a maintenance form fundamentally is just another user entry form to put data into Acumatica, it is identified as an entry form for master data. That is, key data that is entered/updated on occasion for the purpose of use in a common data entry form. Maintenance forms tend to have limited access provided to restrict who is able to maintain these master data lists. By contrast, a Data Entry Form would be where many users may complete transactional data entry which would use the master data contained in the form. For instance, a Vendor would be defined in a maintenance form and used on a purchase order as a data entry form.
As outlined in the training, Acumatica contains 3 layers to provide interaction between the real world and the database. These layers are Data Access Layer (DAC) to access the database, Business Logic Layer to create a view of data contained in one or more DAC’s as well as actions and event handlers to contain the business logic, and the presentation layer used to interact with the outside world (i.e. people using a web browser and other applications using web services.)
In introducing Data Access Classes, the training material gives an interesting performance tip. When Acumatica accesses the data in the database, the session data is stored in server memory for a stand alone instance. This means that the server will consume more and more memory as a process accesses and works with data. While this should be ok for smaller instances, it is possible to setup a cluster of application servers where the session data is serialized and stored remotely which brings scalability to the platform.
With regards to DAC’s – While each field of the DAC contains attributes to modify behavior of the field for Acumatica, a database field defined in a DAC is comprised of two parts. We define a public virtual property to hold the field data from the table (the variable, or property field.) This is basically a variable matching the data type in the database for the respective field to hold the value. We also define a public abstract class to be used as a type to enable BQL commands to access the database. The abstract class must be derived from IBqlField directly for use of BQL statements or indirectly for use of FBQL statements.
A graph (the business logic layer) contains all the business logic. This will include
- Views to be used by the presentation layer.
- Event handlers, such as validation, automation (i.e. turn off that setting when this setting is turned on). Fields that need immediate event handling will need to be set as CommitChanges = true in the screen layout (presentation layer).
- Actions (buttons for user interaction, such as save, cancel, print, etc,)
- Various other elements not covered in this basic training (such as graph specific DAC’s for filters, PXProjections which present a combination of tables to Acumatica as a virtualized table, etc.)
The presentation layer is a screen definition pushed to the web server which bring the views in the graph (business logic layer) to the surface. The physical layout of the screen is defined in the Screens tab of the customization project as well as any Substitute Lists (Generic Inquiry with special settings.)
Page 31 Analysis of the Generated Code of the Graph – The Save and Cancel actions are created using MasterTable if you followed the guide. The example provided shows a change in the Save and Cancel actions. DO NOT change your code to match the example provided to reflect RSSVRepairService. This will be done on page 39 in the training under lesson 1.4.
On Page 44, a very important note is presented as a passing comment, but it is critical to understand for a new developer. “How do I make a field required?” and subsequently, “Why doesn’t my required field have the asterisk noting that it is required?” PXDefault makes a field required. To enforce use of an asterisk to tell the user that the field is required, add Required = true to the PXUIField definition for that field.
Learned something new: In Step 1.5.1 on page 49, we add columns to the grid by checking the fields and using “Create Controls” as I learned almost 2 years ago. What I found particularly interesting is the ability to do this automatically by updating the Layout Property for the grid for AutoGeneratedColumns = Append to add any new columns to the end of the grid automatically.
On page 91, a note reminds us that values to be presented as a combo box should be given a fixed length of 1 for the code and defined with [PXDBString(1, IsFixed = true)]. I have found reason to make this a 2 character wide list in rare cases, so simply adjust the database table size of your database field to accommodate and note the proper size in the PXDBString attribute.