Communication interfaces in R/3:

IDOC interface

for EDI/ALE communicationR/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 sendera 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: it’s 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: it’s 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: INVOIC01Process 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: ORDERS04Process 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 IDocL_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 we’ll 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 recordAn 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.

UseXML 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