May 16, 2022

The fate of specifics in SAP Business Technology Platform (BTP)

Commercially, construction includes a list of products to benefit from databases, data management tools, datawarehousing, analytics, some machine learning capabilities, IoT services and especially development tools.

Continuation of the article below

Technically, the Business Technology Platform, formerly known as the SAP Cloud Platform, is a PaaS hosted by cloud providers. It is therefore the place of reception of the types of services listed above, to be found in the SAP Discovery Center interface. The German publisher presents construction as the space where customers can deploy innovative applications. But it is also a PaaS to host personalized extensions, specific ones, existing or not.

For companies coming from ECC, this is a big change, as they must move from a monolithic approach to a decoupled architecture, or even microservices. “We have an organizational impact to anticipate. Today, everything is included in the same block. Tomorrow, I have several blocks to which I must associate skills, and I must change from one monolithic approach to another based on data, ”considers Gianmaria Perancin, president of USF, the French users’ club SAP.

SAP BTP: three development environments + 1

Because if certain services are sometimes ready to use and connect directly to S4 / HANA, others are bricks from which to draw to develop the applications of a company. In this case, SAP has several development environments from the BTP Cockpit. The oldest is called NEO. This is a proprietary BTP branch hosted on SAP data centers, thought of as a “PaaS enterprise”. It is dedicated to the development of HTML 5 applications (via the SAPUI5 or OpenUI5 framework), Java and SAP HANA extended application services (SAP HANA XS). Neo executes part of the services present on the Discovery Center catalog, and above all makes it possible to orchestrate applications on Java servers, on virtual machines. Its access depends on a different sub-account from the rest of the development platform.

The Cloud Foundry environment is open source, and was chosen by SAP precisely to replace the old NEO on cloud infrastructure (AWS, GCP, Azure, Alibaba Cloud). Cloud Foundry can host the runtimes of ABAP, Java and JavaScript applications (via Node.js), but also PHP, Go, Ruby, .Net Core, etc. via buildpacks. Added to this is, the Kyma environment, an open source project designed to extend the capabilities of CF with containerized microservices and Python or Node.js (FaaS, Serverless) functions in Kubernetes clusters. Finally, the new kid is called “ABAP environment” and relies on the same Cloud Foundry space.

“In the Cloud Foundry environment, you can create a new space for ABAP development. This is what we call the ABAP environment. It allows you to create extensions for ABAP-based products, such as SAP S / 4HANA Cloud, and to develop new cloud applications. You can transform existing custom code based on ABAP or extensions to the cloud, ”the documentation reads.

The Cloud Foundry, Kyma and ABAP environments form the “Multi-Cloud Foundation”. If the publisher does not really mention the term, surely not to offend cloud providers, this multicloud approach is nevertheless in the SAP roadmap. Moreover, CF and Kyma are more tolerant of “non-SAP” services and developments. For customers who deploy S / 4HANA on-premise, access to the Business Technology Platform is remote, after setting up a secure tunnel to avoid blocking the firewall (yes, S4 / HANA is possibly hybrid ).

BTP, the home of specifics with RISE with SAP

However, the Business Technology Platform takes on a strong importance within the framework of the single contract proposed with RISE with SAP. So, what does the German publisher recommend for those who would like to migrate their specifics to the edge of S4 / HANA Cloud?

First of all, it will be necessary to go through the suite of “Readiness Check” tools, and this as early as possible in the preparation of the migration, recommends the publisher. Readiness Check lists the active business functions of an existing system in order to identify those compatible with S / 4HANA. It recommends the most relevant Fiori applications, reveals the integrations impacted by the migration, indicates the solutions adapted to the company’s activity, lists the compatible add-ons and provides access to Custom Code Migration.

Custom Code Migration is a custom code migration tool that must either be attached to an S / 4HANA test environment, or to the ABAP environment within the construction industry. Custom Code Migration is included in the RISE with SAP offer and makes it possible to migrate existing extensions and modify them in BTP, consuming the credits associated with BTP in the contract.

“Clean Core”: SAP wants to protect its standard code

SAP’s primary goal is not to ensure perfect compatibility of existing specifications with S / 4HANA. The publisher wants its customers to apply the “Clean Core” approach.

The concept of “Clean Core” aims to rid S4 / HANA as much as possible of personalized code. From now on, SAP wants us not to touch its engine.

“In practical terms, keeping the kernel clean (Clean Core) means enforcing a zero or minimal modification policy from the start. In short, do not change the standard SAP code, as this locks up the system for system updates and upgrades, and increases the effort of test and upgrade cycles. Try to stay close to the standard and for differentiated / unique business needs, use whitelisted APIs for extensions, to incorporate custom code, ”the SAP documentation reads.

However, we also understand that it is always possible to move away from the SAP standard, especially with private cloud editions: it is simply strongly discouraged.

A migration of specifics to be planned a year in advance

Custom Code Migration is therefore primarily aimed at detecting incompatible and unused SAP ERP code elements.

“SAP recommends collecting usage data in your production systems at least one year prior to your SAP S / 4HANA conversion project, using ABAP Call Monitor and SUSG. ”

Olga DolinskajaProduct manager, ABAP Platform, SAP

“Our statistics for the last 15 years show that 30-60% of the custom code in a production SAP ERP system is not executed, a considerable part can be replaced by the standard SAP code during the conversion of the system. Removing obsolete code will greatly reduce the costs associated with adapting and maintaining custom code in the future. At the same time, it is certainly a first step towards the Clean Core, ”writes Olga Dolinskaja, Product Manager, ABAP Platform, at SAP.

“Identifying unused custom code begins with understanding its usage in customer production environments. SAP therefore recommends collecting usage data in your production systems at least one year prior to your SAP S / 4HANA conversion project, using ABAP Call Monitor and SUSG. […] She adds.

Custom Code Migration should also help identify the custom code to be simplified and verify whether a “standard” equivalent exists. Once the scan is complete, the removal of the “obsolete” code is done through Custom Code Migration or SAP Software Update Manager.

After migration, the code can finally be simplified via the “Quick Fixes” function in ABAP development Tools (ADT) for Eclipse. SAP promises “up to 60% automation for the most frequent simplifications”.

In this paradigm, the lift and shift approach, even for those who have opted for S / 4HANA on site, is no longer recommended.

“There are a number of ways to do this, such as removing the old business logic, redesigning your custom applications using the extensibility of SAP S / 4HANA, or considering the SAP BTP transformation for tailor-made custom extensions. cowardly, ”says Olga Dolinskaja. “Of course, this is a challenge and it will cost you time and effort, but those efforts will pay off in future updates to SAP S / 4HANA and the transformation to SAP BTP.”

A fifth isolated environment of S / 4HANA, an alternative under development

However, SAP is well aware that certain applications or certain extensions are closely linked to the SAP standard. As “classic” extensibility is not supported in S / 4HANA Cloud, you need an environment other than BTP (corresponding to a “Side by Side” extensibility, sic) for these less decoupled programs.

“Starting in 2021, SAP plans to offer an additional extensibility option as part of SAP S / 4HANA and SAP S / 4HANA Cloud to complement the current extensibility capabilities of key users (in-app),” informs the guide dedicated to the implementation of SAP custom code.

The extensibility option provided for (on-stack) developers must meet the requirements of ABAP programmers who would like to maintain their custom applications while respecting the notion of “clean core”.

“Technically, this will allow you to develop custom extensions on the same ABAP platform that is used by the SAP S / 4HANA instance or the SAP S / 4HANA Cloud tenant. A clear separation between custom code and standard code is achieved by adopting the RESTful ABAP application programming model based on CDS views and an optimized ABAP, ”envision the authors.

If such a development environment emerges, it could probably be suitable for customers coming from ECC, since they will be able to reuse part of their business logic from their SAP ERP system. The publisher cautions that more traditional ABAP features such as transactions and SAP GUI programs will not be available.