こんにちは、RPAコンサルタントの鈴木です。
今回はNEアセット（日商エレクトロニクス標準BPアセット）に関する記事の第二回として、「メール送信オブジェクト」について取り上げようと思います。
>>NEアセットって何？という方はこちら：「日商エレクトロニクス標準BPアセットの使い方（１） - 概要編」
メール送信オブジェクトテンプレートとは？
NEアセットには、「NET - メール送信オブジェクトテンプレート」というテンプレートが同梱されています。このテンプレートは名前の通り、Blue Prismからメール送信をするオブジェクトを作るためものです。しかし、Blue Prism開発者の方であればご存じかと思いますが、Blue Prismはわざわざ機能を自作しないとメール送信が出来ないなんてことはありません。標準で「Email - POP3/SMTP」というオブジェクトが存在しており、「Send Message」アクションでメールを送信することができます。では「メール送信オブジェクトテンプレート」で作るメール送信オブジェクトとは、何なのでしょうか。実はここでいうメール送信オブジェクトとは、標準のメール送信を呼び出すときに、メール送信と一緒に実行する必要べき処理をまとめたものです。「Email - POP3/SMTP」の「Send Message」はメールを送る以外の処理を一切行いませんが、代わりに「メール送信オブジェクト」の「メール送信」を呼び出すと、同時に必要な処理を行った上で「Send Message」をしてくれるという訳です（このような実装をプログラム開発の用語で「ラップ」と呼び、また何かをラップする機能を持ったオブジェクトのことを「ラッパー」と呼びます）。
ただそもそも、「メール送信と同時に行うべき処理」と急に言われてもイメージが湧きにくいと思いますので、これから具体的な機能を見ていきましょう。
メール送信オブジェクトテンプレートの機能① SMTPサーバー/ポートの自動設定
標準オブジェクトのPOP3/SMTPでは、メール送信アクションを呼び出す前に、「Configure(設定)」アクションを呼び出して、使用するSMTPサーバーやポートの設定を行う必要があります。もちろんこの設定は会社ごとに異なるため、Blue Prismが予め設定した状態で提供するのは不可能なのですが、RPAから利用するSMTPサーバーが１つの会社内で異なるということは考えにくい話です。それなのにプロセスを１つ作るたびに毎回この設定を実装する必要があるでしょうか？ NEアセットのメール送信オブジェクトには、メール送信前にその会社のSMTPサーバーを設定する機能が付いているため、個々のプロセスでは設定を意識する必要がありません。
メール送信オブジェクトテンプレートの機能② 宛先アドレスのチェック
同じメール送信でも、社内向けと外部向けでは確認のレベルが異なるはずです。会社ごとにルールが異なると思いますが、例えば日商エレでは原則的にRPAによる外部メール送信は禁止としています。しかしこの手のルールにはヒューマンエラーが付き物です。固定のアドレスにメールを送信するロボットであればレビューでチェックすることも出来るでしょうが、ファイルやシステムからメールアドレスを読み取り、そのアドレスにメールを送信するようなロボットを考えてみましょう。誰かがその入力データに外部アドレスを設定してしまうという事故を防ぐためには、ロボット側でアドレスのチェックを実装する必要があります。しかしこのようなチェックを個別のプロセスに実装するのは無駄が大きく、ミスの原因にもなります。NEアセットのメール送信オブジェクトでは、メール送信前に宛先アドレスをチェックし、特定のパターン（@nissho-ele.co.jpで終わる、など）に当てはまらないアドレスへの送信を拒否することができます。
メール送信オブジェクトテンプレートの機能③ CC、BCCの設定
Blue Prism標準のPOP3/SMTPオブジェクトでは宛先にTo以外を設定することができず、CCやBCCを設定するにはプログラムの知識が必要でした。非常に業務担当者からの要望が多い機能ですので、NEアセットのメールオブジェクトは予めCC、BCCの設定が可能な状態になっています。
※厳密にはテンプレートの機能ではなく、製作済みオブジェクト「NEEX - POP3/SMTP」（標準のPOP3/SMTPオブジェクトの機能強化版）の機能になるため、テンプレートを使わずオブジェクトのみを利用することもできます。
メール送信オブジェクトテンプレートの機④ 共通送信先の追加
こちらも会社による面がありますが、RPAから送信されるメール（特にエラー時のメール）はRPA運用チームにも送信する、といったルールがある会社は多いのではないでしょうか。しかし、全ロボットに適用されるルールなら、メール送信時に宛先を追加する処理は共通化したいものです。NEアセットのメール送信オブジェクトでは、メール送信アクションの入力として「共通送信先にも送信」というフラグがあり、このフラグをTrueに設定するだけで自動的に共通の送信先（予め環境変数に設定）に送信することができます。
メール送信オブジェクトのカスタマイズ
ここまでNEアセットのメール送信オブジェクトテンプレートに実装されている機能を紹介してきましたが、実際に使用するには、このテンプレートを元に、自社の環境・ルールに合わせたメール送信オブジェクトを作成する必要があります。カスタマイズの方法を見ていきましょう。
①カスタマイズ用オブジェクトの保存
前回の記事でも紹介した通り、最新版のインポート時に上書きされないよう、カスタマイズ用のオブジェクトを名前を付けて保存しましょう。（左上メニューのファイル⇒名前を付けて保存）
②SMTPの設定
initialize（初期化）ページを開くと、SMTP設定を行う部分があります。サンプルとして [NET_SMTPサーバ] [NET_SMTPポート] という環境変数が配置してありますが、一般的に環境変数名にはプロジェクトごとのルールが存在すると思いますので、まずは自社の命名規則に沿った環境変数を作成し、利用するSMTPサーバーとSMTPポートを格納しましょう。その後、「SMTP設定」アクションステージを開き、作成した環境変数を入力変数に設定してください。
initialize（初期化）ページはそのオブジェクトが最初に利用されるタイミングで自動的に実行されるため、このページに設定アクションを配置しておくことで、メール送信前に自動的にSMTPサーバーとSMTPポートが設定されるようになります。
③宛先アドレスチェックの設定
※2023/05追記※
NEアセット2.0で、「送信先アドレス確認」ページは「送信先の確認・生成」ページに変更され、新機能「メールエイリアス」を使った配信・送信権限チェックが可能になりましたが、個別環境向けのカスタマイズ手順にはほぼ影響はありません。ページ名のみ読み替えてご利用ください。
「送信先アドレス確認」ページを開くと、「NET_メール送信許可アドレスパターン」という環境変数が配置されています。こちらも同様に、環境変数名を変更した上で、「アドレスパターンマッチ」ステージの参照を変更しましょう。
環境変数の参照を修正したら、その環境変数にメール送信を許可するアドレスのパターンを設定する必要があります。アドレスのパターンは正規表現で設定しますが、ここでは最もよく使う「自社ドメインにだけ送信を許可する」パターンをご紹介します。
「@nissho-ele.co.jp」を含むアドレスのみを許可するパターン： .*@nissho-ele.co.jp「.*」は任意の文字が任意の個数あるという意味になります。グループ会社のドメインや、特例として認められた外部アドレスを追加したい場合には、次のようにします。
上記に加え、「@sojitz.com」も許可するパターン： .*@nissho-ele.co.jp|.*@sojitz.com
更に「xxx-dls@mail.dls.dl-service.jp」も許可するパターン：
.*@nissho-ele.co.jp|.*@sojitz.com|xxx-dls@mail.dls.dl-service.jp「|」で複数のパターンを繋ぐと、そのいずれかに該当するという意味になります。その他、詳しい正規表現の説明については詳しい解説サイトが多数ありますので、「正規表現」で検索いただくとよいと思います。
④送信元／共通送信先の設定
メール送信処理も、自社ルールに合わせてカスタマイズしましょう。「メール送信」ページには「NET_メール送信元アドレス」と「NET_共通メール送信先アドレス」という２つの環境変数があります。RPAからのメール送信元（Fromアドレス）は、固定のアドレスとするか、ロボットIDなどを元にした命名規則となっていることが多いと思います。固定のアドレスの場合は、今までの環境変数同様に対応すれば問題ありません（例："rpa@nissho-ele.co.jp"を環境変数に設定し、「メール送信」ページで参照している環境変数名を修正）。ロボットIDなどを元にメールアドレスを決めるルールの場合、ページのinputでIDを受け取り、それを元にメールアドレスを生成する計算ステージを配置すると良いでしょう。
共通メール送信先についても対応は同様ですが、環境変数名を変更した場合は青字になっている「共通送信先設定あり？」ステージと、「共通送信先をToに付与」ステージの両方で参照を変える必要がある点に注意してください。この部分の処理は、本番環境のみ共通送信先を設定しておき、テスト環境や開発環境では値を空白にしておくという運用を想定しています。例えば、運用チームに全てのエラーメールを送信するルールだとしても、開発中のメールまでは不要のはずです。
おまけ：高度なカスタマイズ
ここまでの手順を踏めばメール送信オブジェクトは利用可能になりますが、更に高度なカスタマイズを行う案をいくつか挙げておきます。特定の案を推奨するものではなく、プロジェクトのルールに照らして必要であれば実施するとよいでしょう。
固定メッセージの追加
メール本文の末尾に「このメールは送信専用のアドレスから送信されています。返信はしないでください。」といった固定のメッセージを付加するルールの場合、その処理もこのオブジェクトに実装することは可能です。ただしこのカスタマイズを行う場合、HTMLメールの場合を考慮してください。単に「Body(本文)」データアイテムの末尾に文言を足すだけではHTMLメールのときに上手く動きませんので、「BodyIsHTML」フラグを用いて処理を分岐させる必要があります。
ワークキューの利用
メールサーバーダウン時のリトライなどを考慮すると、メール送信を即座に行うのではなく、送信リクエストを一度ワークキューに貯めてからワークキュー経由で送信するようにすることも可能です。その場合は専用のメール送信プロセスを作成することになりますが、メール送信オブジェクトの機能の大半をそのプロセス側に移してよいと思われます（移すのはコピペでOK）。メール送信オブジェクトには、各プロセスから受け取ったinputを元に、所定の形式でキューアイテムを追加する処理を実装しておくとよいでしょう。
