AIF Top Ten



AIF Top 10 in Dynamics AX 2009


 


You’ve probably already heard that the release of the new version – Dynamics AX 2009 – is on the horizon. For those of you who are using AIF or are planning to use it, the next version has some great features.


 


Here is my list of the top 10 AIF features in Dynamics AX 2009.


 



  1. Services


The programming model for exchanging data has dramatically changed for the better in Dynamics AX 2009. Now, any X++ class can be exposed as a service. If your class methods follow a few simple rules, they can be exposed as service operations. A class method can be exposed as a service operation as long as the method is declared public and the method parameters are one of the primitive types or an object that implements AifXmlSerializable.


 


An AX service can be consumed internally by X++ code or you can expose that service externally through Web services. Now, you also have the ability to consume an external Web service from X++ code and access the service operations through Intellisense.


 



  1. Document Services


Document services are the way that Dynamics AX implements the service architecture to exchange data with external systems. AIF is now based on document services. A document encapsulates business functionality and logic such as sales order, customer, and so on. Instead of Ax<Document> classes being the external interface for exchanging data, now document services are the external interface.


 


When you use one of the transports such as BizTalk or the file system to exchange data, AIF uses the document services internally. You can also expose the document services externally as Web services. When exposed as Web services, the document services support WCF.


 



  1. More Documents


Now there’s even more business functionality represented in AIF. The latest version of Dynamics AX delivers about 35 new documents. AIF now supports picking lists, fixed assets, expense reports, general journal entries, customer payments, and return orders to name a few. See the what’s new documentation (available at RTM) for a full list of new documents.


 



  1. Default Endpoint


Dynamics AX now ships with a default endpoint. This means you can get data exchanges up and running without having to configure a specific endpoint. When you send a message into AX and you want to use the default endpoint, only the action is required to be specified in the message header. You no longer have to specify the MessageId, SourceEndpoint, SourceEndpointUser, or DestinationEndpoint elements in the message.


When AIF uses the default endpoint, it verifies that the user sending the message has the appropriate security. The way the user information is retrieved depends on the transport method. For example, if you use the file system, AIF considers the file owner as the submitting user. Of course, you can still set up specific endpoints when you want to specify the endpoint users, specify endpoint constraints, and implement other functionality that’s only available to specific endpoints


 



  1. Parallelism


You can now specify on a per channel basis that messages are processed in parallel. Until now, messages were always processed sequentially in the order they were received. By selecting the Parallel processing field for an inbound channel on the Channels form, you specify that the AOS process messages in parallel. This enables the ability to scale out your implementation and potentially improve performance by adding more than one AOS to process messages.


 



  1. Services Support WCF


Any Dynamics AX service exposed as a Web service is exposed as a WCF Web service. This includes the document services included with AIF. Services exposed as Web services in AX support both the basicHttpBinding and wsHttpBinding (basicHttpBinding is the default).


 


This means that all the configuration options available for WCF services are available for the document services and any service in AX. This also means that Dynamics AX services can be implemented as part of your overall SOA strategy. Look here for an illuminating discussion of the advantages of WCF services.


 



  1. Consume Web Services


Services are now an integral part of AIF and are the external interface for business logic in AX. You can also consume a Web service from X++ with full IntelliSense support. You simply add a service reference and the service is available to you in the code editor.


 


What does this mean for me, you ask? This translates into a whole new world of integration scenarios. For example, you cou ld build functionality that takes item information (quantity, weight, size, and so on) from a form, calls a Web service, and then presents various shipping methods and costs to the user. If a Web service that calculates tax amounts was available, you could embed that functionality directly into a form in AX. Powerful stuff, I say.


 



  1. Easier Batch Processing


This new feature isn’t specific to AIF, but configuring the batch jobs and tasks is such a breeze now. If you use AIF Web services, this won’t mean much. But if you use the AIF adapters to exchange data, you’ll be well pleased.


 


Setting up the batch is as easy as (1) adding the batch job, (2) adding some tasks to it (one for each of the four AIF message processing classes), and (3) changing the status to Waiting. You can modify each task so that it’s dependent on the completion of the previous task so that the tasks execute in the proper order.


 



  1. Document Object and Data Objects


In version 4.0, the Axd<Document> class was the interface to AIF and a message was passed to this class as an XML string parameter. Now, the document service is the interface to AIF and this class has service operations that take various object parameters, one of which is a document object parameter. The document object encapsulates all the data being passed to the service.


 


