The IDoc Interface

- R/3, Release 4.5 -

Electronic Commerce

Document

IDoc
SAP System R/3 SAP System R/3

IDoc IDoc

Transaction
EDI Subsystem Message EDI Subsystem
IDoc Concept  Asynchronous
 Document-related

System 1 System 2

SAP
IDoc  Document
Document  Transaction
 Message

 R/3 System  EDI subsystem

 R/3 System
 R/2 System
 3rd party software
IDoc Record Types
Control Record IDoc-ID
Sender-ID
Receiver-ID
IDoc type and logical message
External structure

Data Record IDoc-ID

Sequence/Hierarchy
Segment Format definition for
• header data
• item data

Status Record IDoc-ID

Status information
IDoc Types
Control Record

Data Records

E1HDDOC E1TLSUM
M 1 C 1

E1HDADR E1ITDOC
C 5 M 1

E1ITSCH

Tree of Segments C 99 C 5

Status Records
IDoc Data Flow
Outbound Data Inbound

MM
Application SD
Application
...

Message Control Workflow

IDoc Interface & IDoc IDoc Interface &

ALE Services ALE Services

System 2 File System 2

e.g. EDI subsystem tRFC e.g. EDI subsystem
...
Outbound Data Flow
SAP application

Document

Message Control (NAST)

Document
NAST
Record

IDoc Interface & ALE Services

IDoc

System 2, e.g. EDI subsystem

Message Control

SAP Application Processing

Application data

Output Determination Message proposal

NAST-Record

Processing acc/ TNAPR

Processing Program Output, e.g. as IDoc

e.g. RSNASTED
Message Control - Call Sequence
SAP Applications
communication message
structures default

pass suggest
condition
component evaluate output relation
condition determination
tables write

message trigger and message status

process status

Message table
Control TNAPR
call

formatting program

... printout fax ALE EDI E-mail ...

Message Control - Data Set Relations
Application Data possible contents of
documents to exchange

Communication Structures KOMB

KOMKyy
possible fields and values for decision
KOMPyy

Condition Components application

...
procedure
...
message type

access sequence
...
access to condition table
Message Control - Object Relations
Catalogue of fields for key of conditions KOMB

Communication structures
Application
Application filter KOMKyy, KOMPyy
1
n

Procedure
m
n

Message type
m
1

Access sequence
m
n

Access to condition table

Message Control - EDI related
Check NAST-Reord R
S
Read Partner Profile
N
A
Call Selection Module
S
(application) T
E
Call ALE Service D

Transfer according
to output mode
„1“/„2“ „3“/„4“

Single IDoc Batch of IDocs

by RSEOUT00
Outbound Status Transitions
01 37 39 24 04

29
06 05

26

08 07
25

10 09
30

40 41 12 11

03 02

22

18 20
14 15

16 17

31
Inbound Data Flow
System 2, e.g. EDI subsystem

IDoc

IDoc Interface & ALE Services

IDoc +
Process

SAP Business Workflow IDoc +

Function Module

Document

SAP application
Inbound Status Transitions
50 56

65
Notifications
60 from the
61 EDI subsystem
prior to
64 IDoc creation,
can be received via
66
message TXTRAW.

62 63

52 51

53 68
Process Code, Port and Partner Profile

SAP Applications

Process Partner
Port
Code Profile

System 2
e.g. EDI subsystem
Partner Profile General
Partner
Receiver of notifications

Outbound Inbound

Partner
Logical message
Partner
Port Logical message
IDoc type
cond.: EDI structure Process code
NAST-Key cond.: Recv. of notifications
cond.: Recv. of notifications
Partner
Message

Process code
Logical message
IDoc Communication Channels
SAP Application

IDoc Interface & ALE Services

IDoc & IDoc &

IDoc IDoc IDoc
status status

File
tRFC CPI-C MIME ABAP
+ RFC

EDI ALE
R/2 Internet Any
Any Any
2.1 on 3.1 on 4.5 on
3.0 on 3.0 on
Triggering with Port Type „File“

IDoc Interface

