Microsoft Dynamics AX 2012 Services: Everything you need to know about implementing services with Microsoft Dynamics AX 2012 is contained in this hands-on guide. Easy to follow and totally practical, it's a must for both new and experienced AX Dynamics developers.

To make the previous explanation about services more concrete, we will take a look at three very different scenarios in which services can be used.

Depending on the requirements of your projects, a different architectural approach will be needed. To make the right decisions when designing your solutions, it is important to understand the services and AIF architecture.

Compared to Microsoft Dynamics AX 2009, there have been a lot of improvements made to the service architecture in Microsoft Dynamics AX 2012. The biggest improvement is the native Windows Communications Foundation (WCF) support. As a result the proprietary Microsoft Message Queuing (MSMQ) and BizTalk adapters that were available in Microsoft Dynamics AX 2009 have been deprecated and replaced by adapters that use WCF. The file system adapter remains intact, and still allows you to import and export messages from and to the file system.

All services are WCF services and are hosted on the AOS. When an application wants to consume these services on the local network, no further deployment is needed, because it can connect directly to the AOS. Just like with Microsoft Dynamics AX 2009, deployment on Internet Information Services (IIS) is needed for consumers that are not on the intranet. However, the services themselves are no longer deployed on IIS; instead a WCF routing service on the IIS routes everything to the AOS.

If you want to modify messages before they are received or after they are sent, you can use pipelines and transformations . Pipelines only apply to the body of a message, and are handled by the request preprocessor and response postprocessor . You can use transformations to transform a complete message including the header. This allows you to exchange messages in non-XML format.

While not displayed in the diagram, there is now load balancing support for services using Windows Server Network Load Balancing (NLB). Combined with NLB for IIS that was already available, this enables high availability and load balancing for services.

The first major feature that has been added to this release is that the AOS is now the host for the Microsoft Dynamics AX 2012 services. In previous releases, the exchange of messages was either through adapters such as the file system, BizTalk, and MSMQ adapter, or services that were exposed as WCF 3.5 services through IIS. With the latter, IIS was acting as the host for the WCF services.

With this new release of Microsoft Dynamics AX, services will be exposed as WCF 4.0 services hosted directly in the AOS Windows service. As long as intranet users and applications are consuming these services, no IIS is needed.

Microsoft Dynamics AX 2012 provides a lot more support for WCF. Proprietary adapters such as the BizTalk adapter and the MSMQ adapter that were previously available, are now obsolete and no longer available. Instead, support for MSMQ and BizTalk is provided by a native WCF equivalent of these adapters.

This does not mean that creating custom adapters using the AIF adapter framework is not supported anymore. Custom adapters can still be added by implementing the AifIntegrationAdapter interface.

Out-of-the-box, Microsoft Dynamics AX 2012 comes with the following adapters:

In Microsoft Dynamics AX 2009, there was a lot of configuration required to get AIF up and running. This included configuration of the following:

Now, integration ports have been added and they provide a simpler way of configuring services. There are two types of integration ports: inbound and outbound, depending on whether the message originates from outside or inside Microsoft Dynamics AX.

The inbound integration ports can be divided into two types: basic or enhanced. Out-of-the-box, Microsoft Dynamics AX 2012 already has some services that are associated with basic integration ports. These have been deployed and enabled by default. We will discuss how these basic ports differ from enhanced ports in later chapters.

Instead of having Microsoft Dynamics AX specific endpoints and channels, integration ports use native WCF to deploy services and therefore endpoints, security, behaviors, bindings, and so on. All of this is configured using the WCF Configuration utility. By default, integration ports are hosted on the AOS using the NetTcp binding.

Previously, when services were deployed on IIS, they used the .NET Business Connector to communicate to the AOS. This has been replaced by a WCF routing service that implements the IRequestReplyRouter interface. Regardless of whether services are consumed from the intranet or the Internet, they are always processed by the AOS. So when services are deployed to be used on the Internet, they will be deployed both on the AOS and on the IIS. The AOS hosts the service using the NetTcp binding and the IIS has a WCF routing service that will forward service requests to the internal services hosted on the AOS.

