在过去的几个月里，我在一系列的四篇博文中分享了我们建立中央空中交通管制系统的步骤：

第1部分：搭建舞台

第2部分：准备系统

第3部分：根据我们的喜好调整设置

第4部分：最后一段

第5部分：关注事情（2019年1月）

同时收集我的想法，准备在DSAG的ABAP上进行计划中的演示在开发者小组会议上，我草草记下了我们各种活动的大致日期，最后写下了一堆个人笔记。我不想仅仅用这些来建立一个演讲的时间表，我想在它们的基础上写一篇博客文章来详细描述我们从头到尾的旅程可能会很有用。

是的，我用德语记下这样的笔记！

那么，让我们从这条漫长蜿蜒的道路开始吧….

曾经在2016年冬天的一个寒冷而沉闷的日子….

不，把它擦掉，我不知道天气是什么样的，也不知道是哪一天我第一次看到Olga Dolinskaja的博客文章"ATC中的远程代码分析-一个中央检查系统，用于各种版本的多个系统"。我只知道它是在2016年12月16日之后，因为这是奥尔加出版它的日期。但我清楚地记得，物联网解决方案，我很快就迷上了安装这样一个系统的想法，因为它对我来说非常有意义。不过，不用说，这一年太晚了，没法把它列入当年的圣诞愿望清单！

开始了向S/4HANA迁移的概念验证，大数据有什么用，但很快就发现，首先转换为HANA-DB更有意义。然而，我们为PoC提供的沙盒系统使我们能够获得比ERP系统更好的ATC功能。说来刺激我的食欲！

计划在2017年晚些时候升级到HANA DB，智慧农业物联网系统，那时我已经在我们的开发系统中尝试了一些检查变体和ATC。所以我决定继续我所拥有的，定义一个增强的检查变体，把代码检查器（SCI）和ABAP测试驾驶舱（ATC）的一些信息放在一起给我们的开发人员，并在我们的指南中提供所有这些信息（我们将这些信息放在一个合流空间中，以便于访问和维护）。

我还将ATC检查添加到运输发布期间已经执行的SCI检查中。这样做的目的主要是让开发人员接触到这些新的工具。

在我们的指南网页上发布的公告

在Smartshift的帮助下，我们调整了我们的自定义代码，以转换为HANA-DB，这是使用EHP8升级到NW 750的一部分。

我们最初的计划是打开阻塞在升级后不久，ATC的运输放行会进行检查，以避免"HANA关键"代码离开开发人员系统。但是，结果证明这是不可行的，因为我们还没有创建一个基线作为NW 750的一个选项。而且，即使在为HANA-DB做准备时修改了代码，我们也知道我们会让开发人员对ATC发现的长长的列表非常不满意，因为他们实际上没有接触到他们的最新更改！所以，我们暂时搁置了那个计划。但是，这给了我们第一个很好的理由，真正开始考虑建立一个中央空中交通管制系统！

朝着S/4HANA方向前进的计划再次开始成形，随着S/4HANA准备就绪检查的需要，我们还不能用NW 750做其他事情。因此，我们有第二个很好的理由建立我们自己的中央空中交通管制系统。

很明显，我们等待启动的时间越长，由于HANA关键代码未被发现而发生可预防问题的可能性就越高。

在得到管理层的批准后，我们开始了一个项目安装我们自己的中央空中交通管制系统。耶！随着项目的批准，我开始期待在不远的将来拿到这个系统。

来源：Wikimedia（CC）

通过阅读Olga的博客文章，我知道要正确配置ATC系统需要完成很多任务。为了不迷失方向，自助建站系统哪个好，我开始在中央存储库中收集信息。这包括到上述博客文章的链接、相关的OSS笔记、SAP社区讨论线程以及任何我能掌握的技巧和窍门。

为了让我们的开发人员一路顺风，我为一个初始研讨会准备了一个演示文稿，让他们第一眼看到今年晚些时候将要发生的事情。由于我们还没有中央空中交通管制系统，这次首次聚会主要依靠幻灯片和讨论。你可以在我的博客系列的第一部分阅读更多关于设置舞台的细节。

这个系统是由我们的服务提供商在7月份交付的，Alexander Merz做了基本的定制来启动和运行。接下来，他把我们的一个沙盒系统连接到新的ATC系统上，那里也需要应用一些OSS注释。这些活动的细节在我的博客系列的第2部分中有描述。

在8月份，当我们将我们的开发系统连接到中央ATC系统时，发生了很多事情，从沙箱复制了设置，定义了基线和中央检查变量，以便在传输发布期间使用。我还开始每天对dev系统中可修改的传输进行ATC检查，以便更好地处理事情的样子，并帮助调整消息优先级。我的博客系列的第3部分有详细内容。