受信メールから正しくスコープを選別するコツはありますか?

回答済み

コメント

18件のコメント

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

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

    メール文面の構成によっては「フィールドが正規表現にマッチするかどうか確認する」を用いることでうまくコールフロー名全体への条件を書くことができる可能性がありますが、これは正規表現を使い慣れていないと少々難しい方法となりますので、より簡単な方法として「コールフロー名を何らかの文字で囲む」のが良いかと思います。

    例えば「コールフロー名AA」「コールフロー名AAAZ」としていたのものを「コールフロー名"AA"」「コールフロー名"AAAZ"」のようにダブルクォーテーションで囲って送るようにすれば、2つのコールフロー名を完全に区別してルールに一致させることができます。

    もし目立つ囲み文字を避けたい場合は、例えば半角スペースを用いて(わかりやすいように半角スペース部分を_で表現します)「コールフロー名_AA_」「コールフロー名_AAAZ_」のように囲み、ルールでの包含チェック時にも半角スペース部分を含めて比較をするのが良いかと思います。

    ご参考になれば幸いです。
    よろしくお願いいたします。

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

    お世話になっております。
    上記の””(ダブルクォーテーション)を使っての完全一致が、うまく動作しないので再度ご教示ください。

    私の認識が誤っていたら申し訳ありません。

    質問【2021/07/16_2】
    ルールの処理フローにおいて、「本文がxxを包含した場合」との指定では、本文がxxyなどの場合も有効になってしまうため、上記のご質問をさせていただきました。
    ””(ダブルクォーテーション)を使っての完全一致の正規表現ができるとのことだったので、ルールの処理フローを「本文が”xx”を包含した場合」に変更しましたが、そうするとルールはマッチングしないようで後続処理に進みません。


    先日のセミナーでも、良くは見えなかったのですが、囲み文字(*)らしきものを使用なさっているようでしたので、Kompira側での完全一致表現はできるのだと思います。
    何がいけないのか教えていただけますでしょうか?

    また、関連あるかはわかりませんが、間違いなく架電まで動作しているのに、メッセージから見た時のルール処理が「なし」になるのはどういう現象でしょうか?
    その時のイベントは「あり」になっています。

     

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

    ””(ダブルクォーテーション)を使っての完全一致の正規表現ができるとのことだったので、ルールの処理フローを「本文が”xx”を包含した場合」に変更しましたが、そうするとルールはマッチングしないようで後続処理に進みません。

    こちらの意図としては、正規表現ではなく「フィールドが文字列を含むかどうか確認する」を用いて、受信スロットに送信するメッセージ自体も「コールフロー"xx"」のようにダブルクォーテーションで囲む形を想定しておりました。

    この点について、認識は合っていらっしゃいますか?

    また、関連あるかはわかりませんが、間違いなく架電まで動作しているのに、メッセージから見た時のルール処理が「なし」になるのはどういう現象でしょうか?

    申し訳ございません、ルール処理有無の反映には元々タイムラグがございますが、本日一時的に処理の集中が発生し、情報の反映に遅れが発生していた模様です。
    現在は解消しております。大変ご迷惑をおかけいたしました。

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

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

    私の認識があっていないかもしれないので、質問を整理して再度お尋ねいたします。

    質問【20210720_1(改め)】
    処理フロー:もし本文が xxxxx を包含した場合
    の指定をする際の、キーワード xxxxx の完全一致指定について教えてください。

    ①受信スロットに投げる受信メール本文内の正規表現で行う

     ・^xxxxx$ で指定し、テスト上では出来ることを当方では確認済

    ②AlertHub/ルール/処理フローにて行う
     できれば Kompira側 で指定したいと考えたため

     ・""(ダブルクォーテーション)指定でできると思ってました。

      指定例:もし本文が "xxxxx" を包含した場合

     ・セミナーの画面で * を使った指定をしているように見えたので、kompira 側で出来ると思ってしまいました。

    結果としては、"" ,* ともに完全指定の動作はしませんでした。
    ②のkompira側でのなんらかの指定が出来るか、ご教示ください。

    質問【20210720_2】
    受信スロットの作成可能数をご教示ください。
    AlertHub の仕様情報には載っていなかったと思います。

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

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

    質問【20210720_1(改め)】

    まず端的にお答えしますと、「フィールドが文字列を含むかどうか確認する」において「"xxxxx"」や「*xxxxx*」のように文字を囲ったとしても、それはそのまま「"xxxxx"」「*xxxxx*」という文字に一致するのみで、「"」や「*」が特殊な効果を持つことはありません。

    セミナーで「*」を使っていたとすると、それはやはり「*」という文字を受信スロットへの送信内容に含めていたものと考えられます。

    その上でメールの内容を変更せずにコールフロー名全体を取るようにするのであれば、文面にもよりますが二通りの方法が考えられます。

    1. コールフロー名の前後を含めて判定するようにする

    例えば「コールフロー名はxxxxxです」のように前後の文章が繋がっているならば、「xxxxx」ではなく「コールフロー名はxxxxxです」という文面全体を条件として指定する方法が考えられます。

    2. 「フィールドが正規表現にマッチするかどうか確認する」を使用する

    「コールフロー名:xxxxx」のようにコールフロー名が行末にある場合は「フィールドが文字列を含むかどうか確認する」で一致させるのは難しく、このようなケースでは「フィールドが正規表現にマッチするかどうか確認する」を用います。

    例えば「コールフロー名:xxxxx」であれば、「コールフロー名:xxxxx$」と行末マッチを用いることで確実にコールフロー名全体に対する条件付けをすることができます。

    質問【20210720_2】
    受信スロットの作成可能数をご教示ください。

    受信スロットの作成数に関して、特に上限は設定しておりません。

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

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

    お世話になっております。
    回答をありがとうございました。
    こちらでも「フィールドが正規表現にマッチするかどうか確認する」があると
    気づいたところだったので、良いタイミングでご回答をいただけました。
    テストしてみます。ありがとうございます。


    申し訳ありませんが、ルール条件の重複指定についても質問をさせてください。
    以前ルールの処理フローは複数指定した場合、上から順に適用されると伺いました。

    質問【20210720_3】

    ①それは and 条件ではなく、or条件ということでよろしいでしょうか?

    ②一時フィールドを云々する指定がないので無理かもしれませんが、

     ルール:処理フローで

     「本文から正規表現 xxxxx:\s*(\S+) によって値を一つ取り出して一時フィールド mmmmm に保存する」
     を指定した場合、一時フィールド mmmmm を後続に追加した処理フローに利用できることはありますか?

    ③②の一時フィールド名の※に、message から始まる名称」は不可とあります。
    これは他のところのパラメータなどの予約語として、messege が使われているからと推測しますが、どこで使われているかご教示いただけますか?
    連絡履歴で使われている展開パラメータのことでしょうか?

     

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

    お世話になっております。
    本日ご回答いただいた、

    2. 「フィールドが正規表現にマッチするかどうか確認する」を使用する

    について質問いたします。

    上記の処理フローを設定しているのですが、ルール実行結果で破棄されてしまっています。
    メッセージ画面でのルール処理は「有り」です。

    処理フローは
    もし

    件名 - message.content.subject 本文 (text) - message.content.text 本文 (html) - message.content.html 送信元アドレス - message.metadata.from.email 送信者 - message.metadata.from.name
     

    callflow:正規表現_match$
     

    とマッチ

    選択してください した しなかった
     

    場合

     

    と設定。

    メール本文には、

    callflow:正規表現_match$

    hostname:alphabet

    date:20210720

    time:14:29:00

    error:UX:MpCNappl: ERROR: 106:  ノードが停止しました(ICMP/ポート応答なし). (TRAP agent:10.111.162.121 community:public generic:6 enterprise:fujitsu.4.19.3 specific:10 timestamp:0 varbind:(fujitsu.4.51 [1 1 0] 2))
    のテストデータを記載して送っております。

    本文中に P1 と全く同じ正規表現がるので、マッチすると思うのですが
    何が違うのかご教示いただけますでしょうか?


     

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

    お世話になります。
    前述の質問の

    2. 「フィールドが正規表現にマッチするかどうか確認する」を使用する

    がうまく動作しない件について、テストを行っているので、お知らせします。


    AlertHub基本マニュアル p19 作成の流れ 3.ルールの作成(3/7) の左下に

    「フィールドが正規表現にマッチするかどうか確認する」の説明があり、
     説明の例に倣い

    ・メール本文は 「Error」 一行のみ

    ・設定は「もし本文が E(rror|RROR) とマッチした」

    にした場合、ルールは一致し、正常に動作しました。


    けれど、
    ・メール本文は 「正規表現_match」一行のみ

    ・設定は「もし本文が ^正規表現_match$ とマッチした」

    の設定では動作しませんでした。
    何が違うのでしょうか?

    また弊社では、メール本文に正規表現した結果の一行だけを記載して

    メールを飛ばすのではなく、他のアラート情報もメールに含みます。
    通常アラートメールが1種類の正規表現できるワードだけとは限らないので、
    複数行の本文から、指定した正規表現の文字列だけを見つけてマッチングするのが
    こちらの処理フローだと考えていたのですが、この認識は合っているでしょうか?

     

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

    お世話になります。
    前前述の質問がきちんと記載されていなかったようです。
    画面をコピーしてしまったので、選択枝の部分まで貼り付けられていました。
    わかりにくくなってしまい、申し訳ありませんでした。

    前述の E(rror|RROR) ではうまくいくのに、

        ^正規表現_match$  ではできない旨の質問にお答えいただけますでしょうか?

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

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

    質問【20210720_3】について回答いたします。

    それは and 条件ではなく、or条件ということでよろしいでしょうか?

    1つのルールの処理フローに複数の条件を指定する場合、条件としてはand条件となります。

    処理フローの指定順が影響するケースとしては、例えば「フィールドから正規表現によって値をひとつ取り出す」を用いる場合に、この取り出しよりも前に置いた条件では取り出した値を使用できませんが、取り出しよりも下に置いた条件では取り出した値を利用可能となります。

     「本文から正規表現 xxxxx:\s*(\S+) によって値を一つ取り出して一時フィールド mmmmm に保存する」
     を指定した場合、一時フィールド mmmmm を後続に追加した処理フローに利用できることはありますか?

    先述の通り、値の取り出しよりも後に追加した条件では一時フィールドの値を使用できます。一時フィールドは元々あるフィールドと同等に扱うことができますので、上記の例であればフィールドの入力欄(「message.content.text」などを入力していた場所)に「mmmmm」を入力してください。

    ②の一時フィールド名の※に、message から始まる名称」は不可とあります。
    これは他のところのパラメータなどの予約語として、messege が使われているからと推測しますが、どこで使われているかご教示いただけますか?

    「message」を一時フィールドとして利用することを許可してしまいますと、「message」が上書きされてしまうことで後続の条件において「message.content.text」など、受信メッセージの内容に対する条件付けを書くことができなくなってしまいます。

    こういったトラブルを避けるために、「message」や「message.content」などのmessageから始まる一時フィールド名を使用不可としています。

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

    前述の E(rror|RROR) ではうまくいくのに、

        ^正規表現_match$  ではできない旨の質問にお答えいただけますでしょうか?

    大変申し訳ございません。上記について確認いたしましたところ、「^」「$」が行末・行頭ではなく文章全体の先頭・末尾にのみマッチすることがわかりました。こちらに関しては行末・行頭へマッチするようにしたほうが使いやすいかと思いますので、速やかに挙動改善させていただきます。

    ご迷惑をおかけいたします。
    よろしくお願いいたします。

     

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

    お世話になっております。お忙しいところ調査いただき誠にありがとうございます。

    上記につきまして
    質問【20210720_4】として新たにお尋ねいたします。

    ①「速やかに挙動改善」とのことですが、弊社の都合で恐縮ですが、
     評価版での概念実証をしておりまして、あまり時間がありません。
     

     そのため、メール本文からの、特定文字列(コールフロー名)をマッチングキーとすることで
     すでに既存PGMの仕様変更が動いており、
     この部分のKompira側の機能の確認と、仕様決定は少々急いでおります。
     

    特定文字列(コールフロー名)はUNIQUE なキーワードとしてマッチングさせたいのですが、「フィールドが正規表現にマッチするかどうか確認する」が使えないとなると、代替案として何になるでしょうか?

    私個人としては、

     メール本文にて

     ・callflow:^コールフロー名$    の正規表現の一行を指定し、
     処理フローにて

     ・フィールドが文字列を含むかどうか確認する

      ・もし message.content.text が callflow:^コールフロー名$ を包含した場合
     を利用することになると思うのですが、他にもっと良い案があれば、ご教示願えますでしょうか。

    ②挙動改善の見通しとしては、いかほど先になるか、教えていただくことは可能でしょうか?

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

     

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

    私個人としては、

     メール本文にて

     ・callflow:^コールフロー名$    の正規表現の一行を指定し、
     処理フローにて

     ・フィールドが文字列を含むかどうか確認する

      ・もし message.content.text が callflow:^コールフロー名$ を包含した場合
     を利用することになると思うのですが、他にもっと良い案があれば、ご教示願えますでしょうか。

    「フィールドが文字列を含むかどうか確認する」を用いるうえで、入力データを「callflow:^コールフロー名$」のように正規表現の記号で表現する必要はございません。

    本質問の最初の方で示した通り「callflow:"コールフロー名"」とダブルクォートで囲むか、より目立たない方法として「callflow:_コールフロー名_」(_は半角スペース)と半角スペースで囲むのが良いかと思います。この場合、処理フローもメール文面の記載と全く同じ内容を条件指定していただければ問題ありません。

    また正規表現について少々誤解されてるのではと思いますが、正規表現は条件を書く際に使用する書式で、マッチ対象となるデータ(メール本文)の方に正規表現の書式を用いても特に意味はございません。

    例えば挙動改善後に正規表現を使用する場合、メール本文の方は単に「callflow:コールフロー名」とすればよく、これに対して処理フローで指定する正規表現を「^callflow:コールフロー名$」とすることで問題なくマッチすることができます。

    挙動改善の見通しとしては、いかほど先になるか、教えていただくことは可能でしょうか?

    早ければ本日、遅くとも明日中には改善を適用予定です。
    適用時にはコメントにてお知らせいたしますので、お待ちください。

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

    ご回答ありがとうございました。
    仰るとおり、私の記載が誤っておりました。
    弊社では^ と$ の正規表現を使用する予定ですので、挙動の改善のお知らせをお待ちしています。
    よろしくお願いいたします。

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

    AlertHubについて先ほどアップデートを行わせていただき、正規表現の行頭・行末マッチが働くよう挙動改善いたしましたのでお知らせいたします。
    ご迷惑をおかけいたしました。

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

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

    早急な対応をありがとうございました。
    確認は来週になってしまいます。申し訳ありません。

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

    お世話になっております。
    正規表現「^」「$」につきまして、早急な挙動修正にご対応いただき、ありがとうございました。
    弊社にてテストいたしまして、7/20に発生していた

    E(rror|RROR) ではうまくいくのに、

    ^正規表現_match$  ではできない

    の挙動について、修正されているのが確認できました。ありがとうございました。

    重ねてで申し訳ないのですが、運用管理の観点から質問をよろしいでしょうか。

    質問【20210726_1】
    何らかの仕様変更やバグの修正の案内について、どのようにアナウンスされているかご教示いただけますか?(例えば、対象ユーザへのメール告知や、サイト上の掲載なのか等)


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

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

    動作確認の結果をご連絡いただきありがとうございます。

    質問【20210726_1】についてですが、
    現状では以下の製品サイトのページ内にて更新内容をお知らせさせていただいております。
    アップデートが行われますと、以下のページも併せて更新を行っております。
    https://www.kompira.jp/release/update2021/

    0
    コメントアクション Permalink

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