For most developers, modifying standard code (or that supplied from a third party) is the most common task. It isn't sufficient to make a piece of code functionally correct. We have to ensure that the code is maintainable and has a minimal effect on future upgrades. This chapter covers this in the following topics:
- Key goals when customizing standard or third-party code
- How to determine where to make the change
- Adding fields to standard tables
- Integrating a custom module with standard AX
- Changing the behavior of a class
- Extending a framework: vendor electronic payments
- Using event handlers to reduce footprint on standard AX
- Using an extension table for additional fields
Any change we make that alters any element that is in a lower layer is effectively a modification. The terms customization and modification are used to imply the level of change, and somehow a customization has a lower impact. Customizations are often used to describe changes to the user interface, such as moving buttons into a more logical order for the organization.
This is a huge misconception; changes to forms are often the most time-consuming to upgrade, especially when changes are made to the form's code. One key aim we should adhere to when modifying code supplied by our VAR, ISV, or Microsoft is to ensure that further updates are easy to apply. We do this by the following:
- Minimizing the footprint. We use event handlers where possible, and avoid small changes in many places.
- Make modifications at the lowest level possible (see the hierarchy in the next section). In other words, we avoid code changes on forms, and try to make the changes at the table or class level.
- Make changes sympathetic to the code's intent, and avoid repurposing existing fields simply to avoid adding a new specific field.
- Do not hardcode current state business rules. Statements such as "We always / never…" are often followed by "Well, except when we order from that supplier, obviously." after implementation. In these cases, we would use a parameter to control the logic, which provides the benefit of allowing different legal entities to have different rules.
The last point is relevant to any development, but in the case of standard logic, the impact is often greater, as these are often more widely used across an organization. An example of a hard-coded business rule is as follows: place all export sales orders on hold for hold type AUTH.
Our role is to provide the ability for these rules to be implemented. Writing the rules in code often leads to them be changed frequently, as the business evolves, and therefore increases the cost of ownership and risk of regression elsewhere.
The request is a reasonable requirement, but the solution should use a table to store the conditions for placing the order on hold. Even making the hold type a parameter (for example, in the SalesParameters table) will most likely not be enough. Various exceptions will arise, resulting in a large, hard-to-read if statement.