Communication interfaces in

R/3:

IDOC interface

for EDI/ALE communication
R/3 component in Library and OSS: BC-SRV-EDI

Customizing tree: tcode WEDI
You require the IDoc Interface in the
following scenarios:

Electronic Data Interchange (EDI)
Application Link Enabling (ALE)
Linking to any other business application
systems (for example, PC applications,
external workflow tools) using IDoc.

EDI
EDI is a message exchanged between two
systems. The message is encapsulated inside
a structure called IDOC.
Business processes where EDI messages can
be implemented always involve two
partners:
a sender
a receiver
EDI Scenarios
MM invoice verification: a vendor sends
invoice information electronically; these info
will be processed by the logistic invoice
verification module.

In this case the message comes inside R/3:
its an INBOUND IDOC
SD order confirmation: instead of printing
and faxing or emailing to your customers an
order confirmation, you just send an
electronic message to their purchasing
system.

In this case the message goes outside R/3:
its an OUTBOUND IDOC

INBOUND IDOC
In this case we are the receiver; the MM
scenario seen before requires the following
parameters, via WE20 (partner profile):
Partner type: LI (vendor)
Partner role: LF
Message type: INVOIC
IDOC type: INVOIC01
Process code: INVM, INVL
OUTBOUND IDOC
In this case we are the sender; the SD
scenario seen before requires the following
parameters, via WE20:
Partner type: KU (customer)
Partner role: SP (sold to party)
Message type: ORDRSP
IDOC type: ORDERS04
Process code: SD10

Partner type: customer, vendor, or the
system itself
Partner role: optional. For example SP
(sold-to-party)
Message type: see table EDIMSGT for a list
of existing message types for each document
type (purchase order, MM invoice, )
IDOC type (or Basic type): the structure of
the message.
Process code:
INBOUND processing: specify whether the
message is to be processed via direct path or via
workflow.
Direct path: a function module is associated
to the process code. The electronic message
turns into an R/3 document .
Workflow: the incoming electronic message is
an event that creates a workitem, whose
associated task will turn the message into a
document.

Inbound messages: examples of
processing functions, depending on port
types:
Port type Function module
File (EDI messages) EDI_DATA_INCOMING
tRFC: INBOUND_IDOC_PROCESS
IDOC_INBOUND_ASYNCHRONOUS
IDOC_INBOUND_SYNCHRONOUS
IDOC_INBOUND_SINGLE
Process code:

OUTBOUND processing:
In the case of Outbound processing under
Message Control, the process is found
(function module of the application) using
the outbound process code. The process
reads the application data and places it in an
IDoc.

Typically when printing a document, where
the transmission medium is no longer a
printer, but an EDI (code 6): this is known as
the Message Control technique:
It requires customizing settings of course, like for
any other means of transmission, in the output
control brench of SD document tree.
Via esplicit ABAP coding using Function
Module master_idoc_distribute .
When does an electronic message leave the
system? (OUTBOUND processing).
Outbound messages: examples of
functions that create and send an
IDoc
L_IDoc_CREATE_WMTOID01 Transfer orders
L_IDoc_CREATE_WMRRID01 Release reference number
L_IDoc_CREATE_WMCAID01 TO cancellation request
L_IDoc_CREATE_WMIVID01 System inventory records
IDOC TYPE
Path: Tools -> Business Communications -> IDoc Basis ->
Development -> IDoc Types
Authorization object: S_IDOCDEFT; a possible role is
SAP_BC_SRV_EDI_DEVELOPER .
IDOC = attributes + segments
Segments are used to map the information of the R/3
document; so well have
Header data segment -> record occurancy = 1
Item data segments -> record occurancy >= 1

SEGMENTS
Naming convention: SAP segment names
start with "E1. Custom segments should
start with Z1. (message types and idoc
types will begin with Z)
Segment type: the name of a segment and is
independent from SAP release
Segment definition: is the release-specific
name of a segment. Def. = type + release
Release procedure and version creation :
One active segment definition for one version.
If a new version needs to be created the
current one must be RELEASED.
A relationship of predecessor-successor is then
established between the 2 definition.
ONCE A DEFINITION IS RELEASED IT
WILL BE NO LONGER POSSIBLE TO
CHANGE IT.
Fields definition:
The field lengths (in bytes) and any fixed values are
derived from the data elements using the domains
(with field lengths as export lengths).
Do not change the export length. Data is sent to and
from the external systems as CHARACTER fields
with this length.
However, internally (in the IDoc), the data is stored
as a field of the same type as the selected data
element (for example as an integer) with the
corresponding length. Different lengths can lead to
a loss of data (unnecessary bytes are cut off).
Data Transfer Format
Data is only passed on via the interface in CHAR format. The following table contains
the anticipated inputs for the cases which are of greatest interest.
Field Format Designation
MATNR 18 000000000012345678 numeric with leading
zeros
DATUM /UZEIT 8 YYYYMMDD / HHMMSS
Quantity fields in
general
15 13 digits, 1 dec. point and 1 sign, left-justified.
For example 302.35_________ or 302.35-
________
TEST
To start the test tool, choose SAP Menu ->
Tools -> Business Communications -> IDoc
Basis -> Test -> Test tool.
You can use a template for your test IDoc.
(F4 help for existing templates)
IDocs that were generated with the test tools
are indicated with a special status: In
inbound processing it is status 74, in
outbound processing 42.
Extending a Basic Type
Some IDoc types are supplied by SAP in the
standard system: these are the basic types
Other IDoc types are customer extensions:
In these cases, a basic type is combined with
an extension which is created by the
customer, according to certain rules. Unlike
customer extensions, these extended basic
types are upward compatible.

