Batchable AxdSend-class in Ax2009 and Ax2012

The AxdSend-class is a very easy to implement class, that helps you writing outbound services for Dynamics Ax 2009 and 2012. The AxdSendExchangeRates-class from Ax 2009 (not existing in Ax 2012 anymore) gives you an idea of how to use this class. Unfortunately there are some reasons why the AxdSend-class cannot run as-is in batches:

1. The base class: The AxdSend-class needs to derive from RunBaseBatch.
2. The dialog: The dialog is built on the axdSend-form which does not provide the 'tab'-control for the RunBaseBatch-dialog. This form needs to be modified by adding a new tab-control named 'tab'. Otherwise you would get an exception from the buildControl-method in the DialogForm-class. Btw: The name 'tab' is hardcoded in the tabName-method of the same class.
3. The method sendMultipleDocuments: calling this method results in calling the run-method, and, as you know, batches are executed by calling the run-method...

Changing this would let the AxdSend-class be 'batchable', but unfortunately the class wouldn't be executable in the interactive mode anymore. This, because the dialog form from the AxdSend, which is opened by calling the prompt-method, requires these members being initialized:

• aifDocumentClassId
• serviceClassId
• aifConstraintList
• aifSendMode
• sendActionType
• aifActionId

My suggestion here is to create a new base-class for batchable AxdSend-classes to isolate these modifications as much as possible. You can download a private project  that contains my modifications/new classes for Ax2009 in all concerned AOT-objects:

• AxdSend-class
• axdSend-form
• AxdBatchableSend-class (custom base-class)
• AxdSendExchangeRates as an example how to use the AxdBatchableSend class

The batch will use the endpoint that is stored in the usage-data. So the batch needs to be executed at least once in the interactive mode.
Important note:
Importing this project will overwrite these objects and overwrite all modifications in the same layer, too. Please be careful when importing the project.
These modifications are not compatible with Ax2012, but it requires only slight changes to adapt this to Ax2012. I will upload a project for Ax2012 once Ax2012 is released.

Update: (30/06/11) I fixed an issue with the initialization of the endpoint-list.
Update: (02/07/11) Ups, fixed an issue with the dialog initialization.
Update: (04/07/11) Sends only message if query returns more than one element.

The BC.Net in Dynamics Ax 2012

I've never been a fan of using the BC.Net in client applications. It's true that this is a very easy to use interface, but in most use-cases the Ax-client or the AIF are a better choice. The BC.Net is in fact a regular Ax-client without UI (user interface) and this means that it requires such an installation with the application that has been written - with all the constraints of the Ax-client plus some BC.Net specific ones:

1. Local BC.Net installation (not easily maintainable when deploying on a larger scale)
2. Dynamics Ax 2009 doesn't support side-by-side installations of clients (inflexible architecture)
3. RPC-protocol (constraint for the infrastructure: Firewall)
4. No multi-threading (lousy performance). Using multi-threading with the BC.Net results always in exceptions.
5. No session-management. Only one session at a time. (no scalability) A very complex session-management needs to be written.
6. No contract for the method and its signature (difficultly maintainable when application changes over the time) as it is available with the AIF (service+Xsd or Wsdl with AIF-WebServices)
7. BC.Net requires the Enterprise Portal license when hosted by the IIS (this constraint is hardcoded in the BC.Net)

I wasn't surprised when I read that the BC.Net is no longer recommended to be used directly. The future is services + WCF. I would even say, that the use of the BC.Net should already be avoided whenever possible today. The AIF does offer you many possibilities for doing it today and the standard Ax client is for most other situations good-enough...

PS: And don't forget that there is no COM.BC available with Dynamics Ax 2012.

Exporting AIF endpoints with Dynamics Ax 2012

What a good news in Dynamics Ax 2012! The nightmare while deploying AIF endpoints has finally an end and you do obviously not need to be worried about changed classIDs and RefRecIds (AifDataPolicy does reference AifDocumentField by the RecId) anymore. Here's a guide how to export the endpoints by definition groups in Ax 2012 on Msdn.

.Net 4.0 client profile not enough for the Dynamics Ax BC.Net

On Dilip's blog on Dynamics Ax, Dilip suggests in his article on BC.Net compatibility settings, to switch from .Net Framework 4.0 Client Profile to .Net Framework 3.5 with the argument, that this makes sense because the BC.Net is compiled on top of the .Net 3.5 Framework.

I was surprised reading this, because Microsoft promised backward compatibility and the .NET Framework 4:

The .NET Framework 4 is backward-compatible with applications that were built with the .NET Framework versions 1.1, 2.0, 3.0, and 3.5. In other words, applications and components built with previous versions of the .NET Framework will work on the .NET Framework 4.

The errormessage when compiling the BC.Net application against the .Net 4.0 client was:

...could not be resolved because it has a dependency on "System.Web....

So why do BC.Net projects don't compile with client profiles ? To answer this, browse through the BC.Net assembly with the .Net Reflector or, because it's open-source and free: ILSpy and you will notice that the BC.Net does reference for the BC.Net 2012 'Microsoft.Dynamics.AX.ManagedInterop' and this references the 'System.Web' assembly. The BC.Net 2009 does directly reference the 'System.Web'-assembly.

Now, having a look on Msdn for the .Net 4.0 client profile, it is documented:

The .NET Framework 4 Client Profile does not include the following features. You must install the .NET Framework 4 to use these features in your application:

• ASP.NET
• Advanced Windows Communication Foundation (WCF) functionality
• .NET Framework Data Provider for Oracle
• MSBuild for compiling

The 'System.Web' assembly, which is part of the System.Web-namespace and so not part of the reduced .Net framework runtime, requires the full .Net 4.0 Framework. Now select the full .Net 4.0 Framework for compatibility and compile it again. It will work. Selecting the .Net 3.5 client profile will, of course, result in the same error. As I mentioned, this is true for the BC.Net of Dynamics Ax 2009 AND 2012.

UPDATED 02/07/2011: Dilip updated his article with a very interesting information about the runtime-compatibility of applications referencing the BC.Net assembly: It requires the useLegacyV2RuntimeActivationPolicy attribute to be set to true. But read his article fur further information.

UPDATED 17/112011: Dilips first article was about the error message during the compilation and I was referring to the compile-time compatibility that .Net4 guaranties. The updated article now is talking about the runtime-compatibility.
Anyway, the useLegacyV2RuntimeActivationPolicy is, despite of its name, not executing the application in a different CLR context (CLR2), but does translate some legacy shim APIs to the current CLR4, as explained in this great article about this attribute. So even by using this attribute we are, as promised by Microsoft, fully .Net 4 :-)