工作流程的微服務：使用F＃DSL表達業務流程

• 編譯時間驗證：由於開發人員主要是構建步驟和定義工作流程，因此我們希望工作流程享受F＃提供的型別安全性和工具。
• 可讀性：工作流是業務邏輯的表示，應該由開發人員和業務使用者輕鬆閱讀。
• 可擴充套件性：任何好的DSL都允許擴充套件或改進，而不會破壞或影響現有的實現。我們希望將來能夠輕鬆新增新型別的步驟和組合。

workflow : (name : string) -> 
    (triggers : Trigger list) -> 
    (metadata : WorkflowMetadata) -> 
    (step : WorkflowStep) -> 
    Workflow

workflow "SampleWorkflow"
    [Trigger.Stream ("kafka://jetkafka/mock-input", TaskIdType.FromPath(Path.JsonPath("$.orderId")), Path.JsonPath("$.orderId"))]
    metadata
    (step("CreateOrder", "CreateOrder") =>
        step("ReserveInventory", "ReserveInventory") => 
            step("ShipOrder", "ShipOrder") =>>
                [
                    step("ChargeCustomer", "ChargeCustomer") =?>
                        [
                            cond("WriteChargeSuccess", "WriteChargeSuccess", Condition.Simple(Qualifier.State, "$.transactionSuccess", "true"))
                            cond("WriteChargeFailure", "WriteChargeFailure", Condition.Simple(Qualifier.State, "$.transactionSuccess", "false"))
                        ]
                    step("UpdateOrderHistory", "UpdateOrderHistory")
                ]
    )

1. 工作流名稱（workflow "Sample Workflow"）：工作流都需要一個名稱，這些名稱負責許多標識元素以及控制元素，如執行通道控制，啟用/禁用鍵名等。
2.  觸發：使用Discriminated Union指定觸發器，其中每種情況對應於特定的輸入型別/源。常見的觸發器是一個Stream有三個引數string * TaskIdType * PrimaryKeyPath的字串：字串是StreamDefinition，而TaskIdType和PrimaryKeyPath是觸發器訊息的JsonPath。注意：工作流可以有多個觸發器，並且具有各種型別。
3. 工作流後設資料：工作流後設資料定義了與工作流執行器，副作用執行器以及失敗的工作流/副作用應該在哪裡進行通訊的通道，以及各種配置元素，如工作流的併發設定。（有關更多架構詳細資訊，請參閱我之前釋出的微服務到工作流程）
4. 步驟：步驟表示需要執行的操作或副作用。這些操作是顯示名稱和實現模組名稱的元組。注意：在此示例中，顯示名稱和步驟實現是相同的，但是在工作流程中多次重複使用相同步驟實現的情況將導致不同的顯示名稱。
5. 步驟組成：透過一系列組合功能組合步驟以形成工作流程。更多關於後者的內容。

觸發器
工作流可以有一個或多個不同的觸發器。這些觸發器用於配置WorkflowTriggers服務從哪裡使用觸發器訊息。這種消費與我們的微服務中使用的消費機制相同，這在以前的帖子F＃Microservice Patterns @ Jet.com中有詳細介紹。的觸發的型別是可區分聯合（代數型）：

type Trigger =
| Simple of string * TaskIdType
| Stream of string * TaskIdType * PrimaryKeyPath
...

• string ：string這裡表示流定義，它是外部系統的表示（即Kafka，EventStore，API等）。之前的文章在F＃中抽象IO有關這個概念以及我們如何在整個系統中建模和使用它們的詳細資訊。
• TaskIdType ：每次執行工作流都有唯一的任務ID。該TaskIdType指定如何的taskid獲得。目前，我們支援多種型別的任務ID。我們支援隨機生成的這些，當您不希望進行任何形式的重複資料刪除檢查並始終希望執行工作流時，可以使用這些。我們還支援從輸入有效負載中提取任務ID，以確保每個訊息只執行一次工作流。
• PrimaryKeyPath ：是一個JSON路徑，用於從哪裡提取要用作日記帳ID的值。Journal是所有工作流程的真實來源，它是工作流程所採取的每個操作的事件源日誌。

步驟
步驟表示工作流需要採取的操作。步驟是任何工作流程的基礎，也是定義其功能的基礎。目前有三種不同型別的步驟：

• Simple Steps（step）：只表示一個動作，將始終執行，並且所有業務邏輯在步驟本身中都是自包含的。使用該step函式表示簡單步驟。
• 條件步驟（cond）：包含a的步驟Condition，這些條件允許將行為資訊編碼到工作流DSL中，以根據特定邏輯決定執行哪些步驟。
• 可選步驟（option）：步驟包含條件但不需要具有負面情況的路徑。條件步驟總是需要有正面和負面的路徑。

