Architectフローサイズ

使用フローサイズArchitect フローのサイズを追跡および管理し、設計プロセス中にフローを積極的に整理および最適化します。フロー サイズが提供する洞察により、次の作業が容易になります。

  • フロー内の各要素がフロー全体のサイズにどのように影響するかを理解します。
  • リソースを大量に消費するフロー コンポーネントを特定し、設計の初期段階で調整または簡素化します。
  • フローのサイズが制限に達する前に、フローを複数のフローに分割するタイミングをタイムリーに決定します。

アクセスフローサイズ建築家> [選択したフロー] >洞察と最適化メニュー。

画像をクリックして拡大します。

フローサイズの洞察

フローサイズ表示

フローを構築する際、フローのサイズインジケータを使用してフローのサイズを追跡できます。洞察と最適化

Architect における高フローサイズの使用を示すインジケーター

フローサイズタブには、フローが現在最大許容フロー サイズをどれだけ使用しているかを視覚的に表す水平バーが含まれます。バーの充填レベルと色は使用頻度を示します。Architect は、フロー サイズ アイコンの色もそれに応じて調整し、現在のフロー サイズの状態に関する視覚的なフィードバックを即座に提供します。

この表は4つのフローサイズ警告を記述したものです:

サイズ表示 達成率 インジケーターの色 制限
許容最大サイズの30%未満 なし
許容される最大サイズの30% 黄色 なし
最大許容サイズの70% なし
フル 最大許容サイズの98%

フローを公開することはできませんが、変更を保存することはできます。

注記:フローが許容される最大サイズの 100% に達した場合、フローを保存することはできませんが、エクスポートすることはできます。

メモ: 
  • コモンモジュールフローは、他のフロータイプよりもサイズ制限が低くなっています。
  • 要素がエラー状態になったりエラー状態から回復したりすると、フロー サイズが増減する可能性があります。たとえば、タスク内のアクションがエラーの場合、フロー サイズにはカウントされません。エラーを解決すると、アクションが検証され、フロー サイズにカウントされるようになります。フロー内の複数のアクションに同時に影響するエラーを解決する場合、サイズの追加が大きくなる可能性があります。
  1. 洞察と最適化、 クリックフローサイズ。フロー サイズ ウィンドウの右上隅に、全体のサイズ使用量がパーセンテージで表示されます。
  2. 各要素タイプの寄与率や数などの詳細を表示するには、パーセンテージ アイコンにマウスを置きます。 Architect における高フローサイズの使用を示すインジケーター

注記:フローサイズインジケーターの精度は 0.1% 以内です。Architect は、フロー サイズの小数点値の最初の桁を表示するので、フロー ロジックの小さな変更がフロー サイズにどのような影響を与えるかを確認できます。Architect は、フロー サイズのパーセンテージを最も近い 1 桁の小数値に丸めます。たとえば、実際のパーセンテージが 10.68 の場合、フロー サイズ インジケーターには 10.7 と表示されます。

個々のフロー要素による貢献度の内訳を表示し、より多くのリソースを消費するコンポーネントを特定できます。

要素の内容とそのサイズの寄与を表示するには:

  1. 洞察と最適化、 クリックフローサイズ
  2. 「フロー サイズ」ページで、検索ボックスに開きたい要素の名前を入力します。
  3. (オプション)種類要素タイプに基づいて検索結果をフィルタリングするオプション。たとえば、タスクタスク要素を検索する場合は、フィルター オプションで選択します。
  4. 要素の名前をクリックします。 
    要素の内容と、フローのサイズに対する割合を表示できます。たとえば、タスク要素を選択すると、アクションのリストをドリルダウンして、各アクションのサイズを見つけることができます。
  5. (オプション)クリック移動フロー内の特定の要素、アクション、または設定に移動します。

メモ: 
  • ナレッジは自然言語理解 (NLU) ツリーに属しますが、フローの合計サイズの計算に考慮され、フロー要素タイプ「設定」の下に表示されます。
  • アクションはタスクの一部としてカウントされます。

これらのヒントは、フローのサイズを減らすのに役立ちます。

  • それぞれが1つの更新ステートメントを持つ行に複数のデータ更新アクションがある場合は、アクションを複数の更新ステートメントを含む1つのデータ更新アクションに統合します。
  • 重複を避けてください。入力、成功出力、失敗出力の構成方法によっては、データ アクションの呼び出し、セキュア データ アクションの呼び出し、スクリーン ポップの設定、コールバックの作成、データ アクションの呼び出しなどの特定のアクションが大量のスペースを消費する可能性があることを考慮してください。
    いくつかの異なる設定を除いて、基本的に同じ構成の同じアクションのインスタンスが複数ある場合は、アクションのインスタンスを 1 つにするようにロジックを更新し、変数を使用して変更される値を渡すことがベスト プラクティスとして推奨されます。この方法は、フローのサイズを縮小するとともに、将来的に保守性が向上します。以前はアクションのすべてのインスタンスで共通だった設定を変更する必要がある場合、今後はアクションの単一のインスタンスでのみ設定を更新する必要があります。