Control-M + コミュニケーションスイート

あなたのコミュニケーションスイートのワークフローは、メッセージのWebhookが呼び出される前に始まり、上流で何かが壊れると失敗する可能性があります。SAPビジネスプロセスが期待した出力なしに終了します。Salesforceバッチが顧客通知ウィンドウの後に完了します。Control-Mは、上流のアプリケーション処理、ビジネスルールの実行、コミュニケーションスイートメッセージ、および下流のビジネスデリバリーの完全なチェーンをオーケストレーションします。

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

共通のワークフローの問題

今週はこんな感じですか？

これはエッジケースではありません。これらは、複数のツールでコミュニケーションスイートメッセージングワークフローを運営しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかを示します。

早すぎる通知

Teams が完了を発表しました。ビジネスプロセスはまだ実行中でした。

Control-M は、Teams メッセージを送信する前に、コミュニケーションスイートのジョブを成功した上流の完了に依存させます。複雑な依存関係とスケジューリング基準により、ビジネスユーザーは重要なプロセスが実際に完了する前に成功通知を受け取ることができません。

メッセージの失敗

メッセージは決して送信されませんでした。誰も引き渡しが欠けていることを知りませんでした。

Control-M は、メッセージを生成したワークフローとともに、コミュニケーションスイートジョブの状態、結果、および出力を監視します。失敗した通信は、同じスケジューリング環境内で可視のままとなり、チームはビジネスの引き渡しを失うことなくジョブを調査し再実行できます。

ビジネスの締切

プロセスが完了しました。顧客通知は締切を逃しました。

Control-Mは、コミュニケーションスイートのジョブにSLA管理を追加し、ビジネスサービスの一部としてメッセージングを追跡できます。チームは、重要な通知の期限が顧客またはビジネスの問題になる前に、広範なワークフロー内での潜在的な遅延を確認できます。

チャネルの複雑さ

Teams、Slack、Telegram、およびWhatsAppは、それぞれ異なるメッセージ処理が必要です。

コミュニケーションスイートは、プラットフォーム固有のパラメータを保持しながら、サポートされているメッセージングプラットフォームを1つのControl-Mジョブタイプに統合します。チームは、切り離されたスケジューリングロジックを維持するのではなく、同じワークフロー環境からMicrosoft Teams、Slack、Telegram、およびWhatsAppのメッセージングをオーケストレーションできます。

コンテキストの喪失

アラートが到着しました。誰もどのビジネス実行がそれを引き起こしたのかを特定できませんでした。

Control-M変数は、ワークフローコンテキストをコミュニケーションスイートのメッセージに持ち込み、通知を生成したプロセスに接続します。ビジネスおよびアプリケーションのオーナーは、孤立したアラートではなく、ワークフロー実行に関連付けられたアクション可能なメッセージングを受け取ります。

統合事実