Kompira シリーズ間での架電情報の引き渡しについて

回答済み

コメント

23件のコメント

  • 正式なコメント
    Kompiraサポートチーム

    ご質問ありがとうございます。回答させていただきます。

    AlertHubのPigeonアクション単体では、受信メッセージに応じて使用するコールフローを変えることはできませんが、これを実現する方法はいくつかございます。

    ■ ルール・スコープ・アクションを複数作る方法

    使い分けるコールフローが2〜3個と十分に少ないようであれば、受信スロットに対して複数のルールを定義し、例えば「コールフローA」という文面が含まれる場合に「スコープA」にイベントを発行するルール、「コールフローB」という文面が含まれる場合に「スコープB」にイベントを発行するルール・・・といった形でそれぞれ別のスコープへイベントを発行する方法を取ることができます。

    あとはコールフロー毎に1つずつ別のアクションを定義しておき、スコープ毎に異なるアクションを呼び出すようトリガー設定を行うことで、受信したメッセージ内容に応じて呼び出されるアクションが変わり、コールフローの使い分けをすることができます。

    この方法は設定の数が増えるため煩わしいですが、設定の難易度は最も易しくなります。

    ■ Webhookアクションを用いてPigeonのAPIを呼び出す方法

    Pigeonアクションを使わずに、WebhookアクションによりPigeonの連絡実行APIを呼び出すことも可能です。Webhookアクションではリクエストボディ内にメッセージ受信内容や、その一部を抽出して挿入することができるので、コールフローIDを動的に変えてリクエストを送ることができます。

    この方法を取る場合、サービス外からPigeonのAPIを利用するのと同じくAPIトークンを発行し、X-Authorizationヘッダを指定してリクエストを送る必要がございます。

    ■ Kompira Enterpriseを使用する方法

    Kompira Enterpriseを使用する場合、AlertHubでWebhookアクションを用いてEnterpriseのWeb APIを呼び出すか、受信用のメールサーバーが用意できる場合はEnterpriseからそちらへ直接アクセスしてメールを受信する形でメッセージを受け取ります。

    メール本文を解析し、内容に応じてコールフローIDを決定する流れはEnterprise上に実装し、最終的にはEnterpriseからPigeonのAPIを呼び出すことで連絡実行を行う形となります。

    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    長く返答をしないままで申し訳ありませんでした。

    質問【20210824_1】
    2か月前にご教示いただいた、上記3パターンのうち、2パターン目はEnterprise を使わない方法かと存じます。
    Enterprise を使わずに、コールフローID の指定を動的に変える手法が分かりません。
    設定の流れをご教示願えますでしょうか?

    よろしくお願いいたします。

     

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    2パターン目で提示した方法は、curlコマンドにより手動でPigeonのAPIを呼び出すのと同等の動きをAlertHubのWebhookアクションにて実現する形となります。PigeonのAPIの呼び出し方に関しては Pigeon チュートリアル が最もわかりやすいかと思いますので、まずはこちらにお目通しいただいたうえで、下記の説明をお読みください。

    AlertHubのWebhookアクションでチュートリアルにあるようなAPI呼び出しをするには、下記のようにアクションを設定する必要があります。

    1. アクションの種類として「WEBHOOK」を選択
    2. 「Webhook URL」にPigeonの連絡実行APIのURLを入力
    3. 「HTTPメソッド」に「POST」を選択
    4. 「リクエスト本文」にAPIへの送信データを入力
    5. 「HTTPヘッダ」にヘッダ名「Content-Type」を値「application/json」で追加
    6. 「HTTPヘッダ」にヘッダ名「X-Authorization」を値「Token APIトークンの値」で追加

    このとき、手順4で入力する送信データはチュートリアルの例にならうと、下記の様になります。
    (実際のコールフロー・ガイダンスのIDや、ガイダンスの内容によってこの指定内容は変わります)

    {
      "params": {
        "callflowId": "049de6fc-c1a7-4963-af43-616cce2492c6",
        "guidanceId": "570e6f71-5459-43fe-a745-aa7d115ce20d",
        "parameters": {
          "server": "テスト用サーバー",
          "incident": "軽度の障害"
        }
      }
    }

    このとき、コールフローIDの指定を動的に変えるには「049de6fc-c1a7-4963-af43-616cce2492c6」の部分をパラメータ化する必要がございます。例えばトリガーの「パラメーター加工フロー」を用いて「callflowId」というフィールドにコールフローIDをセットした場合の全体の設定イメージは下記の画像のようになります。

    同様の流れにて、使用するガイダンスやガイダンス文面に展開するパラメーターも動的に決めることが可能です。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    時間が経ってしまって申し訳ありません。

    上記の

    ■ Webhookアクションを用いてPigeonのAPIを呼び出す方法

    を実践したのですが、400 Bad Request で返されました。
    何が悪いのかご教示いただけますか?
    "detail": "Invalid request payload", と出ていたので、リクエスト本文を以下に転記いたします。


    {
    "params":{
    "callflowId": "{{callflow}}",
    "guidanceId": "f682ad66-b641-4c59-bf04-9e745239d97e",
    "parameters":{
    "hostname": "{{hostname}}",
    "date": "{{date}}",
    "time": "{{time}}",
    "error": "{{error}}"
    }
    }
    }

    やりたかったことは、コールフロー数が増えてしまったので、
    ・コールフローを動的に変えて架電したい

    ・加工パラメータで一時保存されたデータも併せて動的に変えて架電したい

    です。よろしくお願いします。

     

    ステータスコード400 のボディ:

    { "type": "https://fixpoint.co.jp/probs/badrequest", "title": "Invalid request parameter(s)", "detail": "Invalid request payload", "instance": "/api/apps/pigeon/chain/invoke" }

    ヘッダ:

    Cache-Control no-cache, no-store, no-transform, must-revalidate, private, max-age=0
    Content-Length 168
    Content-Type application/json; charset=utf-8
    Date Fri, 01 Oct 2021 09:24:26 GMT
    Expires Thu, 01 Jan 1970 00:00:00 UTC
    Pragma no-cache
    Server nginx
    Vary Origin           

     

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    お世話になっております。

    いただいた情報から原因を絞り切るのが難しく予想となりますが、よくある失敗として {{callflow}} に展開する値としてコールフローのIDではなく、名前を入れてしまっているケースが考えられます。

    メールの内容、トリガーの「パラメーター加工フロー」の設定内容をご確認いただき、コールフローのID(ガイダンスIDと同様の36桁の形式となります)が取得できているかご確認ください。

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    上記ご説明拝読いたしました。
    再度よく読み直し、弊社はアラートメールの中で、Pigeonコールフローの「表示名」を使って
    ルールの正規表現でマッチングをし、
    パラメータ加工フローによって、Pigeonコールフローの「表示名」を抜き出しているので、
    Pigeonコールフローの「表示名」を使うのではなく、
    Pigeonコールフローの「コールフローID」を動的に利用するのかと推察いたしました。

    以下が弊社で本日再テストしてみた結果です。
    残念ながら、今度はルールが破棄されてしまいました。
    sakura editer で正規表現をためすとちゃんと検索されるのですが、何がわるいのでしょうか?
    また、何か勘違いがありますでしょうか?
    ご教示をお願いいたします。

    *----------------------------------------------------------------------------------*
    【受信スロットに入ったアラートメール】(一部)

    callflow: 73021c20-78a3-42d7-8cea-df7802d86cff

    hostname:xxxxxxxxxxxxxxxxxx 
    date:2021/09/03
    time:11:01:19
    error:種別    :システム       ソース   :Schannel 

    *----------------------------------------------------------------------------------*
    【マッチングさせるルール指定】

    *----------------------------------------------------------------------------------*
    今回、上記ルールが破棄となっています。
    もし破棄とならなかったら、トリガー指定は以下です。
    【パラメータ加工フロー】

     

    *----------------------------------------------------------------------------------*
    【アクション】
    上記パラメータ {{callflow}} を以下のリクエスト本文に指定してAPIを使おうと思っています。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    メール本文では「callflow:」「73021c20-78a3-42d7-8cea-df7802d86cff」の間に半角スペースを入れているようですが、正規表現の方でこれが考慮されていないように見受けられます。
    例えば下記のように「\s」にて空白文字に対するマッチを行うのが良いかと存じます。

    ^callflow:\s73021c20-78a3-42d7-8cea-df7802d86cff$

    ご確認のほど、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    メールの文字間に「スペース」があることに気づかず、失礼いたしました。
    WEBHOOK API での架電は動作いたしました。

    これまでのテストと仕様を変えることになるため、正確に仕様を把握したいと思います。

    上記の仕組みで架電をPigeon ではなく、WEBHOOK で行う場合、
    ①コールフローIDを処理フローでマッチングするため、
     ルール:コールフローID = 1:1 の関係となり、
     ルールはコールフローID数分作成が必要

    ②①より、スコープもコールフローID数分の作成が必要

    ③トリガー・アクション・ガイダンスは各スコープ共通で利用可

    ④WEBHOOKアクションのHTTPヘッダに指定したトークンは、いつまで使えますか?
     トークンカレンダーは何年も先まで用意があるようですが、半年/一年などど利用可能期間を決めて
     運用するべきか、通常どう推奨なさってるのか教えてください。

    ⑤今回、WEBHOOKリクエスト本文にパラメータとして、
     {{hostname}},{{date}},{{time}},{{error}} を指定しました。
     これは加工パラメータによって、メール本文から抽出され、ガイダンスに記載してあります。
     リクエスト本文には、やはりparameters として指定が必要なものですか?

    ⑥この架電の連絡履歴を見ると、Pigeon の時よりずっとパラメータ情報が減っています。
     WEBHOOKリクエスト本文で指定した、
     {{hostname}},{{date}},{{time}},{{error}}
     のみが表示されています。
     これはAPI で指定したもののみ表示する仕様ですか?
     例えば他にも表示できるものはありますか?
     またその表示方法は上記以外にどのようなものがありますか?

    ⑦WEBHOOK API による自動架電を運用に移した時、
     ルールやトリガーの並列処理はどうなるのでしょうか?
     すべての架電において同じ名前の一時フィールドを用いています。
     
     架電が自動で大量に発生した場合、
     処理遅延
     待ち行列
     データのUNIQUE 性(整合性)について
     心配はいらないとは思いますが、Pigeon というアプリ利用に比べて
     API コマンドでは劣る部分があるかなど、念のため教えてください。

    以上、ご回答のほどよろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    回答させていただきます。

    ■ ①②③について

    目的がコールフローの使い分けのみであれば、トリガーによるコールフローID抽出だけ行えば連絡先のコールフローはメール本文から決定可能ですので、ルールやスコープも1つで問題ございません。

    連絡先のコールフローごとに深刻度を分けて管理する必要があるようであれば、ルール・スコープを個別に持つことが必要となりますが、 トリガーの「パラメーター整形フロー」で行っているのと同様にルール側でもコールフローIDを抽出を行い、これを深刻度名として利用することで1つのスコープ・ルールで設定ができる可能性はございます。

    こちらの記事もご参照ください。

    製品情報 - AlertHub のスコープに複数の深刻度を持たせることが出来るようになりました

    ■ ④について

    APIトークンはそれ1つで全てのAPI操作が可能となる非常に強力な情報となっており、漏洩に気を配るのであれば長くとも1年程度に設定しておき、定期的に更新するほうがセキュアとなります。

    とは言え更新が漏れたまま気付かないでいるとPigeonによる連絡が発生しなくなるリスクもありますので、トークン期限の管理に手をかけ難いようであればいっそ十分に長い期間を設定し、事実上期限切れしないトークンを発行する運用にしても構いません。

    安全性と利便性はトレードオフの関係にありますので、運用上無理ない範囲での期間設定をするのがよろしいかと思います。

    ■ ⑤⑥について

    WebhookアクションにてPigeonのAPIリクエストを行う場合、Pigeonの架電パラメーターとして使用する情報は全て「parameters」内に明示する必要がございます。また逆に明示していない情報がPigeonに渡されることはございません。

    Pigeonアクションによる連絡実行も原理としてはWebhookアクションと同等ですが、こちらでは「parameters」へ指定する値を自動的に決定する形となっております。

    ■ ⑦について

    Pigeonアクションではコールフロー・ガイダンスの選択のみに設定を簡素化しているものの、内部的にはAPI経由で連絡のリクエストを行なっております。そのため今回のWebhookアクションを使用するのとPigeonの動作には特に違いはございません。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になります。
    ご回答ありがとうございました。
    申し訳ありませんが、もう少し教えてください。


    弊社の架電は、

    ■1.スコープ・ルール(深刻度は常に0)・トリガー・アクション・Pigeon の
    一番シンプルな構成
    ■2.アラートメールには「コールフロー表示名」を持たせ、ルールで「コールフロー表示名」を指定した正規表現でマッチするかどうかのチェックを施す(↓)

    (もし「本文」が「^callflow:callpocUN$」とマッチした場合)

    ■3.トリガーでパラメータ加工フローによりメール内データ抽出
    (「本文」から正規表現「callflow:\s*(\S+)」によって値をひとつ取り出して一時フィールド「callflow」に保存する
    の構成です。

    >>■①②③について
    >>目的がコールフローの使い分けのみであれば、トリガーによるコールフローID抽出だけ行えば連絡先のコールフローはメール本文から決定可能ですので、ルールやスコープも1つで問題ございません。

    【質問1:20211005】

    今回、目的を「コールフローの動的指定による自動架電」に置いております。
    そうすると、200近くある新規コールフローにおいて、従来のKompira cloud の構築工数が削減できるかと思っております。

    ご回答に「コールフローはメール本文から決定可能ですので、ルールやスコープも1つで問題ございません。」とありますが、

    動的を目的にするので、もし
    ■2.の、ルールによるコールフローIDのマッチングはしないとした場合、
    何か不都合はありますでしょうか?受信スロットに入ってきたメール全てが対象になるかと思います。
    リスクなどありませんでしょうか?

    またその時、マスター構成が1つ在って、コールフローが増えるごとに構築が必要となるのは、
    どれでしょうか?
    ■2・の場合、rule は受信スロットと深刻度のために必要かと思っております。
     ※処理フロー登録なし
     でも受信スロットも深刻度も変更がなければ、マスターがあればよいでしょうか?
     

    【質問2:20211005】
    >>■ ⑤⑥について

    >>WebhookアクションにてPigeonのAPIリクエストを行う場合、Pigeonの架電パラメーターとして使用する情報は全て「parameters」内に明示する必要がございます。また逆に明示していない情報がPigeonに渡されることはございません。

    >>Pigeonアクションによる連絡実行も原理としてはWebhookアクションと同等ですが、こちらでは「parameters」へ指定する値を自動的に決定する形となっております。

    Pigeon が自動的に表示しているパラメータ
    callflow,event,message,scope,scopeSeverities,space,trigger
    については、

    webhook-action のparameters の中に{{scope}} のように指定すれば、連絡履歴に出せるようになりますか?
    また、パラメータ callflow については、

    弊社でガイダンスに載せていないのに連絡履歴パラメータに現われています。
    もしやシステム予約のパラメータ callflow と、
    弊社がパラメータ加工フローで指定した任意の一時フィールド名 callflow が被ってますでしょうか?
    パラメータ加工フローで指定した任意の一時フィールド名 callflow は、callflowID とか CFid とかに
    変えて運用したほうが安全でしょうか?

    以上、ご回答のほどよろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ■ 【質問1:20211005】について

    書かれている内容を拝見した限りですと、受信スロット・ルール・スコープは完全に1つにまとめて問題ないように思います。ただし、受信スロットに対して送信するメールの中にPigeon連絡を実施しないものが含まれるようでしたら、例えば「message.content.text」が正規表現「^callflow:\s*(\S+)$」とマッチ「する」ものだけを通すようにルールを組むなど、連絡対象外のメールを除外するようにルールを設定する必要はございます。

    ルールを1つにまとめることに関してはパフォーマンス上の問題はなく、むしろ1つの受信スロットに対して判定されるルール数が少ない方が有利となります。

    ■ 【質問2:20211005】について

    webhook-action のparameters の中に{{scope}} のように指定すれば、連絡履歴に出せるようになりますか?

    scopeのような複数の値を子要素として持つものを直接指定するのは上手くいきませんが、 {{scope.scopeId}} のように必要な値1つに絞り込む形で指定する分にはPigeonのパラメーターと指定しても問題なく、連絡履歴にも表示されます。

    パラメータ加工フローで指定した任意の一時フィールド名 callflow は、callflowID とか CFid とかに
    変えて運用したほうが安全でしょうか?

    Webhookアクションを用いて連絡を行う場合、「parameters」に指定したパラメータのみPigeonに渡されることになりますので、そちらに指定していないパラメータが渡されることはございません。
    一方でPigeonアクションを使用する場合はトリガーの「パラメーター整形フロー」にて生やしたデータがそのまま受け渡されるため、おそらくはPigeonアクションによる連絡結果と混同しているものと思います。

    どちらにせよ、Pigeon側の処理に特に影響は起きませんので、フィールド名は自由に指定していただいて構いません。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    申し訳ありませんが、rule の正規表現について教えていただけますか?

    ご教示いただいた、^callflow:\s*(\S+)$ ではルールが破棄されてしまいます。
    ^callflow:.*$ などもやってみましたが同じです。
    sakura editer などでは検索できるのですが。


    メール本文には

    callflow:a9be8f92-969d-4f9f-b394-3d352b7b2258

    のように、コールフローID を続けて記載しています。

    申し訳ありませんが、ご教示のほどよろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    もう一点お願いいたします。
    >>scopeのような複数の値を子要素として持つものを直接指定するのは上手くいきませんが、 {{scope.scopeId}} のように必要な値1つに絞り込む形で指定する分にはPigeonのパラメーターと指定しても問題なく、連絡履歴にも表示されます。

    上記の{{scope.scopeId}} をparameters 指定しようと思います。
    "parameters":{
    "hostname": "{{hostname}}",
    "date": "{{date}}",
    "time": "{{time}}",
    "error": "{{error}}"

    の中に指定することになるとおもいますが、
    /api/apps/pigeon/chain/invoke のAPIドキュメントの Schema をみると、

    parameters*

     

    {
    description:

     

    Guidance テンプレートの置換用辞書。 詳細は Guidance の messageTemplate の説明を参照。

    とあります。

    {{scope.scopeId}} をparameters 指定するには、どう記述すればよいかご教示ください。

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    いつも翌日には回答いただいているので、何か情報が足りないのではないかと思い
    ご連絡いたしました。

    大変恐縮ですが、ご回答をお待ちしております。
    何か情報提供が必要でしたらご連絡ください。
    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ご教示いただいた、^callflow:\s*(\S+)$ ではルールが破棄されてしまいます。
    ^callflow:.*$ などもやってみましたが同じです。

    添付画像拝見しましたが、こちらの錯覚かもしれませんが「$」と手前の「)」との間の空白幅が少々大きいように見えます。下記のいずれかにあたる可能性が考えられますので、ご確認ください。

    • 「)」と「$」の間に半角スペースが混じってしまっている
    • 「$」が全角の「$」になってしまっている。

    いずれにも当たらない場合、別の可能性としてはメール本文の方の行末に半角スペース等が含まれていたりすると、空白文字以外とマッチする「\S」と行末マッチする「$」との間に空白文字が許容されていないことからマッチがうまくいかなくなることが考えられます。これを考慮するのであれば、下記のように正規表現を設定ください。

    ^callflow:\s*(\S+)\s*$

    もしくは、行頭・行末にマッチさせてのチェックが不要であればトリガーの方と同様に「callflow:\s*(\S)」とのマッチで確認するのでも良いかと思います。

    {{scope.scopeId}} をparameters 指定するには、どう記述すればよいかご教示ください。

    parametersの中に、たとえば下記のように指定を増やしてください。

    "parameters" {
    "hostname": "{{hostname}}",
    "date": "{{date}}",
    "time": "{{time}}",
    "error": "{{error}}",
    "scopeId": "{{scope.scopeId}}"
    }

     

    いつも翌日には回答いただいているので、何か情報が足りないのではないかと思い
    ご連絡いたしました。

    ご回答遅くなりまして申し訳ございません。

    サポートにいただいたご質問に関しては1営業日中(翌日が平日であれば24時間以内)に返答することを目標としておりますが、可能な限り日付が変わる前に回答できるように努力させていただいております。

    一方で業務状況によっては回答までの時間には差が出てしまうこと、ご理解いただければと思います。

    0
    コメントアクション Permalink
  • 原井麻有

    お疲れ様です。
    ご提示いただいたパラメータ指定だと異常となってしまいます。
    私も同様の指定はしていたのですが、何が悪いのでしょうか?
    申し訳ありませんがご教示願います。

    {
    "params":{
    "callflowId": "{{CFid}}",
    "guidanceId": "f682ad66-b641-4c59-bf04-9e745239d97e",
    "parameters":{
    "hostname": "{{hostname}}",
    "date": "{{date}}",
    "time": "{{time}}",
    "error": "{{error}}",
    "scopeId":"{{scope.scopeId}}”
    }
    }
    }

    ボディ
     
    { "type": "https://fixpoint.co.jp/probs/badrequest", "title": "Invalid request parameter(s)", "detail": "Invalid request payload", "instance": "/api/apps/pigeon/chain/invoke" }
     
     
    ヘッダ
     
    Cache-Control no-cache, no-store, no-transform, must-revalidate, private, max-age=0
    Content-Length 168
    Content-Type application/json; charset=utf-8
    Date Thu, 07 Oct 2021 05:11:13 GMT
    Expires Thu, 01 Jan 1970 00:00:00 UTC
    Pragma no-cache
    Server nginx
    Vary Origin

    リトライ回数:0/3

    失敗理由:400 Bad Request
    イベントID:8ffcae44-21c0-4bb3-9c13-8ef9c59a875b

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    おかしな事象が発生するのでお尋ねします。

    ①rule の正規表現を加工パラメータと同じものにして、ruleがマッチすることを確認しました

    もちろんwebhook API まで動作できて、Pigeonから連絡成功が確認できました。

    ②rule の正規表現を、ご提供いただいた

    ^callflow:\s*(\S+)\s*$

    に変更し、他は何も変えず実施すると、アクションが失敗しました。
    失敗コードは前述と同じ 400 Bad Request です。


    rule の正規表現は、受信スロットから入ったデータをチェックするもので、
    ルールの処理フローを通ったら、そのデータは捨てられるものと思っております。
    ですが今回、ruleの正規表現を変えただけで、後続処理に影響がでました。
    これは何故でしょうか?
    WEBHOOKアクションは、Pigeonアクションに比べて、
    何か安定性が落ちる要因がありますか?
    本契約後の環境で、全架電を WEBHOOKでやろうとしているので、気になりお尋ねしました。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    調べましたところ、

    "scopeId":"{{scope.scopeId}}”

    この行の末尾のダブルクォーテーションが半角の「"」ではなく全角の「”」になってしまっている模様です。こちらを修正のうえ、再度お試しいただければと思います。

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    何度も申し訳ありません。
    ・scopeIdのパラメータがエラーになること
    ・rule の正規表現を変えただけでアクションが失敗することの原因がわかりました。

    原因:メール転送によるもの

    新規メールであれば、parameter の引き渡しは上手くいき、
    転送メールの場合、bad parameter となってしまうようです。

    【転送メールの内容】
    *-----------------------------------*

    転送

     

    From: ■■ ■■(Xxxxx, Xxxx)
    Sent: Thursday, October 7, 2021 4:20 PM
    To: exxxxxxxxxxxxxxxxxxxx_x_q0ygxxxxxxxxxxxxxxxxxxxx_kai@receiver.cloud.xxxxxxxx.jp
    Subject: FW: 必ず初回メールで:^callflow:\s*(\S+)\s*$

     

    転送

     

    From: ■■ ■■(Xxxxx, Xxxx)
    Sent: Thursday, October 7, 2021 4:18 PM
    To: exxxxxxxxxxxxxxxxxxxx_x_q0ygxxxxxxxxxxxxxxxxxxxx_kai@receiver.cloud.xxxxxxxx.jp
    Subject: 必ず初回メールで:^callflow:\s*(\S+)\s*$

     

    callflow:a9be8f92-969d-4f9f-b394-3d352b7b2258

    date:2021/10/07

    time:16:17

    hostname:g o o g l e . c o m n h k

    error:空白 括弧() コロン: チルダ^

    *-----------------------------------*

    加工パラメータでは、
    message.content.text から正規表現「callflow:\s*(\S+)」によって値をひとつ取り出して

    一時フィールド CFid に保存する
    と設定していたので、subject のあたりの情報を拾ってしまい、bad parameter となったようです。
    こちらのミスでした。申し訳ありませんでした。


    話が変わってしまい申し訳ないのですが、scopeId と同じように、
    scope のdisplayName も表示することはできますでしょうか?
    その場合は、
    "displayName":"{{scope.displayName}}"
    の指定でよろしいでしょうか?

    また、Schemaの ChainParams に
    callflow とありますが、
    callflowId だけじゃなく、コールフロー表示名もパラメータ指定で表示することはできますでしょうか?

    次々と申し訳ありませんが、こちらもご教示のほどよろしくお願いします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    scopeId と同じように、
    scope のdisplayName も表示することはできますでしょうか?
    その場合は、
    "displayName":"{{scope.displayName}}"
    の指定でよろしいでしょうか?

    その指定方法で問題ないかと思います。ただPigeonの連絡結果画面だけ見たときに何のdisplayNameかがわかりにくくなりますので、

    "scopeDisplayName":"{{scope.displayName}}"

    と「scopeの」displayNameであることを明示した方が良いかと思います。

    Schemaの ChainParams に
    callflow とありますが、
    callflowId だけじゃなく、コールフロー表示名もパラメータ指定で表示することはできますでしょうか?

    ChainParamsの「callflow」はコールフローのID指定ではなく、コールフローの定義内容を直接指定して連絡を行うためのフィールドで、今回のように事前定義したコールフローを用いて連絡を行う場合には使用することができません。

    ご参考までに、コールフローの直接指定に関してはこちらの記事の「コールフロー・ガイダンスの内容をその場で指定して連絡を実行する」が詳しいので、そちらを併せてご参照ください。

    コールフローの表示名については連絡結果画面から直接確認することはできませんが、「コールフロー」欄のリンクからコールフローの詳細画面に飛ぶことで確認できますので、そちらを併せてご活用いただくのが良いかと思います。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    色々とありがとうございました。

    WEBHOOKアクションの仕様がわかってまいりましたので、新規コールフローの架電はこちらの手法で
    行う可能性が出てまいりました。

    そこで確認をさせてください。

    ■前述した通り、弊社は一番簡単な構成で自動架電の設計をしておりましたので、

    callflow が増えるごとに、guidance 以外の設定はすべて新規作成しなくてはなりませんでした。
    (scope,rule,trigger,actionが新規に必要で、callflow が200なら、200x4=800 定義の作成)


    ■しかしWEBHOOKアクションに切り替えた場合、
    scope:(全共通で1つ)

    rule: callflow:callflowId のレイアウトを ^callflow:\s*(\S+)$ でマッチング(全共通で1つ)

    trigger:必要なデータを加工パラメータで一時フィールドに格納:仕様は同じ(全共通で1つ)
    action:api によりcallflow を動的に変えられるので仕様は同じ(全共通で1つ)
    となり、800定義の作成が必要だった設定が1つで済むという認識でよろしいでしょうか?

    ご回答のほど、よろしくお願いいたします。


    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ご認識の通りで間違いございません。

    Pigeonアクションは事前に決めた1種のコールフロー・ガイダンスを用いて連絡をするには手軽な手段です。
    一方でWebhookアクションはAPIの仕様を把握して使う必要がある分難易度が高いものの、Pigeonアクションでは暗黙的に決められてしまうAPIのパラメーターを全てコントロールできるため柔軟性が高くなります。

    今回のケースではそれがうまく働き、ルール・トリガーを1つだけ定義すれば済むようになっております。

    0
    コメントアクション Permalink
  • 原井麻有

    ご回答、ありがとうございます。
    クローズは今しばらくお待ちいただけると幸いです。

    0
    コメントアクション Permalink

サインインしてコメントを残してください。