The data objects have a programmer-friendly interface and implement XML serialization and de-serialization. The document object is the top-level data object so technically it is also a data object. Using these data objects is much easier than coding the XML string, ensuring that it validates against the message and documents schemas, and so on.


 


For example, AIF would generate three data objects to represent the Customer document:


 





    • Customer – represents the Customer XML element


    • Customer_CustTable  – represent the CustTable XML element


    • Customer_CustAddress – represents the CustAddress XML element

 



  1. AIF Document Service Wizard

 


This wizard is the key to creating your own custom services (and documents). Technically, this is not a new feature, but this replaces the Axd Document Wizard in the previous version. First you must create the foundation query for your service. Then you run this wizard, specify the supported service operations and it creates the service class and all the other associated classes including:


·         A default project in the AOT containing all the classes and objects created by the wizard.


·         An AOT node for the service


·         An AOT node for each service operation that the service supports..


·         The service class, the document class, and the data object classes – The actual classes that encapsulate the data exchange business logic. Found in the Classes node in the AOT.


·         A macro that contains all the data types for the data objects referenced by the service class.


·         AxBC (Ax<Table>) classes that provide an object API on top of the database tables referenced in the query.


·         A job that generates the schema for the service class.


Comments (6)

  1. frank.vanhamel@realdolmen.com says:

    Subject : inbound error "Local endpoint CEU doesn’t exist" – AIF – File System Adaptor

    Hello,

    Can anybody help with the following inbound error : inbound error "Local endpoint CEU doesn’t exist"

    I have done the following setup :

    * I have set my company "CEU" as a local enpoint, with as local endpointID "CEULocalEndpoint"

    * I have setup the "AifFileSystemAdapter" as transport adapter. I set this active with the receive or send direction

    * I created two directory maps (inbound and outbound). I created an inbound channel and an outboundchannel and I linked both channels to the

    correct address (inbound map end outbound map). I set theze active and I selected the file system adapter as adapter. In a last step I linked

    the inbound channel to the outbound channel via the response channel field

    * I enabled the SMAServiceOrderService under the services. Under this service there are 6 actions;SMAServiceOrderService.create,

    SMAServiceOrderService.delete, SMAServiceOrderService.find,

    SMAServiceOrderService.findkeys,SMAServiceOrderService.read,SMAServiceOrderService.update

    * I have set up an endpoint and I linked it to the Local endpoint Id, I set it active and I linkes the outbound channel id to it. I selected no

    constraints and defined the user as user type (admin). This name is also allowed on both directories map

    * I enabled the different SMAServiceOrderServices and I defined the different field via the data policies button

    * I have setup the different 4 batch tasks and I set up my batch processing.

    * I created a service order and send it electronically to the outbound map –> this works correctly

    * I changed one of the fields in this XML (for example the "description" of the service order) and I saved it under the inbound map.

    * When looking at the que manager I got the following message : "Local endpoint CEU doesn’t exist". What do I do wrong

    Help !!!

    Thanks

    Frank

  2. dsiebold says:

    I believe this may be a problem with the header. For an inbound message, the SourceEndpoint would be the sending system (which would be the same as the endpoint defined for that system in your installation, CEU). The DestinationEndpoint would be the local endpoint of the receiving system (CEULocalEndpoint). From the perspective of the AX installation, the local endpoint refers to the current installation and the endpoint refers to the external system.

  3. frank.vanhamel@realdolmen.com says:

    Hello,

    I’ve done the changements you described earlier, but now I receive a different error message when trying to inbound the message : "Cannot process duplicate message. Message {1138A510-54A7-461E-A8F0-8C67F6451E57} has already been processed and is different from the new message"

    Thank you in advance,

    Frank

  4. Alex Anikiev says:

    Addressing Frank's issue:

    When you use read+update operations to organize update, technically each operation = inbound AIF message. {1138A510-54A7-461E-A8F0-8C67F6451E57} above is MessageID used for read operation, and apparently you tried to use the same MessageID executing update operation which resulted in depicted error. To resolve this issue you can generate brand-new MessageID for update operation:

    Guid guidMessageId = Guid.NewGuid();

    Enjoy!

    /Alex

  5. Amit says:

    I have a setup where I am trying to perform an operation in AX by passing Message from BizTalk to the exposed AX AIF Service for a local AX Installation.

    The problem I am facing is that the requests must be directed towards a pre-configured local end point in AX but I can’t find a way to specify the local End Point in my Request.

    If in case I was using the  AIF Adapter I could have done that by specifying the ‘Local End Point’  context property either at run time or port deployment on my send port but since I have to use the exposed WCF service I can’t do that.

    Any suggestions ?