SAP CPIアダプタ種類の比較｜SOAP・REST・IDoc・OData・SFTPの選び方と障害対応

SAP Cloud IntegrationのiFlowでは、送信元または送信先との接続方式に応じてアダプタを選びます。アダプタは単なる通信口ではなく、認証、メッセージ形式、接続方向、タイムアウト、再送設計、監視方法に影響する設定単位です。最初に業務要件と相手システムのインターフェース仕様を整理し、その後にアダプタの選定を行うと、実装後の作り直しを抑えられます。

01アダプタを選ぶ基本軸

アダプタを比較するときは、次の順番で確認します。

1. 相手が公開している通信方式を確認する
2. 送信方向がインバウンドかアウトバウンドかを決める
3. メッセージ形式と変換要否を確認する
4. 認証方式、暗号化、証明書、秘密鍵の管理方法を確定する
5. 同期応答が必要か、非同期でよいかを決める
6. 失敗時の再送、重複防止、エラー通知を設計する

HTTP系のAPIならRESTまたはSOAP、SAPの業務オブジェクト連携ならODataまたはIDoc、ファイル交換ならSFTPが中心になります。仕様書に「API」とだけ書かれている場合は、HTTPメソッド、URL、ペイロード形式、認証、応答コードまで確認してください。APIという名称だけでは、RESTアダプタとSOAPアダプタのどちらを使うか決まりません。

実装単位を整理するときは、SAP CPI iFlowの基本で説明している送信者、処理ステップ、受信者の構成に沿って、各接続点へアダプタを割り当てます。送信側と受信側で異なるアダプタを使う構成も一般的です。

02主要アダプタの比較

この表は候補を絞るためのものです。たとえば、JSONを送るからRESTと決めるのではなく、相手が提供するエンドポイントと認証方式を基準にします。反対に、ファイルを定期的に受け取る業務では、HTTPでファイル管理APIを呼ぶよりSFTPのほうが運用要件に合う場合があります。

03RESTとSOAPの使い分け

RESTアダプタは、HTTP上のリソースを操作するAPI連携に向いています。GET、POST、PUT、PATCH、DELETEの使い分け、JSONの構造、HTTPヘッダー、ページング、レート制限を確認します。応答が2xxでも業務エラーを本文に返すAPIがあるため、ステータスコードだけで成功判定を終えず、レスポンス本文の業務ステータスも評価します。

SOAPアダプタは、WSDLで定義された契約に従うWebサービス連携で使います。実装時は、WSDLから確認できるサービス、ポート、オペレーション、データ型、名前空間を整理します。SOAP FaultはHTTPエラーと別に扱われることがあるため、正常応答のXMLだけでなくFaultの構造もエラー処理へ組み込みます。

RESTではURLやヘッダーの違いが原因になりやすく、SOAPでは名前空間、SOAPアクション、WSDLと実装の不一致が原因になりやすい傾向があります。ペイロード変換が必要な場合は、SAP CPIメッセージマッピングの基本を参照し、変換前後のサンプルを固定してテストします。

RESTの実装チェック

• APIのベースURLとリソースURLを環境ごとに管理する
• AuthorizationやContent-Typeなどのヘッダーを仕様に合わせる
• 4xx、5xx、タイムアウト、レート制限を個別に扱う
• ページングと大量データ時の分割単位を決める
• リトライで二重登録が起きないよう、冪等性キーや業務キーを確認する

SOAPの実装チェック

• 利用するWSDLとエンドポイントを確定する
• SOAPアクションと名前空間を確認する
• SOAP Faultのコードと詳細をログへ残す
• XMLスキーマの必須項目と桁数をテストする
• WS-Securityやクライアント証明書の要件を確認する

04ODataとIDocの使い分け

ODataは、エンティティ単位でSAPのデータを取得・登録・更新する連携に適しています。サービスのメタデータを確認し、エンティティ、キー、ナビゲーション、フィルタ条件、更新可否を把握します。更新系ではCSRFトークン、HTTPメソッド、ETagなどの制御が関係するため、取得処理と更新処理を分けて設計します。

