第二章 什么是通道？

本章主要介绍Mirth Connect开发框架，讲解运行的各个阶段，请大家仔细研读、理解，对后续章节帮助是很大的。开发者把前端与服务分开运行，服务框架集成了很多流行的服务及协议，从中我们也可以看出开发的大致原理。本章涉及到的知识点需要了解一些的，比如SOAP

第二章   什么是通道？

通道是 Mirth Connect  的重要组成部分，被看做是一对多的一种单向通道，其通道组件是解耦的，在两个应用或多个应用之间传输医疗数据。 Mirth Connect  能把长消息任务分割成小消息任务，其可靠性、灵活性、高性能得到保证。

 

图 2-1 Mirth Connect 抽象通道架构

通道架构组成：由源、通道、目标组成，其中通道包括过滤组件和转换组件。

创建一个通道需要满足如下特点：

       ●   源连接器类型，用于读取数据。 (Source)

       ●   目标连接器类型，用于发送数据。 (Destination)

       ●   入站消息格式。 (inbound)

       ●   出站消息格式。 (outbound)

       ●   传输 ( 在入站和出站之间有个映射表 )

什么是连接器 (Connector)

连接器就是一个消息的端点，是 Mirth Connect 之间或与外部应用之间通讯的一种特殊协议。

支持的连接器列表 :

       ●  TCP/MLLP

       ●   数据库 (MySQL,PostgreSQL,ORACLE,SQLServer,ODBC)

       ●   文件（本地文件系统和网络共享）

       ●  PDF RTF 文档

       ●  JMS

       ●  HTTP( 免费版 HTTPS 协议不支持 )

       ●  SMTP

       ●  SOAP( 超 HTTP)

收到数据的连接器被称为 Reader( 读取者 ), 例如 MLLP Reader ；发送数据的连接器被称为 Writer( 写入者 ) ，例如 Database Writer 。

过滤器 (filter)

现实世界中，许多应用之间互联，一个通道可能从许多源接收消息，然后这些消息根据消息的类型或条件，需要分门别类的处理。

有两种方法可以解决上述问题：过滤器或路由器。

路由器最关键的优势是根据唯一的位置决定消息到达目的地的条件。

过滤器是 Mirth Connect 处理消息的主要机制，根据消息的属性（段和元素）决定对消息的处理情况，过滤器从消息队列中检测消息的属性，而消息不会从消息队列中删除，如果本过滤器没有校验通过，原封不动的返回给消息队列，以便此消息用于其它的过滤器进行处理。

如果处理的消息类型很多，可以建立多个独立的到目标的通道，相互之间可以建立多个过滤器进行消息的处理。

转换器 (Transformer)

许多情况下，遗留系统、客户应用和第三方应用，彼此之间需要根据数据模型进行消息的发送，尤其有特殊格式要求的数据系统。当新的商业需求提出一个唯一标准的时候，我们就需要把其他系统数据格式转成新系统要求的数据标准，传统方法处理起来即复杂又困难，更难于维护。

那么，对这些不同格式要求的消息，怎么进行数据互联呢？ Mirth Connect 提供了消息转换器来解决这类问题。通过 Transformer ，接收方得到了它理解的消息，变成自己的内部使用的数据格式。

Transformer 支持的转换器类型：

       ●  Message Builder  把入站消息片段映射成出站消息片段。

       ●  Mapper  把入站消息片段映射成 Mirth Connect  内部变量，这些变量在                以后会被用到。

       ●  External Script  从名字上就能猜到，利用外部的 javascript 脚本进行消                     息的转换或映射数据。

       ●  XSLT Step  就是个 XSL 转换工具

       ●  JavaScript  和 External Script 一样，灵活使用。在本教程中有许多地方                   用到了 JavaScript ， Java 代码也被用到了。

通道脚本执行的阶段

通道还支持脚本特性，增强消息的处理逻辑，适用于管道本身及所有传递的消息。

这些脚本的名字及含义如下：

●  Deploy  部署脚本， Mirth Connect Server 启动的时候或通道重新部署的时候

    启动这部分的脚本 .

●  Attachment  附件脚本，以本地的格式处理消息并允许抽取一部分消息作为

    附件存储起来，或者是不可避免的要修改消息。

●  Preprocessor  预处理脚本，脚本还允许在 Mirth connect 开始将其转换为内

    部格式 ( 即 XML) 之前以本机格式处理每个消息。

●  Filter & Transformer  过滤器和转换器，是我们处理入站和出站消息的主要

    地方。

●  Response  应答脚本，从名字上看出，就是处理目标发送的应答信息。

●  Postprocessor  后处理器脚本，消息成功发送后执行的脚本。

●  Undeploy  反部署脚本， Mirth Connect Server 每次停止服务的时候调用，比

    如释放通道程序占用的内存。

脚本的执行顺序如下：

      1. Global Deploy script  全局部署

      2. Deploy  部署

      3. Attachment script  附件脚本

      4. Global Preprocessor script  全局预处理脚本

      5. Preprocessor script  预处理脚本

      6. Source connector Filters script  源连接器过滤器脚本

      7. Source connector Transformer script or mapping  源连接器转换器脚本或

      映射

      8. Destination 1 connector Filters script 目标 1 连接器过滤器脚本

      9. Destination 1 connector Transformer script or mapping  目标 1 连接器转

      换脚本或映射

      10. Destination N connector Filters script 目标 N 连接器过滤器脚本

      11. Destination N connector Transformer script or mapping  目标 N 连接器

       转换脚本或映射

      12. Response 1 Transformer script or mapping  应答 1 转换脚本或映射

      13. Response N Transformer script or mapping  应答 N 转换脚本或映射

      14. Postprocessor script  后处理器脚本

      15. Global Postprocessor script  全局后处理器脚本

      16. Undeploy  反部署

      17. Global Undeploy script  全局反部署脚本

Deploy 、 Global Deploy 每次管道重新部署启动一次， Undeploy 、 Global Undeploy 也是一样，其他的每次发送接收消息都要执行一遍。注意 Global Preprocessor 在 Preprocessor 之前执行， Global Postprocessor 在 Postprocessor 之后执行。

通道在序列里操作，首先被执行的是第一个通道的 Attachment ，而第一个通道 Postprocessor 是最后执行，让我们看看序列通道执行的情况如下图：

 

图 2-2  脚本执行序列

这个序列有三个通道串行执行，每到 Destination Connector 执行完毕就进入第二个通道，而应答的处理也是逐级递归。

接下来的内容我们就详细介绍这些情况。