AxTech2014 - day 3

Hi,

Last day at the Ax Technical Conference for us today.

A brief follow up on the sessions we attended:

Ask the experts - Microsoft Dynamics Ax components

By far the session I was most looking forward to. How many times do you get guys like

Peter Villadsen, Tao Wang, Sreeni Simhadri and Christian Wolf all together in front of you doing their very best to answer your questions. What did we learn there?

• Is the (periodic or regular) deletion of AUC files recommended?
  No it is not: deleting the AUC file is not standard procedure. A corrupt AUC file is an indication of a bug.
  Even better: the AUC file is self-correcting.

• (different questions related to performance, sizing and scaling, recommended or upper limit of users per AOS)
  The answer to all these questions is: 'it depends'. It is nearly impossible to give indications without knowing what the system will be doing. Will there be only 10 order entry clercks and an financial accountant working on Ax. Or is it a system continuously processing transactions from hundreds of POS's? How about batch activity? Which modules and config keys are active? How is the system parameterized?
  All of this (and much more) has a direct impact on performance, sizing and scaling. So MS does produce benchmark white papers, but again for a very particular (and documented) workload, parameter-setup, … . I see this MS benchmark more like a demonstration of what the system in that specific setup and configuration can haldle. But each and every Ax implementation is unique and has to be treated as such.
  As 'defaults' for an AOS server, the numbers 16 Gb of RAM and 8 CPU cores were mentioned a few times throughout the last 3 days. But that is no more than a rough guideline, just to have a starting point. From there on, all aspects of an implementation need to be considered.
  During the discussion on performance, based on experience the experts mentioned performance issues are most of the time assumed to be related to memory or CPU power. While in reality the problem is most of the time traced back to the process itself: the logic being executed can very often be optimized. Sometimes small changes with little to no risk can boost performance.
• Does the connectioncontext impact performance?
  The connectioncontext option did not seem to be widely known, therefor you can find the info here and basically glues the Ax session ID to the SQL server SPID. This facilitates troubleshooting when issues on SQL server with a specific SPID allows you to map that to a Ax session ID and thus probably a user or batch task. Anyway, the question was if this option impacts performance. In the tests MS performed there was a zero performance impact.  Nevertheless someone in the audience mentioned there might be an issue when using ODBC connections from Ax to external systems while the connectioncontext option is active.
• (various questions regarding IDMF and whether it is a beta product and supported or not)
  First of all: IDMF is not a solution to performance issues.
  IDMF can help to reduce the size of the DB by purging out 'old' data, resulting in an smaller database and therefor reducing the time required for maintenance plans on re-indexing or backups  for example.
  But IDMF (read: using IDMF to clear old data from your system and like that reduce DB size) is no guarantee for your Ax environment to become faster.
  Whether a table has a million records or a few thousand should not matter: you're (or better 'are supposed to be') working  on the data set of the last few days/weeks/months. All data that's older is not retrieved for you day-to-day activities in your production system. With the appropriate and decently maintained indexes in place, the amount of data in your DB should not affect performance.
  Anyway, the status on IDMF was kind of vague since the DIXF tool now sort of is taking over. So my guess would be for the IDMF tool to die a gentle death. Do note the 'my guess' part.

The room where the session on 'Using and developing mobile companion applications' took place was so fully packed that the MS employees were send out of the audience. Funny moment that was. Nice session further on, summarized in these keywords:

• ADFS for authentication
• Azure service bus as the link between mobile devices 'out there' and the on premises Ax environment
• WCF service relaying the messages from 'the outside' to 'the inside' and vice versa
• Application technology based on
• HTML5
• Javascript
• CSS
• indexedDB & cached data (with expiration policy) for performance and scalability

• Globalized: date, time, currency formatting
• Localized: user language of the linked Ax environment

Then there was quite an impressive session titled 'Next generation servicing and update experience in Microsoft Dynamics Ax2012 R3'. Two main topics in the session, in a nutshell:

1 - Update experience (available from R2 CU6 + and in R3)

• Pre R2 CU6 status:
• static updates via installer, the axUpdate.exe we all know
• large payload in CU packages, hundreds of objects affected
• no visibility into hotfixes in CU, the CU is delivered as-is, no clue on which change in code goes with wich KB that's included in the CU
• no option to pick and choose a specific KB during install
• little to not help with effort estimation
• call MS for technical issues  and explain the problem yourself

• Status as from R2 CU6 on and with R3:
• visibility into hotfixes in CU: during installation you get a list of hotfixes included in the CU and you get to pick the ones you would like to install! *cheers*
• ability to pick KB's based on context, country, module, config key, applied processes based on your project in LCS …
• preview (even before installation) of the code changes per object in a specifick KB
• impact analysis to assist on effort estimation
• auto code merge to help reducing effortµ
• Issue search capabilities in LCS to find these types in the results: workaround, resolved issues, by design, open issues and will not be fixed. So now you get a much wider insight! Not just the KB numbers that typically are code fixes for bugs. Your search will also find workarounds, reported issues where MS is working on, …. .

2 - Issue logging and support experience re-imaginated (LCS enabled)

Status before LCS:

• view incidents in partnersource
• # of emails to gather information and seek confirmation to close cases

• days of work before environment was set up to reproduce issues
• clumsy way of communication because both sides probably don't have the same dataset
• getting large loads of data across (for repro or simulation purposes) is also a pain

Using LCS:

• Parameters as set up in the environment experiencing the issue are fetched via collectors in LCS ...
• … and restored on YOUR virtual (Azure) reproduction environment.
• your reproduction scenario will be recorded
• the support engineer from MS can see exactly what you did and immediately start  working on the issue
• this environment is created just for you to reproduce the issue.
  So no more installing and setting up vanilla environments on premise just to reproduce an issue so it can be reported to MS!

That was the Ax Technical Conference 2014 for me.

I have not seen that many technical leaps forward, nevertheless it was a great experience and I'm convinced the strategy MS has in mind can work.

bye