[Amazon Connect] Connectが東京リージョンに来たので、シドニーのコンタクトフローを移設してみました

1 はじめに

AIソリューション部の平内(SIN)です。

本日、東京リージョンで利用可能になったAmazon Connect(以下、Connect)では、コンタクトフローのエクスポート及び、インポートが可能です。(どちらも、現在ベータとなっています)

今まで、シドニーで運用していたインスタンスを、東京に移行するニーズも多くなるだろう、という事で、コンタクトフローの移設を試してみました。

2 移行対象のフロー

題材として、Lambda の実行を含んだフローで、2つのフローが連携して動作しているものを準備しました。

(1) 1つ目のフロー

1つ目のフローでは、Lambdaを実行して、2つ目のフローに遷移させてます。

exports.handler = async function(event, context) {
  console.log(JSON.stringify(event));
  return { message: "Lambdaのメッセージです" };  
}

(2) 2つ目のフロー

2つ目のフローでは、1つ目のフローで実行したLambdaの戻り値を、プロンプト再生した後、キューに入れています。

正常に動作すると、以下のような流れになります。

  • 接続
  • 「最初のフローです」
  • 「2つ目のフローです」
  • 「Lambdaのメッセージです」
  • キューでの待機

3 エクスポート

問い合わせフローエディタの「保存」ボタンから「フローのエクスポート(ベータ)」を選択すると、コンタクトフローをJSON形式のファイルに出力することができます。

取得したJSONを開いてみると、各ブロックが配列で定義され、ブロックごとに振られたIDで、それぞれが接続されているようすを確認できます。また、別のフローや、Lambdaなどは、それぞれのARNで指定されています。

ARNには、リージョンや、ConnectのインスタンスIDが含まれていますが、東京リージョンに移すことで、この辺がどのようになるか確認していきたいと思います。

1つ目のフローの抜粋

{
    "modules": [
        {
            "type": "SetVoice",
            "parameters": [
                {
                    "name": "GlobalVoice",
                    "value": "Mizuki"
                }
            ],
            ・・・略・・・
        },
        {
            "type": "SetLoggingBehavior",
            ・・・略・・・
        },
        {
            "type": "Transfer",
            ・・・略・・・
            "parameters": [
                {
                    "name": "ContactFlowId",
                    "value": "arn:aws:connect:ap-southeast-2:**********:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/f0cf67dc-81dd-4e06-a504-36251c248486",
                    "resourceName": "SampleSecond"
                }
            ],
            ・・・略・・・
        },
        {
            "type": "PlayPrompt",
            "parameters": [
                {
                    "name": "Text",
                    "value": "最初のフローです。",
                    "namespace": null
                },
            ],
            ・・・略・・・
        },
        {
            "type": "InvokeExternalResource",
            "parameters": [
                {
                    "name": "FunctionArn",
                    "value": "arn:aws:lambda:ap-southeast-2:**********:function:Relocation_hello"
                },
                {
                    "name": "TimeLimit",
                    "value": "3"
                }
            ],
            ・・・略・・・
    ],
            ・・・略・・・
    "type": "contactFlow",
    "start": "9639752f-7319-4106-b6ba-5317779db283",
            ・・・略・・・
}

4 インポート

東京リージョンにインスタンスを上げ、先のフローをインポートしてみます。

(1) 1つ目のフロー

問い合わせフローを新規に作成して、保存メニューから「インポート(ベータ)」を使用して、先のフローをインポートしてみます。

読み込んだフローを「保存して発行」とすると、エラーとなります。これは、2つ目のフローへの遷移ブロックがありますが、まだ2つ目のフローが読み込まれていないためのエラーのようです。 取り合えず、ここは「保存」としておきます。

(2) 2つ目のフロー

こちらも、「保存して発行」はエラーとなります。今度は、「キュー」が存在しないためです。ここも、一旦「保存」としておきます。

(3) キュー

キューについては、エクスポート・インポートが出来ないので、新規に作成する必要があります。

(4) 2つ目のフローの「保存して発行」

2つ目のフローに戻って、「保存して発行」をしてみましたが、やはりエラーとなってしまいました。恐らく、名前が同じでも、キューのARNが違うからだと思います。プロパティを開いて、選択リストの中からキューを選択しなおすことで、「保存して発行」が出来ました。

(5) 1つ目のフローの「保存して発行」

その後、1つ目のフローに戻っても、「保存して発行」はエラーでした。 こちらもフローのARNの違いでしょう。プロパティを開いて、選択リストの中からフロー名を選択し直する「保存して発行」が出来ました。

(6) Lambdaの移行

Lambdaのコードを東京リージョンにDeployして、Connectの東京リージョンのインスタンスにパーミッションを与えます。

「AWS Lambda関数を呼び出す」ブロックは、エラーとはなっていませんでしたが、リージョンが変化してARNが変わっているので、変更は必須です。

5 各種ID

ここで移設前と後の各種IDを確認してみると以下のようになっていました。

フロー内の各ブロックのIDは、そのままで、インスタンスIDがインポート先のインスタンスIDに書き換わっています。また、フローのIDは、新しく採番されています。

リソース リージョン ARN
1つ目のフロー シドニー arn:aws:connect:ap-southeast-2:{AWSアカウント}:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/d504ce50-e2ba-4596-969a-ba3981ed33d0
1つ目のフロー 東京 arn:aws:connect:ap-northeast-1:{AWSアカウント}:instance/7fd93104-c08b-4b6e-b4b8-105de9729995/contact-flow/f14e0a55-832f-4438-954c-0c18ceaca277
2つ目のフロー シドニー arn:aws:connect:ap-southeast-2:{AWSアカウント}:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/f0cf67dc-81dd-4e06-a504-36251c248486
2つ目のフロー 東京 arn:aws:connect:ap-northeast-1:{AWSアカウント}:instance/7fd93104-c08b-4b6e-b4b8-105de9729995/contact-flow/67119a4f-4fbc-4a42-9d75-9d20cb6a8344
キュー シドニー arn:aws:connect:ap-southeast-2:{AWSアカウント}:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/queue/d4168d1a-a64a-4cdd-8945-c3411289b786
キュー 東京 arn:aws:connect:ap-northeast-1:{AWSアカウント}:instance/7fd93104-c08b-4b6e-b4b8-105de9729995/queue/e0ec924b-d857-4128-bcc0-e712f99e63e4
Lambda シドニー arn:aws:lambda:ap-southeast-2:{AWSアカウント}:function:Relocation_hello
Lambda 東京 arn:aws:lambda:ap-northeast-1:{AWSアカウント}:function:Relocation_hello

5 最後に

今回は、リージョン間のコンタクトフローの移行を試してみました。

インスタンスIDについては、インポートで書き換わるので気にしなくても良さそうですが、フローやキューのIDが新たに採番されることに注意が必要そうです。

なお、LambdaのARN書き換えは、必須となります。

多くの場所にLambdaを配置しているような場合は、幸い、エクスポートしたコンタクトフローが非常にわかりやすいJSON形式なので、シェルなどで一発変換してからインポートした方が効率的かも知れません。

弊社では、「Amazon Connect」の導入を検討している方を対象とした無料相談会を毎週開催中です。

また、音声を利用した各種ソリューションの導入支援を行っております。お気軽にお問い合わせください。
チャットボット開発支援
クラウド型コンタクトセンターサービス導入支援

コメントは受け付けていません。