SAP CPIのIDoc連携基礎：アダプタ設定から監視・再処理まで

SAP CPI（SAP Cloud Integration）でIDocを連携すると、SAP ERPやSAP S/4HANAで発生した業務データを、外部システムや別のSAPシステムへ非同期で連携できます。受注、出荷、請求、品目、取引先など、業務イベントを定型フォーマットで受け渡せる点が特徴です。

実装では、SAP側の送信設定、CPI側のIDocアダプタ、iFlowのルーティングと変換、宛先システムの受信処理を一つの流れとして設計します。接続できたかだけで判断せず、IDoc番号、メッセージID、処理ステータスを追跡できる状態にしておくことが重要です。

01IDoc連携の全体像

IDoc連携は、次の4層に分けて考えると切り分けしやすくなります。

1. 業務イベント：受注登録や出荷確定など、連携の起点となる業務処理
2. SAP側のIDoc生成：メッセージタイプ、基本タイプ、パートナープロファイルなどに基づくIDoc生成
3. CPIのiFlow処理：受信、検証、変換、ルーティング、外部宛先への送信
4. 送信先の業務登録：外部システムでの登録、応答、エラー返却

IDocはヘッダ、制御情報、データセグメント、ステータス情報で構成されます。実装前に、対象のメッセージタイプと基本タイプ、必須セグメント、コード値、文字コード、日時形式を確認します。特に、同じ業務名でも送信元と送信先で必要なセグメントやコード体系が異なる場合があります。

IDocの用語や構造を先に確認する場合は、IDocの基本用語と構造を参照してください。

02送信側の設計と前提確認

CPIの設定を始める前に、SAP側で次の情報を確定します。

SAP側では、ポート、論理システム、パートナープロファイル、メッセージタイプ、プロセスコードなどの関連設定を確認します。送信元でIDocが生成されても、CPIのエンドポイントへ到達しなければ連携は成立しません。接続先のホスト名、ポート、TLS証明書、認証情報、ネットワーク経路を運用担当者と共有します。

また、再送時に同じ業務データが二重登録されないよう、送信元と送信先の双方で重複判定の方法を定義します。IDoc番号だけを使えるとは限らないため、業務上不変のキーを選び、マッピング仕様書に明記します。

03IDocアダプタの設定

CPIのiFlowでは、IDocを受け取る送信側の構成と、IDocをSAPシステムへ送る受信側の構成を分けて設計します。利用するアダプタの方向、認証方式、接続先、タイムアウト、再試行方針を、接続対象に合わせて決定します。

設定時は次の順番で進めると、通信と変換の問題を分離できます。

1. 接続先のアドレスと認証情報を登録する
2. TLS通信を使う場合は証明書チェーンを確認する
3. IDocの送受信方向とエンドポイントを設定する
4. メッセージタイプや基本タイプを仕様と照合する
5. 小さなテストデータで接続だけを確認する
6. 実データに近いIDocでセグメントとコード値を確認する

認証情報はiFlow内に直接記述せず、セキュアな認証情報管理機能で管理します。開発、検証、本番で接続先や資格情報を分離し、移送後に本番値を確認できる手順を用意します。

IDocのXMLやフラット形式を扱う場合は、受信データのルート要素、セグメント名、繰り返し構造、空要素の扱いを確認します。アダプタが正常終了しても、後続のマッピングで必須値が欠落すると業務登録に失敗するため、通信成功と業務成功を別々に判定します。

04iFlowの処理設計

iFlowは、受信、検証、変換、送信、応答処理の順に責務を分けると保守しやすくなります。

受信直後の処理

受信直後に相関IDを作成し、IDoc番号、メッセージタイプ、送信元、受信時刻をログへ記録します。個人情報や機密性の高い業務データをログへ丸ごと出力せず、障害調査に必要な範囲だけを記録します。

検証処理

必須セグメント、必須項目、コード値、桁数、日付形式を検証します。検証エラーは送信先へ進めず、原因と対象項目が分かるエラー情報にまとめます。エラーを握りつぶすと、後続システムで原因不明の登録エラーとして現れるため、検証段階で止めます。

マッピング処理

マッピングでは、項目名の変換だけでなく、コード変換、単位変換、日時変換、条件分岐、繰り返しセグメントの対応を定義します。固定値や変換表をiFlowへ埋め込む場合は、変更時の影響範囲を小さくします。頻繁に変更されるコード変換は、外部化した設定や参照データで管理します。

送信と応答

送信先が同期応答を返す場合は、HTTPステータスだけでなく、業務応答のコードとメッセージも確認します。通信成功でも業務エラーが返ることがあるため、成功条件を明確にします。非同期連携では、送信完了と業務登録完了の相関を追跡できるようにします。

