Share This Post

Dynamics AX Updates

Dynamics AX Data Partitioning Architecture

In this Article, we are going to discuss the Microsoft Dynamics AX Data Partitioning Architecture and its Characteristics.

Microsoft Dynamics AX enables data isolation by using AX data partitioning. For example, an organization has several subsidiaries. If the management of the organization does not want the employees of one subsidiary to have access to the data for other subsidiaries, data partitions can provide the boundaries that are required for data isolation.

Dynamics AX Data Partitioning provides a logical separation of data in the Microsoft Dynamics AX database. To achieve this separation, Dynamics AX adds a column to each table that contains data that must be isolated. This column contains the partition ID, which is the Recall of an entry in the Partitions table. In the partitioned table, rows that contain the same partition ID value that belong to the same partition. The partition ID is also added to the relevant indexes.

The Partitions are defined in the Partitions form, where the system administrator creates the partition and provides a partition key. A partition key identifies a partition by using the unique string value that the system administrator specifies. MS Dynamics AX displays the partition key in the title bar of the client application. Partitions can also be defined during the installation and upgrade.

Diagram illustrates the AX Data Partitioning Architecture

The scope of Data Isolation

It is very important to understand that AX Data Partitioning does not create separate installations. Consider the following characteristics of partitioned systems:

Shared AOS

Shared AOS

Shared AOS

A partitioned system is created in the context of a single instance of Dynamics AX Application Object Server (AOS) or an AOS cluster. When MS Dynamics AX is first set up, the system creates a default partition. The partition key for default partition is “initial”. Additional partitions can be created during the installation or upgrade, or at any time after the system is deployed. Once a partition has been created, it cannot be deleted.

Shared Database

In a partitioned system, all the data is stored in the same database or database cluster. Partitions provide only logical data separation. No physical isolation of data occurs. Many system tables are nothing but the shared tables that do not contain the column for the partition ID.

Shared AOT

A partitioned system has one MS Dynamics AX Application Object Tree (AOT). Customizations are always shared across all partitions. The model store database is not partitioned. Metadata that describes the objects in the AOT is shared. Custom code is shared across the system.

By default, the code runs in the context of the partition for the current session. This behavior resembles the behavior of X++, which handles the companies by using the dataAreaId field. Therefore, the pre-existing code that uses the X++ query mechanism works without modification. The Direct SQL calls must be modified to filter on the context of the current partition.

The Microsoft Dynamics Axapta cross-reference system is shared. Role definitions are shared across the system. In Dynamics AX and the later versions, multi-partition configurations have no new requirements to define or maintain reports.

Common Administration

Users who have the system administrator role can access the data in all partitions. However, to view the data in a particular partition, the administrator must log on to a client instance for that partition.

System administrators can create new partitions. Both the system administrators and the security administrators can manage the users in the context of a partition.

License keys and the configuration keys are shared across the system.

Common Application Integration

In a partitioned system, the Services and Application Integration Framework (AIF) is a shared subsystem. To guarantee that the incoming requests are correctly isolated, you can restrict an inbound integration port to a particular partition. Additionally, you can specify the target partition for an incoming request by including the partition key in an XML element in the header of the document. Similarly, the outbound responses tell that the source partition for the response data by adding the partition key in the header.

Because AIF uses a single gateway queue, a system administrator can view all the documents in the queue, AIF history, or exceptions list in any partition. The forms that display the lists now have a field that shows the partition key for each document.

Common Batch Framework

Similarly like the AIF, the batch processing framework is a shared subsystem. One batch server is shared across partitions. However, each batch job is associated with a particular partition. The batch server executes the batch jobs in the context of the correct partition. To view the batch jobs or their history, you must log on to the partition that the batch jobs are associated with.

Separate Application Data

Access to the application data is controlled by the combination of the partition ID and the user’s role and permissions. The Dynamics AX client does not let users view unified data across partitions. MS Dynamics Axapta does not give a query mechanism to retrieve and combine data from multiple partitions.

Separate Organizational Hierarchies

Each of the partition contains its own organizational hierarchy, which includes one or more legal entities. Like a new deployment of the Microsoft Dynamics AX, each partition that is created contains the DAT company as a default legal entity. System administrators can add the legal entities to each partition. Legal entities are never shared between the partitions, even if the legal entities have the same name.

Separate User Configurations

Each partition contains its own list of the authorized users. The system administrator who created the partition is automatically created as the user who has the system administrator role in the new partition. After a system administrator logs on to the partition, he or she can add authorized users to the partition.

A user can be authorized to access the data in more than one partition. However, the user must be both created and managed separately in each partition. This user must use a separate client configuration to start the separate client session for each partition. Each user is associated with a default partition. This default partition can be changed by the system administrator. A user who logs on to MS Dynamics AX by using a default client configuration is logged on to the user’s default partition.

The MS Dynamics AX client application displays the partition key for the current session in the title bar of the main window.

User roles are assigned to each partition.

Conclusion

In this Article, we dealt with the Dynamics AX Data Partitioning Architecture and its Characteristics.

Share This Post

Leave a Reply

avatar
  Subscribe  
Notify of
Skip to toolbar