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!"

Review: "Dynamics AX Performance Optimization Guide"

I hope everyone is doing well this fine Friday! I wanted to spend time today, giving you my insights into a recently published book. That being the title of "Dynamics AX Performance Optimization Guide."



First let me say that the depth on the database & query optimization that is given within the pages of this book is worth the purchase. The focus around optimizing the database, for sure is the right focus. I would say, in the field, 80% of the performance issues I've ran across relate directly to a Dynamics AX instance SQL Server. Further, 60-70% of these performance issues identified, usually relate back to indexes. This could be anything from missing indexes, or not having indexes properly configured and covering for where clauses of select statements.

This book goes into good detail around specific settings, how to trace down resource bottlenecks for a Dynamics AX database and more. It goes into the most commonly used Dynamic Managed Views (DMVs). Further it makes a solid attempt actually on trying to address the virutalization side of performance as it relates to Dynamics AX. Wait types, addressing blocking and other such common performance issues are well addressed in this book.



Now that being stated, like all reviews it can't all be good. You can tell that both Martin Zhen & Daniel Liao have spent time in the trenches chasing down resource vampires. Still even with my recommendation of buying this book already, it lacks in several area's.

First, section 3.11 on page 102 titled "Offload Reporting (SSRS)" is a mere nod at the point of reporting and it's impact around performance. It's a single paragraph, that honestly should have just been left off. There is no depth to this point, and it adds little value to the reader wanting to understand this very important topic.

Finally, it lacks in the focus of performance making use of SQL Server 2012 can bring, and further with it's Always On technology. I would also like to have seen mention around InformationSource. I realize however you can't cover every topic around performance or the book would be about 10 times the size that it currently represents.

Final verdict on this book, 3 out of 5 stars. It's for sure got some really great nuggets of information. It's not just for administrator / DBA / consultant types either. It would benefit well that a Dynamics AX developer, read and understand the contents of this book. It would help them in being able to grasp what their code is doing to the actual underlying data layer from X++ code. Further, helping put forth the practice of using the trace parser when developing anything for Dynamics AX.

Well that is all for this review, many thanks to Martin Zhen & Daniel Liao for completing a very nice book, that helps address and give insight on the majority of where performance issues live - The Dynamics AX Database!Til Next Time!
Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

Happy Halloween - 2012!

Well here we are, finding ourselves on yet another All Hallows Eve! Happy Halloween everyone! For me intent means everything, and this is why Halloween is a fun time of year. As in the past, today's post is a recap of this months Freaky Tech Friday series. I really do enjoy trying to mix in the theme's of Halloween, with some value added focuses. It's good to try and be creative, and further help lighten the mood. We all work so hard in this Ecosystem, and so it's good to not take yourself so seriously, laugh, and enjoy the days we have been blessed with.

With that the following frighten list is the full representation of this year's Freaky Tech Friday's!

• Freaky Tech Friday - Tales from the Script
• Freaky Tech Friday - OData of Death
• Freaky Tech Friday - Invasion of the Conference Zombie's
• Freaky Tech Friday - Attack of the Resource Vampires

I do hope you have enjoyed this year's series of post. Further may you have fun with your family and friends today, no matter what you call it, or how you participate. Till Next Time!




Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

Freaky Tech Friday - Attack of the Resource Vampires

Welcome back Ghouls & Ghost, for this year's Shock-tober final fray into Freaky Tech Friday's! For those are still with us, you are the lucky souls who have traveled along the dark and twisted path. I end this years haunting season with a tale that strikes at the heart of many Microsoft Dynamics AX implementations. What I speak too is Attack of the Resource Vampires!



These resource sucking entities creep into existence, sometimes slowly, and sometimes right away in an instance of AX. They start with a focus around performance degrading as more and more processes are spun up for a customer. Those unknowing, slowly loose their ability to respond fast to process needs. Reports start to creep with on-set of early aging - as it would appear at least.

The major attack for these creepy creatures is typically a customers Microsoft SQL Server Database. This is the heart of performance, and like any good vampire, resource vampires always go for the heart. It's where the life blood flows...



Fear not though, young AX travelers as there is remedy for this lifeless state one might find their instance of AX in. There is hope for battling back the waves and waves of complaints from end users, as the processes & reports they so dearly need, dwindle into performance nightmares.

In order to fight back the unholy horde of resource sucking vampires, one must be armed with the right knowledge and correct tools. The sacred text tells us that the focus must first be on your SQL Server for getting the most out of your AX Investment from a performance perspective. There is a guide to this, once that applies to AX 2009 as well as AX 2012. You may find access to this guide, to the first step into performance enlightenment here.: Microsoft Dynamics AX 2009 White Paper: Planning Database Configuration. Keep in mind this applies, the same level of needs, no matter virtual or physical.

