了解 Clean Core 可扩展性最佳实践

学习目标

  • 探索 clean core 可扩展性最佳实践。

第一代：3 层可扩展性模型（现在停用）

原始 3 层可扩展性模型（现在停用）为客户提供决定如何实施扩展的框架。建议使用第 1 层（基于 ABAP Cloud）和第 2 层（云 API 启用）。仅在绝对必要时使用第 3 层（经典）。

虽然原始的 3 层可扩展性模型现已停用，但支持基于新级别的 clean core 概念，本部分将简要介绍，因为它有助于掌握向基于新级别的方法的演变。此外，在原始 3 层指南（尤其是第 2 层包装器）下设计和实施的客户代码不一定需要迁移到基于新级别的方法。

原始基于层级的客户扩展开发方法主要围绕以下三个层级：

  • 第 1 层（ABAP 云）： 首选、面向未来且升级安全的方式。针对所有新开发。使用受限制的云优化 ABAP 版本，并且只能访问已发布的 SAP API。

  • 第 2 层（云 API 启用）： "桥梁"。用于包装现有自定义代码（来自第 3 层）或尚未针对第 1 层发布的标准 SAP 对象。其目的是创建一个稳定的可重用 API，供第 1 层使用。

  • 第 3 层（传统 ABAP）： "传统"或传统方式。对于现有代码和深层扩展，在第 1 层中无法实现。此代码与系统紧密耦合，在升级时可能会出现问题，因此建议将其用作最后手段。

虽然这种方法创建了一个框架，客户可以实际使用，但它已经停用，支持一种不断演进甚至更灵活的方法。

第二次生成：Clean Core 级别概念

演变：从灵活的方法到更加灵活的方法

演变：从灵活的方法到更加灵活的方法

最初，"Clean Core"消息通常被视为二进制、全无原则："要么干净要么不是"。尽管这种方法虽然有效，但仍然给客户带来了一些挑战，尤其是在某些 API 虽然没有正式发布"时"是相当稳定的，并且不太可能在升级场景中引起问题。此外，作为一个实际问题，希望客户简单地放弃所有现有的自定义代码是不现实的。

认识到这一点，SAP 已经对 3 层模型进行了演变，以包含一种基于更实用的方法（基于级别），使客户能够灵活地采用更多基于风险的方法来管理自定义代码。此方法承认并非所有扩展都是平等的，并为开发人员和架构师提供了清晰、结构化的框架。它将 clean core 可扩展性从严格规则转换为更多可操作的路线图。

Clean Core 可扩展性模型概览

clean core 可扩展性模型旨在提高 SAP S/4HANA 扩展中的透明度并减少技术债务。它通过以下方式执行此操作：

  • 更灵活的 clean core 级别概念，具有四个级别（A 到 D），其中级别 A 是最高质量。

  • 鼓励客户尽可能地扩展 SAP S/4HANA Cloud Private Edition。

  • 提高 clean core 级别可以减少技术债务，简化升级，并与 SAP 卓越实践保持一致。

  • 扩展根据其中使用的最低等级技术进行评估。

Clean Core 级别概念如何为客户增强可扩展性选项？

从 3 层可扩展性模型到 clean core 级别概念的转换通过三种主要方式增强了可扩展性的评估：

  • 实用性分类： 新的基于级别的方法对升级稳定且有风险的扩展进行了细致区分。

  • ABAP Classic： 传统 ABAP 对象不再统一分类为高风险，从而实现更灵活的评估。

  • 双领域优势： clean core 级别概念承认传统代码和现代扩展的价值，同时促进解耦

那么，这些水平是如何运作的？

clean core 级别根据扩展是否符合 SAP 的升级稳定性标准对其进行分类。

  • 级别 A 扩展使用 已发布的 API 并完全受 SAP 支持，从而确保最高的升级稳定性。

  • 级别 B 扩展利用 经典 API 和技术，为增强提供更广泛的范围。

  • 级别 C 扩展访问 内部对象， 产生（可管理）风险并允许满足特定客户需求。

  • 级别 D 扩展使用 非推荐对象， 表示最高风险和技术债务。

我们来探索一下这些概念。

新的分类系统

上一段突出显示了用于分类 ABAP 对象的完整术语集：

  • 已发布 API： 客户和合作伙伴用于构建扩展的稳定、支持和安全 按设计升级安全。

  • 经典 API： 虽然不是基于最新框架构建的经典 ABAP 部件，但会被识别为安全升级，并如此分类。

  • 内部对象： 未分类为"经典 API"的部件。借助基于变更日志的方法，组织可以提前评估"内部对象"的升级风险，从而在重大升级项目之前制定明智的决策。

  • 非推荐对象： 已知用于引入升级挑战的部件，帮助客户在项目早期避免风险扩展

级别 A：清理基于已发布 API 的扩展

