Recommendations on the BTP Pillars – Integration

As we continue to unpack SAP’s Business Technology Platform (BTP) in our series “Recommendations on the BTP Pillars,” let us delve into the second pillar – Integration. This facet of the platform embodies the integration of business partners or networks, business applications and public entities into a tight value chain .

At the heart of this pillar is SAP’s Integration Suite. Integration Suite itself is collection of applications that facilitate data, process and event integration. One application called Cloud Integration is at the center of the solution and provides connectivity and mapping functions. Other services such as API Management, Event Mesh and an Adapter Collection complete the offering and make it a leader in Gartner’s magic quadrant.

Three reason why you should start your SAP BTP Integration journey now:
1. API Management functionality can easily and securely make SAP Business Application API’s available to outside parties. In concert with the Cloud Connector it enables access to biz apps that took weeks and months to enable in the past.
2. SAP released an automatic PI/PO migration tool. This tool can dramatically reduce the manual effort involved in moving your existing integration logic to the Cloud.
3. A plethora of content packages and an AI supported mapping engine is in my humble opinion the real reason every SAP customer should evaluate the BTP Integration pillar. The possible savings in development effort can be substantial.

Through the Integration pillar, businesses can seamlessly manage their APIs, facilitating frictionless interactions with legacy applications and external services. In the dynamic digital landscape, this capacity for integration is an invaluable asset. It’s one more way SAP BTP helps businesses stay ahead of the curve and embrace the digital future’s potential.

And that’s just the beginning. There is more to learn about the Integration pillar and the rest of the SAP BTP. So, as we continue to dive deeper into the platform in this series, remember – “SAP Business Technology Platform is the Business Operating System.” Stay tuned for further insights in the coming weeks.


Recommendations on the BTP Pillars – App Dev

Welcome to the first installment of my deep dive series, “Recommendations on the BTP Pillars.” Today, we’ll be exploring the first pillar of SAP’s Business Technology Platform (BTP) – Application Development, and how it empowers businesses to create personalized and innovative applications.

SAP BTP Application Development enables businesses to build and innovate applications using a range of advanced tools and technologies. One of the core offerings of SAP BTP is the low-code/no-code approach, which allows users to build and deploy apps rapidly with minimal coding knowledge, using tools like Build Apps and Build Work Zone. This visual development approach uses pre-built templates, components, and services to accelerate development cycles while ensuring consistency and quality.

For more experienced developers, SAP BTP offers the Business Application Studio and the ABAP Environment, which provide extensive support for pro-code development. With these tools, developers can create microservices, APIs, and custom logic, integrating them seamlessly with existing SAP applications and external systems.

SAP BTP also embraces the concept of side-by-side extensibility, allowing businesses to enhance and extend their applications without modifying the core code. This approach reduces technical debt and maintenance overhead while enabling a flexible, modular architecture.

The platform’s support for developers allows them to leverage in-app extensions and integration services such as SAP Cloud Platform Integration Suite to create a unified and cohesive user experience. At Rizing, efficiency gains of 10%-20% have been experienced in application development using SAP BTP. Thus, we recommend evaluating Cloud Native approaches and specifically the use of SAP’s CAP and RAP frameworks to maximize the platform’s benefits.

In summary, SAP BTP’s Application Development pillar offers a powerful combination of low-code, no-code, and pro-code tools that allow businesses to develop, extend, and maintain applications more efficiently. Stay tuned for the next installments in this deep dive series as we explore the remaining pillars of BTP and provide more technical insights into harnessing this versatile platform.


SAP S/4 Transitions — acceleration of SAP Business Technology Platform activities

With the flood of SAP projects hitting the SAP system integrator community (see other article), S/4 transitions are facing risks beyond the standard list we encounter in any S/4 implementation. SAP resource shortages could lead to unanticipated project extensions. Project extensions in turn lead to deferred benefit realization and additional implementation cost, and in this case, additional maintenance cost for not hitting SAP’s 2027 deadline.

An environment such as this forces us to think about mechanisms to derisk projects by accelerating no-regrets activities and see resource availability as ‘a’, if not ‘the’ critical success factor.

One opportunity is the acceleration of technical content migration and creation.