The idea is to attack the resource vampires foothold, with correct TempDB file settings, having create Disk I/O for Transaction Log commits, and enough RAM to load your entire DB - if possible. Further and beyond that is a focus on indexes. After having your SQL Server set in order, ready to fight, the next level the resource vampires move into is the indexes. They latch onto queries that execute and cause either full table scans or Clustered Index Scans. Both are costly and both can be addressed with equal levels of success. The focus here is around having the concept of "coverage indexes", that is an index that covers the where clause of your queries for the business logic and reports that execute them.

After this the resource vampires start to feel the pressure as your performance story starts to take a turn for the better, instead of one for the worse. Here is where those ugly resource sucking creatures dig in, and latch themselves onto poorly wrote code. We all have sinned in such ways, creating nested while selects that make multiple trips to the database.

The way out from this painful plight is to endure an analysis of the processes being reported as slow, and trace through the code that represents said processes. Find the resource vampires hiding in those nested while selects, or where clauses that have no coverage index. Then address them head on! Take them out, by changing the nested while selects to more complex joins, that reduce the result set being sent from the SQL Server to the end user.

There are other area's that one can look to totally eradicate the evil entities, but the above should be the majority focus for gaining ground and taking control of your instance of AX. Beyond the Server, Database, Indexes and code - sometimes the process has to be reconsidered for desired speed.

Well Ghouls & Ghost, take this warning about resource vampires to heart, and arm yourself's with the knowledge found above to fight back! Further you can download from InformationSource the IDMF tool, that helps with the on-going fight of battling these monters. Further a final warning on this, always stay vigilent in your efforts as performance tuning is a dynamic, on-going process. Let it slip, and before long your knee deep back into resource sucking vampires everywhere you turn!

I hop you have enjoyed this season's gruesome tales of Freaky Tech Friday's! I will leave you with what I looked like after have falling, and becoming a conference zombie. Be warned, the following picture shows the shadow of the man I once was, just before departing for Seattle.




Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

The value of a BI Product outside of Microsoft Dynamics AX 2012

With the a lot of focus this week around Business Intelligence, including being my entire session load, I keep getting asked the same question.: "Why are there so many BI products in the expo hall?" Another flavor of this is "Which BI Products are good candidates to look deeper into."



Before I give my public answer to this, let me first start with this. When you purchase and invest into Microsoft Dynamics AX 2012 you are also getting a BI Solution. It true then, when I state that BI is no longer a separate product or project. With the focus around the BI Semantic model, you can achieve Personal, Team & Organisational BI artifact creation without having any other tool.



You can create compelling executive dashboards, as well as other role tailored user experiences, enabled via SharePoint, Office & SQL Server technologies. This can be viewed without having to access the Rich Client of AX 2012 as well. So having a statement that a "CEO never uses AX" is not valid. Just because they don't make use of the rich client, to enter transactions, does not mean they do not use AX. In fact Role Centers should be front and center for the User Experience modeling for you AX investment.

With that said, there still is a valid reason for adding another BI enabling product to your total solution. First thing we have to focus on is the value such a product brings. If it brings relevant, pre-built, focused artifacts that fit into your business model and needs - then that is functional value. Further, just as important as the functional value, is the fact that whatever product this may be - it should never compete with the Microsoft Dynamics AX BI solution.

This means it should compliment the stack of SQL Server+SharePoint+Office. The artifacts it generates should be easily adding as web parts, so that the targeted Role Tailored user experiences are enabled - not replaced.

Microsoft is committed to the continued development and improvement of having this focus, Role Tailored User Experiences - as part of the out-of-the-box offering. So to answer in short: If the product compliments the stack that represent Dynamics AX, and add value for your company, then it's a possible good candidate for adding to your overall BI story your creating for your company.

That's all for this post. Make sure to join me at 4:00 PM Today, in room 604 for the round table discussion on "Understanding What is Available in Standard AX to Meet your BI and Reporting Needs." This will be an open discussion format, meant to engage the audience and have the audience guide and create the conversation.

Make sure to check back soon and often! Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

SQL Server - The heart of performance for Dynamics AX

With all the wonderful excitement surrounding the release of Microsoft Dynamics AX 2012, I thought it was time to take a step back and focus on something that can benefit those running on AX 2009, as well as AX 2012. What I'm talking about here is performance!

