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:
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
No comments:
Post a Comment