SysOperation UI Builder – Product Category Hierarchy

We had a requirement to provide the user with a selection of the Product Categories, in the service’s dialog. Here is a quick example of how the SysOperation framework UIBuilder classes can be leveraged to display intricate lookups.

Contract with the linked UIBuilder

The hierarchy and the category are the RefRecId’s

Without the necessary changes in the UIBuilder, the dialog displays a simple drop down, listing all the available categories in the system:

Register the overridden lookupReference() method for the Category field:

The Category dialog field now displays a nicely formatted lookup of the category structure for the selected hierarchy:

TFS – Corrupted XPO in Repository

We have experienced situations when a developer attempts to check out an object in AOT, and while the object gets properly checked out in TFS, AX doesn’t quite ‘check it out.’ This is manifested by the fact that while the object gets the familiar blue text highlight in the AOT, indicating that it is checked out to the developer, editing of the object, is nonetheless, disabled.

Attempting to Get the latest version of the object, may also result in an error to the effect that the “Access to the path <Local Repository\object.xpo> is denied…Synchronization failed.”

This is likely an indication that the object’s XPO, in the local repository, got corrupted.


One way to resolve this, is to delete the XPO from the local repository; and Synchronize the version control.

Scheduling Engine – CLR Error

There is an intriguing error in the scheduling engine – “A CLR error occurred while invoking the scheduling engine.


The infolog message is not very descriptive…at first sight. However, if you focus on the message text above the error, you will see the details of the error in the bottom pane:


That may work for you, but in order to enhance the user experience, you may want to make a small change to the ProdUpdScheduling class, and handle the CLR error elegantly to show the error to the user.



Script Record – Record Info

This one may sound trivial, but we get asked about it quite a bit. If you are looking to have the ‘Script’ option available in the Record Info form, the ‘Test framework’ configuration key needs to be enabled.

script - record info

 

script - config key

CIL Build – VS Project AOT reference

We have encountered a CIL compilation issue for a custom class which referenced a custom VS project in the AOT.

The errors gave no indication as to the cause and looked as follows:

Cannot create a record in Compiler information (TmpCompilerOutput). Path: Classes<class><method>, Warning: No proxy found. Type FileIOPermission found on the stack. This code in Class: <class>, Method: <method>.

The record already exists.

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

The interesting thing is, that the class in question compiled fine. However, when we looked at it in the AOT, right after the CIL generation failed, and hovered over the method’s signature line, we saw a context error message stating: CIL generation: Error: .NET Cast Type Name not found. Type System.String found on the stack. This code in Class/Table: <Class>, Method: <method> may not work in CIL run time.

In order to resolve we copied the Microsoft.Dynamics.AX.Xpp.Support.dll assembly from the Server/Bin to Client/Bin, which produced a clean CIL compilation.

Corrupt ModelStore File

Received the following error when deploying a model store to a destination environment:

“…Binary stream ‘178’ does not contain a valid BinaryHeader….”

As part of the deployment, we exported the modelstore from the source environment, then copied the exported *.axmodelstore file over to the destination server, and imported the modelstore to the target environment. Turned out that the file was getting corrupted during the copy operation between the servers. The solution was to export and import the modelstore to/from the same network location.

SharePoint 2013 – Issue Consuming AX Services

Received the following error when consuming a custom AIF service, over Net.Tcp, from SharePoint 2013 :

The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was ’00:59:59.9780837′.

We had successfully consumed the service from other clients, such as a test VS project, ASP.NET page, as well as from the SharePoint’s timer job. The issue occurred only when making the call to the service when executed by the interactive SharePoint users. Turns out this has something to do with the user context/privileges. The solution was to force the SharePoint to execute the call under its application pool’s identity. Wrap the call to the service in SPSecurity.RunWithElevatedPrivileges:

SPSecurity.RunWithElevatedPrivileges(() =>
new
<AXServiceClient>().<AXServiceOperation>());

AX2012 Upgrade – ‘Create Tables’ Errors

We have received errors during the ‘Create tables’ step in the AX2012 Upgrade checklist. The errors were of the following format, and exceeded 10000…

Error 

[Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near ‘?’.

INSERT INTO SQLSYNCINFO (TEXT,TABLENAME,ID,PARENTID,LOGTYPE,MESSAGETYPE,SEQUENCE,

SYNCTABLE, WARNINGOK,RECVERSION,RECID) VALUES (?/*’/* block */’*/,?/*”*/,?/*0*/,?/*0*/,?/*1*/,?/*0*/,?/*1*/,?/*0*/,?/*0*/,?/*1*/,?/*5637172525*/)


 

Cause 

The AX Server configuration was configured with the ‘-internal=comments –internal=nocursorreuse’ command. This setting is recommended by Microsoft for the duration of the upgrade, however, it needs to be set prior to executing the bulk copy scripts. The system errors out, if the setting is present during the ‘Create Tables’ step.

Solution 

Removed the -internal=comments –internal=nocursorreuse command from the AX Server Configuration. (*added it back at a later stage in the upgrade process)

AX2012 Upgrade – New scripts cannot be started while scripts of type [readiness] are running.

You may encounter this error when launching the Live Preprocessing or the Delta processing scripts, for the AX2012 Upgrade checklist in AX2009, even though you have successfully completed the Upgrade Readiness scripts.


Error:

We have encountered this error in the following scenario:

  • Ran the Upgrade Readiness scripts. All scripts completed fine.
  • Ran the Live Preprocessing scripts. All scripts completed fine.
  • Opened the Upgrade Readiness scripts form to review the results; and closed the cockpit form without running the scripts again.
  • Tried to launch the Delta Processing scripts > encountered the error.

Cause:

When the Upgrade Cockpit is opened, it loads all the scripts, for the current stage, into the ReleaseUpdateScripts table. When the form is closed, it checks whether all the scripts have completed. If they have, the logic deletes the records from the ReleaseUpdateScripts table. The records in ReleaseUpdateScripts do not get deleted if the scripts, for the current run, have not completed.

The reason for the error was that when we closed the Readiness cockpit, the records in the ReleaseUpdateScripts table did not get deleted.

Solution:

Delete all the records from the ReleaseUpdateScripts table.

AX2012 Upgrade – AX2009 Cockpit Issues

We have faced an interesting issue with the upgrade cockpit, executed in AX2009 as part of the AX2012 upgrade. There appeared to be a disconnect between the upgrade cockpit and the batch job – the cockpit showed the script as finished, while the batch job showed it as failed. This turned out to be an issue with the upgrade framework logging.

Error:

The cockpit shows the job as ‘Finished’:

However, the corresponding Batch Task is failed:

Cause

In this particular case the table in question, DEL_AddressStateUpgrade, was in fact populated properly – providing the indication that the upgrade script has completed successfully. Therefore, it appears the cockpit status was in fact correct, while the batch job was not. So what was going on?

It turned out the issue had to do with the way the upgrade framework monitors the state of the scripts’ execution. As scripts are executed, their statuses get written to the ReleaseUpdateControlData table. This table tracks the last record executed by the script. This information is stored in the ControlData container field, and typically holds the RecId of the last record processed. This enables the upgrade cockpit to pause, resume and restart, making sure each record is processed only once. Every time you re-open the upgrade cockpit, all of the scripts are added to the batch job, regardless of their status. This means that each script is re-executed every time the upgrade cockpit is re-launched. The ReleaseUpdateControlData logging is what makes sure that only the data that hasn’t processed previously is operated on, each time the script is executed. (By the way, this means that you can’t simply update the batch job status to ‘Complete’; nor can you update the records in the ReleaseUpdateScripts table – as these statuses do not prevent the scripts from re-executing).

What caused the issue in our case, is the fact that for some reason the record in the ReleaseUpdateControlData, for the script in question, wasn’t updated with the correct ControlData (last record ID). The RecID stored in the ControlData field, was smaller than the greatest RecID in the source table (AddressState in this case).

Solution:

  1. Delete the ‘corrupt’ record from the ReleaseUpdateControlData table
  2. Delete the script’s target tables – in our example the tables populated by the script are ‘DEL_AddressStateUpgrade’ and ‘LogisticsAddressState.’
  3. Re-launch the data upgrade cockpit – which reruns the upgrade script successfully

*We have seen a flavor of this issue, where the ReleaseUpdateControlData record didn’t get written at all. The solution in this case is similar: delete the target tables, populated by the script and rerun the script. This procedure may need to be executed every time prior to re-lunching of the cockpit, as from what we saw the record never got created for the script in the ReleaseUpdateControlData table. Manually creating a record in this table didn’t resolve the issue.