SAP 清洁核心的拓展白皮书 - 清洁扩展概念介绍 (2)

本文内容主要来自 Clean core extensibility 白皮书

SAP 发现企业在实施定制化拓展时往往遇到很多问题，包括但不限于：标准功能是否满足需求，有哪些拓展方式是可选的，不同方式可以达成什么样的效果，未来该如何维护这些拓展才能保证持续的创新能力等等。

所以 SAP 推出了 Clean Core 方法论，为组织在拓展核心 IT 系统时提供指导意见，帮助组织打造一个清洁的核心。

清洁核心方法论下又包含了五个维度的清洁，分别是业务流程/拓展/数据/集成/运营 维度的清洁性，本白皮书主要关注拓展层面的清洁核心原则

白皮书内容较多，章节 1，2 的内容见 Link，章节 4 的内容见 Link

本文包含了章节 3 的内容，主要介绍 Clean Core 原则，重点关注扩展性选项，包括”体内 On Stack”和”体外 Side by Side”模型、Clean Core 等级概念以及合作伙伴解决方案的一致性。

3.Clean Core 对扩展性的意义

 3.1 Clean Core 5 大指导原则中的扩展性

Clean Core 是指一套方法论，通过培育敏捷、创新和高效的 ERP 系统来支持持续的业务转型。这些原则专注于构建韧性的业务流程和扩展，由无缝的集成、高效的运营和高质量的数据支持。每个原则都有特定的目标和关注领域。

1. 业务流程

   目标：在降低复杂性的同时保持竞争力。

   关注点：简化和标准化流程以保持敏捷性，同时避免过度定制核心。 

2. 扩展性

   目标：将扩展与标准解耦。

   关注点：使用 SAP Build 实现”体内 On Stack”和”体外 Side by Side”扩展性，使关键用户和开发人员能够在不修改 SAP 核心的情况下进行定制，确保更容易的升级和更好的可维护性。

3. 数据

   目标：根据最新标准控制数据。

   关注点：确保数据被治理并符合当前标准，以获得更好的质量、安全性和集成。

4. 集成

   目标：保持环境可靠和灵活。

   关注点：使用发布的 API 和现代集成概念（例如，基于事件的集成）连接系统，而不产生损害灵活性的依赖关系。

5. 运营

   目标：保持运营有效和高效。

   关注点：简化系统管理，在需要的地方实现自动化，并确保以最少的人工工作实现高可用性和性能。

虽然本白皮书主要关注扩展性，但清洁的拓展与其他指导原则密切相关。例如，创建合规扩展需要业务流程的清晰治理。 

通过突出这些相互依赖性——比如高效的业务流程如何实现更好的扩展性，或扩展性工具如何与运营框架保持一致——清楚地表明每个原则都加强了其他原则。它们共同构成了灵活和可持续的 SAP 环境的基础。

3.2 扩展性选项：”体内 On Stack”和”体外 Side by Side”

无论云 ERP 解决方案如何（SAP S/4HANA Cloud 私有版或 SAP S/4HANA Cloud 公有版），扩展性用例通常通过两种架构方法支持：

• “体内 On Stack”扩展性用于与 ERP 核心紧密耦合并在同一堆栈上运行的扩展

• “体外 Side by Side”扩展性用于松散耦合并在单独扩展性平台上运行的扩展。

在 SAP 环境中，当扩展应该与 SAP S/4HANA Cloud 解决方案紧密连接时，使用”体内 On Stack”扩展性。

当拓展与 ERP 系统要松散耦合时，使用 SAP 业务技术平台（SAP BTP）来实现”体外 Side by Side”扩展性。通常，需要”体内 On Stack”和”体外 Side by Side”扩展性的组合，来满足业务需求。

扩展性选项：何时使用什么？

以下指导原则和建议将帮助决定扩展的哪些部分应该作为”体内 On Stack”扩展在 SAP S/4HANA 上运行，哪些应该作为”体外 Side by Side”扩展在 SAP BTP 上运行。 

注意：此指导包含帮助有效导航决策过程的见解，但并非详尽无遗。重要的是分析每个扩展场景并就每种情况下最适合的技术做出明智决定。有关更多信息和支持，请参阅 SAP BTP 指导框架并使用 SAP 应用扩展方法论。

3.2.1 “体内 On Stack”：SAP Build（基于 ABAP Cloud）或经典扩展性

当扩展必须与 SAP S/4HANA Cloud 系统紧密连接，直接与核心数据、事务或应用程序交互时，通常需要”体内 On Stack”扩展。

常见的”体内 On Stack”用例模式包括：

• 适配和扩展标准应用程序：

通常用于执行以下扩展任务：

• 适配标准用户界面（UI）

  向标准 UI 添加自定义字段

  扩展 SAP 数据模型

  通过在逻辑工作单元内实现 SAP 应用程序的扩展点，用自定义逻辑修改标准业务流程。

• 创建自定义全栈应用程序：开发需要根据前述特征接近 SAP 业务对象和服务的新应用程序。全栈应用程序包括后端和前端实现，因此跨越整个堆栈。

• 创建和启用集成：使用 SAP 的“已发布”API 或事件，来为 SAP BTP 上的”体外 Side by Side”扩展提供对接。有关“已发布”API 或事件的更多信息，请参阅开发人员扩展性页面。

• “体内 On Stack”扩展的典型特征：在同时更新 SAP 标准，自定义表，字段时需要事务一致性。需要自定义集成，如标准对象（API 或服务）的扩展，以对接”体外 Side by Side”扩展。读取数据量大，需要复杂的 SQL 查询和连接。频繁访问和更改 SAP 标准表和字段的数据，导致许多消息往返。扩展现有的 SAP S/4HANA 核心应用程序（例如 UI 适配、自定义字段/逻辑/业务对象）。

SAP S/4HANA Cloud 公有版上的”体内 On Stack”扩展必须使用 ABAP Cloud 开发模型实现。在 SAP S/4HANA Cloud 私有版和本地环境中，也推荐 ABAP Cloud 以满足最高的 Clean Core 标准（参见第 3.3.1 章中的"等级 A"），尽管经典扩展性选项仍然可用。

扩展策略中 ABAP Cloud 的作用和好处

ABAP Cloud 是 SAP Build 的一部分，是创建云原生应用、服务和扩展的标准开发模型。

• 统一开发模型：ABAP Cloud 为构建”体内 On Stack”和”体外 Side by Side”扩展提供单一、一致的模型。它在 SAP S/4HANA Cloud 公有版、SAP S/4HANA Cloud 私有版、本地系统和 SAP BTP 上可用。用于开发客户和合作伙伴扩展以及 SAP BTP 上的 SaaS 应用程序，它是 SAP 用于开发 SAP S/4HANA Cloud 本身的主要模型。开发人员可以利用他们现有的 ABAP 开发工具知识来进行云就绪和清洁扩展性。

• 默认云就绪和 Clean Core 合规：ABAP Cloud 引入的新语言版本允许通过编译器和语法检查强制执行云和 Clean Core 规则，确保它们不能被绕过。

• 全面的模型驱动架构：ABAP Cloud 支持由 ABAP RESTful 应用程序编程模型支持的在线事务处理（OLTP）、在线分析处理（OLAP）以及新集成和 API 的开发。事务一致性则通过严格控制的逻辑工作单元 logical unit of work 维护。

• 丰富的预构建技术和业务服务集：ABAP Cloud 包括可复用服务，如日志记录、变更文档、编号范围、作业、工厂日历、货币转换、度量单位等等。这些服务不需要额外开发，可以降低复杂应用的总开发成本和拥有成本。它们推动自定义扩展的高度标准化和可支持性。默认配置（日历、国家、语言、货币、单位等）自动交付并可开箱即用。

• 内置云质量和工具：ABAP Cloud 通过可扩展性和弹性等功能推动云就绪。它还强制保证代码质量。 

• AI 驱动的开发：ABAP Cloud 利用 SAP 的 Joule 在 ABAP 开发工具内提高开发人员生产力。ABAP 的 AI 软件开发工具包允许开发人员从 BTP 上的 SAP 生成式 AI 中心消费 AI 服务。这样，他们可以在自定义 ABAP 扩展中利用预构建的 AI 功能。

3.2.2 使用 SAP Build 的”体外 Side by Side”扩展

SAP BTP 是一个统一的平台产品，包括应用程序开发和自动化、集成、数据和分析，以及 AI 服务四块。

该平台为用户提供将数据转化为业务价值、编排和自动化业务流程，以及——最重要的——快速为 SAP S/4HANA 构建扩展的能力。它同时提供集成能力，帮助确保业务流程跨 SAP 和第三方解决方案连接。SAP Build 作为 SAP BTP 的一部分，能够开发与 SAP S/4HANA 核心松散耦合的”体外 Side by Side”扩展。

在 SAP BTP 上运行的自定义应用程序和扩展可以使用“已发布”的远程 API 和事件与 SAP S/4HANA 交互，而无需修改核心。

“体外 Side by Side”扩展的常见用例模式包括：

• 创建自定义全栈应用程序：

  全栈、单租户应用程序——客户和实施合作伙伴在 SAP BTP 上开发。

  全栈、多租户 SaaS 应用程序——SAP 的独立软件供应商（ISV）在 SAP BTP 上开发并分发给其客户。有关实施示例，请参阅 SAP Discovery Center 网站上的任务。

  中心场景——在 SAP BTP 上开发数据中心应用以收集和分发来自各种系统的数据，与多个 ERP 系统和云服务集成。有关示例，请参阅 github.com 上的页面。

• 创建自定义移动应用：提供移动开发能力。有关实施示例，请参阅 SAP Discovery Center 上的任务。

• 跨多个系统自动化任务和流程：提供低代码/无代码能力来自动化流程。有关实施示例，请参阅 SAP Discovery Center 上的任务。

• “体外 Side by Side”扩展的典型特征和示例：可以解耦的独立应用或新业务流程。需要使用更广泛的开发语言（如 Java、JavaScript 或 ABAP）和技术架构以及开源库时。为没有 SAP S/4HANA 用户账户的外部用户提供应用程序。独立于基础架构、可扩展性操作和生命周期——实现频繁更新和持续交付。

SAP BTP 提供这些扩展场景所需的平台服务和技术。更多详情，请参阅下一章、扩展架构指南或 SAP BTP 开发人员指南。

扩展策略中 SAP BTP 的作用和好处

SAP BTP 支持两种编程模型。

SAP 云应用程序编程模型（CAP）专为 JavaScript（Node.js）、TypeScript 和 Java 开发而设计。CAP 服务在 SAP BTP、Cloud Foundry 运行时和 SAP BTP、Kyma 运行时上开发和运行。它提供实现和消费服务的库，以及自动处理常见请求的通用提供程序实现。CAP 还允许集成开源库。

ABAP RESTful 应用程序编程模型是 ABAP Cloud 的核心部分，在 SAP BTP ABAP 环境中使用。它支持模型驱动开发，包括创建服务、业务对象和集成的工具。

两种模型都基于核心数据服务（CDS），这是一种用于定义域模型和服务的建模语言。它们设计用于与 UI 框架（如 SAPUI5 和 SAP Fiori）集成，实现企业级应用程序的快速开发。

• 鼓励创新：通过启用”体外 Side by Side”扩展性，SAP BTP 鼓励创新而不会破坏核心 SAP S/4HANA 套件。开发人员可以在 SAP BTP 上试验新功能和应用程序。在创建扩展时，他们可以从更广泛的编程语言中选择，如 ABAP Cloud、JavaScript、Java，甚至 Python（例如，用于 AI 用例）。

• 降低总拥有成本：将 SAP BTP 用于”体外 Side by Side”扩展可以帮助降低总拥有成本。由于这些扩展符合 Clean Core 要求并与 SAP S/4HANA 松散耦合，它们不会干扰升级，从而最大限度地减少测试和维护所需的工作。

• 支持向 Clean Core 的转型：通过为”体外 Side by Side”扩展性提供平台，SAP BTP 支持向前述场景和用例的 Clean Core 转型。在”体外 Side by Side”扩展时，SAP S/4HANA 套件保持不变，提供前面概述的 Clean Core 好处。

使用 SAP Build 扩展 SAP S/4HANA 

根据 SAP 最佳实践，开发扩展的首选工具是 SAP Build。作为 SAP BTP 的一部分，SAP Build 结合了 AI 增强的专业代码（ABAP、Java、JavaScript）和低代码应用程序。通过与 SAP S/4HANA 的紧密集成，它使开发人员和关键用户都能够以更高的效率为 SAP 软件创建扩展。它允许客户加速 ERP 现代化、促进创新和自动化流程——所有这些都在一个综合工具套件内。

简化 SAP S/4HANA 的扩展

使用 SAP Build 的应用程序开发和流程自动化利用前述的编程模型 CAP 和 ABAP Cloud。这些模型与 Clean Core 原则保持一致，实现可扩展、安全和稳定的扩展。

通过 Joule 的 AI 能力加速 SAP S/4HANA 的扩展

SAP Build 通过 Joule 的最新 AI 能力释放新的 ERP 效率。SAP 的 AI 副驾在业务环境中提供对话式指导。它针对 SAP 数据和流程进行了独特的训练，帮助开发人员为 SAP S/4HANA 跨 ABAP、Java、JavaScript 和低代码工具编写代码和设计工作流。作为 SAP Build 的组成部分，Joule 提高了开发人员的生产力并加速了 SAP S/4HANA 扩展的开发。

Joule 生成与 SAP 编程模型一致的高质量代码和代码解释，减少了新老开发人员的开发时间，并加速了向 Clean Core 云 ERP 的转型。

Joule 启用的 AI 能力也可用于通过低代码应用程序开发扩展 ERP。Joule 协助流程自动化，加快为 SAP S/4HANA 创建工作流并用自动化建议指导工作流审批者。

SAP Build 大厅是使用 SAP Build 启动扩展项目的中央入口点，无论是 SAP BTP 上的”体外 Side by Side”扩展开发还是”体内 On Stack”扩展开发。

根据用例，可以启动相应的开发环境，如”体内 On Stack”场景中的 ABAP 开发工具，以及”体外 Side by Side”扩展的 CAP 或 ABAP 开发工具。大厅提供许多便利功能，如监控能力和访问预构建内容以提高生产力。

3.2.3 两全其美：”体内 On Stack”和”体外 Side by Side”扩展

“体内 On Stack”和”体外 Side by Side”扩展选项通过为构建、扩展和运行企业应用提供全面的生态系统。SAP BTP 作为云服务的底层平台，为使用 ABAP Cloud、CAP 和低代码工具开发的扩展提供集成能力，每种都由其各自的集成开发环境支持。

在某些场景中，可能需要同时使用两种方法。以下是一些例子。

混合部署能力：

SAP S/4HANA 的扩展性通常遵循混合部署模型，其中一些组件保留在本地，而其他组件在云中运行。SAP BTP 支持这种混合方法，允许组织以灵活的方式部署扩展。CAP 和 ABAP Cloud 都适合基于云的开发和扩展，同时与本地 SAP S/4HANA 系统集成，帮助确保一致统一的环境。如前所述，ABAP Cloud 还通过开发人员扩展性支持体内扩展场景。 

总之，”体内 On Stack”和”体外 Side by Side”两种方法（以及两种环境中都可用的技术）在 SAP S/4HANA 的转型之旅中有效地相互补充。它们共同赋能组织高效地扩展和定制 SAP S/4HANA，从而满足不断发展的业务需求并推动数字创新。

SAP BTP 在 SAP S/4HANA Cloud 环境中的作用和好处

SAP BTP 在 SAP 云 ERP 解决方案战略中发挥重要作用。SAP S/4HANA Cloud 和 SAP BTP 密不可分，因为 SAP 正在将其创新的主要部分作为 SAP BTP 上的模块化应用程序开发，如 SAP Green Ledger、SAP 数字制造云、SAP 高级财务关帐、可持续性管理和下一代行业解决方案。SAP 遵循这一战略来加强其 Clean Core 方法：

• 核心保留所有行业都需要的基本业务流程（核心流程）。

• 差异化流程（边缘、行业、创新、下一代等）作为模块化应用程序构建在 SAP BTP 上或迁移到 SAP BTP，建立模块化云 ERP。

客户和合作伙伴应该遵循相同的战略并建立双层 IT：

• 层 1：稳定的 Clean Core 托管保持业务运行的基本核心流程，专注于流程自动化以降低成本。

• 层 2：创新层提供快节奏的创新，具有灵活性和模块化，不会破坏核心。这一层通过差异化流程来提供竞争优势，推动增长。

• 
  

SAP BTP 是稳定 Clean Core 旁边的创新层，提供显著优势：

• 它与核心 ERP 深度集成，共享底层元数据和业务模型。

• SAP S/4HANA 使用来自 SAP BTP 的服务，如 SAP BTP 的 SAP HANA 服务、SAP 集成套件、SAP AI 核心基础架构和 ABAP Cloud。

• SAP S/4HANA 中内置的扩展向导允许用户直接导航到 SAP BTP 上的扩展创建工具（参见第 4 章——"使用 SAP Build 扩展 SAP S/4HANA"）或服务中心，后者提供 API、业务 API 和远程函数调用。

• SAP Business Accelerator Hub 提供大量内置的最新内容，包括集成、连接器、API、本地化等。

• Joule 提供专门针对 ABAP Cloud 和 CAP 的 SAP 软件开发支持。

3.3 SAP 的 Clean Core 扩展性模型和 Clean Core 等级概念

3.3.1 Clean Core 等级概念

SAP 引入了 Clean Core 等级概念（类似于能效标签），使 Clean Core 更容易实现，并提高有关扩展 Clean Core 评级的透明度。扩展可以基于四个等级（A 到 D）进行标记，等级 A 是最好的，等级 D 是最差的。与关于自定义代码对象是否可以被视为"清洁"的二进制决策相比，更能反映扩展的不同质量。

SAP 建议客户始终使用 A 级扩展来增强 SAP S/4HANA Cloud 私有版。根据您的具体要求，您可能需要将 Clean Core 等级降低到"B"以实现必要的灵活性。

明确说明：仍然明确建议在等中创建扩展并基于"BTP 优先"策略。

通过优先考虑更高的 Clean Core 等级（A 优于 B 优于 C），您可以减少技术债务，简化系统升级，提高可扩展性，并与 SAP 最佳实践保持一致。这种方法确保了一个标准化、面向未来的核心系统，支持与现代技术的无缝集成，并最大限度地减少维护挑战。

同时，与早期概念相比，这种分层方法为大规模遗留扩展提供了更好的见解。这是通过在经典 ABAP 开发中提供更多透明度来实现的。为了提高您的升级稳定性，首先关注最差的扩展（等级 D）。

当扩展使用到多种技术时，其中最低等级的技术将决定其等级。例如，在一个扩展中使用了一种 A 级技术和另一种 C 级技术时，整个扩展可以被视为等级 C。

如果您有兴趣了解等级概念的更多详细信息，请在下面找到等级的简要概述，并另外参考第 3.3.4 章。

3.3.2 3 层扩展性到等级概念的演进 

SAP 从 3 层扩展性模型，转向 Clean Core 等级概念，代表了从 Clean Core 角度评估 SAP S/4HANA 内扩展性的重大进步。基于等级的方法增强了透明度，特别是在针对经典 ABAP 代码使用方面，通过在升级稳定、推荐的扩展与需要及时修复的扩展之间提供更细致的区分。因此，Clean Core 变得更容易实现。这种精细的评估框架解决了在继续使用经过验证的扩展与系统完整性和升级稳定性长期目标之间平衡的实际需要。

3.3.2.1 SAP 为什么要发展这个模型？ 

Clean Core 概念在市场中继续产生强烈共鸣。将扩展与 SAP 标准解耦以确保升级稳定性的原则被广泛认为是必要的。然而，基于 3 层扩展性模型的现行 Clean Core 指导原则相当严格。这些指导原则指导客户主要通过公开发布的 API 构建升级安全的扩展，在”体外 Side by Side”场景中使用 SAP BTP，在”体内 On Stack”场景中使用 ABAP Cloud，同时将技术和框架限制为公有云中也可用的那些。 

尽管这种方法有其优点，但许多客户环境包含大量遗留代码，甚至开发新 SAP 扩展时也经常继续使用经典 ABAP 技术。对此类场景统一的评估结果不能真实的反映升级风险。实际上，一些经典使用模式——如使用 ABAP 列表查看器 ABAP List Viewer——对升级构成的风险较小，不应被归类为"不清洁"。

作为回应，SAP 发展了其方法，为经典扩展性提供更差异化、透明的评估。更新的 Clean Core 等级概念承认部分遗留代码和部分经典开发模式下扩展的价值，同时维持通过“已发布的“API 解耦扩展的总体目标。

3.3.2.2 和过去相比，变化了什么？

通过 Clean Core 等级概念，SAP 不再将所有经典 ABAP 对象归类为高风险或与升级稳定系统不兼容。新分类引入了以下改进： 

[经典 API]：客户现在可以使用选定的经典 API，虽然不是基于最新框架构建，但被认为是不影响升级的。无需强制进行不必要的代码重写。

[不推荐使用的对象]：SAP 现在会明确标记“会带来升级挑战的”对象，帮助客户在项目早期避免风险

[内部 SAP 对象]：基于变更日志的方法使组织能够提前评估内部 SAP 对象的升级风险，在重大升级项目之前支持明智的决策制定。

3.3.2.3 和过去相比，没有改变的是什么？

Clean Core 等级概念继续保持认为通过 SAP BTP 和 ABAP Cloud 开发拓展依旧是黄金标准——等级 A——代表最清洁、最面向未来的方法。为了支持解耦的理念，SAP 推荐扩展层面的 BTP 优先策略。虽然模型现在适应某些经典 API，但核心指导保持不变：始终努力争取可用的最高等级扩展性。

3.3.3 Clean Core 等级概述

本章提供 Clean Core 等级的概述。有关每个等级的更详细信息，请参考第 3.3.4 章。

等级 A——使用 SAP Build 扩展 

• 最高等级 A 的扩展只允许通过公开发布的接口和扩展点与 SAP 标准功能交互。这些接口附带稳定性合同，确保接口的稳定性。等级 A 扩展通常遵循最新的扩展模型，可以在两个不同的扩展域中实现：

• “体外 Side by Side”：使用 SAP BTP 上 SAP Build 产品组合的全部功能——包括 AI 增强的专业代码和低代码工具，用于应用程序开发和流程自动化。

• “体内 On Stack”：在 SAP S/4HANA 系统内，通过遵循 ABAP Cloud 开发模型作为 SAP Build 产品组合的一部分，基于发布的本地 API（CDS 视图、业务对象接口、扩展点）。

等级 B——利用经典 API 

• 等级 B 扩展使用 SAP 的"经典 API"并利用经典技术和框架。

• 这些经典 API 和框架提供升级稳定、定义良好且有文档记录的扩展接触点（例如 BAPI），可以在云化存储库中找到。升级稳定性不是基于稳定性合同，而是基于 SAP 产品专家对相应 API 的提名。

等级 C——在经典 ABAP 中使用"内部对象"的条件清洁开发 

• 等级 C 的扩展超越了等级 A 和 B，还访问来自 SAP 的内部对象。

• SAP 在技术上使客户能够访问这些 SAP 内部对象，但它们未被声明为"发布"、"推荐"或"云就绪"，也未被正式发布或支持。内部 SAP 对象没有保证的文档，SAP 不保证长期稳定性或认可其使用。

• 虽然 SAP 不推荐使用内部对象，但它非常常见，特别是在遗留代码中。为了反映这一现实，SAP 引入了"SAP 对象变更日志"以提供稳定性风险的缓解路径。

• 这个 SAP 对象变更日志允许客户检查在其自定义开发中使用的内部对象是否在较新版本中发生了不兼容的变化，从而能够主动进行升级规划。

• 尽管 SAP 对象变更日志有助于缓解升级风险，但 SAP 认为使用内部对象是清洁度不高的。

等级 D——使用"不推荐"扩展选项 

• 等级 D 的扩展使用 SAP 分类为"不推荐"的对象。

• 这包括明确分类为不适合客户使用的 SAP 对象（云化存储库中的"noAPI"）。此外，它还包括修改、个别对象类型的选定使用模式（例如对 SAP 表的写访问）以及选定的扩展技术和开发模式（例如隐式增强）。

3.3.4 为什么、是什么和如何做——理解新的 Clean Core 等级 

以下章节将详细描述 SAP 认为哪些扩展技术是 Clean Core 的，以及分配给给定等级的扩展可以期待什么。

如图 5 所示，每个等级都与一个限定符相关联，指示可以使用的 SAP 对象类型。下表显示了 ABAP 测试驾驶舱如何支持 Clean Core 等级概念：

3.3.4.1 等级 A——基于发布 API 创建清洁扩展 

3.3.4.1.1 等级 A 扩展能期待什么？

等级 A 代表 SAP 扩展的最高标准，具有最大的升级稳定性。通过专门使用发布的 API 和扩展点，以及现代技术、框架和开发模式，客户确保其扩展完全符合 SAP 的 Clean Core 愿景。此等级的发布对象由 SAP 正式支持，在 SAP Business Accelerator Hub 中有良好文档记录，并受透明生命周期管理。然而，重要的是要注意，等级 A 覆盖范围不扩展到 SAP S/4HANA Cloud 私有版的完整范围，并且未来不计划全面覆盖。

3.3.4.1.2 哪些自开发扩展是等级 A 的？

当客户扩展完全基于发布的 SAP API 和扩展点构建时，符合等级 A 条件。这适用于 SAP BTP 上的”体外 Side by Side”实现（用于 CAP 和 ABAP Cloud 的 SAP Build）和直接在 SAP S/4HANA 系统内的”体内 On Stack”开发。对于 SAP BTP 上的”体外 Side by Side”开发，只有专门使用发布 API 的扩展才符合等级 A 条件。”体内 On Stack”扩展必须使用相关 ABAP 语言版本的关键用户或开发人员扩展性工具构建。

3.3.4.1.3 等级 A 在 SAP 方面包括什么？ 

等级 A 包括依赖于正式发布并受明确定义的稳定性合同管理的 SAP 对象和扩展点的扩展。发布的接口和扩展点可以在 SAP Business Accelerator Hub、通过云化存储库和直接在系统中发现。

3.3.4.1.4 特殊视角：等级 A 扩展和对 SAP S/4HANA Cloud 公有版的期望 

等级 A 严格依赖现代扩展技术，与 SAP S/4HANA Cloud 公有版的开发方法本质上一致。然而，由于范围和代码库的差异，为 SAP S/4HANA 私有版创建的”体内 On Stack”扩展通常无法在不进行适配的情况下移植到公有云。

相比之下，在 SAP BTP 上开发的”体外 Side by Side”扩展更有可能在没有更大适配努力的情况下兼容，作为私有到公有云转换的一部分。原因：它们本质上将业务逻辑与核心系统解耦。然而，不保证完全一致性：API 可用性和应用程序范围在 SAP S/4HANA 版本之间可能不同（例如，行业特定解决方案在公有云中可能没有等效项）。

3.3.4.2 等级 B：使用经典 API 

3.3.4.2.1 等级 B 扩展能期待什么？ 

等级 B 扩展解决了仅使用对外暴露的 API 无法满足的需求。在此等级，客户依赖"经典 API"和扩展点。这意味着它们是成熟的、广泛推荐的，并由 SAP 持续记录和管理。虽然这些对象不受正式稳定性合同管理，但它们在 SAP S/4HANA 和 SAP ERP 环境中有着长期可靠使用的历史。与等级 A 相比，等级 B 为流程增强和定制提供了显著更广泛的灵活性，同时仍然遵循 SAP 升级稳定性的最佳实践。此等级的扩展受益于 SAP 的内部质量保证流程，代表了扩展核心能力的经过验证的低风险选项。

3.3.4.2.2 哪些客户扩展是等级 B？ 

当客户扩展仅使用正式分类为经典 API 或发布 API 的 SAP 对象和开发模式时，符合等级 B 条件。这包括各种扩展场景，如： 

• 基于经典 API 的包装器，以便向外暴露后，在等级 A 应用中使用——例如，利用 BAPI_PO_CREATE1 与转移订单流程集成。 

• 经典 ABAP 扩展，如在 Dynpro（SAP GUI）或 Web Dynpro 环境中的 ABAP 列表查看器实现，使用经典 API 如 CL_GUI_ALV_GRID。

• 使用 ABAP 语言版本"标准"开发的自定义对象，如果它们不引用受限或不支持的 SAP 对象。

等级 B 扩展通过遵循经过验证的开发实践和使用专门为客户使用而设计的扩展机制，保持了很大程度的升级稳定性 

3.3.4.2.3 等级 B 在 SAP 方面包括什么？ 

在 SAP 方面，等级 B 包括已被 SAP 专家明确提名为经典 API 的对象和扩展点，尽管不受正式稳定性合同覆盖。这些包括广泛的遗留 API、用户出口、BAdI 和已建立的框架——如 SAP GUI 和 ABAP 列表查看器网格 ABAP List Viewer grid——这些已被故意暴露给 SAP S/4HANA 本地和 SAP ERP 中的客户使用。这些技术成熟、广泛采用，并因在按推荐使用时一般不引入升级问题而得到认可。在“已发布”API 不可用的情况下，经典 API 和扩展点提供了次优扩展选项。

识别经典 API 以及扩展技术和框架的关键资源是云化存储库和 SAP Note 3578329，用于框架分类。

3.3.4.3 等级 C：使用内部对象 

3.3.4.3.1 等级 C 扩展能期待什么？ 

等级 C 扩展是指客户使用未分类，或不打算供客户使用的 SAP 内部对象的场景。这些内部对象既不正式发布、推荐或云就绪，也不属于 SAP 的正式支持范围。这些对象的文档可能不完整或缺失，SAP 不提供长期稳定性或使用保证。虽然这些扩展提供了超越等级 A 和 B 的技术灵活性，但它们在未来升级稳定性方面构成了显著风险。然而，通过新的 SAP 对象变更日志，客户将能够在等级 C 对象受到不兼容变更时主动分析和规划潜在的升级影响。

3.3.4.3.2 哪些客户扩展是等级 C？

当客户扩展使用既不正式发布（等级 A）也不被提名为成熟（等级 B）的对象或开发模式时，属于等级 C。典型示例包括直接使用内部功能模块、类或对未认可被消费的 SAP 表的读访问。这些扩展通常解决更高级别 API 未涵盖的特定客户需求，但本质上承载着未来不兼容的风险，缺乏与推荐扩展点相关的保证。

3.3.4.3.3 等级 C 在 SAP 方面包括什么？ 

等级 C 包括未被指定为发布（参见等级 A）、提名为经典 API（参见等级 B）或明确分类为不推荐（参见等级 D）的广泛 SAP 对象集。

默认情况下，所有 SAP 对象都被视为内部的，可能在没有通知或兼容性保护的情况下发生变更。某些使用模式，如对 SAP 表的只读访问，仍可能属于等级 C，前提是它们不违反 SAP 的扩展政策。重要的是，SAP 可能将内部对象重新分类为经典 API 或不推荐对象，这将导致等级重新分配（到等级 B 或 D）。此类变更通常由客户反馈、发展的产品策略或观察到的升级挑战驱动，强调了等级 C 的流动性质。

3.3.4.3.4 特殊视角：SAP 对象变更日志方法 

为了增强透明度并帮助客户管理 C 级拓展的风险，SAP 引入了 SAP 对象变更日志。这一机制将主动识别在即将发布的 SAP S/4HANA Cloud 私有版中面临不兼容变更的 SAP 内部对象。这样，客户可以在升级事件之前充分规划重构工作，以缓解与使用 SAP 内部对象相关的风险。

SAP 对象变更日志的关键功能包括：

• 自动 ABAP 测试驾驶舱检查，分析自定义代码并检测所引用 SAP 对象的不兼容变更和删除

• 提前访问有关影响内部对象的未来不兼容变更的信息

• 提高规划可靠性和透明度，促进及时的资源分配并减少升级项目延迟

• 变更日志中列出的对象不会自动降级为"不推荐"。根据变更的范围和关键性，可能仍然允许继续使用。然而，应该鼓励开发人员基于变更日志在可行的情况下将扩展重构为发布或经典 API。通过采用 SAP 对象变更日志作为其 Clean Core 之旅的一部分，客户可以显著最小化升级风险，实现主动变更管理，并确保跨 SAP 软件版本的更平滑过渡。

3.3.4.4 等级 D：非 Clean Core 

3.3.4.4.1 等级 D 扩展能期待什么？ 

等级 D 代表 Clean Core 等级概念中最关键的风险类别，并可能带来最高程度的技术债务。此类别的扩展使客户面临多重风险和重大维护工作，无论是在升级期间还是在日常操作中。它们可能危及系统稳定性、数据完整性和业务敏捷性，由于持续的兼容性挑战而可能阻碍创新。因此，应该优先立即移除或重新编写等级 D 扩展。强烈建议立即修复，以重新与 SAP 的支持指导原则保持一致，并确保长期运营可靠性。

3.3.4.4.2 哪些客户扩展是等级 D？

所有依赖 SAP 明确标记为不推荐的 SAP 对象或开发模式的客户扩展都属于等级 D。典型示例包括修改、扩展，包括 unsupported write operations on SAP tables, 隐式增强 implicit enhancements，或任何使用 objects designated as out-of-scope for customer consumption 的尝试。

3.3.4.4.3 D 级拓展在 SAP 方面包括什么？ 

在 SAP 方面，D 级拓展包括所有已被正式声明为“不推荐外部使用”的对象和模式。这包括标有"noAPI"标识的对象，可以通过过滤"状态"设置为"noAPI"在云化存储库中轻松识别。此外，等级 D 涵盖修改、某些对象使用模式（如对 SAP 核心表的直接写访问）以及不鼓励的开发技术如隐式增强 implicit enhancements。不鼓励使用的对象和模式的综合列表为客户提供必要的透明度，以识别并系统地从其 SAP 环境中消除这些高风险元素。

文章整理：Arthur Yang

文章来源：https://mp.weixin.qq.com/s/6FqFXr5GCDNyTKdNp6D22w