Automating the setup of your SAP BTP account with btp-setup-automator

[Rui-Nogueira]

With the newly available GitHub repository for the btp-setup-automator we are providing the community with a script to automate the setup of an SAP Business Technology Platform (SAP BTP) account and to learn how this is done with the various command line interfaces and tools.

architectural overview btp-setup-automator

This includes:

• Setup of your SAP BTP account


• Entitlement of services


• Subscription of applications and creation of service instances with api keys


• Addition of administrator users to global account and subaccounts


• Setup of roles and role collections, assignment of roles collections to users


• Deployment of complete applications


• Unrolling created setup

In essence it's all about making it easier to get developers quickly onboard on SAP BTP and use services on SAP BTP without having to know too much of the terminology and how to use the SAP BTP Cockpit.

All in containers

The tooling for the btp-setup-automator is running within a Docker container and the repository provides all what you need. Why Docker? We want to ensure that you can focus on getting your work done on the SAP BTP account without having to worry whether you have the right tools in the right release for the right operating system in place.

Sounds already good, but there is a cherry on top: we provide you as well the pre-built Docker image in our GitHub account at https://github.com/SAP-samples/btp-setup-automator/pkgs/container/btp-setup-automator as a package.

For further reading on improving the developer experience through containers, see this three-part blog post series from my colleague dj.adams.sap: Boosting tutorial UX with dev containers.

CLIs: Sitting (not standing) on the shoulders of giants

The tool is there to prove how much you can already automate today with the various command line interfaces (CLIs) on SAP BTP. The btp-setup-automator uses:

• SAP btp CLI


• Cloud Foundry CLI


• The Cloud Foundry plugin for MTA files


• kubectl (including the kubelogin extension)


• helm


• krew (maybe you want some more kubectl extensions 😊)

Maybe the tool inspires you to create your own tool to automate the setup of your SAP BTP account. And it is so easy and powerful that you don’t even have to stand on the shoulders of giants but can rather sit very relaxed on their shoulders 😊.

Open source

The repository is available under the Apache 2.0 license. It is written in Python and the log files produced by the tool show you which commands you need to use to carry out certain tasks in, for example, the SAP btp CLI to entitle a subaccount to use a service, or how you can create a service instance in your subaccount using the Cloud Foundry CLI.



You can learn through the log files what you need to do in which sequence.

And if you feel like something should be done differently in the code: fork the GitHub repo of btp-setup-automator and send a pull request to the repository or adapt the code to your needs.

 

The use cases

You might already know the use cases for the SAP Business Technology Platform. The btp-setup-automator wants to make it easier for you to set up the SAP BTP part in your SAP BTP account.
As a user of the btp-setup-automator you focus on a specific use case via a file with a defined JSON structure. You can find several examples in the repository and - of course - you can create your own use case files as well.
These configuration files tell the tool which services and service plans are needed.

With the release today we are providing you configurations for the following use cases:

• Deploy full-stack CAP application on SAP Launchpad – on SAP BTP Trial accounts as well as on productive pay-per-use SAP BTP accounts (based on respective tutorial on developers.sap.com)


• Initial setup for SAP Task Center (based on SAP Discovery Center mission)


• Extend SAP S/4HANA Business Processes on SAP BTP by leveraging DevOps (based on a specific GitHub repo for this use case)


• Setup of ABAP Steampunk instance


• Setup of Kyma environments


• Getting started

Just follow the instructions on the GitHub repository for btp-setup-automator and see how easy it is to setup your SAP BTP account with services and subscriptions.

If you hit issues please raise an issue in the repo, we are happy to fix and improve the tool.

Share your experience

To be straight: this tool is not the silver bullet for all possible tasks around SAP BTP. It is focusing on the setup of an SAP BTP account and the creation of service instances and app subscriptions. But even more importantly it wants to inspire you on how easy it is to integrate SAP BTP within your development processes.

Maybe you even start your own GitHub project around SAP BTP.

Share your experience with us here in the SAP Community or inside the "Discussions" tab of the project. Let us know your thoughts on how you are using the btp-setup-automator for your development with SAP BTP.

