跳到正文
DEV Community· Andrea Antonio Perrelli·· 2 小時前AI 評分34

厭倦「Clean Core」口號式簡報？SAP S/4HANA 與 BTP 的實用技術決策樹

Tired of "Clean Core" Buzzword Slides? Here is the Real Technical Decision Tree for SAP S/4HANA & BTP

AI 導讀

文章提出 SAP S/4HANA 與 BTP 的 Clean Core 擴展架構決策框架，以三層模型隔離舊有技術債，並按需求選擇關鍵用戶擴展、並行擴展或 ABAP Cloud。需要與核心 ERP 資料保持交易耦合的邏輯，應採用內嵌式 ABAP Cloud；沒有已發布 SAP API 時，則以 Tier 2 自訂包裝介面連接。

正文

If you’ve been on an enterprise SAP S/4HANA project recently, you’ve probably seen dozens of corporate slide decks talking about "Clean Core".

Most of them say the same generic things: "Keep the core clean, move everything to the cloud, use standard APIs."

Yet, when lead developers and architects actually sit down in front of ADT (Eclipse) and look at a complex manufacturing or billing process, reality hits hard:

  • The standard released API doesn't exist for their specific extension.
  • The legacy system has 25 years of custom procedural code in SE38, implicit enhancements, and direct database queries on VBAK/VBAP.
  • The management wants a "Clean Core" migration yesterday because the 2027/2030 ECC end-of-support deadline is looming.

The result? Teams either freeze in analysis paralysis or over-engineer simple business logic into massive, detached distributed architectures that break transactional consistency.

Here is the pragmatic, production-tested Architecture Decision Framework we actually use on real enterprise projects to bridge the gap between traditional ABAP and modern Cloud Extensibility.

1. The Monolith Problem: What Really Broke SAP Upgrades

In the classic SAP R/3 and ECC 6.0 era, developers enjoyed virtually unbounded freedom. You could:

  1. Write native Open SQL queries modifying standard tables directly (INSERT, UPDATE on dictionary tables).
  2. Hook into standard logic via implicit enhancements, modifying unmanaged memory IDs without audit trails.
  3. Call undocumented, non-released function modules.

This freedom became a technological prison. Every time an enhancement package (EhP) or support package had to be applied, regression testing took months and cost millions.

Clean Core is not about eliminating custom code. Clean Core is about contract-based engineering: ensuring every extension is decoupled via strictly released, upgrade-stable interfaces so that ERP updates take hours instead of quarters.

2. The 3-Tier Extensibility Architecture

To achieve this without rewriting 100% of your business logic from scratch on day one, SAP establishes the Three-Tier Extensibility Model:

  • Tier 1: Cloud-Ready Core (Strict ABAP Cloud) Pure modern ABAP language version (Language Version 5). Zero access to unreleased objects. Only released public APIs (contract C1) and released CDS view entities. Runs directly on the S/4HANA core (Developer Extensibility) or on SAP BTP ABAP Environment (Steampunk).
  • Tier 2: Cloud API Enablement (The Quarantine Wrapper) When a standard released API does not exist, you do not hack the core. You build a custom, encapsulated wrapper (Tier 2 object) that accesses the classic interface and exposes a strictly typed, cloud-compliant interface to Tier 1. When SAP eventually releases an official API, you only replace the wrapper—zero impact on business apps!
  • Tier 3: Legacy Isolation (Classic Extensibility) Existing technical debt quarantined strictly away from modern applications, scheduled for phased refactoring.

3. The Technical Decision Tree (Step-by-Step)

Here is the exact architectural logic to apply for every extension request:

[Business Requirement]
       │
       ▼
Is it simple UI branding, custom field, or basic validation?
  ├── YES ──► [Key User Extensibility] (Low-code/No-code, in-app)
  └── NO
       │
       ▼
Does the business logic require transactional coupling with Core ERP data?
  ├── NO  ──► [Side-by-Side Extensibility on SAP BTP] 
  │           (Kyma / Cloud Foundry / CAP / Node / Java)
  │
  └── YES ──► [On-Stack Developer Extensibility (ABAP Cloud)]
               │
               ▼
       Does a Released SAP API (C1 Contract) exist?
         ├── YES ──► Implement Tier 1 with RAP (RESTful Application Programming)
         └── NO  ──► Implement Tier 2 Custom Wrapper Interface

When Should You Go Side-by-Side on SAP BTP?

A common anti-pattern is pushing high-volume transactional processing onto SAP BTP when it requires sub-second database transactions with S/4HANA.

Rule of thumb:

  • Keep On-Stack (Embedded Steampunk / ABAP Cloud): Heavy transactional processing, deep data queries, high-throughput calculations requiring close proximity to the HANA database, and core business validations.
  • Go Side-by-Side (SAP BTP): B2B partner portals, mobile consumer apps, Generative AI orchestration (SAP GenAI Hub), integration decoupling with third-party SaaS, and event-driven microservices.

4. Anti-Pattern vs. Modern ABAP Cloud Pattern

Here is what transitioning from legacy procedural code to modern ABAP Cloud looks like in practice:

The Legacy Anti-Pattern (SE38 / Procedural): 

" Classic procedural spaghetti: Direct DB reads & uncontrolled calls
SELECT * FROM vbak INTO TABLE @DATA(lt_orders)
  WHERE vtweg = '10'.

LOOP AT lt_orders INTO DATA(ls_order).
  " Calling undocumented BAPI without error handling
  CALL FUNCTION 'BAPI_SALESORDER_SIMULATE'
    EXPORTING
      order_header_in = VALUE bapisdhead( doc_type = ls_order-auart )
    TABLES
      order_items_in  = lt_items.
ENDLOOP.

The Clean Core Pattern (ABAP Cloud / RAP): 

" Modern ABAP Cloud: Type-safe, CDS-backed, EML-driven
SELECT FROM I_SalesOrderBasic
  FIELDS SalesOrder, SalesOrderType, CreationDate
  WHERE DistributionChannel = '10'
  INTO TABLE @DATA(lt_orders).

" Transactional modification using Entity Manipulation Language (EML)
MODIFY ENTITIES OF I_SalesOrderTP
  ENTITY SalesOrder
  UPDATE FIELDS ( Description )
  WITH VALUE #( FOR order IN lt_orders 
                ( %key-SalesOrder = order-SalesOrder 
                  Description     = 'Clean Core Verified' ) )
  FAILED DATA(lt_failed)
  REPORTED DATA(lt_reported).

COMMIT ENTITIES.

Key Takeaways for Solution Architects

  1. Clean Core is a spectrum, not a binary switch: Start by wrapping your critical unreleased interfaces in Tier 2 to decouple your apps today.
  2. Standardize on RAP (RESTful Application Programming Model): RAP is the sole foundation for transactional cloud apps on SAP S/4HANA and BTP.
  3. Decouple via Business Events: Use SAP Event Mesh and RAP Business Events to trigger asynchronous processes outside the core ERP transaction.

📦 Need the Full Architecture Blueprints?

Over the past few months, I’ve codified this entire enterprise methodology, complete with real-world decision trees, BTP landscape diagrams, and production-grade code:

  • 📘 The Definitive Guide to ABAP Cloud & Clean Core Extensibility: 95-page comprehensive handbook, 40 high-resolution Retina diagrams (ready for your client slide decks and ADRs), 61 code listings, and editable DOCX master.
  • 🧭 The SAP BTP & Business AI Architecture Companion: Interactive Notion workspace with decision matrices, GenAI Hub orchestration, and offline PDF playbook.

👉 Explore the Complete Architecture Suite on Gumroad

What’s the biggest challenge your team is facing with Clean Core and S/4HANA migrations? Let’s discuss in the comments below!

來源：DEV Community · dev.to

#教學/實踐#部署/工程