Azure Logic Apps のワークフロー定義言語のスキーマの更新 - 2016 年 6 月 1 日

適用対象: Azure Logic Apps (従量課金)

最新のワークフロー定義言語スキーマ バージョン 2016 年 6 月 1 日および Azure Logic Apps 用 API バージョンには、従量課金プラン ロジック アプリ ワークフローをより信頼性の高い、使いやすいものにする以下の重要な改良が含まれています。

• スコープにより、複数のアクションを一連のアクションとしてグループ化したり、入れ子したりできるようになりました。
• 条件とループがアクションに昇格。
• runAfter プロパティ (dependsOn の後継) でアクションの実行順序をより正確に定義できるようになりました。

以前のワークフロー定義を現在のスキーマにアップグレードするには、「スキーマのアップブレード」を参照してください。

スコープ

このスキーマにはスコープが含まれており、アクションをまとめてグループ化したり、入れ子にできます。 たとえば、1 つの条件に別の条件を含めることができます。 スコープの構文の詳細を確認するか、以下のコードで基本的なスコープの例を確認してください。

{
   "actions": {
      "Scope": {
         "type": "Scope",
         "actions": {
            "Http": {
               "inputs": {
                   "method": "GET",
                   "uri": "https://www.bing.com"
               },
               "runAfter": {},
               "type": "Http"
            }
         }
      }
   }
}

条件とループに関する変更

以前のバージョンのスキーマでは、条件とループはパラメーターとして単一のアクションに関連付けられていました。 このスキーマではその制限が廃止され、条件とループはアクションのタイプとして利用できるようになりました。 ループおよびスコープと、条件の詳細を確認するか、条件アクションを示すこの基本的な例を確認してください。

{
   "Condition - If trigger is some trigger": {
      "type": "If",
      "expression": "@equals(triggerBody(), '<trigger-name>')",
      "runAfter": {},
      "actions": {
         "Http_2": {
            "inputs": {
                "method": "GET",
                "uri": "https://www.bing.com"
            },
            "runAfter": {},
            "type": "Http"
         }
      },
      "else": 
      {
         "Condition - If trigger is another trigger": {}
      }  
   }
}

runAfter プロパティ

dependsOn プロパティが runAfter プロパティに置き換えられ、前のアクションの状態に基づいてアクションの実行順序をより正確に指定できるようになりました。 dependsOn プロパティでは、アクションを実行したかった回数ではなく、前のアクションが成功したか、失敗したか、スキップされたかに応じて "アクションが実行され成功した" かどうかが示されていました。 runAfter プロパティを使えば、オブジェクトの実行後のアクションをすべて名前で指定できるため、オブジェクトとしての柔軟性が大きくなります。 このプロパティでは、トリガーとして許容される状態の配列も定義します。 たとえば、アクション A が成功し、かつ、アクション B が成功または失敗した後でアクションが実行されるようにする場合には、次のような runAfter プロパティを設定します。

{
   // Other parts in action definition
   "runAfter": {
      "A": ["Succeeded"],
      "B": ["Succeeded", "Failed"]
    }
}

その他の変更点

manual トリガーの名前を request トリガーに変更

manual タイプのトリガーが非推奨となり、http タイプの request に名前が変更されました。 これにより、このトリガーを使用して構築されるパターンとの一貫性が向上しました。

新しい 'フィルター' アクション

大きな配列のサイズを小さくして、より小規模な一連のアイテムにするには、filter というタイプを使用します。このタイプは、配列と条件を受け取り、各アイテムを条件に照らして評価し、条件を満たしたアイテムの配列を返します。

foreach と until アクションの制限

foreach と until ループは、単一のアクションに制限されます。

アクションの trackedProperties

アクションには runAfter プロパティや type プロパティの兄弟である trackedProperties という追加のプロパティがあります。 ワークフローの一環として出力される Azure 診断のテレメトリに含める特定のアクションの入力または出力を、このオブジェクトで指定します。次に例を示します。

{
   "Http": {
      "inputs": {
         "method": "GET",
         "uri": "https://www.bing.com"
      },
      "runAfter": {},
      "type": "Http",
      "trackedProperties": {
         "responseCode": "@action().outputs.statusCode",
         "uri": "@action().inputs.uri"
      }
   }
}

スキーマのアップグレード

