TT Lab
はじめる
学ぶ 学習パス コース

システム間連携 (EAI)

IDoc・RFC・BAPI — ERP側の人が使う言葉

TT Labで続きを見る

一言でいうと

SAP連携でまず必要なのは、ABAPの知識ではなく、用語の地図です。IDoc・RFC・BAPI・tRFC・qRFCがそれぞれ何を保証するかを知っていれば、会議で決定を下せます。

なぜこれが問題なのか

レガシー連携で、こちらが不利な立場に立つ理由は、技術が難しいからではなく、相手の言葉がわからないからです。会議で「tRFCで行くか、qRFCで行くか」をその場で判断できないと、決定が先送りされ、先送りされた決定は、たいてい相手にとって楽な側に決まったまま、こちらに通知されます。

その差が、あとでこちらの仕事になります。順序保証のない方式で合意してしまうと、同じ注文の変更電文が入れ替わって届く場合を、こちら側で取り除かなければならず、重複防止のない方式なら、冪等処理をこちらが作らなければなりません。用語を知っていることは、教養ではなく、交渉力です。

SAP連携を担当することになったら

韓国の大企業のプロジェクトで、ERPはたいていSAPで、こちらが作るシステムは、そこからデータを受け取ったり送ったりする必要があります。このとき、会議でこんな言葉が出てきます。

「それはIDocで受け取っていただければよく、リアルタイムはRFCでBAPIを呼び出していただければ大丈夫です。 tRFCで行くか、qRFCで行くかは、協議しましょう。」

何のことかわからなければ、その場で何も決められません。用語から整理しましょう。

用語 何か いつ使うか
IDoc Intermediate Document。SAPの標準の文書交換フォーマット(非同期) 大量・バッチ・EDI
RFC Remote Function Call。SAPの関数をリモート呼び出し リアルタイムの照会/処理
BAPI RFCとして公開された標準の業務関数(Business API) 標準の業務処理
tRFC transactional RFC。1回だけ実行されることを保証(重複防止) データ変更
qRFC queued RFC。tRFC+順序保証 順序が重要な変更
ALE Application Link Enabling。IDocをシステム間で配信する仕組み IDocのルーティング

覚えておくべき対比は1つです。IDoc=非同期の文書、RFC/BAPI=同期の関数呼び出し。そして、tRFC/qRFCは、「重複防止」と「順序保証」という、前のモジュールで扱ったその問題を、SAP側で解く方式です。

IDocの構造

IDoc 1つは、3つの部分でできています。

Control Record (제어 레코드)  ← 딱 1개. "이 문서가 무엇이고 어디서 어디로"
  IDOCTYP  기본 타입 (예: ORDERS05)
  MESTYP   메시지 타입 (예: ORDERS)
  SNDPRN   송신 파트너
  RCVPRN   수신 파트너
  DOCNUM   IDoc 번호
  CREDAT   생성일자

Data Records (데이터 레코드)  ← 여러 개. 세그먼트 단위
  SEGNAM   세그먼트 이름 (E1EDK01, E1EDKA1, E1EDP01 ...)
  HLEVEL   계층 레벨 (부모-자식 관계)
  SDATA    실제 데이터 — 고정길이 문자열 1000자

Status Records (상태 레코드)  ← 처리 이력
  STATUS   상태 코드 (03 전송, 51 오류, 53 성공 ...)

このコードブロックの韓国語は、次のとおりです。制御レコード(1つだけで、この文書が何で、どこからどこへ送られるかを示す)、基本タイプ・メッセージタイプ・送信パートナー・受信パートナー・IDoc番号・作成日、データレコード(複数で、セグメント単位)、セグメント名・階層レベル(親子関係)・実際のデータ(固定長の文字列1000文字)、ステータスレコード(処理履歴)、ステータスコード(03は送信、51はエラー、53は成功)です。

核心はSDATAです。セグメントの実際の値が、1000文字の固定長文字列にまるごと入っています。つまり、IDocをパースするとは、セグメント名でレイアウトを探して、SDATAを位置で切り出す作業です。

前のモジュールで行った固定長のパースと、まったく同じ作業です。そのため、IDocが難しく感じられても、実際の手はすでに身についています。

よく出会うセグメント

注文(ORDERS)系で、実際によく見るもの。

セグメント 意味 代表的なフィールド
E1EDK01 ヘッダー(文書全体) BELNR(文書番号)、CURCY(通貨)
E1EDKA1 パートナー情報 PARVW(パートナーの役割)、PARTN、NAME1
E1EDK02 参照文書 QUALF、BELNR
E1EDP01 明細 POSEX(明細番号)、MENGE(数量)、MENEE(単位)
E1EDP19 明細の参照(資材コード) QUALF、IDTNR(資材番号)

HLEVELが階層を表すので、E1EDP01の下にE1EDP19が付く構造になります。JSONに変換するときは、この階層を生かす必要があります。

IDocのステータスコード

運用でよく見るステータスだけを知っておけば十分です。

コード 意味
03 外部システムへ送信済み(アウトバウンド)
12 発送完了
51 アプリケーション文書が未作成(エラー) ← 最もよく見ます
53 アプリケーション文書の作成に成功
64 処理待ち
68 処理の取り消し(エラーを無視)

「IDocが51で落ちました」は、データは届いたが、SAPの中で業務処理が失敗したという意味です。送信の失敗ではありません。この区別ができないと、「こちらは送りましたが」と「こちらは受け取っていませんが」が平行線をたどります。

実務で設計するときに決めること

SAP連携の設計会議で、実際に決める必要がある項目です。

  1. 方向と方式: こちらが送るのか受け取るのか。IDocかRFCか
  2. 間に何があるか: 直結か、EAIハブを経由するか、PI/POを経由するか
  3. キーのマッピング: SAPの顧客番号(KUNNR)と、こちらのシステムの顧客IDをつなぐ表。 このマッピングテーブルが、連携の心臓です。なければ何もできません
  4. エラー処理: 51が出たときに、誰が見て、誰が直すのか。SAP側の担当者と協議しないと決められません
  5. 再送: 同じIDocを再度送るとどうなるか。重複文書ができるのか、無視されるのか

項目3を強調したいです。システムごとに、同じ対象を別のIDで呼びます。SAPのKUNNR=10001、営業システムのACC-00001、こちらのシステムのCUST-001。この3つをつなぐクロスリファレンス(cross-reference)テーブルがあって初めて、連携が成立します。これをそれぞれがハードコーディングで解決し始めると、6か月後には誰も手を付けられなくなります。

レガシー連携の一般原則

SAPでなくても、レガシー連携には共通の原則があります。