Control-M + OCI Functions

OCI Functions ワークフローは、サーバーレス関数が実行される前に始まり、上流で何かが壊れると失敗する可能性があります。OCI オブジェクトストレージのオブジェクト作成イベントが届かない。OCI データ統合タスクは予想されるウィンドウを過ぎて完了します。Control-M は、オブジェクトストレージの到着、OCI データ統合の変換、OCI Functions の実行、下流の配信という完全なチェーンを調整します。

あなたのようなパイプラインで見る統合事実を見る

一般的なワークフローの問題

これはあなたの週のように聞こえますか？

これらはエッジケースではありません。これらは、複数のツールでOCI Functionsワークフローを実行しているチームにとっての通常の運用条件です。Control-Mがそれぞれをどのように処理するかを以下に示します。

上流の失敗

あなたのオブジェクトストレージオブジェクトはまだ到着していません。関数にはまだ期限があります。

Control-Mは上流の依存関係の背後にある関数をモデル化し、実行は必要なワークフロー条件が整うまで待機し、孤立したクロックに依存しません。失敗したり遅れた上流の作業は可視性を保ち、不適切な実行を防ぎ、下流のワークフローを保護します。

関数の失敗

関数の呼び出しに失敗しました。すべての下流が今待機しています。

Control-MはOCI Functionsのジョブステータス、結果、および出力を監視し、集中型のワークフロー障害処理を適用します。下流のジョブは、失敗した呼び出しの後に進むのではなく、依存関係によって管理され、失敗がプロダクションフローに広がる前に抑えられます。

ペイロードのドリフト

昨日のペイロードは正常に動作しました。今日のランタイムパラメータはそれに基づいて変更されました。

Control-MはOCI FunctionsのペイロードパラメータをJSONで定義し、Control-Mの変数をペイロードに解決できます。チームは変更されるプロダクション入力に対して別々のハードコーディングされた呼び出しスクリプトを維持する代わりに、ワークフローコンテキストから各呼び出しをパラメータ化できます。

SLAリスク

関数は02:14に成功しました。ビジネスワークフローは依然として遅れています。

成功した関数の呼び出しは、エンドツーエンドのサービスが時間通りであることを証明するものではありません。Control-MはOCI FunctionsジョブにSLA管理を追加し、より広範なワークフロー内でそれらを追跡し、関数の完了をフィニッシュラインとして扱うのではなく、依存関係にわたる締切リスクを明らかにします。

ツールチェーンの断片化

OCIはクリーンに終了しました。次の非OCIジョブは開始されませんでした。

Control-MはOCI Functionsジョブを他のControl-Mジョブと統合し、1つのスケジューリング環境で実行します。クロスプラットフォームの依存関係は、下流作業がいつ進行できるかを決定し、切り離されたスケジュールや手作業での調整を、クラウドとエンタープライズシステム全体にわたる1つのプロダクションワークフローに置き換えます。

統合事実