Chapter 22. Developing mobile apps for AX 2012

In this chapter

Introduction

The mobile app landscape and AX 2012

Mobile architecture

Developing a mobile app

Architectural variations

Resources

Microsoft Dynamics is creating new mobile device experiences for AX 2012 customers through apps. These apps are designed to help a broad range of employees improve their efficiency while on the go and stay connected to their business processes. Scenarios include native experiences for both smartphones and tablets. In addition to developing its own apps, Microsoft Dynamics is committed to helping developers build their own immersive device experiences for AX 2012.

These apps can interact directly with AX 2012 by using the existing AX 2012 services framework. This approach also uses existing AX 2012 user accounts so that no additional provisioning is required. For more information about AX 2012 services, see Chapter 12, “AX 2012 services and integration.”

This chapter begins by providing an overview of the current mobile app landscape and how it relates to AX 2012. It then describes the AX 2012 mobile architecture and the technical and user interface considerations for developing mobile apps. For more detailed instructions about developing mobile apps for AX 2012, see the sources listed in the “Resources” section at the end of the chapter.

Creating mobile apps requires a different set of skills than developing for AX 2012, and customers and partners might find it advantageous to pair an AX 2012 developer with a mobile app developer. This way, necessary AX 2012 services can be created by experienced AX 2012 developers. Except for needing to understand the content of the services, typical mobile app developers can develop AX 2012 mobile apps without having to understand the intricate details of AX 2012. Thus, partners and customers can take advantage of the vast pool of mobile app developers.

How to facilitate communication between apps and on-premises installations

How to authenticate users

How to develop for multiple platforms

Because AX 2012 most often runs on-premises or is privately hosted, the average phone or tablet device does not have access to AX 2012 services, which are usually available only through a corporate network. To overcome this challenge, the mobile architecture uses the Microsoft Azure Service Bus Relay. The Service Bus Relay solves the challenges of communicating between on-premises applications and the outside world by allowing on-premises web services to project public endpoints. Systems can then access these web services, which continue to run on-premises, from anywhere.

The Service Bus Relay is based on a namespace that is set up for each company that deploys mobile apps for AX 2012. For example, an administrator from the Contoso company can create an Azure subscription and set up a unique namespace, such as contosomobapps. The namespace is a friendly identifier that end users enter into the mobile app to connect to their company’s AX 2012 instance.

The second challenge is authenticating users. AX 2012 has existing user accounts that are based on Active Directory accounts. Ideally, device users simply use their corporate identities (user IDs and passwords) to access AX 2012 from their devices. The mobile architecture accomplishes this by using Active Directory Federation Services (AD FS). AD FS is a Windows Server component that is used by users whose devices are not on the corporate network to authenticate themselves by using their existing corporate credentials.

Another challenge that mobile app developers face is providing apps for various device platforms, such as Windows 8.1, Windows Phone 8, iOS, and Android. By taking advantage of the mobile architecture, developers can create applications for the platform they choose, depending on customer requirements.

AX 2012 services Apps communicate with AX 2012 through the AX 2012 services framework.

Active Directory Users who access AX 2012 through mobile apps are authenticated against their existing corporate identities.

AD FS AD FS facilitates authentication of Active Directory–based users who are accessing AX 2012 through mobile apps.

Service Bus Relay The Service Bus Relay ferries messages from the mobile app to an on-premises listener through which the app can reach an on-premises instance of AX 2012.

On-premises listener The listener listens for messages from mobile apps that are relayed through the Service Bus Relay. The listener then makes calls to AX 2012 and responds to the mobile app through the Service Bus Relay.

Microsoft Azure Active Directory Access Control Access Control verifies that the user has been authenticated through AD FS and then allows messages to be sent through the Service Bus Relay.

Mobile apps These apps can be for a phone or tablet on any of the prevailing mobile platforms—Windows, iOS, or Android. The architecture provides the means for these apps to communicate with AX 2012. The apps can then interact with AX 2012 as appropriate, based on the business scenario. Apps can also be designed to communicate with other systems, depending on the needs of the business scenario.

Figure 22-1 shows the components of the mobile architecture.

To become familiar with the mobile architecture, we recommend that you install and configure one or more of the AX 2012 mobile apps and the Microsoft Dynamics AX connector (on-premises listener) for mobile apps. Doing so will help you learn the configuration steps necessary for Azure, AD FS, AX 2012, and the listener. That familiarity will help you greatly in debugging and troubleshooting your apps. For more information about these components and their configuration, see the following white papers:

