第二章 什么是通道？

本章主要介紹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 執行完畢就進入第二個通道，而應答的處理也是逐級遞歸。

接下來的內容我們就詳細介紹這些情況。