License codes and Security settings in Microsoft Dynamics Ax

License codes:

·         When purchasing Dynamics Ax you will have to decide on system settings, like, number of users, number of servers, access to MorphX and X++, which application modules you are going to use.

·         For each system setting and module you will receive a license code. All license codes will be compiled in a code letter. These license codes are used for controlling which part of Axapta you will have access to. Only modules with a valid license code will be available in the main menu for end user to use.

·         We can also create our own License codes, However, to use your own license codes you will have to contact Microsoft as they will have to generate license codes on your behalf. Creating new license codes is used by companies creating modules for the GLS layer or by partners who want to sell their own modules.
Configuration keys have a property called LicenseCode, which is used for attaching a license code to your modifications.

 

Configuration keys:

We can have two levels of security settings in Dynamics Ax. Configuration keys are the highest level, and security keys are the second level.

·         Configuration keys are defined in a tree hierarchy where the top configuration key is related to a license code. The form SysConfiguration shows the hierarchy of configuration keys.

·         By default, Some configuration keys are disabled, generally for advanced features and country specific features.

·         When changing the settings of configuration keys, the database must be synchronized. This is because the configuration keys determine whether a table should be synchronized to the database or not.

·         Normal practice would be to attach a configuration key to each table, map, view and menu item for the modifications. This will ensure that an object where the configuration key is disabled will not show up in the menu.

·         Most of the objects in the AOT have a property for defining a configuration key. In the table SalesTable there is a field called ProjId. The extended data type for ProjId has a configuration key.
Another example is base enum FormTextType. Each of the entries added to this base enum from the GLS layer have configuration keys.

·         From X++ you can make a check for whether a configuration key is enabled. The global method isConfigurationKeyEnabled() is used to validated configuration keys.

Example (1): The following is an example for how to verify if configuration key is enabled for a particular field.

static void DataDic_ConfigurationKey(Args _args)

{

SalesTable salesTable;

ProjTable projTable;

;

select firstonly salesTable;

info(salesTable.salesId);

info(salesTable.custAccount);

if (isConfigurationKeyEnabled(configurationkeynum(ProjBasic)))

{

info(ProjTable::find(salesTable.projId).name);

}

}

Here, the name of the project related to a sales order will only be printed if the top level configuration key for the project module is enabled. If the check was left out, a blank value would have been printed, which will not make much sense to the end user.

 

Security Keys:
Where configuration keys are setting access for all users, security keys will set access for a group of users or per user.

·         The standard package uses 9 security keys for each module. One top level security key related to a configuration key, one security key for tables and the last 7 security keys are used for the groupings of the module objects as seen from the main menu. You can view the security hierarchy from the form SysUserGroupSecurity.

·         Security keys must be added to all tables, maps views and menu items. If one of these objects does not have a security key you will not be able to set access rights for the object, and the object will be accessible for all users.

·         Security keys are not only defined as enabled or disabled, instead an access level is defined. The choices of access level are no access, view, edit, add or delete.

·         At tables, maps and views you use the property MaxAccessMode to define the access level a user can retain. Tables will, by default, have MaxAccessMode set to Delete, which will allow the users to retain full access to a table.

·         Menu Items has a similar property called NeededAcccesLevel which acts just the opposite of table as you must specify the required access level to execute the menu item. The default value for NeededAccessLevel is View.

·         The best practice is adding security keys should be done as one of your last tasks when creating your modifications. At least, you should have the security keys added before doing your final test.