Technical work is usual seen as supplemental to the functional work of an implementation, and therefore successive to a business blueprint. In contrast to a net new implementation, a substantial amount of the technical work of a transition from ECC to S/4 is the migration of existing logic into a new IT paradigm.

In analyzing past and present S/4 projects, we determined that each project contains approximately 35% of technical tasks. Further analysis determined that 65% of those technical tasks could be executed ahead of the S/4 transition. This number contains activities such as the migration of ABAP Add-on’s into a side-by-side model, moving integration scenarios to the Cloud and providing insights to decision makers by developing Analytics Cloud and Data Warehouse Cloud-based dashboards.

Sample resource demand for SAP S/4 migration.

The activities must be triaged to determine a ‘no-regrets’ status.

  • Technical objects supporting a static business process receive the status right away.
  • Objects related to an improving business process are evaluated to determine if the technical objects stay consistent across envisioned business process changes or can be developed in a way that can accommodate the envisioned improvements
  • All other objects should be evaluated to see what prerequisites exists to assign them a ‘no-regrets’ status.

If the S/4 transition is taking place soon, the simplest way to structure the segmentation is by pulling the movable BTP tasks forward into a ‘Phase zero — BTP work’ whose end coincides with the start of the S/4 transition program.

In case the S/4 transition is not scheduled for a few years, you can create a program to move the component as outlined above with one adjustment. The components you move out of ECC are replacing existing non-BTP component and reduce the necessary transition work that would occur during the S/4 transition timeline.

Sample resource demand for SAP S/4 migration after acceleration of BTP activities.

The benefits are plenty:

  • SAP’s Business Technology Platform is gradually introduced into the organization to get developers and operators comfortable with it
  • Technical challenges are less likely to impact the critical path of the overall implementation, thus derisking the project and with it the benefit realization timeline
  • Higher likelihood of achieving the planned go live prevents paying incremental maintenance fee or worst-case working in an unsupported system
  • Reducing the BTP resource demand in the high demand/high-cost phase we are expecting in the coming years

The impact of 2027 on SAP customers

For all of us that are working in the SAP ecosystem, December 31st, 2027, is the date that will drive us and our industry for the next years.

SAP is committed to provide mainstream maintenance for Business Suite 7 — the release that a lot of our customers are still using — until the end of 2027. Companies have the option to buy a maintenance extension until 2030 for an incremental 2% in maintenance fees. The prior 2025 support deadline was pushed to 2027 after customers requested more time to move to the new release in 2020 making it unlikely that the 2027 deadline will be moved yet again.

When assessing the current installed base of Business Suite 7, Gartner estimates that 70 percent of Business Suite 7/ECC customers have yet to migrate to S/4 HANA, but SAP S/4 HANA sales are growing at record levels based on SAP latest financial results and comments from SAP CEO, Christian Klein.

Combining these factors, we will see a wave of Business Suite 7 to S/4 migrations hitting the SAP System Integrator community in the next few years. We always knew it was coming, but the pandemic took 2 years out of our planning cycles.

Projected SAP resource demand over the next 10 years

So, here we are at t-5 years with countless customers that have yet to make the move. For IT practitioners, 5 years sounds like a long time, but everyone who has been working on large enterprise initiatives knows: you must create a business case, allocate funding, work with SAP on a license agreement, select an implementation partner, perform the implementation itself, roll it out and ultimately drive adoption of the solution to collect the business benefits you originally committed to in the business case.

If you are a small organization and don’t mind big bang rollouts you might be able to execute this in a year, but for most enterprises we work with, you easily look at an average 2–3-year timeline for transforming from ECC to S/4.

Working in the SAP implementation space, we are equipped to handle a steady stream of SAP projects, ranging from small add-ons to large implementations. We are also equipped to handle ebbs and flows in demand, but the wave we see coming is more analogous to a Tsunami hitting us on all fronts. Business process experts need to re-assess what improvements and benefits S/4 implementations can bring, functional experts need to configure S/4 and various technical teams must migrate interfaces, extensions and any other customer-specific content into the new Cloud-based paradigm.

