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

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

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

To avoid issues regarding the maintainability and the reusability of the components, you can separate the GUI interaction layer by creating a series of libraries with reusable components dedicated exclusively to the interaction with the user interfaces. This way, you can create a versatile and very robust library that is easy to maintain (it only contains GUI interaction elements and no other process-dependent logic) and extremely reusable (it is very likely that a different process that automates the same application can reuse at least some of the components).

Furthermore, the Object Repository introduced in Studio v2020.10 has brought a completely new way of creating and managing elements used in UI automation, making it a gamechanger when it comes to building scalable and highly reusable UI automations.

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

一般的な原則

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

関心の分離

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

• Presentation layer refers to the interaction with the user, displaying data and presenting it to the user. This layer should not contain business logic.

  In the context of an RPA project, the GUI Interaction layer replaces this layer, since the main objective of an automation is to interact with other applications instead of with an actual user.

• Domain layer is concerned with the domain logic, referring to the general business/problem domain that the application solves.

  In the context of an RPA project, this is the Logic layer that is concerned with the logic of the application.

• Persistence layer is where the data required by the application is stored.

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

単一責任

Another principle we need to take into consideration when designing and RPA project is the single responsibility principle. This means that a XAML file should do one thing and one thing only. This principle is associated with the low coupling and high cohesion principle. This means that the code should be modularized, even though it is layered. Therefore, we can have multiple modules for a single layer.

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

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

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

• Data - Pre-defined data types selected when defining variables or arguments, or your own types that you can import and use in Studio. In addition, the Data Service feature introduced in v2020.10 offers a centralized location where you can create data types and reuse them across automations.
• Data manipulation - This can de done through activities which are the building blocks of automation and/or data manipulation expressions. Activities are available in packages that you can install in Studio. You can also create your own custom activities when certain functionalities are not covered by the available packages. For more information about how you can build custom UiPath activities, see Creating a Custom Activity.
• アプリケーションの操作 - これは、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 記述子 - 要素を一意に識別する情報。クラシック セレクター、あいまいセレクター、および画像ベースのオートメーションを組み込みます。画像ベースのオートメーションは、他の方法が機能しない場合にのみ使用することをお勧めします。

  

See About Object Repository for more information on how to use the Object Repository.

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

オブジェクト リポジトリを使用すると、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 つの手順と入れ替えて実行しても問題ありません。

   For example, these are some of the components built to automate the Acme Test Processes.

   

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

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

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

ベスト プラクティス

引数

• Name arguments using the PascalCase standard. This is the standard used for the parameters of activities in UiPath Studio libraries.

• in_、out_, io_ のプレフィックスは引数名に含めないでください。これらはライブラリのアクティビティのプロパティとして表示されます。

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

  

• All workflows inside a GUI library which open / launch the application to automate (for example, an activity that opens and logs in to the application) should return the resulting application window using either an out argument of type UiPath.Core.UiElement for the modern design experience, or UiPath.Core.Window or UiPath.Core.Browser for the classic experience. Additionally, for both classic and modern experience, all other activities in the package should have an in argument of type UiPath.Core.Window or UiPath.Core.Browser which will indicate the correct window in which the current action should be performed. This is extremely helpful if you have multiple instances of an application open during the runtime of the processes. If you are using the classic design experience, do not send selectors as arguments.

Developing a library of automation components for the ACME website (you can download example library below) requires a component which opens the browser and performs the login operation. This activity should take as arguments the username, password, site URL, and return the Browser element. Optionally, to support a scenario in which the login takes place in an existing window, the browser can be sent as an in/out argument.

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

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

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

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

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

エラー処理

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

例

When creating a component that performs the application login, you may want to throw an exception if the login is not performed correctly. To achieve this, after entering the credentials and clicking the Login button, add a Check App State activity (when using the Modern Design Experience) or Element Exists activity (when using the Classic Design Experience) with a timeout of 10 seconds that checks if the "Welcome..." label appears. If this activity returns false, it means that the authentication process was not successful and an exception is thrown:

構造と命名

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

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

場合によっては、単に {Action}を使用できます。この操作は、エンティティ ( ログインなど) に対してアクションを実行しない場合や、名前に属性をそれぞれスペースで区切って追加し、名前を通じて詳細情報を提供する必要がある場合に実行できます。

さらに、ライブラリ プロジェクト内にフォルダー構造を作成し、類似するコンポーネントを同じフォルダーにグループ化することをお勧めします。経験則として、GUI レイヤー内で操作するメイン エンティティごとに 1 つのフォルダーを用意することをお勧めします。アプリケーション内で対話できるエンティティが多数ある場合は、多層フォルダー構造を使用できます。これにより、ライブラリの一貫性が大幅に向上し、各エンティティに対して利用できる操作を簡単に確認できるようになります。

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

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

例

ACME の Web サイト (https://acme-test.uipath.com/)には、ユーザーが作業項目、小切手、アカウント、ベンダー、請求書などのエンティティを操作できるページがいくつか含まれています。

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

注:

各コンポーネント/フォルダーの名前 (アプリケーション名、アクション、アクティビティで使用されるエンティティ) には、タイトル ケースの標準を使用することをお勧めします。

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

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

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

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

メリット

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

プロジェクトの例

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

ライブラリ

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

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

The Acme_ObjectRepository library contains all the ACME automation activities. Even though the library is a module focused on the interaction with the ACME web application, it is also modularized and organized into multiple folders, based on their purpose:

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

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

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

  • The Browser In/Out argument of type UiPath.Core.UiElement. This component will either attach to any ACME windows that are already open, or open a new browser window if one is not already open and perform the login. The browser parameter will return the browser window and this variable will be passed on to all other components in the library.

    

• Logout Acme.xaml - Navigation モジュールから [Navigate to home page] ワークフローを呼び出し、その後現在のセッションを終了します。
• User Options モジュール - ACME Web アプリケーション内の現在のアカウントの設定を変更できるオプションが含まれています。
  • Reset test data.xaml - ACME アプリケーションで使用するテスト データをリセットします。
• Invoices モジュール - テスト データで見つかった請求書に対して実行するアクションが含まれます。
  • すべての invoices.xaml をダウンロード - アプリケーション内の invoice テーブル内のすべての項目を抽出し、 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 アプリケーションにログインします。次に、いずれかのユース ケースを選択するようユーザーに求めるダイアログ ボックスが表示され、ユーザーが選択したユース ケースに対応するワークフローが呼び出されます。

テスト プロジェクト

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

The testing project, Test_UiPath.AcmeProcess_ObjectRepository consists of five different test cases that test different functionalities of the process: login / logout, download all invoices / download invoices by vendor tax id, download work items.