级别 A：清理基于已发布 API 的扩展

  • 级别 A 概览：

  • SAP 可扩展性的最高标准。

  • 确保面向未来的解决方案，最大限度地提高升级稳定性。

  • 使用已发布的 API、扩展点、现代技术、框架和开发模式。

  • 与 SAP 的 clean core 愿景保持一致。

  • 覆盖范围：

  • 仅包含基于已发布的 SAP API 和扩展点构建的扩展。

  • 同时适用于 SAP BTP（面向 CAP 和 ABAP Cloud 的 SAP Build）上的并排实施和 SAP S/4HANA 系统中的堆栈内开发。

  • 堆栈内扩展必须使用具有相关 ABAP 语言版本的关键用户或开发人员可扩展性工具。

  • 不涵盖 SAP S/4HANA Cloud Private Edition 的完整范围。

  • SAP 参与：

  • 扩展依赖于稳定性合同管理的正式发布的 SAP 对象。

  • 接口和扩展点可以在 SAP Business Accelerator Hub、云化资源库中找到，并直接在系统中找到。

  • SAP S/4HANA Cloud Public Edition

  • 级别 A 与 SAP S/4HANA Cloud Public Edition 的开发方法一致。

  • 为 SAP S/4HANA（专用版）创建的堆栈内扩展通常需要调整才能移植到公共云。

  • SAP BTP 上的并排扩展更有可能与公有云兼容，因为它们将业务逻辑与核心系统分离。

  • 由于 SAP S/4HANA 版本之间的 API 可用性和应用程序范围存在差异，因此无法保证完全对等。

级别 B：使用经典 API

级别 B：使用经典 API

  • 级别 B 概览：

  • 仅解决已发布 API 未满足的要求。

  • 利用成熟的、广泛推荐且全面记录的"经典 API"。

  • 与级别 A 相比，为流程增强和定制提供更广泛的范围。

  • 遵循 SAP 的升级稳定性最佳实践。

  • 扩展功能受益于 SAP 的内部质量保证，代表低风险选项。

  • 资格：

  • 当扩展仅使用分类为经典 API 或已发布 API 的 SAP 对象和开发模式时，这些扩展符合级别 B 的条件。

  • 其中包括：

  • 围绕经典 API 进行包装以便于在级别 A 应用程序中使用（例如，使用 BAPI_PO_CREATE1）。

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

  • 使用 ABAP 语言版本"标准"开发的自定义对象，不参考受限制或不受支持的 SAP 对象。

  • 级别 B 扩展通过遵循久经验证的开发实践保持高度的升级稳定性。

  • SAP 参与：

  • 包含由 SAP 专家明确指定为经典 API 的对象和扩展点，尽管缺少正式的稳定性合同。

  • 包括各种传统 API、用户出口、业务加载项和已建立的框架，例如 SAP GUI 和 ABAP 列表查看器网格，这些框架在 SAP S/4HANA 企业预置和 SAP ERP 中公开供客户使用。

  • 如果发布的 API 不可用，经典 API 和扩展点将提供下一个最佳可扩展性选项。

  • 用于识别经典 API 和扩展技术的关键资源是云化资源库（在下一课中介绍）。

级别 C：使用内部对象

级别 C：使用内部对象

  • 级别 C 概览：

  • 涉及使用并非供客户使用的 SAP 内部对象。

  • 这些对象未正式发布、推荐或云就绪，并且不在 SAP 正式的支持范围内。

  • 文档可能不完整或不存在，没有长期稳定性或使用保证。

  • 提供高级技术功能，但会对未来的升级稳定性造成风险。

  • SAP 对象的新更改日志允许客户分析和计划潜在的升级影响。

  • 资格：

  • 使用既未正式发布（级别 A）也未提名为成熟（级别 B）的对象或开发模式时，扩展将落入级别 C。

  • 例如，直接使用内部功能模块、类或对未背书供外部使用的 SAP 表的只读访问。

  • 这些扩展满足了更高级别 API 未涵盖的特定客户需求，但存在未来不兼容的风险。

  • SAP 参与：

  • 涵盖未指定为已发布或经典 API 且未明确分类为不推荐的 SAP 对象。

  • 内部对象如有更改，恕不另行通知或保证兼容性。

  • SAP 可以将内部对象重新分类为"经典 API"或"不推荐"，从而将级别分别移动至 B 或 D。

  • 这些变化由客户反馈、不断变化的产品策略或观察到的升级挑战驱动。

  • SAP 对象的更改日志：

  • 引入以提高透明度并支持客户管理级别 C 风险。

  • 功能包括：

  • 自动化 ABAP 测试主控室检查以分析自定义代码并检测不兼容的更改。

  • 提前访问有关未来不兼容更改的信息。

  • 提高计划可靠性和透明度，以便及时分配资源。

  • 鼓励开发人员尽可能重构已发布或经典 API 的扩展。

  • 采用变更日志有助于最大限度地降低升级风险，实现主动变更管理，并确保 SAP 软件版本之间的更顺畅转换。

级别 D：非 Clean Core

级别 D：非 Clean Core

  • 级别 D 概览：

  • 表示 clean core 级别概念中的最高风险类别。

  • 与重大技术债务、维护工作量和系统稳定性、数据完整性和业务敏捷性风险相关。

  • 因兼容性挑战而破坏创新。

  • 强烈建议立即进行修复，以便与 SAP 的支持指南保持一致，并确保长期运营可靠性。

  • 资格：

  • 使用显式标记为不建议的 SAP 对象或开发模式时，扩展将落入级别 D。

  • 示例包括：

  • SAP 表上的修改、扩展和不支持的写入操作。

  • 隐式增强。

  • 指定为超出客户使用范围的对象的利用率。

  • SAP 参与：

  • 包含所有正式声明为不建议外部使用的对象和模式。

  • 包括标记为"noAPI"标记的对象，可通过过滤"state"设置为"noAPI"在云化资源库中识别。这将在以下练习中演示。

  • 涵盖修改、某些对象使用模式（例如对 SAP 核心表的直接写入访问）和不鼓励的开发技术（如隐式增强）。

  • 通过不鼓励的对象和模式的综合列表提供透明度，帮助客户识别并消除其 SAP 架构中的这些高风险元素。

使用云化资源库查看器的对象搜索功能

练习：开始练习（SAP 官方交互式练习）