LogicApps/Flow で JSON を受け取る際のあれこれ

Logic Apps や Flow を利用するシーンとして、外部から JSON 値を渡してもらい色々と処理を行うケースというのが多々あります。その際、Logic Apps/Flow としては、スキーマを定義しておくことで LogicFlow の作成が楽になるという点があるのですが、このスキーマ作成は開発者でなければ戸惑うところの筆頭でもあります。

色々な形を試してみて、利用する際に注意する場面をまとめてみました。

1.JSON スキーマを定義しない方法のメリット

そもそもスキーマを定義しない状態だとどうなるかというと、実際にはダイアログから指定ができないだけで、渡された値の参照などは可能です。また要求トリガ（HTTP Request）にはスキーマを設定せずに値を受け取るようにし、後続処理で JSON を解析するという処理の流れも場合によって有用です。

この方法のメリットは、受信する際にどのようなデータでも受取が可能ですので、複数種類のデータを受け取る処理の入り口を定義する場合に有用です。

2.JSON スキーマをサンプルから作成する場合の注意

Logic Apps/Flow において、スキーマ生成は多くの人がサンプルデータから作成することと思います。非常に便利なこの機能ですが、その挙動においては若干注意する箇所があります。

上記のように、ある値が配列を持つ場合の挙動です。

{
     "type": "object",
     "properties": {
         "type": {
             "type": "string"
         },
         "text": {
             "type": "string"
         },
         "property": {
             "type": "array",
             "items": {
                 "type": "object",
                 "properties": {
                     "optionsA": {
                         "type": "integer"
                     },
                     "optionsB": {
                         "type": "string"
                     }
                 },
                 "required": [
                     "optionsA",
                     "optionsB"
                 ]
             }
         }
     }
}

サンプルデータを投入すると、上記のようなスキーマが生成されます。一見問題なさそうなスキーマですが、配列となっている箇所に required 属性が設定され、必須項目が初期値となります。JSON に限らず、配列であろうと必須ではないケースもありますので、配列を含んだ値からスキーマ生成する場合は、必須項目の調整が必要です。

3.JSON 解析で想定していない値がきても検知できない

JSON 解析アクションで、スキーマとデータをぶつけた際、スキーマ上で定義していない値があっても特にエラーはなりません。定義していない値が来るのを防ぐには、HTTP Request 要求トリガにスキーマを定義し、設定からスキーマ検証を ON にする必要があります。

ただしこれは悪いこととは言い切れないもので、例えば呼び出し先の API がバージョンアップされ、何かしらの新しい値が連携されるようになったとしても、LogicFlow 側の修正は不要だということになります。

4.すべてのパターンを兼ねる JSON スキーマの作り方

Logic Apps/Flow で多く必要になるケースは、これではないでしょうか。色々な API を利用しようと思ったけども、公式ドキュメントにはスキーマが掲載されていないので、自分で作成しようとしても、どうすればよいかわからないことも多々あるかと思います。

流れとしては、大体以下のような形でやることが多いです。

• A.サンプルデータを入手
• B.別のサンプルデータを入手。A のデータとマージする
• C.以降同様に、予定するすべてのサンプルデータをマージする

例えば

パターン A

{
   "type": "message",
   "text": "sample text",
   "property": [
     {
       "optionsA": 0,
       "optionsB": "1"
     }
   ]
}

パターン B

{
   "type": "message",
   "text": "sample text",
   "timestamp": "2018-08-13T13:00:00.0000000Z"
}

というサンプルデータがあった場合、この二つをマージして次のように用意します。

{
   "type": "message",
   "text": "sample text",
   "property": [
     {
       "optionsA": 0,
       "optionsB": "1"
     }
   ],
   "timestamp": "2018-08-13T13:00:00.0000000Z"
}

A に存在しない B のデータを、後ろに加えていく形です。その際、A のデータの末尾に , を付ける必要があります。

何かしらの API に対応しようとした場合、この作業を繰り返し行うことで必要なパターンをすべて網羅したスキーマを作成することが可能です。LINE Messaging API などはこの方法で、全メッセージに対応可能なスキーマを作成できます。

サンプルデータが作成できたら、実際にスキーマを作成させます。スキーマを設定できたら、何度か実行を行い、予定したとおりにデータを利用できるかを確認してください。

特に起きやすいのは必須項目（required）指定です。２の項目でも書きましたが、ここの調整を行う必要が多いです。場合によっては、すべての required 指定を削除することもありえるのですが、異常なデータ連携のためにも、本当に必要な項目には reqired 指定を行うようにしてください。