AX 2012 - Run Reports without hitting the Production DB

I hope everyone had blessed and wonderful holidays! I hope that you got plenty of time with family, friends and loved ones. I wanted to make sure and get one last post in, for the year 2011. Man, what a great year it has been, for the Dynamics Community and Ecosystem.

There are plenty of great wrap up post going on for 2011, as well as some predictive post as well. So, for my  800th post on this blog, and to close out 2011, I wanted to leave you all with a late Christmas gift, if you will. That is, as the title of this post suggest, a way to run AX 2012 Reports, without hitting the Production Database!




What we see in the above image, is the reporting architecture diagram from MSDN. This explains for us, the steps in which a typical, modeled driven solution report executes and fires from menu item execution, to rendering within the AX Rich client that is hosting the report viewer control.

Now lets take this understanding, along with how to setup multiple instances of SSRS on the same server role, and use this understanding to design a solution that will enable us to run all AX reporting from a Reporting Database. This includes both out-of-the-box and custom developed AX-SSRS Reports!.




Important: This approach has not been widely tested. This is not a solution from Microsoft, but something I've been thinking about how to achieve myself. Use this at your own risk, without any warranty or guarantee's.

So, in order to properly understand how we can do this, safely, and securely, and be able to maintain and support such a design, lets revisit a simple architecture that shows the server roles of how a standard AX-SSRS is setup. To help better understand this point, I've created the following diagram in Visio, that illustrates such a standard setup.




With the above, we see a simple architecture that shows off how SSRS and AX work together. It's via the application layer, and how the default .Net Business Connector configuration is used on the SSRS server role, to point SSRS to the right instance of AX.

The AX instance, has within it, the information that connects it to SSRS. This way when the menu item is fired, from the Rich Client, the AOS then uses the information contained within it's setup about Reporting Servers, to understand what SSRS instance to fire.

Since the default .Net Business Connector configuration for SSRS is pointing back to the same AX instance, when the SSRS instance is executing the reporting and firing the Data Extensionsto get to the correct Query object and therefore data, then in this standard approach, we are hitting the production database for your instance of AX. Of course, this could be any instance, we are saying production because the goal is to offload the resource needs of processing reports, away from your production database.

Now that we have the established understanding of how AX and SSRS works, along with the understanding of how we can actually place a specific config file, that will point SSRS to a specific instance of our choice of AX, lets move forward with our new design.

To help understand this concept, I've created the following diagram in Visio. This illustrates our new, beta>, reporting architecture configuration for enabling the execution of reports, against a replicated reporting database instance of AX 2012.




What we see here, is our simple reporting setup, and we are taking the information we have from setting up multiple instances of SSRS on the same server role, and pointing SSRS, when processing it's data needs, to interact with a different AOS, that is pointing to a log shipping replicated database of AX 2012. So, with this we still have the ability for all the out-of-the-box reports to be fired, as well as executed in batch, server side, EP, etc. but the actual hit against the production database does not take place. Instead the data is accessed from the replicated, new reporting database.

The critical keys that enable this concept are, (1) having the production instance of your AOS and Reporting Server setup, pointing to your SSRS server role within AX. (2) Changing what AOS the SSRS server hits for processing data, by deploying a custom configuration file.(3) Log Shipping is enabled at on the AX Production database, so that the AX Reporting Database is kept up to date with live data.

Keep in mind, with this setup, that all users interact with your production AOS. They never interact with the reporting instance AOS.

Now there is still a concept we have not addressed, and one that is critical to the success of this design. That is code promotion, or change management. Why does this matter? Well simply put, it's because the model store that represents the application now lives as a part of the production database. This then gets replicated when any changes take place.

If we are following the guidelines given to us by Microsoft, for promotion of code to a production instance of AX, via Model Store Files, then we should be fine with this solution. The reason this is the case, is because in doing this, we perform a full compile and full CIL compile within the QA / Test environment. in doing this, and then correctly draining all users from production and shutting down all AOS(es), within our instance. We can then safely move the entire Model Store File, into our production database for AX. Further, we can do the same to our log shipping, reporting database of AX as well.

This means, that before we did this action, we would need to turn off log shipping, while we are importing the model store files into production, and also the reporting database, which is a replica of production. After this was completed, and before enabling users the right to get back connected to AX, enable log shipping again, and your solution is back on-line, with any new changes.

Further to this point, if as part of that new reports were brought in as part of the model store file move, you would deploy the reports from the AX production instance. You would notdeploy them, via the reporting instance.

