Name: An Introduction to Webhooks - SAP Customer Data Cloud
Uploaded: 2020-6-15
Duration: 477 s
Description: This video will introduce SAP Customer Data Cloud Webhooks, followed by a demo on how to configure Webhooks in the Console and see the end to end flow.Check documentation for details https://developers.gigya.com/display/GD/Webhooks

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>This video will introduce SAP Customer Data Cloud Webhooks, followed by a demo on how to configure Webhooks in the Console and see the end to end flow.<br>Check documentation for details <a href="https://developers.gigya.com/display/GD/Webhooks" rel="nofollow noopener noreferrer" target="_blank">https://developers.gigya.com/display/GD/Webhooks</a></div></div>

An Introduction to Webhooks - SAP Customer Data Cloud

Hello and welcome.  In this video, we are going to introduce SAP Customer Data Cloud Webhooks,  followed by a brief demo on how to configure Webhooks in the CDC Console.   CDC Webhooks offer a flexible way to extend CDC flows.  It sends a notification to your server on the specific CDC event.  With Webhooks, you can implement your own code,  and set it to trigger when the relevant hook is fired.   Webhook notifications are sent in near real-time and are delivered at least once.   For a list of supported Webhook events,  please visit our documentation portal developers.gigya.com.   The use of webhooks is one of several ways to integrate CDC with other downstream systems.  One example of a webhook triggered event is a new account registration.  When a new account has been registered,  CDC sends a webhook notification to a service endpoint,  usually hosted on the client's side.  The client can implement their own code on that endpoint, and set it to trigger when the hook is fired.  Next, the service endpoint will process the payload, and distribute it to a downstream system.   An important thing to mention is that CDC recommends enqueuing the webhook data  after sending the 200 Success HTTP status code and processing the data asynchronously.  A Queue Data Structure is the recommended architecture to maintain the order of event data.  Without a Queue Data Structure, it is very likely that a customer's service point will not be able to handle, and respond to webhook notifications on time,  for instance, during traffic spikes.  The MessageQueue will be the application used to log, and then asynchronously process the events.  The explanation of the flow presented in the picture is as follows: 1. Once an event is triggered in the CDC database, the Webhook will trigger the configured endpoint.  2. The endpoint will receive the payload,  and will run a simple check of the header field to verify the authenticity of the request.  If it's a valid request, the endpoint will respond with ‘200 status’ to notify CDC  that the request was correctly received.  If it's not a valid request, the endpoint will respond with a different status.  3. The endpoint will then enqueue the request in the MessageQueue. 4. Once a request is available for processing,  the MessageQueue will serve the next message in the queue for further processing in downstream systems.	  5. Downstream systems retrieve events from the MessageQueue,  perform additional calls to CDC, process the events,  and finally, delete the event from the queue. Some   Some common use-cases for the use of Webhooks include:	 Triggering communications from a Marketing Automation system,  like sending personalized marketing materials to a user based on particular actions.	 Synchronizing CDC users with Commerce Cloud, and replicating your user database.  There are different versions of Webhooks.  Newer versions of Webhooks contain more information in the payload.  Make sure your downstream systems are prepared to receive the new type of notifications and associated data.  The currently supported versions are: 	 1.0 - If you select this version,  Webhooks will be sent out only for interactions performed by fully registered accounts. 	  1.1 - Here Webhooks will be sent out also for lite account interactions. It will include a CallId and version. 	2.0 – This version support using   2.0 – This version support using webhooks with Global Access.  It signs the webhook notifications with a JWT.  Webhooks can be verified with the accounts.getJWTPublicKey endpoint  without having to exchange secrets with the webhook recipient.  It adds the API key of the site that initiated the notification to the webhook payload,  supporting site group scenarios, where an event should be triggered only when a webhook was initiated from a specific site.  This is a Webhook configuration page.   To create a Webhook we: Give a unique name to the Webhook.	  Mention the notification URL where the Webhook’s notification will be sent,  when the subscribed event is fired. 3.	  For version 1.0 or 1.1 we can configure how to sign the notification.  For version 2.0 the Webhook will be signed with a JWT4.	  Then select the event to which the Webhook should subscribed to.  We can send additional details to the notification using HTTP custom headers.  These headers are sent together with the webhook notification, in the form of key-value pairs.   It is possible to define multiple webhooks for a site.  To retrieve all the webhooks defined, call the accounts.webhooks.getAll API.   The API response contains the 200 Success HTTP status code, and the list of all webhooks configured for that specific site.   Let’s see how to configure a Webhook to Subscribe to an Event.  We can configure in the CDC Console or through an API.  In this demo we will use the CDC console.   Select the API key of the site.   Under Registration-as-a-Service, open the Webhooks page.   Create a new Webhook.   Give it a unique name.   Enter the URL of the endpoint to which the notification will be sent.  The URL must be secured behind HTTPs.   For this demo, we will create a version 2.0 Webhook,  which signs the notifications with a JWT.   Finally, select the events to subscribe to and save the configuration.   The URL represents the endpoint where notifications are being handled, and payload processed.   To acknowledge the notification,  the notification URL must respond with an HTTP 200 status code.  If the response takes more than 10 seconds or the response is anything other than Success,  CDC resends the notification at increasing intervals for up to one hour.  If CDC does not receive any response at all, the endpoint is considered offline.  Let’s look at the endpoint URL code.  The code is available on developers.gigya.com.   It is a sample PHP code.   The page receives notification from CDC, and validates the JWT subject against the event body.   If it is valid, it responds with status code: 200 = OK.  So, CDC won't resend the notification.  If it's not valid, it responds with a status code 400, that means Bad Request.   It is strongly recommended to validate the JWT for webhooks version 2, or to recalculate the signature hash for version 1,  in order to confirm that this webhook notification is in fact coming from CDC servers.   In order to log the data provided by this webhook,  we are going to add a few lines of code.  Besides logging the data, we will make an API request by sending accounts.getAccountInfo  to CDC in order to get the account data,  since the ID is the only information provided by the webhook notification.   In this example a user logs in to our CDC site using Google.   Our webhook is configured to send the notification when the ‘Account created’ event is being triggered.   Inspecting the logs after a user has logged in shows us that we are notified of the event type and the user ID.   Thank you for watching.