Best,
Rui for the contributors of the #btp-setup-automator

[former_member205561]

BTP command line is really useful, we use it in similar case to add sub-accounts, subscriptions, role collections and assign users groups to them

[Wallace]

Perhaps a small clarification question...

BTP Account verses Global Account?  Equal/same, different?  While not optimal, perhaps, it is possible to have multiple global accounts active within a single SAP customer?

I see both referenced in the first part of the post.

 

[Rui-Nogueira]

In general a customer has one global account on SAP BTP. Here's the official documentation around this topic: https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/8ed4a705efa0431b910056c0acdbf377.html...

Best,
Rui

[MustafaBensan]

Hi Rui,

Your post and samples are exactly what was needed!  As for "it wants to inspire you", it is certainly a motivation to extend this for the use case of the provisioning and onboarding tasks for multi-tenant SaaS applications.  It would be very useful if the SAP BTP CLI and API could also support Registering a System in future, to allow even further automation.

Regards,

Mustafa.

[MustafaBensan]

Does this mean all three BTP commercial models can now be combined in a single global account?

• CPEA Cloud Credits


• CPEA PAYG


• Subscription

 

[Rui-Nogueira]

No :-). That's why I've said "in general".

If you run the tool, you'll notice that you get in the "metada_log.json" file some information about the type of account you use. That information is bound to the global account.

[Rui-Nogueira]

Thanks a lot Mustafa.

Please go ahead and add a feature request to the repository at https://github.com/SAP-samples/btp-setup-automator/issues/new/choose

Or maybe you even want to get your hands dirty and create a pull request for that feature?

Best,

Rui

[Marco_Dorn]

Hello wallace.henry

Let me add to what Rui wrote: One customer can have several Global Accounts indeed. When you look at the link Rui shared, it starts with: "A global account is the realization of a contract you made with SAP." If there are several contracts, there can be multiple Global Account. Only if  these additional contracts are all upsells of the initial contract, there would be only one subscription based Global Account.

Furthermore, to clarify on mbensan's comment: Since Q1 2021, it's as well possible to have a subscription-based Global Account merged with a consumption-based one (CPEA or PayG). It's not possible to have CPEA+PayG as this won't make sense anyway. If there is over consumption in a CPEA contract, the used credits on top are invoiced.

I hope this clarifies further.

Best regards,
Marco

[MustafaBensan]

Hi Marco,

Thanks for the further commentary.  As I understand it, if a customer starts with a PAYG based global account, they can in future seamlessly transition the same global account to a CPEA model without any rework or migration of the existing deployed applications.  Is that right?

Regards,

Mustafa.

[Marco_Dorn]

Hello Mustafa,

The move from PayG to CPEA is an even easier one as this is only a contractual change from "no financial commitment" to "committed credits". Therefore, the technical account gets only an updated "commercialModel" flag, but nothing else changes.

Best regards,
Marco

[TomD]

Seems like a very useful way to abstract away the CLI details and specifics in favour of a set of JSON service descriptors. The biggest potential I'd see however would be to automatically create such a use case file as a blueprint from an established subaccount. Not sure if the APIs would even support that though? Last I checked a lot of services and instances didn't allow retrieving their configuration.

[Rui-Nogueira]

That's a cool idea and exactly the reason why I've started this open source project. Did you already give the tool a try? You could as well have a look into the SAP btp CLI and play with it a bit. When using the btp-setup-automator you get as a side-effect all the commands that the script uses. This includes various calls of the SAP btp CLI.

My personal favorite command for the SAP btp CLI is this one:

btp --format json list accounts/entitlement --global-account "<your global account subdomain>"

The json that you get back provides you with a huge amount of data and if you combine that with additional commands (see the official documentation), you suddenly are seeing yourself creating your own (open source) project that is using those commands.

In any case, you should add your feature request into the GitHub repo at at https://github.com/SAP-samples/btp-setup-automator/issues/new/choose . We can take it from there and see, whether someone (or even you) is willing to pick-up the task and integrate it into the btp-setup-automator.

