简介

在客户环境中，我们几乎没有在本地SAP HANA环境中移动开发对象的选项。

它们是手动导出导入（不推荐）、本地HANA传输或增强的更改和传输系统（增强的CTS或CTS+）。

相比之下，CTS主要用于ABAP和非HANA环境，增强型CTS或CTS+可以支持非ABAP SAP环境的升级管理（HALM和CTS一起工作；这就像将仍由HALM管理的开发对象移交给CTS一样）。

在已经存在的生产环境中实施增强型CTS解决方案时，很少遇到问题。这基本上意味着，增强的CTS实施是通过使用其他一些选项来完成之前的促销活动的。

增强的CTS传输方法还使用本机SAP HANA的HALM（HANA应用程序生命周期管理）工具来收集作为交付单元（DU）或DU内单个（已发布）变更列表的更改对象。如果你想了解更多关于哈姆的知识，关于大数据，请参阅下面的博客HANA对象的HALM传输

一旦对象被收集，它们将被移交给CTS+传输系统，以便可以在目标系统中作为正常的SAP传输请求导入更改。

本机HANA传输和增强的CTS之间的一个主要区别是，对于本机SAP HANA传输，执行导入意味着您在目标系统上，并且使用配置的传输路由从源系统提取导出。因此，生产系统中的每次导入都会触发从测试系统的单独导出。

现在，如果您有多个生产系统，您必须确保在生产系统中执行导入时测试系统保持不变。

与此不同，使用增强的CTS，您创建了一个可供导入的传输进入多个目标系统。因此，使用增强型CTS，每日返利，除了帮助非ABAP对象传输支持之外，免费大数据，您还可以使用经验证的CTS机制，该机制可以捕获更改并在多个导入的传输请求中可用（如果需要）。

图：CTS+中的通用ABAP和非ABAP对象传输机制

图：增强型CTS，高级流程概述

第一个问题：

我们在客户实施增强型CTS时遇到的问题很少，因为与许多其他初始客户环境一样，我们的计划是保持系统开放，不进行更改跟踪，直到确定传输机制的最佳方法。因此，当客户需要实现增强的CTS时，许多开发对象已经在生产中，业务依赖于它们。在实施变更方法时，我们必须考虑到这一点，因为我们不希望将开发对象完全重新传输到生产中，因为由于持续的开发，两个系统之间存在版本差异。问题是，如何确保生产对象（版本）不被当前开发对象覆盖，同时将环境置于CTS+之下？

第二个问题：

这是由于SAP HANA环境从HANA 1.0 SPS 12升级到HANA 2.0 SPS 03，这意味着系统也从单一数据库容器移动到多数据库容器。这不会引起什么问题，因为有两组表可用于管理CTS+。首先是存储库表，如CHANGES、CHANGE\u ENTRIES、CHANGE\u CONTRIBUTORS、PACKAGE\u CATALOG等，以及HALM表。由于源系统名称（ID）从SDC中的名称更改为MDC中的名称，这将影响对象从源系统传输到目标系统的方式。

如何确保不再发送完整的DU，需要考虑两件事。首先，已经发送到目标系统的对象；其次，源系统名称已更改。

下面我提供了我们在客户项目中如何处理这两个问题。

问题：

在现有SAP HANA生产环境中实施增强的CTS

当生产环境中的系统之间有不同版本的开发对象时，在使用HANA开发对象的导出和导入之前手动管理对象的情况下，使用标准流程实现增强CTS并不容易。

正常流程，在使用增强CTS实现启用更改跟踪后，第一次创建基本更改列表，包含传递单元中的所有对象（映射到HANA内容中的包），尽管用户仅为更改选择了一个对象。这是基本变更列表的创建，因为这是第一次将变更发送到HALM已知的目标系统。（忽略之前发生的所有导出和导入）。如果传输，目标系统中的所有更改都将被删除，并将替换为源系统的当前版本（可能，开发系统就是源系统）。

我们的景观已经在生产中，与已经转移到测试或生产中的对象相比，有些对象是开发中的较新版本。当然，没有人希望删除这些内容，并用开发系统中对象的当前版本替换它们。

下面是我们如何处理该场景。

解决方法：

目标是使源系统和目标系统在DU级别同步，同时，不要像当前版本中的对象那样丢失它们目标系统。需要同步，因为一旦发生这种情况，将基本变更列表从源传输到目标，下一次传输将只带来自上次传输以来的差异或增量更改（包括所需的前置任务，如果有的话）。

首先将目标系统中的所有对象备份到SAP HANA中的本地备份。其次，在源系统HALM中，创建并释放Changelist，将Changelist附加到传输请求（这里需要更好的注意，一般来说，如果选择DU而不是"Released Changelist"，它将始终用DU的完整传输覆盖目标系统的包），并将该传输导入目标系统。您将第一次看到预期的"发布的变更列表"和"基本变更列表"。