SAP連携（PI/PO/CPI）
SAP CPI監視とエラー処理の基礎｜メッセージ処理ログの見方と例外処理
SAP CPI（Cloud Integration）の監視とエラー処理を、メッセージ処理ログ、再処理、例外サブプロセス、通知設計の観点から実務向けに解説します。
SAP CPI（Cloud Integration）の運用では、iFlowがデプロイ済みであることと、業務メッセージが正常に処理されていることを分けて確認します。デプロイ状態だけでは、認証エラー、接続先の停止、マッピング不備、想定外のデータ形式までは把握できません。日常運用では、メッセージ処理ログを中心に、失敗の発生時刻、対象メッセージ、エラー地点、再処理の可否を順に確認します。
本記事では、SAP CPIの監視画面で確認する情報、エラーを分類する手順、例外処理サブプロセスの使い方、再処理時の注意点をまとめます。iFlowの基本構造は、先に SAP CPI iFlowの基礎 を確認しておくと、各ステップと監視結果の対応を追いやすくなります。
SAP CPI監視の基本構成
SAP CPIの監視は、次の三つの層に分けると判断しやすくなります。
- 実行状態：iFlowが開始済みか、停止中か、デプロイ済みか
- メッセージ状態：メッセージが完了、処理中、失敗のどの状態か
- 業務結果：受信側で登録や更新が完了し、重複や欠落がないか
実行状態が正常でも、メッセージ処理は失敗することがあります。逆に、送信側から見るとタイムアウトでも、受信側では登録済みという場合があります。そのため、監視担当者はメッセージ処理ログだけで結論を出さず、相関ID、送信元の記録、受信先の業務ログを突き合わせます。
監視対象には、失敗件数だけでなく、処理時間の急増、再試行の増加、特定の接続先に偏った失敗、同じペイロードの反復送信も含めます。件数が少ないインターフェースでは、失敗率よりも「失敗が一件でも発生したか」を通知条件にする方が実務に適しています。
メッセージ処理ログの確認手順
SAP CPIでは、Monitor画面からメッセージ処理ログを開き、対象期間、iFlow、処理状態を絞り込んで確認します。大量のメッセージを扱う環境では、最初から本文を開くのではなく、発生時刻、処理状態、iFlow名、メッセージIDなどで候補を絞り込みます。
確認順序は次のとおりです。
- 発生時刻を業務側の送信時刻と照合する
- iFlow名とバージョンを確認する
- メッセージIDや相関IDを記録する
- 失敗したステップとエラー内容を確認する
- 添付ログ、トレース、ヘッダー情報を確認する
- 受信側に到達していないことを業務ログで確認する
エラー本文には、HTTPステータス、認証失敗、接続拒否、タイムアウト、変換エラー、必須項目不足など、原因の手がかりが含まれます。エラー文をそのまま転記するだけでなく、「どのステップで」「どのシステムに対して」「どのメッセージが」失敗したかを記録すると、担当チームへの引き継ぎが容易になります。
メッセージ本文や添付ファイルに個人情報、認証情報、業務上の機密データが含まれる場合は、閲覧権限と保存期間を管理します。トレースを使用する場合も、調査終了後に不要な詳細ログを残さない運用が重要です。アダプターごとの接続条件を整理する際は、SAP CPIアダプター種別の比較 も参照できます。
エラー原因を分類する
エラー対応では、エラー文のキーワードだけでなく、失敗地点と再実行の安全性を見ます。実務では、次の分類が扱いやすい構成です。
接続・認証エラー
接続先のホスト名、ポート、TLS設定、証明書、OAuthやBasic認証のアーティファクトを確認します。接続先の停止やネットワーク制御が原因の場合、同じメッセージを繰り返し再処理しても成功しません。接続先の稼働状況と、CPIから到達できる時間帯を確認してから再処理します。
データ形式・マッピングエラー
XMLやJSONの構造、名前空間、必須項目、コード値、日付形式を確認します。マッピング変更後に失敗が増えた場合は、変更前後のペイロードとマッピング定義を比較します。メッセージマッピングの設計を見直す場合は、SAP CPIメッセージマッピングの基礎 が関連します。
受信側業務エラー
通信自体は成功していても、受信側の業務チェックで拒否されることがあります。得意先、品目、会社コード、権限、期間、重複キーなどを受信側のログで確認します。この場合、CPI側だけで修正せず、受信側の業務担当者とエラー内容を共有します。
タイムアウト・一時的な障害
タイムアウトは、処理時間の長期化、受信側の負荷、ネットワーク遅延、応答サイズなど複数の要因で発生します。再処理の前に、受信側で処理済みになっていないかを確認します。処理済みのメッセージを再送すると、二重登録につながる可能性があります。
例外処理サブプロセスの設計
iFlow内で予期しないエラーを扱うには、例外処理サブプロセスを使用します。例外処理サブプロセスでは、エラー発生時に実行するログ記録、通知、エラーキューへの送信、監査用情報の保存などを定義します。
設計時は、次の情報をエラー通知に含めます。
- iFlow名と環境
- 発生日時
- メッセージIDと相関ID
- エラーが発生した処理ステップ
- エラー概要
- 再処理の可否
- 担当チームと対応期限
例外処理サブプロセスの目的は、エラーを隠すことではなく、調査に必要な情報を一定の形式で残すことです。例外処理の中で別の処理を呼び出す場合は、その呼び出し自体が失敗したときの記録方法も決めます。通知処理が失敗した結果、元のエラー情報まで失われないよう、最低限の情報をメッセージ処理ログに残します。
エラー通知は、すべてを即時通知すると運用担当者が重要な障害を見落としやすくなります。接続先停止、認証期限切れ、証明書期限、業務データ不備など、担当者と対応時間が異なる分類ごとに通知先と優先度を設定します。
再処理とリトライの判断
再処理は、原因が解消され、同じメッセージを安全に実行できることを確認してから行います。まず、受信側に処理済み記録がないか、CPIの前段で同じメッセージが送信されていないかを確認します。
再処理しやすいのは、受信側が一時停止していた場合、通信タイムアウトで受信側の処理結果が未確定の場合、短時間のネットワーク障害が原因だった場合です。一方、必須項目不足、コード値不正、マッピング不備では、データまたはiFlowを修正してから再処理します。
リトライを設計する場合は、回数、間隔、対象エラー、最終失敗時の扱いを明確にします。短い間隔で無制限にリトライすると、接続先の負荷を高め、同じエラーを大量に発生させます。指数バックオフや最大試行回数を設定し、最終的には担当者が確認できるエラーキューへ送ります。
再処理可能なメッセージには、冪等性の仕組みを用意します。外部キー、業務伝票番号、メッセージIDなどを受信側で照合し、同一メッセージを複数回処理しても結果が重複しない設計にします。冪等性を実装できない場合は、再処理前の確認手順を運用文書に固定します。
監視アラートの実務設計
アラートは、発生した事実を知らせるだけでなく、誰が何を確認するかまで決めて設計します。最低限、通知内容から対象iFlow、発生時刻、エラー分類、メッセージID、担当チームを特定できるようにします。
推奨する監視条件は次のとおりです。
- 重要iFlowで失敗メッセージが発生した
- 一定時間内の失敗件数が閾値を超えた
- 同一エラーが連続して発生した
- 処理時間が通常値を大きく超えた
- 特定の接続先に失敗が集中した
- 証明書や認証アーティファクトの期限が近づいた
閾値は、開発環境と本番環境で分けます。バッチ連携では実行時間帯ごとの件数を基準にし、リアルタイム連携では遅延時間と連続失敗数を基準にします。休日や月末など、通常と異なる業務量を考慮した除外時間も運用に記載します。
障害対応の標準ランブック
障害発生時は、次の順序で対応します。
- 影響範囲と対象iFlowを特定する
- メッセージ処理ログで最初の失敗を確認する
- 同一時間帯の他iFlowへの波及を確認する
- 接続先と認証アーティファクトの状態を確認する
- 受信側の処理済み状態を確認する
- 再処理、データ修正、iFlow修正のいずれかを判断する
- 対応結果と再発防止策を記録する
最初に見つかったエラーが根本原因とは限りません。たとえば、接続先停止によって複数のiFlowが同時に失敗している場合、個別メッセージを順に再処理するより、接続先の復旧確認を優先します。
障害記録には、発生時刻、検知時刻、影響件数、原因、実施した操作、再処理件数、業務確認結果を残します。再発防止では、通知条件の追加だけでなく、タイムアウト値、リトライ方針、入力検証、エラー通知の宛先も見直します。
監視運用を安定させるチェックリスト
定期点検では、次の項目を確認します。
- 重要iFlowの失敗メッセージが未処理のまま残っていない
- 失敗原因が接続、認証、データ、業務の分類に整理されている
- 再処理前に受信側の処理済み状態を確認している
- 例外処理サブプロセスが必要な情報を記録している
- アラートの宛先とオンコール担当者が最新である
- 証明書、認証アーティファクト、接続先の変更が記録されている
- iFlow変更後に正常系と異常系のテストを実施している
- 手動再処理の権限と承認手順が明確である
SAP CPIの監視では、画面を常時開いて件数を見るだけでなく、失敗を分類し、再処理の安全性を判断し、業務結果まで確認する運用が必要です。iFlow、アダプター、マッピング、例外処理を一つの運用単位として管理すると、原因調査と復旧を安定させられます。
関連する連携全体の位置づけは、SAP連携（PI・PO・CPI）の全体像 で確認できます。IDoc連携を監視する場合は、SAP CPIのIDoc連携基礎 と合わせて、送信元・CPI・受信先の三つのログを対応付けてください。