ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Azure Logic Apps
Azure Logic Appsのワークフローは、ワークフロートリガーが呼び出される前に始まり、上流で何かが壊れると失敗する可能性があります。Azure Blob Storageオブジェクトが届かない。Azure Data Factoryパイプラインが夜間の完了ウィンドウを逃してしまいます。Control-Mは、Azure Blob Storageの到着、Azure Data Factoryの処理、Azure Logic Appsの実行、そして下流への配信を調整します。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。複数のツールでAzure Logic Appsワークフローを実行しているチームの通常の操作条件です。Control-Mがそれぞれをどのように処理するかを見てみましょう。
上流依存関係
Blobが到着しませんでした。Logic Appsのワークフローを開始してはいけません。
Control-Mは、必要な上流条件の背後にAzure Logic Appsジョブを保持し、前のワークロードが成功裏に完了するまでリリースしないことで、不完全な入力がエンタープライズワークフロー全体に波及するのを防ぎます。
スケジュール依存関係
Data Factoryは午前1時に失敗しました。Logic Appsは現在待機しています。
Control-MはAzure Data FactoryジョブとAzure Logic Appsワークフローを同じジョブフローで追跡し、それらの依存関係を評価し、前提条件が完了した後にLogic Appsジョブを開始します。切り離されたスケジュールに依存するのではなく、
一時的なAPI障害
AzureはHTTP429を返します。一時的な制限がワークフローを脅かしています。
Control-Mは、HTTPレスポンスコード429または503が発生した場合に、定義された再実行間隔と試行回数を使用して、一時的な障害から回復するためにAzure Logic Appsの実行ステップを再実行できます。オペレーターの介入なしで。
失敗回復
ワークフローは実行中に失敗します。オペレーションはすべてを再起動すべきではありません。
Control-MはAzure Logic Appsジョブの状態を監視し、再実行可能な失敗したジョブを再実行する際に失敗したポイントから再起動をサポートします。これにより、不必要な再処理が減少し、オペレーションがより迅速にビジネスワークフローを復元できるようになります。
SLAリスク
Logic Appsは成功しましたが、ビジネスサービスはすでに遅れています。
Control-MはAzure Logic Appsジョブをエンドツーエンドのサービスフロー内に配置し、依存ジョブ全体にわたってSLA監視を適用します。これにより、オペレーションは1つのワークフロージョブを超えた可視性を得て、チームが配信リスクを早期に特定し対処できるようになります。
Control-M + Azure Logic Apps
Control-M + Azure Logic Apps
|
プラットフォームとOSのカバレッジ |
Azure Logic Apps Consumption · Azure Logic Apps Standard · Microsoft Azure · Control-M Agent on Linux · Control-M Agent on Windows |
|
サポートされているジョブタイプ |
Logic Appsワークフローの実行 · Consumptionワークフロー · Standardワークフロー（Control-M SaaSおよび9.0.22+） · パラメータ化されたワークフローの実行 · ワークフローステータスの追跡 · 実行ログ · 再実行時の再起動 |
|
SLA監視とアラート |
SLAジョブの添付 · エンドツーエンドのSLA追跡 · 予測SLAの可視性 · ワークフローステータスの監視 · Control-Mアラート · サービスレベルの監視 |
|
監査証跡とアクセス制御 |
セキュア接続プロファイル · Azure Service Principal · マネージドアイデンティティ · 中央集権的な資格情報管理 · Control-Mの役割ベースのアクセス · 実行履歴 · ジョブ出力 |
エンドツーエンドオーケストレーション
1つの生産ワークフロー。スタック内のすべてのツール。
Control-Mは、Azure Logic Apps、Azure Data Factory、Azure Blob Storage、Azure Functions、Azure Service Bus、およびエンタープライズアプリケーション間でワークフローを調整し、依存関係の追跡、SLAの可視性、自動回復を行います。
- クロスツール依存関係: Azure Blob Storage → Azure Data Factory → Azure Logic Apps → エンタープライズアプリケーション
- データ認識トリガー: ファイル到着、APIイベント、上流のジョブ完了、メッセージ処理の引き渡し
|
Azure Logic Apps |
StandardおよびConsumptionワークフローを実行 · JSONパラメータを渡す · ステータスを監視 · 出力を取得 · 再実行を管理 |
|
Azure Data Factory |
パイプラインを実行 · 依存関係を調整 · 完了を監視 · パイプラインステージを接続 |
|
Kubernetes |
パイプラインを実行 · 依存関係を調整 · 完了を監視 · パイプラインステージを接続 |
|
Azure Blob Storage |
ファイル到着を調整 · 下流処理をゲート · ファイル駆動型ワークフローを接続 |
|
Azure Functions |
関数を実行 · 依存関係を調整 · ジョブフローにサーバーレス処理を含める |
|
Azure Service Bus |
メッセージングワークロードを調整 · イベント駆動型およびスケジュール処理を接続 |
|
エンタープライズアプリケーション |
下流処理の順序を付け · 依存関係を強制 · エンドツーエンドのサービス提供を追跡 |
ワークフローを監視する
広範なワークフロー内でAzure Logic Appsを監視する。
Azure Logic Appsは独自のワークフローの実行履歴を提供しますが、運用チームは各実行の前後に何が起こったかを理解する必要があります。Control-MはLogic Appsの実行を依存するエンタープライズワークロードと同じ運用ビューに統合します：
-
Logic Appsジョブのステータス
-
ワークフローの結果と出力
-
クロスプラットフォームの依存関係の可視性
-
エンドツーエンドの実行監視
-
中央集権的な運用ジョブビュー
SLA保証
Logic Appsの実行を超えてSLAを管理する。
成功したLogic Appsの実行は、ビジネスサービスが時間通りに完了したことを保証しません。Control-Mはその実行を上流および下流の依存関係に接続し、完全な生産ワークフロー全体にわたってサービスレベルの監視を適用します：
-
エンドツーエンドのSLA追跡
-
予測的SLAリスクの可視性
-
クロスワークフローの依存関係の監視
-
自動的な障害処理
-
中央集権的な運用監視
複雑なワークフローに秩序をもたらす
Control-Mがチームに視認性、調整、制御を強化して複雑なプロセスをオーケストレーションする方法を学ぶ。