IDocは、SAPの業務イベントや大量の非同期データを連携する場合に適しています。メッセージタイプ、基本タイプ、拡張、セグメント、処理ステータスを先に確定します。送信元で生成されたIDocの制御情報とデータレコードを確認し、受信側で必要な項目が欠落しないかを検証します。

ODataはAPIの応答を見ながら処理する同期型の設計に向き、IDocは受信確認と後続処理を分離する非同期型の設計に向きます。IDoc連携の構造や運用確認には、SAP CPIのIDoc連携基礎も利用できます。

IDocで確認する項目

1. 送信側のメッセージタイプと基本タイプ
2. 拡張セグメントの有無
3. CPI側で受信するXML構造
4. 必須セグメントと繰り返しセグメント
5. 受信後に返すステータスや確認メッセージ
6. 同じ業務キーを受信した場合の重複処理

05SFTPとファイル連携の実装

SFTPアダプタは、相手システムがファイルを配置または取得する方式を採用している場合に使います。接続先ホスト、ポート、ユーザー、認証鍵、リモートディレクトリ、ファイル名パターンを環境別に管理します。秘密鍵やパスワードはセキュリティマテリアルで管理し、iFlowへ直接埋め込みません。

ファイル連携では、ファイルを書き込み中に読み取らない仕組みが重要です。送信側が一時拡張子で配置して完了後にリネームする方式、完了ファイルを別途配置する方式、サイズ安定を確認する方式などから、相手との合意に合うものを選びます。受信後はアーカイブ先、処理済みファイル名、エラー時の隔離先を決めます。

CSVでは区切り文字、引用符、改行、文字コード、ヘッダー、日付形式を確認します。固定長では文字単位とバイト単位の扱いを確認します。大量ファイルでは、1ファイルずつ処理するか、まとめて処理するか、失敗ファイルだけ再処理できるかを設計に含めます。

06認証とセキュリティの設計

アダプタの設定前に、認証方式と通信保護を一覧化します。代表的な要素はBasic認証、OAuth、クライアント証明書、公開鍵認証、署名、暗号化です。環境ごとにエンドポイントや証明書が変わる場合は、接続先情報と認証情報を分離して管理します。

証明書を使う場合は、有効期限、用途、チェーン、秘密鍵の有無、更新手順を確認します。SFTPの公開鍵認証では、相手側に登録する公開鍵と、接続元で使う秘密鍵の対応を管理します。AS2では署名・暗号化証明書に加えて、MDNの返却条件とタイムアウトを確認します。

権限は、開発、テスト、本番で分離し、運用担当者が必要なアーティファクトだけを変更できる状態にします。パスワードや秘密鍵をログ、メッセージ本文、例外詳細へ出力しないことも確認します。

07障害調査と再送の進め方

障害が発生したら、最初にメッセージモニタリングで発生時刻、iFlow、メッセージID、送信元、受信先、エラー本文を特定します。次に、接続障害、認証障害、変換障害、相手システムの業務エラーを分類します。監視とエラー処理の運用設計は、SAP CPIの監視とエラーハンドリングの観点で整理できます。

再送前に、相手側で登録済みかを確認します。タイムアウトは処理が失敗したとは限らず、相手側で処理が完了して応答だけ失われている場合があります。業務キー、外部ID、メッセージIDを使って重複を確認し、再送による二重登録を防ぎます。

08実装前の選定手順

実装前に、次の情報を1枚の接続一覧へまとめます。

この一覧をレビューしてからiFlowを作成すると、アダプタ設定、マッピング、例外処理、監視条件の抜けを見つけやすくなります。仕様変更時は、接続先、認証、データ形式、エラー処理の4領域をまとめて再確認します。

テストで確認するケース

• 正常な最小メッセージ
• 必須項目欠落
• 文字コードや特殊文字を含むデータ
• 大量件数と長時間処理
• 認証失敗と証明書期限切れ
• 相手側の4xx、5xx、タイムアウト
• 同一メッセージの再送
• 部分成功が発生した場合の再処理

アダプタの種類だけで設計の品質は決まりません。通信契約、データ構造、認証、再送、重複防止、監視を一つの運用単位として扱うことが、安定したCPI連携につながります。