Using transformations, Microsoft Dynamics 2012 can transform inbound messages from a variety of formats into the format AIF can understand. Likewise, outbound messages can be transformed from the AIF format into the format required by external systems. There are two types of transformations that can be used: Extensible Stylesheet Language Transformations (XSLT) and .NET assemblies.

You can create XSLT transformations by using any text editor, but tools such as BizTalk MAPPER, Visual Studio, or Altova MapForce make it very easy. .NET assemblies are DLL files that can be compiled using Visual Studio and do transformations in code. This is especially convenient for transforming from or into a non-XML format. Some of the tools available can actually generate both the XSLT and the managed code needed to compile a .NET assembly.

In Microsoft Dynamics AX 2009, document services had a set of six operations available for use:

In Microsoft Dynamics AX 2012, there are two additional operations available for developers:

One of the major changes in Microsoft Dynamics AX 2012 is the ease and flexibility by which you can create custom services. Instead of having to provide all the technical details on how the documents need to be serialized by implementing AifSerializable, you can now easily attribute class instance methods. These attributes are used to identify service operations and data contract members.

Prior to Microsoft Dynamics AX 2012, the RunBase framework was used to provide a generic way of creating processes and batch jobs in the system.

In Microsoft Dynamics AX 2012, the SysOperation framework allows you to leverage the power of services to execute your business logic in Microsoft Dynamics AX. When you create a service, it encapsulates the business logic so other components within the system can use the service instead of accessing the business logic themselves.

The SysOperation framework makes use of the Model-View-Controller (MVC) pattern by using multiple components that each have their own responsibilities. These components separate the business logic from the code that is responsible for rendering the GUI and the classes that represent the data model. This is a great leap forward from Microsoft Dynamics AX 2009, where everything was written in one class that extended Runbase.

Also important to note is that when a service has been created for the SysOperation framework, it requires little effort to expose the same service to the outside world. You can simply expose it using an integration port.

So the advantages of the SysOperation framework can be summarized as follows:

Document services use documents to represent business objects such as purchase and sales orders, customers, vendors, and so on.

A document service is composed of the following components:

When creating document services, developers need to make sure that the business object is mapped correctly to the document query. The document services framework will handle all other things such as the serialization and deserialization of XML, date effectiveness, and so on.

Document services can be deployed using the integration ports and all available adapters can be used.

Custom services were already available in Microsoft Dynamics AX 2009, but support for Extended Data Types (EDTs) was limited, which resulted in developers having to provide custom serialization and deserialization logic.

Microsoft Dynamics AX 2012 introduces the concept of attributes. Attributes provide a way to specify metadata about classes and methods. Two of these attributes are used when creating data contracts: the DataContractAttribute and DataMemberAttribute attributes.

The DataContractAttribute attribute is used to define that a class is a data contract. The DataMemberAttribute attribute is added to methods of data contracts that represent data members that have to be exposed. This way of defining data contracts is very similar to other programming languages such as C#.

Support for more complex data types such as collections and tables has been added so that these types can be serialized and deserialized without developers having to provide the logic themselves.

In a typical custom service you will find the following components:

Custom services can be deployed using the integration ports and any available adapter can be used.

These services are new since the release of Microsoft Dynamics AX 2012. The main difference between these services and the previous two types is that they are not customizable and are not mapped to a query or X++ code. They are not customizable because they are written by Microsoft in managed code. One exception is the user session service, which is written in X++ code but is generally considered as a system service.

There are three system services available for use in Microsoft Dynamics AX 2012: the query service, the metadata service, and the user session service.

Now that it is clear what types of services Microsoft Dynamics AX 2012 has to offer, the question arises as to when each type of service should be used. There is no simple answer for this due to the fact that every type has its strengths and weaknesses. Let us take a look at two factors that may help you make the right decision.