For SAP customers that means you should start the journey as soon as possible, build your business case, estimate your implementation duration and certainly find and lock in your implementation partner as resources will get sparse and potentially more expensive as demand will undoubtedly outpace supply. Depending on your estimated implementation duration, you might have an alternative to delay the implementation and use the option of paying a premium to SAP. Most companies will likely want to use the 2027–30 timeline as a contingency, though.

To make the S/4 business case more attractive, the industry is continuously working on improving both factors (benefits and cost) of the equation.

New SAP applications and technologies open additional areas of benefit realization, but our teams, as well as our customers, must be equipped to see the potential, implement the changes in the system, processes and most important of all, take their people on the journey to increased efficiency.

Compared to the standard, consultative approach used in the past, cost reductions in the implementation effort can be achieved by standardizing and harmonizing business processes while following and utilizing best practices.

In the SAP implementation space, we are working hard to add capacity and ensure our implementation resources are trained up and ready for the hard work and long hours.

How do we get people to move?

It has been a year and a half now of me coding again. I can honestly say it has been a steep learning curve, but fun and exhilarating.

The question that haunts me when I have 10 minutes to think about all the things I have learned is: “How do we get all the people like me to move?”.

I have a fairly unique position in that it is my job to dig into new paradigms, approaches and languages. But there is a whole SAP industry out there whose job it was and is to write RICEF’s (Reports, Interfaces, Conversions, Enhancement and Forms). They are busy 40 hours a week of delivering on projects and have very little time to catch up on new functionality. The most they learn is the 6 new commands that were added to ABAP.

That whole community, the thousands of them, might struggle to make the jump without a major re-education of certain concepts such as:

  • Storage of code in a repository that is not internal to SAP
  • CI/CD – Continuous Integration and Delivery
  • Cloud approaches such as Blue Green Deployments
  • Containerization
  • … and others

I don’t have the answer, but it is a question that keeps me thinking.

The XSUAA Mystery

For all of you not as familiar with the SAP Cloud Platform, XSUAA is the User Authentication and Authorization service of the SAP Cloud Platform. Unless you want to have applications open to the world, you will need to make use of it to restrict access to your application. That was the starting point for me to figure out what it does and what I have to do to use it properly.

The first confusing thing is the XS in front… well, talk about history: The more you look behind the scenes, there more you feel the SAP Cloud Platform stack started out as a HANA box in the cloud (I know I oversimplify), some of the names got dragged along. This service should probably be called UAA or CFUAA for Cloud Foundry by now… but I digress.

The XSUAA can be triggered or used in various ways. At the moment I use it primarily in the app router (xs-app.json) to secure certain URL path’s. Those URL paths then are assigned to what’s called a “scope”. I think of a scope as a security object. An example definition might look like this:

"source": "^/admin/(.*)",
"target": "/admin/$1",
"authenticationType": "xsuaa",
"scope": "$XSAPPNAME.standard",
"destination": "ms-example-srv_api",
"csrfProtection": true

When you create a XSUAA service you have to specify a configuration file called xs-security.json. I usually put it into a separate sub directory called ‘security’. That file lists the different ‘scopes’, ‘roles’ and ‘role templates’ this UAA instance is exposing. One role can have one or multiple scopes.