Write RFC 4 3
1 2 Read RFC
rfcexec startrfc
IDoc file
IDoc file in.script
Status report
out.script status.script

Read Call 1 2
4 3 Write Call

EDI subsystem
EDI related Output Modes

Output Description
Mode

Transfer of single IDoc and start

1 of the EDI subsystem (trigger)

Transfer of single IDoc;

2 no trigger

Transfer of batch of IDocs and start

3 of the EDI subsystem (trigger)

Transfer of batch of IDocs;

4 no trigger
EDI related Priorities and Output Modes
Application Message IDoc Interface EDI subsystem
Control
Save Priority = 4 output mode = 1
Realtime

Save Priority = 1 output mode = 1

Fast batch

Save Prio = 1 output mode = 3

Batch

Save Prio = 1 mode = 4

Batch
Status via File Interface

1 Status 4
report IDoc

IDoc Interface
EDI subsystem

2 startrfc 3
startrfc.exe

IDoc
Status via IDoc Type SYSTAT01

IDoc

IDoc Interface
EDI subsystem

IDoc
Notification and Monitoring
100
80
60
40
20

 The IDoc interface offers 2 different 0

1. 2. 3. 4.
Qrtl. Qrtl. Qrtl. Qrtl.
approaches for tracking of data load
and data flow:
 Workflow for notifications
 Reports for monitoring
 Both approaches are based on the concept of status
transitions, i.e. an IDoc changes its status from a given
value to another value.
 Status transitions can be triggered by the SAP system
as well as by any subsystem, e.g. EDI subsystem.
Determination of Selected Agents

Organizational plan

Task Possible agents

Role resolution Selected agents

Partner profile Permitted agents

IDoc Interface
Determination of Permitted Agents

General Administrator
(System profile)

Determination strategy
Partner related CSR
(Partner profile w/o message)

CSR
Partner and document (Partner profile w/ message)
related
Table of Notification Tasks

Process Task Role

code resolution

EDIM TS30000020 30000001 Administrator, system profile

EDIP TS60001307 30000001 Administrator, system profile
EDIO TS00007989 00000134 CSR, partner profile
EDIX TS00008070 00000134 CSR, partner profile
EDII TS00008068 00000134 CSR, partner profile
EDIY TS00008074 00000134 CSR, partner profile

EDIS TS30000078 30000001 Administrator, system profile

RSEIDOCM TS30200108 30200013 Party from selection screen

application TSnnnnnnnn 00000134 CSR, partner profile

All application tasks can be found by the logical message as search term!
Outbound Data Flow w/ Notification Points

SAP application

Document

Message Control
EDIM Message
NAST
Record
IDoc w/
EDIX syntax error

IDoc Interface
EDIO IDoc

EDIP IDoc batch

IDoc

EDIS
EDI subsystem Status report
Customer
Inbound Data Flow w/ Notification Points
TXTRAW IDoc message

EDI subsystem

IDoc EDIM Message

IDoc Interface EDII IDoc

IDoc w/
IDoc EDIY syntax error

SAP application
IDoc w/o
Application application document
Example of an User‘s Inbox
Workitem: Error in EDI subsystem

A change of status is
triggered by an EDI
subsystem because of
translation error(s).
Someone has to take
care of the situation,
and is notified by
status processing.
Workitem: Status Transition Pending

Change of status triggered by an

EDI subsystem is pending for
more time than expected.
Someone has to take care of the
situation, and is notified by
program RSEIDOCM.
Monitoring Programs

Statistics
“RSEIDOCM”
Active monitoring
4711
4712
Lists, 4713
Find 4718

Display
Statistics - Case 1a: Outbound P.O.

Purchase orders were

created, and wait for
their transfer to an
EDI subsystem.
An administrator
monitors the process by
the statistics transaction
„WE07“.
Statistics - Case 1b: Outbound P.O.

Purchase orders
were transfered to an
EDI subsystem,
some were
confirmed to SAP.
An administrator
monitors the process
by the statistics
transaction „WE07“.
Lists - Case 2a: Outbound P.O.

