DATA PARTITIONING IN MICROSOFT DYNAMICS AX 2012 R3

Microsoft Dynamics AX 2012 R2 enables data isolation by using data partitions. For example, an organization has several subsidiaries. If the management of the organization does not want 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.

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

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 a unique string value that the system administrator specifies. Microsoft Dynamics AX displays the partition key in the title bar of the client application. Partitions can also be defined during installation and upgrade.


Scope of data isolation

It is important to understand that data partitions do not create separate installations of Microsoft Dynamics AX. Consider the following characteristics of partitioned systems:

• Shared AOS – A partitioned system is created in the context of a single instance of Microsoft Dynamics AX Application Object Server (AOS) or an AOS cluster. When Microsoft Dynamics AX is first set up, the system creates a default partition. The partition key for the default partition is "initial". Additional partitions can be created during installation or upgrade, or at any time after the system is deployed. After a partition has been created, it cannot be deleted.
• Shared database – In a partitioned system, all 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 shared tables that do not contain a column for the partition ID.
• Shared AOT – A partitioned system has one Microsoft Dynamics AX Application Object Tree (AOT). Customizations are always shared across all partitions. The model store database is not partitioned. Metadata that describes objects in the AOT is shared. Custom code is shared across the system.
  By default, code runs in the context of the partition for the current session. This behavior resembles the behavior of X++, which handles companies by using thedataAreaId field. Therefore, pre-existing code that uses the X++ query mechanism works without modification. Direct SQL calls must be modified to filter on the context of the current partition.
  For more information about using data partitions in development projects, see Partitions, Companies, and Data Isolation in Microsoft Dynamics AX. see link
  The Microsoft Dynamics AX cross-reference system is shared. Role definitions are shared across the system. In Microsoft Dynamics AX 2012 R2 and 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 data in all partitions. However, to view data in a particular partition, the administrator must log on to a client instance for that partition.
  System administrators can create new partitions. Both system administrators and security administrators can manage users in the context of a partition.
  License keys and configuration keys are shared across the system.
• Common application integration – In a partitioned system, Services and Application Integration Framework (AIF) is a shared subsystem. To guarantee that incoming requests are correctly isolated, you can restrict an inbound integration port to a particular partition. Additionally, you can specify a target partition for an incoming request by including the partition key in an XML element in the header of the document. Similarly, outbound responses indicate the source partition for the response data by including the partition key in the header.
  Because AIF uses a single gateway queue, a system administrator can view all documents in the queue, AIF history, or exceptions list in any partition. The forms that display these lists now have a field that shows the partition key for each document.
• Common batch framework – Like AIF, the batch processing framework is a shared subsystem. One batch server is shared across partitions. However, each batch job is associated with a specific partition. The batch server executes batch jobs in the context of the correct partition. To view batch jobs or their history, you must log on to the partition that the batch jobs are associated with.
• Separate application data – Access to application data is controlled by a combination of the partition ID and the user's role and permissions. The Microsoft Dynamics AX client does not let users view unified data across partitions. Microsoft Dynamics AX does not provide a query mechanism to retrieve and combine data from multiple partitions.
• Separate organizational hierarchies – Each partition contains its own organizational hierarchy, which includes one or more legal entities. Like a new deployment of Microsoft Dynamics AX, each partition that is created contains the DAT company as a default legal entity. System administrators can add legal entities to each partition. Legal entities are never shared between partitions, even if the legal entities have the same name.
• Separate user configurations – Each partition contains its own list of authorized users. The system administrator who created the partition is automatically created as a user who has the system administrator role in the new partition. After a system administrator logs on to a partition, he or she can add authorized users to the partition.
  A user can be authorized to access data in more than one partition. However, the user must be created and managed separately in each partition. This user must use a separate client configuration to start a separate client session for each partition. Each user is associated with a default partition. This default partition can be changed by a system administrator. A user who logs on to Microsoft Dynamics AX by using a default client configuration is logged on to the user's default partition.
  The Microsoft Dynamics AX client application displays the partition key for the current session in the title bar of the main window.
  User roles are assigned for each partition.

In Microsoft Dynamics AX 2012 there are many types of data elements such as the chart of accounts, products, party, exchange rates and more, which are shared across all legal entities in an AX environment. For some organizations, data needs to have a clear separation between entities whether for security, differences in shared data or other unique requirements. This is when Partitioning comes in to play. Available in Microsoft Dynamics AX R2 and higher, Partitioning is designed to provide a logical separation of data between legal entities to isolate the data.

Before Partitioning is configured, Microsoft Dynamics AX data would be structured as per the diagram in Figure 1. One single partition would exist that would contain data for all corporate divisions.

In the case of a company within the AX environment requiring complete isolation of their data they would use Partitioning. For example an organization with a division that does not use the same product list, or a division that should not share their contact list or employee list.

