UI コンポーネントの再利用手法

UiPath のプロジェクトには、次の 2 つの主要レイヤーがあります。

• ロジック レイヤー - すべてのデータの検証と処理、およびプロセス フローに必要な他の論理命令が含まれます。
• GUI 対話レイヤー - データを抽出してアプリケーションに入力するために使用されます。

コンポーネントの保守や再利用に関する問題を防ぐために、GUI 対話レイヤーを分離することができます。その場合、ユーザー インターフェイスとの対話専用の再利用可能なコンポーネントが含まれる一連のライブラリを作成します。こうすることで、汎用性が高く非常に堅牢なライブラリを作成できます。すなわち、保守が容易で (GUI 対話要素のみが含まれ、他のプロセス依存ロジックが含まれない)、再利用性がきわめて高い (別のプロセスで同じアプリケーションを自動化する場合に、少なくとも一部のコンポーネントを再利用できる可能性が非常に高い) ライブラリです。

さらに、Studio v2020.10 でオブジェクト リポジトリが導入されたことで、UI 操作のオートメーションで使用する要素をまったく新しい方法で作成・管理できるようになり、スケーラブルで再利用性の高い UI 操作のオートメーションを構築するための環境が一変しました。

このページでは、ライブラリとオブジェクト リポジトリを使用して保守が容易で再利用可能なコードを構築する手法を定義するとともに、それを支えるアーキテクチャの原則とベスト プラクティスについて説明します。さらに、再利用可能なコンポーネントの作成に必要な手順一つひとつについて、ACME Web アプリケーションを使用する例を多数交えて詳しく説明します。

一般的な原則

プログラミング言語や使用プラットフォームに関係なく適用でき、UiPath Studio での RPA 開発場面で非常に役立つソフトウェア開発の原則には、さまざまなものがあります。

関心の分離

最も重要な原則です。関心の分離とは、1 つのプログラムを複数のセクションに分割して関心ごとに処理するように設計する必要があることを示します。この例では、ソリューションを階層化する、つまり各セクションをレイヤーにする必要があります。ソリューションを複数のレイヤーに分割することで、各レイヤーを個別にテストできます。標準的なソフトウェア アプリケーションには通常、次の 3 つの異なるレイヤーがあります。

• プレゼンテーション レイヤーは、ユーザーとの対話、データの表示、ユーザーへのデータの提示を指します。このレイヤーにビジネス ロジックを含めてはなりません。 

  RPA プロジェクトのコンテキストでは、GUI 対話レイヤーがこのレイヤーに取って代わります。オートメーションの主な目的は、実際のユーザーとの対話ではなく、他のアプリケーションとの対話であるためです。

• ドメイン レイヤーはドメイン ロジックに関連しており、アプリケーションで解決するビジネス/問題の一般的な領域を指します。

  RPA プロジェクトのコンテキストでは、アプリケーションのロジックに関係するロジック レイヤーにあたります。

• 永続化レイヤーは、アプリケーションに必要なデータを保存する場所です。

  RPA プロジェクトでは、永続的なデータ ストレージがないユース ケースもあるため必須のレイヤーではありません。このページの範囲を考慮し、ここでは永続化レイヤーは取り上げません。

単一責任

RPA プロジェクトの設計にあたって考慮すべきもう 1 つの原則は、単一責任の原則です。つまり、1 つの XAML ファイルで実行する処理は 1 つだけにする必要があります。この原則は疎結合および高凝集の原則とも関連します。つまり、階層化されていてもコードをモジュール化する必要があります。その結果、1 つのレイヤーで複数のモジュールを使用できます。

• 疎結合とは、モジュール同士の相互依存をできる限り少なくすべきであることを意味します。UiPath のプロジェクトでは、ライブラリを使用してモジュール化を実現します (詳しくは「メソッド」のセクションをご覧ください)。
• 高凝集とは、同じアプリケーションに関連付けられているアクションは同じモジュール内に保持すべきであるという意味です。

オブジェクト リポジトリを利用する

