Skip to Content
Product Information
Author's profile photo Hozumi Nakano

Migrating the Data Quality Management, microservices for location data from Neo to Cloud Foundry

In my previous blog post, I wrote about how to get started with SAP Data Quality Management, microservices for location data in SAP BTP, Cloud Foundry environment. But what if you are already using the service in the Neo environment? With more innovations implemented and new services becoming available in the Cloud Foundry environment, should you migrate the SAP Data Quality Management, microservices for location data from Neo to Cloud Foundry?

To help you make this decision, first let’s look at the current availability of the SAP Data Quality Management, microservices for location data. As of the time of writing this article, it is available in the following regions.

ID Cloud Service Provider Region
neo-eu2 SAP (Neo) Europe (Frankfurt)
cf-eu10 AWS (Cloud Foundry) Europe (Frankfurt)

Next let’s think about your business applications. Are you already implementing your applications in the Cloud Foundry environment or planning to do so by leveraging the services available there? Then why not maintain your applications and services in one environment? In such cases, it makes sense to migrate your existing subscription to Cloud Foundry. In fact, you should make the switch as soon as possible because once you have started processing in your subscription in the Neo environment, the usage information cannot be transferred to your new subscription in the Cloud Foundry environment.

Now here comes the cases where you may not be able to move to Cloud Foundry. If you are using the SAP Data Quality Management, microservices for location data within one of the pre-built SAP applications, there may be some limitations on which environment you can enable it. To determine this, you may need to evaluate which authentication methods the application supports to call the service.

The SAP Data Quality Management, microservices for location data supports two types of authentication methods: OAuth and Client Certificate. The following table shows the authentication methods that are currently supported within various SAP applications that integrate the SAP Data Quality Management, microservices for location data.

Neo Cloud Foundry
Integration OAuth Client Certificate OAuth Client Certificate

SAP Data Services

DQM Microservices

Supported Not Supported Supported Not Supported

SAP HANA smart data quality

DQMm Cleanse

Supported Not Supported Supported Not Supported

SAP Business Suite

DQM for SAP solutions

Supported (BASIS 756 or later) Supported Supported (BASIS 756 or later) Not Supported

SAP SuccessFactors Employee Central

Address Validation

Supported Planned for 2H 2022 Supported Planned for 2H 2022

SAP Cloud for Customer

Address Validation

Supported Supported Supported Not Supported

SAP Cloud for Customer

Type-Ahead

Supported Not Supported Supported Not Supported

SAP Data Intelligence

DQMm Client

Supported Not Supported Supported Not Supported

Please also see the additional SAP Notes for your applicable SAP applications.

SAP Business Suite

  • 3116756 – Use OAuth client credentials instead of x.509 to authenticate – DQM for SAP
  • 3041932 – Integration limitation between SAP Data Quality Management, version for SAP solutions and Data Quality Services hosted on Cloud Foundry

SAP Cloud for Customer

  • 3037035 – Integration limitation between SAP Cloud for Customer and Data Quality Services hosted on Cloud Foundry using client certificates

If you have all the requirements met for your application and are ready to migrate your subscription to the SAP Data Quality Management, microservices for location data to Cloud Foundry, you can now follow the steps below to perform the migration.

Setup a subaccount to enable the Data Quality Service instance

If you have not created a subaccount in the region that the SAP Data Quality Management, microservices for location data is available, you need to create one. You can then enable the Cloud Foundry, create a space, and create a Data Quality Service instance within the space in the subaccount. These steps are simple and I laid out the steps with screenshots in my previous blog post.

You cannot move your account from the Neo environment to Cloud Foundry environment, so you need a fresh setup with a new Application URL and credentials.

If you want to use the client certificate authentication, make sure to add the additional parameters as described in the documentation under the Creating a Service Instance and Creating a Service Key sections.

Migrate configurations

To migrate your configurations, you can export the configurations from your Neo subaccount and import them into the new Cloud Foundry subaccount using the Data Quality Service UI. You can refer to the documentation for additional instructions and screenshots.

Setup authentication

Authentication credentials are generated when you create a Service Key on your Data Quality Service instance.

After the service key is created, you can view the credentials and URL that are used to retrieve the access token. If you created the service instance to use the client certificate authentication, you can also view the client certificate and associated private key.

OAuth 2.0

How the OAuth client is created is different between the Neo and Cloud Foundry environments.

In Neo, an OAuth client is created with a subscription to the Data Quality Service, and users can specify their own OAuth credentials.

In Cloud Foundry, OAuth credentials are automatically generated when you create a service key on the Data Quality Service instance.

An OAuth access token is generated by calling the authentication URL via a POST method call. You can refer to the documentation on how to retrieve the access token.

When you retrieve the access token in Cloud Foundry, you may notice that the token is much longer, just under 2000 characters, than the token you retrieved on your Neo instance. This is something you may want to be aware if you are integrating the authentication settings within your own application so that the interface will not limit the character length.

Client Certificate

How the client certificate is generated and received is different between the Neo and Cloud Foundry environments.

In Neo, a certificate is generated by the application that calls the Data Quality Service endpoints. The certificate is then imported into the subaccount subscribed to the Data Quality Service.

In Cloud Foundry, a certificate is generated when you create a service key on the Data Quality Service instance. The certificate is then imported to the application that calls the Data Quality Service endpoints.

The certificates in the Cloud Foundry environment are managed by the XS Advanced User Account and Authentication (XSUAA), which is the infrastructure component of Cloud Foundry. By default, the certificate is valid for 7 days, but you can configure it to extend the valid duration up to 180 days.

Summary

Migrating your SAP Data Quality Management, microservices for location data from the Neo environment to the Cloud Foundry environment can be done painlessly. With your services and applications all in one environment, you can easily manage and monitor the service usages. The SAP Data Quality Management, microservices for location data supports OAuth or Client Certificate authentication, and you can integrate it within your own application, or you can simply enable the capability within one of the SAP applications which already integrates it.

If you’d like to learn more on this topic, I encourage you to follow the SAP Data Quality Management tag to read other related blog posts.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.