To partition data, follow these steps:

IMPORTANT NOTE: Once a data partition is created it cannot be deleted.

1. Navigate to: System administration > Setup > Partitions
2. Click ADD and create the required partition(s)

3. Outside of AX create a new shortcut or menu item to enter Microsoft Dynamics AX. Using your existing desktop shortcut, copy and paste the shortcut but rename with the partition key for easier identification.

4. Right click on the newly created icon, choose Properties. Modify the Target path by appending the following after AX32.exe: “-partition={partition name}”. In our case, our partition name is ‘PS’. This is what our shortcut looks like:

        "C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exe" -partition=ps

After the partition is in place our data will now be logically separated as shown in Figure 2. Company 3 data is now isolated while Companies 1 and 2 are still sharing the original partition. Partitioning utilizes the same single database. Microsoft Dynamics AX is able to distinguish the data partitions using a key that is on shared data records.

Partitioning is not a requirement for all companies and should only be an option when the need to separate data exists. Remember a partition cannot be deleted, so review your requirements thoroughly before proceeding. The benefits of maintaining a single partition with data shared among legal entities provides management efficiencies for your IT department, creates a single party contact list for your marketing and communications, allows for intercompany transactions and shared product lists across the organization. Consider these factors should you look to move to a partitioned data set.
=========================================================================

Benefits

• If an organization runs multiple business entities that shares the same business application, can Share IT infrastructure across independent businesses.
• While sharing the IT infra, Organization achieves strict data isolation across businesses.
• This reduces Total cost of ownership (TCO) for managing IT infrastructure.

Data partition basics

Below are some basic features of data partitions. The implementor should understand these before designing/preparing for data partitions.

Understanding Partition and Legal entity

• Metadata (Business application)  is common across all partitions.
• Enabling/disabling configuration key affects all partitions.
• Named user licenses are calculated per principal, i.e. AD user, regardless of the number of partitions they have access to.
• A default partition named Initial is always created for each AX instance.
• DAT company exists in every partition. It is automatically created when a new partition is created.
• A company with same name can exist in multiple partitions. Intercompany doesn’t work across partitions
• AX users are defined per partition.
  • With in a partition a principal can be associated with one AX user.
  • Each user has a “default” partition associated with them, however a user can be authorized to access data in more than one partition.
  • AX user IDs other than admin and Guest are unique across partitions.
  • The principal that creates a new partition automatically becomes the admin user in the partition
  • Each partition contains at least one company or legal entity. A legal entity occurs in only one partition. When you create a legal entity, the system assigns it to the current partition. The legal entity can never be moved to another partition. However, its data can be exported from the partition and then imported to another company in another partition.
  

  Data Partition Structure
  • User to role assignment is per partition.
  • Organizations (e.g. departments, cost centers, etc.)  and hierarchies are defined within a partition.
  
  • User-Role-Organization assignment is per-partition.
  • Intended partition is specified at session creation time via client configuration.
  • If no partition is specified then the user’s default partition is chosen
•  In a partitioned system, Services and Application Integration Framework (AIF) is a shared subsystem. To guarantee that incoming requests are correctly isolated, you can restrict an inbound integration port to a particular partition. Additionally, you can specify a target partition for an incoming request by including the partition key in an XML element in the header of the document. Similarly, outbound responses indicate the source partition for the response data by including the partition key in the header.   Because AIF uses a single gateway queue, a system administrator can view all documents in the queue, AIF history, or exceptions list in any partition. The forms that display these lists now have a field that shows the partition key for each document. for more info click
• Like AIF, the batch processing framework is a shared subsystem. One batch server is shared across partitions. However, each batch job is associated with a specific partition. The batch server executes batch jobs in the context of the correct partition. To view batch jobs or their history, you must log on to the partition that the batch jobs are associated with.
• Separate organizational hierarchies – Each partition contains its own organizational hierarchy, which includes one or more legal entities. Like a new deployment of Microsoft Dynamics AX, each partition that is created contains the DAT company as a default legal entity. System administrators can add legal entities to each partition. Legal entities are never shared between partitions, even if the legal entities have the same name.

Data partitioning architecture

Recommendation

Implementation choice must be made carefully as the companies between two partitions cannot be merged and Intercompany features cannot be used. The only option is to use Data migration tool kit for data export import between partitions and AIF for inter company operations.

How it is implemented Technically?

1. A partition Table is introduced. that keeps the list of partitions in the system.
2. The partition key  is applied in all contexts as data area id used to apply, like all queries, forms etc.
3. Every table in the system now has one more field named partition, that is nothing but the record id of the record created in the step one.
4. 
5. Cross company query doesn’t work across paritions
6. Global function getcurrentpartitionrecid() introduced.