SAP PI・PO・CPIとは？連携基盤の違いとiFlow設計・運用の基本

SAPシステムと外部サービスを接続するとき、PI、PO、CPIはデータを受け取り、変換し、相手先へ届けるための連携基盤です。製品名の変遷だけで判断すると、既存環境の運用や新規インターフェースの設計で迷いやすくなります。まずは、それぞれが担う役割と、実際のメッセージ処理の流れを分けて整理します。

01SAP PI・PO・CPIの位置付け

SAP PIは、企業内外のシステム間連携を構成するためのミドルウェアです。通信プロトコルの違いを吸収し、送信元のデータを受信先が扱える形式へ変換します。SAP ERPやSAP S/4HANAと、非SAPシステム、ファイルサーバー、取引先システムをつなぐ用途で利用されてきました。

POは、PIの連携機能に加えて、業務プロセスを扱う機能を統合した製品です。システム間メッセージ連携を中心に使う構成ではPIに近い考え方で扱いますが、プロセス統合や業務ルールを含む環境ではPOの構成要素も確認します。

CPIは、SAP Integration SuiteのCloud Integration機能を指す実務上の呼称です。Web画面で連携フローを設計し、iFlowとしてデプロイして運用します。PI・POで蓄積した連携要件をCPIへ移す場合は、単純な設定コピーではなく、接続方式、認証情報、マッピング、監視方法を順番に棚卸しします。

ここで重要なのは、PI・POとCPIを単なる略称の違いとして扱わないことです。既存資産の所在、接続先の制約、運用担当者の権限、メッセージ量、障害時の再送手順を確認して、採用する基盤と設計方式を決めます。

02連携処理の基本アーキテクチャ

典型的な連携は、送信元、連携基盤、送信先の3層で構成します。送信元がIDoc、SOAP、OData、RFC、ファイルなどでデータを渡し、連携基盤が受信、検証、変換、ルーティングを実行し、送信先のAPIやファイル領域へ送ります。

[送信元システム]
        |
        | 受信アダプタ
        v
[PI / PO / CPI の連携フロー]
  検証 → マッピング → ルーティング → 例外処理
        |
        | 送信アダプタ
        v
[送信先システム]

CPIでは、この一連の処理をiFlowとして可視化します。受信側のSender、処理ステップ、送信側のReceiverを配置し、各接続のアダプタにエンドポイントや認証方式を設定します。PI・POでは、通信チャネルや統合フローなど、製品世代に応じた管理単位で同じ責務を構成します。

設計時は、データ形式だけでなく処理の境界を明確にします。たとえば、必須項目の検証を送信元で行うのか、基盤で行うのか、送信先で拒否させるのかによって、障害の検知場所と再送方法が変わります。

03PI・POとCPIの違い

PI・POでは、インフラ、アプリケーション、通信チャネルを含む構成管理が運用の重要な部分になります。CPIでは、iFlow本体に加え、セキュリティマテリアル、接続設定、外部化パラメータ、権限を一体で管理します。

既存のPI・PO連携をCPI向けに再設計する場合は、まず連携一覧を作ります。送信元、送信先、業務イベント、データ形式、通信方式、実行頻度、ピーク件数、エラー時の業務影響を記録すると、移行対象の優先順位を決めやすくなります。移行の進め方は、SAP PI/POからCPIへの移行基礎でも整理しています。

04アダプタの選び方

アダプタは、連携基盤と接続先の通信方式を結び付ける部品です。代表例として、HTTP、SOAP、OData、SFTP、FTP、IDoc、RFC、JDBC、メールなどがあります。名前だけで決めず、接続先が提供する認証方式、同期・非同期の別、ファイルの命名規則、再送方法を確認します。

選定では、次の順番で条件を整理します。

1. 接続先が公開しているプロトコルとエンドポイントを確認する。
2. 認証方式、証明書、秘密鍵、許可IPなどの接続条件を確認する。
3. 送受信方向と、同期処理か非同期処理かを決める。
4. タイムアウト、リトライ、重複処理、順序保証の要件を定義する。
5. テスト用と本番用の接続情報を分離する。

アダプタの違いは、接続できるかどうかだけでなく、障害時の挙動にも影響します。たとえばファイル連携では、ファイルの取得後に処理済み領域へ移す設計が必要です。API連携では、HTTPステータス、レスポンス本文、相手先のレート制限をログに残せるようにします。比較検討にはSAP CPIアダプタ種別の比較が役立ちます。

05iFlowの設計単位

iFlowは、メッセージを受け取ってから送信するまでの処理を、実行可能なフローとして表現します。基本構成は、開始イベント、受信処理、変換・分岐、送信処理、例外処理です。小さな処理を組み合わせることで、業務単位の変更やテスト範囲を限定できます。

開始
  ↓
受信アダプタ
  ↓
入力検証・ログ相関ID付与
  ↓
マッピング・値変換
  ↓
条件分岐・ルーティング
  ↓
送信アダプタ
  ↓
成功処理 / 例外処理

