在Mule應用中的流程圖架構

本篇對Mule應用中的流程圖進行描述，流程圖是用Mule來構建應用的默認結構。注意，Mule也支持適用於大數據和流式消息處理的批處理作業。批處理作業也可以與流程圖相結合使用，但是其結構和功能會與下面的內容有所不同。由Batch Processing可見更多關於批處理作業的內容。

關鍵點

簡單應用的場合，Mule應用每次接收一個消息，按照接收消息的循序對消息進行依次處理。如此處理可能有多種結果：

某些情況下，Mule應用向原始消息的來源返回更改過的消息或者替換後的消息
或者，Mule應用向若干第三方發送原始消息或更改過的消息
又或者，Mule可以拒絕對消息進行處理，倘若消息不符合預期。

更進一步

複雜的Mule應用不會侷限於線性消息處理。高級的處理機制可以對不同的消息進行不同方式的處理。你可以結合以下幾點來構建應用：

安排各式隊列與線程來最大化數據吞吐
使用事務或節點集羣來最大化可靠性
使用對象存儲來包裝數據持久性
批處理作業用來處理大數據和流式消息，通過將消息拆解成子記錄進行處理

這些只是你可以用來實現Mule應用的大量特性中的一部分。

下面的章節用Anypoint Studio中的處理器的概念來探討流程圖架構。處理器在Mule xml配置中對應於xml元素，但是爲了對流程圖建模和以及便於理解，本文會使用Studio中的圖形化呈現。

在流程圖中的處理器

處理器被劃分爲不同的功能類別，其中某些處理器又由若干的子處理器構成處理塊。

處理器在流程圖中能被放置的位置是有一點限制的。通常處理器可放置的位置以及其可配置的表現，和流程圖已存在的其他處理器有關（特別是與其相鄰的處理器）。

下一節將詳述各種可以放到Mule流程圖中的處理器（以及處理器塊）

消息源

大多數流程圖中的第一個處理器會是消息源，消息源從一個或多個外部資源接收消息，藉此觸發生成流程圖實例。每次收到一個不同的消息，消息源就會觸發生產新的流程圖實例。

Anypoint連接器就是典型的消息源

有時消息源會將傳入的消息立即放入到隊列中。這使得消息源可以關閉傳入消息的接收線程，然後立即開啓另外的線程接收其他的傳入消息。被放入到隊列的消息會在隊裏中排隊，直到輪到它被流程圖中的邏輯進行處理。由於消息是依次（按照隊列內設的間隔）被兩個不同的線程進行處理，從頭至尾的連續事務處理是不可能的。

譯註：我的理解是，從頭至尾是指第一個消息處理開始至第二消息處理結束，因爲是不同的處理線程，所以無法將兩個消息納入相同事務。只能通過分佈式事務，或者另外的線程進行事務管理。

Message Received, Queued, Processed

消息源可以從多個傳輸渠道接收消息。你可以將一個HTTP節點和Servlet節點相結合來構成複合消息源。或者創建可同時接收IMAP和POP3郵件的複合消息源。其中的任一連接器都可以在受到傳入消息時觸發創建一個流程圖實例。

特定情況下，流程圖不需要通過消息源也可觸發。比如，流程圖引用可以觸發同一應用的不同流程圖。類似的，異步作用域可以觸發異步執行另一個流程圖（與源流程圖並行執行）。

消息處理器

通常、消息處理器是多個消息處理功能單元的封裝，各單元對消息進行不方式的處理。消息處理器的優勢在於：

通常無需自定義代碼即可直接使用。
複數個消息處理器可以用不通過的方式組合起來以實現滿足應用需求。

有兩種不同的方式來將消息處理器結合起來做出應用（或者說做出流程圖）：

在Studio畫布上排列元件（從元件工具箱將元件拖放到畫布上）
在應用配置文件中插入xml代碼

消息處理器劃分爲不同的類別，如下表所示：

分類	簡述
連接器	提供Mule應用與外界通訊的手段。通常作爲消息源，也可以出現在流程圖中的其他位置。與流程圖外的資源進行數據交換，或者作爲消息的最終目的地。
作用域	從多個方面對消息處理器或者處理塊（由多個消息處理器構成的功能組）進行增強。
組件	使你可以爲流程圖附加機能，例如日誌，或者顯示輸出。或者通過特定語言的命令行接口來將舊系統中的業務邏輯集成到Mule應用中。
轉換器	增強或者改變消息負載，屬性，變量或者附件
過濾器	單獨使用或者結合成組，用來判斷消息是否可以流過應用流程圖。
流程圖控制	指定消息如何在流程圖中各個消息處理器之間路由。或可在路由前對消息進行處理（聚合，拆分或者重新排序）
異常處理	指定不同場合下的各式異常處理過程
其他	該特殊類別目前只有一個成員：自定義業務事件處理器，用來放置在其他的處理器之間來記錄關鍵性能指標KPI。通過Mule控制檯可以對其進行監控。

在你的流程圖中按照適合的順序排列好了你的各式處理器之後，你需要配置各消息處理器：

在圖形界面中屬性編輯器中輸入屬性值完成設置
在xml配置代碼中輸入屬性值。

消息處理塊

Mule提供了不同的方式將多個消息處理器合成爲功能處理塊

可以使用合成源作用域將2個或以上的的Anypoint連接器合成爲一個消息源，各連接器監聽不同的渠道。任一連接器收到傳入消息，都會觸發流程圖實例，使消息按序進行處理。

其他的作用域處理器提供了多種將消息處理器組成功能組的方式，使用它們可以：

讓你的xml代碼更易讀
實現並行處理
創建可重用的消息處理序列

交換模式

