During our validation phase of the AX R3 upgrade project, we found some issues regarding security for our product configuration department staff. This is likely due to developing highly customized roles for our users, to keep licensing costs low. Even so, we expected most new menu items to go in to existing privileges for the majority of users. In any case, you may run in to this error message:
In reviewing the AIF Service generation classes between RTM CU5 + Feature Pack and R3, I found a small difference in the AifServiceDataTypeGenerator class.
Specifically the method highlighted in the image above, the generateDataContractClass. Previously, we had been able to deploy AIF ports that used Data Contract Classes which extend SysOperationDataContractBase. In AX 2012 R3, this was broken - for details see my previous post.
In our upgrade to AX 2012 R3 from AX 2012 RTM ( or R1 ), we've run in to some interesting scenarios. Be it the flattening of inherited tables ( you'll see the extended/child table in the AOT but it has vanished in the SQL database ), being SURE you have change tracking disabled on your database prior to running the "Data upgrade checklist for in-place upgrades", or now the deployment of AIF inbound ports which extend SysOperation framework. We'll share our experience so that you can save a few grey hairs!
All inbound AIF service calls to AX 2012 RTM through R3 are wrapped in a single gigantic transaction. In this post, I'll show you where this is happening and how to overcome it.
For those of us who have developed on earlier versions of AX, RunBaseBatch rings a bell. In fact, it was the primary ( and frankly is still used by Microsoft in 2012 R3 ) means of scheduling code execution. It could be an hourly process to invoice sales orders, a nightly MRP run, or a complex financial consolidation. The problem was it still had to execute in native X++ albeit on the Server tier, and if you had an external application that also needed to execute the same logic you had to build an extra interface.
Financial Dimensions in AX6 have been revolutionized, as many of us know. Adding them to a form is rather simple, given that one of your underlying data sources has a Default Dimension field. But, what if you were building a form that didn't meet this requirement, or better yet had no data sources at all? This is where the DimensionDefaultingControllerNoDS class comes in to play.
First thing's first: add the class to your form declaration:
Hello! The name's Lane, and you're probably wondering what is up with the picture above. I've always found art and architecture to inspire and be thought provoking. I'm hoping this portal will serve a similar purpose for our visitors.