謂詞邏輯
謂詞邏輯又名條件，可以在任一使用cond或option步驟或在觸發流用於條件過濾。透過提取資料的工作條件規定的Qualifier基礎上一些JSON路徑，然後他們比較這與提取基於該預期值資料Comparison和OperandType 。支援的不同型別的條件是：

type Condition =
| True
| False
| Simple of Qualifier * path:string * expected:string
| Match of Qualifier * path:string * expectedRegx:string
| Compare of qualifier:Qualifier * typ:OperandsType * path:string * comparison:Comparison * expected:string
| Count of qualifier:Qualifier * path:string * comparison:Comparison * expected:string
| Exists of qualifier:Qualifier * path:string
| Not of Condition
| And of Condition List
| OR of Condition List

• True | False:始終評估（True）或永不評估（False）
• Simple: 從指定的資料中提取資料與預期值進行比較。
• Match: 根據路徑從指定的限定符中提取資料，並使用正規表示式匹配預期值。
• Compare: 提取基於路徑上的指定的資料，並與預期值比較，基於Comparison cast 到在OperandsType，Comparison型別目前支援以下比較：
  

  type Comparison = | GreaterThan | GreaterThanOrEqual | LesserThan | LesserThanOrEqual | NotEqual | Equal

type OperandsType =
| Int
| Long
| Double
| Decimal
| Boolean
| DateTime

• Count: 據路徑（通常是陣列）從指定的限定符中提取資料，獲取元素的計數，並與期望值（字串化的int值）進行比較。
• Exists: 根據路徑從指定的限定符中提取資料，檢測是否存在
• Not | And | Or: 布林運算子是否用於組成條件，即

let cond = Condition.Count(Qualifier.Input, "$.a", Comparison.Equal, "10")
let cond2 = Condition.Simple (Qualifier.Aggregate, "$.bs", "sting")
let cond3 = Condition.Simple (Qualifier.State, "$.a", "20")
let condORAnd = (cond OR (cond2 AND cond3)) |> Condition.Not

步驟組合

step(“CreateOrder”, “CreateOrder”) => 
     step(“PreDealOrder”, “PreDealOrder”)

• chain（=>）：步驟可以組合（=>）在一起形成一個鏈。因此a => b，意味著a首先執行步驟然後執行步驟b。
• any（=?>）：步驟可以由一組條件步驟組成，其中只執行滿足條件的第一步。因此a =?> [b;c;d]，暗示步驟a首先執行。然後，假設步b不符合條件，但步驟c和d滿足條件，則由於c是第一位的，只有c得到執行。
• every（=??>）：步驟可以由一組條件組成，其中執行滿足條件的每個步驟。所以a =??> [b;c;d]意味著一步a最先被執行，那麼，假設步a不符合條件，但步驟c和d滿足條件，那麼這兩個步驟c，並d得到執行。
• all（=>>）：可以在執行所有步驟的組中組合步驟。因此a =>> [b;c;d]，意味著a首先執行步驟然後執行所有步驟b，c然後d執行下一步。

執行
F＃DSL允許我們輕鬆設計和實現工作流程，但為了便於跨服務執行DSL，我們建立了一個不同的內部工作流表示，以便在我們的後端服務中使用。我們將DSL轉換為DAG（有向無環圖），以將我們的規範DSL與執行時環境分離。我們的服務使用此圖表來實際執行工作流程。此圖表很容易表示為F＃型別：

type Name = string
    
    type EdgeData = string
    
    type VertexData<'V> = Name * 'V //'V can be the representation of a step
    
    type Vertex<'V> = 
        { data : VertexData<'V>
          outEdges : Edge<'V> List }
    
    and Edge<'V> = 
        { data : EdgeData
          tail : Vertex<'V> }
    
    type Graph<'V> = 
        { name : Name
          vertices : Vertex<'V> List }

type WorkflowEvaluation = 
{
   name : string 
   model : Graph<WorkflowStep>  
}

結論
所有這些不同元素的組合構成了我們工作流程方案的基礎。雖然工作流DSL（Netflix Conductor，Apache Airflow等）允許在執行時定義工作流，但我們發現在編譯時定義工作流並透過源控制流程時，開發人員的實踐會得到改進。
上述F＃工作流模型允許透過F＃簽名檢查進行工作流驗證，以及能夠執行和預提交工作流步驟和DSL的測試，以確保在部署之前的正確性。透過將我們的工作流DSL與後端執行層分離，我們已經能夠演示以其他語言（javascript）和原始文字表達的工作流定義。