Here is an example of one of my xs-security files (what I have learned as good practice is to overwrite the xsappname with a new name in the MTA, that includes the space):

	"xsappname": "ms-example",
	"tenant-mode": "dedicated",
	"foreign-scope-references": [
	"description": "Security profile for Example",
	"scopes": [
			"name": "$XSAPPNAME.admin",
			"description": "Example Administator"
			"name": "$XSAPPNAME.standard",
			"description": "Example Standard User"
			"name": "uaa.user",
			"description": "uaa.user"
	"role-templates": [
			"name": "ms_example_standard",
			"description": "Example User",
			"scope-references": [
			"name": "ms_example_admin",
			"description": "Example Admin",
			"scope-references": [

To assign a role, you can go into a the cockpit and assign them. I will not go into the details how as it differs depending on what your configured Identity provider is. I started out with the SAP ID Service (you specify the S username and password to login) and we are now using the SAP IAS (Identity Authentication Service). A long story in itself, but I like the IAS and the options it provides… coming back to that later….

How does it work?

In simple terms, xsuaa is jumping in when you need authentication and authorization done. This usually happens in one of two ways:

  1. You are redirected to a logon screen that asks you for your credentials (usually username or email address and password) and then you are redirected from there back to your original target.
  2. You have a service-key or api-key and you make the requests.

Behind the scenes XSUAA complies with OAUTH2.0 and eventually issues you a token that you can use for subsequent requests to your ‘real’ application to insure you are you and are authorized.

The approach works really well if you follow the first way outlined above. You can specify a variety of Identity Providers. The direction to your IDP and redirection to your target work well and you can customize the authentication page if you choose so.

Rather than using the SAP ID service, we switched to using SAP’s provided Identity Authentication Service (IAS) as the standard for most cloud based test and development systems. I like it and it should allow us in the future to simply define a further re-direction to Azure as corporate IDP.

When you choose to access your application through a program it get’s more interesting. Again you should have two options. I will outline the options in a Rest Client conform format. The general idea is that I do one or two calls to receive an access token which I will subsequently use to access the application like this:

GET [Target Server][your service]
Authorization: token [token type] [access token]

Before we can do that we need to get the access token, so let’s try to get that.

Access using grant type ‘password’

There are a lot of examples out on the web that describe this approach and the request should look like this:

Content-Type: application/x-www-form-urlencoded
Authorization: Basic [your username]:[your password]

&username=[your username]
&password=[your password]

This should work as long as you are using the SAP ID Service.

If you are using the SAP Identity Authentication Service (IAS) I receive

{ "error": "unauthorized", "error_description": "Bad credentials" } 

After days of searching the web, I finally found SAP note 2766354 ( , which says what I am trying to do is not supported. Please use SAP ID service… mhh, that would defeat the purpose of having switched to IAS to begin with…

So on I go and try the access key approach.

Access using the grant type ‘client credentials’

In order to perform this access you need to request a service-key. What you really need is a client id and a client secret. You can a) create create a service-key through the command line and find client id and client secret b) create a service key through the Cloud Platform Cockpit or b) simply look at the sensitive information of one of your applications binding to the xsuaa service

Scarily the client id and client secret is the same for all approaches and for all instances of a service key. Call me secure conscious, but that cannot be correct.

The request that I use is the following:

Authorization: [client id]:[client secret]
Content-Type: application/x-www-form-urlencoded

&client_id=[client id]

I receive a response with token! I am all excited as this seems to be a solution. When I use the token to access my service, I am disappointed, as my application will not execute and instead returns a html page with an authentication request… but I submitted a token.

So now I am two for two when it comes to successes in accessing my application.

This is where I give up having already sunk 3 days on and off digging into it and submit a ticket to SAP. I will update this blog with what I get back or what I find.

The outstanding questions I have and hope to get answers to are:

  1. Is SAP really not supporting IAS when I programatically want to access my application through grant_type ‘password’? I would assume that IAS should be a very common IDP these days that SAP would support their own IDP.
  2. Given that this access token is not associated with any user, what scopes does it have associated?
  3. Why are service keys not
    • unique for a certain id?
    • limited to certain scope?
    • limited to a time period?
    • cannot be revoked if you delete the service key?

The summer is here

It has been a while since I posted last. As the world has gone crazy, I was locked up at home with the family and kept working.

The good news is I have made a lot of progress on various subjects.

I finally get used to the asynchronous JavaScript execution model and how to use Promises.

The SAP Cloud Platform is not a mystery anymore but building and deploying cloud applications is routine.

SAP in general has had their shareholder meeting and made the press on several subjects. I believe that SAP made the correct decision over the last few years in acquiring the Cloud companies they have. I also believe that it is time now to clean up the lack of commonality and integration. If anything I fear that the integration and the cleanup will not reach deep enough.

Over the next few weeks I will dive into the individual services and topics and outline what I found.

The journey back into the fray

After a long absence from hands on programming and configuring systems and solutions, my current job allows or even requires me to get back into fray.

There are several things I want to dive into starting from machine learning to augmented reality and IoT, but it becomes obvious immediately that my background in HTML, JavaScript, SQL, Java, and Visual Basic is a start, but everything today is Cloud based, requires JavaScript and Python and without understanding HTTP better than basic POST and GET in my days in connection with OAuth and SAML I will not make it very far.

So let the journey begin…