SAP Integration Suite入門｜Cloud Integration・API Management・Event Meshで実現するシステム連携

はじめに：なぜ今、統合基盤が必要なのか

SAP S/4HANAを中心とした業務システムは、もはや単独で完結しません。CRMはSalesforce、人事はSuccessFactors、ECはShopify、物流は3PL、決済は外部ゲートウェイ──といった具合に、企業の業務はクラウドサービスの組み合わせで成り立っています。ここで問題になるのが「誰がシステム間をつなぐのか」という統合の課題です。

なぜ統合基盤が必要なのか（why so）。それは、各システムを個別にポイント・トゥ・ポイントでつなぐと、接続数が爆発的に増え、変更の影響範囲が読めなくなるからです。10システムを相互接続すると最大45本の接続が必要になり、片方のAPI仕様が変わるだけで複数の連携が壊れます。さらに、SAPが推進するClean Core戦略では「S/4HANAの標準を汚さず、拡張は外側で実装する」ことが求められるため、外側でつなぐための統合層がますます重要になります。

ではどうすべきか（so what）。すべての連携を1つの統合ハブに集約し、再利用可能なAPIとイベントとして外部に公開するのが現代的な答えです。SAPがその答えとして提供しているのが、SAP BTP上で動くSAP Integration Suiteです。本記事では、その全体像と主要コンポーネント、そして実務でどう使うかを入門者向けに整理します。なお、SAP BTP自体についてはSAP BTP入門で詳しく解説しています。

SAP Integration Suiteの全体像

SAP Integration Suiteは、SAP BTP上で提供される統合プラットフォーム（iPaaS：Integration Platform as a Service）です。Gartnerのマジック・クアドラントで長年リーダーに位置づけられており、SAP環境におけるデファクトの統合基盤と言えます。

主要コンポーネントは次の5つです。

なぜこれだけのコンポーネントが必要か。連携の性質が「同期API」「非同期イベント」「ファイルベースEDI」「SaaSコネクタ」と多様だからです。1つの方式ですべてをカバーしようとすると無理が生じるため、それぞれに最適化された道具を組み合わせる思想になっています。

アーキテクチャ俯瞰

Integration Suiteが企業システムの中でどの位置に立つのかを図にすると次のようになります。

flowchart LR
  subgraph SAP側
    S4[S/4HANA]
    SF[SuccessFactors]
  end
  subgraph IntegrationSuite[SAP Integration Suite]
    CPI[Cloud Integration]
    APIM[API Management]
    EM[Event Mesh]
  end
  subgraph 外部
    SaaS[Salesforce/Shopify等]
    Partner[取引先システム]
  end
  S4 --> CPI --> SaaS
  SF --> CPI
  CPI --> APIM --> Partner
  S4 -.イベント.-> EM -.-> SaaS

ポイントは、SAPコアと外部システムが直接つながらず、必ずIntegration Suiteを経由することです。これにより、外部システムの変更がS/4HANAに直接波及せず、Clean Coreの原則を保てます。

Cloud Integration（CPI）詳説

Cloud IntegrationはIntegration Suiteの中核で、メッセージのルーティング・変換・エンリッチメントを行う「データ連携エンジン」です。旧オンプレ製品であるSAP PI/POの後継として位置づけられています。

iFlow（Integration Flow）

CPIで連携を作る単位がiFlowです。送信元アダプタ → メッセージ加工 → 送信先アダプタという流れをグラフィカルに組み立てます。たとえばS/4HANAから受注を取得し、JSONに変換してSalesforceに投入する、という処理を1つのiFlowで表現します。

なぜiFlow単位で管理するのか。1つの業務トランザクションを1つのiFlowに閉じ込めることで、エラー発生時にどこが落ちたかをモニタリング画面で即座に追跡できるからです。逆にiFlowを巨大化させると、責務が混ざってデバッグが困難になります。1 iFlow = 1 業務目的を徹底することが、運用品質を決める最大のポイントです。

アダプタ

CPIには標準で80種類以上のアダプタが付属します。代表例は次のとおりです。

• SAP系：IDoc、RFC、SuccessFactors、Ariba、SAP S/4HANA Cloud
• 標準プロトコル：HTTPS、SFTP、SOAP、OData、AS2、AMQP
• クラウド：Salesforce、ServiceNow、Microsoft 365

OData連携は特に頻出で、S/4HANAが提供する標準ODataサービスを呼び出すパターンが多用されます。OData自体の仕組みはODataの基礎で解説していますので、合わせて読むとiFlow設計のイメージが湧きやすくなります。

モニタリングとエラーハンドリング

CPIには「Message Monitoring」という運用画面があり、すべてのメッセージの成功・失敗・処理時間を一覧で確認できます。失敗したメッセージは内容を確認したうえで再送できるため、運用担当者は障害発生時にコードを書かずに復旧操作ができます。これがないと、エラーが起きるたびに開発者が呼び出されることになり、運用が破綻します。

API Management詳説

API Managementは、APIの「ゲートウェイ」「カタログ」「分析」を提供するコンポーネントです。Cloud IntegrationやS/4HANAが提供するAPIを、外部に安全に公開する役割を担います。

主な機能は次のとおりです。

• 認証・認可：OAuth 2.0、API Key、JWTなどによるアクセス制御
• スロットリング：1分あたり100コールまで、といった流量制限
• トランスフォーメーション：リクエスト・レスポンスの変換
• 開発者ポータル：APIカタログを公開し、外部開発者がセルフサービスでAPI Keyを取得できる
• 分析：API別のコール数、レスポンスタイム、エラー率の可視化

