サブプロセス

サブプロセスには、別の制御フローまたはサブプロセス内で使用できる制御フロー・アクティビティーの事前定義グループが含まれています。

図は、サブプロセスの概念トピックのグラフィックを示しています。
制御フローのサブプロセスは、データ・フローのサブフローに類似しています。 サブプロセスの基本的な利点は、複数の制御フローにおいて再利用できることにあります。 サブプロセスは、次の利点を備えています。
  • エラー処理、クリーンアップ操作などの頻繁に発生するタスクのサブプロセスを別個に作成することによって、モジュラー制御フローを設計できます。
  • サブプロセス内の制御フロー・アクティビティーのプロパティーを変更することによって、サブプロセスを参照するすべての制御フローに確実に変更を伝搬できます。 このようにして、複数の繰り返しタスクを使用する大規模で複雑な制御フローの保守を単純化することができます。

サブプロセスは独立して存在するものではありません。 制御フロー内に含まれる必要があります。 サブプロセスを、Administration Console 内で単独で実行またはスケジュールすることはできません。 ただし、サブプロセスを実行し、Design Studio 内でそのためのコードを生成することはできます。

Design Studio は、サブプロセス・エディターを備えており、サブプロセスの設計に使用できます。 制御フローを設計する場合と同じ方法でサブプロセスを設計し、妥当性検査することができます。 制御フローは、同じデータウェアハウス・プロジェクトに含まれるサブプロセスを参照できます。 制御フロー内でサブプロセスを使用するには、サブプロセス演算子を指定してサブプロセスを参照する必要があります。

サブプロセスは別のサブプロセスを参照できます。 ただし、サブプロセスはそれ自体を参照したり、別のデータウェアハウジング・プロジェクトに含まれるサブプロセスを参照することはできません。 サブプロセスを含む制御フローのパフォーマンスは、すべてのサブプロセス・アクティビティーを制御フロー内で直接定義した制御フローのパフォーマンスと同じです。これは、制御フロー用にコードを生成すると、Design Studio がサブプロセスを通常の制御フローとして処理するからです。

サブプロセス演算子には、3 つの出力 (「成功」、「無条件」、および「失敗」) が含まれています。これは、ほとんどの制御フロー演算子と同様です。 サブプロセスの実行は、開始演算子で開始されます。 開始演算子には、3 つの出力ポート (「開始」、「失敗」、および「クリーンアップ」) があります。 「開始」ポートのアクティビティーが、サブプロセスの主な処理ブランチを構成します。 開始演算子の失敗時ポートに接続しているアクティビティーは、「開始」ポートおよび失敗したアクティビティーの「失敗」パス (もしあれば) に接続されたアクティビティーが完了した後に、実行されます。 開始演算子のクリーンアップ・ポートに接続しているアクティビティーは、「開始」ポートおよび失敗時ポート上のアクティビティーが完了した後に、実行されます。

サブプロセス演算子は、次の 2 つの状況で失敗する可能性があります。
  • サブプロセス内で障害が発生し、「失敗」パスで実行するアクティビティーがない場合
  • サブプロセス・エディターで、開始演算子の「失敗」パスが呼び出されたものの実行されなかった場合

サブプロセス・エディターでの開始演算子の「失敗」パスは、サブプロセス内のすべての失敗したアクティビティーを補うものです。 したがって、サブプロセス内でアクティビティーが失敗し、サブプロセス開始演算子の「失敗」パスが実行された場合、制御フローのサブプロセス演算子は成功と見なされます。