iFlowの構造や処理ステップを整理する場合は、SAP CPIのiFlow設計基礎も確認できます。

05IDoc連携の代表的な事例

受注連携

SAP側で受注を登録した後、受注IDocをCPIへ送信し、外部の受注管理や物流システムへ連携します。販売組織、得意先、品目、数量、納期、価格条件などを変換対象にします。数量単位や通貨、税区分は、送信元と送信先で意味が一致することを確認します。

出荷・配送連携

出荷作成や出荷確定を起点に、配送情報や出荷ステータスを外部システムへ連携します。出荷番号、納品先、明細、ロット、シリアル番号を扱う場合は、分割出荷や複数明細の構造をテストします。

請求連携

請求伝票の生成後に、請求情報を会計、請求書発行、販売管理などのシステムへ渡します。請求金額、税額、通貨、支払条件、参照伝票を確認し、取消や訂正の扱いも仕様化します。

マスタ連携

品目、得意先、仕入先、価格、在庫などのマスタを連携する場合は、初回全件送信と差分送信を分けて設計します。差分条件、削除・無効化の表現、再送時の重複処理を決めておくと、運用時の復旧が容易になります。

06監視とエラー切り分け

本番運用では、CPIのモニタリング画面でメッセージ処理状況を確認し、失敗、処理中、完了を区別します。監視対象には、エラー件数、処理時間、再試行回数、認証エラー、接続エラー、マッピングエラー、業務応答エラーを含めます。

切り分けは、次の順番で実施します。

1. SAP側でIDocが生成され、送信ステータスが進んでいるか確認する
2. CPIでメッセージが受信されたか確認する
3. iFlowのどのステップで失敗したか確認する
4. 接続、認証、証明書、タイムアウトを確認する
5. 入力IDocの必須値とセグメント構造を確認する
6. マッピング後の出力を確認する
7. 送信先の業務応答と登録結果を確認する

SAP側のIDoc番号とCPI側のメッセージIDを関連付けるため、相関IDや業務キーを一貫して記録します。エラー本文だけでなく、発生時刻、送信元、対象業務、再処理可否、担当者を記録すると、同じ障害の再発時にも調査時間を短縮できます。

監視設計と再処理の考え方は、SAP CPIの監視とエラーハンドリングで詳しく整理しています。

07再処理と重複防止

再処理には、通信失敗の再送と業務エラーの修正後再送があります。通信失敗は同じメッセージを再送できる場合がありますが、業務エラーは入力値やマッピングを修正してから再送します。再処理前に、送信先へ登録済みかどうかを確認します。

重複防止では、次の項目を組み合わせて管理します。

• IDoc番号または外部メッセージID
• 業務伝票番号と明細番号
• 送信元システム識別子
• 処理済みフラグまたは登録結果
• 受信時刻と再処理履歴

送信先が冪等性を提供しない場合は、CPIまたは送信先側で重複チェックを実装します。再処理用の操作権限は必要最小限にし、実行者、実行時刻、対象メッセージ、結果を監査ログへ残します。

08テストと本番移行

テストでは、正常系だけでなく、必須値欠落、未知のコード、複数明細、空セグメント、長い文字列、特殊文字、タイムアウト、送信先停止を確認します。IDocの生成から送信先の業務登録までを一つのシナリオとして実施し、各段階の識別子を記録します。

本番移行前には、次の項目を確認します。

• 接続先と認証情報が本番用になっている
• 証明書の有効期限と信頼チェーンを確認している
• iFlowが有効化されている
• 監視担当者と通知先が決まっている
• エラー時の一次対応とエスカレーション先が決まっている
• 再処理の条件と承認手順が決まっている
• 送信元と送信先の稼働時間が合っている
• 初回データと差分データの扱いが決まっている

移行直後は、少数の業務データで疎通と登録結果を確認し、その後に通常量へ広げます。処理件数だけでなく、送信先の登録結果と業務担当者の確認結果までそろってから完了と判断します。

09運用チェックリスト

日次では、失敗メッセージ、長時間処理、再試行中のメッセージ、認証エラー、証明書期限を確認します。週次または定期メンテナンスでは、エラー傾向、処理時間の推移、不要なログ、再処理履歴、接続先変更の有無を確認します。

障害対応では、まず対象範囲を確定し、同じエラーが複数件に広がっているかを確認します。送信元の生成停止、CPIの処理停止、送信先の登録停止を分けて判断し、復旧後に滞留メッセージを安全な順序で処理します。

IDoc連携は、アダプタ設定だけで完了するものではありません。業務イベント、データ構造、変換規則、監視、再処理、重複防止を一体で設計することで、障害発生時にも原因と復旧手順を追跡できる運用になります。