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 11, 2012

AX 2012 - Query Elements, a reusable API




I hope everyone is doing well, as we launch full on into our Dynamics Spring! I love it when the time changes here in America, and we are able to enjoy longer hours in the sun. I'm a spring-summer-fall guy, which really means I love being out in the sun. With that said, I wanted to talk with you today, about Query Element Objects, within the AOT for Microsoft Dynamics AX 2012.



Query node objects, in AX 2012 has received some major overhauls, with giving us the ability to now offer having use, for example, and more complex outer joins, as well as non-exist joins. These kinds of improvements, along with others helps lend themselves to the use of Query Elements from the AOT for a multiple use scenario's. This is where the concept of the Query Element, being slated as a reusable API comes into play. Before we continue forward with that concept, there are some really nice resources from MSDN on this topic I think it's important to share. Mostly, how to create and make use of query elements.: How to: Create Queries by Using the AOT [AX 2012].

With that noted, lets take a look at where all queries are used within AX 2012 and see for ourselves what makes a query element, truly a reusable API. First up, we have the obvious, in which I've talked to in the past on this blog. Specifically I'm making reference to using a query element as the source of a dataset for modeled approach to an AX-SSRS report.



In talking in terms of reporting & BI, having the query as the basis for a reports dataset is the desired, "modeled solution" for report design. In this, as I point out in the past post, the query is the source for the data of the report, and the control of the report is the ranges that one setups from the query.

Moving right along with this concept, we also have seen - in past articles, where query objects can be used as the source of OData feeds for PowerPivot based reports.



In this, we can create a query element in the AOT, that we reference and make use of from the Document Data Sources form that we find under Document Management for an instance of AX 2012. In doing this, we are then able to enable, and publish this query as an OData feed, through the out-of-the-box ODataQueryService. Doing this, we are able to apply and make use of security from within the context of AX, yet offer the flexibility and power, that a tool like Microsoft PowerPivot brings to users and it's nature for creating ad-hoc reports. I've seen in the past, partners training users, even on AX 2012 - to create views that go directly to the database. There is no reason for this, and you should never do such. Instead, make the correct choice with the use of query elements and consume those as your OData feeds for PowerPivot needs.



As we continue to move on with this discover process of what really makes a query element a reusable API, lets look at something else we have talked to in the past on this blog. That is the creation and use of Document Services for AX 2012.



As shown in the above image, referenced from the above post, the use of a query as the basis and start of a document service is critical to understand. There are some key point specific's around certain settings for query elements that are used as the basis for document services, however it does start with the design or use of a query element from within the AOT. The image above is showing the context menu, when you right click on a query element, and what kicks off the AIF Document Service Wizard

The above are just a few examples, in which we can easily speak to and say that query elements truly are a reusable API for AX 2012. Some other area's include: Workflow design, Basis for an RDP class (ie: CustAgingReport), View datasources that themselves are sources for perspectives and cubes, modeling security with XDS, ListPage designs, Cue's, and more!

With the power of Query elements in AX 2012, when you start to look at what all they are the basis of, you should really ask yourself when doing in design work - Can a Query Element be used here? If so, does one already exist, or should I create a new query element? How can it be used throughout my instance of AX 2012? It's a true statement, in that Query Elements are reusable API's for AX 2012, and understanding there value, use cases, and design aspects will help you get the most out of your AX 2012 investment.

That's all for this post, I hope you have a great productive wed, and check back soon as more to come! Till Next Time!
Follow Me @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

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

Wednesday, February 22, 2012

AX 2012 - Report Layout and Style Templates





In a recent post, I talked about AX 2012 and Diving into BI Analytics as a starting point back into a series of post around The BI Story for AX 2012. The point of this series of post, is to drive understanding of the BI options in Dynamics AX, and therefore driving value around making the most use out of your investment.



To help continue this series, I will start to dive into more and more specifics around AX 2012 & BI, specifically around creating BI artifacts with the out-of-the-box tools.

To that end, recently I was working with a long time client, and one of the things that was brought up was the use of Report Templates, in reference to how these could be used in Microsoft Dynamics AX MorphX reports in the past.



Just to be clear on this point, you have the ability to have Layout Templates as well as Style Templates. As I've done in the past with such articles, I would like to start this deeper dive, with referencing what Microsoft has provided for us on MDSN. As I've also stated in the past, Microsoft has been doing a great job with the release of AX 2012 around documentation and this topic is covered with some nice resources.

The following is that resource list:

Now with these resources in hand, we have the ability to start making use of layout & style templates, understand the value, and create our very own if so desired.

To a point of use for these, for example, say in an Auto Design scenario you would like to have the Company Name, Page information, etc on the header of your auto design reports. This was very common need with MorphX reports. Well in order to do this, you could follow the how to on applying Layout & Style templates, and use that to apply the ReportLayoutStyleTemplate which has said information as part of the header.

Further, you can create your own custom layout and style templates that might contain specific design elements, or parts of Header information that help create a specific an uniformed rendering of reports that can go very far with the user base.

The point to be taking, is it's still possible to achieve this same need as it was in AX MorphX reports, with the new reporting model of AX SSRS.

With that, I will end this post and thought process for now. I hope that as we continue down this path, you will see more and more the flexibility and depth of Reporting and BI artifact creation that exists out-of-the-box for AX 2012. Till Next Time!

Follow Me @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

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


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