Contents

1.      INTEGRATION

2.      Integration with Microsoft Dynamics AX [AX 2012]

2.1         Services and Application Integration Framework (AIF)

2.1.1          Exposing Business Entities as Services

2.1.2          Common Usage Scenarios

2.2         .NET Business Connector

2.3         .NET Interop from X++ [AX 2012]

2.3.1          2.3.1 Proxy Classes for .NET Interop to X++ [AX 2012]

2.3.2          Integration with X++ Objects from Visual Studio [AX 2012]

                  Event Handlers

1.  INTEGRATION

Application integration (sometimes called enterprise application integration or EAI) is the process of bringing data or a function from one application program together with that of another application program. Where these programs already exist, the process is sometimes realized by using middleware, either packaged by a vendor or written on a custom basis. A common challenge for an enterprise is to integrate an existing (or legacy) program with a new program or with a Web service program of another company.

2.  Integration with Microsoft Dynamics AX [AX 2012]

There can be benefits to integrating your Microsoft Dynamics AX application with other technologies. One benefit is you can use other technologies to develop parts of your overall Microsoft Dynamics AX application. For example, you can write some of your functions in C# instead of in X++, and then integrate your Microsoft .NET Framework assembly into Microsoft Dynamics AX.

Another benefit from integration is the ability to coordinate your Microsoft Dynamics AX application with external applications. The external applications can be inside or outside the boundary of your enterprise. The functionalities of the two applications can interact, and data can be exchanged.

The inbound and outbound exchanges can be categorized in the following ways:

• Send data – Microsoft Dynamics AX sends documents to an external system.
• Send data in response to requests – Microsoft Dynamics AX receives requests for documents from another authorized system, and retrieves the requested information, such as a document or a list of documents, from the Microsoft Dynamics AX database. Microsoft Dynamics AX then returns the information to the requesting system, and the appropriate filtering and security are applied. The request message contains the entity keys or a query that specifies the data that the external system is requesting.
• Receive and create data – Microsoft Dynamics AX receives documents from another authorized system and creates new records in the Microsoft Dynamics AX database.

Figure 2‑1 Microsoft Dynamics Ax system architecture

You can integrate your Microsoft Dynamics AX application by using the following technologies:

2.1  Services and Application Integration Framework (AIF)

Exposes business logic to other internal or external systems. Microsoft Dynamics AX supports integration with the Application Integration Framework (AIF) components using the services programming model. Microsoft Dynamics AX can expose its functionality through services that are based on Windows Communication Foundation (WCF). Microsoft Dynamics AX code and external applications can consume Microsoft Dynamics AX services. AIF supports the processing of inbound and outbound messages. This processing includes message transforms and value lookups. Together, services and AIF provide the programming model, tools, and infrastructure support for XML-based integration with external applications and data.

To support a range of options for customization and programmability, Microsoft Dynamics AX provides the following types of services:

·         Custom services are services that you create to expose X++ logic through a service interface. You can use the business logic with inbound or outbound transfers.

·         Document Services represent data and business logic within Microsoft Dynamics AX. You can use or customize the over 70 standard Axd document services that are included with Microsoft Dynamics AX. If none of the standard document services meet your needs, you can create a new document service by using the AIF Document Service Wizard. Each document is represented by a class; the name of a document class is preceded by Axd. For example, AxdSalesOrder is the name of the document and also the name of the document class. The terms "document" and "Axd document" and "document class" are used interchangeably.

·         System services cannot be customized. The Query Service, Metadata Service, and User Session Service are WCF services included with Microsoft Dynamics AX. System services provide the following:

o    Access to data that is returned in AOT queries.

o    Metadata for AOT objects such as tables and extended data types (EDTs).

o    Data about the calling user, such as default language and Default Company.

Microsoft Dynamics AX enables you to consume external web services from X++ code, and to consume web services hosted by Microsoft Dynamics AX from .NET Framework languages such as Microsoft Visual C#.

