Jonathan Andre is a lead ABAP developer at IT Partners. Jon has over 10 years experience with SAP, with a concentration on ECC SD, MM, and IS-OIL modules. Jon’s focus has been in the areas of ABAP OOP, ABAP Web Dynpro, and ABAP for HANA and RESTful ABAP development. He can be reached at [email protected]
So far in our ITP Blogs we’ve discussed what the Business Technology Platform is and what it offers. At this point however, we have not made it clear exactly HOW the BTP can be used to replace on-premise functionality that is often still required to meet business needs.
To explain how it all comes together, we will use this blog to understand the BTP, the account model it utilizes, and how to manage BTP options, services, and environments using the BTP Cockpit.
Before we fully dive into the BTP Cockpit, here are some useful terms explaining the BTP account model. This is important to understand exactly where your applications are being deployed and how your applications gain access to the resources it requires to execute.
SAP BTP-Application Basics 
Global Account
The first thing any company needs to do prior to using the BTP is to configure a Global Account. A global account represents the business to business relationship between SAP and the client who wants to utilize the BTP’s services and environments. Regardless of the number of regions, subdivisions, or individual environments required, every company only requires one Global Account. Global Accounts are where users will purchase entitlements, configure subaccounts and directories, monitor account usage and expenditures, and assign quotas to specific subaccounts.
Providers and Regions
The actual services, programs, and environments required to run a BTP instance all reside in an actual physical location. SAP has established relationships with multiple cloud providers, including Amazon, Google, and Microsoft, to allow the BTP to run on their infrastructure. Users must pick a particular provider and an available region that they would like their services to run from. An example would be choosing a provider of Amazon Web Services and a region of US East. Regions vary by provider, and not all BTP services are available for every provider/region.
Subaccounts
A subaccount represents an actual instantiation of a BTP environment. Subaccounts are assigned to exactly one region and one provider. Each subaccount has its own set of environments, tools, and services, both custom and SAP provided. SAP provided services and tools are “subscribed” to through the use of entitlements. The Global Account will purchase these entitles and assign them at the directory or subaccount level. Usage of each entitlement can be restricted using quotas.
Directories
Directories allow the management and organization of subaccounts. While its possible to develop and deploy applications from one subaccount, it often makes more sense to have multiple subaccounts that exist exclusively from each other. Directories allow subaccounts to be organized into logic units. Organizing by region, business area, or by development stage (DEV, STG, etc.) can be easily accomplished by placing the appropriate system into the correct directory.
Entitlements
Entitlements grant users access to their own instance of services and tools. Entitlements allows these services to be consumed in chunks, with each service having its own pricing model. Some services may be purchased in their entirety for one monthly fee. For instance, the ABAP environment itself is purchased per environment, regardless of usage. Others are broken down usage metric, which could be by hours, number of users, GB, etc. This allows users to only pay for what they use in a particular month, while allowing their solution to size up and down as required.
Quotas
Quotas are usage restrictions placed on particular directories and subaccounts. If a global account purchases a specific amount of entitlement credits but wants to make sure one particular subaccount does not consume more than their fair share, quotas can be used to place caps on what any one subaccount can consume.
Tools and Services
The tools and services available support the development of custom extensions by providing commonly used functionality in a pre-built and configurable applications. User validations, monitoring services, codebase management tools, and currency conversion tools are just some examples of the available services that the BTP offers to users to accelerate their application development. This allows application developers to spend less time developing these time-consuming functions and more time on developing the custom business logic that drives their extension applications.
Runtime Environments
Environments are the stage where all custom web services and applications live and are executed. Once published or deployed to an environment, custom developments gain access to resources to execute their routines and connect to the outside world. The most widely used environment on the BTP is the Cloud Foundry environment. The Cloud Foundry supports execution of Java, Python, and JavaScript languages natively. The ABAP Environment, which supports the execution of ABAP code, also resides in the Cloud Foundry. The two primary approaches to BTP programming, Cloud Application Program (CAP, written in Node.js) and RAP (RESTful ABAP Programming, written in a restrictive ABAP language) both execute within the Cloud Foundry, for instance.
Web Services and Applications
Web services and applications are the interface where programs and live users can access a web program, respectively. Generally speaking, the consumer of any custom BTP development will mostly be accessing programs from outside of the BTP. Therefore, there needs to be a web-accessible entry point to the programs. This is where OData and Fiori applications come in. These technologies allow applications and services built on the BTP in running in the environments to be accessed and integrated into external ERP solutions.
SAP BTP-How it All Comes Together
Now that we have named the major components that make up the BTP, lets explore how all of these things come together to create this web-accessible custom development. To do this, we will take a step-by-step walkthrough of IT Partners’ BTP environment and explore our sample web application.
When first logging into the Business Technology Platform, users will be taken to the Global Account. There are a few options on the left-hand side that allow an administrator to manage and monitor their overall BTP account. For this blog we are focused on the Entity Assignments and the Account Explorer.
The Entity Assignment tab allows us to view, add, or delete services for a particular directory or subaccount.
The Account Explorer tab we can view all active directories and the associated subaccounts. From here, we will click “DEV” to navigate to our DEV subaccount.
Once we navigate to our Subaccount page, we are presented with an overview of our current configuration. This includes our current IDs, statuses of our environments, and the current entitlements we are using or have available.
For each subaccount, we can choose to activate any of the three available environments: Cloud Foundry, Kyma, or ABAP. The Cloud Foundry environment, once subscribed to, will allow users to deploy pre-built, ready-to-configure SAP services and/or deploy their own custom built applications. Each service, whether custom built or SAP built, must be deployed to an environment.
When it comes to the Cloud Foundry, the environment itself can be split into multiple spaces. Details of spaces will be covered in a future blog, but for purposes of this blog it should be understood that spaces are just another way to subdivide the CF (Cloud Foundry) environment to separate different functional areas (into process areas, separate projects, or whatever approach suits a particular development team).
By clicking on the tile for our “dev” space, we are able to see details of our CF space. (Note that our Subaccount is named “DEV” and our CF space is also named “dev”. These are allowed to have entirely different names. It just happens that we called both the same name in our environment)
Before we dive into the details of the space, lets first go over what scenario the different applications and services are supporting. Currently deployed in the Cloud Foundry DEV space is a custom Risk Management application. Some of those working towards or that have achieved Extension Suite certification should find this set up familiar. This is a CAP (Cloud Application Programming) app based on node.js.
The Risk Management application tracks risks for a manufacturing company that exports goods to foreign countries. Each risk is associated with a mitigation strategy, a risk owner, priority, impact, and finally an associated business partner. The assigned business partner is extracted directly from an S/4 HANA system via OData service. (see below)
This app, which is a basic CRUD( Create, Read, Update, Delete) application, requires a lot of moving pieces behind the scenes. Things like database deployment and management, connectivity to users and external resources (like our Business Partners), and user authentication are additional concerns that have nothing to do with the specific business logic, but still need to be solutioned for a functioning app. It is for exactly these sorts of tasks that Extension Suite services are created.
SAP BTP Services
Let’s have a look at some of the running services in the dev space to see how our Risk Management app is being supported (the ABAP Instance is related to another project and can be ignored)
hanadev / SAP HANA Cloud Instance:This service just allows us to create and maintain a HANA cloud instance. This is where out data resides while the Risk Management app is deployed. In addition to creating a HANA Cloud instance for application deployment and a data storage, the HANA Cloud instance also creates a web application that allows us to fully manage our HANA instance. You can see the link to this management app, “SAP HANA Cloud” in the above screenshot.
risk-management-db / SAP HANA Schema & HDI Container:This assists in converting design time artifacts to runtime objects. This allows us to deploy our data model so it may be consumed by the running application. The is how our risk management data model is deployed to the database
risk-management-destination-service / Destination Service: The destination service helps retrieve target system information from your BTP account, including URL destinations and any stored credentials. The destination service allows our app to authenticate, connect, and retrieve the Business Partner OData from the external S/4 HANA Cloud system.
risk-management-xsuaa / Authorization and Trust Management Service: The Authorization and Trust Management service lets you manage user authorizations and trust to identity providers. Identity providers are the user base for applications. You can use an identity authentication tenant, an SAP on-premise system, or a custom corporate identity provider. In our application, this is used to authenticate application and service users, as well as providing database level authentication.
SAP BTP Application
Next we’ll have a look at the applications that support our scenario. There are three applications that support our Fiori Elements app, including the OData service app that can be used as a standalone API:
risk-management-srv: This is the only service that was directly “coded” by us as developers. This is an OData service that was generated based off of our CDS Views and customized using minimal node.js changes and metadata modifications. This OData service is continuously running in our Cloud Foundry environment and will respond to OData request from authenticated users/systems both internal and external to the BTP.
This application has service bindings to the risk-management-xsuaa, risk-management-db, risk-management-destination-service services for authentication, database, and connectivity services respectively.
By clicking the app name, we can view additional details about the service. We can also start, stop, restart, or delete the service, modify the resource settings, or spawn another identical instance when loads near their maximum:
risk-management-approuter: The application router is a generated application that has a few purposes. First and foremost, unlike the Risk Management OData service, the Risk Management application itself does not have its own URL. Therefore, to make the Risk Management app UI resources available to external users, the Risk Management app requires an approuter to be accessible by URL. The approuter will handle authentication of users (through use of the risk-management-xsuaa service) then route the user to the UI resources folder so they can interact with the application.
Secondly, although the Risk Management OData service does have its own URL, the OData service itself is unable to authenticate users when directly accessed. Therefore, an approuter is used to authenticate users and forward their requests to the OData service.
The approuter, while accessed through one entry point, is able to determine whether users are targeting the app or the service based on the URL suffix:
Approuter URL: https://…approuter.cfapps.us10.hana.ondemand.com/
Service URL: https://…approuter.cfapps.us10.hana.ondemand.com/service/
App URL: https://…approuter.cfapps.us10.hana.ondemand.com/app/
The approuter, as you may have guessed due to its authorization functionality, has a binding to the risk-management-xsuaa service.
risk-management-db-deployer: The least important of the three applications, this app simply takes our predefined project data and deploys it to the HANA DB when the project itself is deployed. This allows our application to start with the required predefined data, even if we needed to move environments or completely redeploy the project for some reason.
Summary
SAP Extension Suite provides a strategic approach for extending business solutions — whether SAP, non-SAP, cloud, or on premise — beyond what is provided with the core system to drive digital realization forward. With its multi-cloud strategy, you get the best technologies from SAP and underlying hyperscalers, along with a development environment and tools that enable ABAP developers to work on cloud solutions with access to new and open technology while also allowing non-SAP developers to contribute to SAP-related projects. Digital experience and digital process automation tools also enable you to support the channel that best meets user needs.
With our service and application created and running in the cloud, the final step toward integrating with our SAP system is to simply incorporate our Fiori app into our S/4 HANA systems Fiori launchpad, or use extensibility options built into the S/4 HANA system to trigger or reference our OData service. This allows seamless integration while also keeping our core S/4 HANA system clean of any custom code. In future blogs we will go through exactly this type of S/4 HANA system integration using a custom application built from the ground up. Hopefully this blog has given you some insight into the machinations behind the BTP and how it supports creating of Extension Suite apps.
