AX 2012

This error message with label ID: @SYS134518 can be found in the WrkCtrScheduler.loadRoute method. It basically means that it could not run the planning due to an issue with the route map.

I received this error due to a missing route group on a route. This was due to bad data that was imported and would not have happened if routes where created in the application directly.

The tricky thing was that this might pop up when trying to plan an item with a large BOM structure. Somewhere in this structure lies a route that is not configured properly. But which one is it?! That would be nice to have in the error message right? So let’s fix it!

Put this code:

if(_order.tableId == tableNum("ReqTrans"))
{
    info(strFmt("Item Number: %1 in RouteID: %2 on Operation: %3", ReqTrans::findrecId(_order.recId).ItemId, reqTrans::findRecId(_order.recId).ItemRouteId, routeMap.oprNum));
}
else    
    info("Error not related to a reqTrans");

above the line:

throw error("@SYS134518");

This will then read the item, route and previous operation to the issue and you can easily mitigate it.

LOVELY!

The setup for Microsoft Dynamics AX 4.0 and AX 2009 as well Axapta 3.0 (I haven’t worked with older versions) was pretty straight forward when it came to the configuration and number of environments. You had a Live environment, a Test environment and in most cases also a Development environment. You could easily make a copy of a company in any of the environments to get a place to try out transactions and that worked well. (You might have to add an separate test environment for AX 2009 if you where using the Enterprise Portal development.)

With the introduction of AX 2012 there was a lot of changes and most of us where caught of guard. There was good reasons for the changes, but the consequences of did take some experience to actually get right.

Issue #1: Company copy function was gone

Because of the global data and organization hierarchy features you couldn’t just copy a company. The feature to copy a company (legal entity) was deprecated. You would have to have a totally different environment to do that, so in the beginning we did training and process testing in the Test environment.

The challenges this brought was that you might have features for testing in this environment and the results might affect your training or process testing.

The result was that a new environment had to be introduced: A dedicated training environment that was identical to your Live environment.

Issue #2: CIL compiling and code management

This isn’t my area of expertise, but it is clear that the concept of CIL execution, that was new to AX 2012, have changed the way we work with the AX code.

The AX 2012 code has to be TOTALY free for errors if you want to make a full CIL compilation, and you have to be certain that your code is the CIL runs before you move code to your Live environment.
You don’t want to move code to the Live environment and do a CIL compile without knowing if it works. As you might have multiple changes going on at the same time you would need a separate place to do the CIL compile.

The result was that a new environment had to be introduced: A dedicated environment where code could be compiled and tested before moved to the Live environment.

The new environment layout

Live
No development, no untested code, no compiling (Unless… you meet an error that requires it). Receives code through copying the model store from the Staging environment at planned intervals.
If your business is very lokalized, like a manufacturing company with one site location, I would recommend an on-prem solution, but Azure is also a good alternative.

Training
Code is copied in parallell with Live. Receives data through DMF or by routinely copying the Live transaction database. Super users and end users use this environment if needed.
Put it in Azure.

Staging
Code is imported when approved from Test and is compiled, CIL compiled and retested. Data is routinely (at request/if needed) copied form the Live transaction database. You can have multiple updates to the staging environment before a copy to Live is done.
Put it in Azure.

Test
New code imported from development and features are tested and tried out by the super users and admins. Transactional data is copied from Live when needed.
Put it in Azure.

Development
You can either have a common development environment or multiple environments based of the same codebase. Data is rarely, but if absolutely needed copied from the Live transactional database.
Put it in Azure.

Would love some input on this if you’ve got some, so please comment with input if you’ve got any. Thanks!