Purchase orders
were created, and
wait for their
transfer to an
EDI subsystem.
An administrator
monitors the
process by the lists
transaction
„WE05“.
Lists - Case 2b: Outbound P.O.

Purchase orders were

transfered to an
EDI subsystem, some
were confirmed to
SAP.
An administrator
monitors the process
by the lists
transaction „WE05“.
Display - Case 3: Outbound P.O.
Purchase orders sent, were confirmed with
EDI references by an EDI subsystem.

An administrator accesses
the IDoc(s) by selecting
with the interchange and
message references by the
display transaction „WE02“.
Case 4: Outbound P.O., but Application !
A purchase order was created,
the IDoc(s) assigned to that
P.O. are seen from the
application.
Development of an IDoc Type

 Development of a new IDoc type,

i.e. developing „basis type“.

Typically at SAP standard development!

 Extension of an standard IDoc type,

i.e. developing „extension“.

Typically in customer project!

What Kind of Development, and When ?

 The IDoc type requested is available, and matches all

requirements:
Nothing to be done !
 The IDoc type requested is available, but does not
match in all the requirements:
Development as „extension“ !
 The IDoc type requested is not available, or matches
only in few requirements:
Development as „basis type“ !
Development Areas of an IDoc Process

Application

Function Module Business Workflow

Program Function Module

Report e ss
c
IDoc Type
P ro
ess nd
r oc b ou
P Segment
In
u nd
o
u tb
O Segment Segment
Type Name

IDoc Interface
r e
c t u
t ru
a S
a t
D
Definition (1): IDoc Type

 IDoc = Intermediate Document !

 An IDoc type is a hierarichal, complex data
structure constructed by segments, intended to
carry a complete business document.
 Formally basis types and extensions are
distinguished as IDoc types.
 The instance of such a document in „IDoc
format“ is an IDoc of a well-defined IDoc type.
Definition (2): Basis Type and Extension

Basis Type
= IDoc Type

Basis Type
+ Extension
= IDoc Type
Definition (3): Segment

 A segment comprises
 SAP release-independent segment type
 at least one SAP release-dependent segment name
 Segment types are structures in the ABAP
repository.
 All fields of a segment are of data type character
(CHAR).
Definition (4): Segment Type & Segment Name
Segment Name Version 1
E2ccccc000 e.g. 3.0A

Segment Type Segment Name Version 2

E1ccccc E2ccccc001 e.g. 3.0C

Segment Name Version 14

Segment Name e.g. 7.7x
E2ccccc013
/partner/ccccc000

Segment Type Segment Name

/partner/ccccc /partner/ccccc001

Segment Name
/partner/ccccc013
Definition (5): Release

 By releasing segments and IDoc types the data

structures of the interface are „frozen“ to
subsystems and labelled with unique names
for
 the segments, and
 the IDoc types.
 The IDoc definiton tools control the release
feature. Any ongoing development after
releasing leads to new versions of either
segments or IDoc types.
Definition (6): Version

 We distinguish versions for segments as well as

for IDoc types.
 In one SAP correction level, e.g. 4.0B, only one
current version can exist.
 A new version of the development objects
segment and IDoc type is created always, if
changes are made after releasing that object.
 Possible changes are strongly restricted to
guarantee external compatibility of the IDoc
interface.
IDoc Types - Names in ABAP Programming
Control Record, EDIDC

Data Records, EDIDD

E1HDDOC E1TLSUM
M 1 C 1

E1HDADR E1ITDOC
C 5 M 1

E1ITSCH

Tree of Segments C 99 C 5

Status Records, EDIDS

IDoc Types - Names in Subsystem
Control Record, EDI_DC40

Data Records

E2HDDOC* E2TLSUM*
M 1 C 1

E2HDADR* E2ITDOC*
C 5 M 1

E2ITSCH*

Tree of Segments C 99 C 5

Status Records, EDI_DS40

Tools to Develop an IDoc Type

Tool to define the

IDoc type with its segments

Tool to define the E1HDDOC

segment with its fields
Areas of a Customer Extension

