Dynamics AIF Tutorial Series Part 1: Understanding AIF in Dynamics AX 2012

While I was working on my reporting series for Dynamics AX, I realized that it was needing some foundational knowledge. To see the true BI functionality of Dynamics AX, one needs a base understanding of Forms, Services, and Enterprise Portal. Thus, I decided to put together a quick beginning series on Services that is designed to take a beginner and get him/her up to the point where they can get services up quite quickly. If you followed my beginning FORM series, you will see that there is a common, overlooked theme in Dynamics AX development – rapid development for common tasks and ease of use. Then if things require more complexity, you can get do that as the framework allows for this. But what is most surprising is that if one just knows the interface, he/she can do many common development tasks with no code. In this series, we’ll demystify the AIF, build a few services both with and without code, and get an introduction to what all of these definitions mean. You will also learn about some of the differences between services in 2012 as opposed to 2012.

For Part 1, let’s define our key terms and make sure that we are good on that end. Then, we will get started with the development in the other parts of the series.

What is a Service?

Problem: Your company’s new Dynamics AX implementation is working out wonderfully! People love the form functionality and all of the data into it. But you have a problem. You need for 3 other applications to be able to see and update that data if necessary. You’ve been asked to make the customer information available to 3 different applications:

A Java application which takes care of sales orders that were purchased from a vendor.
An MVC .NET application which allows sales forms to display on mobile phones (note: if you are going towards mobile development functionality, MVC is definitely the way to go), which sales representatives can update while out in the field
A Ruby on Rails application that allows for specialized inventory tracking
A custom mobile application that is specific to the human resources department that takes advantage of SharePoint’s survey functionality to help employees enter honest suggestions that can help the company

Solution: Utilize a Service. A service will form a direct connection to Dynamics AX and take care of all the coding to get things connected. Then, all you have to do is direct the other applications to connect to the service instead of Dynamics AX. That way, you don’t have to worry about something like getting Ruby on Rails code to run in Dynamics AX.

So, if you understand that a service is code that is hosted (means that it can be found and used somewhere by others) and that AIF is the programmatic framework that Dynamics AX uses to build and expose services, you are good. Let’s finish this post out by putting in some key terms that you will need to understand as we go through this series. This is more of a reference than anything else as I’m a firm believer that we understand terms in Information Technology by ‘doing’. Remember to refer back to these as we do the tutorials, and they will make more sense.

If you are a developer wishing to learn more then it may be wise to check out our Boot Camp, which takes you from zero to hero with some serious hands-on lab action.

Key Terms that you need to know to Understand, Use, and Develop Services in Dynamics AX

