Data Partition in AX2012 R2

AX2012 R2
AX2012 R2 release extends the concept of sharing data and processes across legal entities to
streamline business processes and simplify the management of 'master data'.

AX2012 R2 release can support 36 country versions in one single installation of Dynamics
AX2012, international companies that are represented in many countries to increase IT and
operational efficiency. You can support all divisions in one installation, and it is the precondition to
share master data and efficiently manage 'master data'.

Data partitioning
Data Partitioning can provide efficiency gains, because installation and system data is still
shared.And data partitioning makes it possible to divide the application data into partitions of
organizations.You will be able to share application data and processes between organizations
within a partition, but not across .
Please see the below figure to understand the datapartitioning.


Please see the below installation types for AX2012R2-

Entities A single
installation
A single installation
of partitioning
Several installations
Application
data and
processes
Shared
between
legal entities
Shared between
legal entities within a
partition. Isolated
between legal
entities in different
partitions
Shared between legal
entities in the same
installation. Isolated
between installations
Master Data
Management
Global
master data
shared
between
legal entities
Global master data
shared between
legal entities within a
partition
Global master data
shared between legal
entities within the
installation. Isolated
between installations.
Meta data and Applies to all Applies to all entities Unique for each
adjustments entities installation
IT
infrastructure
Single Single More
Database Single Single More
A data partition helps sharing the Ax install base but not the data.
There can be companies with the same name in multiple partitions.

E.g Every partition will have the default company DAT.
- Intercompany doesnt work across partitions
Mircosoft Recommends: 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.
Technical:-
A new partition table is introduced with a Key and the Recid field
- There is a new field called PartitionRecid in everytable and as the dataareaid was by default applied to all
contexts(Forms
queries) the partition key will also be added.






Select * from custTable where data areaid = Dat and Partion key = Initial
- No cross company query on partitions are allowed like the cross company query
- You can know the current partition through getcurrentpartitionrecid() similar to curext()
- Batch servers work across partitions
- AIF works across partitions
New table property like SaveDataPerPartition has been introduced as like SaveDataPerCompany.
So for AIF, Batch tables Save data per partition is set to No,because those are shared across partitions.

Partitions in AX 2012 R2
With the announcement of MS Dynamics AX 2012 R2 release on December 1st, 2012, MS has given
a powerful feature in R2 called data partitions. Now in AX, there is a element above the company
called "Partition". Just like with every new AX installation there is a default company "DAT", now there
will also be a default partition called "Initial". This is really powerful feature as the companies now have
the leverage to use an installed AX instance across multiple deployment sites. Couple of features
associated with partitions are:
System data like batch, AIF, workflow is shared between partitions. This has been achieved
by introducing a new table property "SaveDataPerPartition" on these tables.
Business data like UoM, Address Book is shared among companies within a partition only. A
company can be associated with multiple partitions with the same name.
Users only belong to a particular partition.
Some drawbacks like intercompany does not work across partitions and companies across
partitions can not be merged are also there. Cross company queries might not work across
partitions.

Data Partitions with Dynamics Ax 2012 R2
Sign In
Share
RSS
24 Oct 2012 5:45 AM
- This is one of the key feature of Dynamics Ax 2012 R2.
- A data partion helps sharing the Ax install base but not the data
- This is a powerful feature that can help companies use the same installation. Takes
away the hassle of updating multiple
installation.
What it means functionally ?
- As we had company ids there is one level on top of it now, called the partition key.
- The partition key on the status bar indicates your active partition.
- System Data like AIF, Configuration, Batch are shared between the partitions. While
Application data like address book, Unit of
measure are shared only between the companies within each partitions
- Partition is identified through the client configuration.
- Like Default company there will be a default partition called the initial
- Users belong only to a particular partition
- There can be companies with the same name in multiple partitions.E.g Every
partition will have the default company DAT
- Intercompany doesnt work across partitions
- Mircosoft Recommends: 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 is it achieved Technically ?
- A new partition table is introduced with a Key and the Recid field
- There is a new field called PartitionRecid in everytable and as the dataareaid was by
default applied to all contexts(Forms
queries) the partition key will also be added. So a look in to the SQL trace would
transalate a Dax query as follows
Ax Query
Select * From CustTable
SQL (Before Partition)
Select * from custTable where dataareaid = Dat
SQL (After data partiion)
Select * from custTable where data areaid = Dat and Partion key = Initial
- No cross company query on partitions are allowed like the cross company query
- You can know the current partition through getcurrentpartitionrecid() similar to
curext()
- Batch servers work across partitions
- AIF works across partitions
- Programming Impact
BC.Net new parameter to mention the partition id
AIF Envelope includes partition id
Workflow created in the AOT as metadata is shared but while you have to create
workflow configuration in each partition.
- New table property like SaveDataPerPartition has been introduced like the
SaveDataPerCompany. So for AIF, Batch tables Save
data per partition is set to No