RPA プロセスとは、データとデータ操作ならびにアプリケーションとの対話の組み合わせです。

• データ - 変数または引数を定義するときに選択する定義済みのデータ型、または Studio にインポートして使用できる独自の型です。さらに、v2020.10 で導入された Data Service の機能を使用すると、一元的にデータ型を作成して複数のオートメーションで再利用できます。
• データ操作 - これは、オートメーションの構成要素であるアクティビティおよび/またはデータ操作を行う式によって実行できます。アクティビティは、Studio にインストールできるパッケージとして提供されています。提供されているパッケージが特定の機能に対応していない場合は、独自のカスタム アクティビティを作成することもできます。カスタムの UiPath アクティビティを構築する方法について詳しくは、「カスタム アクティビティを作成する」をご覧ください。
• アプリケーションの操作 - これは、UI Automation または連携/API を介して実行できます。現在、UI Automation はほとんどのアプリケーションで利用可能です。UI 対話コンポーネントは、ライブラリまたはオブジェクト リポジトリを使用して再利用できます。

オブジェクト リポジトリは階層構造になっています。各ノードが画面または要素を表し、すべてがアプリケーション レベル下に配置されています。ツリーの構成要素は以下のとおりです。

• UI アプリケーションとは、複数のバージョンを持つ対象のアプリケーションであり、各バージョンに複数の画面を含めることができます。
• 画面は、同じ画面に属する複数の要素を 1 つにまとめる UI スコープです。UI スコープは、ワークフロー内のアクティビティから抽出されるか、要素のキャプチャ時に生成されます。
• UI 要素には、完全または部分的な要素セレクター、アンカー セレクター、画面および要素画像のキャプチャ コンテキスト、画面上の要素について記述するその他のメタデータが含まれます。
• UI 記述子はセレクターの上位セットです。画面上の要素を一意に識別するための情報を保持しています。UI 記述子はワークフロー内のアクティビティから抽出され、それらのアクティビティをアプリケーション、アプリケーションのバージョン、画面、UI 要素ごとにグループ化する、構造化されたスキーマに追加されます。このタクソノミー構造のうち、記述子情報を保持しているのは画面と要素だけです。残りはグループ化に使用されますが、その役割はアプリケーションのバージョン間のアップグレードが確実に行われるようにすることです。

たとえば、下の画像から以下のことが分かります。

• UI アプリケーション: ACME バージョン 1.0.0
• 画面: Dashboard、Invoices、Login

• UI 要素: Email、Login button

  
  

  

  
  

オブジェクト リポジトリの要素と画面のそれぞれに、以下の詳細情報を指定します。

• 画面、ページ、または要素の、UI に表示されるとおりの名前 (例: Login button)。
• 種類 (例: Button、Input) (要素の場合のみ)。
• 任意の説明。要素の使い方を簡単に説明する概要を追加することをお勧めします (例: 「[Login] をクリックしてログイン プロセスを実行」)。

• UI 記述子 - 要素を一意に識別する情報。クラシック セレクター、あいまいセレクター、および画像ベースのオートメーションを組み込みます。画像ベースのオートメーションは、他の方法が機能しない場合にのみ使用することをお勧めします。

  
  

  

  
  

オブジェクト リポジトリの使用方法について詳しくは、「オブジェクト リポジトリについて」をご覧ください。

ワークフロー ライブラリとオブジェクト リポジトリを組み合わせてスケール アップする

オブジェクト リポジトリを使用すると、UI オートメーションの構築が大幅に簡単・効率的になります。ただし、この機能を存分に活用するには、オブジェクト リポジトリの各要素を独立したライブラリ プロジェクトに組み込んで、構築が必要な UI 操作もすべてそこに含めます。これにより、UI 操作を一切含まず、オートメーションのロジックのみを含むプロジェクトを構築できます。

自動化予定のアプリケーションごとにライブラリを作成し、UI 操作とオブジェクト リポジトリの要素をすべてそのライブラリに含めることをお勧めします。その後、ロジック レイヤー (メイン プロジェクト) に含まれるワークフロー ファイルから、ライブラリのアクティビティを呼び出すことができます。これにより、以下が保証されます。

