AIF Error – ContractFilter mismatch at the EndpointDispatcher

If you’re seeing this error when consuming an AIF service, the reason may be that changes were made to the service object in the AOT, without regenerating the incremental CIL and reactivating the inbound port.

In our case, one of the developers changed the namespace of the service in the AOT from the default ‘http://tempuri.org’ to ‘http://schemas.microsoft.com/dynamics/2011/01/services.’ The service was refreshed in the ‘Services’ form, and the inbound test file was updated with the correct namespace. However, since the Inbound Port wasn’t reactivated, the service endpoint (in our case the client used a File System Adapter), was still deployed with the old namespace, resulting in the error below. Reactivating the port (and Incremental CIL) updates the endpoint with the proper namespace and resolves the issue.

The request failed with the following error: The message with Action ‘http://schemas.microsoft.com/dynamics/2008/01/services/<Service>/<Action> cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
View the exception log for more details.

DIXF Crash – Decimals in CSV Source files

Wolftek.Dynamics.AX

We have noted an issue with the DIXF *.CSV source file import, where the presence of decimal values causes the DIXF service to crash. The issue occurs with standard AX entities, in our case the SalesLines entity. The error details in the Event Log are quite obscure, rendering the fix unintuitive.

Yet, the solution is very simple. To get around the error, you can change the CSV file extension association from Excel to Notepad. As can be seen below, the file type in the Windows Explorer changed from ‘Microsoft Excel Comma Separated Values File’ to a ‘CSV File.’ As a result, the CSV files, containing decimal values, import without an issue.

Before:

After:

AIF Sales order document service – XML Mystery

 

We were asked to troubleshoot an interesting issue. The client was generating the sales order confirmation documents, leveraging the standard AIF SalesOrder service. The generated XML document contained incongruent data. The Header section, driven by the SalesTable data, contained information from an entirely different sales order, than the one being confirmed. The Lines section, on the other hand, was absolutely correct – information coming from the correct sales order.

The simplified XML looked as follows. Note the SalesId in the Header section (A) is not the same as the SalesId in the Lines section (B). The actual sales order being confirmed was B– the SalesId in the Lines section.

 

I’m sure you would agree that this picture is bizarre, to say the least. The AIFCorrelation also ended up being skewed. While the document history indicated that the document belonged to the correct SalesId B, the actual correlation was pointing to the incorrect SalesId A.

What this turned out to be was an incorrect customization added to the axSalesTable class. The developer added a new field to the document, by extending the class with a new parm method. Unfortunately, he had made the mistake of creating an inner join between the table from which he wanted to pull the value and the salesTable, and did so using the axSalesTable’s global table buffer variable salesTable – the buffer that drives all of the information in the Header section of the document, when the object is serialized into XML! The inner join resulted in a selection of an entirely different salesTable record and reset the salesTable buffer!

 

 

 

Mystery solved J

 

DIXF ODBC Source Automation – AX2012 R3

 

The AX2012 R3 version of DIXF has introduced automation for file based integrations. It is now possible to configure a periodic processing to monitor a directory for incoming files and to import them into the DIXF staging tables. Furthermore, the ‘Execute Target Step’ setting on the definition group execution, allows the source-to-staging process to also execute the staging-to-target logic. This turns DIXF into a rounded solution, which supports full end-to-end source to target scenarios out of the box. Add to all this the excellent staging and tracking capabilities, and this turns DIXF into an excellent candidate for integrations, rivaling in many respects the AIF framework.

The automation functionality described above had to be custom coded in the previous versions of AX – see the following blog for example.

What is still missing from this version of DIXF, however, is the automation capabilities for other sources, such as ODBC. That is, if you’re reading the source data from SQL, for example, you’re still unable to execute the import steps in a Periodic batch job.

If you do need to implement such automation, have a look at the following script for inspiration.

static void DIXF_Automation_ODBC(Args _args)

{

    DMFDefinitionGroupEntity entity = DMFDefinitionGroupEntity::find(‘<Processing Group>’, ‘<Entity>’);

    DMFStagingWriterContract contract = new DMFStagingWriterContract();

    DMFStagingWriterService service;

    contract.parmExecutionID(‘wolftek1’); //todo: get from num seq

    contract.parmDefinationGroupName(Entity.DefinitionGroup);

    contract.parmEntityNameList(Entity.Entity);

    contract.parmFilePath(entity.QueryForODBC);

    contract.parmRunInBatch(true);

    contract.parmExecuteTargetStep(true);

    service = new DMFStagingWriterService();

    service.executeService(contract);

}

AIF Error – Return type void is not supported

Wanted to mention this briefly, in hope that it may save someone some headaches.

In case you are seeing the following error in the AIF Exception log: “Return type void is not supported,” followed by “Unsupported type,” there may be a compilation issue with one of the axBc classes of the service.

Change the Model Manifest’s Deployment Layer

As you may know the AX utilities – AXUtil and PowerShell – do not support changing the destination layer in the model manifest. The model, by default, gets imported into the same layer, from which it was exported. For reference refer to: https://technet.microsoft.com/en-us/library/hh433512.aspx.

This said, if you need to import the model into a different layer, than the one from which it was exported, you can employ the following procedure.

Open the binary *.axmodel file for editing in a text editor, in order to modify its manifest. The caveat here is that Notepad, for instance, cannot be used, as it can’t properly display/save the binary information. One editor that we like utilizing is SciTE, which can be downloaded here: http://www.scintilla.org/SciTEDownload.html.

Once opened in the editor, change the model’s manifest, to specify an alternate deployment layer and save the file.

 

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