So, with the above information, we have a possible solution that could enable the use of Log Shipping, and some configuration tweaks, that would allow our Production Database to notbe affected by Reporting resource needs. Instead the reports are executed against a replicated database. This, in theory then, would work for all reports, including batch scheduled, server side and EP. I do welcome any feedback on this concept from the community. If you feel I'm overlooking something, or have failed to bring to light some critical point, please share and I will update this post.

Well that's it for me for this year. Thanks everyone for reading my blog, and supporting me in this effort. The reason I write is because of you, so thanks and have a blessed and safe Happy New Year! May 2012 be the best year for each and every one of you! Till next year!

Important: This approach has not been widely tested. This is not a solution from Microsoft, but something I've been thinking about how to achieve myself. Use this at your own risk, without any warranty or guarantee's.

Product Management with Microsoft Dynamics AX 2012 - Part IV

I hope everyone had a great long weekend, and that you got a lot of rest, and ready to tackle the short week ahead.

Today, I wanted to post the final part IV, of Product Management with Microsoft Dynamics AX 2012, from guest blogger Brad Edwards.


So far, Brad has really taking us into a good deep dive into some of the great new features around Microsoft Dynamics AX 2012 for Product Data Management (PDM) / Master Data Management (MDM) for products.

Brad wraps up his guest series, with taking us through intercompany implications, Product management for smaller organizations, as well as some closing thoughts. So, lets here what Brad has in store for us here.:


Intercompany implications

In previous versions, items must be carefully setup to be transacted via intercompany sales and purchase orders. With the release of AX 2012’s product hierarchy structure Released products are tied to one another via the Product number, eliminating the need for Company items setup, or External code setup to link items between companies.

Released products may still have different names in different companies. The Released product’s Item number may be changed by using the Record info > Rename function.

While this greatly reduces the time required to setup products for intercompany use, there are some potential drawbacks. As this is the only way to link Released products for intercompany use, it is no longer possible to link a Released product that is tracked by certain product dimensions in one company to a Released product that is not tracked by product dimensions in another company. 
For example, if company A sells t-shirts in red, green, and blue under item number TSHIRT with color dimensions Red, Green, and Blue, and company B buys the t-shirts under the item numbers TRED, TGREEN, and TBLUE, AX 2012 will not support this type of setup. So it is important to consider the implications of the new product structure on intercompany processing for the organization in question.

Product management for smaller organizations

Thus far, all of the information discussed has assumed the creation and management of products at the instance level, and the release of products to individual AX companies. However, this structure would provide a large amount of overhead in smaller, single company organizations. However, the capabilities exist for users to create Released products directly in the Released products form. The user may do so by clicking the New Product button in the ribbons section of the form:




As with products at the instance level, the user must still specify the Product number, Product type, and Product sub-type so that the product may be created in the Products table. This method of Released product creation is much more suitable for smaller organizations that wish to manage products in a simpler manner.

Technical note

Thus far, the entire article has focused on the functional changes to the way in which products are managed. However, for the slightly technical users, there are some important technical changes to note. AX 2012 now makes use of table inheritance. This means that fields that appear on the Products form may not actually be on the products table, but on a parent table that the products table extends. Without going into too great of detail, it is important that functional users reference screenshots rather than table and field names when completing functional specs, to eliminate confusion during development.

Closing note

While this article has merely scratched the surface, its intent is to provide a high-level overview of the changes to come in the area of Product management in Microsoft Dynamics AX 2012. It is important to note that the release from which this article was written was based on a public beta instance, and there is still the potential for changes to be made. I hope that you all have found this information useful. Enjoy working with AX2012!

Well I would like to thank Brad for taking us through Product Management review, for Microsoft Dynamics AX 2012. It's hard to work in writing to a already very busy schedule, and so thanks Brad!

From here, we will continue to dive into Microsoft Dynamics AX 2012, including diving deeper into some of the topics touched on in this series of blog post. For example taking and doing some real comparisons, with impact, for orgazations of varying sizes, and how PDM would be different for each. 

Product Management with Microsoft Dynamics AX 2012 - Part III

I hope everyone is doing well today, and that your thankful for having another day. I know I am! With that, we continue to dive into Product Management with expert Brad Edwards. 

Product variant release
Once product variants have been created at the instance level, they must be released to individual companies before transactions may be performed in the respective company.

