本投稿はUiPath (ja) Advent Calendar 2019 8日目となります。WindowsアプリケーションやHTMLフォームでコントロール (UI要素) を指定するときに、変わりやすいUIに対して応用編で使う「アンカー」「アンカーベース」という仕組みですが、既存でいくつか解説記事が出ていますが、まったく初めての人にはどれもちょっと難しいのではないか！？と思い書き始めたのがこの投稿になります。(自分なりにかみ砕いて書いたつもりですが、わかりにくかったらごめんなさい!)
はじめに: そもそもなぜコントロールはセレクターでつかめるのか
Windowsでは、昔から障碍者向けの機能を実装するためのアクセシビリティ機能が充実していました。たとえば色覚障碍者向けに画面の色調を変える「ハイコントラスト」が一番有名ですが、それに加えて聴覚障碍者向けに文字を音声にする「テキスト読み上げ」、マウスやキーボードが使えない障碍者のために声やその他の入力からマウスやキーボードをエミュレートする機能などです。
後に挙げた2つの機能を実装するには、Windowsのユーザーインターフェイス (UI)内に現れる各コントロールをシステムが認識できるようにして、障碍者のアシストを行うアプリケーションに情報を渡せるようにする必要があります。そのために生まれたのが「UI Automation」と呼ばれる標準APIです。Windowsのすべての画面要素は一番広い「デスクトップ」の子コントロールという形で階層的 (親子兄弟の関係) につながっています。
一方、ウェブページ/アプリケーションはブラウザーで表示する文書の構造解析/操作を標準化して扱いやすくしたいという別のニーズから「Document Object Model (DOM)」という仕様が標準化されました。
RPAの画面操作技術はこれらの仕組みに乗っかっているのです。より詳しい解説は @RPAbot さんの「RPAを支える技術についての解説」に譲ります。UiPathで使われる、UIの「セレクター」は、これらのAPIを使って実現しています。
コントロール (UI要素) がつかみにくい場合がある
しかし、世の中にはこのルールに従ってくれるアプリケーションばかりではありません。WindowsやVisual Studioが提供する「標準コントロール」およびコントロールをその単位で見た目を変える処理をしている限りはUI Automationはきちんと働くのですが、**ひとつのコントロールを巨大なキャンパスとして、その中にいろいろなコントロールを自分で描画してしまう場合 (カスタムドローイング)**は、Windowsシステムからはこのキャンバスの中の各コントロールは認識できなくなってしまいます。
ケース1: アクセシビリティが考慮されていないアプリケーション
有名なWindowsアプリケーションで実例を挙げると、たとえば「Adobe Acrobat Reader DC」です。起動してすぐの画面は以下のようになっています。
UI Explorerで調べてみると、緑色で囲ったコントロールはつかむことが可能ですが、赤枠のペインはひとつのコントロールで認識され、この中は「カスタムドローイング」が行われています。そのため、赤枠の中の "コントロール" のように見えるひとつひとつのオブジェクトをUI Explorerでつかむことはできません。同様に、赤く丸を付けたコントロールもUI Explorerには反応しません。
※ 2020年12月現在のバージョン (2020.013.20074)では、上記でつかめなかった場所のコントロールも掴めるようになっています。(ただ、試す回によっては相変わらずつかめない場合があり、動作が不安定である可能性があります。)
ケース2: 動的に変わるHTMLフォーム
ウェブアプリケーションの場合、各コントロールの構造は明確なのですが、コントロールにID、名前や目印がついていない場合に、コントロールの識別が難しくなります。ウェブアプリケーションはWindowsアプリケーションよりもレイアウトが動的であり、座標や画像認識での識別が難しくなる場合があります。また、場合によってはウェブページ内に画像が貼り付けられ、画像の中に文字が埋め込まれる場合も考えられます。
動的に変わるウェブアプリケーションはUiPathがRPA Challenge ( http://www.rpachallenge.com/?lang=JA )というデモアプリケーションで環境を提供しています。個人情報登録フォームが、登録するたびにレイアウトやコントロールのIDが変わる仕組みになっています。現実にもJavaScriptで動的に生成されるフォームはこのようなつくりになっていることがあるようです。
コントロールが識別できない場合に起こること
ロボットの実行時に「コントロールが見つからない」というエラーが表示されたり、エラーは出なくても異なるコントロールに対して操作が行われる可能性があります。どちらもその後のシーケンスがきちんと動作しなくなります。
アンカーって何?
UiPathでこれらのようなつかめないコントロールをつかむための足掛かりになるのが「アンカー」の機能です。アンカーとは日本語で「いかり (錨⚓)」のことで、まわりのコントロールに下ろしておくことで、近くのコントロールを認識しやすくする仕組みです。「アンカーベース」は、「錨を下ろす処理をするステップ」と考えてください。
似たような仕組みはMicrosoft WordやPowerPointのようなドキュメント作成アプリケーションでもあります。Wordではフローティングオブジェクト (画像)の位置を測る基準となる場所のことをアンカーポイントと呼んでおり、これと同じ概念です。
アンカーダイアログボックスが出る場合
UiPathでUI操作のレコーディングを行っていると、コントロールを選択した後に以下のようなダイアログボックスが出ることがあります。
アンカーを使いますか?
選択されたコントロールは信頼性のあるセレクターを持ちません。固定属性を持つ相対要素 (アンカー)を指定することにより、より確実に対象を特定できます。
これは、指定したUI要素に十分な情報がないとUiPathが判断した場合に表示されます。この場合は、アンカーとなる周りのコントロールを指定しておくことで、よりコントロールの識別精度が上がる場合があります。ただし、実際に精度が上げられるかどうかは試行錯誤をする必要があります。
どのような場合にアンカーダイアログボックスが出るか試してみる
では、どのようなケースでアンカーダイアログボックスが出るのか試してみました。リアルアプリケーションだと条件が判定しづらいので、Visual Studioでアプリケーションを作って、様々な画面レイアウトのものを作りUiPathのレコーディング機能で操作してみることにしました。
1. Windows Formの入力画面
まず、Windows FormのC#アプリケーションをビルドし、以下のようにラベル付きの入力フィールド (TextBox) が3つ並んだフォームで試してみました。これはダイアログボックスが表示されずに普通に識別できました。
UI Explorerで見た時のセレクターのXMLは以下のような形です。コントロールにtextBox1という名前もついているので、周りにラベルがあってもなくてもコントロール名で識別が可能です。
<wnd app='windowsformsapp1.exe' ctrlname='Form1' />
<wnd ctrlname='textBox1' />
2. WPFの入力画面
次にWPF (Windows Presentation Foundation)のC#アプリケーションを、以下のようにラベル付きの入力フィールド (TextBox) が3つ並んだフォームで試してみました。レコーディング中に真ん中のテキストボックスを選択して入力しようとすると、今度はアンカーダイアログボックスが表示されました。
UI Explorerで見た時のセレクターのXMLは以下のような形です。コントロールには名前がついておらず、idx属性がついているものの、これだけでは信頼できないということなのでしょう。(間に新しいコントロールが入るとidxは自動で変更になる可能性がある)
<wnd app='wpfapp2.exe' cls='HwndWrapper*' title='MainWindow' />
<ctrl idx='2' role='editable text' />
アンカーを左のラベル (Label3)に設定してレコーディングを終了すると、以下のようなシーケンスが作成されます。
作成されたアクティビティのメニューからセレクターを見てみると、idx属性は収録されていないことがわかります。
アンカーを設定したLabelコントロールと操作のターゲットとなるTextBoxコントロールはUI要素の階層構造でいうと以下のように兄弟関係となります。識別しやすい兄弟のコントロールを起点 (アンカー) にして、近くのコントロールを識別することになります。
Labelコントロールはname属性が表示名になっており、一意の識別が可能です。
<wnd app='wpfapp2.exe' cls='HwndWrapper*' title='MainWindow' />
<ctrl name='Label3' role='text' />
このようにウェブに近い技術のWPFではアンカーを使う必要が出てくることがあります。また、ウェブで作成するフォームも、入力フィールドのコントロールに名前を付けることが必須でないので、同様にアンカーでの対応が必要になってくるケースがあります。
自分でアンカーアクティビティの挿入もできる
レコーディングでアンカーが作成されない場合でも、アクティビティの一覧からアンカーベースをシーケンスに挿入することが可能です。「UI Automation」-「要素」-「検出」に「アンカーベース」と「コンテキスト対応のアンカー」の2つが存在します。
「コンテキスト対応のアンカー」はUiPath v2019-fastTrackの新機能で、コンテキスト対応版は精度があげられるようです。
以前の [アンカーベース (Anchor Base)] アクティビティ上に構築することで、新しい [コンテキスト対応のアンカー (Context Aware Anchor)] アクティビティを作成しました。精度を向上させるためにアンカーとターゲットのペアが考慮されるようになり、アンカーが一意である必要性がなくなりました。
まとめ
いかがでしたでしょうか。UI要素の指定としては応用編になりますが、この仕組みを理解して操作方法をマスターしておくと、通常のレコーディングで識別しにくいコントロールが出てきたときに、まわりのコントロールを駆使してターゲットしたいコントロールにたどり着くことができる場合があります。