Microsoft Dynamics AX 2012 White Paper: Developing Mobile Apps at http://www.microsoft.com/en-us/download/details.aspx?id=38413.

Configure Microsoft Dynamics AX Connector for Mobile Applications at https://mbs.microsoft.com/downloads/customer/AX/ConfigureAXConnectorforMobileApplications.pdf. To access this paper, you must have CustomerSource or PartnerSource credentials.

You can download the AX 2012 expense app, which is used as an example throughout this chapter, at http://apps.microsoft.com/windows/en-us/app/dynamics-ax-2012-expenses/07aab6f9-c6ce-4b81-b04c-4b43c3f6de67.

1. The user submits credentials to obtain a token from AD FS.

2. If the user’s credentials are verified, a token is returned that is based on Security Assertion Markup Language (SAML). The token contains a claim that indicates the user name and company domain, such as [email protected]. The claim is used to verify the user’s company affiliation and identity within the company.

3. The mobile app then presents the claim in the SAML token to Access Control. Access Control controls access to the Service Bus Relay; any app that calls the Service Bus Relay must have a token from Access Control.

4. Access Control validates the SAML token based on the previously established trust relationship between Access Control and AD FS for the Service Bus Relay namespace and company domain. Based on the claim in the SAML token, Access Control verifies that the user is from the company associated with the Service Bus Relay namespace. Access Control then provides a second token to the mobile app in Simple Web Token (SWT) format. The SWT token is then included in the request to the Service Bus Relay to send a message to AX 2012. The SAML token is also included and is used by the on-premises listener to authenticate the user.

5. The mobile app then sends the message (with associated tokens) through the Service Bus Relay to the on-premises listener. The Service Bus Relay ferries the message to the listener.

The listener must also be authenticated to listen to the Service Bus Relay. This authentication is based on a Service Bus Relay namespace credential that is stored on the listener. The listener presents this credential as it starts to listen for messages coming from the namespace.

6. After a message is received from the Service Bus Relay, the listener validates the SAML token. The validation is based on a previously established trust relationship between the listener and AD FS. After verifying the token, the listener uses the claim to determine which AX 2012 user is using the mobile app making the call to AX 2012. The listener calls AX 2012 on behalf of the user identified in the claim.

7. The listener receives a response from AX 2012 and then returns the response message through the Service Bus Relay.

8. The Service Bus Relay sends the response message to the mobile app.

Figure 22-2 illustrates the message flow and authentication process. The numbering in the figure roughly corresponds to the numbers in the list.

The AX 2012 services framework provides multiple types of services—system services, custom services, and document services—each with its own programming model. Custom services are the most likely to provide the exchange of messages that are appropriate for a mobile app.

To design an AX 2012 service that can be consumed by your mobile app, you will need to do the following:

1. Create AX 2012 services and data contracts, and deploy a basic inbound port to expose the service operations for consumption.

2. Implement the service methods in X++ classes to perform data operations in AX 2012.

The mobile client must communicate with the AX 2012 service, which is hosted on an Application Object Server (AOS) instance that is deployed behind a corporate firewall. Instead of configuring changes in the firewall, such as exposing an Internet Information Services (IIS) server externally to expose the on-premises service, the app makes use of a secured Service Bus Relay.

AX 2012 services are typically accessed by using Simple Object Access Protocol (SOAP). This approach might work well for some mobile applications. However, the trend in developing web and mobile applications is to interact by using RESTful services. (Representational state transfer [REST] is an architecture that allows developers to write asynchronous code that connects with cloud-based services more easily.) For information about RESTful services, see the article, “An Introduction To RESTful Services With WCF,” at http://msdn.microsoft.com/en-us/magazine/dd315413.aspx.

Currently AX 2012 does not expose custom services by using a RESTful approach. One option is for the on-premises listener to translate RESTful calls from a mobile app to SOAP calls to AX 2012 (and vice versa). The Microsoft Dynamics AX product group used this approach to develop the Microsoft Dynamics AX Windows Store apps (expenses, timesheets, and approvals). For more information about the Microsoft Dynamics AX Windows Store apps, see “What’s new: Companion apps for Microsoft Dynamics AX 2012 R2” at http://technet.microsoft.com/en-us/library/dn527182.aspx.

