Communication interfaces in R/3:
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.
EDIEDI 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 ScenariosMM 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 IDOCIn 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: INVOICIDOC type: INVOIC01Process code: INVM, INVL
OUTBOUND IDOCIn 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: ORDRSPIDOC type: ORDERS04Process code: SD10
Partner type: customer, vendor, or the system itselfPartner 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:
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
IDOC TYPEPath: Tools -> Business Communications -> IDoc Basis -> Development -> IDoc Types Authorization object: S_IDOCDEFT; a possible role is SAP_BC_SRV_EDI_DEVELOPER .IDOC = attributes + segmentsSegments are used to map the information of the R/3 document; so well have Header data segment -> record occurancy = 1Item data segments -> record occurancy >= 1
SEGMENTSNaming 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 FormatData 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.
TESTTo 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 extensionTools -> 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 CMODIn 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 recorddata 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.
ALEEDI -> Electronic Data InterfaceALE -> 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 TYPESThe 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 typeApplication area
File Interface Link to most EDI subsystemsTransactional RFC ALE distribution scenariosCPI-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.
Transactional RFCTo set up the communication, a series of steps are required that you have to carry out in Customizing for ALE (Tcode SALE).
Define the RFC destinations Generate partner profiles Partner profiles and model settings are checked for consistency. Check connections
OUTBOUND PROCESSINGReceiver determination Calling the generated outbound function module Conversion of BAPI call into IDoc Segment filtering Field conversion IDoc version change Dispatch control
IDOC DISPATCHIDocs 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 PROCESSINGSegment 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
XMLDefinition: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