在这个小系列的第1部分，每日返利，服务器和云服务器，我描述了为什么我们决定建立一个中央空中交通管制系统，以及我们最初采取的步骤。现在我们有了一个全新的nw7.52系统，现在是第2部分列出我们实际配置系统的活动的时候了。为了做到这一点，我再次通读并遵循olgadolinskaja非常有用的博客文章系列中概述的步骤。我不会重复那些文章中包含的信息和评论中的讨论来让你厌烦。相反，我将提到我们在哪里遇到了障碍，我们如何规避障碍，以及我认为可能感兴趣的任何其他事情。

为了不给我们的同事带来不必要的不便，肯定会成为一系列的尝试和错误，第一步是在新的中央空中交通管制中完成的-一个很少使用的沙盒作为卫星开发系统。大部分工作是由我和我的同事Alexander Merz从我们的基础团队完成的。亚历克斯专注于相关的系统设置，如授权和OSS笔记，我花了大部分时间在ATC和SCI事务中，风控大数据，在中央和卫星系统中进行设置。我们还邀请了一位同事根据需要帮助进行测试。

我在查看中心设置时首先注意到的一点是明显缺少检查变量。除了一个默认变量外，没有其他变量。幸运的是，通过快速搜索找到了解决方案：我只需进入SCI并使用菜单条目"导入检查变体"就可以加载它们。然而，我不太明白为什么他们不只是来预装一个中央系统没有检查变种真的没有多大意义，不是吗？

当我浏览Olga的第一篇博文时，Alex正在建立系统之间的RFC连接并理顺授权。【更新，2018年10月22日：正如我们在上线后了解到的，将RFC连接的语言设置为英语是有意义的。如果用户在使用未安装在中央检查系统中的语言登录时触发检查，这将避免工具故障。]根据建议，我们决定为此从可信连接开始，尽管这意味着所有开发人员用户名都需要在中央系统中已知。完成后，服务器云，我们显然很想看看它是否有效，所以我定义了我们的第一个运行系列，从沙盒系统中选择一个相对较小的Z包，从中央ATC系统中随机选择一个检查变量，然后点击execute。跑步结束后，我们很快就注意到，我们对"某物"的渴望已经超越了自己！我们得到的不是一长串的发现，而是一个相当小的发现，但沙盒系统中有数百个"工具故障"，ST22中列出了4000多个转储！

我们很快意识到沙盒系统遗漏了很多OSS笔记，Alex及时发现并实现了这些笔记。以下是我们必须进入系统的列表，但这显然会因您当前使用的系统版本而异：

2485231–远程ATC检查修改和增强2270689–远程分析（用于源系统）2587593–ATC：远程检查中修改和增强的可检查性–开发人员场景2190065–ATC/CI：远程代码分析–对象提供程序存根2190065–ATC/CI：远程代码分析–对象提供程序存根2381403–远程检查基础设施2375864–ATC：远程检查–开发人员场景2587593–ATC：远程检查中修改和增强的可检查性–开发人员场景2614006–开发人员场景中的ATC远程检查失败

其中一个注释–2270689–甚至在下载/实现过程中导致了一些超时，爱淘客，仔细阅读发现需要更新一个系统参数以避免发生这种情况（甚至没有详细说明！）。

这也有助于保持2364916–推荐的使用ATC执行远程分析的SAP注释方便，作为设置系统时可能需要执行的各种注释的快速参考。

我热衷于探索的其他内容是S/4HANA就绪检查，我可以将其列为检查变体。因此，我定义了另一个运行序列，再次选择一个相当随机的包和一个相关的检查变量。我非常确定的一点是，包中包含的程序做了一些S/4HANA不会太满意的事情，比如使用18个字符长的字段作为物料编号，或者更糟的是，对SAP表进行硬更新。所以，我有点困惑，当那些检查回来没有任何优先1的结果，但比预期的检查失败了很多。怎么可能呢？

同样，搜索提供了答案，另外一个OSS注释需要在中央系统中实现，以加载简化：2241080–SAP S/4HANA:检查客户特定代码的内容。一旦完成并再次执行run系列，我（有点不太高兴）看到2300多个结果！

我还尝试在卫星系统中定义一个检查变量，它实际上使用了中央系统中定义的一个检查，例如一个S/4HANA就绪检查。所以，在我们两人工作了几个小时之后，亚历克斯和我成功地设置了一些东西，以便能够运行一些初始检查，或者从卫星系统中的代码的中央系统触发，或者从卫星系统中的代码使用一个中央检查变体。下一步将设置豁免流程，并决定最终将哪些检查包括在"主"检查中，以防止开发系统中的传输释放。但这些将是本系列未来文章的主题，请继续关注！

以下是本系列其他部分的链接，以供参考：

第1部分：设置舞台

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

第4部分：最后一段

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

关于整个旅程，请看长长的蜿蜒之路版。