Microsoft Dynamics AX five-layer solution architecture
The Microsoft Dynamics AX five-layer solution architecture, logically partitions a
Microsoft Dynamics AX solution into an application platform layer, a foundation
application domain layer, a horizontal application domain layer, an industry application
domain layer, and a vertical application domain layer. The components in all architecture
layers are designed to meet Microsoft internationalization, localization, and security
standards, and all layers are built on the Microsoft technology platform.
Note: The layers in the Microsoft Dynamics AX five-layer architecture are different from
the model layers that are part of the Microsoft Dynamics AX customization framework
described later in this book. Architectural layers are logical partitions of an end-to-end
solution. Customization layers are physical partitions of application domain code.
The Microsoft Dynamics AX application platform and application domain components are
delivered on the Microsoft technology platform. This platform consists of the Windows
client, the Office suite of products, Windows Server, SQL Server, SSAS, SSRS,
SharePoint Server, the Microsoft ASP.NET web application framework, the .NET
Framework, and the Microsoft Visual Studio integrated development environment (IDE).

The following logical partitions are layered on top of the Microsoft technology
platform:
Layer 1: Application platform layer The application platform layer provides the system
frameworks and tools that support the development of scalable, customizable, and
extensible application domain components. This layer consists of the MorphX model-
based development environment, the X++ programming language, the Microsoft
Dynamics AX Windows client framework, the Enterprise Portal web application
framework, the AOS, and the application platform system framework. The architecture of
the components in the application platform
layer is described in the following section.
Layer 2: Foundation application domain layer The foundation application domain layer
consists of domain-specific reference models in addition to domain-specific resource
modeling, policy modeling, event documenting, and document processing frameworks
that are extended into organization administration and operational domains. Examples of
domain- specific reference models include the fiscal calendar, the operations calendar,
the language code, and the unit of measure reference models. Examples of domain-
specific resource models include the party model, the organization model, the operations
resource model, the product model, and the location model. The source document
framework and the accounting distribution and journalizing process frameworks are also
part of this layer. Chapter 19, Application frameworks, describes the conceptual design
of a number of the frameworks in this layer.
Layer 3: Horizontal application domain layer The horizontal application layer consists
of application domain workloads that integrate the financial resource, operations
resource, and human resource management processes that can be owned and
controlled by organizations.
Example workloads include the operations management workload, the supply chain
management workload, the supplier relationship management workload, the product
information management workload, the financial management workload, the customer
relationship management workload, and the human capital management workload. The
Microsoft Dynamics AX application can be extended with additional workloads. (The
workloads
that are part of the Microsoft Dynamics AX solution are beyond the scope of this book.)
Layer 4: Industry application domain The industry application layer consists of
application domain workloads that integrate the financial resource, operations resource,
and human resource management processes that are specific to organizations that
operate in particular industry sectors. Example industries include discrete manufacturing,
process manufacturing, distribution, retail, service, and public sector. Workloads in this
layer are customized to satisfy industry-specific requirements.
Layer 5: Vertical application domain The vertical application layer consists of
application domain workloads that integrate the financial resource, operations resource,
and human resource management processes that are specific to organizations that
operate in a particular vertical industry and to organizations that are subject to local
customs and regulations. Example vertical industries include beer and wine
manufacturing, automobile manufacturing,
government, and advertising professional services. Workloads in this layer are
customized to satisfy vertical industry and localization requirements.

Data partitioning architecture [AX 2012]
9 out of 9 rated this helpful - Rate this topic
Updated: June 21, 2012
Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2
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.
The following diagram illustrates the architecture for data partitioning.

Microsoft Dynamics AX data partitioning architecture
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 the
dataAreaId 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.
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.

