[Amazon Connect] 問い合わせフローの転送　〜その必要性と、問い合わせ属性の永続性について〜

1 はじめに

Amazon Connect(以下、Connect)の問い合わせフローは、複数に分割することが可能です。 今回は、その必要性なども含めて整理してみました。

2 単一の問い合わせフロー

サンプルとしての検討したのは、以下のようなフローです。受付などで、日付と時刻の入力を求めるものという想定です。

C:「こんにちは」
C:「日付を入力して下さい」
U: 1008
C:「入力された日付は、1008です。続いて時刻を入力する場合は、1を、もう一度、日付の入力をやり直す場合は、0を入力して下さい」
U: 1
C:「時刻を入力して下さい」
U: 1230
C:「入力された日付は、1008、時刻は1230です。入力を終了する場合は2を、もう一度、時刻の入力をやり直す場合は、1を、日付の入力からやり直す場合は0を入力して下さい」
U: 2
C:「終了します」

ざっくりと書いてみると、以下のようになりました。これぐらいであれば、図としても見やすいし、フローを追いかけるのも、それほど無理はないでしょう。

3 単一の巨大な問い合わせフロー

しかし、入力する項目は変わりませんが、エラー制御が追加されるとどうなるでしょうか・・・

エラーとしては、以下のようなものが思いつきます。

• ユーザーの入力がタイム・アウトする
• 日付(時刻)として矛盾する数字が入力された
• 日付(時刻)として4桁以下が入力された
• 選択肢以外の数字が入力された

エラーを制御するために、Lambdaで入力された内容を確認したり、条件分岐でエラーメッセージを案内すると、いきなり以下のようになってしまいました。

通常の要件では、日付・時刻の２項目ぐらいではなく、もっと多くの入力プロンプトが必要になると思います。そうなれば、問い合わせフローが、どんどん巨大になっていくことが用意に想像できます。

実は、書いてみると分かるのですが、このような大きな問い合わせフローは、非常に重くなります。ブロックを動かそうとしてもすぐには動かないし、プロパティを編集しようとしても、ひと呼吸置かないと開かなくなります。

また、フローの線が入り乱れてしまって、何処がつながっているのか、目視では判別できなくなっています。修正したくても、その場所にたどり着くのに一苦労しそうです。

4 フローへの転送

この問題を回避する方法は、問い合わせフローを分割することです。 １つの接続に関しても、機能ごとにフローを分けることで、上記の問題に対処する事ができます。

分割したフローへのジャンプは、終了/転送 の中の フローへの転送で行います。

ブロックでは、移動先のフローの名前を指定します。ここで、指定できるフローは、「保存して発行」されたフローのみです。全ての設定が完了しないと「保存して発行」は出来ませんが、それをしないと、別のフローで指定が出来ないので、まずは、使用するフローをとりあえずの設定でもいいので、「保存して発行」まで持っていくことが必要です。

5 簡単な転送

次のような簡単なフローを作成して、転送を試してみました。

FirstFLow プロンプトで「最初のフローです」とアナウンスした後、次のフローへ移行します。

SecondFlow

プロンプトで「二番目のフローです」とアナウンスした後、次のフローへ移行します。

ThirdFlow

プロンプトで「三番目のフローです」とアナウンスした後、切断されます。

転送に指定された各フローに親子関係はなく、サブルーチンのように、転送元に戻ることは出来ません。元のフローを転送先に指定することは可能ですが、フローの頭から実行されることになります。このため、サブルーチン的にフローを作りたい場合は、若干の考慮が必要です。

6 属性による指定

転送先のフローの指定は、リストのからの選択以外に、属性によりる指定が可能になっています。

しかし、ここで指定する文字列は、ログから確認して分かるように、フローのarnです。予め移転先のフローのarnを把握し、属性などで管理している場合に利用可能です。

7 問い合わせ属性

フローの実行中に保存された問い合わせ属性は、次のフローに移転しても、全て有効です。

試験的に、最初のフローで、問い合わせ属性を設定します。

FirstFlow

そして、それを三番目のフローで読み上げることが可能です。

ThirdFlow

この仕組も非常に便利ですが、同じくサブルーチンのようにフローを扱いたい場合は、属性（変数）のスタックの仕組みは、自分で構築する必要がありそうです。

8 最後に

今回は、Connectにおける問い合わせフローの分割について確認してみました。 大きくなって、こんがらがる前に、最初から分割を検討して作成する必要性を感じています。