Cumulative Update 7 for Dynamics AX R2 has been released today! Download it from Partner Source or Customer Source.
Besides 60 country specific regulatory updates and many quality improvements, these areas have been enhanced:
Inventory and warehouse management
Procurement and sourcing
Product information management
Project management and accounting
Sales and marketing
Backup and recovery
Data import, export, migration
Sales tax processing
Demo Company Overview
The Demo Data set for Microsoft Dynamics® AX 2009 is no longer based on the Global Trade and Manufacturing Company. Based on market feedback we have created a new Contoso Entertainment systems group of companies. It comes with 2 fiscal years of transactional data that enable us to demo our stronger Business Intelligence story and Role Center pages, while allowing us to easily expand the demo data story in future releases as we expand Microsoft Dynamics® AX’s functionality footprint.
Contoso Entertainment Systems (CES) is a home electronics manufacturing, distribution and retail company that includes a Professional Services department. Its headquarters are in the USA with a key distribution subsidiary based in Germany and it works with the relevant currencies. CES distributes televisions, projectors, Digital Video Recorders and Players, and audio receivers. It manufactures speakers and assembles home theatre systems. CES’s customers are primarily based in North America and Europe and include Major Accounts (such as hotel chains), Wholesalers (of differing sizes), Retail stores (that are self-owned and operated), as well an internet storefront.
The legal and physical structure of CES is setup as follows:
· CEC – Contoso Entertainment Consolidation, based in USA
· CEU – Contoso Entertainment USA, Headquarters based in USA
o Site 1: Production of all speakers
o Site 2: Assembly of home theatre systems and Services
o Site 3: Production of Standard speakers
· CEE – Contoso Entertainment Europe, Distribution subsidiary company based in Germany
o Site 4: Distribution, Assembly and Service of all products
· CVC – Virtual company that includes table collections from CEU and CEE.
The downloads for Contoso Entertainment Systems demo data offers transactional data for Basic, Administration, General Ledger, Bank, Fixed Assets, Accounts Payable, Accounts and Receivable, Inventory Management, Intercompany, Production, Master Planning, CRM, Project, Expense Management, and Human Resources modules, and is intended to demonstrate these modules’ functionality. It also offers base data (i.e. no transactions) for the Product Builder modules. There is no demo data available for Payroll and Cost Accounting modules.
About a milestone ago I announced SQL AOD. Since then it has been quite quiet on my blog - for two reasons 1) I've been heads down in new features and 2) I've been on paternity leave. Now the completion of M2, the next milestone of AX "6", is within reach and I've returned to my office. This means I can share some more exciting news.
Since the days of AOD files are numbered we need a new vehicle for deploying metadata elements to an AX installation. To address this need we introduce Models. A model is a containment of metadata elements.
To create a model you use the new command line utility AxUtil:
This will create a new model with the name "My Model" in the USR layer. This new model can be selected in the AX client configuration utility as the default model. When you start AX the status bar will tell you which model you are currently working in - just next to where the current layer is shown. When you make changes in the AOT, like overlayering elements, creating new elements, changing X++ code etc., the resulting elements will automaticaly be contained in your model.
When you have completed all your changes, then your model is complete. In other words it is time to move the model from your developer box to a production system. In AX2009 you would copy your AOD files - with models you need to export it to a physical file. Again you will use AxUtil:
Now you can copy this file to the production system and import it there:
You can even uninstall it again - if that is what you want. This is semantically the same as deleting an AOD file in AX2009:
So far I have described the model capabilities that gives parity with AOD files: We have a file based container that can be xcopy deployed and we can delete models again.
From what I've described so far models aren't much different than layers and AOD files. They are; and provide some highly desirable capabilities - which will be the topic of a near-future post - so stay tuned.
This post is a part of a series on models:
This posting is provided "AS IS" with no warranties, and confers no rights.
If you, like anyone else, want to get your hands on R2 – here are the links for customers and partners.
R2 is an incredible engineering achievement. Let me mention just one remarkable improvement: We have collapsed all GLS layers into the SYS layer. This means that for the first time you can have one instance supporting local requirements in 41 countries simultaneously. Learn more here. I’m proud to have been part of the team making it happen.
With any great product launch a lot of material is made available. That is also true for R2 – and yet something stands out. In collaboration with Microsoft Studios a number of short videos have been created. I think they are truly amazing – what do you think? Try out the links below.
Question What does it feel like to be in control, highly responsive, agile, connected and dynamic?
Answer Explore in the lives of a; CIO, CFO, HR Manager, Practice Manager, Retail Manager and a COO of Manufacturing.
For more information see http://www.microsoft.com/en-in/dynamics/erp-ax-2012-r2.aspx
The Dynamics AX Debugger doesn’t support conditional breakpoints. Once in a while this limitation can be quite annoying – but there is a simple workaround. The third trick in the series of X++ Debugging Tips and Tricks shows you how.
This trick requires code instrumentation – I strongly discourage using this trick on a production system. Only use this trick in a test or development sandbox!
By using the breakpoint keyword, you can write X++ logic that triggers a breakpoint exactly as you want.
Consider this example. It is a recursive implementation of the mathematical function: Factorial. On a 32 bit system it will overflow when called with a sufficient high value. The example shows how to a breakpoint when an overflow occurs.
static void ConditionalBreakpointExample(Args args)
int factorial(int _value)
int result = 1;
for (i=1; i<=_value; i++)
result = result * i;
if (result < prevResult)
breakpoint; //Overflow occurred
prevResult = result;
The same approach can be used in many other scenarios too. Here is another example – I’d like a breakpoint to fire when a Released Product with Item Id “1000” is inserted in the database. To achieve that I add the following to the insert method on the InventTable table.
if (this.ItemId == "1000")
There is another way to achieve the same result. You can also insert a no-op line, like i=i; and set a normal breakpoint on that line using F9. This approach has the benefit that only the user setting the breakpoint will hit it – but at the risk of leaving some “silly looking code” behind. In contrast the breakpoint statement triggers a best practice error – so they are easy to clean out again.
There is another usage of the breakpoint statement. Sometimes regular breakpoints in forms don’t fire – here the breakpoint statement also comes in handy. Instead of setting a breakpoint using F9 – just type “breakpoint;” in the code. This will trigger the debugger.
This post is provided AS-IS, and confers no rights or warranties.
In my first two posts on models in AX (Part 1 and Part 2) I covered the deployment specific behaviors of .axmodel files - it should be apparent we introduced .axmodel files as a deployment replacement for AOD files. In the process we added some nice capabilities like a manifest and signing. The real benefit of models, and the ultimate reason we are adding this level of abstraction is because:
You can have as many models per layer as you want.
Let us examine this statement. In AX2009 a layer is the confinement unit of model elements. The layer is the unit of which you can export, deploy and delete model elements. (Here I'm deliberately ignoring the capabilities provided by XPO files, as these are suitable for development purposes only, and not deployment.) In AX6 this limitation has been removed, that means you can segment your layer into as many models as you like.
Here are a few examples where this could be useful in development scenarios:
Let's examine the statement a bit deeper. There are two ways of getting a model: Either you create one on your own, or you receive it from someone else. If you can have as many models as you want per layer, it also means:
You can deploy models from several sources into the same layer.
Here is an example: You are a customer and would like to install two ISV solutions that both are available in the BUS layer. In AX2009 you would have a tough choice to make: Either you picked your favorite solution and learned to live without the other one, or you invested in having the two solutions merged into one layer. This merge is technical challenging, and a costly affair once updates to either solution are being released. In AX6, however, you download the two models, and use AxUtil to import them. When a new version of either model is released, you simply use AxUtil to update the model.
This all sounds too good to be true, what is the downside? There is one limitation to what a model can contain:
An element can only be defined once per layer.
This means that two models containing a definition of the same element cannot be installed in the same layer. For example; if the two models both contain a class named: "MyClass" they will not be able to install side-by-side in the same layer. Model elements have two alternate keys, they are: [Type, Parent, ID] and [Type, Parent, Name]. Each layer can only contain elements that can uniquely be identified via the two alternate keys. In less technical terms, this means that two elements of same type under same parent (or without a parent) cannot co-exist if they have same name or same ID. For example: A table cannot have two fields with same name, or two fields with same ID. Another example: You cannot have two display menu items with the same name.
There are three ways you can be hit by this limitation:
So apparently we cannot guarantee that models can co-exist in the same layer - so what are the options when two models are in conflict? When you import a model that conflicts with an already imported model, you get three options:
Models enable a lot of highly desirable scenarios, one of the most important scenarios being that models from different sources - for example, two ISVs - can be installed in the same layer side-by-side. There are a few technical limitations; but the risk of conflicts is much reduced in AX6 and even when conflicts occur there is a less-expensive way to make the models co-exist.
More on models...
Here is a sneak preview of the new X++ Editor in Microsoft Dynamics AX 2012.
Notice that the editor now features word-completion, automatic indenting, scripting, zoom, multiline editing, and much much more.
This post is also available on Channel 9.
THIS POST IS PROVIDED AS-IS AND CONFERS NO RIGHTS.
Here is a sneak preview of the new MorphX developer workspace in Microsoft Dynamics AX 2012.
Notice the clear distinction between developer and application workspaces, and how the layout of the drop down menus makes it possbile to access tools with fewer clicks. You can launch the AX client directly in development mode using: AX32.exe -development.
4 layers have been renamed in Dynamics AX 2009 . DIS / DIP / LOS / LOP have become HFX / SL1 / SL2 / SL3 respectively. HFX is reserved for releasing hot fixes, and the 3 new solution layers (SL1/SL2/SL3) will be used to release Microsoft Dynamics Industry Solutions.
The purpose of having 3 solution layers is to enable side-by-side install of Industry Solutions. At deployment time any SL1 layer can be renamed to SL2, SL3, BUS or BUP through a regular file rename. The AOS will recognize the layer, and honor its position in the layer stack. This will enable installing up to 3 Industry Solutions on the same system (or up to 5 Industry Solutions if the BUS and BUP layers are vacant.)
Another aspect of side-by-side installation is conflicting names and IDs in the model. The AX platform requires unique names and IDs of all model elements, we will ensure uniqueness across Industry Solutions through our engineering processes. Naturally there will be logically overlayering conflicts for certain elements; but as the Industry Solutions by nature are verticals we anticipate very few of these. These conflicts will need to be resolved; one way is to reclaim one of the SLx layers as an adaptation layer. More information on this will be available as the Industry Solutions become available.
Why not just support an unlimited numbers of layers?
Frequent feedback we get is to add more layers; and open them up for consumption by the partners. And heck, why we are at it why not have an unlimited number of layers?
Currently; there is an upper limit on the number of layers the kernel can support. This number is 16. The technical explanation has to do with referencing of the elements in the model. Each model element is stored in a record in the AOD file. The RecId for model elements is a 32 bit integer. 4 of these bits denote the layer; the remaining 28 bits are used to calculate the offset into the AOD file where the record is located. In version 3.0 (and previously) the block size was 1 byte. This basically mean the maximum size of an AOD file is about 256MB (2^28). In version 4.0 we moved this limit by denoting one of the 28 bits to control the block size. When the bit is not set, the 27 bits is the direct offset in to the file. When the bit is set, a block size of 48 bytes is used to calculate the offset in the file. This enables AOD files with sizes up to about 6.5 GB (2^27 * 48), while enabling binary backwards compatibility with 3.0 AOD files (with sizes less than 128MB (2^27)).
If we decide to use one bit more to denote the layer (giving us 32 layers); it means we are only backwards compatible with AOD files with sizes less than 64MB (2^26). As that is not acceptable; tools to align the contents in AOD files would be needed. For 6.0 we are investigating options to tear down these limitations once and for all.
Updated 30-06-2012 official beta version available here: http://informationsource.dynamics.com/RFPServicesOnline/Rfpservicesonline.aspx?ToolName=Microsoft+Dynamics+AX+2012+Combine+XPO+Tool+Beta+1.0
Updated 14-01-2011 to support UniCode XPO files. Notice the change in parameters.
So now you are using version control - and you just realized the master is no longer the AOD layer file, but instead a zillion of XPO files. Still you want to provide an AOD file to your consumers, as that is the way to deploy an AX application.
Page 96 in Inside Dynamics AX 2009 contains a description on how to build an AOD file from XPO files. In this section an SDK and a tool are mentioned. While we are working on providing you with the SDK for building a layer file, I can make the CombineXPOs.exe tool available.
See the attached file.
Usage: CombineXPOs.exe -XpoDir XPOfolder -CombinedXpoFile DestinationFile.xpo -utf8
Example: CombineXPOs.exe -XpoDir USR -CombinedXpoFile myFile.xpo
Files in the XPOFolder folder must match the AOT structure. This is automatically ensured when using AX version control integration.