なぜAPIにゲートウェイが必要か。バックエンドAPIをそのまま公開すると、認証ロジックや流量制御を各APIで個別に実装する羽目になり、品質がバラつくからです。ゲートウェイに集約することで、セキュリティポリシーを一元管理でき、バックエンドはビジネスロジックに集中できます。

Event Mesh（イベント駆動連携）

Event Meshは、Pub/Sub方式の非同期メッセージングサービスです。AMQP 1.0やMQTTといった標準プロトコルに対応しており、SAPと外部システムを「イベント」でつなぎます。

たとえばS/4HANAで販売注文が確定した瞬間にイベントを発行すると、Event Meshを購読している複数のシステム（在庫アラート・出荷システム・BIダッシュボード）がそれぞれ独立にイベントを受信し、自分の処理を行います。

なぜイベント駆動が重要か。同期APIだけでは「呼び出し元が呼び出し先を知っている」必要があり、新しい受信者を追加するたびに送信元の改修が必要になるからです。イベント駆動なら送信側は「事実が起きたこと」を発行するだけで、受信側は自由に増減できます。疎結合と拡張性を両立させたい場合は、同期APIとイベントを併用するのが現代の定石です。

PI/POからの移行

オンプレで長年使われてきたSAP PI/POは、2027年末（延長サポートで2030年）でメインストリームサポートが終了します。そのため、既存のPI/POユーザーはCloud Integrationへの移行が現実的な選択肢になります。

移行時のポイント（so what）：

• すべてのインターフェースを一括移行しようとしない。利用頻度・業務重要度でグルーピングし、段階的に移す
• PI/POのICOやIRオブジェクトをそのままCPIに翻訳できないため、iFlow設計を見直す機会と捉える
• 旧来のファイルベース連携をAPI/イベント化できないか検討する。単なる「移植」で終わらせるとモダナイゼーションの機会を逃す
• SAPが提供する「Migration Assessment」ツールで既存連携の棚卸しを行う

ユースケース3例

ユースケース1：S/4HANAとSalesforceの双方向受注連携

SalesforceでクローズされたOpportunityをCloud Integrationが受け取り、S/4HANAの販売注文に変換して投入。S/4HANA側で出荷ステータスが更新されるとEvent Meshがイベントを発行し、Salesforce側にステータスを書き戻します。同期APIとイベントの組み合わせの典型例です。

ユースケース2：取引先EDI連携

Trading Partner Managementを使って、サプライヤーから送られてくるEDIFACT形式の発注書を受信し、Cloud IntegrationでS/4HANAのIDocに変換。取引先ごとのフォーマット差異はTPMで管理するため、新規取引先の追加が設定作業だけで済みます。

ユースケース3：在庫イベントの全社配信

S/4HANAで在庫が安全在庫を下回った瞬間にEvent Meshへイベント発行。購買部門のTeamsチャネル、調達BIダッシュボード、サプライヤーポータルが同じイベントを購読し、それぞれの処理を行います。同期APIで実装すると配信先の追加ごとに改修が必要ですが、イベント駆動なら購読を追加するだけで済みます。

よくある疑問（FAQ）

Q. Cloud Integrationだけ契約すれば十分ですか？ A. 連携の性質次第です。データ連携だけならCloud Integrationで足りますが、外部にAPIを公開するならAPI Management、非同期通知ならEvent Meshが必要です。Integration Suiteは複数コンポーネントをまとめて契約できるバンドル提供があります。

Q. CPIのライセンスはどう数えますか？ A. 月あたりのメッセージ件数ベースの課金が一般的です。ファイルベース連携を漫然と続けるとメッセージ数が膨らむため、バッチをまとめるなどの設計工夫がコストに直結します。

Q. オンプレのS/4HANAとも連携できますか？ A. できます。Cloud Connectorという無料コンポーネントを社内に立てると、SAP BTPからオンプレSAPに安全にトンネル接続できます。

Q. ABAPやJava開発スキルは必要ですか？ A. iFlowはローコードで作れますが、複雑なメッセージ変換にはGroovyスクリプトを書くことがあります。XML/JSON/XPath/XSLTの基礎知識は必須と考えてください。

Q. 既存のPI/POエンジニアはCPIにスムーズに移れますか？ A. 概念は近いですが、UIも開発アプローチも別物と考えたほうが安全です。SAP Learning Hubの公式トレーニングを受けたうえで、小規模iFlowから試すのが定石です。

まとめ

• SAP Integration Suiteは、SAP BTP上で提供される統合プラットフォーム（iPaaS）であり、Clean Core戦略を実現するうえで欠かせない外側の統合層
• 主要コンポーネントはCloud Integration・API Management・Event Mesh・Open Connectors・Trading Partner Managementの5つ
• Cloud Integrationはデータ連携の中核で、iFlowを「1つの業務目的」に絞って作ることが運用品質を決める
• API Managementは認証・流量制御・カタログ公開を集約し、バックエンドをビジネスロジックに集中させる
• Event Meshはイベント駆動連携で、システムを疎結合にし拡張性を高める
• PI/POからの移行は単なる移植ではなく、ファイル連携をAPI/イベント化するモダナイゼーションの機会と捉える
• 同期API・非同期イベント・EDI・SaaSコネクタを使い分けることで、現代の複雑な業務システム連携を破綻なく実現できる

統合基盤を制する者がエンタープライズアーキテクチャを制します。SAP環境においてその答えがSAP Integration Suiteであることは、もはや揺るぎません。まずはCloud IntegrationのトライアルテナントをBTP上で立ち上げ、小さなiFlowから触ってみることをおすすめします。

Integration SuiteはBTP上のサービスなので、BTP全体を体系的に押さえておくと応用が効きます。ハンズオン形式で基礎から学べる講座を紹介します。