LogicApps でのエラー対応

LogicFlow の仕組みとして、直前のアクション結果に基づいた処理分岐が用意されています。これを利用すると、あるアクションが成功した場合と失敗した場合とで処理を分岐させることができ、一般的なエラー対応を行えるようになります。

これまでの投稿の中で、LogicFlow をコードビューで見た際にだけ記述できる runAfter という値を扱ったことがあります。エラー処理を行う場合にも、runAfter の値を用いで行います。

まず簡単な例として、呼び出された際に適当な HTTP ステータスを返却する Azure Function App を用意します。このような検証ですと、速攻で用意できる Azure Function App は本当に便利ですが、VB 使いとしては（

例えば正常な結果を返すテスト用にはこのような形で用意します。

失敗した結果を返すテスト用ですと、次のような感じになります。

見てもらうとわかるように、何もせずに HTTP ステータスを返却しているだけです。次はこれを用いる LogicFlow を作成します。

まずはデザイナー上で、HTTP Request コネクタ、HTTP コネクタ（本当なら Function App の検索で呼び出せればよかったのですが、なぜか今回は一覧に表示されず……）、そして正常時の応答を返す HTTP Response コネクタと、異常時の応答を返す HTTP Response コネクタを用意します。

そして Code View で直接 JSON 定義を編集します。上記の状態では以下のような定義になります。

{
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
        "HTTP": {
            "inputs": {
                "method": "GET",
                "uri": "https://kumafunc.azurewebsites.net/api/FromLogicFlowHTTP"
            },
            "runAfter": {},
            "type": "Http"
        },
        "応答": {
            "inputs": {
                "body": "Called OK",
                "statusCode": 200
            },
            "runAfter": {
                "HTTP": [
                    "Succeeded"
                ]
            },
            "type": "Response"
        },
        "応答_2": {
            "inputs": {
                "body": "Called Bad Request",
                "statusCode": 400
            },
            "runAfter": {
                "応答": [
                    "Succeeded"
                ]
            },
            "type": "Response"
        }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "parameters": {},
    "triggers": {
        "manual": {
            "inputs": {
                "schema": {}
            },
            "kind": "Http",
            "type": "Request"
        }
    }
}

応答 と 応答_2 のコネクタ設定で、どちらも runAfter の値は「直近のコネクタが正常終了した」という条件を表しているのがわかるかと思います。エラー処理を行う場合、ここの条件を調整することで、対応が行えるようになります。

先程の JSON 定義を、下記のように書き換えます。

"応答": {
    "inputs": {
        "body": "Called OK",
        "statusCode": 200
    },
    "runAfter": {
        "HTTP": [
            "Succeeded"
        ]
    },
    "type": "Response"
},
"応答_2": {
    "inputs": {
        "body": "Called Bad Request",
        "statusCode": 400
    },
   "runAfter": {
        "HTTP": [
            "Failed"
        ]
    },
    "type": "Response"
}

応答 と 応答_2 のコネクタ設定のうち、応答_2 の方を「HTTP コネクタが失敗した」という条件になるよう runAfter の箇所のみ書き換えたものです。なお、ここで指定できる値ですが、

• Succeeded：成功
• Failed：失敗
• Skipped：スキップ

の 3 種類が利用できます。MSDN ではまだドキュメントの更新が追い付いていないようで、Aboted と書かれていますが、これは現在のスキーマでは利用できずにエラーとなりますので気を付けてください。

この状態に書き換えた後で、デザインビューへと戻ります。

すると、上記のように並列動作を定義したかのようなフローへと書き換わります。

このようにコネクタの runAfter 値を設定することで、直前のコネクタがエラーになった場合の処理を設定することができるようになります。

なお、上記の状態で、新しいステップを追加するとどうなるかというと。

このような状態となります。ここで Code VIew を見てもらうとわかりますが、並列に並んでいる二つのコネクタがどちらも正常終了した場合に、次のステップが実行されるように設定されています。今回のようなエラー処理の場合、何かしらのエラー処理を行った後に通常の流れと合流する、ということになりますので、このあたりの制御は注意してください。

またあまりにエラー処理を利用すると、LogicFlow が非常に複雑になりがちです。Scope を利用してある程度の処理をグループ化する、別の LogicFlow に分けるなどといった対応も必要に応じて行うと良いのではないでしょうか。

最後に、実際に LogicFlow を呼び出して、想定した値が返却されているかのスクショを張り付けておきます。