Security for document services called from an external client is based on the role-based security that is used in Microsoft Dynamics AX.

Microsoft Dynamics AX supports application integration and data exchange in both intranet and Internet-facing scenarios. Services based on WCF classes are hosted on the AOS for applications to integrate within the intranet of a company. To consume or expose services over the Internet, you must install and use Internet Information Services (IIS).

Figure 2‑2 Services and Application Integration Framework architecture

2.1.1          Exposing Business Entities as Services

Microsoft Dynamics AX installs with over 70 document services. The document services framework provides the AIF Document Service Wizard that generates a document service from the query that defines the business entity. To expose business logic through services, you use serialization with the Data Contract class and custom attributes.

The following table contains information that can help you to decide whether to use document services or custom data contract–based services.

Characteristic	Document Services	Custom Services
Entity complexity	The AIF Document Service Wizard handles queries of any complexity and size and generates the service seamlessly. For example, some queries contain data sources and relationships that include dimensions, polymorphism, date-effective information, and so on. The document services framework handles these types of queries seamlessly.	Suitable when the entity complexity is low. The schema can be written as a data contract class and relevant data member attributes set. If tables and relationships are used in a data contract, then any feature around dimensions, polymorphism, and so on, must be handled in code by the developer.
Performance requirements	The incoming XML is passed to the document services framework, which parses the XML to validate the AxD schema, and then invokes the relevant operation. The framework enables customization to handle any complex pattern in the underlying query.	Custom services use the underlying .NET XML Serializer to serialize and de-serialize the XML into a data contract object. No other logic is present. For simple entity schemas, this approach is faster than document services. For complex schemas, you may have to write a lot of custom code.
Integration requirements	All integration stack elements such as pipelines, transforms, and schema constraints can be applied to document services.	Schema constraints and value substitution are not honored for custom services. However, transforms that convert between the AifXMLMessage format and other formats and pipelines for preprocessing and postprocessing of XML messages can be used.
Flexibility in service contracts	Because the document service is derived from a query, changes to the query object or the data source schema might require a change the service contract. The tight coupling between the service contract and the underlying query-table schema could be limiting for certain scenarios.	The data contracts are written by developers and can be controlled to make sure that the underlying schema changes do not have any effect on them. The control that a developer has in defining the service contracts can be good for service clients.
Microsoft Office Add-ins support	Office Add-ins tools, included with Microsoft Dynamics AX, have built-in support for consuming document services for updating data.	No preinstalled integration with Office add-ins exists.

2.1.2          Common Usage Scenarios

The following table summarizes some of the key scenarios for all the service types in Microsoft Dynamics AX.

Service Type	Common Scenarios
Custom Services	Use to expose very simple business entities as a service, or to expose custom logic from Microsoft Dynamics AX.
Document Services	Use to expose business entitles with varying degrees of complexity, or to support medium-to-complex integration scenario involving business entities.
System Service: Query Service	Use to implement read operations for any Microsoft Dynamics AX, ad-hoc, or existing AOT query.
System Service: Metadata Service	Use to retrieve information about the structures in Microsoft Dynamics AX for a client application. For example, if you want to return information about a table such as what indexes exist on that table, you can use the metadata service.
System Service: User Session Service	Use to retrieve information about the user session.

2.2  .NET Business Connector

NET Business Connector is a component of the Microsoft Dynamics AX development environment. .NET Business Connector enables you to build software applications that integrate with Microsoft Dynamics AX. You can access data or start business logic. The advantage of using .NET Business Connector over other types of integration is that you use the same X++ code and business logic available to clients. You will also be able to use the Microsoft Dynamics AX security model.

Use the .NET Business Connector to interpret and execute code. It provides a run-time environment for interacting with elements in the Application Object Tree (AOT). The .NET Business Connector enables applications to interact with Application Object Server (AOS) instances by providing a set of .NET managed classes. These classes enable access to X++ classes in Microsoft Dynamics AX.

