Designing application forms can be a very time-consuming task if you always design from scratch, especially if your application must run in a multiple-language deployment. To avoid this time and effort, you should follow the best practice of creating forms and reports by dragging as often as possible and setting very few properties manually. If the system’s default property values don’t suit your needs, you can customize almost any property to fit your application.

When you design the layout of a form for which a table or view is used as the underlying data source, you find that the same field groups and field structures in the original Tables and Views nodes are in the Application Object Tree (AOT). This allows you to drag these field groups and field structures from the form’s Data Sources node directly to the form’s Design node. You should configure the Data Sources to use the Dynamics AX AutoJoin system to ensure that data is synchronized when two forms are linked. When you work with the layout and property settings, you must keep the Auto or Default settings. These settings optimize the use of the auto-arrange technology and limit the need to move pixels to unify and align the form presentation with the rest of the application.

When designing forms, you should adhere to the recommendations in the following list whenever possible to optimize the use of the auto-arrange technology. Most patterns are property settings on the form design.

If your customers require a unique user experience, you could completely remodel the user interface—no design restrictions prevent you from taking that step. One disadvantage of such an overhaul is that training, flexibility, and upgrading become more complex.

IntelliMorph is even more important for reports than for forms. The best practices for reports primarily involve retaining the default settings for properties. When you design a report, however, you often don’t know much about the environment in which the report will execute. The following examples illustrate the types of information you won’t have at design time:

Reports can be broadly classified into internal or external reports. Internal reports are circulated and viewed only inside the organization. In such reports, the report presentation and format aren’t critical. Some examples of internal reports are Ledger Transaction List, Project Profitability Statement, bank transactions, and so on. External reports are circulated external to the organization, so their format and layout are important. Such reports include Purchase Orders, Sales Invoices, Vendor Check Payments, and so on. Such reports are usually printed on preprinted stationery and require precision design. Both internal and external reports can be created using the Auto design or Generated design reporting features of Dynamics AX. You can use Auto design for all internal reports and Generated design for external reports that can’t be implemented with Auto designs because they require precise design and layout capabilities such as the following:

You should follow these design patterns whenever possible:

Configuring the security of a Dynamics AX application involves the use of domains. A domain is a collection of one or more company accounts that allow you to define user groups with the same permissions in a company with several subsidiary businesses, while allowing the same user groups to have other permissions within other companies. Domains make it easier to maintain user group security when several companies use the same security profile.

Note

A single company account can belong to more than one domain.

Domains allow great flexibility in the configuration of user group permissions. A domain can generate a strict security policy, in which each user group in each domain is a distinct entity with absolutely no access between groups or domains, or it can allow one user group company account access to similar group data, forms, and modules across multiple domains. The latter option simplifies the access configuration of corporate services such as controllers, multisite planners, human resource functions, and other functions that centralize or share assignments and tasks. Figure 13-11 illustrates how domains and user groups can work together in multiple ways within the same security framework.

Figure 13-11. Example of the relationship between domains and user groups

The domain security key SysOpenDomain controls access to information about users, user groups, company accounts, and domains. Using the domain security key in user groups provides access to records in all domains.

Note

Dynamics AX includes only one domain by default: Admin. The Admin domain always includes all companies. It can’t be removed, and no companies can be deleted. Use the Admin domain for any user groups that need access to all companies. When the license key domain isn’t purchased, domains are still visible and functioning, but access is limited to the Admin domain.

Permissions and user rights are granted to groups, allowing the system administrator to define a set of users that share common security privileges. When you add a user to a group, you give the user all the permissions and user rights assigned to that group. By default, user groups can’t access any menus, reports, forms, tables, or fields in Dynamics AX unless the administrator grants them access. User groups can be shared among all Dynamics AX users.

Note

A user who is a member of more than one group inherits the higher permission level of the two groups. A user can’t access the application without being added to at least one user group.

