まず結論です。SAP Integration Suite は「システムをつなぐための道具」としてだけ見ると、かなりもったいないサービスです。もちろん、API Management、Cloud Integration、Event Mesh などを使って連携を作ることはできます。しかし企業システムで本当に面倒なのは、最初の接続よりも、その接続を長く安全に運用し続けることです。
この記事では、SAP BTP 上の Integration Suite を、単なるインターフェース実装ではなく、API ライフサイクル、イベント連携、監視、認証、監査をまとめて扱うガバナンス基盤として整理します。
この記事で扱うこと
対象読者は、SAP S/4HANA、周辺 SaaS、オンプレミスシステム、クラウドサービスを連携させる立場の人です。開発者だけでなく、アーキテクト、BTP 管理者、情シス側のプラットフォーム担当にも関係します。
この記事で見るポイントは次の 4 つです。
| 観点 | よくある見方 | 実際に重要なこと |
|---|---|---|
| 接続 | API を呼べるか | 誰が、どの条件で、どの責任で呼べるか |
| 実装 | フローを作れるか | 変更・再利用・障害対応に耐えられるか |
| 運用 | エラーが見えるか | 監視、再処理、監査の流れが決まっているか |
| 統制 | 連携を増やせるか | 野良 API と属人化を防げるか |
「つながったので完了」という考え方は、最初のデモでは通用します。運用に入ると、だいたいそこで事故ります。
Integration Suite は何をまとめているのか
SAP Integration Suite は、単一の機能名ではありません。複数の連携機能をまとめたスイートです。代表的には次のような要素があります。
- Cloud Integration: システム間のメッセージ変換、ルーティング、連携フロー
- API Management: API の公開、保護、ポリシー適用、利用管理
- Event Mesh: イベント駆動連携のためのメッセージング
- Open Connectors: 外部 SaaS とのコネクタ活用
- Trading Partner Management: B2B 連携の管理
- Integration Advisor: マッピングや B2B メッセージ設計の支援
もちろん全部を一度に使う必要はありません。ただし重要なのは、これらが「接続手段の寄せ集め」ではなく、連携を管理可能な形にするための部品だという点です。
たとえば S/4HANA の受注データを外部の物流システムへ送るだけなら、技術的には HTTP API、ファイル連携、メッセージキューなど、いくつも方法があります。しかし実務では次の問いがすぐに出ます。
- API の利用者をどう認証するのか
- 失敗したメッセージを誰が再処理するのか
- 項目変更があったとき影響範囲をどう追うのか
- 外部パートナーごとの仕様差分をどこに閉じ込めるのか
- 監査時に、いつ誰が何を送ったか説明できるのか
このあたりを放置した連携は、動いているように見えても運用負債です。
「API を公開する」と「API を管理する」は違う
API Management の価値は、エンドポイントを外に出すことだけではありません。むしろ重要なのは、API を管理対象として扱えるようにすることです。
最低限、次のような論点があります。
| 論点 | 見るべきこと |
|---|---|
| 認証・認可 | OAuth、JWT、API key、Principal Propagation などをどう使うか |
| 利用制御 | レート制限、クォータ、IP 制限、呼び出し元制御 |
| バージョン管理 | v1/v2 の共存、廃止ポリシー、利用者への移行通知 |
| 可観測性 | 呼び出し回数、エラー率、レスポンス時間、利用者別の傾向 |
| セキュリティ | 不要な項目露出、過剰権限、内部 API の外部公開防止 |
API は一度公開すると、勝手に消せません。利用者が増えるほど、変更の自由度は下がります。だから最初から「誰に、どの契約で、どの保証範囲で使わせるのか」を決めておく必要があります。
ここを考えずに Integration Suite を使うと、ただの便利な中継サーバーになります。残念ながら、それは BTP を使っているのに治理できていない状態です。
Cloud Integration はフロー作成ツールで終わらせない
Cloud Integration では、iFlow を使って連携ロジックを作れます。メッセージ変換、条件分岐、例外処理、外部サービス呼び出しなど、実装面ではかなり柔軟です。
ただし、ここでよくある失敗は「動く iFlow」を大量生産することです。動くものを作るだけなら早い。しかし、次の半年で地獄を見る可能性があります。
たとえば次のような状態です。
- 似たようなマッピングが複数の iFlow に散らばる
- エラー処理の方針がフローごとに違う
- 命名規則がなく、何の連携か分からない
- 接続先の認証情報が場当たり的に管理される
- テスト環境と本番環境の差分が説明できない
Integration Suite を治理基盤として使うなら、iFlow はコード資産に近いものとして扱うべきです。命名、責任範囲、再利用部品、エラーハンドリング、リリース手順を決める。地味ですが、ここをやらないと連携基盤はすぐ汚れます。
イベント連携は「リアルタイムっぽい」だけでは足りない
Event Mesh を使うと、イベント駆動の連携を組みやすくなります。S/4HANA 側で業務イベントが発生し、それを購読側システムが処理する、という形です。
これは疎結合化に効きます。送信側が受信側の都合を細かく知らなくてもよくなり、複数の購読者へ展開しやすくなります。
ただし、イベント連携にも治理が必要です。
- イベント名の命名規則
- ペイロードのスキーマ管理
- 冪等性の設計
- 重複配信や遅延への対処
- 失敗時の再処理とデッドレター処理
- 購読者が増えたときの影響範囲管理
たとえば「BusinessPartnerChanged」というイベントを出すとしても、何が変わったのか、どの粒度で通知するのか、過去互換性をどう保つのかを決めないと、購読側はすぐ壊れます。
イベント駆動は魔法ではありません。同期 API の密結合を、名前のついていない非同期地獄に変えるだけなら、むしろ悪化です。
監視と監査を後付けにしない
連携は失敗します。ネットワーク、認証、データ不整合、外部 API の仕様変更、タイムアウト。理由はいくらでもあります。
だから設計段階で、少なくとも次を決める必要があります。
| 項目 | 決めること |
|---|---|
| 検知 | どのエラーを誰に通知するか |
| 再処理 | 自動再試行するか、人手で確認するか |
| 保管 | メッセージやログをどこまで残すか |
| 監査 | 誰がいつ何を連携したか説明できるか |
| 責任 | SAP 側、外部システム側、基盤側の境界 |
Integration Suite には監視やログ確認の仕組みがありますが、ツールがあるだけでは運用になりません。通知先、一次対応、再実行ルール、データ修正の権限まで決めて、初めて運用です。
「エラーが出たら見ればいい」は、だいたい誰も見ません。現場あるあるですが、笑えません。
BTP 全���の治理とつなげて考える
Integration Suite は、BTP の中で単独に存在するわけではありません。認証は Identity Authentication や Identity Provisioning、権限管理、場合によっては Principal Propagation と関係します。拡張アプリは CAP、Kyma、ABAP Cloud などと連携することもあります。監査や運用設計は、企業全体のセキュリティ標準ともつながります。
つまり Integration Suite の設計は、BTP 全体のプラットフォーム設計から切り離せません。
たとえば次のような決め事が必要です。
- どの API を社内標準 API として扱うか
- 誰が API のオーナーになるか
- 接続先ごとの認証情報をどう管理するか
- サブアカウント、スペース、環境分離をどう設計するか
- 本番変更の承認フローをどうするか
- 監査ログをどの期間保持するか
これらを決めずに各プロジェクトが自由に連携を作ると、短期的には速く見えます。しかし数年後には、誰も全体像を把握できない連携ジャングルになります。森ではありません。ジャングルです。しかも毒があります。
実務で最初に決めるべきチェックリスト
Integration Suite を本気で使うなら、最初に次を決めておくと失敗しにくいです。
| チェック | 内容 |
|---|---|
| API オーナー | API の仕様変更と廃止判断の責任者 |
| 命名規則 | API、iFlow、イベント、トピック、パッケージの名前 |
| 認証方式 | OAuth、証明書、Principal Propagation などの標準方針 |
| エラー処理 | 再試行、通知、手動介入、デッドレターの扱い |
| ログ保持 | 監査・障害調査に必要な保持期間 |
| バージョン管理 | 互換性、移行期間、破壊的変更の扱い |
| 環境分離 | 開発、検証、本番の差分管理 |
| 再利用方針 | 共通マッピング、共通接続、標準テンプレート |
この表の半分も決まっていないなら、まだ「統合基盤」ではなく「連携作業場」です。便利ですが、治理とは呼びにくい。
まとめ
Integration Suite の本質は、SAP と外部システムを接続することだけではありません。API、イベント、メッセージ変換、認証、監視、監査を、企業として管理できる形に近づけることです。
要点をまとめます。
- Integration Suite は単なる接続ツールではなく、連携治理の基盤になり得る
- API Management は公開よりも、認証、制御、バージョン、利用状況の管理が重要
- Cloud Integration は iFlow を量産する場所ではなく、運用可能な連携資産を作る場所
- Event Mesh は疎結合化に効くが、スキーマ、冪等性、再処理設計が必要
- 監視と監査は後付けではなく、最初から設計するべき
まずやるべきことは、機能一覧を眺めることではありません。自社の連携を、誰が所有し、どう変更し、どう失敗から復旧し、どう監査に耐えさせるのかを決めることです。
Integration Suite は、そのための道具です。道具を買っただけで治理が生えるわけではありません。そこを間違えると、また高級な配線置き場が増えるだけです。