- 基本情報
- セットアップと構成
- オートメーション プロジェクト
- 依存関係
- ワークフローの種類
- 制御フロー
- ファイルの比較
- オートメーションのベスト プラクティス
- ソース管理との連携
- デバッグ
- ログ
- 診断ツール
- ワークフロー アナライザー
- ワークフロー アナライザーについて
- ST-DBP-002 - 多数の引数
- ST-DBP-003 - 空の catch ブロック
- ST-DBP-007 - 複数のフローチャートレイヤー
- ST-DPB-010 - [ワークフロー] または [テスト ケース] の複数のインスタンス
- ST-DBP-020 - 未定義の出力プロパティ
- ST-DBP-021 - ハードコードされたタイムアウト
- ST-DBP-023 - 空のワークフロー
- ST-DBP-024 - 永続性アクティビティの確認
- ST-DBP-025 - 変数のシリアル化の前提条件
- ST-DBP-027 - Persistence のベスト プラクティス
- ST-DBP-028 - 引数のシリアル化の前提条件
- ST-USG-005 - ハードコードされたアクティビティのプロパティ
- ST-USG-009 - 未使用の変数
- ST-USG-010 - 未使用の依存関係
- ST-USG-014 - パッケージの制限
- ST-USG-017 - パラメーターの修飾子が無効
- ST-USG-020 - 最小ログ メッセージ
- ST-USG-024 - 未使用で保存されたままの値
- ST-USG-025 - 保存した値の誤用
- ST-USG-026 - アクティビティの制限
- ST-USG-027 - 必要なパッケージ
- ST-USG-028 - ファイル テンプレートの呼び出しの制限
- ST-USG-027 - 必須のタグ
- ST-USG-034 - Automation Hub URL
- 変数
- 引数
- インポートされた名前空間
- コード化されたオートメーション
- はじめに
- カスタム サービスを登録する
- Before および After コンテキスト
- コードを生成する
- 手動テスト用のテスト ケースからコード化されたテスト ケースを生成する
- キャンバスに適したコード化されたワークフローを記述する
- トラブルシューティング
- トリガーベースの有人オートメーション
- オブジェクト リポジトリ
- ScreenScrapeJavaSupport ツール
- 拡張機能
- Studio でのテスト
- トラブルシューティング
コード化されたワークフローを構造化し、ローコード ビューアーでわかりやすくローコードのダイアグラムとして表示されるようにするための推奨事項。
小さな構造は、きれいなキャンバスに大いに役立ちます。以下の推奨事項は、ロー コード ビューアー でコード化されたワークフローを、不透明なコード ブロックではなく判読可能なローコード ブロックとしてレンダリングするのに役立ちます。影響順に、最も重要な変更から順に並べ替えられます。
手動でロールされたコードを使用する UiPath サービス
プロジェクトのサービス ( system.AddQueueItem(...)、 excel.ReadRange(...)、 mail.SendSmtp(...)、 uiAutomation.Click(...) ) の呼び出しは、リッチ アクティビティ カード (フレンドリーな表示名、サービス アイコン、編集可能なプロパティ、型指定された出力変数) として表示されます。
HttpClient、System.IO、または NuGet Excel ライブラリを使用してゼロから実装したのと同じ操作は、せいぜい 1 つの長い式を含む代入カードとして、最悪の場合、コード ブロックとして表示されます。最初にアクティビティ パッケージに手を伸ばし、ニーズをカバーするアクティビティがない場合にのみカスタム C# にドロップすると、より多くのワークフローが可視化されます。
// Renders as a "Write Range" activity card with editable properties:
excel.WriteRange("C:\\out.xlsx", "Sheet1", "A1", table);
// Renders as an opaque code block:
using var writer = new StreamWriter("C:\\out.csv");
// Renders as a "Write Range" activity card with editable properties:
excel.WriteRange("C:\\out.xlsx", "Sheet1", "A1", table);
// Renders as an opaque code block:
using var writer = new StreamWriter("C:\\out.csv");
オーケストレーション レイヤーとしてのエントリ メソッド
グラフ ビューでは、エントリ メソッド ([Workflow] または Execute) のみが描画されます。独自のメソッドの 1 つを呼び出すたびに 1 つのラベル付きブロックになり、それを選択するとヘルパーにドリルダウンされます。
エントリ メソッドの最上位レベルの分岐、ループ、およびエラー処理を維持し、詳細なステップ シーケンスを適切な名前のプライベート メソッドに移動すると、グラフは低レベルのカードの壁ではなく、クリーンで高レベルのフロー ( ValidateInvoice → PostToQueue → NotifyFinance ) として読み取られます。また、[ワークフロー] ビューにはヘルパーごとに専用のセクションがあるため、何も非表示になりません。ここでは、意図を明らかにする名前が二重に重要です:メソッド名はブロックラベルです。
式ではなくステートメントとしての制御フロー
キャンバスは、ステートメント レベルで存在する分岐とループのみを描画できます。式 (lambda、Language Integrated Query (LINQ) チェーン、入れ子になった三項、 switch 式など) 内に詰め込まれたロジックは 1 枚のカードに圧縮され、ビジュアライザーの目的を果たせません。
switch違いは注目に値します。switch ステートメントは、1 つのケースにつき 1 つのアームを持つ Switch コンテナーとして完全にレンダリングされますが、式の形式 (var label = total switch { ... };) は 1 枚の [代入] カード内に圧縮されたままになります。分岐が読者に表示されるべきプロセス ステップである場合、ステートメント形式が適しています。
// Invisible logic — one code block, the filtering and branching are not drawn:
invoices.Where(i => i.Amount > 1000).ToList().ForEach(i => Approve(i));
// Visible logic — a loop containing a decision containing an Invoke block:
foreach (var invoice in invoices)
{
if (invoice.Amount > 1000)
{
Approve(invoice);
}
}
// Invisible logic — one code block, the filtering and branching are not drawn:
invoices.Where(i => i.Amount > 1000).ToList().ForEach(i => Approve(i));
// Visible logic — a loop containing a decision containing an Invoke block:
foreach (var invoice in invoices)
{
if (invoice.Amount > 1000)
{
Approve(invoice);
}
}
LINQのワンライナーは、その詳細を喜んで非表示にする単純な投影である場合に問題ありません(var names = rows.Select(r => r.Name).ToList(); 1つの割り当てカードとしてレンダリングされます)。経験則: ダイアグラムの読者に分岐が表示される場合は、 if、 switch、または foreachと記述します。
フォールバック構造のレンダリング可能な同等のもの
いくつかの一般的な構造は、コード ブロックにフォールバックします。それぞれには、代わりに可視ブロックを生成するレンダリング可能な同等のものがあります。
| 代わりに | 書き込み | なぜなら、 |
|---|---|---|
list.ForEach(x => ...) | foreach (var x in list) | 体が見えるブロックになる |
| ローカル関数 | プライベート メソッド | プライベート メソッドは、ナビゲーション可能な Invoke ブロックとして表示されます。 |
using var handle = excel.UseWorkbook(...); | using (var handle = excel.UseWorkbook(...)) { ... } | ブロック フォームはスコープ フレームとして表示され、その内部の handle 呼び出しをアクティビティとして解決できます |
int a = 1, b = 2; | 1 行につき 1 つの宣言 | それぞれが専用の [代入] カードになります |
string result; result = ...;後で | 初回使用時の初期化子を含む宣言 | ベア宣言はコードブロックにフォールバックします |
インライン変数宣言 (ステートメントごとに 1 つ)
初期化子を含む宣言は、代入カードとして (またはアクティビティ カードの出力として) 表示され、メソッドごとの [変数] パネルにフィードされます。ベア宣言はコード ブロックとしてレンダリングされます。各変数の値が最初に生成される場所で宣言すると、変数は表示されたままになります。
var asset = system.GetAsset("Config"); // activity card, output: asset
int retryCount = 0; // Assign card, typed
var asset = system.GetAsset("Config"); // activity card, output: asset
int retryCount = 0; // Assign card, typed
ビューアーが推測できない明示的な型
キャンバスでは、各出力変数に、見つけられる最適な型のラベルが付けられます。
- 認識されたアクティビティの呼び出しの場合、種類は自動的にパッケージ メタデータから取得されます。
var asset = system.GetAsset(...)には実際の戻り値の型がすでに表示されているため、varコストはかかりません。 - それ以外のすべて (プレーンな代入、独自のメソッドへの呼び出し、計算式) については、
varは文字通りvarと表示されます。明示的な型を指定すると、実際の型がカードと [変数] パネルに配置されます。
var totals = ComputeTotals(rows); // Variables panel shows: totals : var
DataTable totals = ComputeTotals(rows); // Variables panel shows: totals : DataTable
var totals = ComputeTotals(rows); // Variables panel shows: totals : var
DataTable totals = ComputeTotals(rows); // Variables panel shows: totals : DataTable
意図を説明するコメント
アクティビティ、メソッド呼び出し、if、foreach、for、switch、try、return、または#regionの直上に配置された// コメントがそのブロックに添付されます。グラフ ビューではカードの説明、ワークフロー ビューでは行のツールチップ、プロパティ パネルでは [説明] フィールドになります。連続するコメント行が結合されます。
// High-value invoices need manual approval before posting
system.AddQueueItem("InvoiceApproval", reference: invoice.Id);
// High-value invoices need manual approval before posting
system.AddQueueItem("InvoiceApproval", reference: invoice.Id);
そのようなステートメントの上にないコメントは、独自の小さなコード行としてレンダリングされるため、ステップごとに 1 つの意図的なコメントは、散在するコメントよりも読みやすいです。
リージョン別にグループ化されたプロセス フェーズ
#region Name ... #endregion は、両方のビューで名前付き折りたたみ可能なグループとしてレンダリングされ、領域を入れ子にすることができます。リージョンにビジネス フェーズ ( Login、 Process invoices、 Reporting ) にちなんで名前を付けている場合、折りたたまれたグラフはプロセスの概要のように見えますが、リージョンを展開するとそのステップが表示されます。
関連する割り当てはグループ化されます。
2 つ以上の連続する割り当ては、1 つの [複数代入] カードに折りたたまれます。関連する値を中断のない 1 回の実行で初期化することで、フロー全体に値が散らばるのではなく、1 つのすっきりとしたカードに保持されます。逆に、独自のカードに値する課題は、他の課題とは一線を画す必要があります。
ステートメントごとに 1 つの呼び出し
呼び出しがチェーンされている場合 (row.GetValue("col").ToString().Trim())、ビューアはチェーンを 1 つの行としてしか表示できず、認識されない受信者のチェーンは完全にフォールバックします。意味のあるチェーンを、名前付き中間変数を持つステップに分割すると、各ステップに独自のブロックが与えられます。Excel ブックやメール フォルダーなどのハンドル API の場合、ビューアーがハンドルを追跡できるため、フォローアップ呼び出しは適切なアクティビティとして表示されます。
認識可能なワークフロー呼び出し
workflows.MyOtherWorkflow(arg1, arg2)は専用の [ワークフローを呼び出し] カードとして表示され、各引数には方向 (入力、出力、または入力出力) とワークフロー ファイルへのナビゲーションによってバッジが付けられます。- プロジェクトの別の
.csファイルへの呼び出しSharedHelpers.Method(...)、ナビゲート可能な Invoke ブロックとしてレンダリングされます。これらを、より長いチェーンの一部ではなく、ステートメントごとに 1 つの呼び出しとして保持することで、解決できます。
クイック チェックリスト
- ステップでは、アクティビティ サービス (
system.、excel.、mail.など) を使用します。これは、手作業で作成した同等のものではなく、 です。 [Workflow]メソッドは短く、適切な名前のプライベート メソッドをオーケストレーションします。- 分岐とループはステートメント (
if、switch、foreach、for、while、try) であり、ラムダや LINQ パイプラインに隠されたロジックはありません。 - 変数は、初期化子を使用して、ステートメントごとに 1 つずつインラインで宣言されます。
- 明示的な型は、ヘルパー メソッドの結果や計算値など、ビューアーが推論できない場合に使用されます。
- 重要な各ステップの上には、1 行の
//コメントがあります。 - プロセスのフェーズは
#regionにラップされます。 - 各ステートメントは、長いチェーンのない 1 つのサービス呼び出しまたはヘルパー呼び出しを保持します。
- 他のワークフローは
workflows.X(...)を介して呼び出されます。 - キャンバスに灰色のコードブロックカードは残っておらず、それぞれが視覚的なビューが盲目になった場所です。