AX 2012 R2 and PowerView - Part I

Well here we find ourselves well into spring and I must say it's a cold one thus far. I'm for sure ready for long, warm sunny days and all the fun that comes with it. That being said, and my battle with the norovirus behind me I wanted to start my writings back to you with a focus around Dynamics AX 2012 & PowerView.


PowerView Design Surface

Without a doubt this topic deserves a good bit of coverage as this truly is a powerful, personal BI enabling technology. Let me states now, as I have in the past, BI is not about a tool. True business insights & intelligence is about owning your data and turning into a true asset. That stated, we must understand the tools that help us yield forth value added insights. Enter now, the focus on Microsoft PowerView and how's it's fired, used and managed within the context of Microsoft Dynamics AX 2012 R2.

For starters, let me give you a great reference resource. It's the official home page for PowerView.: Microsoft Business Intelligence - PowerView.



I think without a doubt, the above referenced resource page has some really interesting demos that showcase the power or PowerView. Further there are plenty of resources on the web, that can take one through the design and usage of PowerView. Before getting into some real examples of how this can be used, I think it's very important to understand how PowerView is targeted to be fired and consume data from Dynamics AX 2012 R2. Therefore, the goal of this post is to do just that. Infer the knowledge of how PowerView works with Dynamics AX, and how it's fired out-of-the-box. After having this knowledge we can then proceed together down a path of examples for how this can be used, and further extended.



The first thing to learn is how to fire PowerView from within Dynamics AX 2012 R2. Throughout different sections of the product, you will find a new icon as pictured above called "Analyze Data - Reporting". This button, is tied to specific action menu items, depending on what focused module of Dynamics AX you happen to be in. As-is, there are three focuses for such PowerView artifact creation, based on these action menu items of.: CreatePowerViewReport *CustCube, *LedgerCube, *VendCube.



Each of these action menu items points to a single class within the AOT named PowerViewReporting. This class takes specific parameters for which targeted OLAP cube should be used for creating ad-hoc or personal BI artifacts.



Looking into the main method of the PowerViewReporting class, we find that this further calls into another class, passing in the datasource of focus. The cube for the specific area of Dynamics AX that you happen to be in. This other class is the SrsReportHelper class. It has a brand new method called: getPowerViewDataSourceUrlClient().



Within the call of this method, exists a new managed code element understood as: Microsoft.Dynamics.Framework.Portal.Deployment.PowerViewDeploymentHelper

Now we understand when we are on the Purchase Orders form, and we see the Analyze Data icon that the data we are about to tackle is based on the VendCube. The VendCube field list of measures & dimensions is then what you see rendered in the right hand screen of the PowerView design space.


VendCube Field List in PowerView

Well that's all for this first post around PowerView. I hope this helps the understanding of this great new tool and how it interacts with Dynamics AX 2012 R2 out-of-the-box. Next post, I will create a brand new cube with Dynamics AX 2012 R2, and show you how to extend the PowerView framework for Dynamics AX to target that cube for Analysis. Thanks for reading, and check back soon! Til Next Time!
Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

AX 2012 - BI Artifacts & Source Control

I hope everyone is doing well today, and your working on exciting Dynamics AX projects. There is for sure a lot going on within the Ecosystem as a whole. New partner highlights across the board, and interest in Microsoft Dynamics AX has never been Higher!. With that, as you have seen in my past post, I like to talk about value and how value is best derived from investing in AX 2012. With that, one of the hot topics that I see day in, and day out as a well under-served part of the Dynamics Ecosystem is around true Business Intelligence .

Now being that I'm a true solutions architect, one of the focuses around BI, is the management, and processes that help us create such needed artifacts likes cubes, KPI's, AX-SSRS reports, etc. That's what prompted me to write up, for example the post on processing cubes error for standard edt. SQL Server 2012 Analysis Services. Further, you've seen me post about future topics as well, with the BI Semantic Model (BISM) post.



With this post, I wanted to continue my dive into value added topics, around AX 2012 & BI. That brings us to today's topic, around Source Control for BI Artifacts.



When thinking in terms of BI Artifacts that are created, that need version control, we are speaking about: Classes for DataContracts & RDP Framework, Query Elements, VS Report Model Projects, Perspectives, Views & Analysis Services Projects. Thinking in terms of Version Control or better Application Lifecycle Management (ALM), there are some great resources on the web. One for sure you need to book mark, is Joris information on the topic, located here.: DAX Musings: ALF | TFS Resource page.

With that resource in hand, and going back to what we need source control for, lets look at the obvious. Please do note, at this time, the article assumes that you have TFS being used with your AX 2012 instance. To continue, with the obvious, things like Classes, Query Elements, Views and Perspectives, most people are use to understanding how this works. These are added to source control by someone, and then can be checked in and out. This means, that understanding the base BI artifacts, when TFS is used, then it's controlled as such.



What about the other artifacts? For example Perspectives build cubes, and Perspectives are made of views and tables. These then are the basis for the Analysis Services Project which is what builds the cubes for AX 2012. This project can be updated, or configured through the Analysis Services Wizard of Ax 2012. Understanding that, what about this project? Well This project, just like the VS Report Model Projects, or even C# Projects. All of these are controlled with the same rules for Models, Layers and Version Control from the AOT as any other object or element in the AOT.

This is important to keep in mind, when thinking about using Source Control outside of AX 2012, or along side of it. The choice of where the source control is being implemented really, is the focus and point. Meaning, that for anything managed by AX 2012 It's best to allow the AOT / AX to enable source control on any objects it has. Everything else, that truly lives outside of AX, should be managed through Visual Studio.

Well that's all I have time for today, check back soon as more to come including a book review, some spotlight post, more into the real Semantics of BI and what it means for AX 2012, as well as a lot-lot more! Till Next!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"