• UI 操作を変更してもアプリケーションのロジックに影響しません。これは、モデル - ビュー - コントローラの分離に例えることができます。この例では、モデル レイヤーは主に、コントローラからビューに渡されるデータに関係します。
• 一度ライブラリをパブリッシュしてパッケージを作成すれば、異なるプロジェクトで参照することができます。毎回ライブラリを作成し直したり、複数のプロジェクト間でコードをコピーして貼り付けたりする必要はありません。UI 操作に変更が発生した場合は、ライブラリを更新して新しいバージョンをパブリッシュすれば、すべてのプロジェクトが最新バージョンを使用するように更新されます。さらに、ロジック レイヤーで変更が発生しても、UI 操作には影響しません。
• Orchestrator に同じライブラリの複数のバージョンを保存しておくことができるため、以前のバージョンを再度使用しなければならなくなっても簡単に取り出すことができます。これにより、同じライブラリの別のバージョンを異なるプロジェクトで使用したり、1 つのオートメーション プロジェクトを同じライブラリの異なるバージョンに即座に切り替えたりすることができます。

この手法を使用すると、メインのオートメーション プロジェクト (コントローラ) にプロセス依存ロジックがすべて含まれ、そこからライブラリ内のワークフローを利用して UI を操作します (擬似ビューと考えることができます)。最後に、モデルは引数で表されるので、これら 2 つのコンポーネント間でデータを渡すことができます。

UI ライブラリを作成する

上記のように UI ライブラリを作成するには、以下の手順に従います。

1. プロセスを分析して分解し、プロセスを構成するステップに分ける

プロセスを可視化するフロー ダイアグラムを作成することをお勧めします。

2. 各ステップをカテゴリに割り当てる

ステップが属するレイヤーに基づいて、各ステップを GUI レイヤーのカテゴリまたはロジック レイヤーのカテゴリに割り当てます。以下に例を示します。

• [クリック]、[文字を入力]、[テキストを取得] などのステップは GUI 対話レイヤーに割り当てます。

  ヒント: 単一のアクティビティをライブラリに追加しないでください。追加するのは、より複雑なアクション (「UI に何かが表示されるまでクリック」「表のすべてのページを移動してすべての行を抽出」など) だけにするか、複数の小さな GUI 対話要素で構成される複雑なアクション (ログインなど) にします。一般的なルールとして、ライブラリに追加する各コンポーネントは、単一の UI オートメーション アクティビティではなく、1 つのアクション (複数のアクティビティが含まれる、オートメーションのより複雑な一部) にすることをお勧めします。

• ロジック レイヤーには、ファイル処理、データ検証とフィルター処理、ビジネス例外処理などのアクションを割り当てます。ロジック レイヤーは、ステップを実行するために GUI 層を呼び出す必要があることに注意してください。

3. オートメーションで使用するアプリケーションごとに別々のライブラリを作成する

4. UI ライブラリを設定し、パブリッシュする

作成するライブラリごとに、以下の手順を実行します。

1. アプリケーション オブジェクトと、必要な画面をオブジェクト リポジトリ内に作成します。

   
   

   

   
   

2. オブジェクト リポジトリの各画面に対して、必要な要素を作成し、それらの記述子を作成します。

   
   

   

   
   
   注: オブジェクト リポジトリを使用できない場合も同じ手順に従いますが、前の 2 つの手順 (4-1 と 4-2) はスキップしてください。

3. 必要なアクションそれぞれに対して XAML ファイルを作成します。画面と要素は新しいワークフロー ファイルの作成時に追加できます。したがって、この手順は前の 2 つの手順と入れ替えて実行しても問題ありません。

   たとえば、以下は Acme テスト プロセスを自動化するために作成されたコンポーネントの一部です。

   
   

   

   
   
4. ライブラリを Orchestrator またはローカル NuGet フィードにパブリッシュします。

