UiPath Studio

UiPath Studio ガイド

ワークフローデザイン

レイアウトダイアグラム

UiPath は、ワークフローファイルを開発する際に、アクティビティをワーキング構造に統合する 4 つのダイアグラムを
提供しています。

  • フローチャート
  • [シーケンス (Sequence)]
  • [ステートマシン (State Machine)]
  • グローバル例外ハンドラー

[シーケンス (Sequence)]

シーケンスは、上から下への流れを示す単純な線形表現で、アクティビティ同士が繋がった単純なシナリオに最適です。たとえば、一度に 1 回のクリック/キー入力でナビゲーションと入力が行われる UI 自動化の場合に有用です。シーケンスは組み立てと理解が簡単なため、ほとんどのワークフローにおいて望ましいレイアウトです。

フローチャート

フローチャートは、アクティビティをより柔軟に接続でき、単純な 2 次元の形でワークフローをレイアウトする傾向があります。フローチャートは、自由形式で見た目がわかりやすいため、プロセス内部の分岐点を表示する場合に最適です。任意の場所を指すことができる矢印は、構造化されていない GoTo プログラミングステートメントに類似しているため、大きなワークフローでは各種アクティビティが複雑に絡み合うおそれがあります。

[ステートマシン (State Machine)]

ステートマシンは、かなり複雑な構造で、トランジションと呼ばれる条件付き矢印のあるフローチャートとしてみなすことができます。論理をよりコンパクトに表現でき、商取引に関わるビジネスプロセステンプレートの標準的な高レベルプロセスのダイアグラムに最適です。

グローバル例外ハンドラー

例外ハンドラーは、大小の自動化プロジェクトで使用できるように設計されています。実行エラーを特定するだけでなく、そうしたエラーが発生した際にワークフローの動作を決定することが、このハンドラーの最も重要な役割になります。デバッグ中に実行エラーが発生した場合、事前に例外ハンドラーで設定したオプションに従ってグローバル例外ハンドラーが介入するように設定することで、ユーザーがワークフローの動作を確認できるようにします。

選択肢

ロボットがデータ処理やアプリケーション操作で様々な条件に応じて異なる動作を行えるように、ワークフローに分岐を実装する必要があります。条件とそれに続くブランチの最も適切な表現を選択することは、ワークフローの視覚的な構造と読みやすさに大きな影響を与えます。

[条件分岐] アクティビティ

If アクティビティは、シーケンスを垂直に分割するため、短く均衡のとれた線形ブランチに最適です。より多くの条件を If… Else If の形でチェーンする必要がある場合、特にブランチが利用可能な画面サイズ (幅または高さ) を超える場合には、問題が生じます。一般的なガイドラインとして、ワークフローを単純/線形に維持するには、ネストされた If ステートメントは避けるべきです。

Flow Decision

フローチャートのレイアウトは、重要なビジネスロジックと関連する条件 (ネストされた [条件分岐 (If)] ステートメントまたは If… Else If コンストラクトなど) の表示に適しています。場合によっては、シーケンス内部でもフローチャートを使用することが適切であることもあります。

If 演算子

VB If 演算子は、マイナーでローカルな条件やデータの計算の場合に非常に有効で、場合によってはブロック全体を単一のアクティビティに縮小することが可能です。

[スイッチ] アクティビティ

スイッチ (Switch) アクティビティは、ブランチごとに別々の条件とアクティビティのある If… Else If カスケードを合理化してコンパクト化するために、If 演算子による収束に使用される場合があります。

Flow Switch

フロースイッチ (Flow Switch) アクティビティは、式の値に応じて次のノードを選択します。フロースイッチ (Flow Switch) は、フローチャートにおけるプロシージャ型のスイッチ (Switch) アクティビティと同じであるとみなすことができます。同一のスイッチノードからより多くの接続を開始することにより、12 を超えるケースと一致することができます。

データ

可視性とライフサイクルという観点から、データは、引数と変数という 2 つの形をとります。引数は 1 つのワークフローから別のワークフローにデータを渡すことを目的としていますが、変数は単一のワークフロー内部のコンテナーにバインドされているため、ローカルでのみ使用することができます。

変数スコープ

ワークフローファイルのどこでも使用可能な引数とは異なり、変数は、自身が定義されているコンテナーの内部 (スコープと呼ばれる) でのみ見ることができます。

変数は最も内側のスコープにのみとどめることを推奨します。これは、[変数 (Variables)] パネルに不要なものを含むのを避け、オートコンプリートにおいて、ワークフローの特定の点で関連するもののみを表示するためです。

注:

同じ名前の変数が 2 つ存在する場合 (このような場合はまったく推奨されませんが)、最も内側のスコープで定義された変数が優先されます。

引数

[分離 (Isolated)] オプション (ワークフローの実行を別のシステムプロセスで開始するオプション) でワークフローを呼び出す場合には、プロセス間でデータを渡すための引数として使用できるのは、シリアライズ可能なタイプのみとなります。たとえば、SecureString オブジェクト、Browser オブジェクト、Terminal Connection オブジェクトは、プロセス間の境界を安全に渡ることができません。

既定値

変数と入力引数には、静的な [既定値 (Default)] で初期化するオプションがあります。これは、呼び出し先のワークフローや他の外部ソースからの本物の入力データは不要であるため、個別にワークフローをテストする際にとても便利です。

命名規則

ワークフローファイル、アクティビティ、引数、変数には、プロジェクト全体におけるそれぞれの用途を正確に表すために、わかりやすい名前を付ける必要があります。

プロジェクトは、Orchestrator のユーザーインターフェイスにも表示され、マルチユーザー環境でも役立つ場合があるため、わかりやすい説明を付ける必要があります。

読みやすくするために、変数名と引数名も命名規則に合わせる必要があります。

  • スネークケース: First1_Name2first_name2
  • キャメルケース: FirstNamelastName
  • パスカルケース: First1Name2First1Name
  • ケバブケース: First-NameFirst-Name1

引数名は大文字と小文字が区別され、in_DefaultTimeoutin_FileNameout_TextResultio_RetryNumber などの引数タイプを示す接頭辞が必要です 。

アクティビティ名は、「保存ボタンをクリック」のように、操作を簡潔に表すものにします。操作を表すタイトルの一部分を必ず含むようにします ([クリック][文字を入力][要素の存在を確認]など)。

メインをのぞき、すべてのワークフロー名には、ワークフローの操作を表す動詞を含めます。例: GetTransactionData、ProcessTransation、TakeScreenshot など。

コメントと注釈

[コメント] アクティビティと注釈を使用して、手法の詳細や、特定のインタラクションまたはアプリケーションの動作の特性を記述します。後日ロボット プロジェクトに他のスタッフが参加することを考慮して、プロセスを簡単に理解できるようにします。

11 日前に更新


ワークフローデザイン


改善の提案は、API 参照ページでは制限されています

改善を提案できるのは Markdown の本文コンテンツのみであり、API 仕様に行うことはできません。