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!