Reusing Addresses in Dynamics AX 2012: Part 2 – User Interface

by | Updated August 15, 2016 | Dynamics AX

In my previous article on address standardization, I showed how to create a C# class to handle the JSON serialization for a call to a RESTful HTML service. In this article, we will take the next logical step and integrate it into the AX user interface. Some of what I will cover is explained in much more detail in this white paper titled  “Implementing the Global Address Book Framework.”

Objective

Our objective in this article is to hook into the Global Address Book (GAB) Framework to make sure that no address can be added to the GAB without first being standardized. We also want to be able to search for existing (standardized) addresses in the GAB to reuse them rather than creating superfluous address records.

Architectural Decisions

One can imagine that there are several different ways to accomplish our task. We need to make a few high-level architectural decisions before we design our solution.

Separation of Concerns

The first decision is where the code should reside. It would be tempting to integrate the code into the forms used to enter addresses. This would serve our purpose most of the time. But what happens when we want to use the DirAddressService to create new addresses? We could end up getting non-standardized records in the GAB from this service.

From an architectural perspective, we want to follow the Separation of Concerns principle. This principle will tell us that it is the concern of the Business Logic to enforce the business rule that all addresses must be standardized. So we need to place our standardization code in the Business Logic layer.

There is a class that provides the business logic to create a new postal address. This class is the LogisticsPostalAddressEntity. Because this class centralizes the logic for creating a postal address, it would make sense to add the business logic here that would return the correct LogisticsPostalAddress record, either a newly created one or a retrieved one when applicable.

Violations of the Separation of Concerns

Having worked through the architectural theory of where to put the code, we now are faced with the reality that Microsoft has violated the principle of the Separation of Concerns. The form that is used to enter new addresses (LogisticsPostalAddress) contains all kinds of business logic that probably should not be contained in the presentation layer. The form also does not use the  LogisticsPostalAddressEntity class that is recommended for use by Microsoft.

So we need to look further for a centralized place to standardize addresses. We are in luck because the LogisticsPostalAddressEntity class  uses LogisticsPostalAddressMap. If we place our standardization in the map we can standardize the address fields of any tables that use the map, including the LogisticsPostalAddress table.  A map abstracts one or more tables into a single wrapper that allows common code to be used to referenced by each table using the map. See this article for more information.

Here is the plan. We will tie into the modifiedField() method. When any of the address components get modified we will call a standardization method on the map to standardize the address. In the standardization method we will check to see if the address is complete enough to standardize. If so, we can standardize the address.

First, we will add the following new method and code to the LogisticsPostalAddressMap:

Now we will hook into the modifiedField() method to call our standardizeAddress() method. If you look at the modifiedField() method on the LogisticsPostalAddressMap you will see a series of Case statements. We want to standardize any time the Street, City, State or ZipCode change. So we need to find the relevant case statements and add a call to the standardizeAddress() method. For example, find the code for the City field case statement ( case extendedTypeNum(LogisticsAddressCity) ) and then insert the following line just before the call to formatAddress()

Add this call for the Street, State and ZipCode case statements also.

Now test out your code. Any time you have enough data to standardize an address the Smarty Streets API will be called. For example, if I add or edit an address that looks like this:

Tory B_Edit Address

When I tab to the next field it now looks like this:

Tory B_Edit Address 2

Notice that the street field has now been standardized.

It is important here to mention that I haven’t actually reused any addresses. I have simply ensured that all addresses that are added to the system are correctly standardized. To reuse them we would need to implement a methodology to use the standardized address to search for existing addresses. I will address this issue in a future post.

In my next post, I will attempt to implement the same solution using AX code without a C# assembly. That should be interesting so stay tuned.

 

Related Posts

  • The Safari browser is now supported natively on Dynamics AX 2012 R2 as well as being supported on Dynamics AX RTM with a hotfix.  Taken from the updated System Requirements…

  • I put together some certification information on the requirements for Microsoft Dynamics AX 2012 and a proposed training roadmap to get to each of the core certifications.  Rather than have this…

  • With the announcement of the release of Microsoft Dynamics AX 2012 R2, Microsoft released an updated system requirements document for AX 2012: http://www.microsoft.com/en-us/download/details.aspx?id=11094.  Windows 2012 Server is now supported, but…

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Upcoming Events

august

12aug10:00 am10:30 amWhy Levridge Grain? How to Achieve Efficient and Accurate Scale Tickets

12aug12:00 pm1:00 pmThe Three Paths to Dynamics 365 Finance and Supply Chain from Dynamics AX

13aug11:00 am12:00 pmConfab with Stoneridge - Livestream - Inspire Keynote Breakdown

19aug10:00 am11:00 amWhat is Levridge? An Overview of the Ultimate Ag Solution

19aug12:00 pm12:30 pmThe Modern Manufacturer - Death by Safety Stock

27aug12:00 pm1:00 pmConfab with Stoneridge - Livestream - Dynamics 365 2020 Wave 2 Preview

september

02sep10:00 am10:30 amThe Modern Manufacturer - Cycle Count Management

09sep10:00 am11:00 amWhat is Levridge? An Overview of the Ultimate Ag Solution

16sep10:00 am10:30 amThe Modern Manufacturer - Product Lifecycle Management

30sep10:00 am10:30 amThe Modern Manufacturer - Return Management

About Stoneridge
Stoneridge Software is a unique Microsoft Gold Partner, with emphasis on partner. With specialties in Microsoft Dynamics 365, Microsoft Dynamics AX, Microsoft Dynamics NAV, Microsoft Dynamics GP and Microsoft Dynamics CRM, we focus on attracting the most knowledgeable experts in the field to our team, and prioritize delivering stellar solutions with maximum impact for your business. At Stoneridge, we are deeply committed to your results. Each engagement is met with a dedicated team, ready to provide thorough, tailored, and expert service. Based in Minnesota, we intentionally “step into your shoes,” wherever you are. We focus on what you care about, and develop trusting, long-term relationships with our clients.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!

X