この記事を読むメリット
- iDoc(Intermediate Document)の構造とそれを支えるテーブルの役割を体系的に理解できます。
- 実務でよく使う主要テーブル(EDIDC、EDID4、EDIDS)の使いどころがわかるようになり、iDocの流れをテーブルベースで追跡するスキルが身につきます。
- トラブルシューティングや開発時に必要な周辺テーブルについても把握でき、モニタやカスタマイズとの関連も含めて総合的に学ぶことができます。
SAPにおけるデータ連携の中核を担う技術のひとつが「iDoc(Intermediate Document)」です。特に、システム間の連携(ALE)、外部システムとのEDI通信など、幅広い場面で利用されます。
iDocは単なるデータ形式ではなく、「データ本体(セグメント)」と「制御情報(コントロールデータ)」「ステータス情報」などを含む複合的な構造を持ち、その内容は複数のテーブルに格納されています。
この記事では、iDocを構成する代表的なテーブル(EDIDC、EDID4、EDIDS)を中心に、iDoc連携時に必要となるカスタマイズ情報を含むテーブルまでを網羅的に解説します。それでは、さっそく解説していきます!
iDocの概要やカスタマイズ、データ確認方法については下記の記事が参考になるぞい!
あわせて読みたい
【SAP基礎】iDocについての解説
この記事を読むメリット iDocの構造、設定内容および確認方法を理解することができます。 iDocを使用したALEやEDIについて理解を深めることができます。 SAPのデータ連…
この記事のポイント
iDocのテーブル関連図
iDocデータは、コントロールレコードとデータレコードとステータスレコードの大きく3つに分かれています。
iDocデータのテーブル関連図
テーブル一覧・概要
まずは、iDocデータの格納時に使用されている代表的な5つのテーブルを紹介します。
| テーブルID | テーブル内容 |
|---|
| EDIDC | iDocのヘッダ情報。送受信先、メッセージタイプ、ポートなど |
| EDID4 | iDoc本体。セグメント単位のデータ構造 |
| EDIDS | iDocの処理ステータス。成功・失敗ログ等 |
iDocデータのテーブル
補足として、iDocのデータ連携時に必要なカスタマイズの設定値が格納されるテーブルを紹介します。
| テーブルID | テーブル内容 |
|---|
| EDIMSG | メッセージタイプの定義情報 |
| EDIPORT | ポートの定義(T-CODE:WE21の設定に対応) |
| EDIPARTN | パートナー定義(WE20に対応) |
| TBDLS | 論理システム定義(T-CODE:BD54に対応) |
| EDPP1 | パートナープロファイルの定義(T-CODE:WE20に対応) |
| EDISG | セグメント定義 |
| EDISEG | セグメントのフィールド定義 |
| TEDS1 | ステータス定義 |
iDocのカスタマイズのテーブル
各テーブル解説
ここでは、iDocデータの照会画面ととテーブル検索例を紹介します。
テーブルの検索はT-CODE:SE16Nを使用しています。
T-CODE:WE02のiDoc一覧照会画面とそれぞれのテーブルを比較しながら見ていくぞい!
EDIDC(コントロールレコード)
iDoc全体の制御情報を格納するテーブルです。項目:DOCNUM(iDoc番号)を主キーとし、送信者・受信者・メッセージタイプ・ポート・全体のステータスなど、iDocの基本的な属性を管理します。
モニタリング時(T-CODE:WE02、BD87など)に最初に参照される非常に重要なテーブルです。
T-CODE:WE02で見るときは、左側に表示されているナビゲーションウィンドウの「制御レコード」をダブルクリックすると詳細が確認できます。
接続が上手くいかない場合、ここからPort番号や基本タイプなどの設定を確認し、カスタマイズが適切に行われているかを調べることができます。この接続部分の検証をする際は、T-CODE:WE19の疎通テスト用のトランザクションコードを使用することもおすすめです。
iDocのコントロールレコード
EDID4(データレコード)
iDocの本体にあたるデータを格納するテーブルです。各セグメント(Z1E1KNA1、E1EDK01など)ごとに1レコードが格納され、フィールド内容はSDATAフィールド(1000文字)にバイナリ形式で保存されます。下記画像のように、セグメント(親)の配下にさらにセグメント(子)を作る場合は、データベース上、セグメント(子)の1レコードが作成され、項目:番号で親-子のリレーションを作っています。
旧形式ではEDID2/EDID3が使われていましたが、現在はEDID4が標準です。
アプリケーションデータが格納されているテーブルであり、iDocで連携したいデータに不足がある場合は、まずこのデータレコードを確認し、目的のデータが入っているかを確認します。なお、T-CODE:WE02のナビゲーションウィンドウにおいて、問題があるセグメントは文字の色が青色ではなく、黄土色になることでErrorを識別してくれます。
iDocのデータスレコード
EDIDS(ステータスレコード)
iDocの処理ステータスが格納されます。送信/受信に関する成功・失敗・再処理といった情報が、時系列で管理され、トラブルシューティング時に必須の情報源となります。
複数のエラーがある場合は、複数レコードが生成され、個別にステータスメッセージを確認することができます。テーブル上は、テキストデータとパラメータが項目として分かれていることも特徴です。
ステータス番号(01, 03, 51など)で処理状況が判断でき、ステータス番号の定義はテーブル:TEDS1で管理されています。
iDocのステータスレコード
まとめ
iDocはその構造上、単一のテーブルでは完結せず、複数のテーブルが連携することで一連の通信・処理を実現しています。
EDIDC、EDID4、EDIDSは最重要テーブルとして抑え、それを支えるEDIPORT、EDIPARTN、TBDLSなどの周辺テーブルも合わせて理解することで、より確実な運用・開発が可能になります。
SAPでのiDoc連携は、正確な設計とトラブル時の素早い調査が求められます。この記事を参考に、テーブル構造への理解を深め、実務での生産性向上につなげていただければ幸いです。