5. ライブラリをオートメーション プロジェクトにインストールする

[パッケージを管理] ウィンドウから必要なライブラリをインストールし、プロジェクト依存関係として追加します。ライブラリ内の各ワークフローは、[アクティビティ] パネルでアクティビティとして使用できます。プロジェクト ワークフローにドラッグ アンド ドロップして、アクティビティと同じ方法で使用できます。

ベスト プラクティス

引数

• パスカル ケース標準を使用して引数に名前を付けます。これは、UiPath Studio ライブラリのアクティビティのパラメーターで使用されている標準です。
• in_、out_, io_ のプレフィックスは引数名に含めないでください。これらはライブラリのアクティビティのプロパティとして表示されます。

  たとえば、引数は次の図のようになります。パブリッシュされたコンポーネントを見ると、引数が既に種類に基づいて異なるカテゴリに分類されていることがわかります。したがって、プレフィックスを追加すると冗長になります。

  
  

  

  
  
• GUI ライブラリ内にある、自動化するアプリケーションを開くか起動するすべてのワークフロー (例: アプリケーションを開いてログインするアクティビティ) は、生成されるアプリケーション ウィンドウを、UiPath.Core.UiElement 型の出力引数 (モダン デザイン エクスペリエンスの場合)、あるいは UiPath.Core.Window または UiPath.Core.Browser 型の出力引数 (クラシック エクスペリエンスの場合) を使用して返す必要があります。また、クラシック エクスペリエンス、モダン エクスペリエンスのどちらの場合も、パッケージ内の他のすべてのアクティビティに UiPath.Core.Window または UiPath.Core.Browser 型の入力引数が必要です。この引数により、現在のアクションを実行する必要のあるウィンドウを正しく指定します。これは、プロセスの実行時にアプリケーションの複数のインスタンスを開いている場合に非常に役立ちます。クラシック デザイン エクスペリエンスを使用している場合は、セレクターを引数として送信しないでください。

ACME Web サイト用のオートメーション コンポーネントのライブラリ (以下からライブラリの例をダウンロードできます) を開発するには、ブラウザーを開いてログイン操作を実行するコンポーネントが必要です。このアクティビティは、引数としてユーザー名、パスワード、サイト URL を受け取り、ブラウザーの要素を返す必要があります。任意で、ログインを既存のウィンドウで実行するシナリオをサポートするために、Browser を入力/出力引数として送信できます。

Browser 要素の型は UiPath.Core.UiElement です。

引数は次のようになります。

ブラウザーを開くワークフロー (例: ログイン ワークフロー) を構築するときは、まず Browser 引数が null かどうかを確認する必要があります。これに当てはまる場合は、以下のように <https://acme-test.uipath.com/> を新しいブラウザーで別のワークフローで開きます。

ログインが実行されて Browser 要素がプロセスに戻された後、このライブラリの他のアクティビティすべてでこのパラメーターが必要になります。たとえば、Web サイトからすべての請求書をダウンロードするアクティビティでは、次のパラメーターを設定します。

有効なブラウザーがこのアクティビティに渡されない場合、実行時にエラーが発生します。

エラー処理

• ライブラリ内では、エラーが表示されたら必ずエラーをスローするようにします。出力引数を通じてエラーを通知しないでください。
• ライブラリ コンポーネントの最後に結果を検証することをお勧めします。目的のアクションが実行されたかどうかを確認し、実行されなかった場合は例外をスローします。

例

アプリケーションのログインを実行するコンポーネントを作成する場合は、ログインが正しく実行されなかったときに例外をスローできます。このためには、資格情報を入力して [Login] ボタンをクリックした後に、[アプリのステートを確認] アクティビティ (モダン デザイン エクスペリエンスの使用時) または [要素の存在を確認] アクティビティ (クラシック デザイン エクスペリエンスの使用時) を追加し、タイムアウトを 10 秒に設定して、「Welcome...」ラベルが表示されるかどうかを確認します。このアクティビティが false を返す場合、認証プロセスは正常に完了しておらず、例外がスローされます。

