Acumatica is developed on C# code in Microsoft’s .NET Framework. If you are just getting started and have no idea how to program in C#, you should stop here for a couple of weeks and learn the basics of C#. Fortunately, Microsoft has some training courses available. Try these 2 to get started, but you can find tons of other resources online if these don’t help your particular learning style.
- https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/
- https://channel9.msdn.com/Series/CSharp-Fundamentals-for-Absolute-Beginners
As an Acumatica developer, you will spend most of your time writing classes and methods, the building blocks of C#. The data component which is the core of an ERP system is referred to as a DAC while the business logic is referred to as a Graph… both of which are C# classes when you boil it down to basics. DAC is short for Data Access Class, which is today’s topic.
I’m sure I’ll cover more parts of the DAC in later posts as you’d hate me if I made you read it all in a single post. You’d be here forever the way I drag it out! But let’s keep it simple for today. Let’s look at the very basic building blocks of a DAC in Acumatica.
In the example above, the DAC called MyExampleDAC contains a single field called MyID. To add more fields, you just add more sections like the one shown from rows 11-16. Of course, the contents of those rows will be quite different based on the data type and more advanced features we won’t discuss today. For now, let’s look at the basic breakdown of the DAC.
Lines 1 and 2 import other classes for easy reference in our code. Line 4 defines the namespace for our class as MYDAC.Example. Remember, the DAC is a data access CLASS, so in some regards, this is just another class as far as C# is concerned. Lines 5 & 18 as well as 10 & 17 define a block of code. In the case of the braces at line 5, the entire DAC is contained within the braces saying that all the code contained is in the same namespace. The braces at line 10 indicate that all the code contained is in the same class. As you can see inside line 15, we will define another class inside the MyExampleDAC, and the braces scope (or determine the life and existence of) the inner class.
Lines 6, 7, 8, 12, and 13 are all Attributes. For now, let’s just leave it that attributes are more code defined later that can be used to describe something and modify the behavior of the thing it describes. At this stage, it’s better to just accept that you need certain Attributes in certain places.
Line 6 explains that the default business logic for the data described by this DAC is found in the graph MyDACMaint. To keep it simple, just know that if you try to access this DAC inside of Acumatica, this will tell the system that the natural place to view and maintain it is the MyDACMaint graph. The graph is specified when you build a screen in Acumatica, but again… just go with it for now if you don’t understand.
Line 7 gives a “pretty name” to the DAC. There are places in Acumatica where the system will tell you what the DAC is, and sometimes it is nicer to communicate that as “My Example DAC” rather than “MyExampleDAC”. Notice the spaces?
Line 8 is required by any and all Acumatica DAC’s. Let me say that again. It is a REQUIRED attribute for all Acumatica DAC’s. The help on the attribute says “Indicates that a class can be serialized, This class cannot be inherited.” That’s not exactly true the way I read it. Trust me, you can inherit MyDAC into another DAC if you need to make another “copy” of the DAC with additional fields for easy access. (More on that whenever I get a post on adding custom fields to standard Acumatica tables.)
Line 9 names this DAC as MyExampleDAC. More importantly, the : iBqlTable at the end tells the class to inherit from iBqlTable, which is a class provided by Acumatica for making your DAC usable with all the advanced features that Acumatica builds in for you. Simply put, you MUST inherit iBqlTable for Acumatica to know how to query your database table represented by your DAC.
Lines 11 and 16 denote a “region” of code which is like a simple comment wrapper for your code. In Visual Studio, you can condense all the code between those lines and see it as only the text of line 11. This is convenient when you want to be able to scan over your code and skip past large blocks of code that are irrelevant for what you want to find. It’s a great way to compartmentalize your code.
Line 12 is an attribute that Acumatica provides to describe the field as an integer and that the field is part of a database table. PXInt tells Acumatica that it is a placeholder for an integer value in the DAC but that there is no database field to access for it. PXDBInt (notice the DB part) tells Acumatica to read and write this data when accessing the database table. There are “PX” attributes for all your common data types – PX[DB]String, PX[DB]Decimal, PX[DB]Bool, etc. Just remember that the DB part is included if you need to access the database with it and excluded if you are populating it and using it from your code.
Line 13 is an attribute used to set parameters of the User Interface for that field. In this example we are simply setting the displayed field label to “My ID”. This attribute contains more parameters that determine visibility, etc.
Lines 12 and 13 are attributes that affect the integer defined on line 14. You will see {get; set;} at the end of line 14. That is a shortcut way of telling C# that you will simply get and set the values for that variable. You can write more complex code to define what is stored or retrieved from the field, but most of the time you simply use this shortcut.
Line 15 defines an abstract class that will be used by Acumatica in certain situations to know how to locate the integer in line 14. Notice that it inherits PX.Data.BQL.BqlInt.Field<myID> and that the type of Field<> is exactly the same as the name of the abstract class that is inheriting it. Also note in this case that we are inheriting BqlInt in the middle of that long string. I won’t go into what BQL is right now, but suffice it to say that you are telling a certain part of Acumatica that this is an Integer field. This inheritance enables use of the field in BQL and FBQL statements that I’ll post about at another time. For now, just note that those are terms referring to Acumatica’s way of ultimately building SQL statements to access the database.
In just 18 short lines, you too can define a DAC with a single field! Doesn’t seem like something to celebrate? Don’t worry. Acumatica provides a tool to prebuild most of the DAC for you once you have the table defined in the database. And like most other “rabbit holes” so far in my posts, that’s a post for another day.