- 基本情報
- セットアップと構成
- オートメーション プロジェクト
- 依存関係
- ワークフローの種類
- 制御フロー
- ファイルの比較
- オートメーションのベスト プラクティス
- ソース管理との連携
- デバッグ
- ログ
- 診断ツール
- ワークフロー アナライザー
- ワークフロー アナライザーについて
- 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
- 変数
- 引数
- インポートされた名前空間
- コード化されたオートメーション
- トリガーベースの有人オートメーション
- オブジェクト リポジトリ
- ScreenScrapeJavaSupport ツール
- 拡張機能
- Studio でのテスト
- トラブルシューティング
Studio ガイド
To ensure that your coded automations are efficient, maintainable, and scalable you need to follow their best practices.
This section provides an overview of key best practices to remember as you embark on your journey of leveraging code to build automation solutions. Adopting these best practices will help you design coded automations, specifically when structuring your code, implementing error handling strategies, or creating reusable components.
ローコードのオートメーションでテンプレートを使用する
ローコード オートメーション (XAML) でコード ソース ファイル (CS) の型またはメソッドを使用している場合、プロジェクトの作成元のテンプレートにそれらを含めたり、このようなファイルをテンプレートにエクスポートしたりすると、XAML ファイルの名前空間が破損する可能性があることに注意してください。この破損により、Studio でプロジェクトを実行できなくなります。
コード ソース ファイルで引数として使用されるオブジェクト
コード ソース ファイルで引数として使用されるデータ オブジェクトには、空のコンストラクターが必要です。そうでない場合、Studio はワークフローをシリアル化できません。
並列処理
並列処理は、パフォーマンスを向上させ、コード化されたオートメーションへの実装も容易です。[並列繰り返し (コレクションの各要素)] ループを使用すると、オートメーションの実行速度を上げることができます。
入れ子になったクラス
コード化されたオートメーション (CS ファイル) では、ローコードのオートメーション (XAML ファイル) 内の入れ子になったクラスの変数や引数の使用または呼び出しはサポートされていません。[ワークフロー ファイルを呼び出し] アクティビティを使用してこのような種類の引数を呼び出したり、このような引数を XAML ファイル内に作成したりしようとすると、エラーが発生します。入れ子になったクラスの変数や引数は、他の CS ファイル内でのみ使用することをお勧めします。
コード化されたワークフローの継承
コード化されたワークフローの継承により、コードの再利用性とモジュール性が向上し、子クラスが親クラスの機能を継承および拡張するクラス階層を作成できます。この継承階層により、コードの整理が容易になり、複数のクラス間で共通の機能が重複するのを回避できます。さらに、親クラスに対する変更は自動的に子クラスにも反映され、バグや不整合が発生する可能性が低くなるため、メンテナンスと更新が簡素化されます。
CodedWorkflow、ParentFile (CodedWorkflow を継承し、カスタム メソッドを含む中間クラス)、および MyCustomWorkflow と AnotherCustomWorkflow (ParentFile を継承する派生クラス) の 3 つのクラスを使用して継承がどのように機能するかを見てみましょう。以下の表は、これらのクラスとファイル間の継承がどのように機能するかを示しています。
| コード化されたオートメーション | 説明 | コード |
|---|---|---|
CodedWorkflow (read-only partial class) | このクラスは、すべてのコード化されたワークフローの基盤として機能し、CodedWorkflowBase クラスから継承された、すべてのワークフローに共通する基本的なメソッドとプロパティが含まれています。この例では、他のすべてのワークフローが最終的に継承するクラスです。重要: 他のワークフローに継承させるファイルも、CodedWorkflow クラスと、暗黙的に CodedWorkflowBase クラスを継承する必要があります。これにより、すべてのワークフローが重要な機能を継承し、予期したとおりに動作するようになります。 | public partial class CodedWorkflow : CodedWorkflowBase { public CodedWorkflow() { //... } } |
ParentFile (code source file containing an intermediate class and a custom method) | このクラスは、CodedWorkflow を継承し、カスタム メソッドと機能を追加します。この例では、Orchestrator でのジョブの開始などの特定のアクションを実行する CustomMethod というカスタム メソッドが含まれています。 | public class ParentFile : CodedWorkflow { public void CustomMethod(string processName, string folderPath, StartProcessDtoJobPriority jobPriority, bool resumeOnSameContext, out string jobId) { // ここにカスタムコードを入力します。たとえば、このカスタム メソッド内では StartJob のコード化されたオートメーション API を使用します。jobId = systemです。StartJob(processName, folderPath, jobPriority, resumeOnSameContext);} } |
MyCustomWorkflow and AnotherCustomWorkflow (coded workflows that inherit the code source file) | これらのクラスは ParentFile を継承し、メソッドをオーバーライドするか、異なるパラメーター値を指定して、ワークフローをさらにカスタマイズします。この例では、MyCustomWorkflow と AnotherCustomWorkflow があり、どちらも ParentFile を継承します。 | public class MyCustomWorkflow : ParentFile { [Workflow] public void Execute() { // ここで基本クラスから CustomMethod を呼び出すことができます。string processName = "YourProcessName"; string folderPath = "YourFolderPath"; StartProcessDtoJobPriority jobPriority = StartProcessDtoJobPriority.Normal; bool resumeOnSameContext = false; string jobId; // カスタム メソッドを基本クラスから呼び出します。CustomMethod(processName, folderPath, jobPriority, resumeOnSameContext, out jobId); } } |
結論として、ParentFile は CodedWorkflow を継承するため、ParentFile を継承するクラスは、CodedWorkflow の機能とメソッドを間接的に継承します。つまり、MyCustomWorkflow と AnotherCustomWorkflow はどちらも、部分クラス CodedWorkflow から中間 ParentFile を介して、コア機能と他のカスタム クラス (CustomMethod など) を継承します。
カスタム サービスを登録する
カスタム ロジックを使用してコード化されたオートメーションを拡張するために、カスタム サービスを登録して後でコード化されたオートメーションで使用することができます。独自のカスタム サービスの登録方法については、「カスタム サービスを登録する」をご覧ください。
Before および After コンテキスト
テスト ケース内では、Before コンテキストと After コンテキストを使用して、テスト ケースの実行前と実行後に特定のアクションを実行できます。これらのコンテキストは、通常、リソースの設定とティアダウン、ログ記録の実行、およびテスト環境の管理に使用されます。「Before および After コンテキスト」で、コンテキストの動作とその実装方法を確認してください。
ヒントとコツ
効率的で堅牢なコード化されたオートメーションを設計するには、以下に記載されているヒントとコツを参考にしてください。これらの情報は、コードを最適化し、エラーを回避して、パフォーマンスを最大限に高めるのに役立ちます。
- 名前空間は変更しないことをお勧めします。
- アクションをクラス内に格納し、プロジェクト全体で再利用して、コードの重複を回避します。
- 設計時にインポートしたものの不要になった名前空間は削除できます。
- 複数のアプリケーションからデータを取得する必要がある場合は、コード化されたオートメーションのフェーズを分離して、さまざまなソースからのデータが混在しないようにします。