AX 2012 R3 Upgrade Gotchas

Inherited Tables are de-normalized

You'll quickly find that in 2012 R3, the inherited tables have been consolidated in the database.  Of course, the concepts of table inheriteance still exist, and from an AOT perspective you cannot even tell things have changed.  Selecting PurchAgreementHeader table will still work its magic and select the parent fields as well as the child table fields in the instance relationship.

What will break however, are your para-AX integrations and reports.  If you are looking to report on Department for example, you may be looking for the OMOperatingUnit table.

This is an inherited table that extends, through varioius hops, the DIrPartyTable.  All of the fields you are looking for from a SQL standpoint are now residing on the DirPartyTable ( aka the root or the top level parent table ). During your upgrade to R3 from a prior version of AX 2012, you'll want to pay close attention to inherited tables in your para-AX integrations and reporting.

Beware the changed-based tracking

First off, I think Microsoft deserves a huge thanks as the documentation for the in-place upgrade to R3 is well vetted.  Our team read the documentation, created our own watered-down version, and made any special tweaks so that the code could progress along our internal migration paths.  One little step that was overlooked ( but IS in the guide from Microsoft ) is to disable changed-based tracking on all tables in your AX database.  This is for the data upgrade checklist.

If your data upgrade cockpit doesn't show simple logging message in the upper right corner of the form, you're about to run in to some serious issues!  The jobs will fail, and the only supported way to rollback is to perform a database backup from a prior restore point.  Definitely look out for this one.

SysOperation Framework Crippled

In one of my prior posts, I mentioned the immense value of ditching the RunBaseBatch classes in preference for the SysOperation method of performing batch jobs in AX.  While this still remains true, arguably more importantly with the new framework is the ability to expose the same service class which performs your internal business logic to external applications via the AIF.  

We went full bandwagon on this new approach which paid major dividends in AX 2012 RTM ( or R1 ).  We had less code to maintaiin, and were able to streamline business processes between internal AX users and external integrations.  However in R3, the same AIF ports which used to deploy without issue are now unable to generate the service artifacts.

The root cause of this is the Data Contract class which is a parameter to our service ( this is typical SysOperation form ) extends from the SysOperationDataContractBase class.  When the AIF tries to generate .NET types for this class, it hits the \Classes\AIFServiceGenerationManager\generateDerivedTypes method.  In this method, it tries to determine the subtypes for our the class SysOperationDataContractBase.  It then decides to pull in all classes which extend this base class, which is different than R1 and frankly inappropriate:

As you can see, it tries to then generate types for all of these other classes, which have nothing to do with the service class or AIF port we are trying to deploy, other then they also extend from SysOperationDataContractBase. We have reported this as a bug to Microsoft Premier and they have been able to reproduce it in a fresh R3 contoso environment.  We are awaiting a supportable resolution.

 For what it's worth, the error message you'll receive on the port activation is less than intuitive:

SysDictMethod object not initialized.

Stack trace

(S)\Classes\AifServiceDataTypeGenerator\getCollectionAttribute - line 17
(S)\Classes\AifServiceDataTypeGenerator\generateCollectionClass - line 52
(S)\Classes\AifServiceDataTypeGenerator\generateType - line 58
(S)\Classes\AifServiceDataTypeGenerator\generateCollectionClass - line 42
(S)\Classes\AifServiceDataTypeGenerator\generateType - line 58
(S)\Classes\AifServiceDataTypeGenerator\generateDataContractClass - line 127
(S)\Classes\AifServiceDataTypeGenerator\generateType - line 54
(S)\Classes\AifServiceGenerationManager\generateDerivedTypes - line 53
(S)\Classes\AifServiceGenerationManager\generateServices - line 144
(S)\Classes\AifPortManager\deployPort - line 22
(C)\Forms\AifInboundPort\Designs\DesignList\DeployPort\Methods\Clicked - line 12

This is because one of those other data contract classes that are now being pulled in has a null parameter, and this is passed in to the type generator.  If you get this error, do not focus on your own code or objects necessarily.  Place a breakpoint in the AIFServiceGenerationManager.generateDerivedTypes() method and see if it is pulling in more classes than you intended.