Inside Dynamics AX 4.0: Licensing and Configuration

[Blog bot]

Источник: http://feeds.feedburner.com/~r/Insid...iguration.html
==============

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 configuration of 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 below image, which is accessed from Administration\Setup\System\License Information.

The 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, serial number, 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 do not 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 themselves are created in the AOT and divided into five tab pages, as shown in above image, based on the type of functionality that they relate to. The grouping is determined by a license code property, and sorting inside the groups is handled by the SysLicenseCodeSort table and its createSortIdx method. 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. You may contact your local Microsoft subsidiary for more details about the program.

The Configuration Hierarchy

The license codes reside at the top of the configuration hierarchy. This 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 are used to 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. This means that 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 is not only the enabler for a variety of configuration keys, but it 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 reduces the number of security keys to be configured when creating user groups. (User groups, which are essential to the security subsystem, are described later in this chapter.) below image shows the system-wide configuration hierarchy followed by most functionalities within an implementation, with the exception of those that do not comply with best practices for developing Dynamics AX application modules.

The configuration hierarchy

The configuration hierarchy might seem complex. However, easy-to-use administrator checklists and forms, such as the License formation, 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. This means that everything from forms, reports, and menus to data elements and the Data Dictionary, as well as the entire development environment, is already present, existing in a temporary state where the elements do not affect the enabled functionality.

Using the configuration hierarchy shown in above image, 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 cannot 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 will be 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 when needed, rather than remove superfluous functionality like other ERP systems do. The consequence of this philosophy is that the system starts minimized by default. This means that all child configuration keys are disabled. An example of the Configuration form and the minimized approach is shown in below image.

The 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 does not 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 below image, an administrator can determine whether a configuration key is enabled and what it would take to eventually enable it, which depends on the parent of the configuration key.

Configuration key flowchart

Using Configuration Keys

An important part of the application development process is mapping extensions to the configuration-based and role-based security frameworks that integrate the extensions into the complete solution. Correctly using the configuration keys throughout the system can make enterprise-wide deployment very powerful, flexible, and economical when divisions, regions, or sites all use the same deployment platform and customize local deployment by using configuration keys, rather than developing specific customizations in each installation. Individualized development, though, cannot be entirely avoided because of the nature of businesses and their development needs.

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

Configuration Key References

Enabling the configuration keys also means invoking hierarchical structures of role-based security options, providing system administrators with an extremely flexible and dynamic framework for setting up user security. The role-based security hierarchy supports use without configuration keys when it is necessary for specific kinds of implementations. In below image illustrates a frequently used security hierarchy in which the configuration key is the gatekeeper for interaction with the functionality underneath.

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 role-based security hierarchy provides a high-level overview of the concept. The particular hierarchy shown in below image demonstrates how the LedgerBasic configuration key opens for a subset of the Vendor functionality that is managed by a sub-hierarchy of security keys. The sub-hierarchy 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 security configuration.

A security hierarchy example

This illustration does not depict all possible elements and combinations within the security hierarchy, which would include such things as reports, classes, Web elements, or how country-specific functionality is invoked for an individual user.http://insidedynamicsax.blogspot.com/
</img> </img> </img> </img> </img>


Источник: http://feeds.feedburner.com/~r/Insid...iguration.html