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 対話レイヤーに割り当てます。

  ヒント： ライブラリに 1 つのアクティビティを追加せず、より複雑な操作 ( UI に何かが表示されるまでクリックする、 表のすべてのページを検索してすべての行を抽出するなど) や、ログインなどのより複雑な操作を追加するだけです。これは複数の小さな GUI 操作部分で構成されます。原則として。ライブラリに追加する各コンポーネントは、単一の UI Automation アクティビティではなく、複数のアクティビティを含むより複雑なオートメーションであるアクションである必要があります。</p.>

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

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

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

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

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

   

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

   

   注:

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

3. 必要なアクションそれぞれに対して XAML ファイルを作成します。画面と要素は新しいワークフロー ファイルの作成時に追加できます。したがって、この手順は前の 2 つの手順と入れ替えて実行しても問題ありません。 たとえば、以下は Acme テスト プロセスを自動化するために作成されたコンポーネントの一部です。

   

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

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

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

ベスト プラクティス

引数

• PascalCase標準を使用して引数に名前を付けます。これは、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 かどうかを確認し、null の場合は、別のワークフローの新しいブラウザーで <https://acme-test.uipath.com/> を開く必要があります。

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

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

エラー処理

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

例

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

構造と命名

アクティビティごとにコンポーネントを作成すると、ライブラリがすぐに大きくなりすぎてしまいます。開発者が [アクティビティ] パネルでコンポーネントを簡単に識別できるようにするには、コンポーネントに名前を付けるための標準を定義することが不可欠です。コンポーネントの命名に使用する標準は {Action} {Entity Used by Activity}です。この規格は、

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

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

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

フォルダーに名前を付けるには、コンポーネントが {Entity Used by Activity} と対話するエンティティの名前、またはコンポーネントが {Action}実行する一般的なアクティビティの名前を使用します。たとえば、Web アプリケーションのページ間を移動するすべてのコンポーネントを格納するフォルダーを作成する場合は、 ナビゲーションと呼ぶことができます。

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

例

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

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

注:

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

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

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

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

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

メリット

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

プロジェクトの例

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

ライブラリ

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

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

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

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

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

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

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

  

• 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 アプリケーションにログインします。次に、いずれかのユース ケースを選択するようユーザーに求めるダイアログ ボックスが表示され、ユーザーが選択したユース ケースに対応するワークフローが呼び出されます。

テスト プロジェクト

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

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