設計時には、1つのiFlowに多くの業務責務を詰め込まないことが重要です。受注連携、請求連携、マスタ連携を1本にまとめると、変更影響と障害調査の範囲が広がります。業務イベントや送信先が異なる処理は、独立したフローとして管理し、共通処理は再利用可能な形で切り出します。

フロー名には、送信元、業務イベント、送信先、方向を含めます。たとえば ERP_Order_To_Logistics のように命名すると、監視画面や運用手順から対象を特定しやすくなります。命名規則には環境名や秘密情報を含めず、識別子と接続先の対応表を別に管理します。iFlowの構成要素はSAP CPI iFlowの基本で詳しく確認できます。

06マッピングとデータ変換

マッピングは、送信元の項目を送信先の項目へ対応付け、形式や値を変換する処理です。項目名を結び付けるだけでなく、必須項目、コード変換、日付形式、単位、文字コード、繰り返し構造を定義します。

マッピング仕様書には、少なくとも次の項目を記載します。

• 送信元と送信先の項目名
• データ型と最大長
• 必須・任意の区分
• 初期値と固定値
• コード変換表
• 複数項目からの編集規則
• エラーにする条件
• 空値とNULLの扱い

コード変換をiFlow内に直接埋め込むと、業務変更のたびにフロー修正が必要になります。頻繁に変わる値は外部化したテーブルや管理対象の値マッピングとして管理し、変更履歴と承認手順を残します。複雑なXML変換では、入力例、期待結果、境界値をテストケースに含めます。実装の考え方はSAP CPIメッセージマッピングの基礎も参照できます。

07監視とエラー対応

連携基盤の監視では、フローが起動したか、メッセージが受信されたか、変換を通過したか、送信先が受け付けたかを分けて確認します。画面上で失敗と表示されても、原因は接続、認証、入力データ、マッピング、送信先業務エラーのいずれかで異なります。

障害調査では、最初に相関ID、実行日時、iFlow名、送信元、送信先、メッセージIDを特定します。次に、エラーが発生したステップと、再送可能な状態かどうかを確認します。認証期限切れやネットワーク障害は接続設定を確認し、入力不備は元データを修正してから再処理します。

再送前には、送信先に同じデータが到着していないことを確認します。業務キーや外部IDを使って重複を判定できる設計にすると、再送による二重登録を抑えられます。再送操作を担当者の判断だけに任せず、対象条件、承認者、実施記録、結果確認を運用手順に記載します。

監視項目は、エラー件数だけでは不十分です。処理時間、待機中メッセージ、連続失敗、送信先の応答時間、証明書の有効期限、ファイル滞留数も確認対象にします。日次確認と即時通知を分け、業務影響の大きい連携には通知先とエスカレーション条件を設定します。障害パターンはSAP CPIの監視とエラーハンドリング基礎にまとめています。

08実装から本番運用までの手順

新しい連携を作るときは、要件定義から運用設計までを一続きで扱います。

1. 業務イベント、送信元、送信先、データ責任者を確定する。
2. 通信方式、認証、データ形式、処理頻度、件数を定義する。
3. 正常系、入力不備、接続障害、送信先エラーの処理を設計する。
4. iFlow、アダプタ、マッピング、外部化パラメータを実装する。
5. 単体テスト、接続テスト、異常系テスト、再送テストを実施する。
6. 監視項目、通知先、運用権限、復旧手順を登録する。
7. 本番切替前に、初回データの確認者と切戻し条件を決める。
8. 本番稼働後に、処理件数、エラー、性能、運用負荷を確認する。

テストでは、正常なサンプルだけでなく、必須項目欠落、未知コード、長い文字列、特殊文字、重複メッセージ、送信先停止を扱います。非同期連携では、受信成功と業務登録完了が別のタイミングになるため、最終結果を確認できる照合方法を用意します。

09運用設計で押さえるポイント

PI・PO・CPIの運用では、設定値、認証情報、マッピング、ログ、再送権限を分けて管理します。開発者が本番の秘密情報を直接参照できないようにし、環境ごとの接続先と権限を明確にします。

変更管理では、フローの変更理由、対象業務、テスト結果、承認者、リリース日時を記録します。マッピングやコード変換表の変更も、プログラム変更と同じように影響範囲を確認します。証明書やパスワードの更新は有効期限の直前に行うのではなく、更新手順と接続テストを計画します。

障害対応手順には、監視画面で見る場所、ログの保存期間、一次切り分け、再送条件、業務部門への連絡方法を含めます。基盤担当、SAPアプリケーション担当、送信先担当の責任分界を事前に定義しておくと、障害発生時の確認漏れを減らせます。

10まとめ

SAP PI・PO・CPIは、システム間の通信を成立させるだけでなく、データ変換、ルーティング、エラー処理、監視を含む連携基盤です。PI・POでは既存構成と依存関係、CPIではiFlowと接続設定、認証情報、運用権限を一体で確認します。

実務では、製品名の比較から始めるより、送信元と送信先、データ形式、処理頻度、障害時の業務影響を明確にする方が設計判断につながります。アダプタ、マッピング、監視、再送を最初から運用設計に含めることで、稼働後の調査と復旧を安定させられます。