Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
sissa
Advisor
Advisor
2,117
The objective of this example is to demonstrate how to setup a Kyma serverless function to be used as an SAP Customer Data Cloud Extension endpoint.

SAP Customer Data Cloud Extensions allow us to synchronously intercept specific SAP Customer Data Cloud REST API calls on the server-side and to execute custom business logic before the specific API call invokes SAP Customer Data Cloud. They also act like filters as they can be used to prevent an API call from invoking SAP Customer Data Cloud by returning a status with the value of "FAIL" and a custom error message to the user if specific business rules aren't met.

Currently, the following SAP Customer Data Cloud REST API calls can be intercepted using an SAP Customer Data Cloud Extension:

  • accounts.register - Registration (OnBeforeAccountsRegister extension)

  • accounts.login - Login (OnBeforeAccountsLogin extension)

  • socialize.login - Social Login (OnBeforeSocialLogin extension)

  • accounts.setAccountInfo - Profile Updates (OnBeforeSetAccountInfo extension)

  • accounts.resetPassword - Reset Password (OnBeforeResetPassword extension)

  • Send SMS - Communication (OnBeforeSendSMS extension)


In this example, the accounts.setAccountInfo REST API endpoint has been intercepted to cleanse the user's address via an external SAP Data Quality Management microservice.

If the address can be cleansed, the request is enriched with the cleansed address and the user's account is updated.

On the other hand, if the address can't be cleansed, an error message is returned to the user and the user's account isn't updated.

The code of this example can be easily re-used to build any other SAP Customer Data Cloud Extension and deploy it to SAP BTP, Kyma Runtime or to Kyma Open Source.
Notes:

  • All the functionality presented here are subject to change and may be changed by SAP at any time for any reason without notice.

  • For demonstration, this example uses an API Key to authenticate requests to SAP Data Quality Management. In a real-world scenario, either OAuth 2.0 or Client Certificate Authentication are to be used.



Scenario


This example includes a Kyma serverless functioncdc-extension, that is exposed as an SAP Customer Data Cloud extension endpoint, and demonstrates how to:

Solution Architecture




Sequence Diagram




Suggested introductory readings



Pre-requisites



Deployment steps



  1. Go to the kyma-runtime-extension-samples repository and clone it. This repository contains a collection of Kyma sample applications including this example (in the cdc-extension subfolder). Download the code by choosing the green Code button, and then choosing one of the options to download the code locally. Alternately, you can also run the following command using your command-line interface within your desired folder location:


  2. Update the values of the following environment variables in the ./kyma-runtime-extension-samples/cdc-extension/k8s/function.yaml file:
    CDC_API_KEYSAP_API_HUB_API_KEYPUBLIC_KEY_KIDPUBLIC_KEY_N and PUBLIC_KEY_E

    • CDC_API_KEY - This is the API Key of the SAP Customer Data Cloud site and can be got from the SAP Customer Data Cloud console.

    • SAP_API_HUB_API_KEY - This is the API Key of SAP API Business Hub. Login to api.sap.com. Then, go to your profile settings and click on Show API Key to get the value for this variable.


    Go to https://accounts.SAP_Customer_Data_Cloud_Data_Center/accounts.getJWTPublicKey?apiKey=Your_SAP_Customer_Data_Cloud_Site_API_Key.

    Find your SAP Customer Data Cloud Data Center. Replace SAP_Customer_Data_Cloud_Data_Center with your Data Center (For example, the US Data Center is us1.gigya.com). Replace Your_SAP_Customer_Data_Cloud_Site_API_Key with your SAP Customer Data Cloud site's API Key.

    The response JSON body of the above request will also include the following fields: kidn and e

    • PUBLIC_KEY_KID - This is the value of the kid field in the response above.

    • PUBLIC_KEY_N - This is the value of the n field in the response above.

    • PUBLIC_KEY_E - This is the value of the e field in the response above.



  3. Create a Kubernetes namespace with the name cdc.

    • kubectl create namespace cdc


    Note: As a prerequisite, please follow the steps listed in the following tutorial: Download the Kyma Runtime kubeconfig

    Alternately, use the Kyma Console User Interface to create a new namespace

    • Open the Kyma console and click on Add new namespace. Enter its name as cdc and click the Create button.



  4. Create/update Kubernetes resources of the cdc-extension serverless function.

    • kubectl apply -f ./kyma-runtime-extension-samples/cdc-extension/k8s/function.yaml

    • kubectl apply -f ./kyma-runtime-extension-samples/cdc-extension/k8s/api-rule.yaml


    Note: As a prerequisite, please follow the steps listed in the following tutorial: Download the Kyma Runtime kubeconfig

    The resources are represented as declarative YAML objects. Applying the resources will perform the following steps:

    • Deploy the Kyma serverless function

    • Expose the serverless function using a Kyma API Rule that will serve as the SAP Customer Data Cloud Extension endpoint



    Alternately, deploy the Kyma serverless function and API Rule using the Kyma Console User Interface:

    • Open the Kyma console and select the cdc namespace.

    • Click on Workloads. Then, click on Deploy new workload and select Upload YAML.

    • Then, click on Browse to select the following YAML file, and click on Deploy./kyma-runtime-extension-samples/cdc-extension/k8s/function.yaml

    • Repeat the above steps and select the following YAML file. Then, click on Deploy./kyma-runtime-extension-samples/cdc-extension/k8s/api-rule.yaml




  5. Go to the Kyma Console -> cdc namespace -> Discovery & Network -> API Rules. Copy the host URL of the cdc-extension API Rule.




  6. Then, go to the SAP Customer Data Cloud Console. Select your site and click on Extensions -> Add.




  7. Enter any Name, select the API as accounts.setAccountInfo (OnBeforeSetAccountInfo), enter any Description, paste the host URL from step 5 above and click on Advanced. Then, enter the Timeout as 10000 ms, select the Fallback Policy as FailOnAnyError and click Save.




  8. In the SAP Customer Data Cloud Console, select your site and click on Schema in the left menu under Registration-as-a-Service.



  9. Set the following schema fields to be Required and select Write Access as clientModify for all of them. Then, click Save Changes.

    • profile.address

    • profile.city

    • profile.state

    • profile.zip

    • profile.country



  10. In the SAP Customer Data Cloud Console, select your site and click on Screen-Sets in the left menu under Registration-as-a-Service.


  11. Click on the Default-RegistrationLogin screen-set.



  12. Select the Registration Completion screen from the dropdown.

  13. Add four Textbox components and one Dropdown component to the SAP Customer Data Cloud Registration Completion screen and map them to the following fields.

    • profile.address

    • profile.city

    • profile.state

    • profile.zip

    • profile.country