How to create an extension
Tools -> Business Communications -> IDoc Basis
-> Development -> IDoc types :
1. Extensions -> Create
(The name of your extension should be no more than 8 characters if
you wish to use the extension to communicate with partners who are
using SAP Releases prior to 4.0)
2. Select the basic type which is to be combined with
your extension
3. Position the cursor on the segment where you
wish to append the extension segments
Example: extension Z1ORDERS appends Z1TEST1 child
segment to E1EDP19 reference segment in ORDERS01
basic type. (The child segment can be used only once).
4. Assign Message Type Basic Type and
Extension:

4.1.Tools -> Business Communications ->
IDoc Basis -> Development -> IDoc
Type/Message .
4.2.New Entry -> Enter the basic type, its
extension and the message type to which
you are assigning this combination.
4.3.Specify the current release
5. Extending Inbound and Outbound
processes with the new fields:
most of the existing basic types has user exits that allow a
developer to insert code so as to be able to read/write the
content of the extended segments: see tcode CMOD
In both cases, the code added to a function should be as
follow:

Data: segment(27).
Segment = int_edidd-segnam.
CASE segnam.
WHEN 'E1EDP19'.
CLEAR int_edidd. "Clear work area
int_edidd-segnam = 'Z1TEST1'.
int_edidd-sdata = z1test1.
APPEND int_edidd.
ENDCASE.
Control record and Status record
An electronic message is made up of:
data containing information about the
sender and the receiver, and the direction:
control record
data mapping an R/3 document (the
segments of the idoc type)
data tracking and logging the status of the
message itself during its transmission: status
record.
ALE
EDI -> Electronic Data Interface
ALE -> Application Linking Enable

So far we applied the IDOC concept to the EDI
communication type: that means, most of all, transmitting
an R/3 document in electronic format from a system to
another.
Applying the same concept to ALE communication type,
means having the possibility of exchanging data, between
R/3 and another application or integrating business
processes between R/3 Systems and non-R/3 systems as
well as between R/3 Systems.
PORT TYPES
The most relevant and visible difference
between these two means of communication
is the means itself: the communication port,
that is the gate between SAP and a
remote system (EDI scenario) or between
SAP and another development platform
(ALE scenario).
Port type Application area

File Interface Link to most EDI
subsystems
Transactional RFC ALE distribution
scenarios
CPI-C Link to R/2 System:
Direct communication with an R/2 System (from
version 5.0F onwards) is only possible using this
port type.

XML E-commerce
Transactional RFC
To set up the communication, a series of
steps are required that you have to carry
out in Customizing for ALE (Tcode SALE).

1. Define the RFC destinations
2. Generate partner profiles
3. Partner profiles and model settings are
checked for consistency.
4. Check connections
ALE SCENARIO
OUTBOUND PROCESSING
Receiver determination
Calling the generated outbound function module
Conversion of BAPI call into IDoc
Segment filtering
Field conversion
IDoc version change
Dispatch control
IDOC DISPATCH
IDocs are sent in the communication layer
by transactional Remote Function Call
(tRFC) or by other file interfaces (for
example, EDI).
tRFC guarantees that the data is transferred
once only.
INBOUND PROCESSING
Segment filtering
Field conversion
Transfer control
Conversion of IDoc into BAPI call
BAPI function module call
Determination of IDoc status
Posting of application data and IDoc status
Error handling

XML
Definition:
The exchange of IDocs via XML files at the operating
system level. The names of XML tags refer to the IDoc
record types or IDoc segments.

Use
XML is designed to be a self-descriptive Internet-enabled
language. In contrast to HTML, tags can be defined here
and recorded in a Document Type Definition. As a result,
XML is extendible and corresponds in particular to the new
definition of IDoc types concept. IDocs in XML format can
be displayed immediately with the corresponding Internet
browser. Electronic Commerce in particular uses XML, but
classical EDI applications should also be XML compatible.
Displaying an IDoc Using an XSL
Stylesheet
Choose Tools -> Business Communications ->
IDoc Basis -> Control -> IDoc Styles .
Identify your stylesheet and the graphics using a
Style ID. See the F1 Help for the fields. Assign the
style ID to the required message type.
Maintain an Inbound Partner Profile for the
required message type. For the process code select
ED00_XML . Assign yourself as the permitted
agent.
Generate a test IDoc of the required
message type, for example with the Test
Tool and start processing.
You receive a work item in the Business
Workplace - when you execute it you
receive the XML display of the IDoc.
Exercises
Tables: EDIDC, EDID4, TBDBA
Test tool for inbound IDocs
Outbound with MC (Message Control)
Outbound without MC (FM master_idoc_distribute)
Looking for user exits
Extensions