I am working on AX6.0 – what are you working on?



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


Comments (10)

  1. AX tech says:

    Any one aware of AX 6.0 architecture? Whether standard AX client will be available or evrything will be web based?

  2. The only thing I would like to see that I am not involved (I do enjoy our meeting with Microsoft Product Product Planners, Programe Managers & UE Team) in already is.. using all the power of Microsoft SQL 2000/2005/2008.

    * Being able to control all the index options from the AOS

    * Being able to write more complex X++ SQL

    * Being able to use the fine tuning tools from MS SQL with AX

  3. AXDeveloper says:

    1) Object Id’s should be replaced with namespaces. GUIDS are a thing of the past! Maybe a central namespace registration service for partners would help avoiding conflicts.

    2) Please do something about the report designer and runtitme. It hasn’t been updated for ages!

    3) One should be able to retreive related table fields without coding explicit joins. The runtime should derive the joins from the relationships between the tables. This is something all ORM frameworks do.

    4) Integrate the editor with the debugger.

    5) Start decoupling and revisiting your designs. Everything in AX is bound together with "super-glue"! You have overused inheritance and failed to adhere to most of the modern object oriented design principles and best practices.

    6) You should stop writing COBOL-like data access code. Its killing performance! I took a look at implementation of the new packing slip invoicing feature. It’s full of loops, in-memory joins and lookups. You should really join at the database level and minimize the roundtrips between application and database server.

  4. KarmaBurner says:

    Nice girl. Why do you call her 6.0?.. (no offence, just kidding 🙂

    I guess, moving application objects to SQL database from file DB could be also a nice thing: performance, reliability, transactions, no need for file server, etc.

  5. Harshman777 says:

    Well. Reporting is one gr8 tool on which DAX has been missing out lots with each new version. It seems like nothing is being done to upgrade the existing reporting architecture…..would definitely like to see the ballistic designing skills of .Net being incorporated into pre-historic DAX Reports.

    Kudos to the future of ERPing!!!!

  6. thensley@firstsolar.com says:

    Sturla’s recommendation to replace Id’s with GUIDs would also greatly simplify the use of source control (no more "team server" handing out object IDs!) and distributed development.

  7. Dilip says:

    Great Post! I would really be interested in learning about the more features which would be built into AX 6.0. Yes, Eventing is very much required where we can subscribe to events raised in .NET assemblies, And also Morphx (AOT integration) with Visual Studio IDE would be awesome. Thanks for the update and keep posting!

  8. sturla says:

    What about dropping the Id’s (tables, fields, indexes,…) as we know them and use GUID instead? That would make it more easy for partners to develop and deploy Dynamics Ax solutions.

    The entity concept is something Dynamics Ax has been needing from day one. That is if you could use them as form data sources like we use tables today. That would make it possible to create good business logic layer between the tables and user interface. I sometimes see MorphX (and the tight bondage of forms and tables) as one of the strongest part of the system today, but also the biggest enemy.

    Regards, Sturla.

  9. thensley@firstsolar.com says:

    With complete ignorance of AX internals, I write…

    I’d certainly like to see MorphX look and feel more like Visual Studio, but actually move it to VS?  Not unless there is some good technical reason for doing so.  I’d hate to see MorphX compromised just to shoe-horn it into VS.

    How many layers should AX 6.0 have?  How about an undefined number of layers between the Microsoft layers and CUS, and the ability to order those layers as you choose?

    Should AX support eventing?  YES! YES! YES!  Coming from the .NET and COM world this is absolutely the thing I miss most.  This would reduce overlayering considerably because you wouldn’t need to place your own code in existing methods.  You could have your own class with handlers for events raised by forms, reports, tables, etc.  You know what would be REALLY cool?  If .NET apps using the Business Connector could handle events triggered on the AOS.  I’d love to be able to write a Windows Service in .NET that would sit and watch for things like insert, update, and delete events on certain tables.

    twh

Skip to main content