Microsoft Dynamics AX 2012 - A Dive Into Services

With the release of Microsoft Dynamics AX 2012, services are a key role that enable many parts of AX. This includes from Office, to internal use, to extending and working with complex datasets, and even to expose custom busienss logic.

To help better understand services in AX 2012, lets first take and understand what services means. There are three distinct service context, which are.:

• System Services - These are services that come as part of AX 2012 offering,
  like the Metadata Service, User Session Service & Query Service
• Document Service - This carries similar concepts and design on previous version of AX, in that a document service is meant to wrap complex datasets, for CRUD based operations. There are some differences now, and we will review these.
• Custom Services - These are meant to wrap simple datacontract needs, or to expose custom business logic. I will note here: These are never recommend to handle complex data operations. Use Document services for that.

System Services
System Services are meant to give a window into the Dynamics AX 2012 world. Part of that world involves Query Service, as well as the Metadata Service. These two services are meant to be very specific uses. The Query Service is meant to take and offer an ad-hoc ability to query datasets, from AX 2012. Now I must say this should be used with caution. If this query, or integration is meant to be re-used in any fashion, you should build a query object, and create a document service from it.

There is a pretty decent example on MSDN, that shows how to use a Windows Form, and Dataviews / grids, for showing off the power of AX 2012, and the Query Service, located here.: Walkthrough: Calling the Query Service with a User-Defined Query [AX 2012]

The meta data service is meant to give the ability for other LOB applications to query against to allow AX 2012 to self describe information about objects that reside within the system. Here again, the use should be limited.

Document Services
Document Services are meant to truly be the path, in which any real complex operations of CRUD, or Create, Read, Update & Delete, operations are meant to be executed via. The idea here, is that a Query Object, or set of Query objects created within the AOT, represent a document service, that is deployed, and consumed by either AX itself, or other LOB systems.

This includes both master data, like EcoResProduct (or Products), as well as Customer, Vendors, and event transactional data like Sales Orders and purchase orders. This has improved a lot since a AX 2009, and the ability to quickly deploy such services in AX 2012 is now such an easy task.

Custom Services
Custom services represent, to most C# developers, something that has been common for a little while. This is, DataContracts, and Service Oeprations. As mentioned above, this is not meant to represent complex data opertaions, but instead, to expose simple data contracts, as well as custom business logic through service operations.

Finally, There are some guidelines when thinking in terms of use of services, which include design patterns around "chatty" services and integrations.

Where possible, it should always be considered, to take and perform the least amount of calls as possible. This means instead of sending a single Entity Object that represents a Document Service create, for example, for a given table, per service call, the better approach would be to build up a collection of said objects, with a single call for the entire collection.

Of course, this might not be always applicable, where you look to transactional data needs, where the very nature of the integration leans towards possible one-off single calls. Still having this kind of design approach in mind, will help in *not* creating possible performance issues around your services related integrations and needs.

There are also other topics, that I will continue to dive into from this post, including the use of Query Objects being represented as OData feeds, and a deeper dive into the Business Operations Framework and the use of the SysOperations for enabling service use to replace the RunBaseBatch framework for business logic and reports.

That's all for now, but check back soon as I dive deeper into each of these topics, and show off real world examples for each. Just keep in mind, the idea is to abstract and extend via SOA, or service-oriented architecture. There should never be a reason, now, to ever go driectly to the AX 2012 database. All interactions, should always take place via the application layer, and typically through services.

Well that's all for now, but check back soon, as more to come! Till Next time!



"Visit the Dynamics AX Community Page today!"