WCF services in AX 2012

Since X++ can be compiled to CIL in AX 2012 it became possible to change the way how X++ services are implemented.
Now all X++ services are WCF services and they are executed in the WCF runtime hosted on the AOS.
It is really hard to overestimate the benefits of this feature. Let me mention here just a few of those:

1. Every service has now WSDL definition. This means that it is extremely easy to generate proxy classes for those services for external clients using standard tools like svcutil.exe (add service reference in VS) or WSDL2java.
2. There is a new protocol to communicate with AOS now – WCF, in addition to the regular RPC.
3. Seamless integration with many applications\technologies, like MSMQ or BizTalk.
4. Simple and standard security model.

It is really nice to see that powerful and standardized technologies are coming to AX.

And one more thing to mention. In AX 2012 all AIF and services concepts were simplified significantly. Just look how AIF menu section was changed:


And most of the setup can be done now just from this very nice form:

X++ can be compiled to CIL in AX 2012

In AX 2012 X++ code can be compiled into CIL and executed in CLR environment hosted on the application object server. This means X++ became almost a .NET language. Almost, because there are still some X++ artifacts that can only be interpreted, for example forms. However the vast majority of server-side code can be compiled into CIL.

Because of that it is important to remember to regenerate CIL after changes have been done to the code. Since CIL compilation takes quite some time, it is not done automatically during regular X++ compilation. There are new compilation commands – Generate Incremental CIL (rebuilds assemblies that are affected by the change) and Generate Full CIL (rebuilds all assemblies). Those commands are applicable to the whole application and not to a specific X++ object (class, table, etc.). AX automatically determines what X++ objects should be compiled into CIL based on the registered entry points, e.g. if it is specified that some method should be executed in CLR, then the whole “using” reference tree of this method will be compiled into CIL.


There are several ways to specify that some code should be executed in CLR instead of X++ interpreter. Right now I want to show only one of them just to illustrate how easy it can be.


TestILExecution job will be executed using X++ interpreter (just in the same way as in previous AX versions), but postSalesOrderPackingSlip() method will be executed in CLR. As you can see, postSalesOrderPackingSlip() method is a standard method of a standard X++ class. Switching will happen because this method is registered as a service operation of FormLetterService service, and the service itself is a member of the AxClient service group which is deployed on the AOS.