关键任务系统()的设计/过程

Question

概述

对于abc公司来说，团队在任务关键应用程序和扩展应用程序方面是分开的.例如，customer使用任务关键数据，但是有一些业务约束/流不能仅用任务关键系统来实现。为了维护数据的完整性(任务关键系统是记录系统)，web服务(S)被用来与任务关键数据进行交互。这些web服务发送一个实体(业务对象)有关任务关键系统。

从关键任务的角度来看，存在着对一些第三方工具的依赖。其中一个工具将web服务调用排队到线程中，并且它能够拒绝当前排队的或新的web服务调用。拒绝意味着数据没有进入目标系统。虽然我没有得到所有标准的澄清，但使用的是典型的关注点，例如大数据集(S)、网络流量或数据库锁。

客户请求

如上所述，扩展应用程序应该提供更符合其预期工作流程的功能(S)。已请求大量修改扩展的应用程序数据，例如供应商x被供应商w买走，以便所有当前发生的事务都必须映射/设置到新供应商。在这种情况下，可以有需要更改的1-n条记录，而且在关键任务系统中，每个记录不可能作为一个实体一起存在。

此过程的最后一步是将更改后的数据上传到关键任务系统，因为外部系统(会计、供应商等)。要求只使用来自该系统的数据。

Notes

有可能获得自定义web服务，但如果第三方工具决定在成功的web服务调用确定后拒绝调用，则仍然存在问题。

在将大量数据导出到文件(CSV或电子表格)的过程中确实存在，但是使用的重点是公司以外的数据。如果web服务可以接受一个文件，那么就会出现拒绝问题。如果可以使用某些批处理/ETL，则存在数据完整性的风险，因为这将创建一个不同的分支来操作不在关键任务系统上下文中的数据。

一个想法已经被抛出，以便在我们自己的分阶段/事务区域中排队数据条目，这样我们仍然可以通过web服务上传并保存记录，如果没有完全处理的话。这个想法的关注点是网络流量。(例:更新了1000个条目，这些数据跨越50个实体。该web服务将以其当前格式进行50个调用。)

问题

就设计而言：

大容量数据操作在哪些方面适合客户请求？

关键任务系统是否应该定义一种接受大量数据的方法？

这仅仅是与扩展应用程序相关的团队的责任吗？(例如:在如何维护数据完整性方面，向客户定义一个“合理的”流程；或者用某种只通过web服务调用传递数据的作业来定义阶段/事务区域)

对于当前的公司结构(许多团队负责处理子集)，有什么可以添加到单个团队的流程中，以帮助处理类似于上述级别的未来功能请求？(涉及关键任务数据完整性的请求)

Answer 1

您应该使用第三方库或构建自己的系统，该系统在进一步尝试之前应立即写入数据库。如果出了什么问题，您仍然可以将该信息保存在某个地方以进行恢复。理想情况下，如果失败，它将重新尝试发送，在执行任何操作之前跟踪数据库上的状态。

如果需要，您可以使用公共标识符链接消息，以便在任何单个消息失败时，可以反转或至少尝试以与执行相同公共标识符的顺序相反的方式反转所有消息，首先从错误点开始，然后向后工作。只需记住，在尝试任何回滚之前，要始终跟踪状态！

当然，这样您就会遇到无法写入数据库的问题，但是数据库应该是服务器的本地数据库，因此不太可能遇到网络问题。它有可能同样失败，如果它在几次重试后继续失败，至少应该做最后的努力，通过电子邮件通知系统管理员一些严重的错误。这确实是一种罕见的情况，因为在这种情况发生之前，发送和写入数据库都会出现问题。

大容量数据操作在哪些方面适合客户请求？关键任务系统是否应该定义一种接受大量数据的方法？

不要让每一个更新都是一条消息！请记住，您只需要保存重新创建请求所需的足够信息。在服务器上以唯一的名称保存csv/电子表格文件，并在消息中指示服务器上要访问该文件的路径。您既减少了消息队列中的杂乱，又消除了将所有这些列及其值存放在数据库中所需的复杂性。程序中负责重试消息的部分还应该能够在这种情况下处理csv/电子表格，并解析/发送它们，就像如果请求进行得很好的话。

这仅仅是与扩展应用程序相关的团队的责任吗？(例如:在如何维护数据完整性方面，向客户定义一个“合理的”流程；或者用某种只通过web服务调用传递数据的作业来定义阶段/事务区域)

负责接收数据的web服务的团队应该有权在数据无效时拒绝它。但是，我强烈建议您想出一个标准的错误系统，定义可能发生的常见错误(以及潜在的错误的可能性，这些错误是web服务特有的)。

我在我的工作场所定义的系统是代码0表示“一切顺利”，代码100-199用于警告，200-299用于常见错误，任何超过1000的代码用于自定义错误代码。因此，您知道，例如，如果他们一方有一个内部错误重试，但不重试，如果数据被认为是无效的。

我也会避免给客户担保。相反，告诉他们您在发生错误时使用的策略，包括重试和尝试时，最后，任何通知都不应该像预期的那样进行。

底线是，只要你在任何操作之前写到数据库，你就可以追溯关键任务系统的确切故障点，尽管你不能保证成功，但至少你可以在失败时采取行动。