HCL Workload Automation: ビジネス ロジックによってワークロードを駆動する方法

2023/8/3 - 読み終える時間: 3 分

HCL Workload Automation: How to drive your workload by business logic https://blog.hcltechsw.com/workload-automation/hcl-workload-automation-how-to-drive-your-workload-by-business-logic/

HCL Workload Automation: ビジネス ロジックによってワークロードを駆動する方法

2023年8月2日

著者: RICCARDO PIZZUTILO / Technical Sales Specialist, HCL Workload Automation

HCL ワークロード オートメーション ソリューションを使用してワークフローをジョブ ストリームに設計する場合、プロセス全体が単純なパイプラインとしてモデル化されておらず、予測されたフローチャートの実装に分岐と決定ロジック (IF… THEN.. ELSE…) が必要になる場合があります。 。

HCL Workload Automation の条件付き依存関係機能を使用すると、この設計上の問題を非常に簡単に解決できます。 多くのユースケースで条件付き依存関係を作成して使用する方法を見てみましょう。

まず最初に、条件付き依存関係とは何ですか?

これは、特定のステータスに達した場合、または親ジョブで特定の出力条件が検証された場合に解放されるジョブの依存関係です。 条件が満たされない場合、依存ジョブは抑止されます。

ジョブ ステータスに対する条件付き依存関係について考えると、これは親ジョブが成功で終了するかキャンセルされた場合に解放される標準的な依存関係を一般化したものであると断言できますが、条件付き依存関係では、ABEND または RUNNING 状態であっても、あらゆるステータスを要件としてマップできます。 。

親ジョブの完了時に満足できない場合、子ジョブは標準の依存関係のように HOLD ステータスのままではなく、SUPPRESS 状態になります。

最初のユースケースのシナリオは次のとおりです。

使用例 1: エラー管理

この使用例では、スケジューラは、PRINT_ANSWER ジョブがエラーで終了した場合に備えて、ジョブ ストリームの処理を区別したいと考えています。

この目標を達成するには、PRINT_ANSWER からジョブ PROCESS_DATA の依存関係を作成し、それに条件付き依存関係としてフラグを付け、ステータスを SUCC として選択するだけで十分です。一方、MANAGE_ERROR ジョブの条件付き依存関係は ABEND ステータスに関連付けられます。

この図からわかるように、PRINT_ANSWER ジョブが成功すると、MANAGE_ERROR ジョブは抑制され、通常の PROCESS_DATA ジョブが実行されます。

場合によっては、ジョブのステータスではなく戻りコードに応じて、ジョブ ストリーム フローを異なる方法で管理する必要があります。

別の例を見てみましょう。

ユースケース 2: 戻りコードによる分岐

上の図に示すように、ジョブ ストリームは、ジョブ START の 2 つの異なる成功リターン コードを管理するために分岐しています。

ジョブ START には、「ゼロ」と「4」というラベルが付けられた 2 つの異なる成功出力条件があり、ジョブ CHILD_0 と CHILD_4 は、それぞれの出力条件に基づく条件付き依存関係でジョブ START に依存しています。

この例では、START の終了コードは 4 で、条件「4」が true ですが、条件「zero」が false であるため、ジョブ CHILD_0 が抑制され、ジョブ CHILD_4 が実行されます。

処理要件をより複雑にしてみましょう。ジョブ ログの内容、データベース クエリの結果、または RESTful ジョブの応答として受信した JSON の特定の値 (ジョブにマップされたステータスではなく) に基づいてワークフローを分岐するなどです。 ジョブ) は別のシナリオで説明します。

使用例 3: 変数の内容による分岐

この例では、ジョブ ステータスに影響を与えない条件 (「その他の出力条件」フィールド) がジョブ MESSAGE に対して作成され、変数 ${this. を使用してジョブ ログ内の文字列「KO」または「OK」の存在を評価します。 stdlist}で処理を分岐します。 後続ジョブには「実行時の変数解決」フラグが設定されている必要があることに注意してください。

ジョブ ログ変数の使用に代わる可能な方法としては、サービスによって応答として受信された JSON ファイル、または、 RESTful ジョブ定義の詳細セクション。 別の例として、データベース ジョブ タイプの SQL クエリ内の列ラベルにちなんで名付けられた変数を使用できます。

ここで、2 つの異なるブランチでは要件を満たさないが、次の使用例のように複数のブランチを実装する必要があると想像してください。

使用例 4: 複数の分岐

親ジョブのジョブ ステータスに影響を与えない 7 つの異なる出力条件を作成し、複数の分岐フローを実装するために、出力条件ごとに 1 つずつ、7 つの異なる条件依存関係を設定しました。

次に、ジョブ ストリーム内でフローを分岐する方法を学びました。 よくある質問: 支店に参加することは可能ですか? はい、次の使用例で説明するとおりです。

使用例 5: ブランチの結合

この図の下部にあるジョブは、特別な依存関係の種類である結合依存関係に依存しています。 結合依存関係に 1 つ以上のジョブを追加し、解決基準を「すべて正常に完了」または「1 つが正常に完了」、または一般的には希望する数のジョブの一部に設定できます。

ブランチが相互に排他的である場合、または図のように 7 つのうち 1 つを指定した場合、1 つのブランチのみが正常に完了して最後のジョブを解放するだけで十分です (他のブランチは抑制されます)。

ジョブ ストリームの論理分岐への取り組みは終わりに近づいていますが、終了する前に次のことを覚えておいてください。各ブランチに複数のジョブのシーケンスを追加する必要がある場合は、条件付き依存関係を有効にして親子ジョブを連結する必要があります。 親ジョブの SUCC 状態によって異なります。

このトリックが本当に必要なのは、追跡されていないブランチ内のチェーンの最初のジョブが抑制され、従来の依存関係定義のデフォルトの動作が子ジョブを実行のために解放することであるためです。 次に、チェーンの 2 番目のステップが実行を開始しますが、望ましい結果はブランチ パイプライン全体が抑制されることです。

親ジョブが SUCC 状態にある場合にのみ依存関係を強制的に解放すると、必要に応じてブランチ内のジョブがカスケード抑制されます。

条件付きロジックの設計を楽しんでください。

HCL Workload Automation の詳細については、こちらをご覧ください。