Skybridge Infotech, Sitecore Certified Solution Partner

By Author: Skybridge Infotech
Total Articles: 6
Comment this article

HOW SITECORE TECHNOLOGY PLAYS SO WELL WITH OTHERS
At Skybridge Infotech, sitecore certified partner, we strive to make it as easy as possible to integrate external systems and data with our technology. Having APIs that allow developers to interact with the various Sitecore implementation services—like content management, personalization, tracking, or analytics—is a critical piece of the integration puzzle. But having APIs only makes integration possible. It doesn’t make it easy.
Sitecore Data Exchange Framework (DEF) is a fully supported module that makes it easier to build custom connectors for Sitecore products. It provides a standardized design that accomplishes several things:
• reduces the amount of work you need to do to design new connectors,
• ensures new connectors are compatible with existing connectors, and
• allows you to define much of the integration logic through configuration rather than through code.
You may have read about Sitecore’s strengths and cautions, which mentioned DEF, in the recent 2017 Gartner Magic Quadrant for Web Content Management. DEF facilitates ...
... the transfer of data between third-party content, analytics, and other data sources with the Sitecore Experience Platform. This blog explains how that works, and how developers can use DEF to ensure integration between Sitecore and other systems.
Anatomy of a connector
To understand why DEF matters, let’s consider an example. Imagine you want to use data from your organization’s home-grown CRM to personalize a landing page you’ve created. That landing page is part of a campaign targeting customers who dialed your call center during the last month.
The connector must support the following:
1. Read data from the CRM
2. Map data from the CRM to the Sitecore® Experience Database™ (xDB)
3. Write the mapped data to xDB
There’s no getting around #1. You have to write the code to do this. But what about #2 and #3? These are very common requirements for connectors. You shouldn’t have to write a lot of code for those requirements, because someone else has almost certainly already written it.
And even if you aren’t daunted by the idea of having to build #2 and #3, there are good reasons not to. Do you really want to be responsible for keeping those components up-to-date? When a new version of Sitecore is released, do you want to figure out the breaking changes and how to accommodate them?
This, in a nutshell, is what DEF does. It isolates the parts of a connector that are truly unique to that connector from the parts that are shared with other connectors. Sitecore has already built the components that handle #2 and #3. You as a developer only need to build the components that support #1.
Extract, transform, and load
If you have experience with system or data integration, you may be thinking “this sounds like an ETL tool.” You would be right. DEF is an ETL tool for Sitecore.
If you aren’t familiar with ETL, it stands for extract, transform, and load. “Extract” is reading data from a source system. “Transform” is converting data from its original format into a format that is compatible with a target system. “Load” is writing the transformed data to the target system.
We are not reinventing the wheel here. We have built a product based on a data integration strategy that has been successfully used for many years, but did it in a way that fits naturally in the Sitecore ecosystem.
Providers and connectors
Providers are the basic building blocks for DEF. A provider represents the ability to interact with a specific system. Sitecore has created a provider for interacting with Sitecore. For example, it lets you interact with content in a Sitecore database and with contacts in xDB. Sitecore also has created a provider for interacting with Microsoft Dynamics. (And we have more providers coming soon.)
These providers are used to build connectors. For example, our connector for Microsoft Dynamics uses the DEF providers for Dynamics and Sitecore in order to enable bidirectional data synchronization.
However, it is important to understand that a connector is more than just its providers. The provider gives you the ability to read contacts from your CRM. The connector gives you the ability to synchronize contacts from your CRM with contacts in xDB. The provider gives you the ability to create a campaign response in your CRM. The connector gives you the ability to use the visitor’s behavior on your website to determine the most appropriate kind of campaign response to create in your CRM.
Compatibility
DEF simplifies the process of building connectors by ensuring providers are compatible with one another.
Providers are never dependent on one another. The DEF provider for Sitecore is a stand-alone component. It focuses on providing read and write access to Sitecore databases. The DEF provider for Dynamics is also a stand-alone component. It does not depend on the DEF provider for Sitecore to work.
Since both of these providers are built for DEF, they are compatible with each other. A connector can use components from the Sitecore provider and the Dynamics provider. In fact, this is exactly what a connector should do. In the future, you can add new providers to your Sitecore environment, and those will be compatible as well.
Configuration vs. coding
Sitecore has long used the concept of pipelines to implement business logic. If you aren’t familiar with pipelines, it helps to understand that a pipeline represents a task or a process. Examples include “publish page,” “translate content,” or “add product to cart.”
In many systems, these things correspond to APIs. For example, there’s an API to publish a page where you identify the page to publish and the system will publish the page.
And many products allow you to replace the logic used when that API is called. This is basic extensibility. You can completely replace the existing logic. Or you can add logic to run before the existing logic, and logic to run after the existing logic runs.
Pipelines offer something much more flexible and powerful. In a pipeline, the logic is represented by individual steps. Steps can be added, removed, reordered, enabled, and disabled though configuration. No code changes are needed. This adds an extra layer of control and transparency that is very useful when trying to connect systems that vary widely and may be extensively customized.
Eyes wide open
System and data integration are complicated. I don’t want to give the impression that DEF makes integration easy. It doesn’t. But, as we believe Gartner’s report acknowledges, it definitely makes it easier than it was before, by providing structure, consistency, and reusability.