To share or not to share Data Partitioning in Microsoft Dynamics AX 2012
R2
Rate This
5

AX PMG

AX PMG
6,477 Points 3 2 1
Recent Achievements
Blog Party Starter New Blog Commentator Blog Conversation Starter
View Profile
Sat, Oct 13 2012 1:23 AM
Comments 5
To share or to isolate data? Multi-divisional organizations now have the option
to do either in a single instance deployment
In my conversations with IT leaders in large organizations the journey to gain efficiency
through synergies between the divisions is a recurring topic. For that reason, multi-divisional
organizations welcomed the introduction of global data in Microsoft Dynamics AX 2012.
This R2 release extends the concept of sharing data and processes across legal entities to gain
business process efficiencies and simplify managing master data. In a recent blog post we
announced that the planned release of Microsoft Dynamics AX 2012 R2 will include 36
country-localizations in a single instance deployment. I see this as an opportunity for
organizations with operations in these countries to further increase IT and operational
efficiencies. Imagine my surprise when I encountered a CIO of holding company, who wanted
exactly the opposite. Why wasnt this CIO looking for what some might call the Holy Grail
for multi-divisional organizations, and does Microsoft Dynamics AX have a solution to
address this need?
What are the options and benefits of sharing data?
A single instance deployment provides the IT-side of the house with the opportunity to share
IT infrastructure between the legal entities; this could drive down costs of the deployment. In
addition to IT efficiencies, business operations benefit by sharing data and business processes
across legal entities. Business efficiencies and benefits include:
Management of vendors, customers and employees can be handled centrally, streamlining
these relationships on a global basis
Management of product information is centralized, including release management of the
products to the individual organizations
Intercompany business is automated for processes including sales, purchasing and the
corresponding financial transactions
Services, including central AR, AP and procurement, are shared
How does this work? What data is being shared and what is not? Organizations in a single
instance deployment use the same code base and system settings. These organizations have
shared application data including parties, products, and locations. The transaction data such as
sales orders or customer and vendor data is specific to each legal entity.
When is it beneficial to isolate data?
In certain, specific cases, organizations do not want to share data and processes between all
companies. But these organizations do want to achieve IT efficiencies by running on a shared
infrastructure. This scenario is typical in holding organizations with divisions that have little
in common, yet have a strong identity, and are supported by a central IT organization. Sharing
data between these divisions would not lead to efficiencies.
Data partitioning gives organizations the best of both worlds and is planned to
be available in R2!
In the planned R2 release, I am glad that organizations now have a choice with data
partitioning. Data partitioning helps IT leaders realize IT operational efficiencies because the
installation and system data are still being shared. And, data partitioning makes it possible to
divide application data into partitions of organizations. You will be able to share application
data and processes between organizations within a partition but not across partitions (see this
scenario illustrated in Figure 1).

Figure 1: Data Partitioning in Microsoft Dynamics AX 2012 R2
The table below illustrates the differences between three deployment alternatives: single
instance, single instance with data partitioning and multiple instances. In the last scenario, you
could use data partitioning as well.
Entities/deployment Single instance Single instance with
partitioning
Multiple instances
Application data
and processes
Shared across all
Legal Entities (LE)
Shared across LEs
within a partition.
Isolated across LEs in
separate partitions.
Shared across LEs
within an instance.
Completely isolated
across instances
Master data
management
Global master data
such as parties,
products is shared
across LEs
Global master data
such as parties,
products is shared
across LEs within a
partition
Global master data
such as parties,
products is shared
across LEs within an
instance. Completely
isolated across
instances.
Meta data and
customizations
Same across all legal
entities
Same across all legal
entities
Unique per instance
IT infrastructure Single Single Multiple
(includes servers,
middle tier)
Database Single Single Multiple
Table 1: Comparison between deployment alternatives
With the inclusion of data partitioning in Microsoft Dynamics AX we have enriched the
alternatives to model organizations real-life operations. That CIO and others like him, who
want flexibility in sharing and isolating data, will soon have a solution.
Interested seeing how Data Partitioning works in Microsoft Dynamics AX 2012 R2? Join us
at the Technical Conference in Bellevue, WA (USA) on Tuesday October 23
rd
, 2012. You can
find the session abstract here.
Pepijn Richter