Is SAP Business Technology Platform Ready for Developing Industry Cloud SaaS Applications?
* Updated section “Tenant-aware Services for Resource Sharing” on 25 June 2022 to remove the reference to Identity Authentication Service as this is no longer applicable.
* Updated section “Frictionless Onboarding of Customer Subscriptions” on 25 June 2022 to correct the understanding of the SAP Help documentation BTP API region limitations.
* Updated section “A Viable Commercial Model” on 20 April 2022.
SAP Business Technology Platform (BTP) is at the core of SAP’s Intelligent Enterprise strategy, with SAP encouraging partners to develop public cloud SaaS solutions for Industry Cloud on BTP, to solve business problems that are not addressed by SAP’s core product offerings. While SAP Industry Cloud has the potential to create significant opportunities for SAP partners and customers, the question I’d like to pose is whether in fact SAP BTP is mature enough to support this?
Architecture of BTP SaaS Applications
Industry Cloud solutions should address common business problems for one or more industries. It therefore makes sense to build these as multi-tenant applications based on the recommended Producer/Consumer approach as documented in Developing Multitenant Applications in the Cloud Foundry Environment. The benefits of this approach are:
- Customers subscribe to these applications via consumer subaccounts in the partner’s global account for their SaaS products. This means that customers do not need to purchase and manage their own BTP environment. Instead they execute all functions of the solution via the SaaS application UI.
- Resources (such as HANA Cloud) for example are provisioned only in the provider subaccount and shared across multiple tenants, making the solution more cost effective, instead of provisioning individual single-tenant resources.
- It is easier to integrate the solutions deployed on BTP with SAP on-premise and cloud applications using features such as Cloud Connector and System Registration.
I have come across very few SAP partners who have successfully implemented a SaaS product based on the producer/consumer architecture and would be interested to know your experiences and lessons learned in this area.
Requirements for Effective SaaS Application Development on BTP
To provide some context for discussion, in my view, for SAP BTP to effectively support SaaS product development, the key requirements are:
- frictionless onboarding of customer subscriptions
- tenant-aware services for resource sharing
- a viable commercial model
Let me elaborate on these requirements and the associated BTP limitations I have observed as follows:
Frictionless Onboarding of Customer Subscriptions
Ideally frictionless onboarding means that a customer should be able to go to the product website for information, select and sign up for a subscription plan, which then triggers the automatic provisioning of the customer’s account / tenant so that the SaaS product is ready-to-use. In other words, a turnkey solution. There should be no need for the customer to have visibility or access to the BTP Consumer subaccount. To enable a consistent user experience, any customer-specific consumer subaccount configuration should be facilitated either through the automated provisioning previously mentioned, or through an admin section in the UI of the the SaaS application itself, both facilitated by seamless integration through the Core Services for SAP BTP API. However, I have come across the following examples of BTP API limitations:
- After conducting a proof-of-concept, I can now confirm Dinu Pavithran’s helpful clarification in the comments below that the region dependency for the SAP BTP Accounts API mentioned in the SAP Help documentation only relates to the region of execution of the API but does not limit the region in which a subaccount can be created via the API. Therefore, the following previously stated interpretation of limitations is no longer applicable: The BTP Accounts API is only available in the Central Region (Frankfurt), which means that if the Consumer subaccount needs to be created in any region other than Central Region (Frankfurt), the only option is for the SAP partner to manually create the customer’s Consumer subaccount in the partner’s SaaS Global Account via the BTP Cockpit, which results in provisioning delays and a poor onboarding experience.
- If the SaaS solution is an extension for a cloud product such as S/4HANA Cloud for example , an integration token must be generated to Register the System, as shown in the video Extend S/4HANA Cloud: 02. Register Systems. There doesn’t appear to be an SAP BTP API to allow the integration token to be generated and returned automatically. Ideally, we would want to create a Register System function in the Admin UI of the SaaS application itself so that the customer can generate the integration token themselves to then complete the S/4HANA Cloud registration in their system. In the absence of a BTP API, the SAP partner must manually generate the integration token in the BTP Cockpit and then communicate this to the customer. Again, not an ideal user experience.
- The post Multitenant Authentication of UAA Admin APIs by Brian McDonnell illustrates another API problem for the scenario of automating the setup of default role collections and the Identity Provider. Again, a limitation that requires manual provisioning resulting in a poor onboarding experience.
Tenant-aware Services for Resource Sharing
Ideally, in a multi-tenant application resources should be shared across tenants rather than being individually provisioned for each tenant/consumer subaccount, in order to make the solution more cost effective. In a BTP context such resources are referred to as “reuse services” but the availability of such services is limited and not well documented, as described in the post Understanding Dependencies in SaaS Provisioning.
A Viable Commercial Model
Anecdotally, and by observation, the SAP BTP Services are not competitively priced compared to other cloud platforms. Some examples of services which could be more cost effective are Custom Domains, Identity Authentication Service (IAS), HANA Cloud and Integration Suite. Another good example is described in this post about Operating a multi-tenant solution on BTP CF – 1 GB Runtime = 10 Routes, which highlights the limits and cost implications of the Cloud Foundry runtime.
Furthermore, the existing revenue share based commercial model for SAP partners developing solutions on BTP is not ideal for multi-tenant SaaS applications from both an administrative overhead and financial viability perspective. It would be helpful if the option of customised commercial models could be offered, including:
- Flat Fee
- Consumption-based (PAYG)
SAP has significantly lowered the barrier to entry for partners wishing to start developing solutions on BTP by offering for the most part cost effective non-commerical licensing for test, demo and development with the PAYG agreement. You can even take advantage of non-commercial licensing by becoming a member of the SAP PartnerEdge Build Open Ecosystem program until you are ready to take up full partnership for going to market with your product. This makes it very easy for start-ups and boutique consultancies to adopt BTP for building SaaS solutions.
Unfortunately, it is not so easy when the time comes to commercialise your BTP solution. Apart from the Partner Edge Build revenue share based commercial model mentioned above, SAP offers an OEM agreement based on the CPEA (Cloud Platform Enterprise Agreement) model. While in principle this is a very good option because it allows a partner to decouple their commercial relationship with SAP from the partner’s commercial relationship with their own customers, thereby addressing the need for frictionless onboarding described above, the OEM agreement is not as flexible as it could be to encourage widespread adoption. It requires a partner to commit to a minimum value of CPEA Cloud Credits for a term of 3 years. The problem with this approach is that when launching a new product, it is not necessarily known in advance what the market uptake will be and hence what the minimum required BTP resources should be for the launch. The minimum OEM CPEA Cloud Credit commitment is relatively high in this context, meaning that initially, until the product uptake ramps up, the full Cloud Credits could go unused in any given year, and in this situation such Cloud Credits cannot be rolled over to the following year because of a “use it or lose it” policy. And you are locked in for three years.
What would be a more effective approach to make it easier for partners to commercialise their BTP SaaS applications would be to also offer partners commercial PAYG licensing for BTP with the option to transition to CPEA, in the same way as is currently offered to SAP customers. This would allow a partner to start small and then scale up with customer uptake.
In contrast, if we consider the major hyperscalers like AWS, Google and Microsoft, it seems to be so much easier to start small and scale up.
The above limitations create onboarding friction and impact adoption, which in turn discourages the use of SAP BTP as a SaaS development platform for SAP extensions and solutions. SAP BTP has a lot of potential and if it is to become the platform of choice for building SAP’s Industry Cloud, I hope SAP Product Management and their commercial team will seriously take into consideration the points raised in this post, particularly relating to the gaps in the SAP BTP APIs and Partner commercial model.
What do you think? For those of you have gone down the path of developing multi-tenant SaaS applications on BTP, I look forward to your comments about the points raised above and how you have overcome the issues identified.
Thank you for the feedback and your motivation and desire to see improvements. We are listening and working diligently to make those improvements happen.
Thanks for sharing your experience on this topic. I will flag this to Product experts.
Thank you again for the insight. I hope partners and customers are reading your observations and its helping them decide their future.
Regarding Point 1, for SAP BTP Industry Cloud solutions, it only makes sense to build and deploy these as multitenant SaaS applications. SAP's recommended architecture for such applications is to deploy these in the Partner's BTP account because of the needed Provider/Consumer subaccount structure.
Extensions/applications that need to be deployed to a customer's BTP account would be bespoke solutions specific to that customer. I would not regard such solutions to be categorised as Industry Cloud because this contradicts SAP's own definition that an Industry Cloud solution "must solve a specific business problem of one or more industries" rather than solving the problem of just one customer as is the case with a bespoke application.
nice and very informative abstract about this topic and starting the discussion.
Here are my 5 minutes of thought on this topic 😉
We are driving the SAP BTP with an ISV contract and are also thinking about reusing some services via Producer/Consumer.
In the past, we had multiple situations with issues inside the destination/connectivity service infrastructure, The issues where most times driven by SAP while doing sporadic live updates that break existing solutions and then rolling back their updates.
For this reason, i am a little bit scared with additional dependencies at the moment. More important are fallback strategies, but the come with addtional costs. Also EU20 as fallback to EU10 is only offered on Azure, but we ObjectStore services implemented with AWSSDK which shows, that not all services are really multi cloud aware and a proxy switcher on top EU10/EU20 supporting custom domains etc. is also not available.
We are thinking about using our Configuration Service (Schema Delivery, Schema Validation, UI5 Schema rendering) as the first service of this kind, that can be used by dependend SAs.This is nessessary, because ABAP is not able to validate a JSON schema, and this way, we can externalize it using a REST service and the service is able to reach the on-premise systems. Here we have a stable API that would work well for SaaS.
But we will use this internally in our UDINA BTP Platform, to share the service accross SAs. We do not have the need for Cost/Usage tracking.
If you need Usage tracking, the API Management is no more available standalone (like in NEO) and only sold as part of Integration Suite, starting with 4.000;- Euro/month.
Looking at your requirements for effective SaaS dev, this will make it hard, to find a viable commercial model for it, or you develop your own usage monitoring (I know some solutions, that gone this way to skip API Mgmt Costs).
Concerning the current status quo, i think this is a nice option for SAP offering SaaS solutions to customers, but for partners, you maybe will struggle with the underlying commercial model, because you are also in competition with other solutions running in the multi cloud universe which are maybe available with lower TCO.
Thanks for chiming in with your valuable feedback. I'm glad to see that the pain points have resonated with you and completely understand the others you have listed. The merging of API Management into Integration Suite from the prior standalone version does indeed have a significant impact on commercial viability, among other issues.
Given both the commercial viability and technical gaps in BTP, it will be interesting to see how much Industry Cloud solution development SAP Partners will undertake with the new model.
Hopefully SAP Next-Generation Partnering listens to the constructive feedback from partners and adapts the partner offerings to encourage adoption and support mutual success.
You have rightly brought the issues of using SAP BTP for SaaS application development and provisioning. We have been battling with these issues for quite some time on SAP BTP -ABAP. We are a partner and have been the early adopter of SAP BTP and developed product using steampunk for a dedicated customer. We wanted to take this to SaaS roadmap thro OEM route but apparently facing various challenges. The following points are still not clear :-
In effect, we are not able to deploy the Add-on package using multi-tenant SaaS application
I also wish that next-generation partnering listens to us constructively and support on the above issues.
Thanks for sharing your experiences in detail. Apart from the technical gaps in SAP BTP you have pointed out, I agree that there is a lack of clarity, alignment and viability for commercialisation through the OEM and new PartnerEdge Build contracts when it comes to developing SaaS applications.
It will be interesting to watch the adoption of SAP BTP by partners wishing to develop Industry Cloud SaaS solutions. Like you, I hope that continuous feedback such as the above from SAP Partners will be taken as an opportunity by SAP Next-Gen Partnering to refine the commercialisation model in a way that maintains the relevance and increases the attractiveness of SAP BTP as the platform of choice for SAP Industry Cloud compared to other PaaS platforms provided by the hyperscalers.
Taking advantage of this post/topic, do we have some example SaaS applications delivered on BTP?
I believe there are a few already in my mind, like WorkZone, Cloud ALM.. maybe more.
Technically all new SAP SaaS applications are supposed to be delivered on SAP BTP, including the ones you have mentioned. What would be more informative for this discussion is to get an idea of which partner-built SaaS applications have been deployed on BTP using the Multitenant Architecture. This metric is more relevant for understanding the progress of SAP Industry Cloud.
the apps you've listed are provided by SAP. Unfortunately SAP does not give their partners the same possibilities like subscription in existing subaccounts.
Gregor, for "subscription in existing subaccounts". Does it actually matter? For SaaS application subscription, should it just be as easy as filling a form with my email and password and credit card, then get an email confirmation with the application url to login? End users may not be interested with BTP or SAP itself at all. My 2 cents. I am just imagining the process that I have no knowledge of IT and I want to use SaaS application like Asana.com and pay monthly. Understand in SAP customers SAP customers usually are tech-savvy and have abundunt IT resources in house and the understand BTP or subaccount concept quite well.
To this point "the only option is for the SAP partner to manually create the customer’s Consumer subaccount in the partner’s SaaS Global Account via the BTP Cockpit, which results in provisioning delays and a poor onboarding experience". To reach larger audience, it might be ok for partners to invest upfront in each key regions for end users to be provisioned later on. I think the onboarding process can be quite seamless to the end user as I mentioned above, while behind the scence for partners it can be semi-auto, considering there might be some post-provisioning manual activities such as the "integration token for registering the system" mentioned in the blog. It can be fully-auto in the future if the feature is provided by SAP. Btw, the APIs are always available to be consumed with a service user in the old way of integration.
I think technically it might just be some of the limitation of the multitenant architecture of cloud foundry. In Kyma I believe it is the same. Maybe SAP can share some knowledge on how it deploys for example Work Zone for subscription across multiple regions.
Assuming if there is no more technical barriers, then comes down to the commercial model. Has SAP work it out yet?
I remember around decade ago when SAP started the "SAP Store" where partners can put on applications to "sell". It turns out to be more like a marketing website afterwards as no application will be actually plug and play, like the ones on the Apple Store.
Hope to see more "unboxing" blogs like this. Nice one and great discussion.
Completely agree with you.
We are working on SAP BTP SaaS application using ABAP Stack. Hopefully , we will share the experience once it becomes productive !
it is great to see movement in this area. As partner, BTP multi tenancy applications seem to be a good way to sell SaaS application to the clients that already have SAP systems.
Most of the limitations have already been mentioned above.
What bothers me in addition is the fact, that I can only subscribe within my global account.
Let us assume we have the following scenario:
We, as a SAP partner, developed an CAP based extension app (for SAP S/4HANA onPrem) and want to sell it as SaaS to a client that already has his own global account. He invested in processes around the BTP and might also have the cloud connector in place for data exchange. Now, he will most likely not be willing to connect his cloud connector to my global account (even if it is possible). It would be much easier if he creates a subaccount in his global account and subscribes to our application. That way he has control about the data integration, the user authentication and several other things.
For me the use case that someone wants to use my application, who has nothing to do with the BTP by himself is not the common. Personally I would not choose SAP BTP as my SaaS platform for clients who have nothing to do with SAP. There are other more convenient platforms out there.
For me, the unique selling point is the integration into the clients hybrid SAP landscape and the already established trust with SAP BTP.
Hopefully this also gets resolved in the future.
as this topic was not yet an influencing request I've filed one: Allow subscription to multitenant apps from subaccounts not part of the provider global account. Please also vote for Support for Multitenany in the Fiori Launchpad.
Can't agree more with the higher effort that is caused by this missing functionality. Especially as this is available in BTP Neo: Providing Multitenant Applications to Consumers in the Neo Environment.
thanks for submitting the request. Just voted for it.
I already voted for the Launchpad topic in October last year. Let us cross our fingers that these things will be available in the future. Whenever that might be.
I think the new blog post Consumability Across Global BTP Accounts Via Custom Service Brokers is intended to address the scenario of subscribing to "multitenant apps not part of the provider account". However, I think the service broker approach has significant limitations which make it impractical for multitentant applications. I've posted my feedback and would be interested in your perspective too.
thank you for the heads up. I share your doubts.
This is great discussion. Thanks for contributing. Please see my further comments in response to yours below.
You make a valid point about the convenience of using the Cloud Connector that is already configured in the customer's global account. Nevertheless, I think that for a truly seamless end-to-end SaaS onboarding experience, a customer should not have to be exposed to the PaaS which underlies the SaaS application, whether it be the partner's BTP account or the customer's. For a coherent user experience, all configuration should be implementable via the SaaS application UI. Furthermore, if the a customer could subscribe to a SaaS application from their own subaccount, how would the commercials and billing work, especially when there are multiple plans to choose from like "Starter", "Pro" and "Enterprise" for example. In a typical SaaS onboarding flow, the customer first signs up on the website by choosing a plan and completing the billing preference details such as credit card, invoice etc and recurrence such as monthly or annual. The completion of this initial step then triggers the provisioning of the customer's tenant. How would all this be done when subscribing from the customer's own BTP subaccount?
from my perspective it should work the exact same way. The only difference is that I need to provide the details about my subaccount where the application should be running during the onboarding. It should be a choice if the customer wants the application in his own subaccount or not.
Thank you so much for putting together this post. I see you've found a couple of pain points that I helped identify so I'm glad you could include them into this more complete collection.
In regards to IAS integration, there is another aspect to this that I'm not sure has been captured yet and that relates to the availability of an API to interact with IAS Applications.
Our multi-tenant application has been live since the summer of 2019 and the pattern we settled into for IAS was to create one IAS application for each SAP BTP subaccount. This works well because it allows us to isolate the configuration on the BTP side within the individual subaccount and on the IAS side within the application.
The issue with this approach though is that there is no API to maintain applications within IAS like there is for other objects in IAS like groups and users. This means that there is always a manual step required when setting up new tenants as somebody needs to go into IAS and manually create the IAS application. Beyond the creation itself, each application shares some common configuration such as branding, onboarding emails, etc. which means a lack of API means a higher risk of inconsistency in common elements across tenants.
The good news is that SAP has plans to address this shortcoming in a new API. The details of this are captured in a Customer Influence Improvement Request (login required): SAP IAS - Publish API to Maintain Applications . I'm not hopeful that this will be available anytime soon though, as the original improvement request was submitted in January 2021 and only confirmed in March of this year with the next update to be provided in Q3 2022.
It's possible that SAP has introduced newer, more streamlined ways of handling this since our original go-live in 2019 but it hasn't been very clear how we'd move to this newer authentication model between SAP BTP and IAS or if it'd confer any benefits. Improved automation would certainly be a reason for us to look into it though.
Thank you for keeping the conversation going. Your feedback is very timely as I have been investigating the most appropriate approach for integrating IAS with a multi-tenant application, considering whether to integrate with the Producer Subaccount or Consumer Subaccount. For the reasons you have mentioned I had landed on the Consumer Subaccount approach but not yet tested it, so it's great to have the benefit of your validation of this pattern.
It's disappointing to learn that there is no API to maintain applications within IAS. I have voted for your SAP IAS - Publish API to Maintain Applications improvement request, although I am concerned at the low priority SAP has assigned with status "Planned (Long-term)". Your statement "Being able to automate the process improves reliability of a successful onboarding and consistency across different tenants." is perfectly aligned with the philosophy of "Frictionless Onboarding of Customer Subscriptions" I have described in my post above.
I have a some questions if I may?
1) Do you get any customers asking to integrate their own IAS tenant with your multi-tenant application instead of the included IAS tenant? If so, why?
2) How do you handle the scenario where a customer asks to integrate their own corporate identity provider such as Azure Active Directory?
3) How do you manage and factor in IAS usage costs for your customers given that the BTP pricing metric is Number of Logons? This has the potential to become quite costly.
4) With respect to your comment "It's possible that SAP has introduced newer, more streamlined ways of handling this since our original go-live in 2019 but it hasn't been very clear how we'd move to this newer authentication model between SAP BTP and IAS or if it'd confer any benefits.", if you haven't already done so, it may be worth looking into the Identity Provider Management and Security Settings APIs of the SAP Authorization and Trust Management Service API Package as detailed in the Access Administration Using APIs of the SAP Authorization and Trust Management Service help documentation.
5) Is your application listed on the SAP Store?
There is a blog (Cloud Integration: Enable SAP IAS (Identity Authentication Service) as Custom IdP for Basic Inbound Authentication in Cloud Foundry Environment) outlining configuration of IAS as default IdP of a subaccount. This method creates an application in IAS in the process.
I can confirm that during a recent end-to-end proof-of-concept, it was possible to fully automate the configuration of IAS as the default IdP of a subaccount as well as creating the XSUAA application in IAS, using the Identity Provider Management API of the SAP Authorisation and Trust Management Service package. However, the IAS API still needs to be enhanced to allow maintenance of the IAS application to configure elements such as branding and onboarding email templates as per Brian's comments above and the improvement request for SAP IAS - Publish API to Maintain Applications.
Thanks for clarifying that.
In the context of configuring IDP for a partner application, don't the customers prefer to connect all applications to their own IAS tenant like in Scenarios 1-4 in Single Sign-on: SAP Reference Architecture for Identity Access Management rather than have a separate user store? What is your experience?
An additional limitation of the blog you posted is the requirement that CF be enabled to allow access to the xsuaa apiaccess service plan.
This is not consistent with the subaccount model we've adopted where there is a single CF-enabled provider account and multiple non-CF-enabled subscriber accounts. The fact that the subscriber subaccounts do not have CF-enabled means that we cannot access that service plan and therefore cannot even automate the application creation, much less the customization of branding or onboarding emails.
These limitations are detailed in this question I asked in March 2021: Multitenant Authentication of UAA Admin APIs
In terms of customer preferences, our application most closely resembles scenario 2 where we have a lightweight cloud application which means the majority of our customers are satisfied with a separate user store to access this application. Despite the shortcomings in application API availability to maintain this for customers, it is still much simpler than the other scenarios where integration to distinct corporate IdPs is required.
The "scenario 2 - Pure cloud landscape with single Identity Authentication tenant" in Single Sign-on: SAP Reference Architecture for Identity Access Management does not envisage an independent user stores. It envisages that all applications of a customer share a common IAS. It is different from Scenario 1, only in that it is not connected to an on premise corporate IDP. When every application comes with an own user store and stay disconnected, we are moving back into the territory of high maintenance of user management, beyond the initial setup, is it not.
Would you have insights on why customers prefer that your application has its own user store and not use the IAS they already have for authentication? Is it something customers prefer during a "trial phase" as mentioned in the recommendation for scenario 2.
What did the other customers, those who did not opt for independent user store, choose to do for identity management?
To be clear, the application I work on has been live in production with customers since 2019 which predates the post you shared by nearly 2 years so if our actual usage of IAS in practice does not directly map to the scenarios outlined in that post, that's part of the reason.
Additionally, the resources that were available to guide our usage of IAS and SAP BTP were much more limited back in 2019 so what we use today may not match modern practice. Migrating to a more modern approach would of course be desirable but with an existing customer base, any type of migration would introduce a risk of disrupting our service which means we'd only carry one out if there were clear advantages. So far it is not clear what we'd gain by updating our model as the limitations we've identified with IAS are still present (the lack of an API to maintain non-CF subaccount trust and the lack of an API to maintain IAS applications).
As for customer preference, it is more the fact that we provide a standard option of the user store maintained via IAS and the fact that the vast majority of customers have found this to be satisfactory to a point where we've had very few requests to integrate a customer provided user store. I think given the uniquity of SaaS in general has made customers fairly tolerant of needing to have separate users to access our application.
Thanks for sharing your experience.
yesterday I've requested a tenant of SAP Cloud ALM for my BTP Free Tier. That is done via SAP Cloud ALM Access Management. This triggers a completely seamless deployment of a new Subaccount in the SAP Cloud ALM Global Account of SAP. There 3 Apps are subscribed (Cloud Transport Management, Cloud Integration Automation Service and SAP Cloud ALM) reachable via their respective UIs. Would be great if SAP could share if this approach can also be achieved by Customers and Partners.
Your comment triggered me to launch SAP Cloud ALM Access Management where I saw that my SAP Partner account was entitled to SAP Cloud ALM, so I submitted a request. Although requested via my SAP Partner account, the automatically provisioned apps (Cloud Transport Management, Cloud Integration Automation Service and SAP Cloud ALM) were all still assigned to the SAP Cloud ALM Global Account as shown below. Is this what you are expecting?
Hi Gregor, isnt that the "normal" behaviour available to customers and partners? if I host (run) an application X on global account GLOB in subaccount RUN, I can create a different subaccount CUST for my customer and give them access to it, where the application X is subscribed (subscription between CUST and RUN on same global account GLOB)
or am I missing something?
That is correct. But when you experience the onboarding for SAP Cloud ALM there is much more to it. With the click of a button the following is done:
All this steps must currently implemented by Customers and Partners or done manually.
In my case, all of the above SAP Cloud ALM onboarding steps occurred automatically as expected at the click of a button, in my Partner account, without the need for any manual steps.
Ah, I see. Yes, this is a huge improvement. Subscribed myself too, now. it even picks same IAS tenant I was logged in from, creates an admin service user there, and wires up the new subscription tenant with it. no additional manual configuration steps required from the provider side (which is the SAP Cloud ALM global account)
Another Topic for the list of things that are hard to handle in the Cloud:
Transport of customizing
I've posted the question:
Use SAP Cloud Transport Management to transport customizing of a CAP application?
on this topic. Unfortunately no replies till now. Would be great to get some advise from SAP here.
I believe this is incorrect understanding. The documentation only means that irrespective of where (region of the subaccount) you create a service instance for cis/central (service/plan), it will point to the service hosted in eu10. You can try creating a service instance with this plan and look at the credentials. The field account_url will point to a domain eu10. The field url (or token endpoint) will point to eu10 and the subdomain for this will be your global account. Account service operates on your global account.
Hope this clarifies what is stated in the documentation.
Tutorial from TechEd202 (DEV360) is old but still usable if you make minor adjustments.
Thanks for the clarification. After recent testing of the SAP BTP Accounts API I also realised that, as you have pointed out, the interpretation of the documentation was indeed a misunderstanding. I have accordingly updated the relevant section of this blog post above.
Some questions about the command line interface (CLI) option you have mentioned: if a command line script is developed for automating the creation of consumer subaccounts then:
I was only pointing out the tutorial and what one might have trouble with using it today.
I see that there is a sample of deploying an application using CLI tools using docker. Automate the setup of your SAP BTP account with the SAP BTP CLI and other CLI tools.. I have not tried it. I suppose one can use the same approach in CF and run it as a CF task too.
I would say that such a script can be triggered from your order processing system. Subscription of the application would be done by the script. You can get to the level of Cloud ALM subscription mentioned in another comment with that. The partners I know of, run such scripts from their workstation after they receive an order. They do not get so many orders to go beyond that yet.
Registering the System appears to give full privileges to any subaccount owner in the subaccount to create any communication scenario in S/4HANA by creating a service instance and connect to S/4HANA system using it. In you experience would customers give that access to a 3rd party? So, beyond the lack of API for automation, is the scenario realistic? What is your experience?
Please see my comments below in response to your questions:
In the context of a multitenant BTP SaaS application, the customer is not giving carte blanche access to a 3rd party to create any communication scenario in S/4HANA. The System Registration approach simply allows the 3rd party BTP SaaS application to present a self-service UI to the customer end user for selecting the business objects (APIs) they want to activate for integration so that the automated process can then be triggered in the background.
You make a valid point about this process technically giving full privileges to create any communication scenario. However, I would suggest that this is an opportunity for SAP to improve the automated configuration process to provide more granular security capability in the S/4HANA system so that the customer can control which communication scenarios are allowed to be automatically created by a "registered system" in BTP, rather than compromising the user experience of the BTP SaaS application through manual processes.
Not only is this scenario a realistic one, it is the SAP recommended approach INSTEAD of using the manual approach:
Therefore, when building a SaaS application on BTP using the SAP recommended Multitenant Architecture, there is no choice but to create the S/4HANA Cloud Extensibility Service instance in the consumer subaccount which is in the global account of the 3rd party. BTP does not support subscribing to the Provider subaccount application of the 3rd party global account from a Consumer subaccount within the customer's global account. Frankly, this would defeat the purpose of a multitenant SaaS application. An SAP partner/3rd party BTP multitenant SaaS application should NOT require the customer to also have their own BTP account just to subscribe to the SaaS application. This creates an unnecessary dependency and overhead. The SaaS application should be loosely coupled with the customer's backend systems that it integrates with.
Even the Architecture Principles of the SAP Architecture and Development Guide for Industry Solutions recommends automation of processes:
Now let's consider the manual configuration approach is implemented in the SaaS application to mitigate the concern you have raised that "Registering the System appears to give full privileges to any subaccount owner in the subaccount to create any communication scenario in S/4HANA". Let's say the customer needed to activate 100 APIs for integration with the SaaS application. The customer would need to manually create 100 communication scenarios in their SAP S/4HANA system and the SaaS application would need to provide a UI for the customer to then also manually create 100 corresponding destinations for the SaaS application to consume the APIs. Do you think this is an ideal user experience?
I am an advocate of consumer grade user experience with frictionless onboarding for SaaS applications. Automation is a very important for achieving this.
Gregor Wolf also provides a very good example of the importance of a seamless, automated user experience in his comment about the SAP Cloud ALM onboarding process above.
I look forward to your further feedback.
I fully agree with you that manual configuration is not giving a good onboarding experience.
I misread your statement. I interpreted it as "api missing for integration token request". My enquiry was limited to this specific functionality as it is today. You point out that you are advocating for a possibility for much more smooth onboarding experience.
Thanks for your clarification.
Actually, your interpretation was correct. I was suggesting that the onboarding process and user experience could be made more seamless from the BTP SaaS application if SAP offered a BTP API to generate and return the token needed for the System Registration process. At the moment, the token can only be generated manually via the BTP Cockpit.
The way I look at it, dependencies are declared to give the provider convenient access to the subscriber tenant's corresponding services. So when you declare dependency to destination service, the provider can use the credentials for its destination service instance to access subscriber's destination service tenant. So these are only for services your provider service binds to. One can always configure destinations to reach any of the services, it is not so convenient for key management, but works. One can configure matching destinations in each subscriber tenant, and have access to subscriber's services. Have you tried this approach?
When you say you miss "Identity Authentication Service" in the list of services that you can declare dependency to, what do you mean? Are you not using xsuaa/application plan for authentication? Are you binding to an instance of identity/application plan?
Thanks for your suggestions. Please see below for my comments.
Thanks for the clarification. Would you have a list of services your needed to access as dependencies. It is possible to setup destination entries (with automation) at subaccount level (not new destination instances) for services from the subscriber you want to access. Have you have tried that?
Thanks for the suggestion. Yes, we have been able to successfully automate creation of destination entries via the Cloud Foundry Destination Service API.
in regards to the original question: Is BTP ready for SaaS applications, I spotted another issue:
When you setup your BTP global account based on directories and would like to give one project team / one SaaS application one directory to create subaccounts for the SaaS subscriptions, as of today, you cannot create subaccounts in the directory using the API if you are not a global account admin. In the Cockpit (UI) it works, but the API does not.
A workaround would be to use the btp CLI, but when we talk about real SaaS applications, this needs to be possible with direct API's and not with the integration of OS level CLI's.
I have created n improvement request to address this topic: https://influence.sap.com/sap/ino/#/idea/285707.
Thanks for continuing to share your experiences Eik. This is certainly valuable input for communicating BTP improvement opportunities to SAP.
Dinu PAVITHRAN Mustafa Bensan Gregor Wolf and other experts,
We are startups and not SAP partners so far. We would like to use SAP BTP automation service with PAYG license and develop BOTs/ our solutions on top of it. We would like to offer only those BOTs to our customers and so that it is not required to them to buy BTP license (being big cost barrier). Is it possible to do so without being partner?
If your company is not already an SAP Partner, you can start your partner journey with SAP by applying for SAP PartnerEdge Open Ecosystem - Build program. You can make use of BTP subscription for Test, Demo and Development (aka TDD) with Pay-As-You-Go for SAP BTP for Partners to develop your applications. When your solution is ready for market, you can upgrade your partnership to SAP PartnerEdge Build and deliver it to multiple customers. Commercial options, these are different from TDD mentioned above, are available to package SAP technology with your solution, like when you are delivering a service on subscription. You may also deliver your solution to run on SAP Technology subscribed by the customer. The benefits you receive along this journey is captured in one slide here.