powerobjects: Dynamics 365 as an Application Integration Platform

[Blog bot]

Источник: https://www.powerobjects.com/2018/04...tion-platform/
==============


Early versions of Dynamics 365 targeted small and medium-sized businesses – for which there is a relatively simple system architecture and where the system directly holds the data and relationships about customers, services, products, etc. The integration between Dynamics 365 and other systems are kept to a minimum and are typically ETL based.

As Dynamics 365 is making its way into enterprises, it must operate within a much more complex system architecture which typically consists of a relatively high number of both Cloud and on-premises systems. In addition, the role of a CRM system is evolving as the enterprise is gradually adopting its Cloud strategy and moving crucial business data and processes to the Cloud one-step a time. At any given point of time, a CRM system is required to maintain a proper balance between its integration role and as a direct source of business data.

Typically, before an enterprise adopts Dynamics 365, data of customers, services, products, etc. are stored in different on-premises Line of Business (LOB) systems. At the introduction of Dynamics 365, it is unlikely the enterprise will move all relevant data to the system all at once. Most likely, Dynamics 365 will not serve as the master source of those LOB data, instead it will play the role of integrating those LOB data and be able to present them to users. Over time, LOB data and business processes can be gradually migrated to Dynamics 365 and the LOB systems can be gradually retired, as the enterprise grows more confident in Dynamics 365 and the Cloud in general. Hence, the enterprise application integration capabilities of Dynamics 365 are crucial to its adoption by enterprises.

Although Dynamics 365 has a wide range of integration capabilities such as those with Azure Service Bus, SharePoint, and Outlook, this blog focuses on leveraging Dynamics 365 custom actions and plugins to integrate LOB applications and present Dynamics 365 users with unified view of customer, service, and product data.

The following diagram depicts such an architecture with Dynamics 365 as an application integration platform:



Dynamics 365 users access enterprise service and data via web forms, web resources, or Unified Service Desk (USD) hosted controls by interacting with Dynamics 365 web services and APIs. As part of the Dynamics 365 web services and API, custom actions can be used to present any service function API CRM and they can be wired with plugins so that when a custom action is invoked, the proper plugins are executed. The plugins can interact with one or more LOB systems (possibly via an Enterprise Service Bus) and may or may not access some Dynamics 365 records. This way, the plugins can implement any integration logic among LOB systems and records.

If the plugins do not access any records, the custom action is like a pass through to Dynamics 365 and accesses the LOB systems behind Dynamics 365 transparently via plugins. The plugins for the custom actions can be registered as synchronous or asynchronous, depending on the functional requirements of those custom actions. If they need to return data or result from LOB systems, the plugins are typically registered as synchronous. If they only need to push data to LOB systems and no need to wait for acknowledgements, they can be registered as asynchronous.

To leverage the wide range of Dynamics 365 capabilities such as entity forms, relationship management, and processes, it is necessary to have some records exist in Dynamics 365 that are representative of the corresponding (master) data records from LOB systems. These proxy records can be created by the relevant plugins when the records are needed by the Dynamics 365 users. Another set of plugins are used to propagate data changes from Dynamics 365 to LOB systems when data is changed by users.

A record typically has a subset of the LOB data fields and the LOB record key as an Dynamics 365 alternative key to maintain mapping to the LOB records. Depending on the system environment, the data synch from LOB system to Dynamics 365 can also be necessary and a separate synch service (with the reverse mapping) is needed to propagate data changes from LOB systems to Dynamics 365 via custom actions.

Dynamics 365 can also provide some offline capabilities for the LOB systems. When one or more LOB systems are down, Dynamics 365 can continue providing services to its users by capturing user input and later synchronize them to those LOB systems after they are back online.

As we can see, the Dynamics 365 custom actions and plugins mechanism provide a very flexible application integration platform for integrating enterprise LOB systems while gradually migrating them to CRM and the Cloud. However, it does require certain amount of custom code development for the plugins.

With virtual entities (starting version 9), Dynamics 365 raises data and application integration to a new level. Even though virtual entities are still in the very early stage, there are still a lot of limitations in the areas of update, security, strict requirements on external data source, etc. However, virtual entities have the great potential to dramatically reduce the custom development effort for application integrations and further strengthen Dynamics 365 as an application integration platform.

Be sure to subscribe to our blog for more helpful Microsoft Dynamics 365 tips!

Happy Dynamics 365’ing!



Источник: https://www.powerobjects.com/2018/04...tion-platform/