I think this topic is very useful with AX new Implementation and all points mentioned here should be taken into our consideration.
This topic describes the tools and strategies that you can use when you are planning to import or export Microsoft Dynamics AX data. The topic also describes how to plan to move data from one enterprise resource planning (ERP) system to another. Finally, the topic describes performance and security considerations when you import and export data. read more
1. In a typical integration scenario, users who have business expertise first determine the document exchange needs. These are requirements from a business perspective. The business users work with the Implementation team to specify:
a. What data is to be exchanged.
b. Any business logic related to that data.
c. The external systems with which data is to be exchanged.
d. The conditions under which data is sent from or received by Microsoft Dynamics AX.
2. The partner or system implementer works with the customer and their IT staff to determine the hardware and software requirements for AIF. They analyze the existing environment and recommend any new hardware or software that must be installed.
3. The customer's IT staff installs and configures any required hardware and software to support AIF.
4. The partner or customer developer programs the document exchange. They can make customizations to the AIF documents or create new documents to meet the requirements of the business users. How AIF is configured depends in part on the network environment. Therefore, the developer may work with IT staff when implementing an integration scenario.
5. IT staff monitors the document exchanges and troubleshoot any errors that are generated.
This topic provides answers to common document management questions. You can use document management in Microsoft Dynamics AX to attach files to records. For example, you can attach PDF, Microsoft Word, or Microsoft Excel files to a purchase order or a sales order. You can also create Word and Excel templates from Microsoft Dynamics AX data.
What is the difference between document handling and document management?
There is no difference. Both terms refer to the same functionality. In earlier versions of Microsoft Dynamics AX, the functionality was called document handling. In more recent versions, it’s called document management.
What is the difference between document management and print management?
What is the difference between document management and print management?Document management lets you add notes, documents, and other files to records in Microsoft Dynamics AX.
Print management lets you control print settings for selected reports. Print settings include the number of copies, the printer destination, and the multilanguage text that can be included on the report. For more information, see Print management.
What is the difference between document types and file types?
Document types are used to categorize the documents that you attach to records or the templates that you create. The document management system handles several types of documents. These include letters, worksheets, and notes. Before you can create templates or attach documents to records, you must configure document types in the Document types form. For more information, see Configure document management.
A file type is the extension of the document. For example, .doc, .xlsx, and .pdf are all file types.
Can I export or import document types?
Yes. For more information, see Export and import a document type.
What is the difference between document management and print management?
Yes. Document attachments can be located anywhere on the Internet or on an intranet and can be attached by using the URL DocuType. For example, if you attach a Word document that is located on SharePoint Online to a record, the attachment opens in the web version of Word
Can I store Microsoft Dynamics AX attachments in SharePoint?
Yes, but only if you’re using Microsoft Dynamics AX 2012 R2. For more information, see Configure Microsoft Dynamics AX document management to use Microsoft SharePoint document libraries.
Can I use templates that are stored in SharePoint as Microsoft Dynamics AX document templates?
Yes, but only if you’re using AX 2012 R2. For more information, see Configure Microsoft Dynamics AX document management to use Microsoft SharePoint document libraries.
Can I move a document archive?
Yes. However, you must copy the documents from the old archive to the new archive before you enter the new location in the archive directory field. This precaution is necessary so that you don’t break existing document references to existing documents.
To move a document archive, follow these steps:
1. Copy all documents from the old archive to the new archive.
2. Click Organization administration > Setup > Document management > Document management parameters.
3. In the General area of the form, in the Archive directory field, enter the path of the new document archive.
Why can’t I click the attachments icon in the Document handling form?
The attachments icon is available only if all of the following scenarios are true:
· You have selected a record.
· You have activated document management. For more information, see Configure document management.
· You have permission to view attachments for the record.
How do I lock the Document handling form?
The Document handling form always lists the documents that are attached to the selected record. If you leave the Document handling form open and you select another record, the form is updated to list the documents that are attached to the newly opened record.
To avoid updating the Document handling form when you select a different record, you can lock the view so that the information in the form doesn’t change.
To lock the Document handling form view, follow these steps:
1. Select a record.
2. Click File > Command > Document handling to open the Document handling form.
3. Click Functions > Lock.
4. Select another record. The documents for the locked record are still displayed in the Document handling form.
You can use the following methods to integrate Microsoft Dynamics AX with other applications:
1- Services and the Application Integration Framework
Services are the preferred option for integration with Microsoft Dynamics AX. Services in Microsoft Dynamics AX are used to expose its functionality through WCF-based services. Microsoft Dynamics AX code and external applications can consume Microsoft Dynamics AX services. AIF supports the processing of inbound and outbound messages such as message transforms and value lookups. Together, services and AIF provide the programming model, tools, and infrastructure support for XML-based integration with external applications and data
2- .NET interop to X++
You can use the .NET interop to X++ feature to call X++ code using C# or another managed language. A proxy is an automatically generated .NET class, in C# or another managed language, that mimics an X++ class of Microsoft Dynamics AX.
3- .NET interop from X++
The .NET interop from X++ (also known as the CLR Interop in the previous release) provides interoperability with external .NET components and you can execute managed-code components from within X++ code. .NET interop from X++ is useful when you want your X++ code to access functionality provided by a CLR-managed assembly. This includes assemblies that are installed with the .NET Framework and any assemblies that you create with a language such as C# or Visual Basic.NET.
4- Consume external web services
You can use the Microsoft Dynamics AX programming model to consume external web services from within X++ code. To consume an external web service from X++, you must first create a reference to the web service. After creating a reference to the web service, you can invoke it from X++
and view the available methods with IntelliSense. Calling and managing external web services is done completely within Microsoft Dynamics AX.
The following figure shows how the AIF integration components interact with Microsoft Dynamics AX through the AOS.
1- You can add users to Microsoft Dynamics AX as the following:
- add Active Directory users.
- Add Active Directory groups.
- Add external users (Claim users): Pluggable authentication is used to allow access to Enterprise Portal to users who are not part of Active Directory, Pluggable authentication provides an administrator three additional forms of authentication in addition to Active Directory: Active Directory Federated Services, Windows Live IDs, or an External
Database.
- Both of Active Directory groups and Claim users are new authentication types added to Microsoft Dynamics AX 2012
2- Process Cycle is a group of duties which can be optionally used when assigning duties to roles.
3- Roles is a group of duties for a job function.
4- Duties is a responsibility to perform one or more tasks or services for a job.
5- Privilege is group of related entry points with associated access levels.
6- Permission is a group of base objects and required permissions For example: Form permissions .
7- Each user must be assigned to at least one role in order to access the system. The security model is a hierarchy, with each element representing a different level of detail. At the top of the hierarchy are process cycles. Process cycles are composed of duties, and they represent business processes, such as the expenditure process. Duties are composed of privileges, and they represent parts of a business process, such as maintaining bank transactions. Privileges are composed of permissions, and they represent access to tasks, such as canceling
payments or processing deposits. Permissions grant access to application elements, such as forms and menu items.
8- Both duties and privileges can be assigned to roles to grant access to the application.
9- Process cycles are used only to organize duties and privileges. If a duty or privilege is not assigned to a process cycle, that duty or privilege is not available in the Security privileges form. To work with duties and privileges that do not appear in the form, you must use application Object Tree (AOT).
10- Because the record-level security feature because will be deprecated in a future release of
Microsoft Dynamics AX, it is recommend using data security policies instead
11- Table Permission framework (TPF ) was limited to denying users access to full records in AX 4 and AX 2009, but could not restrict individual fields from being visible. In Microsoft Dynamics AX 2012 TPF is extended so that it can also work on fields. This shifts more of the security load to the server. This helps to increase the consistency of security between client types.
12- Reusable Permissions: In Microsoft Dynamics AX 2012, a single set of roles applies across all companies and organizations. The administrator no longer has to create and
maintain separate user groups for each company, as was the case in earlier versions. Even though roles themselves are not specific to a company or organization, the administrator can still specify a company or organization context for a particular user in a role.
13- Extensible data security policies, when deployed, are enforced, regardless of whether data is being accessed through the Microsoft Dynamics AX rich client forms, Enterprise Portal web pages, SQL Server Reporting Services (SSRS) reports, or .NET Services.
To create a new role, follow these steps:
1. Open System administration > Setup > Security > Security roles.
2. To create a new role, click New.
3. If you are creating a new role, enter the name that you want to appear for the role in the Application Object Tree (AOT) in the AOT name field.
4. Select the check box next to each desired duty, privilege, or sub-role and then click Close.
5. To remove a duty, privilege, or sub-role from the role, select the duty, privilege, or sub-role, and then click Remove.
6. To change the role's permission level on securable objects such as controls, tables, fields, and server methods click Override permissions.
NOTE: AOT names must contain only alphanumeric or underscore characters. AOT names cannot begin with a number, and they cannot contain special characters or spaces.
8. To include all of the permissions from another role, open the Security roles form, and drag the role that has the permissions that you want to the role that you are modifying. By dragging one role to another, you create a hierarchical relationship, where the main role contains all of the permissions of the sub-role. If you change the
permissions of a sub-role, the changes also apply to the main role.
A role cannot contain duties that conflict according to the rules for the segregation of duties.
TIP: Security is organized hierarchically. Permissions on specific application elements are combined into privileges, privileges are combined into duties, and duties are grouped into process cycles. You can assign either duties or privileges to roles.
Reporting Services uses role-based security to grant user access to a report server. On a new report server installation, only users who are members of the local Administrators group have permissions to report server content and operations. To make the report server available to other users, you must create role assignments that map user or group accounts to a predefined role that specifies a collection of tasks.
For a report server that is configured for native mode, use Report Manager to assign users to a role. There are two types of roles:
Item-level roles are used to view, add, and manage report server content, subscriptions, report processing, and report history. Item-level role assignments are defined on the root node (the Home folder) or on specific folders or items farther down the hierarchy.
System-level roles grant access to site-wide operations that are not bound to any specific item. Examples include using Report Builder and using shared schedules.
The two types of roles complement each other and should be used together. For this reason, adding a user to a report server is a two-part operation. If you assign a user to an item-level role, you should also assign them to a system-level role. When assigning a user to a role, you must select a role that is already defined. To create, modify, or delete roles, use SQL Server Management Studio.
For a report server that is configured for SharePoint integrated mode, you configure access from a SharePoint site using SharePoint permissions. Permission levels on the SharePoint site determine access to report server content and operations. You must be a site administrator to grant permissions on a SharePoint site.
Before you start
Review the following list before adding users to a native mode report server.
You must be a member of the local Administrators group on the report server computer. If you are deploying Reporting Services on Windows Vista or Windows Server 2008, additional configuration is required before you can administer a report server locally.
To delegate this task to other users, create role assignments that map user accounts to Content Manager and System Administrator roles. Users who have Content Manager and System Administrator permissions can add users to a report server.
In SQL Server Management Studio, view the predefined roles for System Roles and User Roles so that you are familiar with the kinds of tasks in each role. Task descriptions are not visible in Report Manager, so you will want to be familiar with the roles before you begin adding users.
Optionally, customize the roles or define additional roles to include the collection of tasks that you require. For example, if you plan to use custom security settings for individual items, you might want to create a new role definition that grants view-access to folders.
Start Report Manager.
Click Site Settings.
Click Security.
Click New Role Assignment.
In Group or user name, enter a Windows domain user or group account in this format: <domain>\<account>. If you are using forms authentication or custom security, specify the user or group account in the format that is correct for your deployment.
Select a system role, and then click OK.
Roles are cumulative, so if you select both System Administrator and System User, a user or group will be able to perform the tasks in both roles.
Repeat to create assignments for additional users or groups.
Start Report Manager and locate the report item for which you want to add a user or group.
Hover over the item, and click the drop-down arrow.
In the drop-down menu, click Security.
Click New Role Assignment.
Note: If an item currently inherits security from a parent item, click Edit Item Security in the toolbar to change the security settings. Then click New Role Assignment.
In Group or user name, enter a Windows domain user or group account in this format: <domain>\<account>. If you are using forms authentication or custom security, specify the user or group account in the format that is correct for your deployment.
Select one or more role definitions that describe how the user or group should access the item, and then click OK.
Repeat to create assignments for additional users or groups.
Configure security settings in Microsoft Dynamics AX
Complete the following tasks in Microsoft Dynamics AX:
• Determine which reports each Microsoft Dynamics AX role should have access to.
• Verify that each Microsoft Dynamics AX role has the correct duties and privileges assigned to it in order to access the reports.
• Assign users to Microsoft Dynamics AX roles.
• Secure the data shown in reports.
Configure security settings in Reporting Services Complete the following tasks in Reporting Services:
• Assign users to the DynamicsAXBrowser role in Reporting Services.
For detailed instructions about how to assign users to Reporting Services roles, refer to my post (How to: Grant User Access to a Report Server).
• Identify the account that is used to run the Application Object Server (AOS) service and the account that is used as the Business Connector proxy. Assign those accounts to the DynamicsAXBrowser role in Reporting Services.
• Restrict access to report folders and reports. Reporting Services includes security features and tools that you should use to help control access to report folders and published reports. Refer to the SQL Server documentation on MSDN for detailed conceptual information and step-by-step tutorials that will help you administer
security in Reporting Services.
Cognos, Microstrategy, BusinessObjects, Board, Tableau, and QlikView are some of the top names in BI software for 2014. Now you can compare them quickly and easily online.
Simply enter your company's high- and mid-level requirements, and you'll get a BI comparison report based on your company's specific needs.
You can also choose to drill down and compare these solutions at a very detailed, granular level. It's fast, free--and you'll get the results immediately!
http://www.technologyevaluation.com/
The following diagram illustrates the architecture of the reporting functionality in Microsoft Dynamics AX.
1. A user requests a report.
Assume that a user clicks a menu item in the Microsoft Dynamics AX client. The menu item is bound to a SQL Server Reporting Services report.
After the user clicks the menu item, a parameters form is displayed to the user. The user enters parameters to filter the data that will be displayed on the report.
The Microsoft Dynamics AX client then requests the report from Reporting Services. (The request includes the parameters entered by the user.)
2. Reporting Services receives the request and asks the Microsoft Dynamics AX server for the report data.
Reporting Services receives the request and examines the report on the server. The report is stored as an .rdl file. The .rdl file indicates the report’s data source. (The data source could be a Microsoft Dynamics AX query, a report data provider class, or an external data source via report data methods.)
In cases where a Microsoft Dynamics AX data source is used for the report, Reporting Services will use the Microsoft Dynamics AX data extension to retrieve the data.
At this point, Reporting Services asks Microsoft Dynamics AX for metadata about the data source. Reporting Services then requests the data for the report.
3. The Microsoft Dynamics AX server receives the request and sends the report data back to Reporting Services.
The Microsoft Dynamics AX services examine the query in the AOT to return the requested metadata. The services also execute the query to generate the data for the report.
Microsoft Dynamics AX returns the metadata and data to Reporting Services.
NOTE: Microsoft Dynamics AX enforces security on all data returned. If the user who is running the report is not allowed to see a specific field, the data for that field is not returned.
4. Reporting Services renders the report and sends it to the Microsoft Dynamics AX client.
The Microsoft Dynamics AX customization extension formats the report.
The customization extension uses metadata to provide automatic formatting of data and can affect the positioning and layout of elements in the report.
Reporting Services then renders the report into a visual representation and sends that to the Microsoft Dynamics AX client.
5. The report is displayed to the user.
The Microsoft Dynamics AX client displays the report to the user in the report viewer control.
In a consolidation, you gather transactions from several sets of legal entity accounts into a single set of legal entity accounts.
Note : We recommend that you use Management Reporter for Microsoft Dynamics ERP to combine the financial results for multiple legal entities in a consolidated format. Management Reporter lets you create consolidated financial reports across legal entities, use Microsoft Excel to import consolidation data from other sources, and translate amounts into any number of reporting currencies without having to run the consolidation process in Microsoft Dynamics AX.
For more information about how to consolidate transactions by using Management Reporter, see Financial consolidations and currency translation.
You can print reports, such as financial statements, from the consolidated legal entity. However, you cannot use the consolidated legal entity for daily transactions.
You can consolidate data from legal entities that use different databases than the database for the consolidated legal entity. This consolidation process is referred to as an import consolidation. Alternatively, the legal entities can use the same database as the consolidated legal entity. This consolidation process is referred to as an online consolidation.
The consolidated legal entity collects the results and balances of the subsidiaries. To prepare a consolidated legal entity for a consolidation, you must follow these steps:
Click General ledger > Setup > Organization > Legal entities.
Click New to create a new legal entity that will be the consolidated legal entity.
Select the Use for financial consolidation process check box, and then enter information about the consolidated legal entity. Enter this information exactly as you want it to appear on financial statements for the consolidated legal entity.
Close the form.
In the lower-right corner of the Microsoft Dynamics AX workspace, click the Current company field to open the Select company form. Select the consolidated legal entity, and then click OK.
Click General ledger > Setup > Ledger.
Select the chart of accounts, the fiscal calendar, the accounting currency, an optional reporting currency, and the default exchange rate type for the consolidated legal entity. For more information, see Ledger (form).
Click General ledger > Setup > Currency > Currency exchange rates.
Set up currency exchange rates in relevant periods for the currencies of the subsidiary legal entities. For more information, see Currency exchange rates (form).
Close the form.
If the consolidated legal entity has subsidiaries that use foreign currencies, open the Accounts for automatic transactions form. (Click General ledger > Setup > Posting > Accounts for automatic transactions.) In the Posting type field, select an appropriate account:
If the legal entity has foreign subsidiaries that are financially or operationally interdependent with the parent legal entity, select an appropriate account for the Profit and loss account for consolidation differences posting type.
If you are consolidating a subsidiary that is financially and operationally independent from the parent legal entity, or a legal entity that contains the results of several subsidiaries that are financially and operationally independent from the parent legal entity, and if you are using translation methods to consolidate the data, select an appropriate account for the Balance account for consolidation differences posting type.
In the Main account field, select the main accounts that will be used for foreign currency revaluation adjustments.
Close the form.
If you create the consolidated legal entity early in a period, you can revalue the foreign currency amounts as exchange rates change during the consolidation period.
The consolidated legal entity is now set up for the Consolidate periodic job. You can specify whether to perform either an online consolidation or an import consolidation:
Click General ledger > Periodic > Consolidate > Consolidate [Import from].
–or–
Click General ledger > Periodic > Consolidate > Consolidate [Online].
Note : Before you can process the consolidation, prepare the subsidiary legal entities for consolidation. For more information, see Set up a subsidiary legal entity for consolidation.
When you import a model into the model store, the resources in the model may have conflicts with resources in other models that are already part of that layer. If you use the push option when importing the model, the conflicting resources will be put into a new conflict model that is located in the patch layer for the current layer in the AOS. This new model will have a name that indicates it contains resources that have caused a conflict. For example the model named Facility Management (Conflict 1) contains the resources that caused a conflict when the Facility Management model was being imported.
Often, it is a developer responsibility to help resolve conflicts that occur when a model is imported. Use the following procedure as a general guideline to help you through this process.
Resolving Conflicts after Importing a Model
Determine whether any conflicts occurred during the model import process.
If you imported a model from the command line, the results returned from the command will indicate whether conflicts occurred during the import process.
If you do not know the results of the import process, use the Models installed command as described in How to: View Model Information to view the list of models that are installed. If you see any conflict models in a patch layer, they will contain the resources that caused the conflict.
Retrieve the list of resources that caused conflicts. Use the view command to see the list of resources in the conflict model. These are the conflicts that you have to resolve. For detailed information about how to list resources in a model, see How to: View and Verify Contents of a Model. For example, the following command uses axutil.exe to list resources in the Facility Management (Conflict 1) model:
axutil.exe view /model:"Facility Management (Conflict 1)" /verbose
In the AOT, select a resource that has a conflict. Right-click the resource and choose Compare. In the Comparison window, click Compare to see the differences between the resource in the patch layer and the resource in the main layer.
Resolve the conflict. There are many ways to resolve the conflict, depending on the resource type and the actual conflict. Some of the ways to resolve the conflict include the following:
Use the information and the available actions from the Comparison window to merge changes from the conflict model into an existing layer.
Make a change in the resource in an existing model in the current layer. For example, if two different models in the layer have modified the same resource, you could consider creating a new “shared” model in the layer that contains a single version of the resource that can be used by both of the other models.
Switch to the patch layer and modify the resource there. In some cases, this is the easiest way to resolve the conflict.
Tip
You can switch to the patch layer by creating a new configuration with the Microsoft Dynamics AX 2012 Configuration tool. You can also switch to a specific patch layer by using the following command to start Microsoft Dynamics AX:
Ax32.exe –AOL=USP
Repeat the conflict resolution process for each resource in the conflict model.
After you have resolved all of the conflicts, consider removing the conflict model from the patch layer. That way, somebody looking at the system will not assume that there are model conflicts that have to been resolved. If you are leaving a resource in the patch layer, move the resource out of the conflict model into another model in the patch layer. Then delete the conflict model.
You can configure Microsoft Dynamics AX Application Object Server (AOS) clusters that include a dedicated load balancer. You can also configure clusters that do not include a dedicated load balancer. This topic describes planning considerations for an AOS cluster that does not include a dedicated load balancer.
Overview
The following figure shows how a client establishes a connection with an AOS instance in a cluster when a dedicated load balancer is not present.
When a Microsoft Dynamics AX client starts, the client reads the list of AOS instances that is specified in the Microsoft Dynamics AX 2012 Configuration utility. The client initiates a handshake with the first AOS instance in the list. If the first AOS instance does not respond, the client initiates a handshake with the next AOS instance in the list. The client continues in this manner until the handshake occurs.
The AOS instance that received the client request queries the database and all active AOS instances in the cluster. The AOS instance returns to the client a list of all active AOS instances in the cluster, sorted by workload. The server that has the smallest workload is at the top of the list. The workload is based on the number of connected clients, divided by the maximum number of clients that are allowed on the server.
The client attempts to connect to each AOS instance in the sorted list until a successful connection is established. The client then uses the AOS instance that it connected to for the whole session.
Considerations for using an AOS instance in a cluster that does not include a dedicated load balancer
If a dedicated load balancer is not present, each AOS instance in the cluster functions as both an active AOS instance and a load balancer.
An active AOS instance has higher hardware requirements than an AOS instance that functions as a dedicated load balancer.
For information about how to configure load balancing clusters, see Create a load balancing cluster post.
You can distribute the user load in Microsoft Dynamics AX across multiple instances of Application Object Server (AOS) by creating a load balancing cluster.
Clustering overview
Microsoft Dynamics AX offers two types of load balancing clusters:
A cluster that includes a load balancer
A cluster that does not include a load balancer
A cluster that includes a load balancer
If you set up a cluster that includes a load balancer, the load balancing AOS instance is dedicated to distributing the user load. The load balancing AOS instance does not process Microsoft Dynamics AX business logic or data.
In this configuration, you must set up client configurations to connect to the load balancing AOS instance. You can then add and remove other AOS instances from the cluster without updating client configurations.
When a client starts, it connects to the load balancing AOS instance. The load balancing AOS instance returns a list of active AOS instances in the cluster, sorted by workload. The client attempts to connect to the first AOS instance in the list. If that connection fails, the client attempts to connect to the second AOS instance in the list, and so on.
A cluster that does not include a load balancer
If you set up a cluster that does not include a load balancer, each AOS instance functions as both a load balancer and an active AOS instance that accepts client connections.
When a client starts, it sends a request to the first server that is listed in the client configuration. That server returns the list of active AOS instances in the cluster, sorted by workload. The client attempts to connect to the first AOS instance in the list. If that connection fails, the client attempts to connect to the second AOS instance in the list, and so on.
Before you begin
Before you can create a cluster, you must install multiple AOS instances. Each instance must point to the same database. For more information, see Install multiple AOS instances and Configure an AOS to access a different database.
Create a cluster
Click System administration > Setup > System > Cluster configuration.
Press CTRL+N to create a new cluster.
Caution
You cannot configure the Non Load Balanced AOS Instances as a load balancing cluster. The Non Load Balanced AOS Instances is a default entity that enables AOS communications for non-load balanced AOSs. To create an AOS cluster, you must create a new cluster.
Enter a name and description for the cluster.
Press CTRL+S to save your changes.
Add an AOS instance to a cluster
Click System administration > Setup > System > Cluster configuration.
In the Map AOS instances to clusters section, select an AOS instance.
If you want the AOS instance that you selected to function as a load balancer, select the Load balancer option.
Note
If an AOS instance is used as a load balancer, it cannot be used as a batch server.
Click the Cluster name field to display a list of available clusters. Select the cluster that you want to add the AOS instance to.
Press CTRL+S to save your changes.
Change client configurations
If the cluster uses one or more load-balancing AOS instances, set client configurations to connect to these load balancing AOS instances.
Use the Microsoft Dynamics AX Configuration utility to change client configurations. For more information, see my post Manage a client configuration .
Developing an extensible data security policy involves the following steps:
1. Modeling the query on the primary table.
2. Creating the policy.
3. Adding the constrained tables and views.
4. Setting the context.
However, before you start developing a policy, you must understand the underlying requirements. You should identify the set of constrained tables and analyze the relationships that these tables have with the primary table. You should also analyze the data access patterns of the constrained tables, the table sizes, and existing indexes on both the primary and constrained tables. All of these aspects influence the impact that a policy will have on the performance of the application.
NOTE: For more information about developing an extensible data security policy, click here to download Developer Documentation
When developing a data security policy, you need to become familiar with several concepts, such as constrained tables, primary tables, policy queries, and context. This section outlines these concepts.
• Constrained table: A constrained table is the table or tables in a given security policy from which data is filtered or secured, based on the associated policy query. For example, in a policy that secures all sales orders based on the customer group, the SalesOrder table would be the constrained table. Constrained tables are always explicitly related to the primary table in the policy.
• Primary table: A primary table is used to secure the content of the related constrained table. For example, in a policy that secures all sales orders based on the customer group, the Customer table would be the primary table.
• Policy query: A policy query is used to secure the constrained tables specified in a given extensible data security policy. This query will return data from a primary table that is then used to secure the contents of the constrained table.
• Context: A policy context is a piece of information that controls the circumstances under which a given policy is considered to be applicable. If this context is not set, then the policy, even if enabled, is not enforced. Contexts can be of two types:
o A role context enables policy application based on the role or roles to which the user has been assigned.
o An application context enables policy application based on information set by the application.
The build version numbers are split into three parts. First the client version number is listed, followed by the application version. Formatted like: Build #client version/application version/localization versions.
| Contents
|
Dynamics AX 2012 R3
| Build number | Version |
| 6.3.126.8 | 2012 R3 CTP5 |
| 6.3.42.13 | 2012 R3 CTP4 |
Dynamics AX 2012 R2
| Build number | Version |
| 6.2.158.0 | 2012 R2 |
| 6.2.1000.156 | 2012 R2 Cumulative Update 1 (CU1) |
| 6.2.1000.1437 | 2012 R2 Cumulative Update 6 (CU6) |
| 6.2.1000.4051 | 2012 R2 Cumulative Update 7 (CU7) |
Dynamics AX 2012
| Build number | Version |
| 6.0.852.78 | 2012 Beta |
| 6.0.947.0 | 2012 RTM |
| 6.0.947.61 | 2012 Cumulative Update 1 (CU1) |
| 6.0.947.280 | 2012 Cumulative Update 2 (CU2) |
| 6.0.947.862 | 2012 Feature Pack |
| 6.0.1108.670 | 2012 Cumulative Update 3 (CU3) |
| 6.0.1108.2423 | 2012 Cumulative Update 4 (CU4) |
| 6.0.1108.4316 | 2012 Cumulative Update 5 (CU5) |
Dynamics AX 2009
| Build number | Version | RPC interface version |
| 5.0.593.0 | 2009 RTM | 50444.0 (C50C.0000) |
| 5.0.593.439 | 2009 Hotfix Rollup 1 (RU1) | N/A |
| 5.0.593.662 | 2009 Hotfix Rollup 2 (RU2) | N/A |
| 5.0.593.827 | 2009 Hotfix Rollup 3 (RU3) | N/A |
| 5.0.593.1084 | 2009 Hotfix Rollup 4 (RU4) | N/A |
| 5.0.593.1287 | 2009 Hotfix Rollup 5 (RU5) | N/A |
| 5.0.593.1429 | 2009 Hotfix Rollup 6 (RU6) | N/A |
| 5.0.1000.52 | 2009 SP1 | 50444.0 (C50C.0000) |
| 5.0.1500.358 | 2009 SP1 Hotfix Rollup 1 (RU1) | 50444.0 (C50C.0000) |
| 5.0.1500.809 | 2009 SP1 Hotfix Rollup 2 (RU2) | 50444.0 (C50C.0000) |
| 5.0.1500.1313 | 2009 SP1 Hotfix Rollup 3 (RU3) | 50444.0 (C50C.0000) |
| 5.0.1500.2116 | 2009 SP1 Hotfix Rollup 4 (RU4) | 50444.0 (C50C.0000) |
| 5.0.1500.2985 | 2009 SP1 Hotfix Rollup 5 (RU5) | 50444.0 (C50C.0000) |
| 5.0.1500.3761 | 2009 SP1 Hotfix Rollup 6 (RU6) | 50444.0 (C50C.0000) |
| 5.0.1500.4570 | 2009 SP1 Hotfix Rollup 7 (RU7) | 50444.0 (C50C.0000) |
| 5.0.1500.6491 | 2009 SP1 Hotfix Rollup 8 (RU8) | 50444.0 (C50C.0000) |
Dynamics AX 4.0
| Build number | Version | RPC interface version |
| 4.0.1659.26 | 4.0 RTM | 41638.0 (A2A6.0000) |
| 4.0.1659.35 | 4.0 RTM (localized) | N/A |
| 4.0.2163.0 | 4.0 SP1 | 42060.0 (A44C.0000) |
| 4.0.2500.XXX | 4.0 SP1 DIS layer hotfixes | 42060.0 (A44C.0000) |
| 4.0.2501.116 | 4.0 SP2 | 42060.0 (A44C.0000) |
| 4.0.2503.XXX | 4.0 SP2 DIS layer hotfixes | 42060.0 (A44C.0000) |
Axapta 3.0
|
|