这是我正在进行的关于建立我们的中央空中交通管制系统的博客系列的第3部分。

第1部分：准备阶段和第2部分：准备系统

到目前为止，我们已经对我们新的中央空中交通管制系统的行为以及如何将卫星系统连接到它变得相当熟悉。因此，现在是时候着手处理一些细节了，比如基线检查的原型、调整消息优先级和设置豁免流程。与此同时，大数据对比，我正在整理必要的文档，以便在几周后开始使用中央ATC检查之前与开发人员共享。

我需要做的第一件事是决定在变量中包含哪些检查，以定义我们的基线。然而，为了做到这一点，云免费，我首先必须考虑并定义哪些检查应该进入我们在任务/传输发布期间使用的未来检查变体中，其中prio 1和2的发现将阻止发布。不幸的是，我的相关问题没有得到任何回答，我只是继续，从我们已经有的检查变量开始，执行和添加检查并不是完全随机的，但基本上只是遵循我的"直觉"，即什么对我们有意义，什么对我们没有意义。

我们决定让一些检查阻止任务/传输发布，即使它们来自"旧"代码，而不只是来自新创建或更改的部分。其中一个例子是对SAP表的硬更新（TVARVC除外），我们知道在遗留代码中有太多的数据。我们计划使用豁免过程至少记录这些更新出现在代码中的位置和原因（以及为什么它们不能轻易地更改为更好的方法）。由于这个决定，用于基线的check variant包含的检查比用于传输释放的工作中的检查少一些。

一旦定义了check variant，我就设置了一个运行序列来检查沙盒系统中从"Z*"开始的所有包中的所有对象：

大约5小时后，作业仅完成了"少量"发现和检查失败：

在沙盒系统中下载了OSS Note 2270689–Remote Analysis（用于源系统）的更新版本后，受影响对象在重新运行时不再出现缺少的先决条件错误。其他错误-据我所知-是源代码中的实际问题，如语法错误或缺少屏幕定义。

在执行基线检查时，有一件事有点奇怪：大多数时候，刷新状态屏幕显示以50个对象为增量的更新，进程保持稳定运行。但在某些时间段（实际上超过一个小时），就可见的进展而言，什么也没发生。通过SM50检查这个过程看起来好像有点卡在了与类CL\u CI\u PROVIDE\u CHECKSUM相关的例程中，从SAT的一些观察来看，在短短几秒钟内发生了很多事情，一些计数在10秒内进入千分之十的高位。

在得到结果后，我将它们添加到基线：

然后我"玩"了一下结果，以检查这是否真的如Olga Dolinskaja发表的相关博客文章所述。你猜怎么着？是的！

我最不期待的一项任务是调整消息优先级。尽管这可以很容易地从事务ATC或SCI和检查变量定义（通过代码检查器–>管理–>消息优先级）完成，但这是一项有点乏味的任务。

我们的计划是从一些检查开始，以防止任务/传输释放，而这反过来又需要重新分类相当多的时间从消息优先级1或2到3的大量检查。为了知道哪些检查需要调整，我们做了以下步骤：

这样做有好处，我可以看到交通工具的结果如何每天根据我对优先级的调整而变化。因此，我不必猜测，大数据技术及数据分析培训，会发生什么，但我会真正知道（或者我希望如此！）。这也应该有助于不给开发者带来太多不便，啥是大数据，一旦我们上线，我可以告诉-和显示！–让他们知道事先应该做些什么。

ABAP开发发生在许多地方，也由全球各地的外部开发人员进行，因此我们提前知道，在使用阻止发布任务/传输的检查之前，我们必须仔细研究如何最好地定义免责流程。特别值得关注的是明显的限制（在Olga的另一篇整洁的博客文章中有描述），即开发人员需要为豁免请求选择一个特定的批准人，因为大多数开发人员并不真正知道在任何给定的时间，可能为数不多的潜在批准人中谁可以"点击按钮"。

我们有现在我们想出了一种在当前环境中实现这一点的方法：

我们已经检查过了，当每个人a）都拥有所需的授权，b）在ATC"维护审批者"设置中被列为审批者时，豁免请求可以由任何人更新-不必是列为审批者的ID。一旦批准或拒绝完成，用户名将切换到实际执行者。

首先，看起来好像我们不得不手动调整作业的设置，以发送有关请求和处理的豁免的通知，因为标准配置每天只运行一次作业-显然不足以满足我们的要求！幸运的是，我们找到了OSS Note 2619387–ATC:Downport Immediate E-Mail Notification，在它实现之后，现在可以立即触发通知：