Open Connectors: アーキテクチャと使用

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 24 min read

本記事の位置づけ#

参考資料#

1) Open Connectorsの概要#

Open Connectors は、SAP Integration Suite のSaaS接続機能です。Cloud Integration がプロセスオーケストレーションを、API Management がAPI公開を担当する一方、Open Connectors は、サードパーティのクラウドアプリケーション（Salesforce、ServiceNow、NetSuite、QuickBooks、Eloqua、Marketo など）との通信という特定の役割を、ベンダー独自のSDKやRESTの癖ではなく、正規化されたREST APIを通じて処理します。

これらは代替品ではありません。

2) S/4HANA への接続方法#

   Third-party SaaS (Salesforce, ServiceNow, NetSuite, ...)
            ▲
            │ vendor REST/SOAP (varies per vendor)
            │
   ┌────────┴───────────────────────────┐
   │  Open Connectors (BTP)             │
   │   ├─ Connector (prebuilt/custom)   │  Auth: OAuth 2.0 / API key / Basic
   │   ├─ Hooks (JavaScript pre/post)   │  Override request/response behavior
   │   ├─ Transformation                │  Vendor schema → Common Resource
   │   ├─ Bulk / Events                 │  Async + webhook patterns
   │   └─ Connector Instance            │  Authenticated tenant config
   └────────┬───────────────────────────┘
            │ Normalized REST API (Open Connectors endpoint URL)
            ▼
   ┌─────────────────────────────────────┐
   │  Cloud Integration  ──  API Management  │
   │           │                              │
   │      iFlow HTTP receiver / API proxy     │
   └───────────┬──────────────────────────────┘
               │ IDoc / OData / RFC / SOAP
               ▼
        S/4HANA (on-prem or Cloud)

重要ポイント: Open Connectors はS/4HANAと直接通信しません。これはIntegration SuiteのSaaSエッジに位置し、サードパーティAPIを正規化し、SAP環境への接続をCloud Integration（最も一般的）またはAPI Managementに引き継ぎます。アーキテクチャ上、Open ConnectorsはSaaSの前面に位置する特殊なREST正規化レイヤーとして扱うべきであり、iFlowの代替ではありません。

3) 成熟度マップ#

4) 要件チェックリスト#

テナントおよび契約の前提条件#

SaaSカバレッジとコネクタの選択#

認証とシークレット#

カスタマイズ（共通リソース、フック、数式）#

可観測性と運用#

ライセンスとサイジング#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. Open Connectorsが解決する測定可能な非効率性とは何か、またそれはどのように計測されるのか？

「Salesforceと連携したい」ではありません。それは願望であり、要件ではありません。防御可能な形式は次のとおりです。「営業オペレーションは、毎週300件の商談更新をSalesforceからS/4HANA受注に再入力している。サイクルタイムは2日。再入力なしで1時間未満にしたい。」この定量化がなければ、Open Connectors、Cloud Integration iFlow、あるいは統合そのものが不要なのか、正しい答えを判断することはできません。

Q2. 統合中、データはどこに保存され、誰が所有するのですか？

Open Connectors はコネクターインスタンスの認証情報を保持し、SAP管理のインフラストラクチャを介してデータをルーティングします。規制対象データ（個人情報、財務データ、医療データ）を扱う場合は、アーキテクチャ設計の前に（後ではなく）、セキュリティおよび法務部門と以下の点を確認してください。Integration Suite テナントの BTP リージョンが許容可能であること、SaaS 側の監査証跡が十分であること、そして記録の管理者が SAP ではなく顧客であること。

Q3. 予算と運用権限の両方を持つ内部スポンサーは誰ですか？

Integration Suite 内に存在するSaaS統合には、ベンダー調整、メッセージ量の予算、そしてベンダーがAPIを変更した際に避けられないコネクタ更新について責任を負うオーナーが必要です。これら3つすべてについて単独で署名できる人物がいなければ、統合は漂流します。要件ドキュメントにスポンサーを明記してください。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害 1: カバレッジの前提 — 「カタログには160以上あるから、私たちのものもきっと含まれているはず」

このカタログは主流のSaaSエコノミーをカバーしていますが、ロングテールは対象外です。業界特化型ツール（業界固有のHR、ニッチなeコマース、地域限定の決済処理業者など）は、多くの場合含まれていません。対策は、要件段階でのカタログチェックです。コネクタカタログを開き、カテゴリではなく名前で確認します。ベンダーが存在しない場合、その要件はHTTPアダプタを使用したCloud Integration、またはConnector Builderにルーティングされ、プロジェクト計画ではアーキテクチャの前にその判断を下す必要があります。

