xConnect and the xDB

Current version: 10.0

xConnect is the service layer that sits in between the xDB Collection database and xDB index, and any trusted client or device that wants to read, write, or search contact and interaction data. No other system has direct access to the xDB Collection database or the xDB index.

xConnect and the xConnect Client API

xConnect is made up of two web services and an indexing worker:

All clients must use xConnect to read, write, and search xDB data. Access to xConnect is secure by default and all clients must supply a valid certificate thumbprint. You can use the xConnect Client API (C#) or interact with the web API directly. The following diagram shows three applications (Content Delivery, Content Management, and a custom CRM) using the xConnect Client API to read and write contact and interaction data:

The xConnect application and worker roles.
Important

xConnect is not designed to receive data directly from a user-owned client such as a mobile phone.

xConnect supports multiple providers

xConnect supports the following providers:

  • Solr, SolrCloud (9.0 Update 2 and later), or Azure Search for the xDB index.

  • SQL or MongoDB (9.0 Update 2 and later) for the xDB Collection database.

Azure Search is the default search provider in Azure, and Solr is the default search provider for on-premise or IaaS deployments performed by the Sitecore Installation Framework. SQL is the default xDB Collection database provider for all deployments.

xConnect implements the oData protocol

xConnect implements the oData protocol. The oData protocol defines a set of standards for building and consuming RESTful APIs. Visit the oData website to find out more. By oData convention, the service root is: http://[xconnecthost]:[port]/odata. You can view the complete oData schema for xConnect at: http://[xconnecthost]:[port]/odata/$metadata.

Note

xConnect only supports the oData JSON format.

xConnect does not replace the web tracker

In Sitecore 9.0 and later, the web tracker submits interaction data to xConnect rather than accessing the xDB directly. Refer to the Web Tracking documentation for more information about the relationship between the Tracker API (including ContactManager and ContactRepository) and the xConnect Client API on a Content Delivery Server.

The Reference Data service

You often use xConnect together with the Reference Data service. Every interaction in the xDB contains ID references to marketing definitions such as campaigns, events, and venues. These marketing definitions are created and maintained in the Content Management environment, then to the Reference Data service.

The Reference Data service provides a centralized service for clients such as xDB Processing to access contextual information about marketing definitions, for example, the name of a campaign and the campaign group it belongs to. In the following example, the xDB Processing role uses a combination of data from xConnect and the Reference Data service to build reporting data:

xDB Processing role using a combination of data from xConnect and the Reference Data service.
Note

The Content Delivery also writes Geo IP, device, and user agent data to the Reference Data service.

The xDB and xDB subsystems

All contact and interaction data is stored centrally in the xDB Collection database. There are several xDB sub-systems that access contact and interaction data via xConnect:

The following diagram shows the default XP Scaled topology, which includes every role required to run the xConnect and the xDB:

Default XP scaled topology.

Do you have some feedback for us?

If you have suggestions for improving this article,