ワークフロー定義言語を使用して Azure Logic Apps ワークフローを記述する

JSON ドキュメントを使って、Azure Logic App ワークフローの構造とワークフローを定義します。 このドキュメントには、ロジック アプリのワークフローを構成し、ワークフロー定義言語スキーマで検証される要素の JSON の記述が含まれています。 スキーマを説明する最も簡単な方法は、Azure portal でワークフロー デザイナーを使って作成された既存のワークフローを調べてから、ロジック アプリの JSON 記述を表示することです。

サンプル シナリオでは、あなたはコンサルタントに、担当している大学の特定のニーズに適合させることができる一般的なワークフローを提供することを考えています。 各ワークフローのカスタマイズとデプロイをできる限り簡単にするため、ワークフローの背後にあるコード、つまりワークフロー定義 JSON を調べることにしました。

ワークフロー デザイナー

ワークフロー デザイナーを使うと、ロジック アプリのワークフローを視覚的に作成およびデバッグできます。 また、デザイナーを使うと、開発者はワークフローを念入りに調べて、実装する方法を確認することもできます。 次の図では、指定した URL に HTTP GET 要求を送信することによってトリガーされる単純なワークフローの例を示します。 HTTP 応答で結果が返されます。 この例では、単純な Hello Logic Apps Template! メッセージを送り返すというワークフローです。

ここで、JSON テンプレートで使用されるワークフロー定義言語を見てみましょう。

[コード ビュー]

[コード ビュー] ウィンドウには、ワークフローを記述する JSON ドキュメントが表示されます。 サンプル アプリの JSON は次のようになります。

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Response": {
                "inputs": {
                    "body": "Hello Azure Logic Apps Template!",
                    "statusCode": 200
                },
                "kind": "Http",
                "runAfter": {},
                "type": "Response"
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "parameters": {},
        "triggers": {
            "manual": {
                "inputs": {
                    "method": "GET",
                    "schema": {}
                },
                "kind": "Http",
                "type": "Request"
            }
        }
    }
}

デザイナーで示されている、アクションとトリガーに関連する definition スコープ内のセクションに注目してください。 このドキュメントの JSON コードを編集して、ロジック アプリ ワークフローの機能で必要なすべての変更を反映することができます。 さらにアクションを追加し、ワークフロー内のロジックが次から次にアクションを実行する方法を指定することもできます。

Triggers セクション

triggers セクションには、トリガーの種類とそれを呼び出す方法の説明が含まれています。 この例では、トリガーは HTTP GET 要求に応じて実行する単純な HTTP トリガーです。

"triggers": {
    "manual": {
        "inputs": {
            "method": "GET",
            "schema": {}
        },
        "kind": "Http",
        "type": "Request"
    }
}

トリガーには次の要素を含める必要があります。

• ワークフロー内で一意の名前。 前の例で、トリガーの既定の名前は manual ですが、もっとわかりやすい識別子に既定の名前を置き換えることができます。

• トリガーの種類。 種類は、トリガーを実行するイベントを示します。 Request トリガーは、HTTP 要求に応答して実行します。 他に、次のトリガーの種類を使用できます。

  • Recurrence: 定期的なスケジュールに従って実行するトリガーを作成します。

  • HttpWebhook: エンドポイントでイベントをリッスンします。

  • ApiConnection: 他の Azure サービス (メッセージ キュー、メール メッセージなどに到着するメッセージなど) によってトリガーされるイベントに応答します。 ApiConnection トリガーの種類は汎用化され、サービスの種類および必要なすべての接続情報を示すさらなる詳細を指定します。

• inputs セクション。 このセクションでは、トリガーの動作を定義するデータを指定します。 Request トリガーの場合、method はトリガーを実行する HTTP 要求の種類を示します。 ApiConnection トリガーの場合、inputs セクションにはイベントをトリガーするリソースへの接続方法に関する情報が含まれます (メッセージ キュー接続文字列など)。 トリガーが Request トリガーの場合、入力定義の schema セクションでは、要求本文のペイロードが準拠すべきスキーマを指定します。 HTTP GET 要求には要求本文がないため、前の例の schema は空です。

次の例では、ワークフローを開始して HTTP POST 要求を受信する別の Request トリガーの定義を示します。 通常、POST 要求は、投稿されるデータを含む要求本文を提供します。 この例では、要求本文には顧客の名前と、市区町村と番地で構成される住所が含まれています。

