この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
1 はじめに
Amazon Connect(以下、Connect)で、問い合わせフローを作成する場合、条件による分岐や、値を保持することが可能ですが、残念ながら計算ロジックを組み込むことは出来ません。
カウンターのような変数を作ったとしても、これを数値としてインクリメントするようなことは出来ません。
そして、フローの中で出来ないことを処理するのが、統合の中にあるAWS Lambda関数を呼び出すです。
今回は、このブロックからLambda関数を呼び出した際のログから、戻り値やエラーの確認要領についてまとめてみました。
2 Lambdaサンプル
最初に、下記のような超簡単なLambda関数を作成し、動作を見ていきます。
Connectから受け取った引数をログに残し、「Key：outputData、Value:200」を返すだけの関数です。
exports.handler = async (event) => {
console.log(JSON.stringify(event));
return {"outputData": "200"}
};この関数を呼び出す側のブロックでは、「Key:data、Value:100」をLambdaへのパラメータとしてセットしています。
3 labmda ログ
このLambda関数が呼び出された際、CloudWatch Logsには、次のようなログが記録されます。
関数の先頭で、Lambdaに渡された引数をログに出力していますが、この中を見ると、パラメータとして送られたデータはもちろんですが、それ以外にもSystemの属性などが格納されています。
上記のログには含まれていませんが、Details.ContactData.Attributesには、ユーザー定義の属性が入っていますので、問い合わせフローの中でユーザー属性として保存されている値は、わざわざパラメータで渡す必要はありません。
4 Connect ログ
Connectでは、ログ記録の設定というブロックでログ記録を有効（無効）化できます。
ログ記録を有効にした場合、各ブロックごとにログが出力されますが、AWS Lambda関数を呼び出すでも、以下のようなログが記録されます。
ここでは、パラメータとして渡した値と、戻り値を確認することが出来ています。
5 エラー
ここまでは、Lambdaの呼び出しが正常に行われた場合の話でしたが、Lambda関数の内部でエラーとなった場合も確認してみます。
下記のように、const変数の変更して例外を発生させてみます。
exports.handler = async (event) => {
console.log(JSON.stringify(event));
const x = 0;
x = 1; //<= const変数を上書き
return {"outputData": "200"};
};Connectのログでは、ExternalRequslの代わりに Result が追加され、 "The Lambda Function Returned An Error." が記録されました。これで、Lambdaの実行がエラーとなっていることが分かります。
しかし、Connect側のログでは、Lambdaの中で何がエラー担っているのかまでは当然分かりません。こちらはLambdaのログを確認するしかないでしょう。
6 ARNの指定誤り
例えば、LambdaのARNの指定を誤った場合、どうなるでしょうか・・・
正しいファンクション名sample001ですが、ここで smaple002に変更してみました。
この場合、Connectのログでは、やはり、ExternalRequslは無く、 Result に "Status Code: 403; Error Code: AccessDeniedException; RequestId: xxxxxxxx" と表示されていました。
ここは、401となると嬉しいところですが・・・
当然ですが、Lambdaはコールされていないので、ログはありません。
7 Lambdaのパーミッション誤り
ConnextからLambdaを実行する場合、パーミッションが必要です。
Using AWS Lambda Functions with Amazon Connect
このパーミッションが設定されていない時も、上記の「ARNの指定誤り」と同じ状況となります。ログからは判別ができないので注意が必要です。
403（リソースへのアクセス拒否、アクセス禁止、アクセス権利など）は、ARN誤りでは、ちょっとピンときませんが、ここでは、パーミッションなしと言う事でしっくり来ます。
8 最後に
今回は、AWS Lambda関数を呼び出すからLambdaをコールした場合のログについて確認してみました。比較的分かりやすいログなので、特に迷子になることは無いのではと感じました。
なお、Lamndaに直接関係ありませんが、Connectのログは、下記のようにメッセージのところの統一感がありません。これは、Json内のキーの順番が、セッションごとに変化することが原因です。
時系列では、ちゃんと並んでいるので気にしないようにするしか無いでしょう。でも、１つのセッション内では同じのようなので、セッションの区別には逆に役立つかも知れません。
4
