Studio ガイド

最終更新日時 2026年2月18日

ベストプラクティス

コード化されたオートメーションの効率性、保守性、およびスケーラビリティを確保するには、ベストプラクティスに従う必要があります。このセクションでは、コードを活用したオートメーションソリューションの構築を開始するときに覚えておくべき主なベストプラクティスの概要を示します。これらのベストプラクティスに従えば、特にコードの構成、エラーの処理方法の実装、または再利用可能なコンポーネントの作成時に、コード化されたオートメーションを設計するのに役立ちます。

ローコードのオートメーションでテンプレートを使用する

ローコードオートメーション (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 コンテキスト」で、コンテキストの動作とその実装方法を確認してください。

ヒントとコツ

効率的で堅牢なコード化されたオートメーションを設計するには、以下に記載されているヒントとコツを参考にしてください。これらの情報は、コードを最適化し、エラーを回避して、パフォーマンスを最大限に高めるのに役立ちます。

名前空間は変更しないことをお勧めします。
アクションをクラス内に格納し、プロジェクト全体で再利用して、コードの重複を回避します。
設計時にインポートしたものの不要になった名前空間は削除できます。
複数のアプリケーションからデータを取得する必要がある場合は、コード化されたオートメーションのフェーズを分離して、さまざまなソースからのデータが混在しないようにします。