障害 2: 可観測性のギャップを過小評価

本番環境でCloud Integrationを運用してきたチームは、Open Connectorsの呼び出しでも同じメッセージ処理ログが利用できると想定しますが、実際には利用できません。ステップ値のログは4MBに制限されており、警告なく欠落する可能性があります。本番環境でのトラブルシューティングは、誰かが設計、構築、保守しなければならないカスタムログに依存します。この問題を解決するには、最初のインシデント発生時にギャップを発見するのではなく、要件定義の段階で可観測性に関する作業を明示的にスコープに含めることです。

障害 3: コネクタのライフサイクルドリフト

ベンダーSaaS APIは変更されます。Open Connectorsのコネクタはプロジェクトのスケジュールではなく、SAPのスケジュールに従います。Salesforceのメジャーリリース、ServiceNowのアップグレード、またはベンダーの非推奨通知により、本番コネクタが数週間使用不能になる可能性があります。対策は二面的です。ベンダーのリリースノートを購読し、四半期ごとにコネクタ適応のための統合時間を少し確保することです。コネクタを「設定したら終わり」と扱うことが失敗の原因です。

障害 4: 統合 #2 で共通リソースがスキップされました

Open Connectorsのアーキテクチャ上のメリットは、1対多のパターンにあります。つまり、1つの共通リソース（例：「リード」）を複数のSaaSシステムにマッピングするというものです。最初のSaaSを統合する際に共通リソースを定義しなかったチームは、2つ目のSaaSが登場したときに再構築を余儀なくされます。そして、2つ目のSaaSの作業は必ず発生します。その対策は、最初のコネクタを本番稼働させる前に、たとえ現時点でコネクタが1つしか存在しなくても、共通リソースを設計することです。

障害 5: 共有メッセージメトリクスによるコストの予想外の増加

Open Connectors の API コールと Cloud Integration のメッセージは、同じ Integration Suite のメトリクスを共有します。iFlows にキャパシティユニットを割り当て、Open Connectors を忘れたチームは、2年目の更新時にそのギャップに気づきます。解決策は、すべての Integration Suite の消費（iFlows、API プロキシ、Open Connectors のコール、Event Mesh）を1つのキャパシティユニット予測にモデル化することです。機能ごとの予算は幻想です。

障害 6: 長期計画におけるライフサイクルの不確実性の無視

Open Connectors は非推奨ではありませんが、SAP のここへの投資ペースは、Cloud Integration や API Management と比較して明らかに鈍化しています。Open Connectors の高度なカスタマイズ（多数のカスタムコネクタ、深い共通リソース、複雑なフォーミュラ）に依存した戦略的な5カ年計画には、文書化すべきライフサイクルリスクが伴います。対策は Open Connectors を避けることではなく、カスタマイズを規律正しく保ち、SAP の戦略が変更された場合に備えて、文書化されたコンティンジェンシープランを用意することです。

障害7: フックの複雑さがランタイムエンベロープを超えている

プリクエストフックとポストレスポンスフックは強力で魅力的です。チームは変換ロジック、エンリッチメントルックアップ、エラーハンドリングチェーンを追加し、フックが5MBのペイロードまたは29秒の実行制限に達するまで拡張します。対策は、フックを小さく保ち、重量級のロジックをCloud Integrationにルーティングすることです。フックが「iFlowのように見える」処理を行っている場合、それはiFlowであるべきです。

FAQ#

Q: Open Connectors は非推奨または廃止予定ですか？

いいえ、2025/2026年時点ではそうではありません。このサービスは引き続きSAP Integration Suiteの月次アップデートに掲載されており、サポート終了の発表はなく、顧客は積極的にオンボーディングされています。実際のところ、SAPのOpen Connectorsへの投資ペースは、Cloud IntegrationやAPI Managementと比較して明らかに遅くなっており、SAPは対象となるコネクタのリストから一部のコネクタを選択的に削除しています（KBA 3170197）。Open Connectorsは、安定した低速度の機能として扱い、5年計画の基盤となる製品として期待するものではありません。

Q: 実際のコネクタ数はいくつですか？「400以上」という数字を見たことがあります。

SAP公式ソース（BTPユースケースページ、ヘルプポータル）では、160以上のプリビルトコネクタが存在すると記載されています。「400以上」という数字はマーケティング関連資料で見られるもので、ハブのバリエーション、非推奨エントリ、コミュニティ構築のコネクタが含まれている可能性があります。要件文書やプロジェクトコミュニケーションでは、SAP公式の160以上という数字を使用し、カタログ内で特定のベンダーを名前で確認するようにし、集計値に依存しないでください。