The .NET Business Connector can be installed as a stand-alone component. It can also be used to develop third-party applications that integrate with Microsoft Dynamics AX.

To support integration with Microsoft Windows SharePoint Services and to enhance product security, the .NET Business Connector requires Windows integrated authentication.

2.3  .NET Interop from X++ [AX 2012]

Classes in assemblies that are managed by the common language runtime (CLR) can be accessed in X++ code. This feature of Microsoft Dynamics AX is called .NET interop from X++.

.NET interop from X++ is useful when you want your X++ code to access the functionalities in a CLR managed assembly. This includes assemblies that are installed with the .NET Framework. It also includes any assemblies that you create with a language such as C# or Visual Basic.

The .NET interop from X++ feature works in the direction from X++ calling into CLR managed assemblies. For information about .NET interop in the other direction, see the following topics:

2.3.1    Proxy Classes for .NET Interop to X++ [AX 2012]

A proxy class is a .NET Framework class that provides access to one X++ item type of Microsoft Dynamics AX. You can build proxies for the following X++ item types:

• Classes – both application and system classes.
• Tables – both application and system tables.
• Enums – both base and system enums

Proxies are usually a better alternative to .NET Business Connector. .NET Business Connector requires your C# code to use a late-bound programming model. Proxies require an early-bound programming model. The early-bound model enables the code editor to provide IntelliSense. The early-bound model also enables the compiler to catch misspellings and other errors before the code is run.

2.3.2    Integration with X++ Objects from Visual Studio [AX 2012]

The two features in Microsoft Dynamics AX that support managed code and X++ interop are proxies and event handlers.

2.3.2.1  Proxies

Proxies enable you to add an AOT element to your project in Visual Studio so that element can be accessed by managed code. When you add an AOT element to a project by using Application Explorer, a proxy for that element is created internally by the system.

The AOT elements that you can add to a managed code project are as follows:

·         Classes

·         Tables

·         Enums

After you add the AOT element to your managed code project, all the methods and properties are available through IntelliSense.

A typical scenario for adding an X++ object to managed code is when you identify managed code functionality that you want to call from X++. This functionality may already be located in managed code or the development scenario may require that it run in managed code.

For example, you might want to have your Microsoft Dynamics AX installation updated with customer data from an external system. In this case, you create an X++ job that is scheduled to run periodically and calls a managed code class method. This method could then check for the external data and then call the appropriate CustTablemethods to update the customer data (see the following diagram). Because the managed code that you write runs in the Microsoft Dynamics AX process, that code will typically be in a class library project.

The following diagram provides a high-level view of the integration of X++ and managed code. The initial call from X++ to managed code can originate from either an X++ .NET interop call or from an event handler.

Figure 2‑3 X++ and managed code integration

2.3.2.2    Event Handlers

In the AOT, you can associate a class method with an event handler. An event handler is code that runs before the associated method runs or after the associated method has finished running. The event handler itself is also a class method, and it can be written in either X++ or managed code.

For example, you may have an X++ class method called MyClass.myMethod, and you have managed code that you want to run after the MyClass.myMethod method has finished running. In this case, you would create an event handler class and method in managed code, such as MyEventHandlerClass.PostmyMethod. This event handler contains the code that will execute after the MyClass.myMethod method is called.

When you add an event handler in Visual Studio, the system automatically creates a method that begins with either “Pre” (for event handlers that run before the method runs) or “Post” (for event handlers that run after the method completes). An event handler subscription is also automatically added to the MyClass.myMethod method. In addition, the properties of that subscription are set to point to the managed code class method. After the MyClass.myMethod method has finished running, then theMyEventHandlerClass.PostmyMethod event handler code executes. Event handlers can only be associated with a class in the AOT Classes node.

The following diagram illustrates how a managed code post-event handler is called. You can create the managed code class method and configure the event handler in the AOT to call that class method all from Visual Studio.

Figure 2‑4 Managed code post-event handler flow