Term	Definition	Why you Care
Adapters	Programmatic add-ins that simplify the process of getting Dynamics AX to work with some other framework.	Many of these have been removed in 2012 as Dynamics AX has become easier to integrate. Still, there are some good ones to work with that will make your life easier when it comes to adding functionality.
AIF	Application Integration Framework. This is Microsoft Dynamics AX Service Oriented programming framework.	This is where you do all of your programming for Services in Dynamics AX. This runs as WCF but provides a friendly way to get services up – in many cases with no code.
AOS	This is the term for the component of Dynamics AX that runs all of the programming logic runs on the server. (AKA Application Object Server)	Don’t get confused. This is where all programmatic Dynamics AX functionality runs.
Asynchronous	A service that doesn’t instantly take commands or information from a client(application attempting to communicate with it)	It’s about scheduling. For example, if an order entry application processes 500 orders a day, you can schedule them all at midnight rather than at the time that they occur.
Attributes	Descriptions that appear in brackets in code which affect the run-time behavior of your application.	For example, when you mark a class as a data contract, the runtime knows that this class defines how the data turns into XML.
Basic Integration Ports	This is the 2^nd of the two types of data ports: It is a rapid sort of port that you can create by basically checking a checkbox in a wizard. Quick and easy to configure.	Use this during development to test your service, not production. The idea behind this is so that you can rapidly get your service up to look at the functionality. Security settings and all kinds of other protocols are not included. It is just basic.
Change Tracking	Allows you to keep track of which documents have changed so that you can send out updates.	If documents represent sets of data (as defined earlier), than wouldn’t it be nice if we had some way of automatically sending updates to clients when that data changed. That is what change-tracking does.
Client	This is used to access Dynamics AX from a Windows Machine.	A lot of stuff runs right on your machine in Dynamics AX. This prevents it from putting a load on the server and uses your good old fashioned desktop to get things done.
Custom Services	The 2^nd of 3 categories of service that you need to know. These are services that we create with classes.	This gives us the ability to do anything. This is a Dynamics AX 2012 feature, but as you will see in our tutorials, these rock. These are the services that we write to communicate with the outside world.
Data Contract	A class that tells Dynamics AX how to take x++ objects and “serialize” the data to a format that can be transmitted over a network.	This actually really easy to do as you will see. In the most common case, you just tell the framework how you want to name certain objects(like columns in a table) in the XML that clients see.
Document	A class that becomes XML for transmittal between the client and the server. Sets of data are a great example of a document.	Information queries are classic cases of document classes which can be used for sending out information.
Document Services	The 3^rd of 3 categories of services that you need to know. These are quick services that we can configure to communicate with outside applications with a wizard. Great for exposing information.	These are awesome. Using a wizard, you can build some very nice services quite quickly. It brings a whole new meaning to the term ease of development & will make it easy to share your Dynamics AX data with other apps. Note, there are already 90 of these running on AX!!!!
Enhanced Integration Ports	There are 2 types of data ports(this is the 1^st): Enhanced and Basic. Enhanced ports have all the works and configuration options, so that we can do anything with them.	Use these for development. This way, you will have all the options available.
IIS	This is what is used to host your service so that other applications can communicate with it.	If you want http communication and all the good stuff, you need this.
Inbound Ports	Most common type of integration port. Clients can request data on command but Dynamics AX can also accept data.	These allow for everything. Use these to answer data requests on demand or accept data from a client application.
Integration Ports	Used to be called endpoints, but now they are called integration points. These are the URL’s that users of the outside world use to call your service.	For a service to be a service, there has to be a way to invoke that code. Typically, this is done through an integration point which is configured with a url that can be used to call it.
Message Queue	A place that messages can reside until they are ready to be received by the client or service. A queue is a storage location where messages can stay until the service is ready for them. That way, Clients don’t have to wait to send messages.	Just say that your Dynamics AX application is busy & can only accept messages at midnight. Sometimes, we can’t tell other applications to wait to send messages. No problem, Queues solve that problem along with many others for us.
Outbound Ports	Integration ports that only send out information on their schedule. Clients have no ability to request when they want the information. This is determined in the settings by you.	Not as common as inbound. This is good if you want to control when information goes out. So, you could say to only send out the orders at midnight, so you don’t put too big of a load on the server.
Pipelines	X++ classes that can take XML and change it before it reaches its destination.	Sometimes, clients don’t send out messages in a format that Dynamics AX can accept. In that case, use a pipeline to get the information in an acceptable form.
Processing	All of the changes that take place on information as it being transmitted between the client and the server.	Transforms and pipelines will act on this (defined in this table)
Proxy	A class generated from a WSDL document that make it easy to have external applications communicate with a service. A proxy is a class autogenerated to take care of all the complex stuff, so that it will be easy to make applications communicate with your service.	The process of connecting a client to a service could be hard – think about network connections, protocols, and everything. Thankfully, you don’t have to worry about that.
Serialization	Convert ‘Objects’ which are used by the programming framework to do programmatic manipulation into a format of data that can be transmitted over a network.	Essential concept to understand. Programming data has to be transferred into a format that can be transmitted by the network – usually text or string data but there are other options.
Service	Code running on the AOS or in IIS that can be used to share data across applications or even within the same application	When you have another application that needs to communicate with Dynamics AX, you can bet utilizing a service will usually be the answer
Service Contract	Class that has the actions that a service can do.	Really easy to implement. Maybe, you have a class which needs to update data. Easy enough. You create a method in a service contract class called update. The client can call it by name.
Service Group	A wizard based unit of deployment to get your service up and running.	These are awesome. A service group represents all of the settings and classes that you need to get a service up and running, so that it can be used by clients.
Synchronous	When an update happens, it is instantly processed	You got a real-time application, for example. Then, you want processing immediately – no latency with scheduling.
System Services	The 1st of 3 major categories of services that you need to know. There are 3 groups of this type of service: query service – allows you to pull information & return it as a .NET data set. Metadata service allows you to pull object and table names. User Session service allows you to get information about the current user.	The 1^st of the big 3 Categories that you need to know! The System services are built-in and made to enhance the functionality of AX. These should be used for internal functionality, not external functional. So, for example, if you wanted to build a custom component to Dynamics AX, using these would be ideal.
Transforms	Like pipelines, in that these can change information in transit, but these are .net classes that can change ANY information, not just XML before it reaches its destination.	Classic example: an application will only send CSV files or text files, but Dynamics AX needs XML to understand the information. No problem, transforms allow for you to easily convert the format, so that you don’t have to change the external application.
Value Substitution	These are predefined alterations of data to get them in a format that Dynamics AX understands.	For example, suppose that system A uses company code 323. However, say that Dynamics AX calls the same company “ABC”. A value substitution would be a place in the pipeline where you convert 323 to ABC so Dynamics AX can store it.
WCF Runtime	The regular .NET Service Oriented framework for programming. The Dynamics AX implementation of services (AIF) is actually using this to deliver services.	Often troubleshooting Dynamics AX Services (AIF) errors is really troubleshooting WCF errors.
WSDL	AKA Web Services Description Language. This is published form of markup by your services that allows third party applications to consume the information.	WSDL is the ultimate “output” goal.. Once it is generated, other applications can easily communicate with your service. WSDL allows for applications to automatically communicate with the service through what are known as proxies.
XML	The way to have applications communicate is to have a universal communication mechanism. XML is simply a markup language that can be recognized by everything.	The traditional way to get communication working between services. What is XML – it is markup based. Then, after that, it is whatever you want it to be. The service and the client agree on the terms to use.