Q: コネクタが存在する場合でも、Open Connectors を使用すべきでないのはどのような場合ですか？

3つのケース。第一に、ペイロードが定常的に8MBを超える、または処理時間が29秒を超える場合、プラットフォームの上限により本番環境がブロックされます。第二に、運用またはコンプライアンス上、Cloud Integrationの完全な可観測性（メッセージ処理ログ、マッピングデバッガ、リプレイ）が必要な場合。第三に、要求/応答ではなくリアルタイムのイベント配信が必要な場合、Event MeshまたはHTTPアダプタを使用した直接のiFlowがより適切です。慎重に選択してください。

Q: Open Connectors の課金方法は？

Open Connectors の API 呼び出しは、統合 SAP Integration Suite メトリック内のメッセージとしてカウントされます。メッセージは 250 KB 単位でサイズ設定され、10,000 件のブロックで販売されます。同じキャパシティユニットプールが、Cloud Integration メッセージ、API Management 呼び出し、および Open Connectors 呼び出しに充当されます。Open Connectors 専用のラインアイテムはありません。実際には、これは、1 年目と 2 年目のボリュームを、各機能ごとではなく、すべての Integration Suite 使用量にわたってモデル化することを意味します。

Q: Open Connectorsの要件を適切に文書化するにはどうすればよいですか？

各統合には以下が必要：(1) ターゲットSaaSベンダーと確定したカタログエントリ、(2) 必要な操作（読み取り、書き込み、一括、イベント）を明示的に列挙、(3) 認証モードと資格情報の所有権、(4) 月間メッセージ数の見積もり、(5) ベンダーとの調整権限を持つ指名されたスポンサー、(6) プラットフォーム標準を超えた可観測性戦略、(7) 複数のSaaSが同一のSAPプロセスに到達する場合の共通リソースマッピング、(8) コネクタが廃止されたりベンダーがAPIを変更した場合のコンティンジェンシープラン。要件文書に「Open Connectorsを使用します」と一行書くだけでは不十分である。その一行こそ、ほとんどの本番インシデントの発生源となる。

Q: いつOpen Connectorsの統合をプロジェクトからスコープ外とすべきですか？

以下のいずれかに該当する場合は、導入を見送る（Descope）こと：SaaSベンダーがカタログに含まれておらず、Connector Builderのコストが統合の価値を上回る場合；ボリューム予測によりキャパシティユニットコストがビジネスケースを超える場合；可観測性要件がOpen Connectorsの提供範囲を超え、結果的にCloud Integrationが必要となる場合；または、継続的な運用オーナーシップを受け入れる内部スポンサーがいない場合。これらのケースでは、「はい、ただし後で」または「いいえ、別の方法で対応します」という回答が、無理に適合させるよりも適切な選択肢となる。

Q: Open Connectors はオンプレミスの SAP でも動作しますか、それとも S/4HANA Cloud のみですか？

両方とも、間接的です。Open Connectors自体はBTP Cloud Foundry上で動作し、正規化されたRESTエンドポイントを公開します。そのエンドポイントがS/4HANA Cloudテナントに到達するか、オンプレミスのS/4HANAシステムに到達するかは、受信側のCloud Integration iFlow（オンプレミスにはSAP Cloud Connectorを使用）に依存します。Open Connectorsはオンプレミスに依存せず、接続性の判断は後続の処理に委ねられます。

概要#

SAP Open Connectorsは、SAP Integration Suite内でSaaS統合を実現するための、REST正規化に特化したレイヤーです。160以上のプリビルトコネクタがハブ単位で整理されており、Common Resources、Formulas、JavaScriptフック、Bulk、Eventsといった機能を備え、サードパーティAPIを単一の正規化エンドポイントの背後で統合します。ランタイムは本番環境で安定しており、ハードリミット（ペイロード8 MB、JS 5 MB、実行時間29秒、ストリーミング6 GB）も明確に文書化されています。Common Resourcesを活用して複数のSaaSを単一スキーマで抽象化した場合、アーキテクチャ上のメリットは確かに実感できます。制約として、Cloud Integrationと比較して可観測性が低い点、ベンダー主導のコネクタライフサイクルがメンテナンス負荷を生む点、そしてSAPの投資サイクルがIntegration Suite全体と比べて遅い点が挙げられます。コンサルタントとしての価値は、アーキテクチャ検討の前にカタログを確認する習慣、サイズ超過や可観測性不足のワークロードをCloud Integrationに振り分ける規律、そしてOpen Connectorsが要件に合わないケースに備えた代替計画を文書化する姿勢にあります。

次に読むべきもの#