Does my BW run in cloud or on-premise?

In case there is a need to recognize programmatically whether the BW system runs in cloud or on-premise there are some options on how to check it.

First let’s see how it is regarding HANA DB. There is ABAP class CL_SHDB_HC (HANA cloud base functions). Its method IS_HANA_CLOUD fetches versions of the HANA (major, minor, revision and patch) via calling system function call DB_GET_REL. The method returns true in case the HANA DB runs in the cloud and false if it doesn’t.

Subsequently regarding SAP BW. There is the ABAP class CL_RS_UTILITIES (General Auxiliary Methods) and its method GET_IS_CLOUD_BW4_SYSTEM. The method reads table RSADMINA table for column CLOUD_MODE (domain and data element RS_CLOUD_MODE). If the value of the parameter is X it means the BW system runs in the cloud otherwise it is considered as on-premise system.

In case of other SAP systems like S/4 there is the ABAP class CL_COS_UTILITIES (Utility routines for content separation/client separation) and its method VALIDATE_GV_S4H that can be used to determine running environment of the system. The other method IS_CLOUD in the same class is set as obsolete. The VALIDATE_GV_S4H reads first the information from shared memory via parameters like s4h_public_cloud / s4h_on_premise. If that is not successful it reads table TDEVC (Development Packages) for cloud-only packages like 'SR_APS'. Finally, it calls FM 'SFW_IS_BFUNC_SWITCHED_ON' (checks what Business Functions are activated in the system) to check whether function 'SIMPLIFY_ON_PREMISE' is active.

My ABAP code snippet to check whether the BW and underlaying HABA DB runs in cloud or on-premise environment is available here.

More information:

BW4 – Parameters of RSADMINA table

Parameters of RSADMINA table

3 Tier Model to get to ABAP Cloud

Customers who want to migrate tier SAP ERP systems to a cloud need to embrace the cloud from ABAP perspective too. This shift is needed as within on premise SAP ERP systems Classic ABAP extensibility options (user/customer exits, BADIs, enhancement points, modifications, append, structure, menu exits, etc.). All of these were used to tailor SAP systems to meet specific business requirement. But since the introduction of cloud the Classic ABAP extensibility options are not supported anymore in the cloud bases SAP ERP systems.

Apparently majority of SAP customers won’t start with move to the cloud by having a new greenfield implementation of ERP system like S4/HANA Could is. Therefore, SAP had to come up with something that would enable the cloud transition for the existing customer running their ERP systems on premise. It is a 3-tier Extensibility Model. Its purpose is to enable the transition from Classic ABAP to ABAP Cloud. It is also intended to manage a coexistence of these different extensibility models.

Remember much used term - "clean core"? Well as it means up2date, transparent, unmodified SAP system. All these adjectives describe a system that is cloud compliant. Reason why it is important is that as in the cloud all the customers use same base code line and changes are applied to all customers simultaneously. Therefore, there is a no way to allow each individual customer to implement enhancements in the same way that they could in their on premise systems.

 

Tier 1 – Cloud development: default choice for all new extensions and new custom applications following the SAP S/4HANA Cloud extensibility model. Goal is to get to this tier form the lower tiers.

 

Tier 2 – Cloud API enablement / API layer: if there are any objects (BAPI, Classes, Function Modules, Core Data Services) that are not yet released by SAP and are required in tier 1 a custom wrapper is created for them. By this a missing local public APIs or extension points are mitigated. The custom wrappers are built and released for cloud development. Once there is SAP released public local API, the custom one can be set as obsolete and removed. ABAP Test Cockpit (ATC) can be leveraged inhere to force ABAP Cloud guidelines. Also via ATC exemptions violation of the ABAP Cloud rules can be managed.

 

Tier 3 – Legacy Development / classic ABAP development: classic extensibility based on classic ABAP custom code that is not supported in the ABAP Cloud development model. E.g. BAPIs, user exits, modifications, SAP GUI, file access, reports writing to GUI, etc. The goal is to avoid developments in this tier and follow the ABAP Cloud development mode. However, as the customer is at this stage the classic objects are to be modernized and moved to the tier 1. Those need to be refurnished one-by-one there is no any tool for that.

 