I personally like the idea very much. Thanks a lot for your input!

Best,
Rui

[gleiss]

Hi colleagues,

is there a way to execute BTP CLI commands from within a Jenkins pipeline? If I understand it correctly, one has to install the BTP CLI client before being able to execute commands. Is there something like a plugin or a docker image that could be used?

Thanks and best regards,
Eric

[yevgen_trukhin]

Hi Eric, in the past I had my own image with btp cli that I maintained and executed within Jenkins, now you can use the image "ghcr.io/sap-samples/btp-setup-automator:main" in your pipeline.

 

Br Yevgen

 

 

[JoeGoerlich]

Hi marco.dorn,

I'm wondering if there is something like a CCC functionality for Global Accounts?

How can I get knowledge of existing Global Accounts in my company?

How can I keep track if a contract for a Global Account with my desired commercial models already exists within a different department and whos the contact far that?

Do we need some kind of CASB to get visibility of SAP BTP usage?

 

Best regards,

Johannes

[Rui-Nogueira]

Hi Johannes, not sure what CCC or CASB is. Maybe marco.dorn knows more here.

As far as I know there is currently no means to find out via the BTP CLI which user has access to which SAP BTP global account. And as the btp-setup-automator is using the various CLIs, we can't provide that information through the btp-setup-automator.

Best,
Rui

[Marco_Dorn]

Hello johannes.goerlich,

Same here, I am not sure what you mean by CCC-functionality.

From what I know, it's not possible to get the information about all Global Accounts for an account via the CLI or the BTP cockpit.

Maybe this is possible via SAPforMe (documentation)? oguzhan.genis, can you help out with more details?

Best regards,
Marco

[JoeGoerlich]

thank you both for picking this up.

@marco.dorn 

With SAP BTP, we fear to run into the same issues as we had in the past for example with AWS or Azure where each department could order a separate account by entering a credit card number ending in several not-governed accounts, no proper cost optimization and unstructured service usage.

CCC is the abbreviation for the SAP Corporate Group function of the "on-prem world". Quote from the documenation "A CCC group allows more than one account (customer number) to be joined together in a Corporate Group hierarchy, so that S-Users with CCC Level authorizations, can manage the accounts. Features such as managing installations, systems, license keys, incidents, and S-Users, are enabled with the proper CCC level authorizations."

AWS introduced a similar concept with the "AWS Organizations".

A CASB solution could be used to scan the network traffic in order to find out which cloud solutions are used from the company's network. Or even to prevent users from ordering SaaS solutions by circumventing the organisational requirements or processes.

Best regards,

Johannes

[hschaefer123]

Hi Ruy,

thanks for the informative blog.

I just gave it a try but also ran into some issues.One is that all created SA´CF Environments are prefixed with "cloudfoundry-".

It also seems, that Directories are currently not supported like in
https://github.com/SAP-samples/cp-cli-automate-operations

Also the former SAP tutorial is currently no more available, so here is the git link.

Doing the same with BTP CLI works without issue.

I would like to have full control over all namings to fullfill my own nameschema.

Anyhow, the tool was also not creating the users/roles for me.

Anyhow, if this is fixed/available in the future, this nicely automates creating usage scenarios (even for workshops) to quickly rollout SAs.

Best regards
Holger

[Rui-Nogueira]

Hi Holger,

your message seems to be missing some links and other information like e.g the name of the use case you've tried.

Ideally, you'd create an issue on the repo and the community will help and support bug fixes.
Here's the link to it: https://github.com/SAP-samples/btp-setup-automator/issues/new/choose

Did you try adding the parameter "org" to your parameters.json file as a string?

Best,

Rui

[TomD]

Hi Rui,

Still haven't really had much chance to dive into this again and I must admit I'd be unlikely to dive into the actual source code. 😉 But that command and in particular the --format option I hadn't realised existed are very interesting though. Will likely make our idea to look at RPA-based automation much more viable.

