3

从自定义代码的角度来看，我正在计划在迁移到本地 S/4 HANA 期间要执行的操作。到目前为止，中央 ATC 已设置为验证当前的 SAP ECC 代码，我们已经可以在迁移之前在 ABAP 代码中实施大部分修复。

下一步是 Basis 团队使用 SUM 进行系统升级。他们告诉我，我必须在 SPAU 中实施其余的调整和修复，但据我所知，SPAU 仅用于调整使用“访问密钥”修改并在升级期间发生更改的标准 SAP 对象。

我之前为较小的升级做过 SPAU，情况就是这样，当然数据模型没有改变，标准对象也没有像 S/4 HANA 升级那样被弃用。

然后是 SPAU_EHN，用于可能受到升级期间标准对象更改影响的自定义增强功能。

但是当涉及到 ABAP 对象的其余部分时，假设是一个完全独立的自定义程序、一个 Z 功能模块、自定义类等。对这些对象的调整是 SPAU 的一部分，还是我认为它们已经是 SPAU 的一部分？升级完成后要执行的手动活动？

我关于调整自定义对象的顺序的想法如下：

  1. 通过 ATC 验证调整当前 ECC 中的一切可能
  2. [基础] 使用 SUM 升级系统
  3. 如有必要，在 SPAU 中调整修改后的标准对象
  4. 如有必要，调整 SPAU_ENH 中的增强功能
  5. 完整的升级过程
  6. 使用 Fiori Migration App、Quick Fixes 等调整其余的自定义存储库对象，直到列表归零。

按照这个顺序，我将在第 3 步和第 4 步中使用 1 个传输请求，然后在第 6 步中使用尽可能多的传输请求。

4

1 回答 1

1

你是对的。进行 S/4 迁移的常用方法是先进行升级，然后再进行自定义代码迁移。

首先使用 SUM 升级系统，然后使用 SPDD、SPAU 和 SPAU_ENH 修复标准修改和升级之间的任何冲突。但这些事务只关心您修改过的 SAP 标准代码，然后在此升级期间又被 SAP 修改。他们忽略了对升级期间未触及的对象的修改，他们当然不关心 Z* 和 Y* 命名空间中的任何内容。

因此，在技术升级完成后，您将拥有一个充满客户代码的 S/4 系统，由于它不符合 S/4 标准，因此该系统已损坏且存在漏洞。

现在，您使用 ATC 及其与 ABAP Development Tools for Eclipse 的集成来查找自定义代码中所有损坏的部分并修复它们。根据您在系统中拥有多少自定义代码、编写和记录的质量以及与更改的功能的交互程度如何，这项工作需要几天到几个月的时间。这不像您通常在 SPAU 和解中所做的那样自发地进行并且几乎没有计划。

有关该程序的更多信息，请参阅SAP 的官方指南。

于 2020-07-10T14:59:24.847 回答