Before I get into some of the really good resources, to share with you on this topic, performance for SQL Server comes down to three area's: 1. Having enough RAM, 2. Right amount of Cores and 3. A great disk I/O Sub-system.

The last one, 3. A great disk I/O Sub-system, is usually always the issue when it comes to performance related problems in an AX solution. I can't stress this enough! Therefore, we have some good resources now, published by Microsoft, that everyone using AX, no matter what version, needs to understand. Make sure to work with your partner to get the following information, applied correctly to your instance of AX.

First off, we have the newly updated checklist / whitepaper for things to make sure you have set on your SQL Server. Microsoft Dynamics AX 2009 White Paper: Planning Database Configuration

Now don't be fooled you AX 2012-ers, this is also for you. The title has not been updated, but the content still applies. There is some great points in here, around RADI 1+0 over RAID 5, splitting your TempDB into as many physical files as you have Cores, etc. Read it, understand it, and make sure for your instance this is applied.

Next up, we have two trace flags. The first I covered last year, but still needs focus for this area. That is: Important SQL Server Change! - Parameter Sniffing and Query Plan Caching

Based on research by the Microsoft perf team, some great benefits have come from applying the above trace flag to a SQL Server. Next, we have a new trace flag, that works in conjunction with the TempDB split advice. This next trace flag, will make sure that all TempDB files grow at the same time, and with the same size increase. This too, has been proven, when you have your TempDB split out, to increase performance. Consider Enabling Trace Flag 1117 on Dynamics AX SQL Server

With this arming you as weapons, you can slay the nasty performance dragons, with ease! Of course, there is still nothing that can be done for bad Query design, or coding that forces huge resultsets, or many trips to the database. That must be addressed, and using the Trace Parser in AX 2012 is just a wonderful thing. Microsoft did a great job of making that tool, very useful, and very, very easy to use.

That's all for now, but check back soon as more to come. Till next time!

"Visit the Dynamics AX Community Page today!"

MSDW: Article on Self Service BI and Dynamics

Well as promised, I have a new article I wrote for MSDynamicsWorld.com, which can be found here.: Self Service BI - Where the Rubber Met the Road in 2010 for Microsoft Dynamics

In this article, I try to cover how we have arrived at where we are today, why it's important, a high level of technology involved, and a real aassement and hopefully push for the concept of self service BI.

I try to capture the Vision Microsoft has with self service BI, that goes beyond Dynamics itself. And the fact that Microsoft Dynamics AX, and those companies that invest in it, can make use of this vision.

I hope you enjoy it, and many thanks to Jason and the MSDynamicsWorld.com team for allowing me to write for them.

Check back soon as more to come!

"Visit the Dynamics AX Community Page today!"

Dynamics AX 2009 - SSRS Report Deployment Issue

If you have deployed the SSRS Report Lib.'s from Dynamics AX 2009 before, you might have ran into some timeout issues.

Even with deploying the reports one ReportLib at a time. And if you have not seen this yet, most likely you will.

An error message, sometimes with great detail will show up during the Reports Deployment process, and that will reference something similar to the following.

[ThreadAbortException: Thread was being aborted.]

The ThreadAbortException is the key for this error. Basically the thread trying to do the deploy is timing out writing to the Report Server.

Most likely you cause is related to the amount of langauge files / cultures that are trying to be deployed for the given ReportLib.

A simple change can be done to help fix this issue.



The following is the steps to do, that relate to the above table inside Dynamics AX.:
1) Open the AOT
2) Expand Data Dictionary > Tables > LanguageTable > Fields
3) Right click on the 'LabelFile' field and choose properties
4) Change the Visible property to 'Yes'
5) Save the change
6) Right click on the LanguageTable and choose Open
7) In the table, uncheck the Label file field for any languages that are not needed
8) Deploy the ReportLibs again that were having issues

This may not be the fix all the time, but most likely it will be. Also this can be used to help clean up the Report Manager. The initial deploy can deploy a lot of reports in languages you just don't care about. So you can remove those, or clear the entire Report Manager and then deploy with only the language files / Cultures that matter to you.

Well that's call for now, check back soon, as I have more post coming! See you then!




"Visit the Dynamics AX Community Page today!"

Getting the most out of Dynamics AX - Performance I

Alright, so last week I left you would a post about SSRS performance and scaling. This was to kind of wrap up the long series I have been doing on SSRS, which is a part of Dynamics AX BI and Reporting.

I will continue to write about reporting, and get into more pratical post about it. I wanted to also take the time to start a new series of post 'Getting the most out of Dynamics AX - Performance'.