構造と命名

各アクティビティに対してコンポーネントを作成すると、ライブラリがすぐに巨大化します。開発者が [アクティビティ] パネルでコンポーネントを簡単に識別できるように、コンポーネントの命名基準を定義する必要があります。お勧めするコンポーネントの命名基準は、「{アクション} {アクティビティで使用されるエンティティ}」という形式です。この標準に従うことで、以下が可能になります。

• 開発者は、コンポーネントの名前、このアクティビティで実行されるアクション、またはこのアクション中に使用されるエンティティでコンポーネントを検索できます。
• コンポーネントの用途や、コンポーネントで操作するアプリケーションのページを非常に簡単に把握できます。

場合によっては、{アクション} だけを使用しても構いません。この基準を使用できるのは、エンティティに対してアクションを実行しない場合 (例: ログイン) か、追加の属性をスペースで区切って名前に追加して、より多くの情報を名前で提供する必要がある場合です。

さらに、ライブラリ プロジェクト内にフォルダー構造を作成し、類似するコンポーネントを同じフォルダー内にまとめることをお勧めします。経験上、操作するメイン エンティティごとに 1 つのフォルダーを GUI レイヤー内に用意するのが適切です。操作可能なエンティティがアプリケーション内に多数ある場合は、多層フォルダー構造を使用できます。こうすることで、ライブラリの凝集度が大きく向上し、各エンティティで利用可能なアクションを確認しやすくなります。

フォルダーに名前を付ける場合、コンポーネントが操作するエンティティの名前 ({アクティビティで使用されるエンティティ}) を使用するか、コンポーネントが実行する全般的なアクティビティ ({アクション}) を使用できます。たとえば、Web アプリケーションのページを移動するコンポーネントをすべて格納するフォルダーを作成する場合は、Navigation という名前を付けることができます。

オブジェクト リポジトリのエンティティ (画面や要素など) にも命名規則を適用する必要があります。できれば、ワークフローやフォルダーの場合と同じようにパスカル ケースを使用します。

例