Application  Define data structure:

In area menu „WEDI“.
Function Module Business Workflow

Program Function Module  Implement processing in

Report
outbound and inbound:
IDoc Type Project management „CMOD“.
 Publish documentation:
Segment
In area menu „WEDI“.

Segment Segment
Type Name

IDoc Interface
Advantages of Extensions

 The standard code of processing is still in

use.

 Developments and corrections of standard

code are available automatically.

 Extensions are much less effort than

developments.
Fundamental Rules for Customer Extensions

 Additional customer fields are assembled in

separate customer segments.
 Customer segments are assigned to standard
segments as child-segments.
 Processing of customer segments is
implemented in „customer-exits“.
The customer-exits are called in standard code.
Steps to Extend the Data Structure

 Identify the required fields, and their

underlying data elements in ABAP
repository.
 Define the required segments with the
„segment editor“.
 Define the „extension“ by extending a
basis type with the
„IDoc type editor“.
 Assign the logical message to the
extension via
„environment in the IDoc type editor“.
Steps to Extend the Processing

 Create project in
„project management, attributes“.
 Select the „right“ customer-exit(s) in
„project management, SAP enhancements“.
 Implement the selected customer-exit(s) in
„project management, enhancement components“.
 Outbound: Read the SAP database and format
data into IDoc format.
 Inbound: Write data from the IDoc format to the
database.
Outbound Call Sequence SAP Application

Message Control
IDoc Interface

Customer-exit 1

Customer-exit 2 Process Code

Call Function ...

Customer-exit x

IDoc Interface

EDI subsystem
Inbound Call Sequence EDI subsystem

IDoc Interface

Customer-exit 1

Customer-exit 2 Process Code

Call Function ...

Customer-exit x

SAP Application
Publish Documentation of the Extension

...
Begin typedef struct z2incodx000
… {
…
End } z2incodx000
Exercises to Extend IDoc Processing

Orders

Customer Vendor

IDoc
SAP System R/3 Orders Light SAP System R/3
Exercise 1: Start-Up

 Set-up a partner profile to send purchase orders to vendor IDOC-LI-nn. The

message control settings are EF / NEU / LF, the logical message is ORDLGT with
process code ME21-BC621-nn.
 Create a purchase order via transaction ME21, and check with one of the monitor
programs that the IDoc exists (note the IDoc‘s number).
 Set-up a partner profile to receive customer orders from customer IDOC-KU-nn.
The logical message is ORDLGT with process code VA01-BC621-nn.
 With the test tool, transaction WE19, flip-around the IDoc created in step 2. The
IDoc will serve as the customer order. Because you have changed „sites“, you
have to change the control record, so it will match with your set-up in step 3.
 Due to those exercises set-up, the inbound processing will fail, and the IDoc
reaches status „51“: Document type NB unknown.
Exercise 2: Extend Inbound (Cross Reference)

 You plan to overcome the error from exercise 1 by implementing a cross-

reference from purchasing document type NB to sales document type TA.
Hence you implement a customer-exit for the inbound processing in project
management.
 Create a project
 Select SAP enhancements; search with development class IDOCTRAINING
 Implement the exit in enhancement components
 Activate your project
 Test your exit by reprocessing the inbound IDoc from exercise 1 with the test tool,
transaction WE19.
 The IDoc now reaches status „53“: Sales document posted.
Exercise 3: Extend Outbound (Fill Field)

 The IDoc type ORDLGT01 has the field NAME (ekko-ernam in purchasing) in
segment E1HEAD, anyway the field is not populated by outbound processing.
Hence you implement a customer-exit for the outbound processing in project
management.
 Create a project
(With exercise 2 the project already exists!)
 Select SAP enhancements; search with development class IDOCTRAINING
(With exercise 2 the enhancement is already selected!)
 Implement the exit in enhancement components
 Activate your project
 Test your exit by creating a new purchase order via transaction ME21, and check
with one of the monitor programs that the IDoc exists, and the field NAME is
populated.
Exercise 4: Extend IDoc Type

 You are asked to transmit „Terms of Delivery“ with your orders documents.