古いワークフロー定義言語スキーマを使っている従量課金プランのロジック アプリ ワークフローがある場合は、最新のスキーマを使うようにワークフローを更新できます。 この機能は、従量課金プランのロジック アプリ ワークフローにのみ適用されます。 最新のスキーマにアップグレードするには、いくつかの手順を行うだけです。 アップグレード プロセスでは、アップグレード スクリプトを実行し、元のロジック アプリ ワークフローを新しい従量課金プラン ロジック アプリ ワークフローとして保存します。必要な場合は元のロジック アプリ ワークフローを上書きすることがあります。

ベスト プラクティス

次の一覧では、ロジック アプリ ワークフローを最新のスキーマに更新するための主なベスト プラクティスを示します。

• テストが完了し、更新されたワークフローが期待どおりに動作することを確認するまで、元のワークフローを上書きしないでください。

• 更新されたスクリプトを新しいロジック アプリ ワークフローにコピーします。

• 運用環境にデプロイする "前に" ワークフローをテストします。

• 移行が正常に完了したことを確認した後、可能な場合は、最新バージョンの Azure Logic Apps のマネージド コネクタを使うようにロジック アプリ ワークフローを更新します。 たとえば、古いバージョンの Dropbox コネクタを最新バージョンに置き換えます。

ワークフローのスキーマを更新する

スキーマを更新するオプションを選ぶと、Azure Logic Apps によって自動的に移行ステップが実行され、必要なコード出力が提供されます。 この出力を使って、ワークフローの定義を更新できます。 ただし、この出力を使ってワークフローの定義を更新する前に、「ベスト プラクティス」セクションで説明されているベスト プラクティスを確認し、それに従ってください。

1. Azure portal で、従量課金ロジック アプリ リソースを開きます。

2. ロジック アプリのリソース メニューで、 [概要] を選択します。 ツール バーで [スキーマの更新] を選びます。

   注意

   [スキーマの更新] コマンドを使用できない場合、ワークフローでは最新のスキーマが既に使われています。

   

   [スキーマの更新] ページが開き、現行のスキーマの改良点について書かれたドキュメントへのリンクが表示されます。 返されたワークフロー定義をコピーして貼り付けることができます。この定義は、必要に応じてロジック アプリのリソース定義にコピーして貼り付けることができます。

3. アップグレード ウィンドウのツール バーで、[名前を付けて保存] を選択して、アップグレードされたロジック アプリ ワークフロー定義ですべての接続参照が有効なままになるようにします。

4. ロジック アプリ ワークフローの名前を指定し、状態を入力します。

5. [作成] を選択して、アップグレードしたロジック アプリ ワークフローをデプロイします。 アップグレードしたロジック アプリが正常に動作することを確認します。

   重要

   ワークフローで Request トリガー (以前は "manual" という名前) を使用している場合、アップグレードされたワークフローでこのトリガーのコールバック URL が変更されます。 新しいコールバック URL をテストして、エンド ツー エンドのエクスペリエンスを確認してください。 以前の URL をそのまま維持する場合には、既存のロジック アプリ ワークフローを複製しておきます。

6. 省略可能: 元のロジック アプリ ワークフローをアップグレードされたバージョンで上書きするには、ツール バーの [スキーマの更新] の横にある [複製] を選択します。

   このステップは、ロジック アプリ ワークフローのリソース ID または要求トリガーのコールバック URL をそのまま維持したい場合に必要となります。

アップグレード ツールの注意事項

リソース タグ

リソース タグはアップグレード後に削除されるので、アップグレード後のワークフローで設定し直す必要があります。

条件のマッピング

アップグレード ツールでは、アップグレード後のワークフロー定義で条件分岐アクションを可能な限り 1 つのスコープとしてグループ化しようとします。 具体的には、@equals(actions('a').status, 'Skipped') というデザイナー パターンが、else アクションとして表示されます。 ただし、認識できないパターンが検出された場合は、true の分岐と false の分岐について別個の条件が作成される可能性があります。 アップグレード後、必要に応じてアクションのマッピングを変更してください。

条件判定を伴う foreach ループ

アップグレードされたスキーマでは、フィルター アクションを使用することで、項目ごとに 1 つの条件が設定された For each ループを使用するパターンをレプリケートすることができます。 ただし、変更はアップグレード時に自動的に行われます。 このような条件は、For each ループに先行して表示されるフィルター アクションに置き換えられます。つまり、このフィルター アクションによって、条件に一致したアイテムの配列のみが取得され、その配列が For each アクションに渡されます。 例については、ループとスコープに関する記事を参照してください。

次のステップ

• ロジック アプリのワークフロー定義の作成
• ロジック アプリ デプロイを自動化する