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.
PartnerSource: https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/AX2009DemoData.htm
CustomerSource: https://mbs.microsoft.com/customersource/downloads/servicepacks/AX2009DemoData.htm
http://blogs.msdn.com/epblog/
I've added a link to their blog in my "Other Dynamics AX Blogs" section.
The Microsoft Dynamics AX 2009 Client has successfully completed the Certified for Windows Vista testing conducted by VeriTest.
Products that are certified to run on Windows Vista have passed an extensive set of tests conducted by an independent testing authority. These tests cover areas such as Security, Compatibility, Install /Un-Install and Reliability. The logo assures customers that Dynamics AX 2009 is among the elite applications that provide the best Vista experience.
The Certified for Windows Vista logo the more prestigious of the two Windows Vista Logo programs, the other being Works with Windows Vista which is given to an application that offers baseline compatibility.
Today Microsoft Dynamics AX 2009 is RTM. This means DVDs are now being mass produced, and the product is available for download at Partner Source.
My favorite features in DAX2009:
- Brand new UI: List pages, role centers, crumb-bar, activity centers and ribbons.
- Improved performance. Especially I like the near-instantly startup of the clients.
- Workflow support.
- Improved reporting and BI facilties; powered by SSRS.
- Enhanced developer experienced: TFS integration, XML documentation, ER diagrams, CLR interop and much more.
- New suite of tools for code upgrade.
I'm proud to have been a part of the extraordinary team building this extraordinary product, executing on a 2 year plan and delivering on time. Since you are reading my blog, I feel confident this product will have a postive impact on your professional life. Starting today!
We've had feedback from many sources (comments in this blog, emails, in-person meetings, partner advisory board, etc.) that we should fix the element ID problem in AX - the sooner the better. Thank you very much for this feedback. This post is intended to give a bit of background on this subject.
The element ID problem in AX causes pain on two fronts:
- Uniqueness. Element IDs must be unique on any given installation. We have a suite of tools to help generating unique IDs, detect uniqueness conflicts, etc. Learning and using these tools are painful, resolving ID problems is even more painful, especially on live systems. Further the uniqueness issue makes it hard to combine solutions from different source in one installation.
- Upper limit. Each layer has a finite number of IDs. This means there is an upper limit to how many model elements you can create. Microsoft's core development team knows exactly how this pain feels.
At any rate; this is a problem we need to address - and my team has been given the task. While many solutions spring to mind (use GUIDs or drop IDs completely) this is a case of Devil in the Details.
Business Data: IDs are persisted in the business data base. Any change to IDs would require upgrade scripts. To make matters even worse, IDs are also stored in unstructured blobs; making identification and migration even harder.
Business Logic: Business logic uses IDs. Both Microsoft's business logic; but certainly also the business logic in solutions authored by partners around the world. Changes to IDs would impact all this business logic.
Kernel: The implementation of the kernel used IDs heavily. Changing data type or dropping IDs totally would require rewrite of large portions of the kernel. The kernel provides the API for converting IDs to names and back again.
Application model: IDs (and Names) are stored in the Application Model. IDs are used as references between model elements and IDs bind customizations to the original element. Whatever changes we make, we cannot break the references in the model.
Getting challenges like this is what I love about my job.
The most visual idiosyncrasy in X++ is the dangling semicolon separating the variable declarations from the actual code. But why is it there and why is it needed?
Best practices in X++ (as in most other modern languages) suggest using TitleCase when declaring (and referring to) types, and using camelCase when declaring variable types. Here is an example of what an X++ developer could write:
AccountNum accountNum;
;
accountNum = "4000";
As X++ (unlike most other modern languages) is case insensitive, this is what the compiler will see:
accountnum accountnum;
;
accountnum = "4000";
Suppose the dangling semicolon wasn't there. Then the "accountnum" statement in the second line is ambigious. It could either refer to the type or to the variable. The X++ compiler assumes it is the type, and thus generates a compilation error when encountering the equal (=) sign; as you cannot assign into a type. By inserting the dangling semicolon you instruct the compiler that there will be no more variable declarations; and thus "accoutnum" is a reference to the variable and not the type.
If it was made a priority to get rid of dangling semicolons, what could be done?
-
X++ could be made case sensitive. This would likely break all customizations and solutions available; unless it is accompanied with a code "beautifier".
-
The compiler could be made more intelligent by looking one more token ahead before giving up. As human beings easily can see through the ambiguity; the compiler should be able to do so too. I guess the developer solving this issue would kudos in AX-land.
The above is a draft of a blog post I wrote last week. I wrote it for two reasons: Mainly to explain the dangling semicolon issue, and secondarily to lay out bait for a developer on the X++ team. As it turned out more progress was made this weekend than the past eleven years in this corner of AX . After writing the draft above I decided to take a look under the covers in the compiler; to gauge the challenge, I guess. So I installed the latest version of VS and downloaded the latest source code for the kernel. (These are some of the freedoms you enjoy when working for Microsoft). After playing around with the grammar for a while, I came to the conclusion that the grammar is crisp and clear; the scanner is just feeding the wrong tokens to the parser. I found the spot where non-keyword tokens are evaluated. I discovered that if a token shares name with an X++ type (Class, Table, EDT, etc.) the parser assumes it is a type-token. After finding this spot it took me less than two hours to write some code that reads one token ahead and only assumes the current token is a type-token when it is followed by another non-keyword token. Sunday afternoon I had build 585 (the Release Candidate (RC0) of AX 2009) with a twist on my box: The dangling semicolon is no longer a requirement. I enjoyed the rest of the day in the sun with my family.
This morning I have created a package with my findings and sent it to the X++ team for evaluation. This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.
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 * 49), 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.
Yvonne Dittrich and Sebastien Vaucouleur have just published a report on their research into Customization and Upgrading of ERP systems. More specifically they have studied Dynamics AX and Dynamics NAV; and their report reveals some interesting insights into the how problematic it can be to "build a house on the back of an elephant".
Abstract
An increasing number of software systems are developed by customizing a standard product that provides the major part of the functionality. The customizations of Enterprise Resource Planning systems are examples of such a practice. Nonetheless, little empirical research on the specific characteristic of this kind of software development is available. Do the recommendations for “normal” software development also apply in this case? We present an empirical study on ERP customization practices based on video recordings, interviews and a survey. The observed and reported practices challenge some of the principles of software engineering acknowledged as good practices. Based on the analysis, we discuss essential challenges and identify directions to take when addressing specific difficulties. Besides bearing the potential to influence the development of future generations of enterprise systems, the presented research provides insights in software development practices changing and amending a software product “from within” rather than developing the central functionality from scratch or re-using components “from without”.
For more information please see: http://www1.itu.dk/sw82268.asp
The ready-set-go call has just resonated through the hallways at Microsoft, and we are now officially working on the next release of AX. What will the next release of AX look like? What features will it contain? What architectural changes will we make? What tools should we support? These are some of the many questions we will be working on during the upcoming months while we are defining the scope for the next release. I work in the Developer and Partner Tools team. This means I get to influence decisions like: "Should MorphX move into Visual Studio?", "How many layers should AX 6.0 have?", "Should X++ support eventing?", "Do we need an Entity concept in the AOT?", "How do we make our unit test cases available to partners?" - just to name a few. These are the questions that can get me out of bed in the morning - for a lot of good reasons, but primarily because I know my job makes a big difference to a lot of people.
If you want to join me shaping the future of AX at Microsoft Development Center Copenhagen, please visit:
http://www.microsoft.com/danmark/om/mdcc/default.mspx
Dive deep in to the architectural details of Microsoft Dynamics AX to make relationships clear and development tasks easier. The first part of the book is aimed at consultants and developers who are new to Microsoft Dynamics AX but have backgrounds in business application development using traditional languages, frameworks, and tools. It describes the architecture and development environment and explains key application frameworks that developers need for their customization, extension, and integration projects. The second part of the book is a reference guide for developers who work with Microsoft Dynamics AX deployments, with information on developing new functionality and supporting users. It covers more complex development concepts such as advanced forms and reports, reflection over the application metadata, performance, upgrades, migration, and setup. This is the first book written by the Microsoft product group architects and the first to take developers deep inside Microsoft Dynamics AX.
Inside Microsoft Dynamics 4.0 is now available for download at: http://download.microsoft.com/download/2/5/8/258C8894-B94A-4A87-81EA-4DBB9776F8F2/622579eBook.pdf
We are planning future versions of our partner-oriented tools and understanding your use of the Sure Step Rapid Configuration Tool is important to us. Please spend 3-5 minutes to tell us what you think of the RCT. The survey can be found here. Your feedback is very much appreciated!
Here’s the full address to the survey: http://www.surveymonkey.com/s.aspxsm=4GB88KoZFMGCGqY15Jo7nA_3d_3d
In the entire development cycle this is my favorite day. My mail box is getting filled up with testimonies of customers going live on Dynamics AX 2009, followed by various happy mails. Some might consider it spam; I could read them all day long.
We are happy to announce that the new Microsoft Dynamics AX 2009 Pre-Release (CTP3) Demonstration Toolkit is now available on Partner Source.
The Dynamics AX 2009 Pre-Release (CTP3) VPC is an unsupported ready to use pre-release of AX 2009. The Virtual PC image of Microsoft Dynamics AX 2009 Pre-Release (CTP3) enables you to demonstrate the features of Microsoft Dynamics AX 2009 using a single PC or laptop computer.
AX 2009 Pre-Release (CTP3) Demonstration Toolkit Demo Data.
This version of the Dynamics AX Pre-release Demonstration Toolkit is based on the new Contoso Demo Data Company. The current demo data version will only have base data and no transactions. We are planning to upload a demo data version with transactions shortly.
The Developer Highway Code, written by Paul Maher of DPE, is a concise handbook that captures and summarises the key security engineering activities that should be an integral part of the software development process. This companion guide should be a must for any Developer, Architect, Tester etc. undertaking software development...The book is presented in easy to read checklist form, covering essential guidance on writing and releasing secure code. And it is available for free!
“Developers are a most critical component to a more safe computing experience for all computer users in the UK and around the world. Code written for a program or operating system, or process must be able to withstand the most aggressive attempts to ‘break it’. From games to mission-critical operations, secure code will form the base for success or disaster. The Developer Highway Code should be a required reading." Edward P Gibson, Chief Security Advisor, Microsoft Ltd
Where can you get The Developer Highway Code?
Download full book only as a pdf or Download full book only as an xps
Deepak Kumar and myself hosted a session on the upgrade process at Convergence in Orlando. A big thank you to everyone who attended; we are truly humbled by the great feedback we are receiving for our session. An even bigger round of applause is due to Paul Langowski from Tectura, who joined us on stage to give testimony on two "double-leap" upgrades he has worked on.
For those of you who wasn't able to attend, I've attached the slide deck to this post.
Here is the excerpt of the session:
Upgrading to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009; 3/13/2008 10:00AM-11:00AM; W204
This session will take you through the end-to-end flow of upgrading from Microsoft Dynamics AX 3.0 to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009. You will see an overview of the code upgrade as well as the data upgrade process along with recommended best practices. Examples of the improved upgrade documentation, with a focus on the implementation guidelines that come with a dedicated section for upgrade, will also be covered. This session will also include tips on performing data upgrade and code upgrade more efficiently and effectively. Additionally, you'll learn tips on the extra steps needed to upgrade if you've extended your solution. This session is designed for partners and customers who are planning to upgrade or would like to learn more about a Microsoft Dynamics AX upgrade.
