SAP Customer Data Cloud integration to AEM: Lessons Learned

Share on facebook
Share on twitter
Share on linkedin

An Overview – SAP Customer Data Cloud Integration with AEM

In this business case, we take a look at one of our customers, a large complex enterprise. They have a multitude of brands, each brand holding its own online domain/website and they were looking to have a holistic view of the consumers who use these sites, unfortunately, they still have independent registration and login for each domain making it tedious to see the data as a single customer view.  We looked into how SAP Customer Data Cloud (CDC) can achieve these requirements. As our customer is already using Adobe Experience Manager (AEM), we have created three separate basic AEM prototype sites. Each prototype site was integrated with CDC and their own site-level identity and consent store.  Below is a list of things we have learned while working on this POC:

Multi-Brand IDM

The initial approach we had for the POC is to put the brand sites in one site group. This way, the customers are stored in one database. Each brand site can also share site settings, provide configurations and policies.  However, with this implementation, a customer cannot register with the same email address in another child site. Once a customer registers, the customer will exist in all the sites under the site group. We then opted to not use a site group and explore how we can consolidate customer data from different sites. 

After installation and configuration, you just have to run the command

We have proven that it is possible with the following methods:
  1. Using CDC’s REST API. A Python class was created to query the accounts using API per site, looking for a particular username/email.
  2. Using CDC’s Dataflows tool to push data from each site to an SFTP server as a zip/csv file
  3. Using CDC’s Webhooks to send customer login/registration events to a running HTTP server.


CDC’s UI Builder is easy to use. You can simply select a screen-set from the console and it will take you to another page containing different forms for each screen. On each screen, you can simply drag and drop controls such as text box, checkbox and different kinds of widgets. There are also out-of-the-box validations for required fields and field types. The controls can easily be mapped into any field in the schematic.  A CSS editor is also available where you can modify the style of existing CSS classes or create new CSS classes which can be applied to a screen or to a specific control on the screen.  One limitation of using the UI builder is the form layout. Based on our experience it can only go to a maximum of two columns and as you can see from below, not all rows can have two columns. This is probably the reason why some would opt to develop the screens using markup extensions or using the Accounts API, especially for a profile update.

Social Login

Aside from site accounts, users can also register and login using their social network accounts. Instructions on how to configure these social network providers, such as Facebook, Google, Twitter, can be found in

When working on the change password screen, one thing to keep in mind is that there can be users who registered using their social network account so they do not have a password. For this, we have created two screens, one for password reset and another for password change. We have also updated the onBeforeScreenLoad event script to detect if the user has a password using the provider and the allowsLogin attributes.

// Called before a new screen is rendered. This event gives you an opportunity to cancel the navigation by returning false.
    onBeforeScreenLoad: function(event) {
    	function getAccountInfoResponse(response) {
            if ( response.errorCode == 0 ) {            
                var identities = response.identities;
                identities.forEach(function(element) {
                    if (element.provider === 'site' && element.allowsLogin === true) {
            else {
                console.log('Error :' + response.errorMessage);
                gigya.accounts.showScreenSet({screenSet:'Default-RegistrationLogin', startScreen:'gigya-login-screen'});
    	gigya.accounts.getAccountInfo({include: 'identities-all', callback: getAccountInfoResponse});

What’s Next

We are still experimenting on other use cases for CDC. Please watch out for other lessons we can share and feel free to share yours too.



Margaux Cabrera

Margaux Cabrera

Subscribe to our newsletter