Dynamics 365 for Operation, PowerApps, Common Data Model and mobile apps

A lot has been going on in the field of Dynamics AX - in the spring, AX7 got renamed to "The New Microsoft Dynamics" but by November 2016 AX7 was released as Dynamics 365 for Operation as "the evolution of Dynamics AX on Azure". 

Some of us perhaps remember "Project Green" back around 2007. Project Green was rumored to combine or merge the at that time vastly different business applications in the MS portfolio. An article from 2007 by Mary Jo Foley gave us some insights:

"Green was Microsoft's plan to unify its four ERP applications. Initially, Microsoft officials said Green would culminate in a single, Microsoft-branded ERP product that would take the best features of the existing four ERP products and meld them together. Before Microsoft got to that point, according to the Green roadmap, the Micrososft Business Solutions team would roll out new "waves" of its existing ERP products that used shared elements, such as a common workflow engine and business-intelligence tools." (reference)

Does it sound familiar to the products we now have? But wait there is more:

"The plan of record -- even though Microsoft no longer refers to it publicly as "Green" -- is to introduce at some point in the next decade [my emphasis] a round of releases of its ERP products where Microsoft's four ERP lines all look and feel remarkably similar, he said.
Ultimately, "we could have Dynamics without the little (GP, AX, SL and NAV) appendages [my emphasis]," Utzschneider said."(reference)

Well, there you have it - or at least it could be interpreted as "Project Green" finally saw the light of day with the release of the Dynamics 365 suite. The referenced article is from 2007 so the "decade" was not far off.

Alongside the release of Dynamics 365 for Operations - D365O - a plethora of other products got released that in some way or the other integrate with D365O pretty much out-of-the box. These product are referred to as the application platform (reference)

The Common Data Model (CDM) is a data store that offers a consolidated set of data sourced, via an entity model, from across the enterprise (reference) and PowerApps can build on data consolidated from the various system of records in an enterprise - system of records being the phrase used most often to describe the "old" Dynamics ERP products, when the lack of intelligence-offerings is contrasted to the capabilities of the newest version, i.e. Dynamics 365.

PowerApps is a generic framework for building apps for any device - it is super easy to use and it literally took me less than 45 min to go from "Hmm - I wonder how this PowerApps work" to I published my customized app to my iPhone that showed real data from my D365O instance. That is pretty amazing and a huge leap from the capabilities of the previous versions of AX.

While CDM offers consolidating options, if you just need to build a mobile app for you D365O instance, there is a little trick to get the mobile customization option.

Normally the URL looks like this:

And the Settings offer the usual options:

But if you add a small snippet to the end of the URL :

"&mode=mobile"

a new option appears in the Settings:

If you then open a list page and click the Mobile app you can create a mobile app drawing on the data from that particular page:

Add a page and select the fields that you want to present on your page in the app

When you press the Select fields you can select fields directly from the overview grid by pressed the '+' icon next to the field:

Super easy to populate and you even the type of the field from the grid.

When you are done with customizing the app you get the option of publishing or exporting your workspace:

And you created your first workspace app.

So, there are many new features and products in the Dynamics 365 product portfolio and there are many areas to explore business wise and tech wise with the increased application platform. 

The public roadmap is always worth to watch

Performance and The New Microsoft Dynamics AX

The performance landscape has changed with the New Microsoft Dynamics AX - of that there is little doubt. The client executable is now a browser and the rest of the topology resides in the cloud (until the on-premise version is released).

Well, since the "client" is now a browser, the lessons learned regarding performance of the client side executed code of the previous versions are no longer valid. Latency is king, when it comes to a smooth user experience.

Addressing performance starts with the user's experience of the performance of the system and luckily Microsoft have introduced some nice feature where we can start getting some information when the client is in the browser.

The workspace of AX has a URL, no surprise here, and it may look something like this:

https://YourNameHere.dynamics.com/?cmp=DAT&mi=DefaultDashboard 

But what happens if you add "&debug=develop" after the last character in the URL, like

https://YourNameHere.dynamics.com/?cmp=DAT&mi=DefaultDashboard&debug=develop

After the page loads again a small number appears next to the Search box

Left click the number and a performance pane pops up to the right where the stack is presented

You are able to drill-down if you click one on entries in the stack to get more information regarding the elapsed time

So, a short but effective start off to digging into the end-users performance challenge simply by adding a small snippet after the URL.

WHS Mobile Device application debugging

This post is about my debugging and error finding in the WHS Mobile Device application.

First of all some general info about the Warehouse Mobile Device Portal, Microsoft published a series of post on the topic that will cover the architecture, setting up etc. The posts are well worth the read.
Warehouse Mobile Device Portal part 1
Warehouse Mobile Device Portal part 2

and a general post about my problem area

Inventory on-hand movements/transfers using the mobile device menus

First of, there is the option of simulating the web based client by opening the Form WHSWorkExecute:

when opening it you get a X++ form that is ideal for debugging the code - the menu is customizable - so your may look different


And now to the problem, when ever we did a Location transfer (that was setup as a movement as per the guides in the Microsoft blogs above - so it's not the standard naming) in the mobile device application it went back to the From page.

We could copy the license plate into the client and the rest of the data would be filled in - seemingly:



Once we pressed the OK button however, the client would skip back to the From-page again, deleting the Qty:



Since the environment is without customisations, we suspected that the issue was data related - furthermore we could tell that the Inventory status was apparently blank even though we confirmed the status to be available in the On-hand inventory.


We could do transfers in the AX client via the Transfer journals, so the data related to the item was correct.

We were interested in investigating how the client form (either the web based or the AX form) got populated, because somewhere along the lines, the inventory status went missing.

Well, after some extensive digging we found the class that populates the form with labels, data fields and buttons:

WHSRFControlData



The population takes place in the populateData() and we could confirm that the InventStatusId was correct when assigning to the fromInventStatusId variable
 
but when adding the Id to the control, there was a round trip to the WMSInventStatus where the Name was inserted as data value and not the Status from the actual inventory status.

A short look into the WHS Inventory status form showed that the Name was blank, resulting in the Inventory status of item in the Mobile Device Portal not being populated - and consequently resulting in the user not being able to transfer the item (and the behaviour above).
 

Adding the Name to the Inventory status resulted in expected behaviour of the forms and we could do our transfer