Microsoft Dynamic AX 2009 : Configuration and Security - Licensing and Configuration

Dynamics AX allows licensing of application modules, multiple user types, languages, server technology, the Web framework, database logging, record level security, development tools, run-time execution, and integration frameworks. The system elements and application modules are locked by license codes that must be unlocked by license keys.

Unlocking a license code is the initial step in configuring the Dynamics AX system because the license codes reference the configuration key that links to the physical functionality. You unlock the license code by using the License Information form, shown in Figure 1, which you access from Administration\Setup\System\License Information.

Figure 1. License Information form

You enter the license codes manually or import them by clicking the Load License File button. All the license codes and license files available for import are supplied by Microsoft through the Microsoft Partner Program.

The license codes are validated individually based on the license holder name, the serial number, the expiration date, and the license key being entered or imported. The validation process either accepts the license key and updates the status field with counts, names, or OK or returns a negative result in the Infolog form.

Note

Standard customer licenses don’t contain an expiration date. Licenses for other uses, such as evaluation, independent software vendor projects, education, and training, do include an expiration date. When a license reaches its expiration date, the system changes execution mode and becomes a restricted demo product for a limited amount of time.

The license code elements are created in the AOT and divided into five tab pages—System, Modules, Partner Modules, Web, and Languages—based on type of functionality, as shown in Figure 1. The grouping is determined by a license code property, and the SysLicenseCodeSort table and its createSortIdx method handle sorting inside the groups. The Partner Modules tab allows you to include licensed partner modules. Partners can sign an agreement with Microsoft that gives other partners and customers the opportunity to purchase and request partner-developed functionality. Contact your local Microsoft subsidiary for more information about this program.

The licensing framework can also track dependencies among various licenses. A license can have up to five different prerequisites. Adding a prerequisite for a license ensures that the Application Object Server (AOS) tracks the license dependencies. So if your application depends on multiple licenses, you don’t need to check whether a particular license exists in your code.

Configuration Hierarchy

The license codes reside at the top of the configuration hierarchy, which is the entry point for working with the configuration system that surrounds all the application modules and system elements available within Dynamics AX. The configuration system is based on approximately 200 multiple configuration keys that enable and disable functionality in the application for the entire deployment. Each license key controls access to a specific set of functions; when a key is disabled, its functionality is automatically removed from the database and the user interface. The application runtime renders presentation controls only for menu items that are associated with the active configuration key or where no configuration key is available.

The relationship between license codes and configuration keys is very comprehensive. An individual license key not only enables a variety of configuration keys but also removes the visibility of configuration keys and their functions throughout the entire system if the license key is not valid. Removing configuration keys with invalid license keys reduces the configuration complexity. For example, if a license key is not entered or not valid in the license information form (accessed from Administration/Setup/System), the Configuration form hides it and displays only the valid license keys and the configuration and security keys that depend on them. This functionality reduces the number of security keys you need to configure when you create user groups.Figure 2 shows the system-wide configuration hierarchy followed by most functionalities within an implementation—except those that don’t comply with best practices for developing Dynamics AX application modules.

Figure 2. Configuration hierarchy

The configuration hierarchy might seem complex. However, easy-to-use administrator checklists and forms, such as the License Information, Configuration, and Permission forms, reduce the initial complexity.

Configuration Keys

The application modules and the underlying business logic that license codes and configuration keys enable are available when Dynamics AX is deployed. Everything from forms, reports, and menus to data elements and the Data Dictionary, as well as the entire development environment, is already present in the product, existing in a temporary state in which the elements don’t affect the enabled functionality.

Using the configuration hierarchy shown in Figure 3, you can enable parent configuration keys with valid license keys to appear in the global configuration form by navigating to Administration\Setup\System\Configuration. The parent configuration keys controlled by the license codes appear with a red padlock overlay and can’t be disabled; any configuration key children displayed below the parent can be changed. Parent configuration keys with no children are not available from the configuration form.

Note

Parent configuration keys can exist without an attached license key. These are available for the administrator to enable or disable at all times from within the Configuration form.

The Dynamics AX configuration philosophy is to enable functionality as needed. The consequence of this philosophy is that the system starts minimized by default, with all child configuration keys disabled. An example of the Configuration form and the minimized approach is shown in Figure 4.

Figure 4. Configuration form

As a more detailed example, consider a company buying the Trade module license code. The company wants most of the functionality in the module, but it doesn’t do business with other countries. The company therefore chooses to disable the Foreign Trade configuration key.

By using the configuration key flow chart shown in Figure 5, an administrator can determine whether a configuration key is enabled, and if not, what it would take to enable it, which depends the configuration key’s parent.

Figure 5. Configuration key flow chart

Using Configuration Keys

An important part of the application development process is mapping extensions to the configuration-based security frameworks that integrate the extensions into the complete solution. Correctly using the configuration keys throughout the system can make enterprise-wide deployment flexible and economical, with divisions, regions, or sites all using the same deployment platform and customizing local deployment by using configuration keys rather than by developing specific customizations in each installation. You can’t entirely avoid individualized development, however, because of the nature of businesses and their development needs.

Configuration keys affect the Data Dictionary, the presentation, and the navigation infrastructure directly, meaning that you can reference a configuration key property on all relevant elements. Table 1 lists the elements that can be directly affected by configuration keys.

Table 1. Configuration Key References

Grouping	Element Types
Data Dictionary	Tables, including fields and indexes Maps Views Extended data types Base enumerations License codes Configuration keys Security keys Perspectives
Windows presentation and navigation	Menus Display: Menu items Output: Menu items Action: Menu items
Web presentation and navigation	URL: Web menu items Action: Web menu items Display: Web content Output: Web content Web menus Weblets
Documentation references	System documentation Application developer documentation Application documentation HTML Help files

When a configuration key is enabled, the functionality associated with that configuration key is enabled. This means that appropriate menu items, submenu items, tables, buttons, and fields are enabled when the configuration key is turned on. A user has access only to those areas that the administrator has granted access to and that have been enabled by the configuration key.

Figure 6 illustrates a frequently used security hierarchy in which the configuration key is the gatekeeper for interaction with the functionality underneath.

Figure 6. Security keys as permission gates

The hierarchy is based on security keys that, working together with user groups, act as permission gates that allow users to see, invoke, and work with the user interface, business logic, and rules represented by menu items, submenu items, tables, buttons, and fields.

This introduction to the security hierarchy provides a high-level overview of the concept. The particular hierarchy shown in Figure 7 demonstrates how the LedgerBasic configuration key opens for a subset of the vendor functionality that is managed by a subhierarchy of security keys. The subhierarchy is the link to functionality such as the Purchase Order form and the Vendor form that are referenced via display menu items. These display menu items explicitly reference specific tables to decrease the complexity of configuring security.

Figure 7. Security hierarchy example

This illustration doesn’t depict all possible elements and combinations within the security hierarchy, which would include such things as reports, classes, Web elements, or an explanation of how to invoke country-specific functionality for an individual user.