CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

SAP Customer Data Cloud Site Setup

9 min read

Quickly and easily produce an architecture and implement in SAP Customer Data Cloud

Overview

The SAP Customer Data Cloud enables speedy setup of environments within the Admin Console; however, it is important to note that you cannot delete these sites once they're created.

This article presents an easy-to-implement approach for producing a SAP Customer Data Cloud site architecture that can quickly be implemented but is also expansible enough to accommodate future-states.

Table of Contents


What is the SAP Customer Data Cloud Admin Console?

The SAP Customer Data Cloud Admin Console is the application portal through which you manage the settings relevant to the site or sites that you are integrating for use with the SAP Customer Data Cloud solution. These settings will govern how integrated applications and end-users using these applications interact with your implementation of the SAP Customer Data Cloud.

When you log into the SAP Customer Data Cloud console you are logging into a SAP Customer Data Cloud environment - often referred to as Partner - due to each environment having a unique Partner ID (a 7-digit number).

A single user can be a member of one or many environments.

How do I get a SAP Customer Data Cloud Console Login?

If you are designated as an Administrator of the console for your organisation, you will receive an email with a link allowing you to create a single Partner. If you are not an Administrator, then the Administrator will be responsible for inviting you to the Partner.

What are the Next Step that I need to Take?

Once you have logged into the SAP Customer Data Cloud console, we recommend reading the collateral on site setup configuration options here:

Sites

A ‘site’ is simply a term used to describe a unique API key within the SAP Customer Data Cloud. The site is given a name which is a semantic description of what that site is being used for and it’s relationship with both its’ children and other parent sites within the environment.

Parent & Child Sites

Within the out-of-the-box setup, sites have the following 1:many parent:child relationship:

The following rules apply to the parent:child relationship:

  • Integration can take place against any of the API keys within a site group
  • User accounts reside against the parent API key regardless of if a child is used for integration
  • Child sites inherit all settings and configuration values from the parent
  • Certain settings and configuration values can be overridden by the child

Site Groups & SSO

Whilst this document won't go into how to configure site groups and how SSO is implemented, it's important to understand the relationships between sites when they are and are not part of a single site or SSO group as this will influence your decisions for how your sites are configured.

Considerations include:

  • How will I be implementing SSO?
    • Per-brand?
    • Per-country?
    • Per-service?
      • Or will I be implementing SSO across all of my applications?

Common Site Group Configurations

Multiple Disparate Brands/Services in Disparate Markets

Your business may have multiple brands/services in multiple markets all of whom compete with one another. In this instance, the configuration below is recommended:

This seeks to allow:

  1. Unique site configuration per-brand/service per-market
  2. No SSO cross-brand/service or cross-market
Consolidated Categories of Brands/Services in Disparate Markets

Your business may group seemingly disparate brands/services into categories that share configuration options but do not share SSO outside of these categories. In this instance, the configuration below is recommended:

All Brands Consolidated Across Disparate Markets

Your business may group all brands/services together per-market, enabling a consistent configuration and SSO. In this instance, the configuration below is recommended:

Full SSO Across Markets

Your business may group all brands/services together across all markets, essentially enabling a single identity across all regions. In this instance, the configuration below is recommended:

Naming Conventions

When coming up with a naming convention for your sites, it's important to consider all processes during which you will interact with the site and how semantic these will need to be. These could include:

  1. Managing site configuration from within the SAP Customer Data Cloud console
  2. Orchestrating site configuration from one site to another
  3. Acknowledging client-side calls by verifying trusted URLs configured against the sites (which could default to the site names within the SAP Customer Data Cloud)
Parent(s)

A recommended template for parent site naming conventions is below:

Part I Part II Part III Part IV Part V Part VI
sso. parent. {brand/service} {market}. {dataCentre}. {environment}

The above table is a recommendation to cover all use-cases; not all 'parts' are mandated to be used, but this can act as a jumping-off point for your parent site(s) naming convention

The 'parts' resolve back to the following definitions:

Part Definition
sso. A static placeholder to indicate SSO being applied to the site group or not
parent. A static placeholder to indicate that the site is being used as a 'parent'
{brand/service} A brand or service that you offer as an independent function within your business unit; think of the SAP Customer Experience Cloud within SAP
{market}. The market that you operate in; this could also be 'country' or 'region'
{dataCentre}. The data centre that the parent belongs to
{environment} The environment as adjudicated by your SDLC; common examples are 'development', 'staging' and 'production'
Example Naming Convention

An example of the naming convention above when applied to a real project is as-below:

  • sso.parent.customerExperienceCloud.uk.eu.production
Children

A recommended template for child site naming conventions is below:

Part I Part II Part III Part IV Part V
{channel}. {brand/service} {market}. {dataCentre}. {environment}

The above table is a recommendation to cover all use-cases; not all 'parts' are mandated to be used, but this can act as a jumping-off point for your child site(s) naming convention

The 'parts' resolve back to the following definitions:

Part Definition
{channel}. The channel used by the integrating application; common examples include 'web' and 'mobile'
{brand/service} A brand or service that you offer as an independent function within your business unit; think of the SAP Customer Data Cloud within SAP
{market}. The market that you operate in; this could also be 'country' or 'region'
{dataCentre}. The data centre that the parent belongs to
{environment} The environment as adjudicated by your SDLC; common examples are 'development', 'staging' and 'production'
Example Naming Convention

An example of the naming convention above when applied to a real project is as-below:

  • web.customerDataCloud.uk.eu.production

Environments

As indicated above, the SAP Customer Data Cloud team recommend synchronizing the environments configured within your Partner with your front-end applications and the SDLC.

The out-of-the-box functionality with the SAP Customer Data Cloud is to contain all environments within a single Partner; therefore, the below recommended setup applies to a single Partner only.

Common Environment Configuration

The naming convention presented within this document assumes a DevOps alignment between the sites and thus enables continuous delivery through the environments. This naming convention correlates to the recommended setup below:


Conclusion

Once you have read this article, you should be in a position to do one of two things:

  1. Produce & present a site architecture to be signed-off ready for implementation
  2. Ready to implement your site architecture

To reiterate the message at the outset of this document:

Sites cannot be deleted once created, so ensure that the architecture has been considered from all perspectives

Overlay