[UiPath]"Exchange関連アクティビティ"を活用する

はじめに

この記事は、[RPA] UiPath Friends 公式 Advent Calendar 2020 の7日目の投稿です。

追記情報

• 2020/12/08
  • ExchangeへのWebアクセスが許可されていない環境では利用できないことがわかりましたので、一部記述を変更しました。

まだ "Outlook" で消耗してるの？

という煽りはさておき。みなさんはUiPathでメール処理の自動化を行うとき、どのように実装していますか？
きっとほとんどのRPAデベロッパーのみなさんは、Outlookを使って自動化されているんじゃないかな、と思います。
だいたいの企業でOffice製品がインストールされていてすぐに使えるということもありますし、最近はOffice365（Microsoft365）を使っている企業も増えてきていて、それが基本的にはOutlookを使用する前提であるからです。

そのOffice365で使われるOutlookのメールのシステムって、実はExchangeという仕組みを利用しています。
そしてUiPathには、このExchangeに対して操作を行うことが出来るアクティビティが備わっているんですね。つまり、Office365を使っているユーザーのほとんどはそのアクティビティを利用した自動化が出来る、というわけです。

Exchange関連アクティビティを使うメリット

「いや、Outlookのアクティビティで十分動いてるし。。。」
まあそれはそうかもしれないですが、Exchangeを使うメリットって意外と大きいんです。

実はOutlookのアクティビティを使うときには、Outlookを起動しておく必要があります。厳密には必須ではないのですが、Outlookを起動した状態で操作することが現実的には推奨されます。
その理由は、Outlookを利用するアクティビティは、その端末が過去にダウンロードしておいたメールしか操作できないからです。すなわち、最新のメールを取り扱う必要があるとき（大抵の自動化がそのような要件だと思いますが）には、まずOutlookを起動して、サーバーから最新のメールをダウンロードする処理を行わなければいけないのです。
Exchangeを利用するアクティビティの場合、この作業は不要になります。このアクティビティは、都度Exchangeのサーバーにアクセスしてデータを取得します。サーバーには最新のメールが格納されているので、常に最新の状態のメールを取り扱うことが出来る、というわけです。

Outlookを起動する必要がないということは、いくつかのメリットを生み出します。
1つめに、動作の安定化が見込めます。RPAの特長のひとつであるUI操作は、業務の自動化にとって効果的ではあるものの、動作安定性の観点では出来る限り使用しないに越したことはありません。
2つめに、UI操作を行わないことによる動作時間の短縮が見込めます。アプリケーションの起動時間や、起動によるリソース消費が発生しないことによるメリットですね。
3つめに、（上記2点とも関連しますが）開発やメンテナンスの工数の短縮も見込めます。上の2点を考慮して、例えばTry-catchやRetry Scopeなどによる安定化の工夫を凝らす必要がなくなるので、その分の時間が削減できるというわけです。

Exchange関連アクティビティを使うデメリット

無論、まったくデメリットがないわけではありません。
1つめに、Exchangeの環境が存在しなければExchangeを利用しており、かつWebアクセスが有効な環境でなければこのアクティビティは使えません。ご自身のメールの環境がExchangeを利用しているかどうか、またWebアクセスが有効であるかどうか、は別途確認していただければと思います。
2つめに、実行する環境が途中の経路で認証などを求められることなくExchangeサーバーに接続できる必要があります。これは私の環境では未検証ですが、途中の経路で認証が求められる場合には接続できない可能性がひじょうに高いです。
3つめに、取得したいメールの量が多い場合にはタイムアウトが発生しやすいです。これはメールの取得をネットワーク越しに行うために発生するもので、Outlookを使用する場合には起こりにくい事象です。いちおうタイムアウトの値は設定可能で、私が開発した事例でも個別に設定して安定化を図っています。

実際につかってみよう（設定の仕方）

さて、それでは実際に使う方法をご説明したいと思います。
今回はプロパティペインのみ抜粋して紹介します。また直接Exchangeに関係しない項目や、他のメールアクティビティに共通している項目は割愛します。

Get Exchange Mail Messages

Send Exchange Mail Message

プロパティの説明

• ログオン
  • ドメイン
    • （実は設定したことがなく…… Exchange Onlineの場合は不要です）
  • パスワード
    • Office365にログインする際に利用するパスワードを指定します。
      • String型を利用します。SecureString型のデータを利用する場合は、別途 NetworkCredential型のオブジェクトを生成してから抽出する必要があります。
    • 企業によってはシングル・サインオン（SSO）を利用されていると思いますが、その場合にはそのシングル・サインオンで利用するパスワードを指定します。
  • ユーザー
    • Office365にログインする際に利用するメールアドレスを指定します。
      • メールの送受信に利用するメールアドレスとは異なることがありますので、設定時には注意してください。
      • ドメイン部分も正しく設定する必要があります。
• 共通
  • タイムアウト (ミリ秒)
    • タイムアウトの値を設定します。デフォルトでは 30,000ms = 30s です。
      • 「上限数」を大きくしたり、「添付ファイルを取得」をTrueにする場合は、この設定値も大きくしましょう。十分にテストすることをおすすめします。
• 接続
  • Exchange バージョン
    • プルダウンで "Exchange2013_SP1" を指定します。
  • サーバー
    • 文字列で "https://outlook.office365.com"と指定します（固定）。
  • メール自動検出
    • 未指定で結構です。
• ターゲット ※Get Exchange Mail Messages のみ
  • 共有メールボックス
    • Exchangeの機能である 共有メールボックス にあるメールメッセージを読み込みたい場合に指定します。
      • 未指定もしくは空白の場合、後述するログオンユーザー自身のメールボックスを読み込みます。
      • Outlookの場合は、アプリケーション上で設定する必要がありますが、Exchangeの場合にはアクセス権限が付与されていればOKです。
• 送信者 ※Send Exchange Mail Message のみ
  • 名前
    • 未指定で結構です。指定した場合でも、下記「送信元」で指定したメールアドレスに紐付く名前で送信されます。
  • 送信元
    • 送信元として利用するメールアドレスを指定します。アクセス権限が付与されている共有メールボックスを指定することが想定されています。

実際に動作させるところをお見せできれば良いのですが、あいにく公開できるような内容に留まっている環境がないため、ぜひ皆様のお手元でお試しいただければと思います。
上記のアクティビティと確認用のログ出力などを配置すれば、10分も掛からずにお試しいただけるかと思いますので。

さいごに

実はこのアクティビティを使うきっかけになったのは、もともとOutlook系のアクティビティで実装しようとしていた処理が上手く動作してくれなかったことでした。
自分が想像していたものが思い通りに動かないということは往々にしてあるかと思いますが、私の場合にはそれをきっかけに色々と調べた結果、よりメリットがある（と考えられる）別の手法に辿り着くことが出来ました。「メール処理だからOutlookだね」と考えるのももちろんありですが、さまざまなきっかけを「深く理解するために」、あるいは「新しい手法を見つけるために」ポジティブに捉えていただければ、面白いことがあるかもしれません。