Design Patterns to Be Used in Modernize Crm System

SBX - Finance Heading

Integration Design Patterns for Dynamics 365

on 2 Nov 2017 10:00 PM

Data migration and integration in Microsoft Dynamics 365 can be a complex topic because data is often more complex than what people realize. When delivering a new implementation of Dynamics 365, or when considering making your XRM system communicate with other IT systems, a proper design for data migration and/or integration is key to success.

Let's start by giving some definitions before we analyze some design patterns for system integration:

• Data Migration is the process of moving data from one system to another, which is often necessary in order to set up a new system with the data that already exists in the current systems.
• Data Integration is the process of building and maintaining the synching of data between IT systems over time.

While data migration and integration are two different things, the processes and design principles are very similar. In this post, I'll look at best practices and design patterns to model your data migration and integration strategies for Dynamics 365.

The Integration Journey

Effective and efficient Dynamics 365 integration with systems like web portals, data warehouse / BI applications, ERP systems, etc. is critical to making it a valuable business tool. Many organizations are making their XRM system the center of their technology portfolio of IT system to support the many business processes for sales automation, marketing, case management, etc. In order to provide a single view of their customers, though, it is necessary to integrate the XRM with other line of business applications and share relevant information. There are numerous touchpoints and opportunities for Dynamics 365 integrations to provide value for an enterprise, such as connecting to legacy systems, developing a partner ecosystem, or building new company initiatives. As the "journey" towards uncovering new opportunities and obtaining a single view of customers evolve over time, so integration does, often resulting in convoluted and over-engineered solutions. These types of point-to-point connections are neither practical nor sustainable. Separate teams involved, different designs and approaches, a variety of technologies and multiple vulnerability points to secure, all make the integration architecture a rich ecosystem that does not scale.

Spaghetti-style Integration Architecture

Point-to-point integrations grow a tangled architecture over time. Different technologies, different message formats, multiple endpoints, each of them to secure. Maintenance is a nightmare, and scalability is at stake. Say that you want to replace your SMS system, you would need to update all the connections towards the other systems. This is what I call a "spaghetti-style" integration architecture, and for as much I love spaghetti being Italian myself, in software architecture this is an anti-pattern to avoid at all costs.

What's the alternative? We want to avoid point-to-point connections and make sure that each endpoint can be (relatively) easily replaced, by abstracting its communication channel, message format, and by centralizing its security (i.e. one identity and access management system). A good approach to resolving these challenges is to introduce an enterprise system that conveys messages, exposes a common communication interface, and represents the single point of contact for all our IT systems. This system typically goes under the name of "Enterprise Service Bus", or ESB, and provides:

• Message publishing: Each system can submit a message (signal) and get it dispatched to another system.
• Topic subscription: A system "subscribes" to a specific topic and receives data only from other systems that publish messages in the same topic. This pattern is called Publish / Subscribe.
• Message queueing: Messages in input are queued in order to guarantee delivery. There is no strict requirement for the receiving endpoint to be available, as it would be in a direct point-to-point connection. If the target system is not available, the message is not lost. A mechanism for retrial of submission is in place for a determined period of time, passed which the message is eventually removed from the queue if not consumed by any system.
• Workflows: Integration flows can be built to define sequence of operations, for example data transformation or lookup into external APIs. This allows for messages to be enhanced, or "massaged", before they reach destination.

Integration Architecture based on Enterprise Service Bus

Next Steps

In the next articles I'll explore how to implement the Publish/Subscribe pattern in Dynamics 365 using Azure Service Bus, and describe a collection of different data integration patterns that an Enterprise Service Bus supports.

Design Patterns to Be Used in Modernize Crm System

Source: https://community.dynamics.com/365/b/xrmandbeyond/posts/integration-design-patterns-for-dynamics-365

Share this post