In this section, we provide several scenarios to
demonstrate how you can use .NET Business Connector in real-world
situations. The usage scenarios described fall into the following
categories:
1. Client
In
client-based scenarios, .NET Business Connector and the application
that uses it are installed on a user’s computer. To make client setup
easier, Dynamics AX 2009 allows the installation of just .NET Business
Connector on the development machine.
Business Data Lookup Snap for Microsoft Office
The business data lookup snap is an add-in for
Microsoft Office that was written using .NET Business Connector. It
allows information workers to access and use Dynamics AX data from
within Office applications. For example, customer information stored in
Dynamics AX can be retrieved using this snap and inserted into a letter
being written in Microsoft Word.
This type of integration has some specific requirements:
It must be possible to authenticate the current user as a valid, active Dynamics AX user.
It
must be possible to take a user-selected Dynamics AX record and search
string, and retrieve any matching records from Dynamics AX.
It must be possible to copy the retrieved data into the Office application being used.
The following actions are associated with the use of .NET Business Connector for the business data lookup snap:
The business data lookup snap is added to Office.
The snap authenticates the current user’s credentials using .NET Business Connector and establishes a Dynamics AX session.
The
selected Dynamics AX record and user-entered search criteria passed to
the snap code are used to create a query that .NET Business Connector
executes.
If any records are returned to .NET Business Connector from the query, they are passed back to the snap.
To find out more details about the business
data lookup snap, go to the CodePlex site and search for “Snap-ins for
Microsoft Dynamics AX.” Note that you must register to see the snap-ins.
PDA Synchronization Example
A potential client-based use of .NET Business
Connector is for PDA synchronization. For example, you could develop an
application that allows a PDA to collect information that can be
uploaded to Dynamics AX. PDAs generally rely on some kind of
synchronization manager; if this synchronization program is
customizable, you can extend it to integrate with Dynamics AX.
The specific requirements for this type of integration follow:
It must be possible to verify that the current Windows user matches the identity of the device owner.
It must be possible to retrieve the data to be uploaded from the PDA or from the local file system if downloaded from the PDA.
It must be possible to validate and insert the downloaded data into the corresponding Dynamics AX tables.
The diagram in Figure 1 illustrates the topology of this integration.
The following actions are associated with the use of .NET Business Connector during PDA synchronization:
The synchronization manager downloads data from the PDA and recognizes that it needs to be uploaded to Dynamics AX.
The
synchronization manager authenticates the current user’s credentials
with .NET Business Connector and establishes a Dynamics AX session.
Data
read from the PDA is uploaded to Dynamics AX through .NET Business
Connector. The data is validated using X++ business logic defined in
Dynamics AX. Exceptions are reported as errors in the synchronization
manager.
Validated data is persisted in the Dynamics AX database.
This usage scenario shows how you could
incorporate .NET Business Connector into the synchronization mechanism
for a PDA, and how data entered on the PDA can be transferred to
Dynamics AX. For more information on this approach, look at the mobile
solutions that have been developed for Dynamics AX (http://www.microsoft.com/dynamics/ax/product/mobilesolutions.mspx). They include development tools for building mobile applications.
2. Web
We explained how .NET
Business Connector interacts with the managed HTTP context, thus
enabling Web applications, including Enterprise Portal, to access and
use this
context information. One of the primary processes in Enterprise Portal
is page processing, which is a good example of how you can use a .NET
Business Connector to enable a Web application.
3. Server
A final usage scenario uses .NET Business Connector on the server that hosts the AOS and the Dynamics AX database, as shown in Figure 2.
In this scenario, a non-Web-based managed
application uses .NET Business Connector to integrate with Dynamics AX.
This approach can be used for a variety of purposes, but one example is
offline processing. Typically, a Dynamics AX user must be logged on to a
computer to authenticate in Dynamics AX. In some cases, this isn’t
possible. For example, the asynchronous integration offered by the AIF
doesn’t require the originating user to be logged on to the machine
where data is processed and inserted into Dynamics AX. However, this
task must be executed using the correct user identity.
The solution is to use .NET Business Connector to impersonate a Dynamics AX user, which you can do in one of three ways:
Use the Logon API method and supply the original user’s credentials, assuming they are known and maintained securely.
Use the LogonAs
API method and supply the credentials of the .NET Business Connector
proxy user. The .NET Business Connector proxy user is a specifically
created domain account used by the user impersonation mechanism in .NET
Business Connector. For more details about this, review the online Help
section “How to: Connect to Microsoft Dynamics AX Using the LogonAs Method.”
Execute .NET Business Connector in a Windows process owned by the .NET Business Connector proxy user, and then call the LogonAs API method.
If you use one of these methods to log on to
.NET Business Connector, you can develop server-based applications that
can process data using the correct Dynamics AX user identity.
