Wednesday, April 20, 2016

AX Development for Modularization

 If you feel it is a challenge in finding related elements from the monstrous AOT, you are on the same page with me. AX is a composite application framework that contains a mixture of feature implementations, but we developers need to quickly identify the related elements when assigned with a task either to develop a new feature or to fix an issue. This drives me to examining modularization approaches in AX. I realized at least three ways available: projects, naming convention, and models. Note, the word modularization here means different from AX Modules, this is further explained in the last section of this article.

Projects
Project is used to organize developments - a project is a container of elements that are to be modified or created new, to keep the development in one place. Since an element can be contained in multiple projects that may be worked by different people in parallel, conflicts may occur but can be resolved through team collaboration.

Beyond the normal use, we actually can also use project as a strategy to organize features. We can maintain two types of projects: development projects and feature projects, differentiated with naming convention. A catalog of feature projects representing solutions for different business problems/areas enable us to quickly derive solutions for new development tasks.

Comparing to using models, projects are more handy and agile.

Models
According to official documentation, models are created for partitioning elements of solutions. An element can only exist in one model,  and a single layer can have one or more models.

An “element” that can exist in a model is granular than general thinking of objects. E.g, a table method, a table field, or a class method all are the elements, not just a table or a class as a whole. Actually anything that has a model property that you can see from the AOT is an “element” (Fig.1). This approach actually give a fair degree of flexibility on parallel development.

Figure 1. A element has Mode property
It is helpful to realize that the legacyId property indicates whether an element is newly created in the layer (Fig. 2), newly created elements have legacyId = 0. For changed/overlaying elements, we can review the changes by comparing between implementation layers (Fig.3).
Figure 2. A element has LegacyId property

Figure 3. Comparing an 
element from two layers
While using models we can retrieve the elements of a model through AXUtil and AX Management Shell commands both for a summary and for a detailed list (Fig. 4), we also can do so through the model management GUI. 

Figure 4. Use command utils to view and manage models

Naming Convention        
Projects don’t enforce cohesiveness, while models do but generally in a larger granularity. For example, both don’t support in finding the tables and classes for General Leger management. Here what really help is naming convention.

As shown in following screenshot of the AOT (Fig. 5), naming convention clearly demonstrates its criticality for grouping elements and partitioning solutions. Further down the road,  new development requires to maintain and create naming schemes, especially in a team environment.

Figure 5. Naming convention in AOT

A Side Note for AX Modules
AX module is a concept representing functional area partition in terms of entry points - the Menus. It has nothing to do with the concept of layers, models or projects etc. In fact, different AX modules can have components from the same layer and the same model (Figure 6 shows layers and models installed that contains components for all AX modules).  AX modules are not for partitioning solutions and development.

Figure 6. Installed models by model management tools 


Finally, notice the two aspects of partitioning: the development/project and the solution. As pointed out earlier, projects provide divisions only for developments, as compared to the sense of models that partition solutions that are corresponding to business features or functional areas. So model is the main tool to achieve a clean-cut, modular solution structure in AX. To this regard, I would say that we have under leveraged the model as a partition strategy.

No comments: