本文内容主要来自Clean core extensibility白皮书
SAP发现企业在实施定制化拓展时往往遇到很多问题，包括但不限于：标准功能是否满足需求，有哪些拓展方式是可选的，不同方式可以达成什么样的效果，未来该如何维护这些拓展才能保证持续的创新能力等等。
所以SAP推出了Clean Core方法论，为组织在拓展核心IT系统时提供指导意见，帮助组织打造一个清洁的核心。
清洁核心方法论下又包含了五个维度的清洁，分别是业务流程/拓展/数据/集成/运营 维度的清洁性，本白皮书主要关注拓展层面的清洁核心原则
如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容
白皮书内容较多，章节1，2的内容见Link
本文包含了章节3的内容，主要介绍Clean Core原则，重点关注扩展性选项，包括”体内On Stack”和”体外Side by Side”模型、Clean Core等级概念以及合作伙伴解决方案的一致性。
3.Clean Core对扩展性的意义
3.1 Clean Core 5大指导原则中的扩展性
Clean Core是指一套方法论，通过培育敏捷、创新和高效的ERP系统来支持持续的业务转型。这些原则专注于构建韧性的业务流程和扩展，由无缝的集成、高效的运营和高质量的数据支持。每个原则都有特定的目标和关注领域。
业务流程目标：在降低复杂性的同时保持竞争力。关注点：简化和标准化流程以保持敏捷性，同时避免过度定制核心。 扩展性目标：将扩展与标准解耦。关注点：使用SAP Build实现”体内On Stack”和”体外Side by Side”扩展性，使关键用户和开发人员能够在不修改SAP核心的情况下进行定制，确保更容易的升级和更好的可维护性。数据目标：根据最新标准控制数据。关注点：确保数据被治理并符合当前标准，以获得更好的质量、安全性和集成。集成目标：保持环境可靠和灵活。关注点：使用发布的API和现代集成概念（例如，基于事件的集成）连接系统，而不产生损害灵活性的依赖关系。运营目标：保持运营有效和高效。 关注点：简化系统管理，在需要的地方实现自动化，并确保以最少的人工工作实现高可用性和性能。
虽然本白皮书主要关注扩展性，但清洁的拓展与其他指导原则密切相关。例如，创建合规扩展需要业务流程的清晰治理。
通过突出这些相互依赖性——比如高效的业务流程如何实现更好的扩展性，或扩展性工具如何与运营框架保持一致——清楚地表明每个原则都加强了其他原则。它们共同构成了灵活和可持续的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”以实现必要的灵活性。
明确说明：仍然明确建议在等级A中创建扩展并基于“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注释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环境中消除这些高风险元素。
3.4 合作伙伴附加组件和Clean Core
合作伙伴附加组件是SAP Clean Core战略的组成部分，提供专业知识以增强系统架构，同时最大限度地减少定制。这些解决方案通过利用SAP认可的技术开发，确保它们与Clean Core原则保持一致，并有助于维护简化的系统环境。通过整合合作伙伴解决方案，SAP可以在不破坏核心流程的情况下扩展功能。SAP集成和认证中心（SAP ICC）为符合SAP Clean Core扩展性标准的合作伙伴扩展提供开放认证计划，如博客“遵循Clean Core的合作伙伴解决方案认证“中所述。通过这个计划，合作伙伴可以向SAP客户展示Clean Core兼容性并获得官方标识：SAP S/4HANA Cloud Clean Core SAP认证。
3.4.1 SAP解决方案扩展
SAP S/4HANA Cloud私有版上的SAP解决方案扩展已经经SAP进行了彻底审查，并确认这些解决方案满足所需的Clean Core合规标准。
关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果时间紧迫，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间
本文内容主要来自Clean core extensibility白皮书SAP发现企业在实施定制化拓展时往往遇到很多问题，包括但不限于：标准功能是否满足需求，有哪些拓展方式是可选的，不同方式可以达成什么样的效果，未来该如何维护这些拓展才能保证持续的创新能力等等。所以SAP推出了Clean Core方法论，为组织在拓展核心IT系统时提供指导意见，帮助组织打造一个清洁的核心。清洁核心方法论下又包含了五个维度的清洁，分别是业务流程/拓展/数据/集成/运营 维度的清洁性，本白皮书主要关注拓展层面的清洁核心原则 如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容 白皮书内容较多，章节1，2的内容见Link本文包含了章节3的内容，主要介绍Clean Core原则，重点关注扩展性选项，包括”体内On Stack”和”体外Side by Side”模型、Clean Core等级概念以及合作伙伴解决方案的一致性。 3.Clean Core对扩展性的意义 3.1 Clean Core 5大指导原则中的扩展性Clean Core是指一套方法论，通过培育敏捷、创新和高效的ERP系统来支持持续的业务转型。这些原则专注于构建韧性的业务流程和扩展，由无缝的集成、高效的运营和高质量的数据支持。每个原则都有特定的目标和关注领域。业务流程目标：在降低复杂性的同时保持竞争力。关注点：简化和标准化流程以保持敏捷性，同时避免过度定制核心。 扩展性目标：将扩展与标准解耦。关注点：使用SAP Build实现”体内On Stack”和”体外Side by Side”扩展性，使关键用户和开发人员能够在不修改SAP核心的情况下进行定制，确保更容易的升级和更好的可维护性。数据目标：根据最新标准控制数据。关注点：确保数据被治理并符合当前标准，以获得更好的质量、安全性和集成。集成目标：保持环境可靠和灵活。关注点：使用发布的API和现代集成概念（例如，基于事件的集成）连接系统，而不产生损害灵活性的依赖关系。运营目标：保持运营有效和高效。 关注点：简化系统管理，在需要的地方实现自动化，并确保以最少的人工工作实现高可用性和性能。 虽然本白皮书主要关注扩展性，但清洁的拓展与其他指导原则密切相关。例如，创建合规扩展需要业务流程的清晰治理。 通过突出这些相互依赖性——比如高效的业务流程如何实现更好的扩展性，或扩展性工具如何与运营框架保持一致——清楚地表明每个原则都加强了其他原则。它们共同构成了灵活和可持续的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”以实现必要的灵活性。明确说明：仍然明确建议在等级A中创建扩展并基于”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注释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环境中消除这些高风险元素。3.4 合作伙伴附加组件和Clean Core 合作伙伴附加组件是SAP Clean Core战略的组成部分，提供专业知识以增强系统架构，同时最大限度地减少定制。这些解决方案通过利用SAP认可的技术开发，确保它们与Clean Core原则保持一致，并有助于维护简化的系统环境。通过整合合作伙伴解决方案，SAP可以在不破坏核心流程的情况下扩展功能。SAP集成和认证中心（SAP ICC）为符合SAP Clean Core扩展性标准的合作伙伴扩展提供开放认证计划，如博客”遵循Clean Core的合作伙伴解决方案认证”中所述。通过这个计划，合作伙伴可以向SAP客户展示Clean Core兼容性并获得官方标识：SAP S/4HANA Cloud Clean Core SAP认证。 3.4.1 SAP解决方案扩展SAP S/4HANA Cloud私有版上的SAP解决方案扩展已经经SAP进行了彻底审查，并确认这些解决方案满足所需的Clean Core合规标准。 关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果时间紧迫，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间 Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