ACME Web サイト (https://acme-test.uipath.com/) は複数のページで構成され、ユーザーが各ページで Work Items、Checks、Accounts、Vendors、Invoices などのエンティティを操作できます。

ACME Web サイト内にある前述の項目を操作するコンポーネントを含むライブラリを作成する場合、次の画像のようにライブラリ内にフォルダー構造を作成して、ワークフローに名前を付けることができます。

注: 各コンポーネント/フォルダーの名前にはタイトル ケースを基準として使用することをお勧めします (Application Name、Action、Entity Used by Activity)。

大規模ソリューションへのアプローチ

大規模なオートメーション プロジェクトでは、ライブラリ内の複数のコンポーネントに、非常によく似た、あるいはまったく同じコードが含まれる場合があります。この場合、そのコンポーネントを独立したワークフローに分離することをお勧めします。また、このワークフローにライブラリ外からアクセスできないようにする場合は、パブリッシュから除外するようにマークして非公開にします。

さらに、同じロジックを複数のプロセスに実装しなければならない状況も考えられます。この場合、ロジックの再利用可能な部分を別々のライブラリに分離する必要があります。

次の図に、このようなソリューションの概要を示します。

メリット

• レイヤーを 1 つ構築するだけでよく、他方のレイヤーに干渉しない。
• 既存のコードを再利用でき、コードの使用時に毎回作成し直す必要がない。
• アプリケーションの更新が発生した場合、UI 操作を簡単に変更し、ライブラリを使用して変更をすべてのプロセスにプッシュできるので、再パブリッシュする必要がない。
• UI 対話レイヤーを複数のプロセス間で共有することで、同じモジュールをより徹底的にテストできる。また、一度にすべてのプロセスに対して修正を実行できるため、非常に堅牢で信頼性の高いオートメーションが実現できる。
• 専用の GUI 操作ライブラリを設けることで、特定のアプリケーションの UI オートメーションのテスト専用のテスト オートメーション プロジェクトを簡単に作成できる。これにより、コードのテストが非常に容易になるほか、アプリケーションに重大な変更があった場合にも速やかに検出できる。

プロジェクトの例

オブジェクト リポジトリを使用してライブラリを作成、使用する方法の例を示すために、ACME Web アプリケーションのユース ケースを作成しました。

ライブラリ

すべての ACME オートメーション アクティビティが含まれるライブラリは Acme_ObjectRepository という名前です。最新のバージョンは、以下で確認できます。

ライブラリ プロジェクトをダウンロード

ライブラリ パッケージをダウンロード

このライブラリは ACME Web アプリケーションの操作に特化したモジュールですが、目的に基づいてモジュール化され、複数のフォルダーに編成されています。

以下に、ライブラリ コンポーネントの内容を簡単に説明します。

• Login Acme.xaml - アプリケーションにログインします。次の引数が含まれます。

  • 4 つの入力引数 (URL、Username、Password、TimeoutDesired)。

  • UiPath.Core.UiElement 型の Browser 入力/出力引数。このコンポーネントは、既に開いている ACME ウィンドウにアタッチするか、ブラウザー ウィンドウがまだ開いていない場合は新しいウィンドウを開いて、ログインを実行します。Browser パラメーターによりブラウザー ウィンドウが返されます。この変数はライブラリに含まれる他のすべてのコンポーネントに渡されます。

    
    

    

    
    
• Logout Acme.xaml - Navigation モジュールから [Navigate to home page] ワークフローを呼び出し、その後現在のセッションを終了します。 

• User Options モジュール - ACME Web アプリケーション内の現在のアカウントの設定を変更できるオプションが含まれています。 

  • Reset test data.xaml - ACME アプリケーションで使用するテスト データをリセットします。

• Invoices モジュール - テスト データで見つかった請求書に対して実行するアクションが含まれます。

  • Download all invoices.xaml - アプリケーション内の請求書テーブルにある項目をすべて抽出し、DataTable として返します。
  • Download invoices by vendor tax ID.xaml - 特定の税 ID を持つ請求書が見つかるまで請求書テーブル全体を移動し、税 ID を返します。 

• Navigation モジュール - Web アプリケーションのさまざまなページを移動するワークフローが含まれます。

  • このモジュール内のコンポーネントは、主に他のライブラリ ワークフローで使用されます。通常はメイン プロセスから直接呼び出さないでください。ただし、ロボットを特定のページに移動してユーザーがアプリケーションを操作できるようにする有人プロセスで役立つ場合があるため、「パブリッシュ可能」とマークされています。

• Work items モジュール - アプリケーションで見つかった作業項目に対して実行するアクションが含まれています。

  • Download all work items.xaml - テスト データ内のすべての作業項目をダウンロードします。

プロセス

プロセスをダウンロード

メイン プロジェクト AcmeProcess_ObjectRepository は、4 つの異なるユース ケースで構成されています。ユーザーは ACMETest という名前のジェネリック型の Windows 資格情報を作成する必要があります。これにより、ロボットが ACME Web アプリケーションにログインする際に使用するユーザー名とパスワードを保存します。

このプロセスのユース ケース コンポーネントは、ACME UI コンポーネント ライブラリに組み込まれた複数のコンポーネントを使用してさまざまなタスクを実行します。

Main.xaml ワークフローが呼び出されると、ロボットは ACME アプリケーションにログインします。次に、いずれかのユース ケースを選択するようユーザーに求めるダイアログ ボックスが表示され、ユーザーが選択したユース ケースに対応するワークフローが呼び出されます。

テスト プロジェクト

テスト プロジェクトをダウンロード

テスト プロジェクト Test_UiPath.AcmeProcess_ObjectRepository は 5 つの異なるテスト ケースで構成され、各テスト ケースでプロセスの異なる機能をテストします (ログイン/ログアウト、すべての請求書のダウンロード、ベンダーの税 ID による請求書のダウンロード、作業項目のダウンロード)。