Beyond Dynamics AX with Business Intelligence

I hope everyone is having a blessed day, and you find yourself productive in our Dynamics filled world. May is once again here, and that means we tilt ever so closer towards our solar systems star - in the northern hemisphere that is. That also means planning for summer time vacation, baseball / softball, as well as an assortment of water related activities. The march towards summer begins, and that means the world around us continues to come alive.

With spring in full force, I thought it was time to talk about the needed topic of beyond Dynamics AX with Business Intelligence. Lets face it, more and more projects are being sold & implemented well, that has Microsoft Dynamics AX only acting as an operational ERP element. It's one spoke in the total solution for larger companies. When you have this reality, Dynamics AX is no longer the single data mart from which analytic's & insights are derived from.



As we see from the above image, when Dynamics AX is the data mart in which such BI artifacts solely are crafted around, then you have a very compelling story in which a companies total reporting needs can be told by. This is Sunrise's standard offering for business intelligence needs. That is: Office+SharePoint+SQL Server.

Are focus is expanded however, when the needs of the customer expand. To help facilitate the understanding of when and where this might be the case, let's start by listing a high level set of topics, that in turn will be used to guide into greater business insights for customers. Further, how each of these topics would drive to a more complete or total BI story that is crafted for a customer. All the while, keeping in mind that the tool is the last thing you focus on for a real BI project.

• Dynamics AX is a spoke, not the hub - Here we have a total solution scenario, where Dynamics AX is an operational ERP element in a customers total solution. This means 2:n possible line-of-business applications that complete an end-to-end solution for a customer. When this is the case, items like real data warehouses, ETL, Master Data Management across the systems, and more must come into the picture. This further means that what tools are best for achieving the ultimate end goal might need to be extended beyond the Office+SharePoint+SQL Server.
• Security & Exposure beyond the Dynamics AX walls - Here we have a need for an organization that has reporting requirements. These reporting requirements however dictate that there are business insights needed for employees that will not have, nor should not have access to Dynamics AX at all. When this is true, again, then we have directive for something that extends beyond the walled garden of Dynamics AX.
• Mobile BI across a multitude of platforms - There is a very compelling story that can be told with the BI stack of Office+SharePoint+SQL Server. Mobile is very much apart of this, specifically with the release of Office 2013 and SharePoint 2013. However when you want a mobile BI platform, that needs to reach beyond the Microsoft world, in a more native way, then extending beyond the BI stack that comes with Dynamics AX is needed.
• Abstraction - This last point is more focused around that true executive information system, or dashboard. With the continued improvements being made for Dynamics AX, and those improvements driving more technology and model churn, the need for abstracting away the C & B level executives from such churn is a valid one. Having something that extends beyond the Dynamics AX BI stack, can help abstract out the executive's and their analytical needs. Reality is, these might change some, but not at the rate in which technology, and further Dynamics AX is changing.

Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.

The above, by far is not a final list but something that hopefully has you thinking in terms of a more complete BI solution. There is hardly ever any truth in we bought (insert product name) now we have BI! Real business intelligence for customers is always about the data first, then reporting need second, and finally the product or products that help delivery on said need last. Take into consideration any of the above points, and you have a more larger requirement - where selecting specific tools first could halt the needed progression that is demanded by the organization.

Over the next several weeks, I will continue to expand upon each of the above topics, and others in how I feel these are best addressed. This includes both the stack that comes with Dynamics AX, and beyond that for a total solution offering.



That's all for this post, I hope you have enjoyed it and your excited to hear more. One final note, I would like to say that I'm honored to have been listed once again this year in the DynamicsWorld Top 100 list. Top 25 again this year! Honestly the amount of work that some of the people put into the ecosystem, that I can be included with amazes me. This community as a whole has grown leaps and bounds over the past 3 years. I can't say enough of how honored I am to be included as part of it. Til Next Time!


Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.


Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

The Cube behind the Power View - Part II - Create, Deploy & Process

