Tips: Configuring Warehouse Mobile Devices Portal after installation on CTP7 and CTP8 builds of the latest Dynamics AX release

Introduction

Over the last couple of months we have had a number of customers go live on the latest version of Microsoft Dynamics AX, and some of them have decided to use the Advanced Warehousing solution including the Warehouse Mobile Devices Portal (WMDP) that is shipped together with AX.

In my last post I provided links for how to install and use the portal:
http://kashperuk.blogspot.dk/2016/01/tutorial-warehouse-mobile-devices.html

Here I would like to focus on a few aspects we've learnt based on interaction with the Go-Live customers, that will hopefully help some of you to avoid the same problems.

Tip 1

In CTP7 and CTP8 (in case you don't know what CTP stands for, read wiki) WMDP was not strongly signed. That means that on your environment after installation, you could receive an error like below (In Event Log):

Exception information: 

    Exception type: ConfigurationErrorsException 

    Exception message: Could not load file or assembly 'Microsoft.Dynamics.AX.Whs.Web, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name signature could not be verified.  The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)

In the final (RTW) release of Microsoft Dynamics AX the assembly is strongly signed.

But if you are on CTP7 or CTP8, you can refer to one of the below solutions:

Solution 1

One thing you can do to resolve this is sign the assembly, using the strong name tool in a command like the following:

C:\Program Files (x86)\Warehouse Mobile Devices Portal\DEFAULT\bin> sn -Vr .\Microsoft.Dynamics.AX.Whs.Web.dll

This is the preferred approach.

For test environments, you could also just go with Solution 2

Solution 2

You can also just disable strong name verification on the machine you are testing out the portal on, by modifying the registry with commands below (for x86 and x64):

reg DELETE HKLM\Software\Microsoft\StrongName\Verification /f
reg ADD HKLM\Software\Microsoft\StrongName\Verification\*,* /f
reg DELETE HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification /f
reg ADD HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification\*,* /f 

Or, if you want to limit the scope of allowed non-signed assemblies, you can restrict it to just the WMDP dll in the above ADD commands like below:

reg ADD HKLM\SOFTWARE\Microsoft\StrongName\Verification\Microsoft.Dynamics.AX.Whs.Web,31bf3856ad364e35

reg ADD HKLM\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\Microsoft.Dynamics.AX.Whs.Web,31bf3856ad364e35 

If you want to learn a bit more (or get a ready PowerShell function for the above), refer to this blog post.

Tip 2

WMDP is an ASP.NET MVC based web site and has a number of important configuration options in its web.config file. You can read more about the configuration options on MSDN.

One particular setting is important to note, since it is believed that it has an "incorrect" value by default after installation in AX 2012 CU8 build.

The setting is customErrors, and you can read all about it on MSDN

In production environments, this setting should always be set to "On", as WMDP X++ code in some cases throws unhandled exceptions, which result in a complete meltdown of the web site, if not redirected correctly to a user-friendly error page. 

The "Off" setting can be used on test environments when debugging the site, as it will provide call stack information for what happened. 

Hope this helps!

And let me know if you have additional tips to add here about WMDP, I will gladly add them here

Walkthrough: Fixing the error message "WorkGroupingId is not found in the map"

Introduction

Since the release of the new Warehouse management solution with Microsoft Dynamics AX 2012 R3, a number of people have reported a sporadic error that was difficult to reproduce, but it was happening consistently on their environments.

The error message shown to the user on the mobile device was also not very helpful:

The value "WorkGroupingId" is not found in the map.

The challenge for us is usually to reproduce the problem, so we can actually debug through the code and see the root cause. We have finally managed to reproduce the problem recently, and have produced a simple fix, that will prevent people from getting into this situation in the future.
I don't yet know if this will be released as a hotfix for 6.3, but I will make sure to update this post with the link if that happens.

You can also just get the code from this post below, but that means you will need to apply it yourself.

But the primary purpose of this blog post is to release a small job to update the data that was messed up. Since we will not update all consumers of the mobile device menu items impacted, but only prevent future setup like that.

Of course, please have your development team review the job and the fix before applying this on your environment, and make sure to run it on your test environment first.
Neither Microsoft nor I will be held accountable for any data loss you might experience as a result of incorrectly applying the fix.

Example of scenario that is broken

I have a purchase order for one of my vendors, for 1 item that is WHS-enabled, as shown below:

Simple purchase order

I now want to use the mobile device to receiving this purchase order in my WHS-enabled warehouse 42. That assumes that I have Location directives, Work templates, Work users, etc. set up already. If you are not familiar with the inbound flow in Warehouse management, please look at some my other posts, where this is described. For this post, I only will include the configuration screen for the Mobile device menu items.

In my company, we used to normally receive small inbound orders, so we configured the mobile device to allow first grouping multiple incoming orders to put them away all at once, and then grouping the puts into one once you are at the location (assuming, of course, that the put-away location is the same for multiple orders). The following menu item configuration corresponds to that:

Mobile device menu items - User grouping

But then, since we got more and more deliveries that were much larger in size, where grouping them for put away on one pallet was no longer an option, we decided to change the menu item setup to just order by order, as shown below:

Mobile device menu items - User directed

But suddenly, when processing putaway for incoming orders, our workers started getting the above error about "WorkGroupingID not found in map":

Warehouse mobile device portal flow

Product bug fix

The fix, as I mentioned above, will only address the part, that touches the configuration of the mobile device menu items, as that is where the root cause of the issue is. When you change the "Directed By" to something other than "User grouping" or "System grouping", the "Group putaway" gets hidden, but still contains the value it had before. Then the mobile device code relies only on this value (in some flows), and does not check that the "Directed by" is also appropriate.

Here's the fix. I am inserting it as an image so it's more difficult to copy to make sure you don't overwrite whatever changes you have in that method already.

Code changes required to fix "WorkGroupingId" bug

Data fix

The above fix means that people who have invalid setup will still be hitting the exact same issue when doing putaway. So below is a small job that fixes the invalid data by unchecking the "Group putaway" check-box for menu items where it was set incorrectly.

static void dataFix_WHSRFMenuItemTable_WorkGroupId(Args _args)
{
    WHSRFMenuItemTable menuItemTable;

    ttsBegin;

    update_recordSet menuItemTable
        setting GroupPutaway = NoYes::No
        where menuItemTable.MenuItemDirectedBy != WHSMenuItemDirectedBy::SystemGrouping
            && menuItemTable.MenuItemDirectedBy != WHSMenuItemDirectedBy::UserGrouping
            && menuItemTable.GroupPutaway == NoYes::Yes;

    ttsCommit;

    info(strfmt('Fixed %1 menu item(s).', menuItemTable.RowCount()));
}

When you run the above job, you'll at the end get an infolog message informing you how many records were fixed.

Result

After applying the above fix and running the above data fix job, you should be able to successfully complete the putaway.