Microsoft Dynamics AX 2012 R2 Services

So what is a service? The best way to understand what a service is, is understanding why you would need a service. Typically, there are a lot of different applications being used in an enterprise. Sometimes this is by design; for example, because a specialized functionality is needed that is not implemented in the ERP system. In other cases, legacy systems are not replaced when implementing an ERP system, simply because they do their jobs well. Whatever the reasons, these or others, the result is the same: a growing number of different applications.

One of the problems with these applications is that they are likely to have been built using different technologies. Because they speak a different language, it makes them unable to communicate with each other. This is a problem that services address by providing a means by which applications can communicate, independent of their technology. They achieve this by adhering to standards and protocols so that, in essence, they start speaking the same language.

A service should have many of the same qualities as modern applications. Applications should be modular, components should be reusable, and everything should be loosely coupled. These principles also apply when developing services. Your services should have a well-defined functionality and should be able to autonomously execute that functionality without interaction with other services.

Services should also be abstract. By this we mean that other applications should not have to know the inner workings of the provider in order to use the service. This can be attained by hiding details such as how data is stored, what technologies are used, and how the business logic is implemented. Abstraction is not an end goal, but a way to achieve loose coupling and reusability.

A service is also self-describing, meaning it can provide other applications with metadata about itself. This metadata describes what operations can be used and what the input and output is. In the case of Microsoft Dynamics AX, this information is published using the Web Service Description Language (WSDL).

All of these qualities make services usable in a Service-Oriented Architecture (SOA). In an SOA, services are published and made discoverable. Services are then composed to create loosely coupled applications.

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 MSMQ adapter in particular is replaced by an adapter that uses the WCF NetMsmq binding. The filesystem adapter remains intact and still allows you to import and export messages from and to the filesystem.

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 a non-XML format.

The following diagram depicts the architecture as it is in Microsoft Dynamics AX 2012 and clearly shows the central role of WCF:

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, which was already available, this enables high availability and load balancing for services.

Services have been around for some time in Microsoft Dynamics AX. AIF was initially introduced with the release of Microsoft Dynamics AX 4.0, with Microsoft Dynamics AX 2009 continuing to build on that. But with the release of Microsoft Dynamics AX 2012, Microsoft has really succeeded in bringing the service functionality to a whole new level. Occasionally, even more features and enhancements are added in new releases and cumulative updates. Let us take a walk through the major changes that Microsoft Dynamics AX 2012 brings to the table.

Integration ports

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

• Endpoints

• Local endpoints

• Channels

• Endpoint users

• Endpoint constraints

Now, integration ports have been added and they provide a simpler way to configure services. There are two types of integration ports: inbound and outbound. Which type you should use for your service depends on whether the message originates from outside or inside of Microsoft Dynamics AX.

The inbound integration ports can be divided into two types: basic and 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.

In Microsoft Dynamics AX 2009, document services had a set of six operations available for use. They are as follows:

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 to create 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:

Microsoft Dynamics AX 2012 already provides a number of services out of the box. These services, together with additional services that can be developed, can be divided into three types. Each of the service types has its own characteristics and a different approach to create it.

In this first chapter, we went through the major changes that Microsoft Dynamics AX 2012 brings for services architecturally and saw that a lot has changed because of the WCF support.

Looking at the new features that were added, it is clear that Microsoft has provided us with a lot of new tools and methods for integration. A lot of work has been done to enable developers to expose business logic in a more intuitive way using attributes. The setup is simplified, and the system services allow you to build entire applications without the need for development in X++.

There are a lot of options to choose from, so it is not always easy to choose the right approach for your implementation. In this book, you will get to know all of the features to help you to make the best choice.

In the next chapter, we will look at the service architecture in more detail and review the many options that are available when deploying services.