Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Wednesday, April 25, 2012

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 @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , , , , , , ,

3 Comments:

Anonymous ksp said...

Hi, thanks for the info, but i habe a question: You write that even c#-Projects can be added to TFS source control, but i don't really understand how that should be used.
It's true that i can add c#-Projects to version control via the AOT like any other object, but when i syncronize another system afterwords i get syncronization errors, because AX puts the *.cs files under version control and they can't be (re-)imported without the detour via Visual Studio. Or at least that's how i understood the procedure.
That's a major problem we have ATM in our project because some of the business logic of the SSRS Reports is located in c#-Projects and we need to customize some of them.
Any ideas how Microsoft thinks that should be done?
Regards, ksp

11:40 AM  
Anonymous Cindy said...

Nice post which 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. Thanks a lot for posting this article.

8:32 AM  
Anonymous Natalie said...

Nice post which 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. Thanks a lot for posting this article.

7:08 AM  

Post a Comment

<< Home


Copyright 2005-2011, J. Brandon George - All rights Reserved