BC620
R/3 System Release 46B 25.06.2002
Business Integration Technologies II...3 Course Prerequisites...4 Target Group...5 Course Overview...1 Course Goals...2 Course Objective(s)...3 Course Content...4
Course Overview Diagram...5
Main Business Scenario...6
Basic Principles...1
Topic Objectives...2
IDoc Concept...3
IDoc Applications...4
EDI and ALE...5
Process Flow: Sending Data...6
IDoc Settings: Sending Data...7
Process Flow: Receiving Data...8
IDoc Settings: Receiving Data...9
Basic Principles: Summary...10
IDocs in Business Processes...1
IDocs in Business Processes: Course Objectives...2
Business scenario...3
IDoc Record Types...4
Control record...5
Data Records and Segment Structures...6
Status Record...7
IDoc Record Types: Summary...8
IDoc Types...9
Outbound and Inbound Processing...10
Outbound Processing using Message Control...11
Direct Outbound Processing using ALE...12
Output in Various Formats II...7
Documentation Tools: Summary...8
Documentation Tools Exercise...9
Port Definition...1
Port Definition: Unit Objectives...2
Overview Diagram (Sending Data)...3
Port Definition: Business Scenario...4
IDoc Interface: Port Types...5
Port Definition: Port Type ...6
Process Flow: Port Type File (with Triggering)...7
Port Type XML: Flat File and XML File...8
Port Type XML: Flat File and XML File (2)...9
Port Definition - Port Type tRFC...10
Process Flow: Port Type tRFC...11
Port Definition: CPI-C (R/2 System)...12
Process Flow: Port Type CPI-C...13
Port Definition: Internet...14
Process Flow: Port Type Internet...15
Port Definition: PI...16
Process Flow: Port Type PI...17
Communication with Older Releases...18
Port Definition: Summary...19
Port Definition Exercise...20
Partner Profiles...1
Partner Profiles: Unit Objectives...2
Overview Diagram (Sending Data)...3
Partner Profiles: Business Scenario...4
Partner Profiles: Fields...5
Checking Partner Profiles...6
Partner Profiles: Outbound Processing I...7
Partner Profiles: Outbound Processing II...8
Partner Profiles: Inbound Processing...9
Process Codes I...10
Process Codes II...11
Process Codes III...12
Outbound Modes: Port Type File...13
Partner Profiles Output...14
Partner Profiles: Summary...15
Partner Profiles Exercise...16
Test Tool Exercise...4
Message Control and IDocs...1
Message Control and IDocs: Unit Objectives...2
Business Scenario...3
Outbound Processing using Message Control...4
Message Control...5
Condition Elements...6
Message Processing: IDocs...7
Dispatch Times in Outb. Procg using MC...8
Summary...9
Message Control and IDocs Exercise...10
Message Control and IDocs: Solution...11
General Settings...1
General Settings: Unit Objectives...2
Customizing using the IMG...3
Number Ranges...4
Event-Receiver Linkage...5
IDoc Administration: Global Parameters...6
IDoc Administration: User Parameters...7
Fast entry...8
Long Names - Short Names...9
General Settings: Summary...10
General Settings Exercise...11
Additional Test Programs...1
Processing Tests: Unit Objectives...2
Processing Tests: Business Scenario...3
Test Layers: Overview...4
Test Layers: Outbound Processing...5
Test Layers: Inbound Processing...6
Test Layers: Status Confirmation...7
When to Test Which Function?...8
Statistics and Monitoring: Unit Objectives...2
Business Scenario...3
Monitoring Programs: Overview...4
Selection Fields for Monitoring...5
Implementing Functions...6
Status Group: Monitor/Statistics...7
Work Item Analysis...8
Statistics and Monitoring: Summary...9
Statistics and Monitoring Exercise...10
Statistics and Monitoring: Solution...12
Workflow and IDocs...1
Workflow and IDocs: Unit Objectives...2
Workflow and IDocs: Business Scenario...3
Inbound Processing with Workflow...4
Exception Handling with Workflow...5
Exceptions in Outbound Processing...6
Exceptions in Inbound Processing...7
Notification Concept I...8
Notification Concept II...9
Notification Concept III...10
Maintaining an Organizational Structure...11
Integrated Inbox...12
Workflow and IDocs: Summary...13
Workflow and IDocs Exercise...14
Using an EDI Subsystem...1
Using an EDI Subsystem: Unit Objectives...2
Overview Diagram (Receiving Data)...3
Business Scenario...4
EDI Subsystem: Responsibilities...5
Required Fields in IDoc Inb. Processing: Control Record...6
More Documentation...7
Using an EDI Subsystem: Summary...8
Using an EDI Subsystem Exercise...9
Archiving...1
Archiving: Unit Objectives...2
Overview Diagram (Sending Data)...3
Archiving: Business Scenario...4
Archiving Object: IDOC...5
Status Transfers in Outbound Processing...6
Course Summary...11 Appendix...1 Appendix...2
SAP AG 1999
BC620 - SAP IDoc Interface (Technology)
SAP AG
BC620
BC620
SAP IDoc
Interface
(Technology)
SAP IDoc
Interface
(Technology)
Release: 4.6A Status: January 2000 Mat. No.: 5003 4022SAP AG 2001
Copyright 2001 SAP AG. All rights reserved.
Neither this training manual nor any part thereof may
be copied or reproduced in any form or by any means,
or translated into another language, without the prior
consent of SAP AG. The information contained in this
document is subject to change and supplement without prior
notice.
All rights reserved.
Copyright
Trademarks:
Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®,
Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ® are registered trademarks of Microsoft Corporation.
Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation. Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.
ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.
TouchSend Index ® is a registered trademark of TouchSend Corporation. Visio ® is a registered trademark of Visio Corporation.
IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation. Indeo ® is a registered trademark of Intel Corporation.
Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape
Communications, Inc.
SAP AG 1999
Business Integration Technologies II
Business Integration Technology
BC095 3 days
Level 2
Level 3
Building Enterprise Solutions with SAP Components
CA150 2 days
Data Transfer
BC420 5 days
Programming with BAPIs in Visual Basic
CA925 5 days
R/3 Interface and BAPI Programming in C++ CA927 5 days Application Link Enabling (ALE) Technology BC619 3 days EDI Interface CA210 4 days Interface Programming Data Exchange Communication Interfaces in ABAP BC415 2 days Programming with BAPIs in JAVA CA926 5 days SAP IDoc Interface -Development
BC621 1 day SAP IDoc Interface
Technology
SAP AG 1999
Recommended:
Basic knowledge of the R/3 System, as gained from
courses SAP20 and SAP50, for example
SAP AG 1999
Participants:
Consultants Administrators Project team members
Duration: 2 days
Target Group
SAP AG 1999
Course Overview
Course Goals
Course Objective(s)
Course Content
Course Overview Diagram
Main Business Scenario
SAP AG 1999
Understand the possibilities offered by the
IDoc Interface for electronic data transfer
Use the IDoc Interface
Course Goals
This course will enable you to:
SAP AG 1999
Course Objective(s)
Configure the IDoc Interface
Trace the processing of IDocs in the
system
Select and use the correct IDoc types for
your business processes
At the conclusion of this course, you will be
able to:
SAP AG 1999
Course Content
Unit 9 General Settings Unit 10 Further Test Programs Unit 11 A Process Chain
Unit 12 Statistics and Monitoring Unit 13 Workflows and IDocs Unit 14 Using an EDI Subsystem Unit 15 Archiving
Unit 1 Course Overview Unit 2 Basic Principles
Unit 3 IDocs in Business Process Unit 4 Documentation Tools Unit 5 Port Definition
Unit 6 Partner Profiles Unit 7 The Test Tool Unit 8 MC and IDocs
Preface and Introduction
Exercises Solutions Appendix
SAP AG 1999
External System External System
Course Overview Diagram
Data flow A Process Chain Test, monitoring Message Control, Workflow Archive IDoc? Archive IDoc? EDI Subsystem? EDI Subsystem? Partner Profiles Partner Profiles Port Definition Port Definition Documentation Tools Documentation Tools IDocs in Business Processes R/3 System
The units can be divided as follows:
Units which describe how to configure the IDoc Interface
Units which describe the data flow in the R/3 System and between R/3 Systems and external systems
The unit "Test" describes an important step in the process of configuring the IDoc Interface. The
emphasis is placed on the implementation of the test programs in the data flow.
The unit "General Settings" describes Customizing activities which, for example, create templates
for configuring the IDoc Interface. You should therefore consider this chapter to be more advanced than the other "configuration chapters".
SAP AG 1999
Main Business Scenario
Message IDoc IDoc QuickDeliver SmartMart
SAP R/3 System
SAP R/3 System
EDI Subsystem
EDI Subsystem
EDI Subsystem
EDI Subsystem
SAP R/3 System
SAP R/3 System
In order to reduce costs, the company SmartMart wishes to send purchase orders to QuickDeliver via
EDI. QuickDeliver wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems and must configure their IDoc Interface accordingly. The IDocs are to be
translated into another EDI standard form.
SAP AG 1999
Basic Principles
IDoc concept and fundamental terms
Data flow and process flows when using the IDoc Interface
Contents:
SAP AG 1999
Explain the terms IDoc, EDI and ALE
Identify the basic steps in IDoc processing
Topic Objectives
At the conclusion of this unit, you will be able to:
SAP AG 1999
IDoc Concept
Message-oriented AsynchronousSystem 1
DocumentSystem 2
IDoc
Document IDoc is an SAP standard format for data transfer between systems. IDoc stands for Intermediate
Document. It is intermediate in two respects:
Message-oriented - Data is also stored in applications, only in other formats (the application
documents). The IDoc communicates between these application documents, as the language spoken by both applications. It is not important whether the application is programmed by SAP or by another third-party system.
Asynchronous - Data can be stored in IDocs before an application document is created. This is
important, for instance, when incorrect data is transferred: In this case, the application document is only created when the data is corrected.
The IDoc Interface is available in the R/3 System from Release 2.1A onwards and in the R/2 System
SAP AG 1999
IDoc Applications
Workflow
Workflow
Business
Business
Connector
Connector
Electronic
Electronic
Form
Form
ALE
ALE
EDI
EDI
Subsystem
Subsystem
R/3 System
R/3 System
R/2 System
R/2 System
Other
Other
Systems...
Systems...
Internet
Internet
Intranet
Intranet
IDoc
IDoc
Examples of systems or applications which use IDocs:
ALE: Application Link Enabling EDI: Electronic Data Interchange
Business Connector: Sending business documents using the Internet
SAP AG 1999
EDI and ALE
Document IDoc Message IDoc IDoc
SAP R/3 System
SAP R/3 System
EDI Subsystem
EDI Subsystem
EDI Subsystem
EDI Subsystem
SAP R/3 System
SAP R/3 System
Two special IDoc application areas should be defined:
EDI: Electronic data interchange between different companies
ALE: Electronic data interchange between different systems within one company
Systems can exchange IDocs either directly (for example R/3 with R/3) or have them translated into
other standards (for example UN/EDIFACT or ANSI X.12) by EDI subsystems.
The application which uses IDocs (for EDI or ALE) must be able to write data to IDocs, or read data
from IDocs, or both.
The IDoc format is valid as an EDI standard when used for EDI. However, translating IDocs into
other standards has the advantage of allowing communication with more partners.
Within the R/3 System, only IDoc formats are used. All translations into other EDI Standards are
performed by an EDI subsystem. The advantage is that SAP applications only have to recognize the IDoc format - not several EDI standards - and are therefore easier to maintain. The disadvantage is that SAP do not supply an EDI subsystem and customers must purchase such a subsystem when other EDI standards are to be used.
SAP AG 1999
Process Flow: Sending Data
Check partner, find port
Transfer data, process further Post document Generate IDoc R/3 System R/3 System External system External system
In the following examples, data flow is always seen from the point of view of the R/3 System.
Therefore, if data is sent via IDocs from an R/3 System to an external system, the process is called outbound processing or simply outbound.
Outbound processing includes:
Posting the application document
Generating the corresponding outbound IDoc Finding the partner and the port
Transfer of the IDoc to the external System via the port
SAP AG 1999
IDoc Settings: Sending Data
Post document
Generate IDoc
Check partner, find port
Transfer data, process further Archive IDoc ? Archive IDoc ? EDI Subsystem ? EDI Subsystem ? Partner Profiles Partner Profiles Port Definition Port Definition Documentation Tools Documentation Tools R/3 System R/3 System External System External System
SmartMart must configure the IDoc Interface for outbound processing:
SmartMart defines the system which will receive IDocs and the technical parameters via the port
definition.
SmartMart defines QuickDeliver as a partner for message type ORDERS in the partner profiles
and enters the port which has already been defined.
Outbound IDocs created in the R/3 System should be archived by SmartMart and then deleted. The documentation tools inform the EDI Subsystem which IDoc types are to be recognized.
SAP AG 1999
Process Flow: Receiving Data
Error handling
ok?
ok?
No
No
Check port & partner, Generate IDoc Send data to R/3 System transfer Post document R/3 System R/3 System External System External System
Receiving data from an external system and the subsequent processing in the R/3 System is called
inbound processing or also inbound.
Inbound processing includes:
Receiving IDoc data from an external system via an inbound port Creating the inbound IDoc
Finding the correct processing type via the partner profiles Creating the application document
If an error occurs, error handling (more general: exception handling) is triggered. Exception
handling is a different kind of processing and is not part of inbound processing. There is also exception handling for outbound processing but it is less important: For outbound processing you should usually presume that the data being sent is correct.
SAP AG 1999
IDoc Settings: Receiving Data
Error handling
Send data to R/3 System
Check port & partner, generate IDoc Post document Port Definition, Partner Profiles Port Definition, Partner Profiles Archive IDoc ? Archive IDoc ? Documentation Tools Documentation Tools EDI Subsystem ? EDI Subsystem ? R/3 System R/3 System External System External System
QuickDeliver must configure the IDoc Interface for inbound processing:
The documentation tools inform the EDI Subsystem which IDoc types are to be recognized. The port name must be maintained in the port definition before IDocs can be accepted by the R/3
System.
In the partner profiles, QuickDeliver enters SmartMart as a partner for inbound processing and the
message type ORDERS. In addition, agents responsible for error processing are entered here, specifically for partners and messages.
Like SmartMart, QuickDeliver wishes to archive and subsequently delete inbound IDocs which have
SAP AG 1999
IDoc is an SAP standard for data transfer between
systems.
Known implementation areas for IDocs: ALE and
EDI scenarios
The IDoc Interface facilitates both IDoc processing
and flexible error/exception handling
Basic Principles: Summary
SAP AG 1999
IDoc Record Types
IDoc and IDoc type
IDoc processing: Inbound and outbound
processing
SAP AG 1999
At the conclusion of this unit, you will be able to:
IDocs in Business Processes:Course Objectives
Explain the difference between IDocs and
IDoc types
Describe the structure of an IDoc
Determine where in the business process or
the process chain the IDoc was created
SAP AG 1999
Business scenario
As a member of the implementation team for
your company (SmartMart or QuickDeliver), you
are responsible for configuring the IDoc
Interface. You must therefore understand the
basic principles behind the interface: the IDoc
format and how to embed the interface in both
outbound processing (SmartMart) and inbound
processing (QuickDeliver).
SAP AG 1999
IDoc Record Types
Status records Data records Control record
Each IDoc in the SAP database consists of:
One control record
Data records which store the application data in segments and describe the hierarchy of these segments.
Status records which determine the defined processing steps for the IDoc. As a result, the number of status records for an IDoc increases as processing continues.
An IDoc for transmission to or from an external system, however, only consists of:
One control record The data records
If the external system is to inform the R/3 System of the progress of the IDocs which were sent, a
status confirmation message is sent. The R/3 System then appends the status records which were received to the corresponding outbound IDoc in the database. The R/3 System can also send status confirmation messages for IDocs. However, this is only possible via the special IDoc type
SYSTAT01, that is, no control records or data records are sent in this case. The status information is therefore located in the data records for each IDoc!
Summary: IDocs which are transmitted between two different systems are always 'smaller' than the
IDocs in the R/3 System because they do not contain status records.
SAP AG 1999
Control record
Control record IDoc ID
Partner
IDoc type and logical message External structure
An important part of the control record is the IDoc ID, a 16-digit number which is assigned
automatically by the system. This number is used as a unique identifier for the IDoc in the R/3 System. Status confirmations also refer to this number.
The control record also contains the key fields for partner profiles: Partner and logical message (3
fields each), as well as a flag indicating whether it involves a test partner. For inbound IDocs, these key fields determine the dependent parameters of the inbound partner profile, for example, how inbound IDocs should be processed in the R/3 System.
The three key fields for the partner (recipient) are:
Partner number (internal number from master data in the R/3 System) Partner type (customer, vendor or logical system in ALE scenarios)
Partner function (important in outbound processing using Message Control, otherwise optional)
The three fields for logical messages are:
Message type (corresponds to UN/EDIFACT messages if possible) Message variant (optional)
SAP AG 1999
Data Records and Segment Structures
Data record
Control part, contains segment names
Application data Field 2
Field 1 ...
Segment
Segment names are stored in the control part of a data record. This segment is defined as a structure
in the R/3 System.
As a result of the segment name being stored in the control part, a structure is assigned to the
unstructured section of the application data by applying the "network of application fields". This always happens when an application reads data from an IDoc or when the application writes data to an IDoc.
The data type of the segment fields is character. If possible, ISO codes are used for coded fields.
SAP AG 1999
Status Record
Status Record IDoc ID
Status information
The IDoc number of the IDoc to which the status record refers is an important part of the status
record. This allows the IDoc relevant to a status conformation message to be identified in the system and the returned status records can therefore be appended.
The first status information during processing is taken from the status value or status. This is used as
a basis for the exception handling.
More detailed information can be obtained from three fields which are used to name R/3 messages in
the standard system. If an error occurs during IDoc processing in the R/3 System, a corresponding error message can be stored in the status record via the status value "incorrect". Example - message SAPE0133 ("error during RFC with port X"):
SAP: R/3 message, displayed in a standard window (field STAMQU) E0: Message class as defined in table T100 (field STAMID)
133: Message number as defined in table T100 (field STAMNO).
If the first three characters refer to an external system, special messages can be displayed for the system. However, the display must be programmed specifically and a link to the program must be included to table TEDE3.
SAP AG 1999
IDoc Record Types: Summary
Control record
Data records
IDoc ID Partner
IDoc type and logical message External structure
Control part Application data
Status records IDoc ID
Status information
SAP AG 1999
IDoc Types
Control Record
Status Records
Data records, represented as a segment tree
E1TLSUM E1HDADR E1ITSCH E1HDDOC E1ITDOC Elternsegment Kindsegment E1ITSCH C 5 E1ITDOC M 1 C 99 M 1 C 5 C 1
Each business process (for example a purchase order) usually corresponds to a certain IDoc type,
which can include the relevant data.
An IDoc type is defined by the segments, their hierarchy, sequence and frequency of use. This
information is contained in the control part of the data records.
The segment hierarchy can be represented in tree form as parent and child segments. This allows the
application data to be structured.
Summary: IDoc types are special data structures for special applications or messages. If such a
SAP AG 1999
Outbound and Inbound Processing
Outbound Processing Inbound
IDoc Interface/ALE Services
External System
SAP Application
R/3 System
Directions are always defined from R/3. Therefore, in the outbound direction, data is sent from the
application to the external system via the IDoc Interface. For the inbound direction, the opposite is true.
For inbound processing, the external system must be assigned certain authorizations. Documents
(IDocs and application documents) are to be created in the R/3 System.
Different options are available for both inbound and outbound processing. These options are
explained in the following slides.
SAP AG 1999
Outbound Processing using Message
Control
IDoc IDoc MC MC record record Document DocumentSAP Application
Message Control (MC)
External System
IDoc Interface / ALE Services
During outbound processing using Message Control, the application sends IDocs to the IDoc
Interface via Message Control. The IDocs can be processed further (for example filtered) by the ALE services, if required, before being sent to the port.
The IDoc Interface sends each IDoc to the subsequent system according to the technical port
definition. Examples of various port types:
External system = R/3 System: usually transactional RFC (standard ALE scenario) External system = EDI subsystem: Usually the file interface
SAP AG 1999
Comm. IDoc
Comm. IDoc
Comm. IDoc
Comm. IDoc Comm. IDocComm. IDoc
M as te r ID o c M as te r ID o c
Direct Outbound Processing using ALE
SAP Application
External System
IDoc Interface / ALE Services
During direct outbound processing, the ALE services are always called. These services:
Filter the IDoc: Data not required for the communication is removed from the IDoc
Change the (segment) version: if the recipient only recognizes an earlier version of the IDoc type, the version can be changed here. This means that less data is transported, as later versions of IDoc types can only contain more data than former versions and never less.
Determine the IDoc recipient using a maintained distribution model, in case the application itself did not specify the recipient.
Duplicate the IDoc, if required, for distribution models.
The ALE services create one (or more) communication IDoc(s) from one master IDoc (which is
transferred to function module MASTER_IDOC_DISTRIBUTE). Only communication IDocs are saved in the database.
SAP AG 1999
Inbound Processing using Workflow
Document Document IDoc + IDoc + process process IDoc IDoc
SAP Application
SAP Business Workflow
External System
IDoc Interface & ALE Services
The external system sends IDocs to the R/3 System. The R/3 System is addressed via the port name
SAP<SID> for example SAPC11 for an R/3 System called C11.
If the IDoc Interface recognizes the external system, the inbound IDocs are accepted and checked,
that is, a syntax check is performed and the system checks whether the sender is entered as a partner.
The IDoc is sent to the application via SAP Business Workflow according to the settings in the
partner profile.
If required, the IDoc can be processed by the ALE services before being saved in the database as an
SAP AG 1999
IDoc
IDoc
Direct Inbound Processing using ALE
IDoc
IDoc
SAP Application
External System
IDoc Interface & ALE Services
Until the partner profile settings are read, direct inbound processing works in the same way as
inbound processing via workflow:
The IDoc is passed directly to the application function module according to the partner profile
settings.
You can also set the process code (see the Partner Profiles unit) so that the ALE services are always
called during direct inbound processing. As in the case of outbound processing, these services are responsible for filtering and version changes. However, IDocs cannot be duplicated during inbound processing.
When using an ALE service, the “end result” is only ever stored in the database. This is the
application IDoc, in contrast to the inbound communication IDoc.
SAP AG 1999
IDocs in Business Processes:Summary
Each IDoc in the R/3 database consists of one control
record and several data and status records.Only
control records and data records are exchanged with
external systems.
There are various IDoc types which are distinguished
by their segments and their order. This information is
stored in the control part of the data records.
Different processing options are available for IDocs in
both inbound and outbound processing.
Data for exercises:
Training system: Will be announced by the instructor (for example
I40)
Client: 400
User: BC620-nn
Password: KURS
Ports: SUBSYSTEM of type “File” (default)
Data
Data in training system
Data in IDES
Customer side:
Material
SH-100
SH-100
Vendor
T-BILnn
1014
Purchasing organization
1000
1000
Purchasing group
001
001
Plant
1100
1100
Vendor side:
Material
SH-100
SH-100
Sold-to party
T-BIKnn
1110
Order type
TA
Sales organization
1020
1020
Distribution channel
22
22
Division
00
00
Delivering plant
1100
1100
nn is your group number
Explain terms
Define IDoc structure
1.1 True or false:
1.1.1 IDocs are always used for process chains.
1.1.2 IDocs are intermediate documents: When the application documents have
been created, the IDocs are deleted from the R/3 System.
1.1.3 IDoc types describe how IDocs are structured.
1.1.4 There are basic rules for IDoc structures.
1.1.5 The differences between IDoc types involve more than the segments which
they contain.
1.2 True or false:
1.2.1 In outbound processing, IDocs are always generated by the IDoc Interface
or by the application.
1.2.2 In inbound processing, IDocs are always generated by the IDoc Interface.
1.2.3 Exception handling via workflow is not possible in outbound processing.
1.2.4 An external system has its own formats for IDoc data. There are therefore
Unit: IDocs in Business Processes
1.1 True or false:
1.1.1 IDocs are always used for process chains.
false: Process chains can also be used within the R/3 System (for example
workflow) and can therefore be used without IDocs.
1.12
IDocs are intermediate documents: When the application documents have
been created, the IDocs are deleted from the R/3 System.
false: IDocs can only be deleted from the system when they have been
archived. The phrase “intermediate document” does not refer to the "life
expectancy" of an IDoc.
1.1.3 IDoc types describe how IDocs are structured.
true
1.1.4 There are basic rules for IDoc structures.
true
1.1.5 The differences between IDoc types involve more than the segments
which they contain.
false: IDoc types are only defined by their segments. IDocs, however, can
be distinguished by the IDoc type and their contents.
1.2 True or false:
1.2.1 In outbound processing, IDocs are always generated by the IDoc Interface
or by the application.
true
1.2.2 In inbound processing, IDocs are always generated by the IDoc Interface.
true
1.2.3 Exception handling via workflow is not possible in outbound processing.
false: Exception handling exists for processing errors or syntax errors
when dealing with both inbound and outbound processing.
1.2.4 An external system has its own formats for IDoc data. There are therefore
no IDocs in the external system.
false: The IDoc format must at least be recognized by the external system.
In addition, "external systems" can be R/3 Systems or R/2 Systems, in
which case IDocs are always stored in the system.
SAP AG 1999
Documentation Tools
Record types, IDoc types, segments
Output formats
SAP AG 1999
Use the documentation tools
Decide in which situations they would be useful
At the conclusion of this unit, you will be able to:
Documentation Tools: Unit Objectives
SAP AG 1999
Overview Diagram (Sending Data)
R/3 SystemR/3 System
Post document
Generate IDoc
Check partner, find port
Transfer data, process further Archive IDoc ? Archive IDoc ? EDI Subsystem ? EDI Subsystem ?
Documentation
Tools
Documentation
Tools
Partner Profiles Partner Profiles Port Definition Port Definition External System External System SmartMart must configure the IDoc Interface for outbound processing:
Using the documentation tools, SmartMart sends information about the structure of IDoc Type
SAP AG 1999
Business scenario
As a member of the implementation team for your
company (SmartMart or QuickDeliver), you are
responsible for configuring the IDoc Interface.
Your EDI subsystem does not yet know the structure
of the IDoc type to be used. The IDoc Interface can
export IDoc type structures in various formats, using
the documentation tools. You must know about this
function, as you can save yourself a lot of
programming work in the EDI subsystem.
SAP AG 1999 R el ea s e 3 .0
Internal and External Structures
Field 1 Field 2
Field 1 Field 2 Field 3 Field 4
Segment
internal external E1...
E2...001
IDoc types are distinguished by their segments, that is the structure or raster laid upon the data part
of the data record. These Segments exist in both internal and external form:
Internally as a release-independent structure (SAP names begin with E1), containing all the defined segment fields.
Externally as a release-dependent structure (SAP names begin with E2), containing only the segment fields defined for the specified release in the partner profile.
In addition to the segments, there are also IDoc record types, in both internal (in the R/3 database)
and external (as structures sent to the external system) forms. Both have changed in different R/3 Releases. The documentation tools only export the external structures in this case.
As a result, when running the documentation tools, you have to enter the following parameters:
The version of the external record types (as entered in the port definition) The release of the external segment (as entered in the partner profiles)
The default values are the current release number and the relevant status record version. If you
SAP AG 1999
Output in Various Formats I
?
? ?
?
IDoc types, segments and record types can be displayed in user-friendly formats which can be read
by other systems. The following display options are available:
R/3 tree display: In the case of general record types, the "tree" has only one level because the hierarchy only exists for segments and therefore for special IDoc types.
HTML file In the IDoc administration user parameters you can set whether an external browser is to be started or whether the SAP internal HTML control should be used.
The documentation goes beyond the structure: It also relates to the data elements behind the segment
structure fields. The documentation tools can also provide information about using individual IDoc types.
SAP AG 1999
Output in Various Formats II
Begin … End
typedef struct z2incodx000
…
z2incodx000
?
? ?
?
XML
Machine-readable formats are:
A simple chain of begin..end declarations which can be read by a parser C-Header
Meta-IDoc, type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types) Meta data for IDoc types in XML format
You start the documentation tools from the initial node of the IDoc Interface from the
SAP AG 1999
Documentation Tools: Summary
The documentation tools describe both the
structure and the use of different IDocs.
The structure is in the structure information.
External structures are always documented,
specifically regarding how they are exchanged
with external systems.
The output formats can be read by external
systems, so that non-R/3 Systems can quickly
recognize the IDoc structure.
Unit: Documentation Tools
Topic: Output formats
At the conclusion of these exercises, you will have:
•
Learned about different output formats
As a member of the EDI project team for your company, you require
information on IDoc type ORDERS01 for two reasons:
To prepare for a project discussion about “purchase order/order via EDI”.
To inform your EDI subsystem provider of this data structure.
1-1
Select Documentation →
IDoc types from the initial node of the IDoc interface. As you
wish to use the standard and have not yet extended any IDoc types, enter the IDoc type
ORDERS01 and then select Basic type in the Development object frame.
1-2
You wish to receive all the information on the IDoc type. By selecting Goto →
User
settings, you can check that all the display attributes are activated. Save your entries
and return to the initial screen.
1-3
When preparing for the discussion, you opt for the output format HTML page due to
the convenient navigation options. Three files are generated on your PC. If you have
not changed any of the settings, these files are ORDERS01_F.HTM,
ORDERS01_I.HTM and ORDERS01_D.HTM. File ORDERS01_F.HTM can be
opened via Internet Explorer.
SAP AG 1999
Port Definition
Port types and when they are used
Port definition parameters
Communication with Older Releases
SAP AG 1999
Decide which port types should be implemented
for which external systems
Enter a port definition in the R/3 System
Determine which additional steps are required for
linking to the relevant external system
Enter special settings which are required for
communication with older R/3 releases and R/2
Systems
At the conclusion of this unit, you will be able to:
Port Definition: Unit Objectives
SAP AG 1999
Overview Diagram (Sending Data)
R/3 System
R/3 System
Post document
Generate IDoc
Check partner, find port
Transfer data, process further Archive IDoc ? Archive IDoc ? EDI Subsystem ? EDI Subsystem ? Documentation Tools Documentation Tools Partner Profiles Partner Profiles
Port Definition
Port Definition
External System External System The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver
wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems and must configure their IDoc Interface accordingly.
SmartMart must configure the IDoc Interface for sending data (outbound processing or simply outbound):
SmartMart defines the system which will receive IDocs and the technical parameters via the port
definition.
SAP AG 1999
Port Definition: Business Scenario
As a member of the implementation team for
SmartMart, you are responsible for configuring
the IDoc Interface.
You must decide which port type is suitable for
the system of your partner company
SAP AG 1999
IDoc Interface: Port Types
IDoc Interface
CPI-C R/2 System External System File IDoc/ IDoc/ status status IDoc/ IDoc/ status status PI IDoc IDoc?
XML IDoc IDoc tRFC IDoc IDoc Internet IDoc IDoc Ports are the channels via which the IDocs are exchanged. The IDoc Interface supports six different
transmission methods. These are the port types:
"File": IDocs are written in files at an operating system level. The receiving system can read the files
here. The receiving system can also be started using the synchronous RFC. Besides IDocs (that is data and control records), status records can also be exchanged by file.
"XML": The IDocs are written in XML format in the files. As is the case with the port type "file",
the receiving system is started via RFC, but here status records are only transferred by means of the IDoc type SYSTAT01.
"Transactional RFC" IDocs are sent as tables. Typically here, the external system is an R/3 System
(ALE scenarios).
"CPI-C" IDocs or control records are transferred according to the CPI-C protocol, in the way it is
implemented for the IDoc Interface in the R/2 System. The external system is always an R/2 System. IDocs are always exchanged by means of the CPI-C protocol in the R/2 IDoc Interface (available from R/2 Release 5.0F). For further information see the R/2 handbook, p53.2.
"Internet": The IDocs are written in MIME format to an e-mail attachment.
"Programming Interface (PI)": IDocs are sent as tables to one of the function modules defined. You
therefore do not leave the R/3 System via a PI port. Your function module can naturally trigger or perform an external dispatch.
SAP AG 1999
Port Definition: Port Type "File"
Command file Outbound file Inbound file Status file IDoc file Status report rfcexec out.script RFC destination (TCP/IP connection)
Data for technical linking is determined in the port definition for the IDoc Interface. So that a port
can be used, settings outside of the IDoc Interface must be made.
The port definition for the port type "file" includes
Name and directory of files. Only the outbound file is important, as the place and name of the file are determined by the external system during inbound processing of IDocs or a status
confirmation. However, if you do enter a parameter for the inbound IDoc and status file, the test tool can generate default values. It is important that the port exists every time, even if it is only used in inbound processing, as the IDoc Interface only accepts ports that it recognizes.
Instead of the outbound file, you can also store a function module, which dynamically generates names and thus helps to prevent files from being over-written. You can also use logical file names: You should also see the F1 Help for the field.
Name and directory of command file that is to be called from program "rfcexec" and which should start the external system - this file must be created so that the R/3 System can start the receiving system automatically (= trigger) as soon as it has generated an IDoc file.
SAP AG 1999
Process Flow: Port Type File (with Triggering)
1
Write IDoc file4
Read2
RFC3
Call rfcexec out.script1
Write IDoc file Status report startrfc in.script status.script3
RFC2
Call4
ReadIDoc Interface
External System
IDoc outbound:In step 1, a new file is generated with the transferred IDocs by the IDoc Interface. In the second step, the program “rfcexec” (synchronous RFC) with the path to an executable program is called (here: “out.script”) and also the path to the IDoc file. “out.script” thus contains the path and name of the file as an input value. In step 3, it therefore calls the external system, which reads the file in step 4. After successful processing of the IDoc file, the external system must delete the IDoc file. The call command in “out.script” depends on the external system.
IDoc inbound:
In step 1, the external system generates an IDoc file. In step 2 it starts the R/3 System in which it executes the program "startrfc". “startrfc” receives the logon parameter and the names of the function module to be executed, the port and the path to the IDoc file. The “startrfc”command can be included in an executable program, here “in.script”. In step 4, the R/3 System started then processes the IDoc file and deletes it after successful processing. It is important that the external system logs on to an R/3 System with a user which has the corresponding authorization for creating application documents.
The status report works in exactly the same way as an inbound IDoc, except that here a status file
instead of an IDoc file is transferred.
“rfcexec” and “startrfc” are example programs for the use of the RFC library and are supplied with
this.
SAP AG 1999
Port Type XML: Flat File and XML File
EDI_DC40 004000000000030702346B 3013 ORDERS01
...
E2EDP01005 00400000000003070230000210000000200
E2EDP20 00400000000003070230000220000210323
...
E2EDPT1001 004000000000030702300002600002103BESTD
E2EDPT2001 004000000000030702300002700002604This is
The IDoc data is written in a file under the port type "XML", but in XML format. Hence the port
definition and technical structure are almost identical.
Under port type "file", no structure information at all is written in the file. The individual segments
are put in a row one after another as data records and are separated with carriage return. Thus you also speak of a "flat file".
The fields are identified by means of their position in the individual records. Such a flat file therefore
SAP AG 1999
Port Type XML: Flat File and XML File (2)
EDI_DC40 E1EDP01 E1EDP20 E1EDPT1 E1EDPT2 <EDI_DC40 SEGMENT="1"><TABNAM><![CDAT A[EDI_DC40]]></TABNAM><MANDT>004</MAN DT><DOCNUM>0000000000307023</DOCNUM> ...
<E1EDP01 SEGMENT="1"><POSEX>00010 </POS EX><ACTION>001</ACTION><PSTYP>0</PSTYP ><MENGE>23.000</MENGE>... ... <E1EDP20 SEGMENT="1"><WMENG>23.000 </W MENG><EDATU>19990622</EDATU></E1EDP2> ... <E1EDPT1 SEGMENT="1"><TDID>BEST</TDID> <TSSPRAS>D</TSSPRAS>... ... ...
<E1EDPT2 SEGMENT="1"><TDLINE>This is the purchase order text.</TDLINE>... ...
</E1EDPT1> </E1EDP01>
The segments are also written one after another in the XML file. But they are considerably different
to a flat file:
Segments are enclosed by start and end tags and therefore do not need to be separated by carriage
return. As the fields are also enclosed by tags, the segments are only ever as long as the data contained requires hence there are no "unnecessary" blank characters.
As the tags can be connected with one another in XML, you can display an XML file as a tree. The
SAP system IDoc structure therefore remains in the file received and can be displayed in any XML-compatible browser.
SAP AG 1999
Port Definition - Port Type tRFC
RFC destination (R/3 connection)
Port name (assigned automatically)
Application server for receiving system
Only the name of an existing logical RFC destination is entered in the port definition. The system
then generates a name for this port which consists of an "A" and a 9 digit number. The automatic number assignment requires a number range which is configured in IDoc Interface Customizing. There you can also set whether the numbers are to be assigned internally or by an external system.
Alternatively to port definition in the IDoc Interface, you can create tRFC ports from ALE
Customizing.
SAP AG 1999
Process Flow: Port Type tRFC
IDoc Interface
External System
RFC Interface RFC InterfaceTCP/IP
For tRFC a system calls a function module in a second system. It follows for the IDoc data exchange
that the sending system is always the active system: It calls the function module in the receiving system and transfers the IDocs as tables. The function modules are therefore inbound function modules of the respective system.
Inbound function modules in the IDoc Interface are the function modules
INBOUND_IDOC_ASYNCHRONOUS (new for Release 4.0) and INBOUND_IDOC_PROCESS (older releases). Therefore if you want to send IDocs from a 4.0 System to an older R/3 release, you must call INBOUND_IDOC_PROCESS there: This is set via the port version.
Non-R/3 Systems require the R/3 RFC library. The external RFC Interface can be generated for the
function module from the development environment (transaction SE37) (menu: Utilities -> RFC Interface -> Generate). If a non-R/3 System wants to be able to receive IDocs by tRFC, it still needs a function module that is configured like INBOUND_IDOC_ASYNCHRONOUS or
INBOUND_IDOC_PROCESS.
All IDocs transferred are saved asynchronously in the database using the single COMMIT WORK
command.
For further information see the ALE documentation (under R/3 Library->CA-Business Framework)
SAP AG 1999
Port Definition: CPI-C (R/2 System)
Host destination
RFC destination
Technical parameters Send status records? sideinfo-entry
Host on R/2 TXCOM entry
The logical destination and the host destination are determined in the port definition. The RFC
destination is created with the transaction SM59 and contains the logon data (name, password). The host destination indicates an entry in the R/3 internal table TXCOM.
The TXCOM entry refers to a gateway. The logical destination is assigned a logical unit on the R/2
side in a sideinfo-file of this gateway. The logical unit is part of the network architecture SNA and identifies computers or also programs to be started.
Besides the target system, the port definition also contains technical parameters like the buffer size
of the CPI-C data buffer or a flag showing whether the R/2 System should send a confirmation of receipt.
Note that for this port type not only the name, but rather also technical parameters are also important
for inbound processing. The reason for this is that the R/2 System is always passive, that is, the R/3 System also collects the IDocs from the R/2 System under inbound processing.
The exact functions and configuration of this port type can be found
In the R/2 manual S53.2 (IDoc Interface). Unit 8 of the manual describes in detail how the sending and receiving side of the CPI-C connection in an EDI subsystem are configured
SAP AG 1999
Process Flow: Port Type CPI-C
R/2 IDoc Interface
LU 6.2 TCP/IP2.
2. Retrieve/send IDocs or Retrieve/send IDocs or receive/send status receive/send status records records CPI-C 1. Communication structure
R/3 IDoc Interface
The R/2 System is always passive, the communication is always started from the R/3 System. The
data bindings supported are:
R/3 outbound, IDoc from R/3 to the R/2 (R/3 sends IDocs: from R/2 Rel. 5.0F, from R/3 Rel. 3.0) R/3 inbound, IDoc from R/2 to R/3 (R/3 receives IDocs: from R/2 Rel. 5.0F, from R/3 Rel. 3.1) Status report (R/3 sends exactly one status record per IDoc: from R/2 Rel. 5.0F, from R/3 Rel. 3.1) Status report (R/3 receives exactly one status record per IDoc: from R/2 Rel. 5.0H, from R/3 Rel.
3.1)
The CPI-C protocol commands are used (Common User Programming Interface). The gateway
converts the CPI commands into:
LU 6.2 protocol commands to the R/2 side (IBM mainframe) TCP/IP protocol commands to the R/3 side (client/server systems)
The IDocs are saved synchronously in the database.
SAP AG 1999
Port Definition: Internet
Internet address
Folder name for outbound IDocs Additional mail attributes
Internet destination
The most important part of the port definition is the Internet address (IP address). Together with the
IDoc it is transferred via SAPconnect to the Internet gateway (or the Microsoft Exchange server).
Furthermore, the port definition contains mail attributes:
- an explanatory text which can be read first when receiving a mail as the mail body - the title of the mail in the mail header
- the name of a folder in which IDocs to be sent can be saved in the original system for control purposes.
The general settings (IDoc Administration) contain the name of the folder where mails with the
SAP AG 1999
Process Flow: Port Type Internet
IDoc Interface
SAPoffice/SAPconnect
External System IDoc IDoc MIME e-mail For sending via the Internet, IDocs are converted to another format (SAPoffice name: R3I): a table
with 255 characters. This table is transferred by SAPconnect: To the Internet gateway (sendmail program), or
To the Microsoft Exchange server.
The gateway (or the Exchange server) converts the IDoc table into MIME format.
For inbound processing, the procedure is reversed. Internet IDocs are displayed to the relevant users
as mail attachments in SAPoffice.
To use this port type, the following parameters must be entered:
A SAPconnect node for address type INT (Internet) must be configured (for forwarding and managing Internet messages)
The user must have a SAPoffice address for address type INT to receive IDocs
The recipient of an Internet IDoc forwards this to the dummy user EDI USER (see the Help on the application in the port definition: “Configure the SAPoffice user address for the Internet”
SAP AG 1999
Port Definition: PI
Function module: Name and description
Own function module in the R/3 System
For a port of type "programming interface", only enter the name of the function module to be called
for outbound processing.
In this ABAP function module you can program any type of processing. Only the interface is
standard.
SAP AG 1999
Process Flow: Port Type PI
IDoc Interface
Own function module
IDoc
IDoc
Outbound Processing
The IDoc Interface calls the function module and transfers the IDoc control records in table format. Further processing (reading data, processing data, writing status records) is programmed by the user.
Inbound Processing
Your function module must call the SAP function module IDOC_INBOUND_ASYNCHRONOUS, which saves the IDocs in the database and triggers the event. This event asynchronously starts inbound processing.
SAP AG 1999
Communication with Older Releases
Field 1 Field 2 Field 1 Field 2 Field 2 2.1/2.2 3.0/3.1 4.X New field 3 Field 1 Field 3
Differences in IDoc record types
The IDoc record types are defined in the dictionary by their structure.
Structures have changed in different releases, with names becoming longer and new fields being
added.
Example: For R/3 Release 3.0, the partner function was included in the control record.
To be able to communicate with earlier releases, the version is specified in the port definition:
Version 1: Record types are transferred using the Releases 2.X structure Version 2: Structure of Release 3.X
Version 3: Structure of Release 4.X
For port type "tRFC", a non-R/3 System must also recognize the function module to be called, as
well as the correct record types: INBOUND_IDOC_ASYNCHRONOUS (new in Release 4.0) or INBOUND_IDOC_PROCESS (older releases).
As record types in the R/2 System always have the same structure, no version must be maintained for
SAP AG 1999
Port Definition: Summary
IDocs or status records are always exchanged with an
external system via a port.
In the port definition for the IDoc Interface, users define
the target system and the technical communication parameters. In addition, users can specify the release status for the external system via the version entry.
Additional technical settings must also be entered (also
outside R/3), before a port can be used.
There are six basic communication techniques for the
IDoc Interface, represented by the six different port types.
Unit: Port Definition
At the conclusion of these exercises, you will be able to:
•
Create a port
You are a member of the EDI project team. The decision has been made
to connect the EDI subsystem to the R/3 System via the file (port type
"File").
1-1
Create a new port: From the initial node of the IDoc Interface, select IDoc →
Port
definition, choose File a
nd select Create.
You should use the port name PORT-nn. As the first test does not involve triggering,
you only have to maintain the Outbound file tab page. Ensure that the file names can
be generated dynamically. Select the logical directory EDI_GLOBAL_PATH and a
suitable function module. Leave the Outbound file field empty.
From the Outbound file tab page, check the settings using the corresponding
pushbutton (check icon). Save your entries.
<SID> is the 3-character system ID (for example I40)
nn is the number of your group (01 to 18)
SAP AG 1999
Partner Profiles
Standard partner profiles
Checking Partner Profiles
Fast entry
SAP AG 1999
Partner Profiles: Unit Objectives
At the conclusion of this unit, you will be able to:
Explain the purpose of partner profiles and
process codes
SAP AG 1999
Overview Diagram (Sending Data)
R/3 System R/3 System
Post document
Generate IDoc
Check partner, find port
Transfer data, process further Archive IDoc ? Archive IDoc ? EDI Subsystem? EDI Subsystem? Documentation Tools Documentation Tools
Partner Profiles
Partner Profiles
Port Definition Port Definition The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver
wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems, use EDI subsystems and must configure their IDoc Interface accordingly.
SmartMart must configure the IDoc Interface for sending data (outbound processing or simply
outbound):
SmartMart defines QuickDeliver as a partner for message type ORDERS in the partner profiles and enters the port which has already been defined.
SAP AG 1999
Partner Profiles: Business Scenario
SmartMart must define QuickDeliver as a partner.
You have already configured a suitable port in the
port definition.