第十三章 Productions最佳实践 - 将接口转换为生产元素

本章假定对于每个应用程序，可能需要同时定义入站和出站接口。

当将 IRIS 引入此类配置时，通常是为了用 IRIS 替换现有的接口引擎。为此，必须：

本章中的转换方法保留现有的接口引擎并将接口一个接一个地转换为使用 IRIS。未转换的接口继续使用以前的引擎，同时使用 IRIS 测试并确认新接口正常工作。一旦转换后的接口正常工作，就可以开始处理下一个未转换的接口。这种增量更改策略可确保在转换期间提供不间断、无差错服务的最佳机会。

可以采用同时转换相关接口组的方法。不过，可能会发现这项工作归结为一次转换一个接口。

本章介绍如何将一个现有接口转换为使用 IRIS。一般步骤如下。本章的每一节都详细描述了其中一个步骤：

本章中的过程与通常描述作品的顺序相反。（“业务服务接收传入消息…”）但是，接口转换的经验表明，如果自上而下地开发元素，从业务服务开始并向下处理到自定义模式，必须经常回溯到前一个在配置了较高级别项目的各种表单中填写或更正较低级别项目名称的步骤。

本章中的过程采用自下而上的方法，通过首先创建较低级别的项目将回溯减少到最低限度，以便在配置较高级别的项目时知道它们的名称。自下而上的顺序如本章所示：步骤 1 和 2；步骤 3、4、5、6、7、8；步骤 9 和 10

可能会以自上而下的顺序成功执行此过程，特别是如果有完善的命名约定，这会减少简单错误。自上而下的顺序如下：步骤 1 和 2；步骤 8、7、6、5、4、3；步骤 9 和 10。

备份Production

要执行完整备份，请参阅开发产品中的“部署产品”。

注意：关于 XML 备份文件：如果使用 UNIX® 系统，切勿以二进制方式通过 FTP 传输备份 XML 文件。常规 FTP 会将此文件从 DOS 正确转换为 UNIX®，但二进制 FTP 可能不会。

企业中使用的每个应用程序都应提供自己的应用程序规范文档。规范文档解释了应用程序可以发送（或接收）哪些类型的消息，以及应用程序为这些事件发送（或期望）哪些消息段和每个段的片段。资料非常详细。每个申请的管理员都可以向您展示他或她的申请文件。

源应用程序和目标应用程序都应该有一个应用程序规范文档。但是，这些应用程序之间的任何单个接口（例如您正在转换的接口）都使用规范文档中列出的可能性的一小部分。接口描述的最佳来源实际上是要替换的接口定义。

打开现有的接口定义。了解此定义后，打开一个文本文件并在其中键入接口功能的简短描述。不要试图详细复制现有定义（LOOP、CASE 等）的编码约定。简单识别：

在此步骤中，必须确定将哪个模式用于接口的入站和出站端。这从一个近似的选择开始，可以通过在管理门户中针对该模式测试消息来优化它。

每个应用程序都应该有一个应用程序规范文档，用于标识发送消息时使用的模式以及接收消息时期望的模式。

创建路由规则集。有关信息，请参阅开发业务规则中的“创建和编辑规则集”。

创建 DTL 数据转换。有关信息，请参阅开发 DTL 转换。

接口的业务操作控制到目标应用程序的传出消息传输。有关添加业务操作的信息，请参阅配置制作中的“添加业务主机”。

出于测试目的，使用具有相同配置名称的两个业务操作来配置生产很有用：

按照惯例（这些项目具有相同的配置名称）一次只能启用这些配置项目中的一个。根据是想要“测试”环境（文件操作）还是“实时”环境（TCP 或 FTP 操作）启用其中一个。

创建“实时”业务操作及其“测试”对应项的步骤如下：

为“测试”（文件）操作提供与“实时”操作相同的配置名称。