In most books that outline the ERP implementation best practices, customization is a bad word. However, in reality, one can't avoid it completely in the project. Hence, the ease of use in the development platform and the variety of tools available play a key role in the selection of an ERP system. One of the key reasons why Microsoft Dynamics AX is selected over the other ERP systems is the availability of the broad variety of technology toolsets for building additional solutions. The best practices need to be followed to ensure that the customizations are kept to a minimum, they avoid altering the core foundation of the product, and enough thought is put into making them 'temporary' and upgrade-friendly. I will explain the concept of temporary later in the chapter.
Dynamics AX provides a layered-development approach, where the partners, ISV Solutions, and the customers each have a layer where they can make the customizations without disrupting each other's work.
In this chapter, we will learn to get ready for the development phase of the project and understand the development environment, version control, and branching strategies. Then we will walk through the process of customization and the best practices. In the end, we will explore the Application Lifecycle Management (ALM) process for code promotion and release strategies, across environments.
Before the development phase of the project starts, the Project manager and the Technical solution architect need to set a few ground rules, such as defining the development environment, version control, the branching strategy and coding standards, the naming convention to be followed, and the code review process. In this section, we will walk through these topics in brief to understand what they mean.
Keeping track of the code is critical to good development practices. The following are the version control systems commonly used with Dynamics AX 2012:
- Team Foundation Server (TFS): This is the most common version control system used with Dynamics AX. It provides source code management, reporting, requirements management, project management, automated builds, testing, and release management capabilities. It covers the entire application life cycle.
- Visual Studio Online: Visual studio online is a cloud-based service. It utilizes the TFS integration with Dynamics AX and provides various ALM capabilities.
- MorphX VCS: This is an inbuilt source code management capability within the Dynamics AX application. It is suitable for small projects as it can only be used within a shared development environment.
The following are the two commonly-used development environment topologies for developing customization with Dynamics AX.
In this model, a single Dynamics AX AOS and the database are shared among the developers. The shared AOS machine can either be configured to use the MorphX VCS, or the TFS version control with a public profile. This topology may be cost-effective as it requires a single development environment but it's NOT recommended for large projects as there are many known issues when using this topology(This model was popular prior to Dynamics AX 2012 when the project sizes were small, and the Dynamics AX architecture supported it with fewer issues):
Following are few limitations why the shared AOS topology is not recommended:
- Stale metadata or unpredictable behavior on clients.
- Problems with installing new solutions or upgrading the existing ones, which may lead to corrupt data.
- Unresponsive AOS while another user is debugging the CIL code (The CIL process is used to compile the X++ code into the Common Intermediate Language (CIL) of the .NET Framework. Dynamics AX allows you to generate a Full CIL or an Incremental CIL).
- The need to frequently restart the AOS instance.
The private AOS topology is the recommended topology for a development environment. As shown in the following diagram, in this topology, each developer has his/her own Dynamics AX client, AOS, business database, and model database and is connected to the TFS. A separate build machine is also connected to the TFS, and is used for creating a build for deployment:
Microsoft's Team Foundation Server (TFS) is the preferred and the more widely-used version control system in the Dynamics AX development projects. One of the main features of TFS is Branching, which can be useful in the following scenarios:
- When a stable version is needed for testing while the development work continues in the other areas.
- When multiple development teams are working on a set of features that are independent, but each team also depends on the features developed by the other teams. You need to isolate the risk of the changes made by each team; and yet, you will finally need to merge all the features together into one product.
- When the implementation is being carried out in multiple phases, one phase that is in production may need continuous support but the team may be working on the next phase.
This is the simplest and most basic branching methodology where one branch is created and all the developers check in the changes to the main branch. The build machine can be used to create a build out of the main branch to be released for testing and later, for the production environment:
The development and main branching strategy introduces one or more development branches from the main, which enables the concurrent development of the next release, multiple projects running in parallel, experimentation, or bug fixes in an isolated development branch:
The next thing, after getting the development environment and the version control strategy finalized, is defining the ground rules for the development team. The following are some basic rules which need to be defined by the solution architect and the project manager for the development team.
Dynamics AX provides a development approach of using layers and models. The team needs to make a decision regarding the layer (CUS and USR are, typically, the layers used by the customers) that will be used for customization. Models were introduced in Microsoft Dynamics AX 2012 to help develop and maintain multiple solutions side by side, in the same layer. By default, each layer has its default model. For example, the default model for the USR layer is USR-Model. Multiple models can be created for independent solutions. For instance, if a project involves customization for different business streams, and they are independent, you can create customizations in separate models for each business stream so that they can be installed and maintained separately.
For more information on the Dynamics AX Layers, you can read the TechNet article at https://msdn.microsoft.com/en-us/library/aa851164.aspx.
Naming conventions provide consistency and make the application easier to understand. The best practice is to use the following naming convention for the custom objects:
{client prefix} + {business area name} + {business area description} + {action performed (for classes) or type of contents (for tables)}
It is a good practice to add a client prefix at the beginning of the object name to get a unique name for each object and to avoid name collision with any other ISV solution or future upgrade.
For example, a new class created by the vendor ABC for the sales order import process should be named as AbcSalesOrderImport.
The labels in Dynamics AX are localizable text resources, and they are used throughout the product as messages to users, form captions, form controls, help text, and so on. When developing custom features in Dynamics AX, the developers should create new label files; they should also create labels and define the translation for each language to be used. The label file names which will be used during the development process should also be defined. Typically, the client prefix used for the AOT object name or the model name are used as the label file name. If your project involves development in multiple models, you should create label files for each model.
Effective code review during the development phase helps identify issues earlier, and avoids rework and bug fixes during the later phases of the project. It is important for the project team to define the code review process and the guidelines for the project at the beginning of the development phase. The code review should not be limited to checking the naming conventions, indentation, and other best practices errors or warnings, which can be easily caught by the Dynamics AX best practices tools. The process should primarily be focused on achieving the following quality objectives:
- Solution approach: The code should be implemented in the correct way. If the existing business logic or processes are modified, they should be modified at the appropriate level. The code should be aligned as per the technical design documents.
- Performance: Code performance with a high volume of data and the production load.
- Extendibility: The solution should be extendible and appropriate.
- Easy to read and follow: The code should be easy to read and follow.
- Error handling: The code should be able to handle errors appropriately. It's easier to catch such issues during the code review process as compared to the testing phase.
- Education for team: The code review process helps in educating the development team members with review feedback from more senior resources. It needs to be used as a training exercise. Set up a culture where the code reviews and feedback sharing become a learning experience rather than a blame game.
One of the common issues that I have seen in the field is that the code reviews are ignored during the development phase, and are considered towards the end of the development cycle, or close to going live. Most of the time, the code review feedback at such later stages is just not feasible. It is difficult to make changes to the code that is already tested and stable. The best way is to embed the code reviews as part of the development cycle, and the learnings from the previous reviews can be used by the developers in further coding.