Now when it comes to real (re)development of the objects in the particular tiers. A concept of software components is used in here. By creating its own component, the object is separated from the others (e.g. non-clean core components – remember clean core). This is because the component puts stricter ABAP Cloud rules to the objects thus separation is needed.

For all the details how to work with the object within specific tier follow below SAP official guidelines.

 

More information:

Clean Core

ABAP Cloud API Enablement Guidelines for SAP S/4HANA Cloud, private edition, and SAP S/4HANA - overview

ABAP Extensibility Guide - overview

ABAP Cloud - How to mitigate missing released SAP APIs in SAP S/4HANA Cloud, private edition and SAP S/4HANA – The new ABAP Cloud API enablement guide

SAP S/4HANA Extensibility: All You Need to Know

What is a difference SAP RISE vs SAP GROW (GROW with SAP)?

SAP tries to pitch its S/4 cloud solution to its customers very hard for a years. However as per surveys conducted by the SAP User groups like ASUG or DSAG the adoption is not at the level SAP would wish it would be.

Therefore, SAP continues to provide offerings to help customers with their transformation to S/4. It started back in 2021 with SAP RISE followed by this year (March 21^st 2023) Sapphire when another offering – SAP GROW (or Grow with SAP) was introduced.

Let’s look at the both offerings in the nutshell.

The SAP RISE is an offering that combines SAP S/4HANA Cloud public and private edition, accelerated adoption services (e.g. SAP Readiness Check, Custom Code Migration, etc.), SAP Signavio to manage business processes, pre-configured best practices. See more information here.

The SAP GROW is also build on SAP S/4HANA Cloud public edition with the focus on midsize companies where the business processes are more standardized.

The main difference between them is that RISE with SAP is more flexible and customizable, while GROW with SAP is more standardized and out-of-the-box. RISE with SAP targets larger and more complex businesses, and offers both public and private cloud options for SAP S/4HANA. On the other hand GROW with SAP focuses on midsize companies, and only provides SAP S/4HANA Cloud, public edition.

 

More information:

SAP RISE (RISE with SAP) blog

RISE page

RISE online docu

GROW page

SAP CAL and its solution types

SAP CAL (Cloud Appliance Library) enables a deploying of SAP solutions on hyperscalers. In other words it servers for a purposes of SAP system preparation to be running in cloud environment of hyperscaler of a customer's choice. Normally customers face challenges while preparing systems for cloud deployment. It is a very lengthy process that involves activities like: infrastructure setup, install IS, install DB for SAP system, install SAP system itself, Basis configuration of the SAP system, install Support Packages/patches on the SAP system, testing of the system, etc.

In case the customer is aiming for test drive of the SAP system, doing proof of concepts projects, custom development, demo systems for trainings etc such a lengthy process is not acceptable.

To save the time the CAL can be used instead. What the CAL offers is the SAP system that pre-configured and ready-to-use type of system in form of image that can be spin up in hyperscaler's cloud environment.

Currently there are 48+ solution available via the CAL. For ABAP developers there is also an offering of SAP ABAP Platform 1909, Developer Edition available. This can be an option for people who do not have laptops with 32+ GB of RAM to install the ABAP development system on their own hardware.

 

There are following types of solutions (aka charging models) available at the CAL:

Free solutions:

1 Educational solution (EDU): for educational purposes normally running for a length of course on e.g. open.sap.com, open.hpi.de.

 

2 Developer solution (DEV): length of usage depends of particular terms of conditions of developer agreement.

 

3 Free trial period solution (TRIAL): length of usage is free for certain period (e.g. 30days). After that free period, a subscription period needs to be unlocked.

 

Paid solutions:

4 Subscription period solution: usage length is driven by the subscription period that can be bought at SAP store. Customer must have own license for certain SAP solution.

 

5 SAP Model company (MC): Prepackaged system for a specific industry or line of business as an example how an digital transformation in specific industry can be achieved. See Notes: 2568464 - Master Note - SAP Model Company, 2516683 - Installation of Model Company Appliances.

 

