
THE RECIPE
For every Business Central customer I have to store Lat and Lng coordinates.
Starting form the customer full address, the coordinates are obtained by using Geolocation and Reverse Geolocation APIs of Azure Maps.
The coordinates are finally stored in the Customer table.
The whole procedure is implemented with a time triggered Azure Function acting as a scheduled orchestrator between Business Central API and Azure Maps API.

The next step implementation will automate this process by using webhooks: with this solution Business Central notifies the Azure Function every time a customer entity is updated and the azure function automatically and immediately update the coordinates.
ACTIVATE AND CONFIGURE AZURE MAPS ON AZURE
Login in Azure Portal and create a new source.

After resource is created just grab the primary key from “Authentication” blade.

TEST AZURE MAPS WITH INSOMNIA
The rest call to get the address’s coordinates is pretty simple:
Eg: https://atlas.microsoft.com/search/address/json?subscription-key={key}&api-version=1.0&query=Via Martiri del Popolo, 22, 50055 Lastra a Signa (FI)
By using Insomnia you easily test the API:

The JSON contains the coordinates of given address.

AZURE FUNCTION
The Azure function ProcessCustomers downloads a list of customers by using an API. For each customer it queries Azure Map service to get the lat and lon coordinates from the given address.

First it gets the list of customers by using a custom API and deserialize it.

The Customers.cs contains the business central Customer domain class converted in C# class.

Azure Map API services are used to get the lat and lon coordinates.

The full address is composed by formatting the business central address fields to obtain an Azure Map compliant address.
The Azure Map returns a JSON as represented in AzureMapResults.cs class file.

This is a typical json as returned from Azure Maps services:

The coordinates are updated in Business Central by using an http PATCH request on my custom API.
The patch request has the standard format: The If-Match header represents the entity ETag as returned from Business Central and the Query URL must contain the filter by using the primary key field (No in my case).
If the PATCH request succeeded the API returns the new updated entity.

ETAG: PAY ATTENTION!!!
The Etag is updated every time an entity in modified in Business Central. This means the Etags are loaded when the azure function is called and if an user change some field in Bc this Etag is changed too.
In this case the Http PATCH request will be denied because we try to update a record that has changed on ERP and it will return an “Http 409 Conflict” error.

SOURCES
https://github.com/avalonit/AzAPP365AzureMaps
LAST UPDATED
9th of September, 2020