SAP連携（PI/PO/CPI）
SAP CPIのiFlow基礎：構成・作成・運用時の確認ポイント
SAP Integration SuiteのCloud Integrationで使うiFlowについて、送受信、処理ステップ、アダプター、マッピングの役割から、作成・テスト・運用時の確認手順までを実務向けに解説します。
SAP CPI（現在のSAP Integration Suiteに含まれるCloud Integration）で連携処理を実装するとき、中心になる成果物がiFlow（Integration Flow、統合フロー）です。iFlowは、メッセージを受け取る方法、必要な変換や処理、接続先への送信をひとまとまりに定義します。設計を読みやすく保ち、実行時の確認箇所を明確にすることが、障害対応や変更時の手戻りを減らします。
この記事では、iFlowの構成要素を整理し、作成前の設計からテスト、デプロイ後の確認までを実務の順序で説明します。連携全体の製品選択や構成を確認する場合は、SAP連携製品の概要も参照してください。
iFlowの役割と処理の流れ
iFlowは、送信元から届くメッセージを受け取り、定義された処理を実行して、送信先へ渡すための処理モデルです。一般的には、送信側のシステムが開始点となるSender、メッセージ処理を行うIntegration Process、接続先となるReceiverで構成します。どのシステムから何を受け取り、どの条件でどこへ届けるかを、フロー上で追えるようにします。
代表的な処理には、メッセージ変換、条件分岐、ヘッダーやプロパティの設定、例外処理などがあります。実際に利用できるステップは接続方式やシナリオによって異なるため、要件に対して必要な処理だけを選びます。単純な連携でも、受信、変換、送信の境界が分かる形にすると、ログを見たときに処理の進み具合を追いやすくなります。
大切なのは、iFlowを図として完成させることではなく、処理の責務と入出力を明確にすることです。受信データの形式、必須項目、変換後の形式、送信先の応答、再送の扱いを設計時に定義しておくと、実装後の確認が一貫します。
主要な構成要素
SenderとReceiverは、メッセージの入口と出口を表します。それぞれにアダプターを設定し、通信プロトコルや接続先の条件を定義します。アダプターは通信方式に応じた接続を担うため、接続先のシステム、認証、ネットワーク経路、データ形式を踏まえて選びます。アダプターの用途や特徴を比較するには、SAP CPIアダプターの種類と選び方を確認してください。
Integration Processは、受信後に実施する処理の流れを配置する領域です。メッセージの変換や分岐などを、業務上の処理順に並べます。データ形式を変える場合は、入力と出力の構造を明らかにしたうえでメッセージマッピングを組み込みます。マッピングの設計と確認は、SAP CPIのメッセージマッピング基礎で扱う観点も参考になります。
接続に使う認証情報や証明書などは、iFlowの処理ロジックから分離して管理します。接続先の資格情報をフローに直接埋め込まず、環境ごとに管理できるセキュリティ成果物や設定を使います。開発・検証・本番の各環境で参照先が適切かを、デプロイ前後に確認してください。
作成前に決める設計情報
実装を始める前に、連携仕様を短い一覧にまとめます。最低限、送信元と送信先、起動方法、通信プロトコル、認証方式、データ形式、処理頻度、想定件数、タイムアウト、エラー時の扱いを記録します。これらが未確定のままでは、アダプターや処理方式の判断が変わり、後から設計を修正する可能性が高まります。
| 確認項目 | 記録する内容 |
|---|---|
| メッセージの入口 | 呼び出し元、起動条件、要求形式 |
| 接続方式 | プロトコル、宛先、通信方向 |
| データ変換 | 入力・出力のスキーマ、項目対応、必須条件 |
| 運用条件 | 件数、頻度、タイムアウト、再送・重複の扱い |
| エラー処理 | 失敗時の応答、通知先、再処理手順 |
| 環境設定 | 接続先、認証情報、環境ごとの差分 |
また、メッセージの一意性や重複処理をどう扱うかを、送信元と送信先の仕様に沿って決めます。連携基盤の再送だけで重複を防げるとは限りません。送信側の再試行と受信側の処理結果がずれる場合を想定し、業務データのキーや送信先での重複制御も含めて確認します。
iFlowを作成して検証する手順
- 要件と入出力を固定する。 サンプルメッセージを用意し、正常系に加えて必須項目欠落、値の範囲外、文字コードや日時形式の違いなど、実際に起こり得る入力を整理します。
- フローの境界を決める。 受信、変換、分岐、送信の役割を分け、各ステップに目的が分かる名前を付けます。処理内容を一つの大きな流れに詰め込まず、後から調査する人がログと処理箇所を結び付けられる構造にします。
- アダプターと接続設定を行う。 送信側・受信側それぞれの接続方式を設定し、宛先や認証情報を環境に合わせて準備します。接続テストでは、資格情報だけでなく、ネットワーク到達性、証明書、許可された経路も確認します。
- 変換と業務ルールを実装する。 入力と出力の構造を照合し、必須項目、コード値、日時、数値形式、空値の扱いを確かめます。必要な場合はマッピング後のサンプル出力を確認し、送信先の仕様に合うことを検証します。
- 異常系を含めてテストする。 正常な応答だけでなく、送信先のエラー、タイムアウト、入力不正、認証失敗などを試します。失敗時にメッセージがどう扱われ、どこから再処理できるかを運用手順に反映します。
- 環境設定を点検してデプロイする。 接続先やセキュリティ設定が対象環境に対応していることを確認し、デプロイ後に実際のメッセージで疎通を確認します。テスト結果、変更内容、切り戻し方法も記録します。
開発用の接続情報を本番で使わないこと、テストデータに実データを不用意に含めないことも重要です。変更を反映するときは、iFlow本体だけでなく、関連するマッピングや接続設定、セキュリティ成果物がそろっているかを一括して確認します。
運用時の確認と障害切り分け
本番稼働後は、処理件数、失敗件数、処理時間、接続先の応答を継続して確認します。障害が起きたときは、まず対象メッセージと発生時刻を特定し、実行ステータス、エラー内容、処理が止まった位置を確認します。次に、原因を「受信」「認証・接続」「変換」「送信先処理」に分けると、担当チームと次の調査先を判断しやすくなります。
| 症状 | 主な確認点 | 次の確認 |
|---|---|---|
| メッセージが到着しない | 呼び出し元の送信結果、開始条件、接続先URL | 送信側ログと受信側の到達性を照合 |
| 認証・接続で失敗する | 認証情報、証明書、宛先、許可経路 | 接続設定と期限、接続先の応答を確認 |
| 変換処理で失敗する | 入力構造、必須項目、値の形式 | 失敗したメッセージの項目を仕様と比較 |
| 送信後にエラーになる | 送信先応答、タイムアウト、業務エラー | 送信先の処理結果と再送可否を確認 |
| 同じデータが複数回処理される | 送信側の再試行、応答遅延、重複制御 | 一意キーと再処理手順を照合 |
メッセージ監視では、個人情報や認証情報をログに残さない運用を徹底します。ペイロードを記録する必要がある場合は、目的、閲覧権限、保存期間、マスキング方法を明確にしてください。監視画面の見方やエラー対応を深掘りする場合は、SAP CPIのメッセージ監視とエラー対応を参照できます。
再処理は、同じメッセージを再送すれば安全とは限りません。送信先で処理が完了した後に応答だけ失われた場合、単純な再送が二重登録につながることがあります。再処理前に送信先の処理結果を確認し、重複の有無、再送可能な条件、業務担当者の承認要否を手順化します。
変更管理と保守のチェックリスト
変更のたびに、影響範囲と確認結果を追跡できるようにします。運用引き継ぎでは、フローの目的、依存する接続先、アダプター、マッピング、環境別設定、監視方法、エスカレーション先を記録してください。担当者が画面上の処理を追うだけでなく、入力から送信までの業務上の意味を理解できる資料にすると、障害の初動が安定します。
- 変更の目的と対象iFlowを記録する
- 接続先・認証情報・証明書の変更有無を確認する
- 正常系と代表的な異常系のテスト結果を保存する
- デプロイ後に件数、処理時間、エラーを確認する
- 再処理と切り戻しの判断条件を運用担当者と共有する
小さな変更でも、マッピングや接続先を変えると後続システムへの影響が生じます。テストデータと確認項目を再利用できる形で管理し、次回の変更でも同じ品質基準を適用してください。
まとめ
iFlowは、送信元から送信先までの処理を、接続とメッセージ加工を含めて定義する統合フローです。設計時に入出力、接続条件、異常時の扱いを決め、作成後は正常系・異常系の両方を試験します。運用では、実行結果から停止箇所を特定し、再処理前に送信先の処理状況を確認することが重要です。
フローを簡潔に保ち、接続設定や機密情報を適切に分離し、変更・テスト・監視の記録をそろえることで、連携処理を継続的に保守しやすくなります。