A design paper about implementing GIS-based services in Dynamics CRM, structuring address data, and delivering location services in the form of API endpoints via an Enterprise Service Bus.
A Geographic Information System (GIS) is a computer system for capturing, storing, checking, and displaying data related to positions on Earth’s surface. GIS can show many different kinds of data on a map, such as streets, buildings, and vegetation. This enables people to more easily see, analyse, and understand patterns and relationships.GIS can use any information that includes location. The location can be expressed in many different ways, such as latitude and longitude or address. Many different types of information can be compared and contrasted using GIS. The system can include data about people, such as population, income, or education level. It can include information about the land, such as the location of buildings and assets.
This experience is about providing location services in the context of a local Council in Melbourne, Australia. The vision of Council is to have a single view of their customers (landlords, tenants and businesses), and have identified the Dynamics CRM platform as the master data source for case management. Information about location of properties and assets is made available in CRM from the GIS system in order to provide location-based services, also via the Council’s web portal.Location information is structured as follows:
Utilized for identifying an exact point on a map, and for GPS applications.
Utilized for identifying a residential or business place, and for postal correspondence.
The following principles apply when dealing with geographical data (not an exhaustive list).
For additional information about geo-coordinates, and how to convert from one format to another one, please refer to the article Converting GIS spatial coordinates.
In light of the minimum information to capture for locations, and the compliance and integration requirements, the following data structure is implemented in the CRM and/or the integration layer.
Dynamics 365/CRM already contains a standard Address entity that fits the purpose. Latitude and Longitude are available fields, although not assigned to the Address form out of the box. This can be simply done by adding the two fields to a proper section in the form. An address can be associated to a parent entity (owner), and an address type can be specified (e.g. residential, correspondence, etc.). Multiple addresses can be assigned to an owner, with different address types.
Address form in Dynamics CRM with Geo-coordinates.
A system integration infrastructure based on an Enterprise Service Bus (ESB) provides the means for service orchestration and the Publish and Subscribe architecture pattern, by which a message is processed by the ESB and associated queue, and is routed to the interested parties. A third-party system can register its interest in a specific message via subscriptions, and received queued messages based on specific topics. The Publish and Subscribe model is an asynchronous programming technique that makes it easier to share information between entities that send information (publishers) and entities that receive information (subscribers) without coding point-to-point integration channels.
The Publish / Subscribe pattern with an ESB.
Location data flows from and to the CRM system via the Enterprise Service Bus. The GIS system represents the application for resolution of location data and geographical representation, whereas CRM is the master data repository of location information for each relevant entity (property, individual, asset).
External applications, such as a Web portal requesting location services, will access the relevant API exposed by the Service Layer. The API provides location information as stored in the CRM (message queueing mechanism may be in place for optimization of performance). Specific location services, such as visualization of points on a map, will be delivered by the GIS system, which is informed of such request by the ESB. By implementing the Publish-Subscribe pattern, the GIS system will subscribe to receive updates (“signals”) from the ESB for anything that is related to location. When such a signal is broadcast by the ESB, as a result of a request from the API, the subscribed application (the GIS in this case), will receive the message and provide its services to the requestor.
The Service Layer, implemented as part of the Enterprise Service Bus, exposes several Application Programming Interfaces (API) for consuming location-based services. Examples of services that can be implemented (not an exhaustive list) are:
Internal implementation of the API as accessible by the CRM and the GIS systems via the ESB is done using the ASP.NET WebAPI technology, building relevant “controllers” and “models” for each entity.
WebAPI provides an HTTP-based RESTful platform for CRUD operations (Create Read Update Delete) on entities that abstracts from the specific implementation in the source and target systems (CRM and GIS). The public API exposed by the Service Layer, as listed before, consumes the available WebAPI internally for communicating with the relevant system, via the ESB and without accessing the system directly. Messaging queueing may be put in place for optimization of reliability and response performance and throughput.
API Layer Components.
Geocoding is interpolating spatial locations (Latitude and Longitude coordinates) from street addresses. Individual address locations can be interpolated, or estimated, by examining address ranges along a road segment. GIS software approximates where that address belongs along the segment. For example, an address point of 500 will be at the midpoint of a line segment that starts with address 1 and ends with address 1,000. Geocoding can also be applied against actual parcel data, typically from municipal tax maps. In this case, the result of the geocoding will be an actually positioned space as opposed to an interpolated point. This approach is being increasingly used to provide more precise location information.
Reverse geocoding is the process of returning an estimated street address number as it relates to a given coordinate. For example, a user can click on a road centerline theme (thus providing a coordinate) and have information returned that reflects the estimated house number. This house number is interpolated from a range assigned to that road segment. If the user clicks at the midpoint of a segment that starts with address 1 and ends with 100, the returned value will be somewhere near 50. Note that reverse geocoding does not return actual addresses, only estimates of what should be there based on the predetermined range.
Several location-based services can be exposed to the public (or external applications) based on the location of the requestor (an individual or an application), and the geographical data provided by the CRM. The GIS system can be leveraged for data calculation and transformation, and for displaying such information on maps.
Services exposed by the GIS application, in connection with location data available in the CRM, may be: