Control-M + Microsoft Power BI SP

あなたのPower BIワークフローは、セマンティックモデルのリフレッシュが実行される前から始まります。上流で何かが壊れると失敗する可能性があります。Azure Data Factoryパイプラインが期待されたデータロードを見逃す。Azure Databricksジョブがレポートウィンドウ後に終了します。Control-Mは、ソースデータの到着、上流の変換、Power BIのリフレッシュ、下流のレポート配信という完全なチェーンをオーケストレーションします。

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

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

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

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

遅延ソースデータ

あなたの午前7時の更新が開始されました。Databricksの変換はまだ実行中です。

Control-MはDatabricksジョブとPower BIの更新を1つのワークフロー内の依存関係としてモデル化し、更新は必要な上流作業が完了するまで待機し、準備が整っていないデータに対して開始されることはありません。

更新失敗

Power BIはHTTP 429を返しました。あなたの朝のダッシュボードは今危険にさらされています。

Control-Mは設定されたHTTP応答コードを検出でき、429を含む、定義された試行と間隔設定を使用して実行ステップを再実行します。ワークフローは、ビジネスユーザーに失敗を発見して再起動させるのに依存するのではなく、制御された回復を得ます。

SLAリスク

リフレッシュが長引いています。経営陣は午前8時前にダッシュボードを期待しています。

Control-MはPower BI SPジョブをより広いワークフローSLAに添付し、運用が依存する処理が時間通りに完了するかどうかを可視化し、遅延した更新がビジネス報告の約束を逃す前に介入を可能にします。

デプロイメント調整

開発は準備ができています。プロダクションはまだ最新のPower BIデプロイメントが必要です。

Control-Mは、周囲のアプリケーションやデータジョブと同じスケジューリング環境内でPower BIパイプラインデプロイメントジョブを実行し、プロダクションプロモーションを広範なリリースワークフローから孤立させるのではなく、上流および下流の依存関係と調整しながらワークスペースデプロイメントを行います。

失敗の可視性

リフレッシュが overnight 失敗しました。ビジネスは古いダッシュボードからそれを発見します。

Control-Mは、他のジョブとともにPower BI SPジョブのステータス、結果、出力を監視します。チームは、報告書の消費者が古い情報をフラグするのを待つのではなく、オペレーショナルコンテキスト内で失敗した実行を特定できます。

統合の事実