Technical Documentation
Before any new PR is done, a test case should run following the steps described below:
- Rename src/ to _src/
$ npm run init- Delete the new src/ and rename _src/ to src/
$ npm run build- Check configurations of
cdc-accelerator.preferences-center.com/inbuild/including the imported JS files in thewebSdk.jsfile and thePreferencesCenter-Landing.jsscreen-set $ npm start- Check if features look okay in the preview and without errors in the console
$ npm run deploy- Validate if configurations on /build were correctly sent to CDC
- Check the PR build result on jenkins https://onestrike.jaas-gcp.cloud.sap.corp/job/cx-servicesautomation/job/sap-customer-data-cloud-accelerator/view/change-requests/
To start using Customer Data Cloud accelerator please do the following actions:
- Clone this github repository to a local directory
- Create a project with your preferred IDE (e.g. VSCode)
- Install all project dependencies using the command
npm install. It is assumed that you already have node and npm installed, if not please do it first - Define project configuration:
Open or create the file .env and define the value of the properties USER_KEY and SECRET_KEY. These are the credentials used to access Cloud Data Customer console. Open or create the file cdc-accelerator.json and define the sites' info that you want to work with. See configuration chapter for details.
- Execute the command
npm run update-sap-cdc-toolkitto update the code of a dependency used to interact with Customer Data Cloud. This command will add the directory cdc-accelerator/sap-cdc-toolkit inside the project with the dependency source code.
At this point you are ready to start working on the Customer Data Cloud accelerator project or on a Customer Data Cloud's customer project.
Customer Data Cloud accelerator offers some operations to be used by the user when working on a project, these are described next:
This operation will get the data from the site(s) configured on file cdc-accelerator.json.
It creates a src directory and one to many subdirectories named with the site domain. Inside the subdirectories, is also created a directory, for each feature, that will have files containing feature related data.
This feature will only work if the src directory do not exists, otherwise it will show an error, saying that data already exists and to use the reset operation to start from scratch.
These files in src directory are the ones to work with by the user.
This operation will recursively delete the src directory and execute the init operation.
This operation will process the files, for each site and each feature, that exist on src directory and bundles them, in a way to be prepared to be sent to the Cloud Data Customer console. These processed files are stored in the build directory containing the same directory structure as the src directory
This operation will run the build command and then process the files, for each site and each feature, that exist on build directory and send its data to the Cloud Data Customer console, using its REST API.
This operation will start a local development server. This server will execute the content of the cdc-accelerator/preview directory to render the content of the build directory. This will allow local development manual testing before deploying the data to the Customer Data Cloud's console
This operation will execute the unit tests implemented for each feature implemented on Customer Data Cloud accelerator
The working directory structure can be seen on the next image:
There are two kind of features: partner features, which executes on partner level and site features, which executes on site level. The next chapter will describe the site features.
This feature allows a user to change a site's schema related data.
During this operation the schema related data is obtained from a site and stored on different files on directory src/<partner-name>/Sites/<site-domain>/Schema.
The files are called data.json, which contains the data schema related data; profile.json, which contains the profile schema related data; and subscriber.json, which contains the subscriber schema related data.
The following image shows the schema related data on Customer Data Cloud console:
During this operation the Schema directory, of all sites that are configured on the configuration file, will be refreshed with the schema data of the sites. More detailed the Schema directory, of all sites that are configured on the configuration file, will be deleted and then it is executed the init operation.
During this operation the schema files are simply copied from the src directory to the build directory, maintaining the directory structure.
There is no need to perform any transformation on the files
During this operation the schema files are read from the build directory and its content sent to Customer Data Cloud console using its REST API.
This feature allows a user to manage a site's policy-related data.
During this operation the Policies are obtained from a site and stored on different files on directory src/<partner-name>/Sites/<site-domain>/Policies.
The files are called policies.json, which contains the policies policy-related data.
During this operation the Policies directory, of all sites that are configured on the configuration file, will be refreshed with the policies data of the sites. More detailed the Policies directory, of all sites that are configured on the configuration file, will be deleted and then it is executed the init operation.
During this operation the policies files are simply copied from the src directory to the build directory, maintaining the directory structure.
There is no need to perform any transformation on the files
During this operation the policies files are read from the build directory and its content sent to Customer Data Cloud console using its REST API.
This feature allows a user to manage the webSdk data.
During this operation the webSdk related data is obtained from a site and stored on a different file on the directory src/<partner-name>/Sites/<site-domain>/WebSdk.
The files are called webSdk.json, which contains the data webSdk related data;
During this operation the WebSdk directory, of all sites that are configured on the configuration file, will be refreshed with the webSdk data of the sites. More detailed the WebSdk directory, of all sites that are configured on the configuration file, will be deleted and then it is executed the init operation.
During this operation the webSdk files are simply copied from the src directory to the build directory, maintaining the directory structure.
There is no need to perform any transformation on the files
During this operation the webSdk files are read from the build directory and it's content is sent to the Costumer Data Cloud console using it's REST API.
This feature allows a user to change a site's web screen sets related data.
During this operation the web screen sets related data is obtained from a site and stored on different files on directory src/<partner-name>/Sites/<site-domain>/WebScreenSets.
A subdirectory is created for each web screen set with the same name as the web screen set. The files are called .js, which contains the javascript code of the web screen set; .default.css, which contains the style sheets code of the web screen set.
The following image shows the web screen set related data on Customer Data Cloud console:
During this operation the WebScreenSets directory, of all sites that are configured on the configuration file, will be refreshed with the web screen set data of the sites. More detailed the WebScreenSets directory, of all sites that are configured on the configuration file, will be deleted and then it is executed the init operation.
During this operation the web screen set files that exists on the src directory are processed and bundled together in the build directory. The src directory can have several files, more than the initially created during the init operation. For example if the user want to customize the css code, instead of changing the .default.css, he should create a new file .custom.css and during the build operation these files will be merged into a single file called .css. The same can happen with the javascript files, instead of adding lots of code into a single file, we can write the code in several modules, a file can import code from other files and during the build operation these files will be merged into a single file called .js.
During this operation the web screen set files are read from the build directory and its content sent to Customer Data Cloud console using its REST API.
This feature allows a user to change a site's email templates related data.
During this operation the email templates related data is obtained from a site and stored on different files on directory src/<partner-name>/Sites/<site-domain>/EmailTemplates.
Two subdirectories are created for each email template:
- locales - will contain several subdirectories, one for each email template, each one containing one or more translation files. The filename's pattern is .json TODO Explain content
- templates - will contain one or more template files. The filename's pattern is .html TODO Explain content The following image shows the email templates related data on Customer Data Cloud console:
TODO Add image
During this operation the EmailTemplates directory, of all sites that are configured on the configuration file, will be refreshed with the email templates data of the sites. More detailed the EmailTemplates directory, of all sites that are configured on the configuration file, will be deleted and then it is executed the init operation.
During this operation the email templates files that exists on the src directory are processed and bundled together in the build directory.
During this operation the email templates' files are read from the build directory and its content sent to Customer Data Cloud console using its REST API.