When configuring group permissions, the system administrator works with a hierarchical security tree that represents all the available security keys and includes application module access, individual permission levels, and Help text that explains the security element. The User Group Permissions form allows you to configure high-level permissions and very detailed permission levels for individual user groups. Figure 13-12 shows the configuration interface that system administrators work with to assign permissions.

Figure 13-12. User Group Permissions form

You can use the User Group Permissions form to display the security elements by selecting one of the following Viewing filters, which are available near the top of the form:

These elements are the main overview elements, but additional filters are available if the menu node doesn’t have a parent, such as Task Panes or Tools. If the preceding criteria are met, you can present customized menus automatically in the filter.

If you set the permission level to Full Control on the parent node key, security key children, menu items, and tables inherit the same permissions. However, if you set any other permission level, permissions are not inherited below the parent menu item. If a permission level is required for the entire subtree, the Cascade button grants the current permission level when clicked.

Important

If you change permissions for a user group, especially if you demote permissions, you should instruct all group members to restart the Dynamics AX client so that the permission changes take effect. If a group member doesn’t restart his or her instance of the client, you should use the Online Users form, found in the Administration module, to kill the user’s session. Keep in mind that killing a session through the Online Users form immediately terminates the session, so if the user has open transactions, they are rolled back.

Within any enterprise, some users are restricted from working with certain sensitive data because of confidentiality, legal obligations, or company policy. In Dynamics AX, authorization for access to sensitive data is managed via the table-based record level security (RLS) framework that builds on the restrictions enforced by user group permissions. With user group permissions, you restrict access to menus, forms, and reports for group members. The RLS framework allows you to add additional restrictions to the information displayed in reports and on forms. The Dynamics AX application runtime automatically applies these restrictions when the application requests data from the database table included in the RLS framework. You include the restrictions by extending the WHERE clause within the SQL statement with the defined RLS query details.

Common uses of record level security include the following situations:

When you enable record level security, you select user groups and the appropriate database table by using the Record Level Security Wizard, and then you execute a query that specifies the fields and criteria to be applied. The query criteria are specified using the generic Query form and are added to the individual database table that you chose with the wizard. Record level security is configured per company, so the wizard and criteria definitions must be executed for each company.

Important

If an application role that uses multiple user groups has record level security applied on a certain table within a company account, maximum access is given to the role. For example, if one user group has no record level security for the Customer table and another user group allows users to see only a subset of the Customer table, the user has access to all customers.

Use the following process for enabling record level security for a user group for a particular database table:

By default, the tables in the wizard are presented based on the TableGroup property with the value set to Main, and they are grouped according to the parent security key matching the main menu structures. Setting the value to Main results in a subset of the tables. However, you can expand the selection by clicking Show All Tables.

The kernel automatically invokes the RLS framework when criteria have been applied to database tables. In certain situations, such as those in the following list, you might need to do additional work to invoke the RLS framework:

Whenever you use a display or edit method to return a value from another row, you must evaluate the business impact of displaying the data. To avoid displaying particular information, you need to perform an explicit authorization in X++ code to check permissions before calling these methods. The following code shows an explicit authorization.

if (hasSecurityKeyAccess(securitykeyNum(mySecurityKey), AccessType::View))
{
    myMethod();
}
if (hasMenuItemAccess(menuItemDisplayStr(myMenuItem), MenuItemType::Display)))
{
    myMethod();
}
DictTable dictTable = new DictTable(tablenum(myTable));
if (dictTable.rights >= AccessType::Insert))
{
    myMethod();
}
if (isConfigurationkeyEnabled(configurationkeyNum(myConfigurationKey))
{
    myMethod();
}

Note

For more security-related information on using display and edit methods, refer to the Microsoft Dynamics AX 2009 SDK.

If you don’t want to display certain query data that populates a FormListControl, FormTreeControl, or TableListControl control, you must manually activate record level security, as shown here.

public void run
{
    CustTable custTable;
    super();
    // Ensure that record-level security is used.
    custTable.recordLevelSecurity(true);
    while select custTable
    {
        listView.add(custTable.name);
    }
}

When the form cache is filled with data from a temporary table, you must ensure that the data conforms to the record level security you’ve set. This includes tables declared as temporary in the code, as illustrated in the following code example, and tables in the AOT whose Temporary property is set to Yes.

public void run
{
    CustTable custTable, tmpDatasource;
    ;
    // Ensure that record-level security is used.
    custTable.recordLevelSecurity(true);
    while select custTable
    {
        tmpDataSource.data(custTable);
        tmpDataSource.insert();
    }
    formDataSource.setTmp();
    formDataSource.checkRecord(false);
    formDataSource.setTmpData(tmpDatasource);
    super();
}

Record level security is not required in the following situations:

The table permissions framework provides security for tables that reside in the database and are available through the AOT. Annotating specific create, read, update, and delete operations on tables, combined with assigning user group permissions on tables, enables the AOS to authorize individual user permissions on tables.

The AOSAuthorization property specifies the operations that can be performed on a table when combined with user permissions set on the User Group Permissions form. Figure 13-13 shows the table property form and values for AOSAuthorization.

Figure 13-13. Table property form

The AOSAuthorization property is an enumeration with the possible values described in Table 13-3.

To secure the database tables even further, you must have a set of data manipulation language (DML) validation routines at the AOS server location when inserting, reading, updating, or deleting records from the database tables. The following four system-defined methods are included in the Override Method group to support the routine validation, located in the AOT under Data DictionaryTableMethods:

Table 13-4 describes the behavior of the AOS when authorizing an authenticated user on a table, including the user group permissions setting and the AOSAuthorization property value.

The code access security (CAS) framework provides methods that can make dangerous APIs more secure against invocation attempts by nontrusted code (code that doesn’t originate in the AOT). If you extend the CodeAccessPermission class, a derived class can determine whether code accessing the API is trusted by checking for the appropriate permission.

If the API executes on the server tier, the impact of malicious code that could exploit the API is more severe in a shared environment, so you must secure the API. To secure a class that executes on the server tier, follow these steps:

Additional information about code access security and securing APIs is available in the Microsoft Dynamics AX 2009 SDK.

Dynamics AX 2009 introduces a new and more secure type of batch framework that is completely server bound. Rather than having to start a client and open the Batch Processing form, you can now schedule a batch job so that the server automatically picks up and executes it at a given time.

A batch job can be composed of multiple batch tasks that can be executed in sequence or in parallel. For a batch task to run on the server using the new batch framework, the job must use the runAs function. When this type of batch processing is used, the user who initiates the batch processing can’t interact with the batch task or view its output. In addition, the task must not access any client-side resources while executing.

Dynamics AX 2009 also continues to support batch processing that doesn’t use the runAs function and requires the client to execute. And if you need to, you can easily update old batch-enabled classes to use the runAs function.

Note

When you move batch tasks to the runAs function, you must ensure that there are no additional Dynamics AX application runtime interactions.

To identify possible runtime interactions, use any of the following approaches:

If you discover any runtime interactions, you should eliminate them by refactoring the application logic involved. When the class is ready to use the runAs function, you must override a method shown to return true, as shown here.

public boolean runsImpersonated()
{
    return true;
}

Note

Batch jobs in Dynamics AX 2009 can contain a mixture of legacy and new batch tasks. The tasks that use the new framework automatically execute on the server, whereas the legacy tasks require the batch processing form on the client to be running.

The Best Practice tool can help you validate your application logic and ensure that it complies with the Trustworthy Computing initiatives. The rules that apply to Trustworthy Computing are grouped under General ChecksTrustworthy Computing in the Best Practice Parameters dialog box, as shown in Figure 13-14. The Best Practice Parameters dialog box is accessible from ToolsOptions.

Figure 13-14. Best Practice Parameters dialog box with Trustworthy Computing rules