Neither IDoc type ORDLGT01 nor one of its segments has fields for „Terms of
Delivery“.
 Extend the IDoc type ORDLGT01 with a 3-digit field for the code and a 28-digit
field for the description of „Terms of Delivery“ (dataelements INCO1 and INCO2).
 Create a customer segment Z1INCOnn
 Create an extension ZEXTENnn by extending IDoc type ORDLGT01
 Assign logical message ORDLGT to basis type ORDLGT01 and extension ZEXTENnn.
 The processing of that extension will be implemented in the following exercises
number 5 and 6.
Exercise 5: Extend Outbound (Fill Customer Segment)

 You are asked to send „Terms of Delivery“ with your orders documents. The IDoc
type ORDLGT01 was already extended in exercise 4. Now you have to implement
the outbound processing.
 Create a project
(With exercise 2 the project already exists!)
 Select SAP enhancements; search with development class IDOCTRAINING
(With exercise 2 the enhancement is already selected!)
 Implement the exit in enhancement components
 Activate your project
 Because of the IDoc type is maintained in the outbound partner profile, you have
to adjust the partner profile for vendor IDOC-LI-nn.
 Test your exit by creating a new purchase order via transaction ME21, and check
with one of the monitor programs that the IDoc exists, and the segment Z1INCOnn
was populated (note the IDoc‘s number).
Exercise 6: Extend Inbound (Process Customer Segment)

 You are asked to receive „Terms of Delivery“ with your orders documents. The
IDoc type ORDLGT01 was already extended in exercise 4. Now you have to
implement the inbound processing.
 Create a project
(With exercise 2 the project already exists!)
 Select SAP enhancements; search with development class IDOCTRAINING
(With exercise 2 the enhancement is already selected!)
 Implement the exit in enhancement components
 Activate your project
 Test your exit by reprocessing the inbound IDoc from exercise 5 with the test tool,
transaction WE19.
 With exercise 2 the IDoc reached status „53“: Sales document posted.
With the changes of this exercise also the „Terms of Delivery“ in the sales
document are updated.
IDoc Layers of Testing

Application

Message Control Workflow

WE15 WE19

IDoc Interface

WE14 WE16 WE17

Outbound WE12 Inbound Status

IDoc file IDoc file report
IDoc Outbound Testing
 With transaction WE15, Application
program RSNAST00
test the creation of an IDoc based on Message Control
the Message Control record.
WE15
 With transaction WE14,
program RSEOUT00 IDoc Interface
test the forwarding of an IDoc to the
receiver system, e.g. WE14

 as preparations for the inbound testing

 EDI processing with an EDI subsystem Outbound
IDoc file
IDoc Inbound Testing
 With transaction WE12, Application
test the inbound processing of an
IDoc by coping an outbound file, and Workflow
handle the copy as an inbound file.
WE19
 With transaction WE16,
test the inbound processing of an IDoc Interface
IDoc by picking up any inbound file.
 With transaction WE19, WE16

test the inbound

processing of an IDoc Outbound
IDoc file
WE12 Inbound
IDoc file
by creating the IDoc in
editor, and feed the result to the
inbound process.
IDoc Inbound Testing, WE19
IDoc Status Testing
 With transaction WE17, Application
test the processing of the status
report, and its reactions in behalf of Workflow
the status report.
 A status report can be processed
also via IDoc type „SYSTAT01", then IDoc Interface
you proceed as described in inbound
testing by WE17

 transaction WE12
 transaction WE16 Status
report
 transaction WE19
EDI Subsystem Responsibilities

EDI subsystem

partner profile translator archive

addresses message handling monitor

mappings communication
EDI Certification
 Certified process
 Purchase Order, out
 Customer order, in
Document  Order confirmation, out
 P.O. Acknowledgement, in
System R/3 System R/3
IDoc IDoc

 Certified funtionality
Status IDoc Status IDoc
 file interface w/ RFC
Subsystem Subsystem  outbound IDoc
Transaction
 status report
Transaction  inbound IDoc