Most of our CF use cases are relatively simple and usually stick with the more basic (SAP) services as our more exciting projects often have an established hyperscaler setup we'd be loathe to touch. But this does look promising for things like tier and transport management or deploying of packaged solutions that are getting more common and often prove cumbersome.

Appreciate your reply here and in the other comments. Take care!

Kind regards,
Tom

[hschaefer123]

Hi Ruy,

sorry, that some infos were missing and has been removed while editing.

Here again the missing stuff:

1. ORG Issue
   I just did a retest and yes, i am using option parameters option
   "org": "udina-customer-namespace-test"
   and the created Cloud Foundry ORG Name will be
   "cloudfoundry-udina-customer-namespace-test"
   Maybe issue is only if leaving orgid, to create a new account env with given orgname.
   
   


2. Usergroups issue
   Always getting error
   >you didn't define usergroups in your parameters file >parameters.json<
   but i did 😉


3. Outdated usecase services naming validator (maybe only typeahead issue)
   Using latest nessessary services like feature-flags-dashboard and plan dashboard,
   services are marked as invalid value.
   Sadly SAP lately changed the handling of the dashboard just with a notice in news, that you have to use the new plan instead. This frustates devs and also toolings 😉
   Problem is, that tool hardly rejects this
   >service >feature-flags< with plan >dashboard< in region >eu10< IS NOT AVAILABLE
   even if this would be possible with SAP BTP CLI

I am not creating tickets, because this was just a try.

For the above reasons, we will still use BTP CLI script to have more fiine control.

Our usecase is to

• create a managed directory with relevant customer entitlements in our SAP BTP ISV Account.


• create two SubAccounts (TEST/PROD) in a dedicated namespace (also on ORG Level with prefixed udina-)


• enable CloudFoundry Environment with given ORG Name


• create dashboard service instances


• create admin/developer users and map them to RoleCollections

Everthing else if autocreated by MTA deployment.

If this will be supported in the future, i would like to give the tool a new try 😉

Since we have to use the tooling for our productive scenarios, we need to make sure, that the existing customer udina-commerce landscape can be rolled out without hazle.

Best Regards
Holger

 

[Rui-Nogueira]

Hi Holger, another root cause could be, that you are using an older version of the container image, in case you have not deleted your container cache before.

The use case you are describing above should be completely covered by the btp-setup-automator already today.

In case you want to try it out let me know and I can give you a helping hand.

Best,
Rui

PS: ideally you put your questions into the github repo: https://github.com/SAP-samples/btp-setup-automator so that the community can help

[timdachtera]

Hello,

i have a few questions using the automator I'm not finding much documentation for, if anyone can help.

1. We are trying to add in our entitlements within a sub-account, and with the UI setup wizard, I see the name and plan, however, when adding them into the JSON file, I get errors on only a few items, yet others work correctly.
   
   
   
   1. 
      

       While trying to add Cloud Foundry: ERROR      : service >application_runtime< with plan >memory< in region >eu10< IS NOT AVAILABLE

      
      
   
   
   2. While trying to add SAP Business App Studio:
      

      ERROR      : USE CASE NOT SUPPORTED IN YOUR GLOBAL ACCOUNT!

      
      
   
   
   
   

However, both of those items can be configured manually in the UI without issue.

 

2) We are needing to adjust values for entitlements like memory limits for Cloud Foundry.  I'm not seeing how/if we can do this in the JSON file.

 

For reference, I'm using the defaults.json file as my starting point, as I did not quickly see. If anyone has seen/resolved this before, please let me know, or if there is a more detailed set of documentation on the support in the JSON files.

Thanks in advance.

 

 

[lechnerc77]

Hi Tim,

the usecase.json as well as the parameters.json should be backed by a JSON schema, so you should get type-ahead support when editing the files.

Concerning the "memory plan", there is alrady an issue open: https://github.com/SAP-samples/btp-setup-automator/issues/238

It would be great if you could add your usecase.json as well as your parameters.json to the issue or create a new one in the GitHub repo so that we can analyze what goes wrong in your setup (https://github.com/SAP-samples/btp-setup-automator/issues )

Best,
Christian