In this series of post, what I would like to do is talk about performance tuning a Dynamics AX instance. I have thought about my approach to this and considered several different ways.

After looking at this from different ways, I want to address this topic in the manor in which this topic exists, Dynamically.

So in order to deliver a series of Dynamic post about performance tunning and scaling of a Dynamics AX instance, we have to look at this from a scenario approach.

Before we get into the first scenario though, it's important to understand what I mean by 'addess this topic in the manor in which this topic exists.'

What I mean by that statement is that performance tunning is not a single, clear, happyily wrapped box. It's a very Dynamic, instance specific on-going series of events that happens over the lifetime of an instance.

There are certain tools that are used in common across instances, like SQL Server Profiler and the Data Tunning Engine. Like using Query Plans to analyze use of fields, indices, etc. Also taking account events, and performance bench marks about CPU, Disk and Network I/O, RAM usage and need, etc. etc.

All of this must come into play, and you must be able to paint in your head with these tools, logs and so forth a picture of the performance your given Dynamics AX instance is experincing at the time.

So lets take a given scenario now and move from there:

You started out with a single, decent size SQL Server, two AOSes, and a few custom applications. Your concurrent users stayed at 50 or below. But now it's been over 1.5 years since you went live, a lot more custom reports and code has been done by your internal staff and you VAR. You also have 100+ concurrent users. MRP and other processes are running a long time, and custom code, processes and report ar taking extreme amounts of time to complete.

What to you do?

First you need to take and write down a list of all the processes, including reports and noting modules and times that are slowing down or taking a while to complete.

Then you need to take that information, and build yourself a plan of attack for what to look for.

While your building your plan of attack start your SQL Server Profiler Trace run, and make sure to get all the right columns and objects. Also make sure to start performance monitoring for CPU, RAM, Disk and Network on your SQL Server.

Let things run for around 4-8 hours depending on how serve, and how much data your Profiler trace is capturing. Take this captured information, along with your performance information and now you can load both up into profiler and look at the times reported slow downs are taking place.

Then attack the known processes and reports that have slowed down, and look at the queries that are executed as part of those. Use the Data Tunning Advisor on those queries, making sure correct indexes exist, noting ones that need to be created and creating them.

The idea, if you can tell from what I am saying so far is start with your SQL Server database. And look at the interaction between AOS / Dynamics AX and SQL Server Database. This means look at XppSQL, making sure that there is not a lot of unneeded while select looping statments. Making sure that there are covering indexes for your where clauses, and that you make use of joins.

Again, focus on the SQL Server, but that also means the code that is being executed from the AOS and the objects they are hitting or should be hitting (like missing indexes).

There is plenty of information on the web for how to use the SQL Server Profiler, how to read a Query plan, and make use of the DTA. Just keep in mind, with all the information, you have to read into to it. Don't just randomly accept the suggestions from the tools, like DTA. Investigate if what is being suggested is valid.

The other side to this SQL Server focus is looking at the possibility that you need to increase the RAM on the SQL Server, or maybe CPU power. The performance monitor will tell you this.

Alright, we will stay with this scenario and dive deeper. This is a good start to think about performance, and start getting your mind around what it takes to be able to address performance problems.

The mind set must be, it's a Dynamic set of on going events. This can't be a static thing that happens once. You don't have to deal with it everyday, but just because you get things running smooth and fast, does not mean that will last for 3-6 months. If you add a lot, change a lot, etc. then what ever is changing and adding needs to be investigated for best performance possible.

I will continue this series, and stick with the scenario later this week. To make this more Dynamic, if you have questions about getting the most out of your Dynamics AX instance, feel free to leave me a comment or email me through my profile. If you leave a comment, leave a way for me to contact you. Also if you wish the comment remain private, for email spam protection, etc. make sure to note as well in the comment and I will not publish the comment.

That's all for now, see you soon!



"Visit the Dynamics AX Community Page today!"

What is SQL Server BI Anyway? - Part II

Recently I post this article: 'What is SQL Server BI Anyway'

In that article I took and addressed, at a high level, what SQL Server BI is. What technologies from SQL Server can and are a part of a SQL Server BI Solution.

We answered with that post: 'So what is BI in terms of SQL Server?' We talked about the 3 main teachnologies that make this up: SSRS, SSAS & SSIS.

Now having that knowledge level of SQL Server BI Solution, and technologies, that make it up, we can move forward with the next question posed during that post.

Why is this important to understand?

The reason why this is most important to understand, for someone wanting to know about BI in terms of Dynamics AX, is that the BI offered in Dynamics AX is based on the technologies that SQL Server BI Solutions are made up of.

