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
