Developing Mobile Apps for Microsoft Dynamics AX 2012 R3

  • 8/11/2014

Developing a mobile app

When you are developing a mobile app, it is helpful to start by prototyping and developing based on simple scenarios. For example, one initial prototype app that the Microsoft Dynamics AX team developed simply updated data to AX 2012; it didn’t read data from AX 2012 or require authentication. Additional features were added as the app moved from prototype to production. Keeping apps as focused and as simple as possible is a good guideline for mobile apps in general.

Platform options and considerations

The mobile architecture described in this chapter is platform-independent and device-independent. You can use this architecture to develop applications across the spectrum of devices, including laptops, tablets, and phones. You can also use it across the landscape of development technologies, such as C# and Extensible Application Markup Language (XAML), HTML5 and JavaScript, Objective-C, and Java.

The underlying technologies used in the architecture, such as AD FS, the Service Bus Relay, and AX 2012 services, are commonly used in cross-platform development.

Developer documentation and tools

One of the goals of the mobile architecture is to solve the basic issues of interacting with AX 2012 so that mobile app developers can focus on their apps. With the problem of communicating with AX 2012 solved, developers can use the wealth of documentation and tools available to them. A large community of mobile app developers builds apps for AX 2012, without needing to understand the underlying AX 2012 framework. To the mobile app, calls to AX 2012 are simply web services calls, which is very common for mobile apps.

Microsoft offers an exhaustive set of samples, tutorials, and tools for developers who are creating apps for the Windows Store and for Windows Phone. As of this writing, the Windows 8.1 app sample pack includes more than 330 samples at The following are of particular of interest:

These types of samples can be relevant to developing mobile apps for AX 2012.

Third-party libraries

In addition to published samples, an extensive set of third-party libraries are available for developing mobile apps. Examples of functions provided by these libraries include data binding, storage, lookups, currency, controls (such as calendars), and date/time functions. If your organization allows the use of third-party libraries, using these libraries can help boost developer productivity.

Best practices

This section describes some valuable considerations to keep in mind when designing and developing mobile apps.

  • Take advantage of native device capabilities Taking advantage of the capabilities of a device can greatly enhance mobile apps. For example the device’s camera can be used to record documents or receipts. The camera can also be used to capture damage or repair situations (for construction, manufacturing, or field services) as part of an AX 2012 transaction. The geographic information from the device can be used to map a location or address known to AX 2012, such as a customer, vendor, or site.
  • Make use of data caching and local storage Master and lookup data might need to be cached on the device as an alternative to requesting data from the service each time it is needed. For example, expense categories or currency types are relatively static and can be safely cached locally. The mobile app can refresh those on an infrequent basis. Some reference data can be cached but must be refreshed more frequently. For example, projects or customers can be stored locally but might need to be refreshed at app startup or on a regular basis.

    You can store data locally by using available technologies such as indexDB or SQLite. These technologies are supported across platforms and devices. You might need to use the RecVersion field to determine whether records are synchronized. For more information, see “Concurrency When Updating Data” at

  • Consider bandwidth and connectivity in your design Mobile devices typically have less bandwidth than desktop computers on corporate networks. You’ll need to make appropriate tradeoffs to ensure that your apps work on lower bandwidths. For example, a phone app might impose a size limit on a picture that is sent with a transaction because of bandwidth limitations.

    You should also consider intermittent connectivity. Mobile apps should be designed to expect interruptions in connectivity. This might mean saving appropriate state information and data locally, and using that stored data when connectivity is restored.

  • Allow for offline use In some scenarios, it is beneficial for users to have some app functionality when the app is offline (not connected). Consider whether you can enable some of the app’s functionality offline. It is important to consider the level of business logic that should reside in the app for offline scenarios. It probably makes sense to enable offline features where extensive business logic (which is available in AX 2012) is not required. If you don’t enable offline features in such cases, your app will need to apply the business logic and have the user react as appropriate when it reconnects.

Key aspects of authentication

Authentication was discussed earlier in this chapter as part of the overall message flow. However, because authentication is a key and potentially complicated part of the process, this section focuses on some of its more complicated aspects.

As mentioned earlier, because the mobile app will likely run on a device that is not on a corporate network, users must be authenticated. The first step in the process is to acquire the users’ credentials (user names and passwords). We recommend that you store those credentials in the app by using a secure storage mechanism on the device. That way, the mobile app can silently authenticate users without prompting them for credentials each time the app runs.