許多Anypoint連接器是基於節點的，要麼是作爲傳入節點（通常出現在流程圖的最開始），要麼是作爲傳出節點（可以出現在流程圖中間或者結束）。通過通用的協議（HTTP，FTP，SMTP等等）進行通訊。傳入節點和傳出節點可以實現單向或者請求響應交換模式。

當基於傳入節點的連接器譬如HTTP或VM被配置爲請求響應交換模式時，其等效的變爲混合傳入傳出節點。即使有其他的傳出節點並存在流程圖中將數據傳出，配置爲請求響應交換模式的傳入節點也會將數據傳出流程圖，會向消息的原始發送者返回響應。

請求響應交互模式

傳出節點被配置爲請求響應交換模式時，它們可以與流程圖外的資源交換數據，也可以與同一Mule應用中的一些消息處理器交換數據。

並非所有的節點都可以被配置成請求響應交換模式，且對於可配置響應交換模式的節點，只有其中的部分是默認配置爲該模式的。如果主流程圖中沒有節點被配置爲請求響應交換模式，流程圖在接收消息時會遵受單向交換模式，且不會向原始發送者發送響應。但是，流程圖可以向其他方發送數據，例如日誌文件、數據庫、郵件服務器或者Web API。

處理策略

處理策略決定了Mule運行消息處理器的順序。例如，當消息源配置爲請求響應交換模式時，Mule將處理策略設置爲同步，則流程圖的執行是在單一的處理線程中進行的。這樣確保整個消息處理器序列得以執行，客戶端可按照預期獲得相應。

與之相反，當流程圖配置爲單向交換模式且非事務性（源消息發送者不需要收到響應，且不必對全部執行步驟進行完成校驗），Mule會將處理策略設置爲隊列化異步，這樣可能會增加流程圖的吞吐量。這種情況下，傳入節點將傳入消息立即放入隊列，並關閉對應接收線程。當消息在隊裏中排到出隊列後，則該消息會被另一個不同的線程繼續處理。由於通過了不同的線程對消息進行，在某一線程中出現異常則無法回滾另一線程中的處理，所以橫跨整個過程的事務管理是無法使用的。

單向異步模式

更多細節：參見流程圖處理策略

異常處理策略

異常處理策略決定了Mule對於消息處理過程中發生的異常如何進行響應。最簡單的處理方式是將異常記錄到日誌文件。

通過配置自定義異常處理策略可以靈活的根據不同的條件進行響應。比如異常在消息被轉換之後發生，你可以設置Mule在異常發生之前被轉換之後就立刻被提交，這樣可以避免消息被意外的重複處理。

Stuido提供了四種現成的異常處理策略來應對消息處理序列中各種位置拋出的異常。詳情請見異常處理.

流程圖架構

Mule流程圖極其靈活，所以你可以用許多不同的方式來組織處理器來達成相同的結果。然而，在許多用戶用例下，鬆散排序模式下的消息處理器更容易出錯。譬如，假設你要創建一個應用，該應用從網頁接收產品目錄請求，將產品目錄的PDF發送給提交請求的客戶端。另外，你想通過這個流程圖將客戶端的客戶信息保存到日誌並記錄事務。你的流程圖可能會一如下圖所示：

在線假日廣告冊下載-設計

注意過濾器和轉換器可以內嵌在傳入節點，但是把它們放在主流程圖易讀性更佳，對於圖形界面的畫布和xml格式的配置文件皆是如此。

在線假日廣告冊下載-流程圖

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:mulexml="http://www.mulesoft.org/schema/mule/xml" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/xml http://www.mulesoft.org/schema/mule/xml/current/mule-xml.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/scripting   http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd">

<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>

<flow name="Catalog_DownloaderFlow1" >
    <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
    <mulexml:xml-to-object-transformer doc:name="XML to Object"/>
    <scripting:component doc:name="Groovy">
        <scripting:script engine="Groovy" file="myScript.groovy"/>
    </scripting:component>         
    <logger level="INFO" doc:name="Logger"/>
</flow>

</mule>

流程圖配置

雖然流程圖很靈活，但是處理器放置在流程圖中的位置依然是有一定限制的。根據流程圖中已放置的處理器，可繼續放置的處理器位置會有所不同。處理器根據其在流程圖中所處位置不同，其可配置的屬性也會不盡相同。

如果你通過Anypoint Studio的可視化編輯器進行Mule應用的開發，Studio會自動跟蹤處理器之間的限制，以確保你不會將處理器放到不應該出現的位置。

以下是覆蓋大部分運用場景的創建可用的流程圖的處理器序列的規則。

一個消息源包含若干傳入節點或流式連接器，任一節點和連接器收到消息時都會觸發流程圖。
過濾器用來判斷無效的消息並阻止無效的消息通過流程圖中的其他處理。
轉換器可將傳入消息轉換成流程圖中其他消息處理器可處理的格式
消息增強器可往消息中增加特定的關鍵信息。譬如，附帶着地址信息的消息傳入，消息增強器可能會利用其中的郵政編碼來查找相應的電話區號，然後將查到的信息追加到消息頭部供市場部門使用。
消息準備好被處理後，通常會被髮送往預先組裝好的自定義業務邏輯（通常稱爲組件）進行處理。這樣就可以對內容按照合適的方法去處理。
關於流程圖的結尾有各種可能；以下的可能部分出現或全部出現：
- Mule向消息的原始發送者發送響應
- Mule將業務處理的結果記錄日誌到數據庫或者發給第三方

流程圖處理之後，你可以：

將消息發送往隊列（即便是同一流程圖中也可以往多種隊列發送）
指定線程模型
調用各式其他的流程圖

在Mule應用中的流程圖架構