Dynamics AX provides one of the best development environments of any ERP product. It is often easy to forget that the purpose of this environment is to create or extend functionality in order to satisfy a business requirement. The purpose of this chapter is to provide a short refresher on some of the core concepts and the preparation work required, before we start cutting code to put us on the right track to develop or extend functionality in Dynamics AX. This will enable your solutions to be maintainable and extendable, and minimize the impact on future updates and upgrades.
This chapter does not cover the installation and configuration of the required environments; it is assumed that this has already been done. We assume that our development environment has the AX client, management tools, and Visual Studio Professional 2013 installed. If you are using a version prior to cumulative update 8 (CU8), you will need to use Visual Studio 2010 Professional.
If we have to use Team Foundation Server (TFS), each developer must have their own development environment. Typically, we will have a virtual server as a single box AX installation.
In this chapter, we will cover the following topics:
- The technical architecture of a solution
- Minimizing the footprint of customizations
- Selecting the appropriate layer for our solution
- Creating the models
- Creating a label file
- Configuring source control
- Creating a project
- Setting up a default project and model
- Designing the technical solution
- Designing test plans
In the first part of this chapter, we will briefly cover some key topics to refresh our memory. We will then cover some areas that we will expand on as we progress through the chapters. If you want to read in more detail about the technical infrastructure, the MorphX IDE, and development practices and patterns, refer to Appendix A, Efficient Design and Development with Microsoft Dynamics AX.
A good design is just as relevant to small change requests as it is for larger development. It has many attributes; some key points to consider are as follows:
- Configurable: As much of the decision making as possible should be stored in configuration and parameter tables. It may take longer, but it will save time when the development goes through integration testing.
- Extendable: The solution (no matter how small) should be designed such that it can be extended without rewriting. Using patterns can help with this.
- Design around standard patterns: This helps avoid reinventing the wheel and ensures a higher quality design that is more consistent. The solution we write should look and feel like any other part of AX. This means less training and better adoption by our users.
- Validate the design: This should be done against the requirement before the work on the design commences. In some cases, it is appropriate to prototype the solution.
- Use the advanced features of AX appropriately: Just because a cool feature exists, it doesn't mean that it should be used in this case.
- Configuration and parameter tables should be rule-based: For example, a property used to determine which mode of delivery is urgent is limiting. It implies that there can only be one urgent delivery mode.
- Minimize changes to standard code: The more standard code we change, the more work is required to maintain the system in terms of updates and upgrades. We will discuss minimizing this footprint in the next section.
Most of the functionality that we write in AX (a new solution or customization of an existing functionality) is data-based. We use forms to create, maintain, and view this data, tables to store and validate this data, and classes to act upon it.
The first part to design is the data structures. Even though these may evolve, a lot of attention is required here. A simple analogy would be to compare this to building a house; you can change the furniture, even add a room, but you cannot add a basement garage.
There is some guidance to be found here, that is, the structure will normally fit into an existing pattern that is already being used by AX. We normally expect to have the following types of tables in our solution:
- Parameter: This is a single record table that typically contains the table's defaults and other behavioral properties, such as the default printer settings.
- Group: An example of this can be the customer group or delivery mode tables. They can act as lookup values, or even control functionality. For example, we may create a table that contains a user's default label printer.
- Main: These are the master data tables, such as items and customers.
- Worksheet header and Worksheet line: These are the standard document entry tables, such as the sales order table and lines, where the dataset has a header and lines.
- Worksheet: This is a table used to enter data that is later processed in some way. This is not very common in AX as most documents have both a header and lines.
- Transaction header and Transaction lines: These are the result of the worksheet after posting or committing, such as the sales invoice header and sales invoice lines.
- Transaction: This is the table where the result of posting is a single-level transaction record. The stock transaction table called
InventTransis an example, which is viewed as a list of stock transactions.
During the course of this book, we will be writing a solution based on a hypothetical case of a fleet management system as Contoso's internal development team. Based on the previous guidance, we can take the following simple requirement and quickly turn it into a data structure: we require the ability to view and maintain records of vehicles and their utilization.
From this, we can see that we will need to store a list of vehicles, probably of varying types, and then a record of their utilization will be attached to each vehicle. This leads us to the following structure:
|
Table type |
Example table name |
Description |
|---|---|---|
|
Parameter |
|
The main parameters |
|
Group |
|
A list of vehicle types |
|
Main |
|
A list of vehicles |
|
Transaction |
|
The utilization records |
In this case, little thought was required as the requirement fits nicely into the standard AX patterns.
The naming was also straightforward: the organization's prefix is Con, the module's prefix is FMS, and the rest of the name comes from the entity name and the table type. You will see this type of naming throughout AX. As far as possible, we should be able to understand from the name alone what it is, what it does, how it does it, and why it does what it does.
The next part of the structure is the user interface, where we again have a set of templates that suit most circumstances:
- List page: This is the main entry point to both the main tables and worksheet tables. The list page offers the ability to search and act upon the data. You can also open a details form from list pages that allows the record to be edited or a new entry to be created. An example can be found by navigating to Forms | CustTableListPage.
- Details form, master: This is designed to allow the maintenance of master data, such as customers and items. These are not entry points, but are opened from a related record or the list page. We sometimes use this form type to create data, but we typically use a specific creation form for this. An example can be found by navigating to Forms | CustTable.
- Details form, transaction: This is intended for the maintenance of worksheet tables, such as the sales order form. An example of this can be found by navigating to Forms | SalesTable. The term "transaction" may be confusing here; it is not related to the
TableGroupproperty of the table. - Simple list: This is useful for group and transaction tables that are a simple list of records with only a small number of fields to present. An example of this can be found by navigating to Forms | CustClassificationGroup.
- Simple list, details: This is where the group table has many fields that are better arranged in groups of fields. There is still a list element, but there is a pane that allows for easier entry of data. An example of this can be found by navigating to Forms | DeliveryMode.
- Table of contents: This template is used for parameter forms. An example of this can be found by navigating to Forms | CustParameters.
- Dialog: These forms follow a style design to be used as a popup to gather some information and return it to the caller. A form used to create data is likely to use this template as we enter data and then ask AX to create the record once complete.
- Drop dialog: These appear as if they drop down from the calling button, and are typically used to perform an action using the current record. They are designed to display a small number of form controls, which the user will update as required before pressing OK. The following screenshot shows this:
Based on the preceding templates, we can create the following forms for our example requirement:
- Table of contents:
ConFMSParameters - Simple list, details:
ConFMSVehicleGroup - List page:
ConFMSVehicleTableListPage - Details form, master:
ConFMSVehicleTable - Simple list:
ConFMSVehicleTrans
We normally name forms after the table they act on, except for list pages. The last example does not really have a true template; the simple list is the closest. The data structures and forms are taken directly from how other parts of AX behave. This should always be a design goal as it ensures that our users' incumbent knowledge of AX is used, reducing the time needed to learn the new feature and minimizing errors.
Classes are used to store the main business logic. They are often used to handle user interface and table events as well. This allows the code to be reused and extended more easily.
The other key point is that we should also consider that we may want our solution to be available on mobile devices, and a careful thought about how we write the logic can make this much easier.
Classes in AX can be deployed as custom services that are consumed as WCF services in mobile or other Windows applications. This means that the logic should be simple to access, and have business logic in distinct classes, allowing the logic to be reused safely.
For example, we have a table with a status field that performs some validation and other events. We would write this in the data contract and service class pattern—a data contract to store the data to be acted upon and a service class to process the change. This can be used in a dialog form with the AX client or exposed as a service, allowing a mobile application to set the status.