Migrating SAP 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 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 service. As of the time of writing this article, it is available in the following regions.

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 migrate to Cloud Foundry. If you are using the 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 service supports two types of authentication methods: OAuth 2.0 Authorization with client credentials and Client Certificate authentication. The following table shows the authentication methods using OAuth 2.0 Client that are currently supported within various SAP applications that integrate the microservices for location data.

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 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 Services instance

If you have not created a subaccount in the region that the 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 Services 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 Services 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 Services 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 Services, 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 Services 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 Services endpoints. The certificate is then imported into the subaccount subscribed to the Data Quality Services.

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

The certificates in the Cloud Foundry environment are managed by the SAP Authorization and Trust Management service (alternatively known as XSUAA). By default, the certificate is valid for 7 days, but you can specify the parameters to extend the validity.

Summary

Migrating your 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 service supports OAuth 2.0 authorization 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.