Traditionally, BI solutions are implemented during the second or third phase of an Enterprise Resource Planning (ERP) implementation project. Needless to say, project fatigue sets in (and the budget gets exhausted), and subsequent phases are postponed or delayed. BI implementation is complex and involves the integration of many components. Also, the skill set required to implement a BI solution is distinctly different from the skill set required to implement an ERP system. Often, implementation of the BI solution involves engaging a different partner or consultants. All of these factors contribute to postponing the BI implementation.
Microsoft Dynamics AX 2012 simplifies the implementation of a BI solution, so that all Microsoft Dynamics AX 2012 partners and customers (regardless of whether they have access to BI specialists) can implement the prebuilt BI solution when they implement the ERP functionality.
In Microsoft Dynamics AX 2012, the default SQL Server Analysis Services (SSAS) project is a
first- class citizen of the Application Object Tree (AOT), as are other SSAS projects that you create in the AOT. This means that SSAS projects derive all of the benefits of being residents of AOT.
■ SSAS projects respect the layering concept. This means that an independent software vendor (ISV) or partner can distribute a customized version of an SSAS project that adds additional analytic components to the solution that is included in the SYS layer.
■ You can import and export SSAS projects to and from different environments as part of a model (by using models or .xpo files).
■ SSAS projects respect the version control capabilities offered by AOT-based artifacts.
When you deploy a project by using the SQL Server Analysis Services Project Wizard, which is new in Microsoft Dynamics AX 2012, the wizard selects the project in the highest layer for deployment.
If you examine the Visual Studio Projects node in the AOT, will see the default SSAS project that is included with Microsoft Dynamics AX 2012, as shown in Figure below. If you have any customizations at higher levels, they are also displayed.
Implementing the prebuilt BI solution consists of the following steps:
1. Implement the prerequisites.
2. Configure an SSAS server.
3. Deploy the cubes.
4. Process the cubes.
5. Provision users so that they can access the analytic data.
The following sections describe each step in further detail.
1- Implement the prerequisites
Before you implement the analytic components in the prebuilt BI solution, the following Microsoft Dynamics AX core components should be in place:
■ At least one AOS instance must be implemented.
■ The Microsoft Dynamics AX Windows client must be implemented, and the initialization checklist must be completed.
■ The Enterprise Portal web client must be configured.
If you are implementing the analytic components on a development or test instance, you might not implement a scale-out architecture. However, if you are implementing these components in a
production system, you may want to implement a redundancy or load balancing infrastructure. You need to configure the clustering or Network Load Balancing (NLB) solution before you implement the
analytic components.
2- Configure an SSAS server
This step configures a given SSAS server for the Microsoft Dynamics AX 2012 analytic components.
To do so, run the Configure Analysis Extensions step in the Microsoft Dynamics AX Setup wizard on the SSAS server that hosts Microsoft Dynamics AX 2012 cubes.
Running the configuration step should take you a few minutes. This function does the following:
■ Ensures that the SSAS server has all of the necessary prerequisites to host Microsoft Dynamics AX 2012 cubes.
■ Adds the Business Connector (BC) proxy user as an administrator of the SSAS server. This step is required to enable AXADOMD data extensions to operate without the use of Kerberos
constrained delegation.
■ Allows you to add a read-only user account to the Microsoft Dynamics AX 2012 database for processing cubes (you should specify a domain account whose password does not expire).
3- Deploy cubes
When you deploy cubes, Microsoft Dynamics AX generates and processes an OLAP database by using the metadata definition contained within the Analysis Services
project that is included with Microsoft Dynamics AX 2012. The result is an OLAP database that contains
Microsoft Dynamics AX cubes that are referenced by analytic reports and Role Centers.
In a Microsoft Dynamics AX 2012 R2 environment where there is only a single partition, the deployment step generates a single OLAP database that sources data from the Microsoft Dynamics
AX OLTP database. In a multiple-partition environment, the deployment step generates multiple OLAP databases that correspond to each partition. Figure below shows the deployment process both
in a single-partition and multiple-partition environment.
You use the SQL Server Analysis Services Project Wizard in the Microsoft Dynamics AX 2012 client to deploy, process, and in some instances, update cubes. To deploy the cubes, you must have the
right to deploy projects to the SSAS server. If you are also processing the cubes, you must have the right to read the Microsoft Dynamics AX 2012 OLTP database.
To start the SQL Server Analysis Services Project Wizard and deploy cubes, do the following:
1. In the Development Workspace, on the Tools menu, click Business Intelligence (BI) Tools > SQL Server Analysis Services Project Wizard.
2. On the Welcome page, click Next, and then select the Deploy option on the next page, as shown in Figure below
3. On the next page, you select an SSAS project to deploy—in this case the Dynamics AX project.
You can select a project in the AOT, as shown in Figure below, or you can select a project that is saved on a disk.
4. Next, you specify the SSAS server to deploy the project to, the SSAS database you want to use, and whether you want the project to be processed after deployment .
By default, the wizard uses the SSAS server that you configured earlier, but you can select any server to deploy the project to.
Deploy cubes in an environment with multiple partitions
As mentioned earlier, in a Microsoft Dynamics AX 2012 R2 environment with multiple partitions, the SQL Server Analysis Services Project Wizard generates an OLAP database for each partition. You can
use the wizard to select the partitions for which OLAP databases are created, as shown in Figure below
In this case, the SQL Server Analysis Services Project Wizard deploys the SSAS project to multiple OLAP databases. In each database, <partitionkey> is added as a suffix to the name of the OLAP
database.
Also, within each OLAP database, the data source view (DSV) is modified so that a partition filter is applied to all queries. Figure 10-8 shows the architecture of an environment with multiple partitions.
In all cases, the SSAS project in the AOT is partition-unaware, whereas the OLAP databases that are deployed are partition-specific. The SQL Server Analysis Services Project Wizard handles the step of
making sure that each OLAP database is wired to read data only from the corresponding partition in Microsoft Dynamics AX. This is a departure from the behavior of Microsoft Dynamics AX 2012. You
need to be aware of the following implications:
■ If you deploy Microsoft Dynamics AX SSAS projects by using Analysis Services tools, such as the Deployment Wizard or Business Intelligence Development Studio, the resulting OLAP
database is not partition-aware. In other words, cubes will aggregate data across partitions.
■ If you want to extend an SSAS project, always check out and modify the project in the AOT.
Do not customize a project associated with a specific partition by importing the project directly in Business Intelligence Development Studio. The Deploy function in the wizard will overwrite any partition-specific customizations that you have made directly on the server.
■ If you add custom query definitions in the DSV, the wizard adds where clauses to each select statement that restrict rows from other partitions.
4- Process cubes
The SQL Server Analysis Services Project Wizard lets you process deployed cubes directly. However, before processing, the wizard also runs through several prerequisite checks to ensure that cube
processing will not fail later. If you are using demo data, you can ignore these preprocessing warnings and have the wizard process the cubes.
While the project is being processed, the wizard displays a progress page. When processing is complete, click Next, and the wizard will show the completion screen.
5- Provision users in Microsoft Dynamics AX
After you deploy and process Microsoft Dynamics AX cubes, you must grant users permissions to access them. Provisioning users involves two activities:
■ Associate an appropriate user profile with each Microsoft Dynamics AX user.
■ Provide Microsoft Dynamics AX users with access to the OLAP database.
No comments:
Post a Comment