I hope everyone is having a blessed, Dynamics filled week! Hard to believe that we are well into April of 2013. I do love when the days get longer, the sun is closer, and there is plenty of vitamin D to be absorbed. With this, I wanted to continue the series that was started yesterday, focusing on 'The Cube behind the Power View'. In yesterday's post, Part I - Perspective, we covered the in's and out's of modeling a cube from a perspective.



Having gone through the previous post, you should have a perspective that is ready for targeting a brand new Analysis Services project. After generating the analysis services project in the AOT, we will further create, deploy & process our newly generated cube. Lets get's started then!

A - Create
Our next step is to make use of the 'SQL Server Analysis Services Project Wizard.' This is located within a development work space for AX 2012 R2. You then click on the Tools menu option, Business Intelligence (BI) Tools & finally launch the wizard. Shown in the below image is that exact path.



In launching the Analysis Services Wizard, you should see a screen shot similar to what we see in the below image.



Clicking on the next button will take you to the first prompt where we start to configure this session of the Analysis Services Wizard.



You will notice in the above screen shot, that I have selected the create option. Further I've supplied what the project should be called. The goal is to create a separate SSAS database, and cube within. This leaves in tact the out-of-the-box cube database and cube elements. Further you will notice the name I've given this new project. It has a prefix, which is recommended being this will live in the AOT. Since I work for Sunrise Technologies, I use the prefix of "sun".

Clicking next after filling in the prompt for the create option, will lead us to the below image.



You will notice in the above screen shot, that we have selected the Sales Data perspective. This is listed by label, and what the cube will be named. Moving right along from here, clicking next will bring us to the next image, shown below.



The above shows dimension possibilities from the Shared Dimensions perspective. This is not something we care about in our current targeted cube, and therefore we will leave out for now. Clicking next on this screen, with leaving everything left blank, should take you to the following.



What you see with the above, is the date dimensions in which we can select and work with. These are generated and created within Dynamics AX. We can modify these, and further create different one's, like a fiscal date set. Keep in mind that based on any dimension we selected which has a Date or UtcDateTime data type, will be crossed with these date dimensions. Dynamics AX will automatically generate this for yu via the modeling of the perspective that you created earlier. Selecting date above, and clicking next, should take you to the following screen.



The above image shows the language selection for the cube that is being targeted. Based on the languages you have setup within Dynamics AX, such can be taking advantage of here. Translations exist within cubes as they do within Dynamics AX. For our current target we are selecting just U.S. based English. Doing so, and clicking next will take you to the following.



You will see in the above image we are now generating our project. This basically ends the create portion of this post, as the Analysis Service project is now generated and living within the AOT.

B - Deploy
Now that we have created our analysis service project, we will continue using the wizard to finish things out. With that, we should see a screen shot similar to the below.



Clicking on next from the progress update, should take us to the following screen.



You will notice I'm saving the actual project to the AOT, under the name sunSalesAnalysis. This allows for again a separate project not related to the out-of-the-box cubes. Clicking next, after filling this prompt out as shown above, will take me to the following.



Here is where we actually select which cube databases we want to deploy. Since the concept of partitions came into being with R2, cubes take this into consideration. With the demo data set we have two partitions which are initial and ps. Since we only care about the inital partition and the legal entities contained therein, that is the target for deployment.

C - Process
I eject the process here, as it's an option we have selected int he above screen shot. Doing this means once the cube database is deployed it will process as well. Allowing us to remain within Dynamics AX the entire time, without having to jump into anything else to achieve this. Having made our above selections and clicking next, will take us through a series of progress updates.



Having reached the end of the deployment and processing, we should see an image similar to the one below.



In clicking next, that is it! We have created, deployed & finally processed our new cube. If there where multiple cubes targeted for this specific database, then those would have processed as well. Just to show that this processing took place, I quickly consumed the Sales Data cube from within SQL Server Data Tools. You can see this data, processed in the cube in the image below.