Another complicated aspect of configuring authentication is setting up Secure Sockets Layer (SSL). AD FS uses SSL to ensure that the passing of credentials and tokens between the mobile app and AD FS is protected. The AD FS endpoint has a URL based on the company’s domain. For example, the AD FS endpoint for the Contoso company might end in To enable SSL, you must install an appropriate SSL certificate in AD FS. More precisely, you must set up SSL in IIS, which is used as the front end for AD FS.

Setting up SSL in IIS is a common practice because many websites require the use of SSL for inter-actions that require authentication or share protected information. The SSL certificate must be issued by a recognized certificate authority (CA). In issuing an SSL certificate, the CA verifies that the entity requesting the certificate is associated with the domain for which the certificate is being issued. For example, the administrator for Contoso must prove to the CA that she is associated with the domain. This is typically done by the CA making contact by using the contact information (phone number and email address) associated with the domain in the Domain Name System (DNS) records. Whether you are setting up AD FS for demonstration, testing, or production purposes, it is necessary to have a CA-issued SSL certificate for the domain used by AD FS. For more information, see “Obtain an SSL Certificate” at

For more information about configuring authentication, see “Developing secure mobile apps for Microsoft Dynamics AX 2012” at and “Microsoft Dynamics AX Connector for Mobile Applications” at (CustomerSource or PartnerSource credentials are required).

User experience

Developing mobile apps for AX 2012 creates an opportunity for developers to reimagine user experiences. Across the landscape of devices, mobile apps are generating a wave of exciting new user experiences. We encourage you to be inspired by these immersive experiences when envisioning mobile apps for AX 2012. The expense app created by the Microsoft Dynamics AX product group provides some vivid examples.

The following illustrations show examples of the existing AX 2012 experience compared with the new mobile app experience in the expense app. The top half of Figure 22-3 shows the expense report experience in the AX 2012 Employee Services portal. The bottom half of Figure 23-3 shows the corresponding experience in the AX 2012 expense mobile app. Both user interfaces display views of a list of expense reports. Note that the mobile app takes advantage of cards to represent expense reports and uses color to represent status. The app is designed to be touch-friendly and hides commands until needed. However, the mobile app also works well with a mouse and keyboard.


FIGURE 22-3 Screenshots of expense reports in the AX 2012 Employee Services portal and in the expense mobile app.

Figure 22-4 shows the edit experience within an expense report in the AX 2012 Employee Services portal and in the expense app. Again, the mobile app uses cards to represent expenses, and color and icons to show categories. The mobile app also uses a calendar to show the expenses during the week based on the transaction date.


FIGURE 22-4 Screenshots of the edit expense reports experience in the AX 2012 Employee Services portal and in the expense mobile app.

User experience guidelines are quickly evolving as the role of devices expands. For detailed information and guidelines for developing mobile apps, see “Getting started with developing for Windows Phone 8” at This document is updated frequently, so check back often.

Globalization and localization

Mobile apps should support globalization and localization, as described here:

  • Globalization entails using the correct formats for numbers, dates, times, addresses, and phone numbers for different locales. For the AX 2012 apps developed by Microsoft, globalization is based on the country or regional settings of the device.
  • Localization entails displaying the user interface in the language of the user. For the AX 2012 apps developed by Microsoft, the app language is based on the user’s language in AX 2012.

We recommend that you design apps so that resources, such strings and images, are separate from code. This enables them to be independently localized into different languages.

App monitoring

Having information about the usage of your mobile apps is generally valuable, so we suggest that you develop your apps to capture and save monitoring information. This approach is also referred to as telemetry or instrumentation. Windows Store apps and Windows Phone apps inherently capture some information, including downloads, basic usage, and errors. In addition, it is useful to capture more detailed information about how the apps are used. Application insights help you find out what users are doing with the app and help you diagnose performance or exceptions with the app. Application Insights for Microsoft Visual Studio Online is a cloud-based service designed for monitoring mobile or web apps. For more information, see

Web traffic debugging

The mobile app architecture relies heavily on calls to web services. These include calls to authenticate the user of the app and calls to AX 2012 (through the Service Bus Relay). It is very useful to capture and analyze the content of these calls. The Fiddler web debug proxy is an excellent tool for viewing and analyzing the web services calls. You can configure Fiddler to work with mobile devices.

The following blog posts describe how to use Fiddler to develop apps for Windows 8 phones:

And the following blog post describes how to use Fiddler with iPhone5:

Related resources

There are currently no related titles.