"mypostrequest": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      "method": "POST",
      "schema": {
         "type": "object",
         "properties": {
            "customerName": {
               "type": "String"
            },
            "customerAddress": { 
               "type": "Object",
               "properties": {
                  "streetAddress": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

トリガーでは条件も指定できます。 これらの条件が満たされた場合にのみ、トリガーが起動します。 条件は省略可能な conditions セクションで定義します。 たとえば、要求本文で mypostrequest 市を指定した場合にのみ、(前の例で示されている) New York トリガーを実行することができます。

"mypostrequest": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      ...
   }
   "conditions": [
      {
        "expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], 'New York')"
      }
   ]
}

Actions セクション

ロジック アプリの actions セクションでは、ワークフローのロジックと構造体を定義します。 このセクションには一連の "アクション" が含まれます。 アクションは、ワークフローを構築するための基本的な構成要素です。 アクションは入力を受け取って出力を生成します。これがワークフローの次のアクションに渡されます。 次の表は、使用できるさまざまなアクションの種類の一覧です。

トリガーと同様、各アクションにはワークフロー内で一意の名前が必要です。 次の例では、既定のアクション名は Response ですが、もっと有効でわかりやすい識別子を使用できます。 アクションには、アクションで使用するデータを指定する inputs セクションが必要です。 Response アクションでは、応答メッセージで返される式のデータと、HTTP の状態コードを指定できます。

この基本的なワークフローの定義では、アクションによって本文が短いメッセージである HTTP 応答が生成されます。

"actions": {
    "Response": {
        "inputs": {
            "body": "Hello Azure Logic Apps Template!",
            "statusCode": 200
        },
        "kind": "Http",
        "runAfter": {},
        "type": "Response"
    }
}

runAfter セクションでは、ワークフロー シーケンス内でアクションが実行される場所を示します。 前の例では、1 つのアクションしかないため、トリガーの起動時にそれが常に実行されます。 ワークフローに複数のアクションがある場合は、アクションの名前とそのアクションの状態をこのセクションで指定できます。 runAfter アクションが指定された状態で完了すると、このアクションが実行されます。 次のコードは例を示します。 アクション mySecondAction は、myFirstAction が myFirstAction の状態で終了した場合にのみ、Succeeded の後に実行されます。

"actions": {
    "mySecondAction": {
        "inputs": {
            ...
        },
        "runAfter": {
            "myFirstAction": [
                "Succeeded"
            ]
        },
        "type": ...
    },
    "myFirstAction": {
        "inputs": {
            ...
        },
        "runAfter": {},
        "type": ...
    }
}

Outputs セクション

outputs セクションを使用して、実行が完了したときにワークフローが返すことができるデータを定義します。 ワークフローを実行するたびに特定の状態またはデータを追跡できます。 Azure Logic Apps の実行履歴 (Azure portal または Workflow REST API で入手可能) を使って、ワークフローの各実行からの出力を調べることができます。

outputs セクションの形式は次のようになります。

"outputs": {
  "<key-name>": {
    "type": "<key-type>",
    "value": "<key-value>"
  }
}

ワークフローの式

任意の固定値、変数、または定数の代わりに、ワークフローの式を使うことができます。 また、式の前にアットマーク (@) を付けることによって、JSON 文字列値の任意の場所に式を配置することができます。 たとえば、式で @parameters 関数を使用して、名前付きパラメーター (パラメーターは次のセクションで説明します) の値を取得できます。

"customerFullName": "Bill Frost",
"accountName": "@parameters('customerName')"

Azure Logic Apps には、複雑な式の作成に使用できる組み込み関数があります。

• 文字列関数:文字列の連結または分割、文字の大文字または小文字への変換、部分文字列の検索を行います。
• コレクション関数:コレクションに特定のパターンに一致する項目が含まれているかどうかの検出、コレクションからの項目の取得、コレクションの組み合わせを行います。
• 論理比較関数:オペランドを互いに比べたときに、同じか、異なっているか、数値的に大きいか、または小さいかを検出します。
• 変換関数:データの種類または形式を変更します。
• 算術関数:add、sub、div、mul など。
• 日付と時刻関数:日付と時刻を解析および処理します。
• ワークフロー関数:ワークフロー アクションに渡されるデータに関する情報を取得します。 たとえば、(前に示した) parameter 関数を使用すると、名前付きパラメーターの値がフェッチされ、(前に示した) body 関数を使用すると、アクションによって生成されたデータが返されます。
• JSON および XML 操作関数:JSON および XML ドキュメントを解析および処理します。

inputs アクションの InitializeVariable セクションで変数を定義して、式を使ってこれらの変数を操作することができます。 variables 関数を使って変数の値を読み取ります。 次の例では、InitializeVariable アクションを使用して、myIntegerVariable という名前の整数型の変数を作成し、それを 99 に初期化しています。 この例では、また、Condition 型の If アクションが示されています。 条件で式を使用して、myIntegerVariable 変数値をテストし、それが値 100 と一致すると、条件が HTTP アクションを使用して GET 要求を実行します。

"actions": {
    "Condition": {
        "actions": {
            "HTTP": {
                "inputs": {
                    "method": "GET",
                    "uri": "http://dummyurl.com"
                },
                "runAfter": {},
                "type": "Http"
            }
        },
        "expression": {
            "equals": [
                "@variables('myIntegerVariable')",
                100
            ]
        }        ,
        "runAfter": {
            "Initialize": [
                "Succeeded"
            ]
        },
        "type": "If"
    },
    "Initialize": {
        "inputs": {
            "variables": [
                {
                    "name": "myIntegerVariable",
                    "type": "Integer",
                    "value": 99
                }
            ]
        },
        "runAfter": {},
        "type": "InitializeVariable"
    }
}

parameters セクション

parameters セクションでは、ワークフローをパラメーター化することができます。 実行時に、これらの各パラメーターに値を指定できます。 定数または式を使うワークフロー内の任意の場所のパラメーターを参照できます。

既定値でパラメーター定義を追加することができます。 実行時にパラメーターの値を指定しない場合は、既定値が使用されます。 次の例では、cityParam という名前のパラメーターを定義する方法を示しています。 そのパラメーターは、mypostrequest アクションの条件内で使用されます。 要求ドキュメントにパラメーターの値と一致する都市が含まれている場合にのみ、アクションが実行されます。 パラメーターの既定値は New York です。

    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            ...
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "parameters": {
            "cityParam": {
                "defaultValue": "New York",
                "type": "String"
            }
        },
        "triggers": {
            "mypostrequest": {
                "conditions": [
                    {
                        "expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], parameters('cityParam'))"
                    }
                ],
                "inputs": {
                    ...
                },
                "kind": "Http",
                "type": "Request"
            }
        }
    }
}