这是我正在进行的关于建立中央空中交通管制系统的博客系列的第4部分。对于整个旅程，请看漫长的曲折的道路版。

第1部分：设置阶段和第2部分：准备系统和第3部分：调整设置到我们喜欢的

如第3部分结束时提到的，我已经计划了一些会议与我们的开发人员（内部和外部）让他们跟上即将到来的变化a）的速度空中交通管制检查和b）运输发布过程。

我创建了德语和英语版本的演示文稿，因为就开发活动而言，我们有一个相当异构的设置：

我是一个小型内部开发团队的一部分我们流程/职能团队中的同事，他们做一些编码工作定期在现场工作的德国外部开发人员在其他一些有特定开发需求的地方（例如巴西），相当独立的内部开发团队临时签约的开发人员在一些地方执行特定的任务，在这些地方，我们通常没有太多的，如果有的话，淘客网站，与开发人员直接接触

显然，返利宝，做演示对其中一些人来说比其他人更容易！对于我们的内部和外部内部开发人员，我提供了两个德语会议，并为那些在家工作的人提供了虚拟加入的附加选项。我还为巴西和美国的开发人员领导做了一次英语WebEx会议。

对于每个人，包括签约的开发人员，演示文稿都以PDF文件的形式提供，这些文件包含在我们的开发指南中，每个人都可以通过合流空间访问。

基于我还准备了一个FAQ页面，并通过我们的指南空间随时提供。

在计划会议时，我有足够的时间讨论可能出现的任何问题。其中之一是如何最好地处理阻止释放运输工具的调查结果。评论的范围从"开发人员将简单地使用伪评论，如果一个是可用的"或"他们将只是要求豁免，期望它将被迅速授予"到"调查结果应该被检测和修复，甚至在发布传输之前"。这些讨论无疑有助于形成常见问题页面！

在第二次研讨会之后，中央系统的新检查变体在开发系统中被激活，但在优先级1和优先级2发现的情况下，尚未打开阻塞传输释放。开发人员被邀请仔细查看他们在正常工作过程中得到的检查结果，并收集诸如发现之类的反馈，其中优先级可能仍然需要调整。豁免程序也被激活了，这样开发者就可以在没有任何实际后果的情况下进行尝试。

为了希望减轻一些"恐惧"，我的演示文稿中包含了一张幻灯片，其中有一些关键要点：

在进行演示并为他们抓取详细的屏幕截图时，我注意到在结果列表中显示豁免的方式有一个小的潜在的混淆问题：所有的豁免都显示为"Has Pragma"，尽管它们实际上是通过被包括在基线中而被豁免的。由于我没有收到任何关于这个问题的回复，我打开了一条OSS消息，当它在一天之内被直接、毫不拖延地或进一步的问题转发给开发支持时，我感到非常惊讶。我不记得以前发生过这种事！

事实证明，这也是纠正支持用户设置的一个好方法，需要一些额外的授权和访问，以便在开发系统和中央ATC系统中重现问题-这是我们在新设置的雷达上还没有的。所以，很好的一件事，我们发生了这个之前，我们遇到任何问题后，当系统是活的！

在撰写本文时，OSS消息被搁置，企业软件公司，因为它需要的不仅仅是一个快速的错误修复来得到纠正。一旦我们得到回复，我会用提供的解决方案更新我的问题。

在设置中央ATC系统的整个过程中，懒懒淘客，我们必须对各种授权做一些调整。真正的魔鬼在于细节！最后，我们完成了这些设置：

尽管建立我们的中央ATC系统的项目花费了比预期更长的时间，但这仍然是一件相当简单的事情。真正起到很大帮助的是ATC系统和SAP社区提供的良好文档，在线建站平台，特别是Olga Dolinskaja的博客文章非常清楚地列出了待办事项。很明显，这也有助于我们在一个轻松的项目时间线，因为它并没有什么真正的问题，当它上线。用sandbox系统进行第一次试运行被证明是一项非常宝贵的时间投资，避免了在实际开发系统中不必要地"烦扰"开发人员。

底线-我希望从现在开始实际使用中央检查将证明我在这方面是正确的！–投入资源（金钱和时间）建立中央ATC系统是非常值得的！

这很可能是这个博客系列的最后一集，因为剩下要做的唯一一件事就是在几周后用priority 1和priority 2发现阻止传输版本。但这只是一个简单的"开关的翻转"，所以不值得写回家！这不排除我可以写一种结语，一旦我们已经运行了几个月-如果有什么有趣的报告。

我希望你觉得这个博客系列有帮助，我有兴趣阅读你的经验与中央空中交通管制检查的评论！

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

第1部分：设置舞台

第2部分：准备系统

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

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