SAP S/4HANA Cloud Public vs Private Edition?

SAP S/4HANA Cloud is an enterprise resource planning (ERP) suite offered by SAP, and it comes in two primary deployment options: Public Edition and Private Edition. Each offers different features, levels of customization, and deployment flexibility to cater to various business needs. In general, below is a breakdown of the differences between the two:

SAP S/4HANA Cloud Public Edition is better deal for organizations that want a standardized, effective, and quickly deployable ERP solution with minimal customization needs.

On other hand its Private Edition is better suited for organizations that require a highly customized ERP environment, need control over their system updates, and are willing to invest in a more flexible and powerful deployment model.

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

MERGE process in SAP BW

In SAP BW systems running on SAP HANA database there is a process called merge. Data being written into (BW) objects/tables are first saved in uncompressed delta index. Merge process is a transfer of uncompressed delta index table data to performance-optimized storages. In order to fully leverage those performance-optimized storages the merge process must be started in regular intervals. In case the data would be just staying in the delta index storages there would be an increased memory consumption (delta storages tables may become very large) that could lead to system instability.

The merge it-self can be executed based on several reasons. There is a term - merge motivations that is a mechanism by which a delta merge operation is triggered. From SAP HANA DB depending on how the merge process is triggered there are following types of the merge process:

Delta merge - operation in the column store of the SAP HANA database that moves changes collected in the delta storage to the read-optimized main storage.

Smart merge – delta merge operation triggered by a request from an application. In SAP BW this term is referred as DataStore smart merge.

Hard merge – delta merge operation triggered manually by SQL statement.

Forced merge – delta merge operation triggered manually by SQL statement that passes an optional parameter to execute the delta merge regardless of system resource availability.

Memory-only merge - delta merge operation triggered manually by SQL statement that passes an optional parameter to omit the final step of the delta merge, that is, persisting main storage to disk.

Auto merge – automatically executed merge by database system.

 

Smart Delta merge in SAP BW trigger can be set on DTP level. In the DTP maintenance t-code RSDTP on Update tab there is a checkbox called 'Trigger Database Merge'. There is also a process type in Process Chains called 'Trigger the delta merge' that can be used to trigger the merge process.

Hard delta merge after request deletion in aDSO can be driven by RSADMIN table parameter called 'RSDSO_HARD_MERGE_AFTER_REQDEL'. It can be set to X to enable hard delta merge after the request deletion.

 

More information:

SAP HANA Delta Merge Related To SAP BW/4HANA

3481267 - Hard delta merge after request deletion

'accounts.sap.com' vs 'account.sap.com'

With an introduction of SAP Universal ID (UID) there are two different sites for managing SAP sites’s user accounts. One is https://accounts.sap.com and another https://account.sap.com. Kindly note the difference, singular 'account' vs plural one - 'accounts'

Difference between the two is with respect to what accounts are they supposed to manage. For S-user or P-user and Universal IDs type of the accounts there are different platform thru which the two are managed.

S-user/P-user type of the accounts are managed via singular 'accounts' - https://accounts.sap.com (Profile Management).

Whereas the SAP Universal ID are managed via plural 'account' - https://account.sap.com (Universal ID Account Manager).

Users can use the respective sites to manage passwords and account information too. For example, if the user  wants to reset a UID password he or she needs to make sure 'account.sap.com' is used. On other hand if he or she wishes to reset an S-User or P-User ID password (if that ID is not linked to a UID) then you would use 'accounts.sap.com', site.

 

More information:

SAP Universal ID (UID)

Something about SAP Service Marketplace (S-user or S*user) ID

What are 1972 requests in BW?

In my earlier post about RSPM (Request Status Process Management) I mentioned special data loads request numbers (so called TSN - Transaction Sequence Numbers). One of them is called housekeeping request. ID of those request starts with 1972 thus they are sometimes called as 1972 request or TSN from year 1972 or 1972-replacement request.

Request format:

{1972-XX-XX XX:XX:XX XXXXXX XXX}

Example of such a request can be:

{1972-01-01 01:00:00 001359 CET}      

Not sure why particular year 1972 was chosen. Perhaps it has something to do with a fact that SAP was founded in 1972 ? Not sure, probably not :-)

Example of the 1972 request as it was seen in RSMNG t-code:

More information:

Request Status Process Management 

BW request types: RSSM vs RSPM