Variants may be released from any of the Products forms (All, Distinct, Product masters), or from the Product variants form by clicking Release products in the ribbon section of the form. This launches the Release products form:


The user will first select the product variants that they wish to release. This is done in the Product variants section for Product master releases, and the Products grid for Distinct product releases. 
NOTE: before Product variants can be released for a Product master product, the Product master must be released. This is performed by checking Include product master in the Product variants section.
The user will then click Select companies.

Here, the user will select each of the companies to which the selected products are to be released, and click OK at the bottom of the form.

Any errors that occur may be viewed on the Open product releases form, accessible from Product information management > Common forms:

The user has the ability to view and infolog for each release issue. Once issues have been resolved, the products may be released directly from this form, or the open releases may be removed.
Released product management

Up to now, we have discussed management of products at the instance level. Users in all companies will see the same records in the Product master forms.

Once products have been released, they can be managed within the individual companies by going to Product information management > Common > Released products. This is the AX 2012 company specific item master. Here, the user will only see products and product variants that have been released to the AX company within which they are currently working. The form looks similar to the products form, but much more information can be stored for each Released product.


Much of the information that was setup at the Product level can also be setup at the Released product level. However, there are several fields which, if setup at the Product level, may NOT be changed at the Released product level. The most notable cases of this type of behavior are the Storage dimension group, and the Tracking dimension group.

As with the Product dimension groups, Storage and Tracking dimension groups specify which dimensions are active for the Released product.

As mentioned earlier in the article, Storage and Tracking dimension groups are not required at the Product level. However, if they are specified on the Product, they will default each Released product, and may NOT be changed at the company level. This means that if Storage dimension group were specified for our testProduct product such that site and warehouse were the only active dimensions, then these settings will apply to all companies in which the product will be used. If it desired to maintain different Storage or Tracking dimensions in different companies, then these fields should be setup for each Released product in their respective companies.

Before Released products can be transacted upon within a company, several additional fields must be setup for the Released product:

• Item model group
• Storage dimension group
• Tracking dimension group

Item model group may be specified by clicking Edit in the ribbons section of the form, and changing the value in the Administration section of the form:


The two dimension groups may be modified by clicking Dimension groups in the ribbons section of the form:


If these three fields are not setup, a user will receive an error if trying to create a transaction for the newly Released product. This, however, is a nice improvement from previous versions of AX, where it was necessary to specify this information upon creation of the product. In actuality, the product designer may have no insight as to:

• How the Released product should be costed
• Whether or not physical updates should be posted to the general ledger
• Which WMS strategy should be used
• How reservation logic should occur
• Whether or not the Released product should be lot traceable or serialized

By eliminating the need to specify this information upon product creation, AX has now opened the window for product creation workflow capabilities that did not exist in the past. For example, a possible workflow may be setup such that product managers or engineers design and create the product, accounting specifies the necessary financial information, the warehouse manager specifies the necessary storage dimension group, and the quality manager specifies the necessary tracking dimension group.

One field that was not mentioned in the previous section is the Item group. In AX 2012, Item group may only be specified at the Released product level. However, Item group is no longer a required field. This is a very important change, as it affects the use of inventory posting profiles. While posting profiles still work in the same manner (Table/Group/All), if the Released product does not have an Item group specified, AX will skip the second option, and revert directly to the All items posting profile.

This means that it is very important to consider whether or not an All items posting profile should be used, as it could result in incorrect postings to the ledger. For example, if an All items posting profile is setup to post to the raw materials inventory GL account, and a user fails to specify an Item group for a newly released finished good, transactions will be incorrectly posted to the raw materials account. While this scenario exists in previous versions in the case where a user specified an incorrect Item group, it may be much more likely to occur, as Item group is no longer mandatory.

Now that all required pieces of information have been specified for the Released product, the product may be purchased, inventoried, and sold as defined by all of the specified properties.


Once again, I would like to thank Brad for the continued effort in giving us great insight into what's waiting for us with Microsoft Dynamics AX 2012, relating to Product Management.


This shows off the power of Microsoft Dynamics AX 2012, around Master Data Management (MDM) & Product Data Management (PDM) concepts. All companies need a good plan for this, and it's a very important topic.

Product Management with Microsoft Dynamics AX 2012 - Part II

In the second part of this series, Brad dives into the next section of Product Management, with Product, Tracking & Storage dimensions, as well as more.:


Another key change coming with AX 2012 is the decoupling of Product dimensions from Storage dimensions and Tracking dimensions. See below:

• Product dimensions: Color, Size, Configuration
• Storage dimensions: Site, Warehouse, Location, Pallet ID
• Tracking dimensions: Batch number, Serial number

Product dimension requirements are now defined for the Product, whereas Storage and Tracking dimension requirements are defined for the Released products.
The Product dimension group defines whether or not each product dimension is active, as well as whether or not they are to be used in the price search for trade agreements.

The Configuration technology field specifies which type of product configuration, if any, will be applied to the newly created product.

• Predefined variant - This type should be chosen if the product will not be configured, but simply rely on the user’s choice of Color, and/or Size, and/or Configuration for each transaction
• Dimension-based configuration - This type should be chosen if the user will build a configurable BOM that relies on configuration rules to build the Config ID and the BOM lines. (This technology may only be chosen if Configuration is active on the Product dimension group selected for the product)
• Rule-based configuration - This type should be chosen if the product will use Product builder
• Constraint-based configuration - This type should be chosen if the product will use the new AX 2009 Constraint based product configuration method. (This technology may only be chosen if Configuration is active and is the lone Product dimension active for the Product dimension group selected for the product)

NOTE: No functionality around configuration technologies will be discussed in the remainder of the document. 

Once all fields have been specified, the user simply clicks OK to create a new Product record. There are now two types of Products records (Product and Product master) that will be discussed further:
NOTE: Two additional menu items are accessible from the main module menu for managing products: Distinct products, and Product masters. These two menu items will respectively direct the user to Products of sub-type Product or Product master, and allow the user to manage these specific sub-types separately from one another, if desired.

Product variant creation and management

A large amount of information may be maintained at the Product master level, including, but not limited to:

• Product dimensions
• Images
• Product categories
• Product attributes
• Unit conversions

For Product master products, Product dimensions and Product variants are extremely important. Both may be managed from menu items in the ribbons section of the Products form:

Product dimensions allow the user to define color, size, and configuration values (if active) for the product.

Product variants are the AX 2012 version of Item dimension combination, or unique combinations of color, size, and configuration. These may be created for a product by clicking Product variants from the Products form: 

Users may manually create the variants by creating a new record, and selecting the appropriate product dimensions for the variant.

Users still have the option to allow AX to automatically create all possible product variants by selecting the Generate variants automatically checkbox in the product details (by clicking Edit from the Products form): 

As noted during product creation, Distinct products do not have product dimensions, and therefore, do not have the ability to create multiple product variants. In fact, a Distinct product is actually, itself, a Product variant."

I would like to thank Brad for his continued efforts in giving us detailed insight into the world of Product Management with Microsoft Dynamics AX 2012. 

Product Management with Microsoft Dynamics AX 2012 - Part I

As part of my continued effort to try and help grow the Microsoft Dynamics Community and Ecosystem, I have reached out to those peers of mine that I trust. The reach out, is an effort to get them to use their knowledge, and expertise to help the Dynamics community at large.

As part of this effort, Brad Edwards, Supply Chain Consultant with Sunrise Technologies, has agreed to do a guest post here on my blog.

With the upcoming release of Microsoft Dynamics AX 2012, a lot is changing. That means deeper functional depth, and more possible ways for customers to maximize their investment with AX.

Brad, in this series of guest post, takes us through the new possibilities with product management, for Microsoft Dynamics AX 2012. 

history of microsoft

Microsoft began using its current logo inMicrosoft Windows splash screens with Windows 95.

Microsoft is a multinational computer technology corporation. The history of Microsoft began on April 4, 1975, when it was founded by Bill Gates and Paul Allen in Albuquerque.^[1] Its current best-selling products are the Microsoft Windows operating system and the Microsoft Office suite of productivity software.

Starting in 1980, Microsoft formed an important partnership with IBM that allowed them to bundle Microsoft's operating system with computers that they sold, paying Microsoft a royalty for every sale. In 1985, IBM requested that Microsoft write a new operating system for their computers calledOS/2; Microsoft wrote the operating system, but also continued to sell their own alternative, which proved to be in direct competition with OS/2. Microsoft Windows eventually overshadowed OS/2 in terms of sales. When Microsoft launched several versions of Microsoft Windows in the 1990s, they had captured over 90% market share of the world's personal computers.

The company has now become largely successful. As of 2008, Microsoft has a global annual revenue of US$ 60.42 billion and nearly 90,000 employees in 105 countries. It develops, manufactures, licenses, and supports a wide range of software products for computing devices