Inside Dynamics AX 4.0: Usage Scenarios

[Blog bot]

Источник: http://feeds.feedburner.com/~r/Insid...scenarios.html
==============

This section provides several scenarios to demonstrate how the Business Connector might be used in real-world situations. The usage scenarios described here fall into the following categories:

• Client
• Web
• Server

Client
In client-based scenarios, the Business Connector and the application that uses it are installed on a user's desktop computer. To make this easier to set up, Dynamics AX 4.0 allows the installation of just the COM or .NET Business Connector, instead of the entire Dynamics AX rich client (which was required in the previous version of Dynamics AX).
Office Excel Integration Example
Microsoft Office Excel integration is probably the best illustration of client-based use of the COM Business Connector, because it is a commonly used tool and particularly appropriate for viewing and manipulating data sets from ERP systems such as Dynamics AX.
You can extend Office Excel by developing add-ins that load when Excel launches. Office Excel exposes a menu that can be accessed by users working on a spreadsheet. Here are the requirements for this type of integration:

• It must be possible for the current Windows user to be authenticated in Dynamics AX.
• It must be possible to retrieve data from Dynamics AX into a range within a workbook in Office Excel.
• It must be possible to update data in Dynamics AX that corresponds to the retrieved data.

In below image illustrates the topology of this integration.

Office Excel integration with Dynamics AX using the COM Business Connector

The following actions are associated with the use of the COM Business Connector from the Office Excel add-in:

1. The COM Business Connector is invoked initially to authenticate the current Windows domain user and to establish a session with Dynamics AX.
2. An Office Excel user clicks a menu option to retrieve data from Dynamics AX. This executes code in the add-in to query data (through the Business Connector). Data retrieved from Dynamics AX is then passed back to the worksheet via the Business Connector.
3. After the data appears in the worksheet, the user manipulates it.
4. When the data is ready to be saved back to Dynamics AX, the user clicks a menu option, which causes the Business Connector to execute code in the add-in to persist the data. Note that any business logic attached to the destination table in Dynamics AX is executed when the Business Connector processes the updates, and exceptions are passed back to the calling application, which in this case is the Office Excel add-in.

This scenario illustrates the concept of developing an add-in to a popular Microsoft Office program using the COM Business Connector. In fact, this concept was used to develop several snap-ins for the previous version of the application, which are published here: http://www.gotdotnet.com/codegallery...b-1119fffbe018. Search the page for "Snap-ins for Microsoft Dynamics AX 3.0." Note that you must register to see the snap-ins. As of this writing, there are three such snap-ins:

• Business Data Lookup Provides the ability to access Dynamics AX data from Microsoft Office applications by using the task pane
• Time Sheet Management Enables time sheet data to be entered and submitted from Office Outlook
• Vacation Scheduler Allows users to submit time-off requests from Office Outlook

Each of these snap-ins uses the COM Business Connector to access Dynamics AX business logic and data. You can download the source code to see how the Business Connector is used in each one.
PDA Synchronization Example
A potential client-based use of the .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 are as follows:

• 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 below image illustrates the topology of this integration.

PDA synchronization using the .NET Business Connector

The following actions are associated with the use of the .NET Business Connector during PDA synchronization:

1. The synchronization manager downloads data from the PDA and recognizes that it needs to be uploaded to Dynamics AX.
2. The synchronization manager authenticates the current user's credentials with the Business Connector and establishes a Dynamics AX session.
3. Data read from the PDA is uploaded to Dynamics AX through the Business Connector. The data is validated using X++ business logic defined in Dynamics AX. Exceptions are reported as errors in the synchronization manager.
4. Validated data is persisted in the Dynamics AX database.

This usage scenario shows how the Business Connector might be incorporated into the synchronization mechanism for a PDA, and how data entered on the PDA can be transferred to Dynamics AX.
Web
Earlier in this chapter, we explained how the .NET Business Connector interacts with the managed HTTP context, thus enabling Web applications, including the Dynamics AX EP, to access and use this context information. One of the primary processes in the EP is page processing, which is a good example of how you can use a Business Connector to enable a Web application.
Server
A final usage scenario uses the .NET Business Connector on the server that hosts the AOS and the Dynamics AX database, as shown in below image.

Server-based use of the .NET Business Connector

In this scenario, a non-Web-based managed application uses the .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 is not possible. For example, the asynchronous integration offered by the AIF does not 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 the .NET Business Connector to impersonate a Dynamics AX user. You can do this in one of three ways:

1. Use the Logon() API method and supply the original user's credentials, assuming they are known and maintained securely.
2. Use the LogonAs() API method and supply the credentials of the Dynamics AX Business Connector Proxy user. The Business Connector Proxy user is a specifically nominated domain account used within the user impersonation mechanism in both types of Business Connector. For more details about this, review the documentation supplied with the application.
3. Execute the Business Connector in a Windows process owned by the Dynamics AX Business Connector Proxy user, and then call the LogonAs() API method.

If you use one of these methods to log on to the Business Connector, you can develop server-based applications that can process data using the correct Dynamics AX user identity.
</img> </img> </img> </img> </img>


Источник: http://feeds.feedburner.com/~r/Insid...scenarios.html