[Amazon Connect] Lambda関数を呼び出した際のログを確認する　〜エラーや戻り値の確認などについて〜

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内のキーの順番が、セッションごとに変化することが原因です。

時系列では、ちゃんと並んでいるので気にしないようにするしか無いでしょう。でも、１つのセッション内では同じのようなので、セッションの区別には逆に役立つかも知れません。