SAP連携(PI/PO/CPI)

SAP PI/POからCPIへの移行基礎:アセスメントから切替・運用まで

SAP PI/POからSAP Integration SuiteのCloud Integrationへ移行する際に、インターフェース棚卸し、アダプター、マッピング、認証、テスト、切替、監視を実務の順番で整理します。

PI/POからCPIへの移行プロセスアセスメントから切替後監視までの実務順序を示すPI/POからCPIへの移行プロセスアセスメントから切替後監視までの実務順序を示す要件実装承認引き継ぎアセスメントインターフェース、マッピン…CPI設計iFlow、接続、認証、例外処…テスト正常系、異常系、重複、復…切替承認済みの切替手順と戻し…運用と監視技術処理と業務結果を照合CertPas オリジナル図解
PI/POインターフェースのアセスメントからCPI設計、テスト、切替、監視までの流れ
目次
  1. 移行の全体像
  2. 移行アセスメントの進め方
  3. アダプターと接続設計
  4. iFlowへの再設計
  5. マッピングとデータ変換
  6. 認証情報と秘密情報の管理
  7. テストと切替計画
  8. 監視と障害対応
  9. 移行で起きやすい問題
  10. 移行完了後の運用

SAP PI/POからCPIへ移行するときは、既存インターフェースをそのまま置き換える作業ではなく、連携要件を再確認してCloud Integration上のiFlowとして再設計する作業になります。特に、アダプター、マッピング、例外処理、認証情報、監視方法は製品間で実装単位が変わるため、先に棚卸しを行うと手戻りを抑えられます。

PI/POのサポート期限や移行時期は、利用製品、リリース、契約、社内の移行計画によって確認対象が異なります。対象システムの保守情報と契約条件を確認し、業務停止の許容時間、並行稼働期間、切替責任者を決めてから詳細設計に進めます。

移行の全体像

移行は、次の順序で進めると管理しやすくなります。

  1. 既存インターフェースの棚卸し
  2. 移行方式と優先順位の決定
  3. 接続先、認証、ネットワークの設計
  4. iFlow、マッピング、例外処理の実装
  5. 単体テスト、結合テスト、業務シナリオテスト
  6. 並行稼働または段階切替
  7. 本番監視と旧環境の整理

CPIの基本構成を先に確認する場合は、SAP連携(PI/PO/CPI)の全体像を参照してください。移行対象を製品名単位でまとめず、業務イベント単位で分けることが重要です。たとえば、受注連携、出荷実績連携、請求書連携を別々の対象として管理します。

PI/POの棚卸し項目とCPI移行時の判断既存資産を具体的な移行判断へ結び付けるPI/POの棚卸し項目とCPI移行時の判断既存資産を具体的な移行判断へ結び付ける接続リスクデータリスク運用リスクアダプターとプロトコルプロトコル、TLS、認証、…マッピングと変換項目ルール、欠損値、形式…運用と監視メッセージ検索、通知、再…移行判断業務影響度と運用複雑度で…CertPas オリジナル図解
CPI移行の判断に使うアダプター、マッピング、運用の棚卸し項目

移行アセスメントの進め方

最初に、PI/POのIntegration Directory、構成オブジェクト、通信チャネル、マッピング、ルーティング条件、運用手順を一覧化します。設計書だけでなく、実際のメッセージログ、エラー履歴、手動リカバリ手順も確認します。設計書に記載されていない補正処理が運用担当者の手作業に含まれている場合があるためです。

棚卸し表には、少なくとも次の項目を持たせます。

  • インターフェースIDと業務名
  • 送信元、受信先、データ形式
  • 同期・非同期の区分
  • 通信プロトコルとアダプター
  • マッピングと変換ルール
  • 送信頻度、ピーク件数、最大メッセージサイズ
  • エラー時の再送、保留、業務確認の手順
  • 認証方式、証明書、秘密情報の管理責任者
  • 業務オーナー、技術オーナー、切替優先度

件数だけでなく、障害時の影響度で優先順位を付けます。月次の低頻度連携よりも、受注や在庫更新のように停止が業務へ直結する連携を先に検証すると、移行計画のリスクを早く把握できます。

アダプターと接続設計

PI/POで使用している通信チャネルを、CPIで利用する接続方式へ対応付けます。HTTP、SOAP、SFTP、IDoc、ODataなど、送信元と受信先の双方で必要なプロトコルを確認し、接続先の到達性、TLS、証明書、有効期限、認証ユーザーを設計書に記録します。

アダプターは名称だけで置き換えず、次の観点で評価します。

  • 接続先が要求するプロトコルと暗号スイート
  • 同期応答のタイムアウトと再試行
  • ファイル名、文字コード、改行、圧縮の扱い
  • IDocやSOAPのエラー応答
  • ペイロードのサイズ制限
  • 接続先のIP許可、プロキシ、ネットワーク経路

方式ごとの特徴を整理するには、SAP CPIのアダプター種類比較が役立ちます。接続テストでは、単純な疎通だけでなく、実際の証明書、業務用サービスユーザー、代表的なペイロードを使って確認します。

iFlowへの再設計

CPIでは、送受信、変換、ルーティング、例外処理をiFlowの処理ステップとして構成します。既存のPI/PO構成を一つの大きなフローに移すのではなく、変更頻度、障害範囲、再利用性を見て分割します。

処理の境界を決める際は、次の設計を先に文書化します。

  • 入力メッセージの必須項目とデータ型
  • 正常系の変換順序
  • 条件分岐の判定項目
  • 受信先ごとの出力形式
  • エラーを技術エラーと業務エラーに分ける基準
  • 再送可能なエラーと手動確認が必要なエラー
  • 相関IDや業務キーの引き継ぎ方法

