xConnect and the xDB
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:
The xConnect Collection service reads and writes interaction data. For example, the Content Delivery role submits web interactions to the xConnect Collection service.
The xConnect Collection Search service can read, write, and search contact and interaction data. For example, the Content Management role's List Manager interface uses the xConnect Collection Search service to search for contacts.
The xConnect Search indexer updates the xDB index as data is written to the xDB Collection database. Only a subset of the data in the xDB Collection database is indexed.
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:
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:
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
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:
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 Marketing Automation Engine and Marketing Automation Operations service read contact and interaction data as part of evaluating plan and activity enrollments. Use the Marketing Automation Reporting service to access reporting data about activity and plan enrollments.
Sitecore Cortex Processing Engine workers (Sitecore 9.1 and later) can read and write to xConnect. For example, you can project contact and interaction data into a format that is suited to machine learning.
The following diagram shows the default XP Scaled topology, which includes every role required to run the xConnect and the xDB: