Microsoft Dynamic AX 2009 : .NET Business Connector - Inside .NET Business Connector

.NET Business Connector is a versatile platform component. It contains the Dynamics AX kernel and provides a runtime environment for executing X++ code and interacting with other elements in the AOT. Nearly the entire Dynamics AX development and runtime environment is based on X++, and the kernel is responsible for interpreting and executing this code, part of the reason .NET Business Connector is so powerful.

1. Logical Component Stack

In .NET Business Connector, the following three logical components (illustrated in Figure 1) interoperate to deliver functionality:

• Managed classes

• Transition layer

• Interpreter

Managed Classes

The managed classes component is a set of .NET Framework–based classes that expose the functionality you can access through .NET Business Connector. It includes the following classes: Axapta, AxaptaBuffer, AxaptaContainer, AxaptaObject, and AxaptaRecord. The functionality of the managed classes is mostly equivalent to the COM Business Connector, which will be discontinued in future versions of Dynamics AX.

Transition Layer

In the transition layer, .NET Framework objects and types are mapped to their Dynamics AX equivalents. This mapping occurs as part of both the request and the response processing in .NET Business Connector.

Interpreter

The interpreter is the part of the Dynamics AX kernel that is responsible for parsing and executing X++ code. Dynamics AX allows code to be executed locally in the kernel of .NET Business Connector or remotely in the kernel of the AOS. The interpreter manages local and remote code execution. It also manages connectivity to the AOS and other infrastructure, such as session management and security.

2. Run Time

At run time, .NET Business Connector interacts with the AOS. Figure 2 depicts the run-time interaction.

The following list describes the important interactions among .NET Business Connector, the AOS, and the Dynamics AX database:

• .NET Business Connector authenticates against the AOS when the Axapta.Logon method is called. The credentials that .NET Business Connector passes to the AOS must correspond to an existing Dynamics AX user, who must be enabled and have the appropriate rights, granted through security keys, to use .NET Business Connector.

• The AOS completes the authentication and establishes a session for the Dynamics AX user.

• Other .NET Business Connector classes and methods are invoked as needed. Once the session is established, .NET Business Connector can be used to create, read, update, or delete (CRUD) Dynamics AX data. In addition, the X++ business logic that resides in the Dynamics AX metadata store, the application object data can be invoked and executed either on the AOS or in .NET Business Connector.

3. Web Interoperability

The Dynamics AX development environment includes a Web framework, the Enterprise Portal framework. This framework is used to develop the Web-based functionality in X++, which is then exposed in Enterprise Portal. Enterprise Portal uses .NET Business Connector to integrate with Dynamics AX, and .NET Business Connector can interoperate with Microsoft Internet Information Services (IIS) and Microsoft ASP.NET to provide access to the HTTP context information, including requests, responses, and view state, necessary to enable Web-based functionality.

Figure 3 illustrates how Web interoperability works.

Managed Web applications, including Enterprise Portal, execute in IIS within an application domain. Upon initialization, the application domain loads and instantiates .NET Business Connector. The managed application then uses .NET Business Connector to invoke Dynamics AX Web framework elements, such as Web menu items, Web forms, and Web reports. The X++ code stored in the application object data that defines these elements accesses the HTTP context as needed through the following classes (located in the AOT under System Documentation\Classes):

• IISApplicationObject

• IISContextObject

• IISPostedFile

• IISReadCookie

• IISRequest

• IISRequestDictionary

• IISResponse

• IISServer

• IISSessionObject

• IISStringList

• IISVariantDictionary

• IISViewState

• IISWriteCookie

For example, you could write an X++ class to retrieve a variable from the HTTP context, which you could then use in another X++ class. In the following code example, the method takes a parameter, which is the name of the HTTP context variable, the value of which is obtained using IISRequest.

str getIISServerVariable(str 80 var)
{
    IISRequest request;
    str res;
    ;
    request = new IISRequest();
    res = request.serverVariables().itemTxt(var);
    return res;
}

If you want to develop a new, custom Web-enabled application that integrates with Dynamics AX and can access managed HTTP context information, you can use both ASP.NET and .NET Business Connector. The interoperability among IIS, ASP.NET, and .NET Business Connector allows you to access HTTP context information from X++ code that is part of your application.

4. Security

This section highlights the security mechanisms in place for .NET Business Connector and covers authentication, authorization (including security keys), and code access security.

Authentication

Integrated Windows authentication is implemented throughout Dynamics AX 2009, including .NET Business Connector. The managed classes use parameters that are specific to Integrated Windows authentication.

Authorization

.NET Business Connector has an associated set of Dynamics AX security keys that control access to different parts of its functionality. Table 1 describes these security keys. You can find more information about these keys in the Data Dictionary under Security Keys.

You can create sessions in .NET Business Connector either directly or indirectly. The direct approach uses the credentials of the current Dynamics AX user. The indirect approach uses the proxy impersonation mechanism whereby an AX user can be impersonated using the LogonAs API. You can control the use of .NET Business Connector in different user groups in Dynamics AX by configuring these security keys. If you do configure these security keys, they will apply only in sessions created directly.

Code Access Security

Code access security (CAS) was introduced in Dynamics AX 4.0. CAS is a mechanism intended to help Dynamics AX developers write code that invokes protected X++ APIs in a manner that minimizes the potential for them to be maliciously exploited. A protected API is an X++ API method that has been secured by using CAS. CAS also ensures that the protected APIs are executed only on the AOS, not on the Dynamics AX client or .NET Business Connector. CAS therefore restricts the X++ APIs that can be executed locally in .NET Business Connector. If an attempt to use a restricted API is made, a CAS exception is returned.