iFlowの基本構造を確認する場合は、SAP CPIのiFlow基礎を参照してください。処理ステップを細かく分けすぎると運用時の追跡が難しくなるため、ログで確認したい境界と、変更単位の両方を基準にします。

マッピングとデータ変換

PI/POのMessage Mapping、Operation Mapping、ユーザー定義関数を移行するときは、関数の再現だけでなく、入力データの欠損や複数件データの扱いを確認します。空文字、NULL、未存在ノード、日時、数値の丸め、コード変換は不具合になりやすい箇所です。

マッピング仕様書には、項目対応だけでなく、条件と例外を記載します。たとえば、入力値が空の場合に出力項目を省略するのか、空要素を出すのか、既定値を設定するのかを明確にします。また、1対多や多対1の変換では、レコード単位とメッセージ単位の境界をテストデータで固定します。

変換ロジックの確認には、SAP CPIのメッセージマッピング基礎を利用できます。移行前後で同じ入力を処理し、XML、JSON、CSVなどの出力を差分比較すると、目視では見落としやすい文字コードや要素順の差を検出できます。

認証情報と秘密情報の管理

ユーザー名、パスワード、証明書、秘密鍵、APIキーは、iFlowやスクリプトに直接記述せず、CPIのセキュリティアーティファクトとして管理します。名称、用途、所有者、有効期限、更新手順を台帳化し、担当者が交代しても更新できる状態にします。

証明書を使う連携では、発行者、サブジェクト、SAN、有効期限、証明書チェーン、秘密鍵の対応を確認します。切替前には本番用証明書を登録し、接続先が要求するチェーンを含めて実通信を行います。パスワードや証明書の更新後に、再デプロイや再起動が必要かどうかも運用手順へ記載します。

テストと切替計画

テストは、技術的にメッセージが届くことだけで完了にしません。正常系、必須項目欠落、コード不正、重複送信、受信先停止、タイムアウト、部分的な業務エラーを含めて確認します。各ケースには入力データ、期待結果、確認ログ、担当者、実施日を記録します。

最低限、次のテスト層を分けます。

  • 接続テスト:認証、TLS、ネットワーク、プロトコル
  • 変換テスト:項目、形式、文字コード、件数
  • 異常系テスト:再試行、エラー通知、保留、再送
  • 結合テスト:送信元から受信先までの一連の処理
  • 業務テスト:後続伝票、在庫、請求、照合などの結果
  • 運用テスト:監視、担当者通知、ログ検索、復旧

切替方式は、一括切替、段階切替、並行稼働から選びます。並行稼働では二重登録を防ぐ制御、メッセージの識別、処理済み判定、旧経路の停止条件を定義します。切替当日の手順には、開始条件、担当者、確認画面、判定基準、戻し方、関係者への連絡先を含めます。

監視と障害対応

本番稼働後は、メッセージ処理の成功・失敗だけでなく、処理時間、滞留、再試行、接続先の応答、業務上の件数を監視します。技術的に成功したメッセージでも、受信先で業務登録に失敗する場合があるため、受信側の登録結果との照合を設けます。

監視設計では、次の情報を一つの障害記録に集約します。

  • インターフェース名とiFlow名
  • メッセージID、相関ID、業務キー
  • 発生時刻と処理ステップ
  • エラー分類と受信先の応答
  • 再送可否と再送回数
  • 一時対応、恒久対応、担当者
  • 業務影響と未処理件数

運用画面での確認手順は、SAP CPIの監視とエラーハンドリング基礎に沿って整理できます。再送前には、受信先に登録済みでないこと、重複登録を防ぐキーが機能すること、元メッセージを保存していることを確認します。

移行で起きやすい問題

移行プロジェクトでは、次のような問題が発生しやすくなります。

  • 棚卸しに含まれない未使用または臨時インターフェースが本番で必要になる
  • 旧環境のマッピング関数に暗黙の変換処理が含まれている
  • 接続先の証明書チェーンや送信元許可が不足する
  • エラー時の再送が二重登録を引き起こす
  • 業務オーナーが期待する完了条件と技術担当者の完了条件が異なる
  • 監視通知は届くが、誰が復旧するか決まっていない
  • 切替後の照合期間が短く、月次や締め処理の不具合を見逃す

これらを避けるには、アセスメント表、テスト証跡、切替判定表、障害対応手順を同じインターフェースIDで紐付けます。移行完了の判定は、デプロイ完了ではなく、業務結果の照合と運用引き継ぎまで含めます。

移行完了後の運用

切替後は、少なくとも一つの業務サイクルを対象に、件数、金額、ステータス、未処理、再送、業務側の後続結果を旧実績または基準値と照合します。日次処理だけでなく、週次、月次、締め処理、繁忙日のピークも確認対象にします。

安定稼働後に、旧PI/PO側の通信停止、証明書やユーザーの無効化、監視ジョブの整理、ログ保管、設計書の更新を実施します。旧環境をすぐに撤去せず、保管期間、参照権限、障害時の確認方法を決めてから整理すると、移行後の問い合わせにも対応しやすくなります。

SAP PI/POからCPIへの移行は、技術変換と業務継続を同時に管理するプロジェクトです。インターフェース単位で棚卸しし、接続、変換、例外、監視、切替の判定基準を事前に揃えることで、移行後の障害を早期に切り分けられます。

ブログ一覧へ戻る