Steps to test the solution



  1. Register an account in your SAP Customer Data Cloud site.
    Note: This can also be done by previewing the registration screen of the Default-RegistrationLogin screen-set in the SAP Customer Data Cloud console.




  2. The Registration Completion screen will be displayed. Enter an invalid address and click the Submit button. An error message will be returned.





  3. Fix the address and click the Submit button. The form should be processed successfully.





  4. View the details of the account that was registered in the Identity Access screen of the SAP Customer Data Cloud console. It can be observed that the address of the user has been cleansed.





Troubleshooting steps


Check the logs of your Kubernetes pods


To see the logs of a specific function, open the function in the Kyma console (Go to Workloads -> Functions -> cdc-extension) and you will see the logs in an expandable window at the bottom of the page.





Alternately, go to Workloads -> Pods in the Kyma Console (within the cdc namespace) to see the list of all running pods. Then, click on the three dots to the right of the running pod of the cdc-extension function, and click on Show Logs to see the logs of the pod.



Or use the following kubectl command to get the list of pods running in the cdc namespace.

kubectl get pods -n cdc

Then, to see the logs of any of the pods, use the following syntax:

kubectl logs <pod-name> -n <namespace-name>

Example:

kubectl logs cdc-extension-65khj-58b6d69cd9-l7dgs -n cdc

Conclusion


This example demonstrates how to easily extend SAP Customer Data Cloud. Care should be taken, however, to ensure that the custom business logic executes as quickly as possible so as to provide a good user experience. In general, synchronous microservices should execute within about 50 ms to about 300 ms depending on the use case. It is to be noted that SAP Customer Data Cloud Extensions currently support a maximum latency of 10,000 ms. Here are a few things you could do that could help decrease the latency of your Kyma serverless function:

  • Minimize external API calls as much as possible.

  • Parallelize external API calls that aren't dependent on each other.

  • Use OData or GraphQL APIs if possible, to get only the required data when making external API calls. For example, use the $select parameter when using OData calls to select the fields to be returned.

  • Simplify the logic of the Kyma serverless function and reduce the amount of custom code as much as possible.

  • Cache the responses of repetitive external API calls having identical request payloads using fully managed caching solutions if possible. In this example, the SAP Customer Data Cloud Public Key, that hardly changes, has been saved using environment variables, and the API call to get the Public Key is only made if it has changed.

  • Increase the replicas (horizontal scaling) or the memory and CPU resource usage of your Kyma serverless function (vertical scaling) for more resource intensive workloads or higher load, which can be easily done in the Resources tab of the Kyma serverless function (Workloads -> Functions -> cdc-extension -> Resources -> Runtime Profile). You can also utilize the auto-scaling feature of the Kyma Runtime by setting minimum and maximum replicas.


As a next step, you could try to extend this example to implement your own custom logic or use case.

I'd like to request you to kindly provide your feedback or ask clarifying questions related to this post in the comment section below. Additionally, I'd like to invite you to submit any broader Kyma related questions in the Q&A area of the SAP BTP, Kyma runtime topic.

If the SAP BTP, Kyma runtime topic interests you, here are some other links that you may like:

Lastly, if you liked this post, I'd like to request you to kindly hit the like icon, leave a comment below or share this post.