第十一章 Productions最佳实践 - 生产电子表格

生产电子表格

维护一个电子表格是很有帮助的，它可以逐个应用程序地组织信息系统。作为一般准则，应该为每个提供传入或传出数据馈送的应用程序提供一行。在每一行中，以下列很有用：

Feed——接口引擎或服务器通常将来自多个应用程序的消息提供给路由产品。在这种情况下，请在此处记下引擎或服务器名称。
Application应用程序——简要说明一个特定的应用程序，它在你的系统中的作用，以及关于这个应用程序的任何问题的联系人。理想情况下，此描述对不使用 IRIS 但通常熟悉系统工作原理的组织成员有意义。
Name 名称 — 此应用程序的唯一名称，由 3 到 6 个字符组成。
Type 类型——应用程序用于外部通信的协议。
Sends 发送——此应用程序贡献给信息系统的消息结构。

考虑进入信息系统后的传入消息结构。是否需要根据目标系统或其他因素进行不同的路由或转换？如果是这样，请多次列出，并附上有关差异的注释。这样，当为每个案例创建必要的路由规则、数据转换和自定义架构时，电子表格可以用作清单。

Receives 接收 — 此应用程序从信息系统中使用的消息结构。
ACK——确认细节。是否需要 ACK 和 NACK 消息？是否有单独的接口用于发送和接收它们？生产应该生成 ACK 和 NACK，还是接收应用程序生成？

当开始该项目时，初始电子表格不需要描述信息系统中的每个应用程序。可以在部署每个新界面时添加到电子表格中。

界面设计

本主题概述了保持界面设计模块化的有效方法，以便产品在其开发的每个阶段都易于理解、扩展和维护：

为将消息发送到 IRIS 的每个应用程序提供一项业务服务。这是一个在生产电子表格的发送列中至少有一个条目的应用程序。

一项业务服务可以接收同一应用程序的所有消息结构。这通常是合适的设计。当为此目的设置业务服务时，通常希望它始终保持与其应用程序系统的连接。

配置的某些方面可能需要提供连接到同一应用程序的附加业务服务。例如，如果源应用程序已配置为将消息发送到两个不同的 TCP/IP 端口，可以设置一个业务服务从一个端口接收所有消息，另一个业务服务用于另一个端口。这通常与每个应用程序一个业务服务的模型一致，因为每个通信源都有一个业务服务。

或者，当同一临床应用程序的数百名用户向企业发送数据时，通过一个业务服务将所有这些消息路由到 IRIS 可能会很有用，该业务服务可能会或可能不会永久连接到应用程序的任何单个实例.
为每个业务服务提供一个路由进程。路由进程可以根据消息本身的内容或存储在 IRIS 中的信息来路由消息。如果路由依赖于其他消息的内容，或者需要调用外部应用程序来确定路由，则路由流程应该是调用其他类的 BPL 业务流程。然而，在大多数情况下，基于内置路由规则引擎的路由过程就足够了。
为从生产接收消息的每个应用程序提供一项业务操作。这是一个在生产电子表格的接收列中至少有一个条目的应用程序。

一项业务操作可以为同一应用程序发送所有不同的消息结构。这通常是合适的设计。当为此目的设置业务操作时，通常希望它始终与其应用程序系统保持连接。但是，对于业务服务，此模型可能会有所不同。

指导原则是保持设计模块化。即一次开发一个接口，每个接口使用一个路由进程。这与单个大型路由进程充当所有接口的路由引擎的模型形成对比。许多路由进程优于一个路由进程的原因有很多：
- 每个路由规则集都更简单，更易于维护，因为它只涵盖一个接口所需的情况。更容易共享和重用独立的工作并解决一组简单的问题
- 接口变得易于单独开发、替换和维护。如果企业必须删除或升级特定应用程序，则只需要触及那些处理该应用程序的路由进程。如果接口出现故障，只需禁用、诊断、修复和重新测试该接口，即可将其恢复。

这比每次需要添加、删除或修复一个接口时都要求重新测试和验证一个大型路由过程中的所有规则要干净得多。当某些界面上线而其他界面仍在开发中时，这些注意事项变得尤为重要。对已在生产中的路由流程的每次添加都可能需要您重新测试和验证数百个现有规则。下图显示了具有多个接口的路由生成：

image.png

生产中的每个配置项都有特定的作用。保持每个项目的作用：

保持业务服务和业务运营简单。一般情况下，业务服务或者业务运营不需要自己写代码。选择 IRIS 提供的内置类。此选择会自动为您提供正确的适配器。使用管理门户设置配置这些类。
将所有复杂活动置于路由流程的控制之下。如果一个接口很简单，它的路由过程就不必复杂，但如果存在复杂性，它就属于路由过程，而不属于业务服务或业务操作。为了完成任务，路由流程可以链接到其他路由流程，或者它可以调用业务规则、路由规则、数据转换、业务流程或自定义代码。