AlertHubで、受信したメッセージの文中から取り出す値について
回答済み
お世話になっております。
上記タイトルの機能を使って、抽出した値をガイダンスにて読み上げるように設定しております。
その中には、アラート通知アプリからのメッセージ全文を抽出指定しているものもあるのですが、文中にスペース（空白）が登場したところで文の抽出が切れてしまいます。
上記マニュアルの中にあった
変数名:\s*(\S+)
ではダメで、以下
変数名:\s*(\S+)( | )+
変数名:.*
でもダメでした。
どう指定すればメッセージ全文が抽出できる正規表現になるか、ご教示いただけますか？
よろしくお願いいたします。
-
正式なコメント
ご質問ありがとうございます。回答させていただきます。
「\S」を使用するとスペース以外の文字にのみマッチしてしまうため、スペースを含めて値を抽出する場合は全ての文字にマッチする「.」を用いて
変数名:\s*(.+)
としていただくとうまく抽出できるのではないかと思います。
踏み込んだ解説
ここからの解説は少々難易度が高くなりますので、難しければ読み飛ばしていただいて構いません。
「フィールドから正規表現によって値をひとつ取り出す」機能では、正規表現に「()」で囲われた部分がある場合はその部分にマッチした文字列を、そうでない場合は正規表現全体にマッチした文字列を取り出すようになっております。
この仕様に照らし合わせて質問に記載していただいた正規表現の動きを見ていきます。
変数名:\s*(\S+)
こちらは「変数名:」のうしろに「0個以上のスペース（\s）」と「1個以上のスペース以外の文字（\S）」が続いた場合にマッチします。
マッチした場合、カッコで囲われている「1個以上のスペース以外の文字（\S）」の部分が結果として抽出されます。例えば「変数名: abc def」という文章に対して処理を行うと、「abc」が抽出されます。
変数名:\s*(\S+)( | )+
こちらは「変数名:」のうしろに「0個以上のスペース（\s）」と「1個以上のスペース以外の文字（\S）」が続き、さらにその後に「1個以上の半角スペースまたは全角スペース」が続いた場合にマッチします。
マッチした場合、1つめのカッコで囲われている「1個以上のスペース以外の文字（\S）」の部分が結果として抽出されます。例えば「変数名: abc def」という文章に対して処理を行うと、こちらも「abc」が抽出されます。
変数名:.*
こちらは「変数名:」のうしろに「0個以上の文字」が続いた場合にマッチします。
カッコが含まれないため、マッチした場合は全体が結果として抽出されます。例えば「変数名: abc def」という文章に対して処理を行うと、その全体である「変数名: abc def」が抽出されます。
コメントアクション -
お世話になっております。
ご担当者様。
今回、こちらのミスに気付かず問い合わせをしてしまい、誠に申し訳ありませんでした。
怪我の功名と申してはいけないかもしれませんが、おかげでご担当者様がどこからスコープの違いを見抜いてらっしゃるのか推測することができました。
連絡履歴のパラメータ一覧の scope のところに Displayname と scopeId がありました。
こちらから判別されたのではないでしょうか？
（もし間違っていたら、どうやって見抜いたのかよければご教示ください）
実は、現在テストをしていて困っていることが幾つかあります。
業務分析がまだなせいもありますが、AlertHub/Pigeon の各命名ルール（どう運用するか）について悩んでいます。理由は以下のようなことです。
１．連絡履歴から実行アクションが追えない
（7/15に「そういう仕様だからアクション・コールフロー・ガイダンスの命名の対応付けなど工夫してください。」との回答をいただいていましたが、これは今回のことで追えることが分かりました。
助かりました。２．ルールの処理フローによって実施が制御されているので、マッチング条件がUNIQUEでないとならない。弊社ではマッチング条件にコールフロー名を使うつもりですが、どのメールがどのコールフローと対応するかなどの分析はまだです。
コールフロー毎に受信スロットを分ける運用にすべきか、御社とのオンラインミーティングでお尋ねしたところ、受信スロットは分けなくても、ルール次第でなんとかなる、とのお話でした。
でも現在までのところ、やはり何らかのカテゴリーで受信スロットを分けておくことが肝心な気がしています。今は受信スロットは一つで行っていますが、すでに把握が難しくなってきているからです。
また先日のオンラインセミナーの講師の方は受信スロットを分けていらっしゃいました。３．アクションやpigeonの設定は使いまわしができるとのアドバイスもいただきますが、２のことも考えるとよく考えて設計しないといけない気もしています。
色々書いてしまって恐縮ですが、何か良いアドバイスか、良い導入事例などあれば教えていただけないでしょうか？
ご迷惑をおかけした上で更にお尋ねして申し訳ありません。 -
連絡履歴のパラメータ一覧の scope のところに Displayname と scopeId がありました。
こちらから判別されたのではないでしょうか？はい、今回はそちらを見てスコープが異なることに気付くことができました。
連絡履歴から実行アクションが追えない
（7/15に「そういう仕様だからアクション・コールフロー・ガイダンスの命名の対応付けなど工夫してください。」との回答をいただいていましたが、これは今回のことで追えることが分かりました。確かに、先日の回答ではこの点は見落としておりました。
あくまでPigeon連絡を実行時のパラメーター情報、という見せ方のため使い勝手には欠けますが、表示されているID類は追跡に利用可能と思います。でも現在までのところ、やはり何らかのカテゴリーで受信スロットを分けておくことが肝心な気がしています。
受信スロット分ける/分けないの選択に関しては、選べるの状況であれば分けたほうが良いと考えます。
理由としては下記の通りです。- （ご理解の通り）受信スロットごとにルール・スコープ等をカテゴライズできる
- 受信スロットが分かれることで、誤ったルール判定を通ってしまうリスクが減る
- 1つの受信スロットから実行されるルールの数が少ないほうが、処理パフォーマンス上有利（極端に多いケースでなければ無視できますので、これは副次的メリットとお考えください）
何か良いアドバイスか、良い導入事例などあれば教えていただけないでしょうか？
AlertHubというよりはシステム開発での方法論由来の話になるのですが、いきなり設定を共通化・汎用化することを考えるよりも、まずは個別に分けた設定としてある程度作成を進めてみてからどこを共通化できるか考えるほうが上手くいくことが多いかと思います。
分量が多いとこれはこれで大変な作業になってしまうのですが、少しでも参考になれば幸いです。
よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
7件のコメント