Beyond the listener’s primary purpose of passing messages between the Service Bus Relay and AX 2012, the listener can provide additional features that facilitate the development of mobile applications. For example, the listener can provide configuration information to the app, such as whether certain features of the app are enabled or disabled. The listener can expose RESTful calls to the client. The Microsoft Dynamics AX product group used WCF features to translate between the SOAP and JavaScript Object Notation (JSON) protocols for messaging to the Windows Store apps. This is a standard feature of WCF. The listener can also capture meaningful information in the event log and provide telemetry information.

Another approach is to use the Azure Service Bus adapter built into AX 2012 starting with AX 2012 R2 cumulative update 6. With this approach, you configure IIS as the listener. Depending on the requirements of your mobile app, you can choose the best approach. For a comparison of these approaches, see “Microsoft Dynamics AX White Paper: Developing Mobile Apps” at http://www.microsoft.com/en-us/download/details.aspx?id=38413.

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.

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 http://code.msdn.microsoft.com/windowsapps/Windows-8-Modern-Style-App-Samples/view/SamplePack#content. The following are of particular of interest:

“Windows Store app for banking: code walkthrough (Windows Store apps using JavaScript and HTML)” at http://msdn.microsoft.com/library/windows/apps/hh464943.

A data binding overview (Windows Store apps using C#, Visual Basic, C++, and XAML) at http://msdn.microsoft.com/en-us/library/windows/apps/hh758320.aspx.

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

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 http://technet.microsoft.com/en-us/library/cc639058.aspx.

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.

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 contoso.com. 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 contoso.com domain. This is typically done by the CA making contact by using the contact information (phone number and email address) associated with the contoso.com 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 http://msdn.microsoft.com/en-us/library/gg981937.aspx.

For more information about configuring authentication, see “Developing secure mobile apps for Microsoft Dynamics AX 2012” at http://technet.microsoft.com/EN-US/library/dn155874.aspx and “Microsoft Dynamics AX Connector for Mobile Applications” at https://mbs.microsoft.com/downloads/customer/AX/ConfigureAXConnectorforMobileApplications.pdf (CustomerSource or PartnerSource credentials are required).

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-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.

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 http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402529(v=vs.105).aspx. This document is updated frequently, so check back often.

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.

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

http://www.geekchamp.com/news/windows-phone-8-and-fiddler

http://www.spikie.be/blog/post/2013/01/04/Windows-Phone-8-and-Fiddler.aspx

http://blogs.msdn.com/b/fiddler/archive/2011/09/14/fiddler-and-windows-8-metro-style-applications-https-and-private-network-capabilities.aspx

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

http://blog.brianbeach.com/2013/01/using-fiddler-with-iphoneipad.html

Web apps have the following advantages:

They work across devices, although they need to be tested and refined to handle device-specific nuances.

They are more adaptable to AX 2012 customizations and extensions. Because they are rendered from the AX 2012 server, the apps can include the customizations and extensions that have been applied to the server.

They do not require users to install or configure the apps.

Web apps have the following disadvantages:

They don’t provide the high-fidelity, immersive experiences available in modern mobile apps.

They rely completely on the server to deliver the app and content. The server might not perform as well or might be less responsive than an app that is installed on the device.

They typically don’t have local caching or offline capabilities.

They probably can’t take advantage of device features such as a camera or GPS.

You can use these tradeoffs to decide which approach is most appropriate for your scenario.

CustomerSource and PartnerSource The “Mobile Apps for Dynamics AX” page on CustomerSource and PartnerSource has a wealth of information for deploying the existing apps or developing mobile apps:

• CustomerSource https://mbs.microsoft.com/customersource/northamerica/AX/news-events/news/MSDYN_MobileAppsAX

• PartnerSource https://mbs.microsoft.com/partnersource/northamerica/news-events/news/MSDYN_MobileAppsAX

Companion Apps blog The Microsoft Dynamics AX Companion Apps blog is a source of regularly updated information. The blog includes an FAQ page for common questions and issues at http://blogs.msdn.com/b/axcompapp/.

Support The normal Microsoft Dynamics AX support channels are available to support the mobile apps released by Microsoft for AX 2012. This includes support for the on-premises listener and its associated configuration.