ポイント: SAP BTPジョブスケジューリングサービスは、SAPビジネステクノロジープラットフォーム上でジョブスケジューリングを自動化することを可能にし、孤立したアプリケーション内の時間ベースのタスクに最適です。複雑なプロセスやシステム間の依存関係には制限があります。
- 単純な孤立したBTPタスクに最適
- オーケストレーションが必要な大きなワークフローの一部になると限界を迎える
BTPジョブスケジューリングサービスとは
SAP BTPジョブスケジューリングサービスは、SAPビジネステクノロジープラットフォーム（BTP）に組み込まれたジョブスケジューラです。これにより、BTPにデプロイされたアプリケーションやサービスに対して、ジョブ（単発または定期）を定義して実行できます。ジョブはHTTP経由でアプリケーションアクションエンドポイントをトリガーしたり、ダッシュボードを通じてまたはプログラム的に表現状態遷移（REST）アプリケーションプログラミングインターフェース（API）を通じて長時間実行される作業のためのCloud Foundryタスクを起動したりできます。ジョブはcronスタイルおよび人間が読める再発パターンでスケジュールされます。このサービスはCloud Foundry環境とKymaランタイムの両方で実行され、OAuth 2.0で保護された実行とマルチテナントアプリケーションをサポートし、成功または失敗のイベントをSAPアラート通知サービスに送信できます。
このサービスは、SAPの他の自動化レイヤーの中でも位置づける価値があります。SAPビルドプロセス自動化は、BTP上でのワークフローおよびロボティックプロセス自動化を扱い、SAP S/4HANAはそのネイティブフレームワークを通じて自らのアプリケーションバックグラウンドジョブをスケジュールします。これらすべて、BTPジョブスケジューリングサービスを含め、各自の環境内でうまく自動化されますが、依存関係、タイムライン、または環境を超えた監視を調整することはできません。その境界はこの記事の後半で重要になります。
BTP上で構築しているチームにとって、このサービスは基本をうまく処理します: スケジュールに基づいてアプリケーションロジックをトリガーし、非同期実行をサポートし、ジョブごとの実行ログを記録し、追加のインフラストラクチャを必要としないため、ネイティブプラットフォームサービスです。クリーンコアの景観を構築している場合（カスタムロジックがS/4HANAコアからBTPに移動する）、ジョブスケジューリングサービスは「この拡張をスケジュールで実行するにはどうすればよいか？」という質問に対するデフォルトの回答です。
これは本当に役立つ機能であり、多くのワークロードにはそれだけで十分です。
うまくフィットする場所
このサービスは、次の3つの条件が真であるときに強くフィットします。
まず、作業は完全にBTP上に存在します: ジョブはBTPにデプロイされたアプリケーションまたはCloud Foundryタスクをトリガーし、その単一ユニットの成功または失敗が全体の話です。
第二に、スケジューリングのニーズは時間ベースです: 毎日午前2時に実行、15分ごとに実行、月の最終日に実行。
第三に、結果を消費するチームはジョブを所有するチームです: ジョブが定義されている同じダッシュボードでログをチェックする開発者またはアプリケーションオーナーです。
単一アプリケーションスケジューリング、単純な再発、およびBTP居住ワークロード: その境界内で、外部スケジューラを追加することはオーバーヘッドであり、価値ではありません。
チームがそれを超える場所
制限は、スケジュールされたジョブが孤立したタスクでなくなり、ビジネスプロセスの一部になるときに現れます。その時点で、質問は「このジョブは実行されましたか？」から「全体のプロセスが正しく、時間通りに、回復および監査するのに十分な可視性を持って完了しましたか？」に変わります。5つのパターンが繰り返し現れます。
システム間の依存関係
BTPジョブは孤立して存在することはめったにありません。その実行される拡張は、S/4HANAコアでバッチジョブが完了することに依存しており、それがデータウェアハウスにロードを供給し、銀行やキャリアへのファイル転送を行います。BTPジョブスケジューリングサービスは、時間によってスケジュールされますが、依存関係によってはスケジュールされません。上流のSAPジョブが完了したかどうか、または下流の非SAPステップが開始する準備ができているかどうかを把握することはできません。チームはしばしば、開始時間を緩衝時間でパディングすることでそれを補いますが、これは壊れやすいです: 上流のジョブが長くかかると、下流のジョブは不完全なデータに対して実行される可能性があります。
サービスレベル予測
このサービスは、ジョブが実行されたかどうか、失敗したかどうかを伝え、いずれかの結果を通知できます。しかし、現在のペースで依存する作業のチェーンがビジネスが必要とする午前8時までに完了しないことを事前に警告することはできません。複数のジョブにまたがるプロセスに関連付けられたサービスレベル契約（SLA）の締切の概念はなく、そのプロセスが遅れている傾向があるときの早期警告もありません。
失敗からの再起動セマンティクス
マルチステッププロセスが途中で失敗した場合、復旧の質問はすべてを再実行するかどうかではありません。プロセスがどこで失敗したか、完了したステップはどれが信頼できるか、作業を重複させたり、下流のデータを破損したりせずに再開する方法はどれかです。時間ベースのスケジューラには、エンドツーエンドのプロセスのモデルがないため、プロセスのどこで失敗が発生したかを把握することはできません。
生成されたジョブの認識
SAPのバックグラウンド処理は頻繁に子ジョブを生成します。親ジョブが成功を報告しても、その子ジョブがまだ実行中または失敗している可能性があります。親の状態を全体の真実として扱うオーケストレーションは、下流の作業を早期に放出することになります。
中央集権的な監査とガバナンス
ジョブログは、ジョブごとに、サブアカウントごとにBTPコックピットに存在します。システム間の障害をトラブルシューティングするには、別々のコンソールで実行ログを比較し、手作業で依存関係を追跡する必要があります。そして監査人が誰が何を、いつ、どのような結果で実行したかを尋ねると、S/4HANAコア、BTP拡張、およびその間の非SAPシステムのすべてを通じて、答えられる単一の場所は存在しません。
これらはどれも欠陥ではありません。プラットフォームスコープのスケジューラが企業スコープのオーケストレーションを求められる自然な境界です。
Control-Mが置き換えるのではなく関連する方法
Control-MはBTPジョブスケジューリングサービスを置き換えません;それはサービスが実行するジョブをオーケストレートします。ネイティブBTP統合を通じて、Control-MはBTP APIを介してBTPスケジューラージョブを作成、トリガー、および監視します。これらのジョブは、SAPの認定されたバックグラウンド処理用外部インターフェイス（XBP）を介して実行されるS/4HANAジョブや、データロード、ファイル転送、クラウドサービス呼び出しを含む接続された非SAPプロセスとともに、すべて単一のワークフローでオーケストレートできます。（Control-MはSAP認定を受けており、SAPストアに掲載されています;コア統合はSAP自体の認定インターフェイスを介して実行されます。）
これは特にクリーンコアにとって重要です: カスタムロジックがコアからBTPに移動すると、プロセスは単純化されるわけではなく、より分散されます。Control-MはBTPジョブをコアと並行してオーケストレートし、コアとBTPの両方にまたがるビジネスプロセスが一つの可視でガバナンスされたフローのままであるようにします。
統合は双方向です。RESTおよびWebhookトリガーにより、Control-MはSAPジョブの完了にほぼリアルタイムで反応します。下流のステップは、上流のジョブが完了した瞬間に開始され、ポーリング間隔が発生するのを待つのではなく、開始されます。これは、イベント駆動型オーケストレーションとバッファ時間スケジューリングの具体的な違いを示しています。また、生成されたジョブの問題にも直接対処します: SAPコア側でControl-Mは親-子ジョブツリー全体を検出し監視し、すべての前任者が完了したときのみ後続者を開始します - 時間ベースの依存関係がチームに強いる手動バッファ時間のパディングを排除します。
結果: BTPジョブスケジューリングサービスをその得意なことに引き続き使用し、システム間の依存関係、SLA管理、再起動セマンティクス、および中央集権的な監査トレイルを得ることができます。
SAPおよびパブリッククラウドと共に成長
GROW with SAPでは、S/4HANAのパブリッククラウドエディションでは、スケジューリングサーフェスが変更されます。コアへの古典的なXBP経路がないためです。代わりに、BTPスケジューラとSAPの外部スケジューラAPI、通信シナリオSAP_COM_0948がスケジューリングインターフェースになります。Control-Mは、その外部スケジューラAPIを使用してOData/RESTコネクタを介してパブリッククラウド環境に接続し、OAuth 2.0およびトランスポート層セキュリティ（TLS）で保護されます。結果は、妥協が必要ないAPIベースのオーケストレーションモデルであり、同じオーケストレーションレイヤーがオンプレミス、RISE、GROWデプロイメントにまで拡張され、各々に異なるアプローチが必要ありません。
スケジューリングがオーケストレーションになるタイミングを決定する方法
問題は、どのツールが優れているかではありません。特定のジョブがどこに位置するかです。
BTPローカルで、時計に基づいて実行され、アプリケーションを所有するチームに応じるジョブにはBTPジョブスケジューリングサービスを使用します。ジョブがそれ自身を超える重みを持ち始めると、企業オーケストレーションに移行します: 上流ステップを待たなければならない、下流システムに作業を放出しなければならない、誰かが締切を保持している、再開しなければならない回復パス、または他のすべてとともに考慮される監査トレイルを持たなければなりません。
ほとんどの景観はその線の一方に留まりません。ほとんどは最初の側から始まり、拡張が増えるにつれて2番目の側に到達します。役に立つ演習は一度選択することではありません。今日、各ジョブがどちらの側にあるのかを知ることです。
よくある質問
SAPのBTPジョブスケジューリングサービスは十分ですか、それとも私たちはそれを超えますか？
SAP BTPジョブスケジューリングサービスは、ジョブが完全にBTP内で実行され、時間ベースのスケジュールのみに依存し、所有するチームによって個別に監視できるときに十分です。組織は通常、スケジュールされたジョブがより大きなビジネスプロセスのステップになるときにそれを超えます。BTPジョブがS/4HANAコアジョブの完了に依存し、非SAPシステムにフィードを供給し、ビジネスの締切を運び、または他のジョブ群とともに監査可能でなければならない場合です。この時点で、スケジューリングからオーケストレーションへのニーズがシフトします: システム間の依存関係、SLA予測、失敗からの再起動、および中央集権的な監査トレイル。Control-Mは、BTP APIを介してBTPスケジューラージョブをオーケストレートすることで、これを解決します。SAPコアジョブや非SAPワークロードと同じ依存関係グラフ内で、プラットフォームスケジューラはその役割を維持しながら、エンドツーエンドプロセスに可視性と制御をもたらします。
Control-MはSAP BTPジョブスケジューリングサービスを置き換えますか？
いいえ。Control-MはBTPジョブスケジューリングサービスを置き換えません;それはサービスが実行するジョブをオーケストレートします。BTPスケジューラはBTPローカルジョブをトリガーする責任を持ち続けます。Control-Mが追加するのは、その周囲のコンテキストです: BTPジョブはS/4HANAコアジョブを待つことができ、下流の非SAP作業を終了した瞬間に放出し、SLA締切にカウントされ、中央の監査トレイルに表示されますが、それはBTP内で内部のものを変更することなく行えます。
Control-MはクリーンコアおよびBTP拡張にどのように役立ちますか？
クリーンコアはカスタムロジックをS/4HANAコアからBTPに移動させます。それは正しいアーキテクチャの方向ですが、ビジネスプロセスを簡素化するわけではなく、より分散化します。Control-Mは、SAPコアジョブとその周囲の非SAPステップと並行してBTPスケジューラージョブをオーケストレートし、プロセスがエンドツーエンドで可視的、依存関係を意識し、ガバナンスを維持します。拡張はコアからきれいにデカップリングされ、両方を通過するフローは、見ることができ、管理することができる一つのもののままです。
次のステップ
自分のBTPジョブがより大きなビジネスプロセス内のどこに位置するかをマッピングしている場合、始めるべき場所は、BTPスケジューラージョブが実際にシステム間依存関係グラフにどのように参加するかを見ることです。Control-M for SAPやControl-Mデモライブラリにアクセスしてみてください。
これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。