Now obvious there are plenty of things that can be done from this point. More advanced topics that could and should be covered. However there is only so much one should write at a given time, specifically for the type of medium you find yourself reading right now. I hope this helps you out, and further helps show how easy it is to create a cube. Finally, keep in mind the focus of extending power view within Dynamics AX. The combined knowledge should give you exactly what you need to really start taking advantage of the bull BI Semantic Model. Make sure to check back soon & often! Til Next Time!

Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

AX 2012 - From PowerPivot to Tabular Model

Today I wanted to continue the focus around some of the great options that now come as part of the stack offering for Microsoft Dynamics AX customers. This builds on the BI Semantic Model, going from the perspective of personal BI through to needed scale offered via organizational BI concepts.



What I'm speaking about specifically to you today, is the ability to target a PowerPivot BI Artifact and use it as the basis for creating a scalable, tabular model for SQL Server 2012. This knowledge, builds on that which I've covered in depth for Personal BI. This recently includes my last post Dynamics AX 2012 R2 - OData Improvements. Further, this is a prime example that I explained at a high level, with the post about Understanding the natural flow of the BI Semantic Model.



What we see above is the final outcome of a focus around PowerPivot, OData and a Dynamics AX Query Element. This query element brings together Sales data, for a specific set of customer groups. You can see in the following screen shot, the targeted query element from the AOT.



What would prompt you to take this PowerPivot artifact and move it along from the Personal, Team and into the Organizational BI area is the need to scale. That is the focus when we talk about organizational BI artifacts. These are BI needs that need to scale beyond the capability of what Personal & Team BI aspects can offer us. Having created this personal BI artifact in PowerPivot, we do not have to start from scratch. In fact, we can actually use the work completed in the design space of the PowerPivot workbook, to become the basis of an Analysis Service Tabular Model. This starts with SQL Server Data Tools, the replacement of BIDS for SQL Server 2012.



Having launched SSDT, we can navigate to creating a new project type of Analysis Services > Import from PowerPivot. This is what we see in the below screen shot.



In doing this action, we are then taking to a screen in which we must set a target work space database instance. For the sake of time, I'm doing all of this on an AX 2012 R2 demo image that you can download from Microsoft PartnerSource. This is why, as seen in the screen shot below, I'm targeting a localhost\Tabular instance of SSAS.



Having set our target work space server, we can then move forward with selecting a PowerPivot workbook. At this point there are some very specific security design considerations you need to keep in mind. Specifically when the target is a remote server vs. a local server. To find out more about this topic, please review the following resource.: Impersonation (SSAS Tabular). The goal of this article is to show off the concepts, in which such details will be discussed at length, in a later post.



What we see in the above screen shot, is the selection of our PowerPivot personal BI artifact that we created in earlier post. Having this selected, our tabular workspace server is able to read in the meta-data as well as data contained within the workbook. We can see this reflected in the following image.



Now that we have our tabular model created from the effort put forth in the creation of the personal BI artifact, we can begin modifying and creating needed elements to complete our scaled out BI needs. What important to keep in mind, is that any computing measures that where created in the PowerPivot artifact, are now in our tabular model. Further, the connection via an OData feed to our Query Element is in tact. You can see this from the screen shot below.



Having this understood, and not worrying about security design concerns at this point, we can proceed with deploying our tabular model to our workspace server for Analysis Services. That is what we see, in the outcome below.



With the above example, we can see how quickly the BI Semantic Model can easily take the efforts of a Personal BI design and turn that into a truly scalable state as a tabular model. This does require SQL Server 2012 as well as Dynamics AX 2012. With this however, we can now process our OData feed from within the Tabular model, and work off it for scalable artifacts that can help complete a companies BI story. Further this takes advantage of Dynamics AX, specifically with the use of Query Elements & Document Data Sources.

That's all for this post, but check back soon as I continue to dive further into taking full advantage of Dynamics AX, in helping put your companies data to work for you! I will continue to build on the concepts that I have been writing about, plus more including coverage of the upcoming Convergence 2013! Till 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!"