More information:

SAP CAL

CAL wiki

CAL docu

CAL info page

FAQ Solution Types and Charging Model

SAP Cloud Appliance Library: creating an instance in AWS - YouTube

"ABAP strict" as ABAP language version

I learned a term "ABAP strict" for first time in autumn 2021 during an openSAP course called Introduction to ABAP in the Cloud. So what is "ABAP strict" sometimes called as "ABAP strict mode"?

The ABAP strict is ABAP programming language version that uses only a subset of the Classic ABAP's syntax. If we think about ABAP in this context, there are now two versions of ABAP.

The first version is ABAP classic. It is the one that we all (hardcore SAP stack programmers) know from on-premise SAP solutions world like R/3, ERP, ECC including SAP S/4HANA on-premise as well.

Another version is ABAP strict. It is the one used in cloud based SAP solutions like SAP S/4HANA Cloud, ABAP environment as well in SAP Business Technology Platform (BTP) ABAP environment.

What are the differences between the two ABAP versions?

As both the versions are used in different environments (on-prem vs cloud), it naturally drives the language’s feature sets.

In case of ABAP strict access to repository objects is given only by released APIs. This means you cannot directly manipulate e.g. database tables with CRUD SQL statement. Instead there a whitelist of allowed APIs to do that. Allowed APIs are checked statically at compile time, as well as runtime.

Moreover, only ABAP Development Tools (ADT), based on Eclipse IDE platform, can be used as development tool. Remember it is about the cloud - SAP GUI is no more the ABAP developer IDE.

In addition, ABAP language keyword set is restricted if compared to ABAP classic. There are many ABAP commands that are obsolete in the cloud environment. E.g. access to SAP server OS, screen manipulation (no GUI, FIORI is the UI), no SQL for data in database tables manipulation, no more WRITE command, dynamic connections, client overrides, relative keywords are not supported, secondary database connection is not allowed etc. just to name a few. Naturally, there is a stricter syntax rules and checks are applied to all elements, including ABAP classes and SQL statements.

 

More information:

SAP BTP ABAP Environment

SAP cloud discovery center

ABAP sessions at SAP TechEd 2021

SAP RISE (RISE with SAP)

In January 2021 SAP has come up with a new offering called RISE with SAP. It is the latest move to push a sales of its cloud software. Branded, as the offering that brings all pieces a customers need to have in order to transfer their business. So called business transformation as a service (BTaaS).

(Rise logo – credit SAP)

The service includes, software and hosting offer, which can involve a lift and shift of an existing application portfolio to the cloud, part of process analysis (via acquisition of Signavio), migrations to the latest HANA-backed version of the software and a lot of business process change. Customer signed to this service (on subscription basis) will have one responsible party for service-level agreement, operations and support. It includes: BTaaS, Infrastructure as a Service (from SAP or a hyperscaler (Azure, GPC, most like AWS too)), Cloud Managed Services – CMS (from SAP), and Application Managed Services – AMS (from SAP or a systems integrator).

In past there were similar solutions (although at lower scale) trying to push customers towards running SAP’s HANA based software in cloud. Around year 2013; it was HANA Enterprise Cloud. Back then HANA wasn’t offered by major cloud providers and it required special hardware to run it on. That killed this initiative. Nowadays; the hyperscalers are offering the HANA hosting however, there is another problem. Move to HANA still lacks the business case. There is no killer application for HANA. Similarly, as push to cloud is driven by cloud providers SAP has nothing to say about it to customers. 

With the SAP RISE offering, the SAP is trying to address issues like those. By offering a service of business process mining (included in process analysis /business process change - BTaaS) it can build the case for HANA move (e.g. of legacy ECC running on any DB). By offering cloud migration (CMS), it can help customers who has no cloud experience yet. Finally, by offering AMS on top of above and having it on one single contract (e.g. also having SLAs defined against single vendor) can help to reduce overall TCO. Let’s see in future how does this offering will be picked up by a market.

More information:

RISE with SAP

RISE accouchement

RISE overview

SAP RISE FAQ