On top of that, the BI solutions inside Dynamics AX add another part to the dimension of reporting, with KPI offered up by PerformancePoint Services for SharePoint. Also SharePoint itself plays another critical role in offering these reports, Cube, KPI point, etc. via Role Centers, targeted to information worker roles inside the Dynamics AX instance.

Once you understand the BI solution from SQL Server point of view, then you can truly incorporate that into Dynamics AX 2009 (and beyond) with how those technologies, were meant to be used.

For example, SSRS reports are meant to be used within Dynamics AX, and Dynamics AX role centers for reports. There is a new AOT node inside Dynamics AX 2009 called Datasets. These Datasets are part of what enables datasources for SSRS reports to be built with.

You also have OLAP cubes, which Dynamics AX comes with standard cubes out of the box. These can be built, processed, and then viewed from within Dynamics AX. For analytics, this is where your data comes from. Looking at different dimensions of data, across a slice of time, customers, vendors, inventory, etc. etc.

Then PerformancePoint comes in, which will not be delivered by SharePoint, and be a part of SharePoint. This offers KPI and other Analytical dashboards, etc. for use with your transactional data.

This could also be made use, of say you make use of SSIS to build a data mining database or several that come into a Datawarehouse. Well in turn the KPI, Dashboards and reporting inside PerformancePoint Services for SharePoint could be ran not just on the Dynamics AX parts of the information, but on all the data in your Datawarehouse for cross sections of information from all the systems you make use of.

There is a white paper on Microsoft's site, that is right at a year old. Actually one year old this month, to be exact. Even though this is a year old white paper, this does a great job of giving even more details into what I am talking about here. The direct link to that whitepaper can be found here: Microsoft Dynamics AX - BI White Paper (2008)

The only thing you need to really make note of in this, is that PerformancePoint Services is now part of SharePoint. That knowledge was not known yet when this white paper was wrote.

Also feel free to take a look at the BI home page of Microsoft: Microsoft BI Home page.

With the knowledge that you have gained, or can gain from these several post that have been done, you can start to really understand BI from Microsoft's point of view. The solution, how they are used and built from SQL through Dynamcis AX.

One other thing that can come into play is Office. I did not mention that, but Excel is a favorite of everyone. That very much can play into your BI solution, where Excel can be the front end for deliverying BI reports and Analytical information to your information workers.

Well check back soon. More great post are coming out. If you have further questions about BI, getting BI working for you at the SQL or Dynamics AX level and want to get into more details. Feel free to contact the experts at Sunrise Technologies, Inc..

See you soon!




"Visit the Dynamics AX Community Page today!"

What is SQL Server BI anyway?

One of the major focuses for a lot of companies these days, even in these tough times, is BI. I have wrote about this recently, specifically with the move of PerformancePoint as being part of the SharePoint offerings.

Direct link to my last post here: Dynamics BI: BI for the Masses

That post gave a real broad picture into what BI will look like from an overall Microsoft BI strategy.

However, what is BI in terms of SQL Server? Why is this important to understand?

Well Dynamics, and therefore Dynamics AX, makes use of SQL Server to run on top of. And more and more SQL Server features are being tightly integrated and very much a part of Dynamics AX solution.

Since this is the case, it makes sense, that one needs to understand BI from SQL Server point of view. In doing this, then the incorporation can better be unnderstood, and the use of SQL Server BI solutions inside Dynamics AX can be better made use of.

So what is BI in terms of SQL Server?

BI for SQL Server is made up of several key technologies / terms. They are:

• SQL Server Reporting Services (SSRS).
  


• SQL Server Analysis Services (SSAS)
  - Multidimensional Data
  
  - Data Mining
  


• SQL Server Integration Services (SSIS)
  

These technologies make up what can be used to create BI solutions from SQL Server's point of view. Each of the above links goes to the home page found on MSDN, which contains to wonderful amounts of information about each of these topic area's.

SSRS can be used to create functional / procedural reports, where SSAS can be used to mine data, create predication based cubes, and other OLAP data dimensional cubes from transactional data. SSIS can be used to ETL, or Extract, Transform and Load data from many, many sources into a SQL Server staging or Datawarehouse that can then be used by SSRS and SSAS for reporting and knolwedge management about a businesses operations.

These are the key to understanding BI solutions from SQL Server's point of view, and answer the question What is BI in terms of SQL Server?

Next I will move forward with these topic area's for help in understanding them, and answer the next question in line: Why is this important to understand?

Check back soon, and see you later!




"Visit the Dynamics AX Community Page today!"