Removal of operations for app providers in SaaS Provisioning Service

[bmcdonn2]

Hello all,

I'm inquiring about the potential removal of API endpoints for operations for app providers in the Saas Provisioning Service API. The specific endpoint in question being:

`POST /saas-manager/v1/application/tenants/{tenantId}/subscriptions`

We make use of this endpoint in an onboarding script that lets us onboard a new tenant from an app provider context given the tenantId of the subscribing tenant. We have been using this endpoint for many years now and the last time we successfully used this was mid-August. When I attempted to onboard a new customer today I found that accessing that endpoint now fails with an HTTP 403 error and this plaintext error message:

This API Is not supported. Please use the 'POST /saas-manager/v1/applications/{appName}/subscription' API.

For more information about the API, check the 'Subscription Operations for App Consumers' section at https://api.sap.com/api/APISaasManagerService/resource.

To learn how to get the authorization to use the API, see https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/3670474a58c24ac2b082e76cbbd9dc19.html

Based on this response, it seems we no longer have an option to subscribe tenants from an app provider context. If this is the case, can anyone point to any SAP documentation on this? The SaaS documentation doesn't have a What's New section so it's difficult to determine if a deprecation announcement was ever made. Similarly, the API documentation linked at the top of this question does not indicate that the endpoint has been removed. It would be highly disappointing for SAP to remove such a key endpoint without notifying developers in some way so I'm certain it must be my mistake.

In any case, the advice of the error response suggests to use the 'POST /saas-manager/v1/applications/{appName}/subscription' instead which seems reasonable enough. The issue here is a matter of retrieving a proper token though. The error response provides a link to authorization documentation which suggests using the SAP Cloud Management service. The instructions show you how to create an instance and retrieve a token using the service key but there's no mention of how to do this within the context of a consumer subaccount that would like to subscribe to the app.

The pattern we follow in terms of delivering apps is to have a single provider subaccount with CF enabled and multiple consumer subaccounts without CF enabled. This is fine because the consumer subaccount does not need any services of their own, just the ability to subscribe to the app deployed in the provider account. Now there are a few services which can be instantiated within these non-CF consumer accounts but the SAP Cloud Management service is not one of those services. So this is where I am stuck on how to proceed, it is not clear how to access the `POST /saas-manager/v1/applications/appName/subscription` from an app consumer context.

Any guidance on how to subscribe consumer subaccounts given the removal of the app provider endpoints is greatly appreciated.

Thanks,

Brian

[gregorw]

Have you already reached out to SAP Support? If not I think you should do so to get an official statement here.

[bmcdonn2]

gregorw I'll file an incident and let you know when I hear back in a few weeks🥲

[bmcdonn2]

gregorw I finally got a response from SAP on the removal. It seems the API was removed due to security concerns which is about what I'd expect. Still incredibly disappointing that SAP never marked the endpoint as deprecated to allow consumers of the API some time to react when it was eventually removed.

Additionally, alperdedeoglu has provided a viable workaround, even if it requires coordinating even more services an API calls. Given all this, I think the question of how to create a subscription from a provider context is solved. While it is not the most intuitive or simple approach, hopefully anyone that runs into similar issues will be able to find this question to help solve their problem.

It would be nice if SAP provided a simpler alternative some day though, I guess I can dream 🙂

[gregorw]

Hi Brian,

I hope you still have the incident open with SAP. Please ask them if they followed the API Deprecation Policy - Recommendations. Also it would be good too lear if there is any public announcement or SAP Note about this change.

Best Regards
Gregor

[enryuu]

Greetings,

I wanted to add to this post as we are having the same issue and scenario.

The thing to add is that the required functionality exists in the BTP CLI.

Why is it supported in the BTP CLI that allows this behavior but not in the SaaS Provisioning API?

Under the hood it is nothing but HTTP Calls with the proper authentication,

Kind reagrds,

Stephan Provis

[alperdedeoglu · Accepted solution]

To be able to get the token in subaccount context, you need a CIS-local Instance and binding in tenant subaccount, since it has the relevant scopes for it. Please check the official documentation of Cloud Management Service.

Good news are, you do not need a CF Runtime on tenant subaccount to create a CIS Service instance and binding with local plan, you just need to add relevant entitlement, and you can create a CIS Service Instance in tenant subaccount from provider subaccount with the help of CIS-Central Instance.

Following approach could help for your requirement:

1. Create a CIS instance with plan Central in your provider subaccount.
2. Create a Service Management Binding in tenant subaccount using Cloud Management Service - Central plan on provider subaccount with the help of the Accounts API, subaccount operations section. ( If your SaaS app is running on CF Runtime, you need to get the token with password grant type with an admin user, for CF Runtime, client credentials grant type is not available yet. )
3. In the response of step 3 you will get a service management binding so you can create a Cloud Management Service Instance with Local plan in the tenant subaccount using the Service Manager API, service instances section. Use following body:

 {
  "name": "CIS-LOCAL-INSTANCE",
  "service_offering_name": "cis",
  "service_plan_name": "local",
  "parameters": {"grantType": "clientCredentials"}
}

Please note that we have given parameters property as well since by default all cis instances accepts only password grant type. With this parameters you will be able to create a service instance which accepts client credentials grant type. Here is the relevant documentation section.

5. To be able to interact with Cloud Management Service Instance with Local plan via using client credentials, you need to create a service binding again with the help of Service Manager API, service bindings section.

6. Since you have the Service Binding credentials of Cloud Management Service Instance with Local plan, you can get the token with local plan credentials and with that token you can subscribe to any application or unsubscribe from any application from your tenant subaccount.

Let me know if this helps,

Best

[bmcdonn2 · Accepted solution]

Alper,

Thank you for the guidance on this, I was able to subscribe the app using the method you described but it did require an additional step which was to add the entitlement for "cis" to the tenant subaccount as it is not present by default. In my test I added the entitlement by hand but it does appear there is an API for this: Entitlements Service.

It is somewhat disappointing that a single call from a provider context has been replaced by so many additional calls, each of which could fail:

1. Create service management binding
2. Update entitlements for tenant subaccount
3. Create Cloud Management Service Instance
4. Create Cloud Management Service Instance binding
5. Retrieve Token for Cloud Management Service Instance

(And there could be even more calls to retrieve instance, binding and app ids).

This also does not clarify why support for the original endpoint was removed or why it is still present in the API documentation.

I will keep the question open until you can provide some insight on these remaining points.

Thanks,

Brian

[alperdedeoglu · Accepted solution]

Hi Brian,

Glad that workaround from me worked for you.
For entitlements, you can create a directory for your consumer subaccounts and assign that CIS-Local entitlement to that directory.
This would be helpful since any subaccount will created under the consumer subaccounts directory will automatically have that entitlement, no API call required.

To be honest, I have no clue why that API endpoint is deprecated. But there must be a good reason behind it.
Please share also the response you get from the official channel here.

Thanks,
Alper

[bmcdonn2 · Accepted solution]

Alper,

Thank you for the suggestion on using directories to allow for a shared set of entitlements across consumer subaccounts. This leads to another question though: what is the best way to find the directory guid that is needed to make the necessary association during consumer subaccount creation? The existing endpoints for directories do not include an open GET endpoint to list directories for a given global account meaning there is no way to look-up the guid programmatically using an identifier like directory name.

Is the only option here to directly input the directory guid via some input or hardcoding? If so, the option to directly make the entitlement assignment via the entitlements endpoint may actually be the preferable option given that it allows for a more dynamic script that could be used across different deployment environments.

I hope I'm just missing something here with regards to locating the directory guid via API so I appreciate any insight you can provide on this.

Thanks,

Brian

[alperdedeoglu · Accepted solution]

Brian,
You can get all of the directories with the help of Accounts Service Global Account Operations section.
If you call the /accounts/v1/globalAccounts?expand=true (with query parameter expand) you will see that you will receive all the directories under that global account in children array of the response.

You can find your directory from there with searching in that array and get the guid, then use that guid again for creating a subaccount.

Thanks

Alper

[bmcdonn2 · Accepted solution]

Alper,

Ah yes, I see it now. In terms of overall API calls it basically comes down to loading the directory guid via that call or assigning the entitlement directly.

In either case, I think what I've settled on is the following flow for consumer subaccount creation and subscription:

1. Retrieve cis central token
2. Create consumer subaccount using (1)
3. Create service management binding (1,2)
4. Retrieve token using service management binding (3)
5. Add cis local entitlement to consumer subaccount (1,2)
6. Create cis local service instance (4)
7. Create cis local service binding (4)
8. Retrieve cis local token (7)
9. Retrieve saas manager token
10. Locate saas app guid (9)
11. Subscribe to app (8,10)

(Numbers in parens indicate usage of values from a previous step).

So overall I need 7 additional calls compared to the old process described below

1. Retrieve cis central token
2. Create consumer subaccount (1)
3. Retrieve saas manager token
4. Subscribe to app (2,3)

I surely hope SAP will reconsider re-adding support for the subscription from the provider context as this is a significant amount of additional overhead.

Having said all of that, I really do appreciate all the help you've provided here. I don't know if I would have ever figured this out given the existing documentation.

Thanks,

Brian