Name: Introducing Extensions in SAP Customer Data Cloud
Uploaded: 2024-5-28
Duration: 405 s
Description: This video introduces SAP Customer Data Cloud Extensions, followed by a demo showing how to configure Extensions in the CDC Console and end to end flow.

Share feedback

<p>Planned maintenance of Practice Systems</p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Subscribe now

Learn more

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div><div><div>This video introduces SAP Customer Data Cloud Extensions, followed by a demo showing how to configure Extensions in the CDC Console and end to end flow.</div></div></div></div></div></div></div></div></div>

Introducing Extensions in SAP Customer Data Cloud

Hello. In this video, we are going to introduce SAP Customer Data Cloud Extensions, followed by a brief demo showing how to configure Extensions in the CDC Console.  CDC extensions ​enable a quick implementation of your custom data validations and restrictions.  Extensions support secure, server-side, synchronous execution of your code.  Using Extensions, you can meet a wide range of business use-cases, such as registration validations or data enrichment.  For the list of available CDC API endpoints to which extensions can be attached, please visit developers.gigya.com.  One supported use of Extensions is to perform validations on data submitted by the client, right before CDC commits the operation.  In this example, we will look at a registration initiated by a user.  When the accounts.register API is executed, CDC triggers an extension point, straight after which CDC runs all validation checks that are required for creating the user in the database,  and right before creating the user.  After this point, unless the response returned to CDC from the extension endpoint specifically requests to fail the registration, CDC will proceed with the registration as usual.  Next, CDC propagates the registration response to the client.  If the extension endpoint responded “Fail”, the corresponding custom error is displayed to the user.  Another supported use of Extensions is to perform data enrichment.  In this scenario, the extension point is triggered during the account.setAccountInfo API, immediately before account data is written to the database.  Data enrichment can be achieved in the extension endpoint by overriding received user data with a different data set.  For instance, data retrieved from a third-party system.  Some common use-cases for Extensions include: Preventing a user from registering with an abusive username, or with a disposable email address.  Validating a user’s address and checking if the address exists in an official address database.  Performing transformations and enrichment of the profile data submitted by a user during a profile update flow.  This is an Extension configuration page.  To create an Extension, follow these three steps:  1. Give the extension a friendly name, and select the API to which this extension is attached.  2. Enter the URL where the extension is hosted.  Your custom code should be hosted on a designated URL, and the CDC Extension service will send an HTTPS POST request to that URL.  3. Under Advanced, you can customize the timeout. The default timeout is 1 second.  You can also customize the Fallback policy. The default setting is to ignore the error, meaning the user flow will not be failed. You can change this policy to fail the user flow on any extension error. For instance, if a timeout occurs when calling the extension, CDC could abort the user flow.  This is the extension logs page in the CDC Console.  Here, a log is written every time an attempt is made to call an extension.  The tooltips in the first table column indicate which response was received from the extension: The green icon indicates that an extension sent a valid response and allowed CDC's flow to proceed.  The red icon indicates that an extension sent a malformed response, or the response took too long.  The flow was allowed to continue or stopped, depending on the configuration of the fallout policy.  Finally, the orange icon indicates that an extension sent a valid response that indicated to CDC that the flow should be stopped.  Let’s see how to set up an Extension attached to an event.  We can configure it in the CDC Console or through the API.  In this demo we will use the CDC console.  Select the API key of the site.  Under Basic open the Extensions page.  Add a new Extension.  Give a unique name.  Select the event to which this extension is attached. For this demo, we will create an extension to the registration flow.  Enter the URL where the extension code is hosted.  The URL must be secured behind HTTPs.  Finally, save the configuration and enable the extension.  Let’s look at the endpoint URL code.  The code is available on developers.gigya.com.  It’s a sample JavaScript code for a node.JS application.  The endpoint receives a POST request from CDC with a JSON body that contains a single base-64 encoded JWT parameter.  The JWT consists of three parts:  Header  Payload  Signature  First, the JWT must be verified using the accounts.getJWT PublicKey API to retrieve the public key for validation.  If it’s valid, the extension will proceed to the validation or data enrichment logic.  If it’s not valid, the extension will respond with status fail.  The custom code will execute one simple validation using the OnBeforeAccountsRegister extension. The validation will prevent users from registering with any domain but the "xyz" domain.  CDC expects to receive a response from the extension URL.  The response could be one of the following:  A response indicating that CDC should proceed as usual with the registration process;  or a response indicating that the registration should be failed.  Finally, the response object is sent back to CDC.  In this example, a user attempts to register on our CDC site using an invalid email address.  Our extension is configured to validate the parameters submitted when the registration flow is being triggered.  This is how it would appear to the end users:  a user trying to register with domain "x" will receive the custom error sent by the extension.  Now, a user trying to register with the valid domain “xyz”, will be able to complete registration.  Thank you for watching.