ワークフローのデザイン

レイアウトダイアグラム

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

• フローチャート
• シーケンス
• ステート マシン
• グローバル例外ハンドラー

シーケンス

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

フローチャート

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

ステート マシン

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

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

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

選択肢

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

[条件分岐 (if)] アクティビティ

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

フロー条件分岐

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

If 演算子

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

[条件分岐 (switch)] アクティビティ

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

フロー スイッチ

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

データ

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

変数スコープ

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

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

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

引数

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

既定値

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

命名規則

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

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

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

• スネークケース: First1_Name2、first_name2、
• キャメルケース: FirstName、lastName、
• パスカルケース： First1Name2、First1Name、
• ケバブケース: First-Name、First-Name1。

引数名には、引数の型を示すプレフィックスが必要です (例: in_DefaultTimeout、in_FileName、out_TextResult、io_RetryNumber)。

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

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

コメントと注釈

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