ca210 - edi interface.pdf

7/26/2019 CA210 - EDI Interface.pdf

1/407

SAP AG 1999

CA210 EDI Interface

CA210CA210

EDI InterfaceEDI Interface

System R/3

Release 4.6B

September 2000

Mat. No.: 5004 1963


2/407

SAP AG 1999

Copyright 2000 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, Saarbrcken

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.

OSF/Motif is a registered trademark of Open Software Foundation.

ORACLE is a registered trademark of ORACLE Corporation, California, USA.

INFORMIX -OnLine for SAP is a registered trademark of Informix Software Incorporated.

UNIX and X/Open are registered trademarks of SCO Santa Cruz Operation. ADABAS is a registered trademark of Software AG

The following are trademarks or registered trademarks of SAP AG; ABAP, InterSAP, RIVA, R/2,

R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript,SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and

ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included

herein are also trademarks or registered trademarks of SAP AG.

Other products, services, logos, or brand names included herein are trademarks or registered

trademarks of their respective owners.


3/407

SAP AG 1999

R/3Client / Server

ABAP

COControlling

AMAsset Mgmt

PSProjectSystem

WFWorkflow

ISIndustrySolutions

HRHuman

Resources

SDSales &

Distribution

PPProductionPlanning

QMQualityMgmt

FIFinancialAccounting

PMPlant Main-

tenance

MMMaterials

Mgmt

The R/3 Integration Model

SAP's R/3 System has set new norms for standard software that can be universally implemented.

R/3 uses advanced development techniques to achieve comprehensive integration of business

administration and data processing.

R/3 combines state-of-the-art technology with comprehensive business administration functionality

to provide a fully integrated business solution for your company.


4/407

SAP AG 1999

Business Integration Technologies I

SAP BusinessWorkflow - Introduction

BC600 2 days

ABAP WorkbenchProgramming UserDialogs (Level 3)

BC410 5 days

Level 2 Level 3

WorkflowSAP BusinessWorkflow - Programming

BC610 3 days

Archiving

SAP ArchiveLink

BC615 3 days

Data Retention Tool(DART)

BC680 2 days

R/3 Web ConnectionDevelopingInternet Applications

BC440 5 days

Data Archiving

BC660 3 days

Build and UseSAP BusinessWorkflow

BC601 5 days

Business IntegrationTechnology

BC095 3 days

ABAP WorkbenchConcepts and Tools

BC400 5 days

Programming DisplayFunctionality

BC670 2 days


5/407

SAP AG 1999

Business Integration Technologies II

Business IntegrationTechnology

BC095 3 days

Level 2 Level 3

Building EnterpriseSolutions with SAPComponents

CA150 2 days

Data Transfer

BC420 5 days

Programming withBAPIs in Visual Basic

CA925 5 days

R/3 Interface and BAPIProgramming in C++

CA927 5 days

Application LinkEnabling (ALE)

Technology

BC619 3 days

EDI Interface

CA210 4 days

InterfaceProgramming

Data Exchange

Communication

Interfaces in ABAP

BC415 2 days

Programming withBAPIs in JAVA

CA926 5 days

SAP IDoc Interface -Development

BC621 1 day

SAP IDoc InterfaceTechnology

BC620 2 days


6/407

SAP AG 1999

Course Prerequisites

Level 2 course in a revelent application

EDI knowledge is strongly recommended


7/407

SAP AG 1999

Target Group

Audience:

Project team EDI analysts responsible for implementing EDI

Duration: 4 days

Notes to the user

The training materials are not teach-yourself programs. They complement the course instructor's

explanations. Your material includes space for noting additional information.


8/407

SAP AG CA210 1-1

SAP AG 1999

Course Overview

Contents:

Course Goals

Course Objectives

Course Content

Course Overview Diagram

Main Business Scenario

Course Introduction


9/407

SAP AG CA210 1-2

SAP AG 1999

Course Goals

This course will prepare you to:

Explain the possibilities offered by the IDoc

Interface for electronic data interchange

Configure the system to handle the IDoc

interface


10/407

SAP AG CA210 1-3

SAP AG 1999

Course Objectives

At the conclusion of this course, you will be able to:

Configure the IDoc interface

Trace the processing of IDocs within the system

Find out the correct IDoc types for your business

processes.


11/407

SAP AG CA210 1-4

SAP AG 1999

Contents

Unit 10 Inbound Invoice Processing

Unit 11 Payment/Remittance Process

Unit 12 Price Catalog, Inventory Advice

Unit 13 Test of Processing

Unit 14 Documentation Tools

Unit 15 Working with an EDI Subsystem

Unit 16 IDoc Monitoring

Unit 17 Archiving IDocs

Unit 18 Miscellaneous Topics

Unit 19 Conclusion

Unit 1 Course Overview

Unit 2 IDocs in the Business Process

Unit 3 General Settings

Unit 4 Port Definitions

Unit 5 Partner Profiles

Unit 6 MM EDI Application

Requirements

Unit 7 Message Control and IDocs

Unit 8 Workflow and IDocs

Unit 9 SD EDI ApplicationRequirements

Exercises

Preface

Appendices

Solutions


12/407

SAP AG CA210 1-5

SAP AG 1999

General Settings 333

Port Definitions 444

PartnerProfiles 555

MM EDI Application

Requirements 666

777

Test of Processing 131313

Inbound Invoice

Processing 101010

Price Catalog, Inventory

Advice 121212

Documentation Tools 141414

SD EDI Application

Requirements 999

Payment/Remittance

Process 111111

222

Workflow and IDocs 888

IDocs in the

Business Process

111

Message Control & IDocs

Course Overview Diagram (1)

Course Overview


13/407

SAP AG CA210 1-6

SAP AG 1999

IDoc Monitoring 16

Archiving IDocs 17

Working with an

EDI Subsystem 15

Miscellaneous Topics 18

Conclusion 19

Course Overview Diagram (2)


14/407

SAP AG CA210 1-7

SAP AG 1999

Main Business Scenario

You are a member of the integration team (either

SmartMart or NOE Food Company)

You are responsible for setting up the IDoc

interface.

You must know the basics of the IDoc format and

of IDoc processing; both outbound and inbound

processing.

The outbound customer is SmartMart.

The inbound customer is NOE Food Company.

You will be testing your configuration through thecreation of business documents which you will

exchange between SmartMart and NOE Food

Company.


15/407

SAP AG CA210 1-8

SAP AG 1999

Introduction

Contents:

EDI location in SAP

IDoc Overview

Overview of EDI Interface


16/407

SAP AG CA210 1-9

SAP AG 1999

Introduction: Topic Objectives

At the conclusion of this topic you will be able to: Indicate where the EDI interface is located in

the SAP system

Describe the overview of the EDI interface

Define the general concept of the IDoc


17/407

SAP AG CA210 1-10

SAP AG 1999

EDIFA

CT

EDIFA

CT

EANCOM

GENCODTRADACOMS

UCS II, WINS

SEDAS

HL7

ARUA

GALIA

ODETTE

VDA

ATA SPEC2000

AECMA SPEC2000M

BAI, BAI2

MultiCash

S.W.I.F.T.

HBCI

EDIFER

EDIFICE

EIAJ

EANCOM

GENCOD

TRADACOMS

UCS II, WINS

SEDAS

CEFIC

PHOENIX

EDIFICE

ELFEX12

X12

EDI Standards in the World

IBUs and SBUs clockwise:

SAP Consumer Products

SAP Insurance

SAP Public Sector

SAP Telecommunications

SAP Chemicals

SAP Pharmaceuticals

SAP Retail

SAP Banking

SAP Mill Products

SAP Aerospace & Defense

SAP Media

SAP Automotive

SAP Health Care

SAP Service Provider

SAP Utilities

SAP Oil & Gas

SAP Engineering & Construction

SAP High Tech & Electronics


18/407

SAP AG CA210 1-11

SAP AG 1999

Introduction to SAP EDI

SAP EDI is a cross-application function that is delivered with the SAP Basis component.

SAP EDI allows for Electronic Data Interchange between your company and your trading partners.

In the following chapters you will learn how to configure SAP EDI and enable your partners with the

R/3 Applications.


19/407

SAP AG CA210 1-12

SAP AG 1999

System 2System 1

IDocDocument Document

IDoc Concept

message oriented

asynchronous

IDoc is an SAP Standard format for data exchange between systems. IDoc means Intermediate

Document, and is intermediate in two senses:

Message oriented - Data reside in the applications as well, only in other formats (the application

documents). The IDoc stands between these application documents, as a language, spoken by thecommunicating applications. It does not matter whether the application is programmed by SAP or

by another foreign system.

Asynchronous - Data can already reside in IDocs before an application document is created. This

is important, for instance, when wrong data were transmitted: In this case, the application

document shall only be created when the data are corrected.

The IDoc interface is available in R/3 starting with Release 2.1A, in R/2 starting with Release 5.0F.


20/407

SAP AG CA210 1-13

SAP AG 1999

IDoc Applications

Workflow

WWW

message

Electronic

Form

ICR/OCRICR/OCR

DocumentDocument

ALE

EDI MessageEDI MessageEDI Message

R/3 System

R/2 System

Forms

FeedFlows

Internet

Intranet

IDocIDoc

Examples of systems/applications which use IDocs:

ALE Application Link Enabling

EDI Electronic Data Interchange

ICR Intelligent Character Recognition

OCR Online Character Recognition

WWW World Wide Web


21/407

SAP AG CA210 1-14

SAP AG 1999

The IDoc Interface

EDI Standard Independent ANSI X.12

EDIFACT

Proprietary

EDI Subsystem Independent

Certified EDI Subsystems

Not limited to use of Certified subsystems

The intermediate document, or IDoc, interface was designed by SAP application developers.

It is independent of any EDI standards, and is also independent of any EDI subsystem (translator).


22/407

SAP AG CA210 1-15

SAP AG 1999

Electronic Commerce

Document

SAP System R/3 SAP System R/3IDoc

EDI SubsystemEDI SubsystemTransaction

Message

IDocIDoc

Business partners exchange business documents on a logical level, this is physically achievable by

means of letters, fax or phone. All those methods have one thing in common: the technical structure

of the documents get lost, and the recipient has to re-enter the information in their system.

With EDI the technical structure of the document is retained. This enables the recipient toautomatically process the document using their business software. Since both partners are

independent, they will make independent decisions on their IT infrastructure and their business

software. Hence EDI standards are required, to map from the application data structure of the sender

into the EDI standard, and from the EDI standard into the application data structure of the recipient.

This means the partners stay independent.

The IDoc is the data structure of the SAP application at the interface. This gives a unified interface to

any EDI subsystem regardless of the SAP module, which creates or receives the messages.

By linking SAP systems directly, IDoc can be transmitted without a mapping into EDI standards.

This is the ALE (Application Link Enabling) approach. Partners are, in a technical sense, linked

together, which means they loose some of the independence of their IT infrastructure.

The IDoc format can be considered an EDI standard when used for EDI. However, translating IDocsinto other standards has the advantage of communication with more partners.

The advantage of IDocs is that the SAP applications only have to know the format IDoc - not several

EDI standards and thus, are more easily maintained. The disadvantage is that an EDI Subsystem

must be bought when other EDI standards are to be used.


23/407

SAP AG CA210 1-16

SAP AG 1999

FiletRFC

XML

...

Application

Message Control

IDoc Interface &

ALE Services

System 2e.g. EDI subsystem

MMSD...

IDoc

Application

Workflow

IDoc Interface &

ALE Services

System 2e.g. EDI subsystem

Outbound Data Inbound

IDoc Data Flow

Please read the left (outbound) from top and the right (inbound) from bottom.

Message Control is in use with transactions of the supply chain, applications MM and SD, in

outbound processing.

Workflow is conditional with all inbound processing by all SAP applications.

Nevertheless Workflow is in use with all SAP applications to report on exceptions in the

implemented processes. For details please refer to the notification and monitoring section.


24/407

SAP AG CA210 1-17

SAP AG 1999

External SystemExternal System

R/3 SystemR/3 System

IDoc Processing Flow: Outbound

Create application document

Create IDoc

Check Partner, find Port

Receive Datado further processing

In the following, data flow is always viewed from the R/3 system. Therefore, if data is sent from an

R/3 system to an arbitrary external system, this is called outbound processing, or simply outbound.

Outbound processing comprises

Creating the application document

Creating the respective outbound IDoc

Finding the partner and port

Passing the IDoc to the external System via the Port.


25/407

SAP AG CA210 1-18

SAP AG 1999

IDoc Topics: Outbound


R/3 SystemR/3 System

Create application document

Create IDoc

Check Partner, find Port

Receive Datado further processing

PartnerPartner

ProfileProfileGeneral

Settings

PortPort

Description,Description,

Partner ProfilePartner Profile

DocumentationDocumentation

ToolsToolsEDIEDI

Subsystem ?Subsystem ?

ArchiveArchive

IDocs ?IDocs ?

MessageMessage

ControlControl

Smartmart must setup its interface for outbound processing.

Via the Port description, SmartMart defines the systems to receive IDocs, and the technical

communication parameters.

Smartmart defines NOE Food Company as a partner for the message type ORDERS in the Partner

Profiles. Here, Smartmart enters the port it had defined earlier.

Outbound IDocs created in the R/3 system shall be archived and deleted in the system.

The Documentation tools tell the EDI Subsystem which IDoc types it must understand.


26/407

SAP AG CA210 1-19

SAP AG 1999

IDoc Processing Flow: Inbound

External System

R/3-SystemR/3-System

Pass Data to R/3 system

Check Partner, create IDoc

Create Document

Error handling

Ok?

Ok?

no

no

Data reception from an external system plus data processing within the R/3 system is called inbound

processing or, simply, inbound.

Inbound processing comprises:

data takeover from an external system via an inbound port

creating the inbound Idoc(s)

finding the correct processing type via the partner profiles

creating the application document(s)

If an error occurs, error handling (more general: exception handling) starts. This is another kind of

processing and is not only connected to inbound processing.


27/407

SAP AG CA210 1-20

SAP AG 1999

IDoc Topics: Inbound


R/3-SystemR/3-System

Pass Data to R/3 system

Check Partner, create IDoc

Create Document

Error handling

Ok?

Ok?

no

no

DocumentationDocumentation

ToolsTools

PartnerPartner

ProfileProfileGeneralSettings

PortPort

Description,Description,

Partner ProfilePartner Profile

EDIEDI

Subsystem?Subsystem?

WorkflowWorkflow

ArchiveArchive

IDocs ?IDocs ?

NOE Food Company must setup its IDoc interface for inbound processing.

The Documentation tools tell the EDI Subsystem which IDoc types it must understand.

The port name must appear in the Port description; otherwise, the IDoc is not accepted.

In the Partner Profiles, NOE Food enters Smartmart as an Inbound Partner for the message

ORDERS. In addition, responsible agents for error processing are entered here, specific for Partner

and message.

In the general settings, NOE Food defines responsible agents which are notified in the case that no

agent could be found from the partner profiles. This is the case when the inbound IDoc originates

from someone which is not defined as a partner in the partner profiles.

As with Smartmart, NOE Foods wants to archive and, afterwards, delete inbound IDocs which are

completely processed.


28/407

SAP AG CA210 1-21

SAP AG 1999

Summary: Introduction

EDI is located in the Basis portion of the SAP system.

The IDoc type is an open standard interface which is the

integration point between the SAP system and other SAP

systems or perhaps an EDI subsystem.

There are two different ways of processing an IDoc:

inbound and outbound.


29/407

SAP AG CA210 1-22

SAP AG 1999

Introduction: Unit Summary

You are now able to:

Indicate where the EDI interface is located in the

SAP system

Describe the overview of the EDI interface

Define the general concept of the IDoc


30/407

SAP AG CA210 2-1

SAP AG 1999

IDocs in the Business Process

Contents

IDoc record types

IDoc and IDoc type

IDoc processing: inbound and

outbound direction


31/407

SAP AG CA210 2-2

SAP AG 1999

IDocs in the Business Process: Unit Objectives

At the conclusion of this unit you will be able to: Define the difference between IDoc and IDoc type

Describe the general structure of an IDoc

Point out where in the (business) process chain

the IDoc is created


32/407

SAP AG CA210 2-3

SAP AG 1999

General Settings 333


PartnerProfiles 555

MM EDI Application

Requirements 666

777


Inbound Invoice

Processing 101010


Advice 121212


SD EDI Application

Requirements 999

Payment/Remittance

Process 111111

222


IDocsin the

Business Process

IDocsinthe

Business Process

Course Overview


IDocs in the Business Process: Course OverviewDiagram (1)


33/407

SAP AG CA210 2-4

SAP AG 1999

IDoc Monitoring 16

Archiving IDocs 17

Working with an

EDI Subsystem 15


Conclusion 19

IDocs in the Business Process: Course OverviewDiagram (2)


34/407

SAP AG CA210 2-5

SAP AG 1999

EDI message IDoc SAP document

EDI subsystem SAP System R/3

IDoc Concept, Technical

Proper interface between application and

EDI subsystem

Basic support for application

API for development

easy to use

Real-time EDI

Independent of EDI standards

Independent of trading partners

The interface with the applications is given by:

the IDoc data structure (this is the IDoc type)

the API (application programming interface) to create, read and process IDocs

The data flow is triggered from the source by RFC (Remote Function Call). This guarantees real-

time processing.

An IDoc type is dependent on the logical message (business document) only, but independent of a

specific EDI standard for that logical message.

The IDoc is independent of trading partners, this means:

all data from the master records and the SAP document is filled into the IDoc

the mapping - selection of data to be transmitted - is defined a the EDI subsystem only


35/407

SAP AG CA210 2-6

SAP AG 1999

The Intermediate Document (IDoc)

Control record

Intermediate Document type

Application

EDI subsystem

Data record

SegmentAdministrative

Section

Status record

This graphic represents the IDoc as the interface between the EDI subsystem and the R/3 application.

It is very important to note that the IDoc is data stored in a structured format - it is not a process or

any kind of executable code.

An IDoc structure can be used to support multiple message types, for example the data in a sales

order is very similar to the data in a purchase order, therefore both of these message types can use

the same IDoc format.


36/407

SAP AG CA210 2-7

SAP AG 1999

IDoc Architecture

Record structure

control section (key) and data section

identical for outbound and inbound processing

Fields in the data segments according to EDI standards

field length

field type

field values

Application programming interface (API)

creation of IDocs

processing of IDocs

status log

Field lengths and types are compared with the data element directories of

UN/EDIFACT,

ANSI X12 and

SAPs data repository

Codes for coded fields are taken from international standards where the standard applies. For

example - Country codes, currency codes, and unit of measure codes use the ISO (International

Standards Organization) codes.


37/407

SAP AG CA210 2-8

SAP AG 1999

IDoc Support

Storage of IDocs for

Processing at a later time

Reference

Display of IDocs

Monitoring and reporting on IDoc processing

Utilities for Documentation of

IDoc types

Record types

Segment types

Utilities for IDoc definition

IDoc structures at segment level

IDoc segments at field level

IDocs are stored in three tables in SAP. They are stored by record type. The three IDoc tables are:

EDIDC- control records

EDID4 - data records from release 4.x onward

EDID2 - data records from release 3.0C to 3.1I

EDIDD - data records from release 2.0A to 3.0B

EDIDS - status records


38/407

SAP AG CA210 2-9

SAP AG 1999

Status records

Data records

Control record

IDoc Record Types

Each IDoc in the R/3 database consists of

exactly one control record

data records which hold the application data in segments and describe the hierarchy of these

segments.

status records holding well defined processing steps. Therefore, IDocs far ahead in the processing

chain generally contain more status records than IDocs where processing has just begun.

However, when an IDoc is exchanged with an external system, it only contains the control record

and the data records.

If the external system notifies the R/3 system about what has happened to its IDocs, it can do so by a

status report. In this case, the R/3 system receives status records. The R/3 system attaches the records

to the right outbound IDoc which is still stored in its database.

The R/3 system can also actively send status reports outbound, but only via the special IDoc type

SYSTAT01. Note that in this case, again only control and data records are exchanged. The relevant

status information is contained in the data records.

To summarize: IDocs exchanged between two systems are always smaller than their R/3 database

counterparts, since they do not contain status records.


39/407

SAP AG CA210 2-10

SAP AG 1999

Control Record

Control record IDoc-IDPartner

IDoc Type and logical messageexternal structure

The IDoc-ID is an important part of the control record. It is a simple number which is internally

generated. It uniquely identifies the IDoc in the R/3 system. Status reports always refer to that

number.

The control record also contains the key fields of the partner profile: partner and logical message (3fields each) as well as a test flag. For inbound IDocs, these key fields determine the dependent

parameters of the inbound partner profile, e.g. which was the IDoc should be processed within the

R/3 system.

The three key fields of the partner (e.g. the receiver for outbound IDocs) are:

number (In the R/3 system, this is the master data number which may be internally generated)

type (customer, vendor, bank or logical system in ALE scenarios)

role (important for outbound processing via message control)

The three message fields are:

message type (if possible, follows UN/EDIFACT notations). For example, ORDERS, INVOIC

code (optional)

function (optional; e.g. changed message)

Other fields are related to mapping IDocs to another EDI standard, e.g. the EDI standard structure or

the EDI message archive.


40/407

SAP AG CA210 2-11

SAP AG 1999

Data Record and Segment Structure

Data record

Control area, contains

segment name

Application Data

Field 2Field 1 ...

SegmentSegment

The control area of a data record contains the name of the segment. In the R/3 system, the segment is

defined as a structure, i.e. a series of fields of certain length and data type. Generally, one segment

field is related to one application field.

The application data area of a data record is a single field of 1000 bytes. This is where theapplication data resides.

By virtue of the segment name field in the control area, the unstructured application data field of the

data record gets its structure. This always happens when the application writes data into the IDoc or

reads data from the IDoc, because data transfer occurs through the segments.

The data type of the segment fields is character.

If possible, coded fields abide by ISO rules.


41/407

SAP AG CA210 2-12

SAP AG 1999

Status Record

Status record IDoc IDStatus information

The IDoc number is an important part of the status record. It points to the IDoc to which the status

records belong. Thus, it is possible that status records can be transferred separately and still be

attached to the right IDoc.

First, status information is given by the status value, or simply status,a two-digit number assigned toa well defined process step.

More detailed information is given by three fields naming an R/3 message. If, for instance, a

processing error occurs, the error message can be included in the new status record reporting the

error situation.

Consider the message SAPEA211; the three fields then take the following values:

- SAP: R/3 message displayed in a standard window (Field STAMQU)

- EA : message class as defined in table T100 (Field STAMID)

- 211 : message number as defined in table T100 (Field STAMNO)

If STAMQU describes messages defined by an external system, messages of that system may be

displayed in a special way. To that end, a special display program must be written and be entered

into table TEDE3.

Other fields of the status record are the date and time when the record was created, and the name of

the program that created it.


42/407

SAP AG CA210 2-13

SAP AG 1999

Control record

Status records

Data records

IDoc-ID

Partner

IDoc-Type and logical messageExternal structure

Control area Application data

IDoc-ID

Status information

IDoc Record Types: Summary

In summary: the IDoc consists of three record types.

The control record contains information about the type of message be exchanged, and to whom it is

being sent/received.

The data records hold the application data.

The status records represent the life-cycle or major milestones of the IDoc's life.


43/407

SAP AG CA210 2-14

SAP AG 1999

Control Record

Status records

Data records, displayed as a tree

E1TLSUM

E1HDADR

E1HDDOC

E1ITDOC

M 1

C 99

M 1

C 5

C 2

E1ITSCH

C 5

IDoc Types

Each business process (e.g. a purchase order) is transferred by a special IDoc type which can hold

the relevant data.

An IDoc type is defined through its segments, their hierarchy, order and repeatability. This

information is part of the control area of the data records.

The segment hierarchy can be visualized in a tree as parent and child segments. It gives structure to

the application data.

In conclusion: IDoc types are special data structures tailored to special applications or messages. If

such a structure is filled with application data, an IDoc is created (the instance of the IDoc type).


44/407

SAP AG CA210 2-15

SAP AG 1999

Inbound and Outbound Processing

R/3 System

SAPapplication

IDoc Interface/ALE Services

External System

Outbound direction Inbound direction

Directions are always defined as viewed from R/3. Thus, in the outbounddirection, IDoc data are

transferred from the application via the IDoc interface to the external system. The inbounddirection

processes data from the external system via the IDoc interface to the application.

For inbound processing, the external system must have certain authorizations since it will be creatingdocuments (IDocs and application documents) within the R/3 system.

Both the inbound and outbound processing directions have multiple ways of processing. These are

explained in the following slides.


45/407

SAP AG CA210 2-16

SAP AG 1999

IDoc

NAST

record

Document

SAPapplication

Message control (NAST)

External System


Outbound Processing via Message Control

SAP applications can create IDocs directly or via message control.

When message control is involved, there is the possibility that it can be further processed (i.e.,

filtered) by the ALE services before it is passed to the port.

The IDoc Interface passes every IDoc to the chosen port, according to the technical port description.

Examples for Port types are:

External System = R/3 System: Common is the transactional RFC (Standard ALE scenario)

External System = EDI Subsystem: Common is the file interface.


46/407

SAP AG CA210 2-17

SAP AG 1999

Direct Outbound Processing (FI and ALE)

SAPApplication

External System


Comm.-IDocComm.-IDoc Comm.-IDoc

Master

IDoc

During direct outbound processing with ALE scenarios, the ALE services are always called. The

services:

filter the IDoc. Segment fields containing data not necessary for the recipient system are removed

from the IDoc

change the (segment) version. If the recipient system is on an earlier release of SAP or is using an

earlier version of a segment in the IDoc type, the version can be changed here. This means that

less data is transported, since later versions of segment can only contain more fields than former

versions and never less fields.

Occasionally split the IDoc into several IDocs. The can happen in ALE distribution scenarios,

where more than one system receives the data.

To achieve these tasks, the ALE services transform one Master IDoc(passed to the function module

MASTER_IDOC_DISTRIBUTE into one (or more) Communications IDoc(s).Only

Communication IDocs are saved in the database.

The process is slightly different for IDocs created from the FI (financial) area of R/3. A master IDoc

is not created and the ALE services are not called. However, the IDocs are processed through the

IDoc interface to the external system.


47/407

SAP AG CA210 2-18

SAP AG 1999

SAPApplication

SAP Business Workflow

External System


DocumentDocument

IDocIDoc

IDoc +IDoc +

ProcessProcess

Error

IDocIDoc

Inbound Processing via Workflow

The external system sends IDocs to the R/3 system via a port name which is defined in R/3. The port

name of the R/3 system can be SAPCLNT e.g. SAPC11CLNT810 for an R/3 system

C11 and client 810.

If the IDoc interface knows the external system (as an inbound port), it accepts the inbound IDocsand starts processing: For instance, it performs a syntax check and tries to find the IDoc sender,

found in the control record, in the partner profile.

The partner profile determines if the IDoc is directly passed to the application (ALE function

module) or if a workflow is started. If a workflow is started, the ALE services may be called before

the inbound IDocs are stored in the database.


48/407

SAP AG CA210 2-19

SAP AG 1999

Direct Inbound Processing with ALE

SAPApplication

External System


IDocIDoc

IDocIDoc

During direct inbound processing, the ALE services are always called. As in the outbound case, they

can do filtering and change versions. However, inbound IDocs cannot be split.

The ALE processed IDoc is stored in the database. This is called an application IDoc as opposed to

the communication IDoc of outbound processing.

The ALE services can also be called when workflow is invoked.


49/407

SAP AG CA210 2-20

SAP AG 1999

IDocs in the Business Process: Unit Summary

You are now able to:

Define the difference between IDoc and IDoc type

Describe the general structure of an IDoc

Point out where in the (business) process chain

the IDoc is created


50/407

SAP AG CA210 2-21

Data Used in the Exercises

Data Data in Training System Data in IDES System

Company Code: 3000

PO Vendor number V100##

PurchasingOrganization: 3000

Purchasing Group 000

Plant 3000

PO Material DCC-##

PO Output type NEU

Customer number 300##

Customer Material CCS-##

Sales Organization 3000

DistributionChannel

10

Division 00

OrderAcknowledgment

Output Type

Advance Shipment

Notification OutputType

Invoice Output

Type

BA01

LAVA

RD00


51/407

SAP AG CA210 2-22

Exercises

Unit: IDocs in the Business Process

At the conclusion of these exercises, you will be able to:

Describe what is meant by an IDoc type

Indicate how IDoc types are used in SAP

IDocs are used to move data into and out of the SAP system. It is

therefore necessary to understand what their components are and how

they are used in the SAP system.

1-1 What is an IDoc type?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

1-2 What are the three records types within the Intermediate Document?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

1-3 Which IDoc record type contains the data which is used to determine the partner

profile information and the direction the data is to travel (into/out of SAP)?

___________________________________________________________________

1-4 The ____________________ is the main key that links the three record types

within an IDoc.

1-5 Are different IDoc types used for inbound messages as opposed to outboundmessages?

___________________________________________________________________

1-6 What is the difference between an IDoc type and an IDoc?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________


52/407

SAP AG CA210 2-23

1-7 True/False: Status records are sent out of the SAP system?

___________________________________________________________________

1-8 The rule-based condition technique used to output IDocs is called:

Workflow Management

Message Control

Intermediate Document

None of the above

1-9 The rule-based inbound processing technique is called:

Output Determination

Partner Profiles

Workflow Management

None of the above

1-10 Does SAP have a different IDoc type for each transaction or document in R/3?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________


53/407

SAP AG CA210 2-24

Solutions

Unit: IDocs in the Business Process

1-1 An IDoc type is a hierarchical structure containing segments which have fields

that hold application data taken from the SAP database, or application data

which is to create an application document in SAP. Examples are ORDERS02

and MATMAS01, which contain segments that relate to order information and

material master information respectively.

1-2 The three records types within an Intermediate Document (IDoc) are the control

record, data record, and status record.

1-3 The control record contains the fields, which are the keys to the partner profile,

and the direction field value indicates whether the IDoc is outbound or inbound.

1-4 The IDoc ID (number) is the main key that links the three record types within an

IDoc.

1-5 No. The same IDoc types can be used for inbound and outbound messages.

1-6 An IDoc type is a structure which is defined by its segments, hierarchy, order and

repeatability. It is meant to indicate the type of data that will be found in an

IDoc. An IDoc is an instance of an IDoc type with the structure filled with theapplication data and assigned an IDoc ID (number) and housed in the IDoc

tables.

1-7 False only the control record and the data records are sent out of SAP. Status

records are sent into SAP to update an IDoc.

1-8 Message Control

1-9 Workflow Management

1-10 No. The IDoc type represents a series of related business documents. For

example, the MM outbound PO, the SD inbound PO, the SD outbound Order

Confirmation and the MM inbound Order Confirmation all use IDoc type

ORDERS01, which contains the structure for order information.


54/407

SAP AG CA210 3-1

SAP AG 1999

General Settings

Contents:

Units of Measure

Logical System

Number Ranges

Process Technology

Workflow Customizing

Event Receiver Linkage

IDoc Administration

Proposal Values for Partner Profile

Map Long Names to Short Names


55/407

SAP AG CA210 3-2

SAP AG 1999

General Settings: Unit Objectives

At the conclusion of this unit, you will be able to:

State which parameters can be customized

Determine the time when the IDoc administrator is

notified


56/407

SAP AG CA210 3-3

SAP AG 1999

333


PartnerProfiles 555

MM EDI ApplicationRequirements 666

777


Inbound Invoice

Processing 101010


Advice 121212


SD EDI ApplicationRequirements 999

Payment/Remittance

Process 111111

222


IDocs in theBusiness Process

111Course Overview


GeneralSettings

GeneralSettings

General Settings: Course Overview Diagram (1)


57/407

SAP AG CA210 3-4

SAP AG 1999

IDoc Monitoring 16

Archiving IDocs 17

Working with an

EDI Subsystem 15


Conclusion 19

General Settings: Course Overview Diagram (2)


58/407

SAP AG CA210 3-5

SAP AG 1999

Customizing via IMG

R/3 Customizing

IMG

Basis Components

Basis Services

IDoc

InterfaceIMG Documentation

Project Documentation

Project Management

Activities

For the IDoc interface, general parameters can be set using the IMG. The IMG is an implementation

guide helping you to customize your R/3 system according to your needs. Maintaining the relevant

customizing tables is done in activities.

By selecting the appropriate attributes, users can display only the activities that are required in eachcase. For example, if a customer wishes to adopt all SAP standard settings, only the activities with

the attribute required must be executed.

The IMG node or path for the IDoc Interface is Basis Components --> Basis Services -->IDoc

Interface / Electronic Data Interchange. You should read the IMG documentation, which is available

for each activity (double-click on the relevant document).

You can also create your own projects from the standard IMG : projects are a type of view of the

standard IMG, which are used by different teams. The IMG offers project management functions

(resource planning, etc.), as well as functions for creating your own project documentation via

customer notes.


59/407

SAP AG CA210 3-6

SAP AG 1999

Units of Measure

ISO Code(IDoc)

CS

CS

CS

CS

Unit of Measure(SAP)

CSE

BOX

CSE

CAR

There are several fields that may be in the IDoc that are presumed to follow International Standards

Organization values. These fields are currency, country, and unit of measure.

The ISO Unit of Measure may or may not be the same as the SAP internal unit of measure.

Additionally, the trading partner may or may not be following the ISO standard for unit of measure.

It may be necessary to configure additional ISO unit of measure codes to associate with the SAP unit

of measure code.

In the configuration of the SAP unit of measure, there are two fields of interest. The ISO code field is

where the association is made between the ISO unit of measure code and the SAP internal unit of

measure code. The other field is the Primary code field. This is used for inbound information to

determine which single SAP internal unit of measure will be assigned.

For outbound information, many SAP internal units of measure can translate to a single ISO unit of

measure code. The ISO code is placed in the IDoc.

For inbound information an ISO unit of measure code will translate in a single SAP internal unit of

measure code which has the primary code checked.


60/407

SAP AG CA210 3-7

SAP AG 1999

PR1

client 100

PR2

client 200

Logical system -

PR1CLNT100

Logical system -

PR2CLNT200

Logical System

Create Logical System

Assign Logical System

A logical system is a way to name each system/client combination in the system landscape. It is the

way to address where information is being sent to or received from.

All EDI transactions are ALE enabled and ALE technology requires the use of a logical system.

The typical naming convention for logical systems is:

system id CLNT client

All clients in a system must have a unique logical system name. It is also true that the same clients

on different instances must have unique logical system names. For example: DEV client 100 could

be named DEVCLNT100, and PRD client 100 could be named PRDCLNT100.

It is usually the function of the Basis systems people to create logical system names and assign them

to each client.


61/407

SAP AG CA210 3-8

SAP AG 1999

Number Ranges

IDoc Interface

[]

Number ranges are intervals of natural numbers which are assigned to objects by the R/3 system.

This is called internal number assignment.

In the IDoc interface, number ranges are set for:

IDocs: The IDoc number is taken from this number range

Ports: These numbers identify the tRFC ports

Mailbags: Mailbags are only used when communicating with an R/2 system. Here, IDocs are

communicated in mailbags. Note that this item only exists prior to release 4.5x

These number ranges are set in the IDoc interface IMG component.


62/407

SAP AG CA210 3-9

SAP AG 1999

Replace Process Technology with Workflow

Only necessary when upgrading from 2.1/2.2

IMG Activities:

Change exception handling

Change inbound processing

Please note the IMG documentation of the individual activities.


63/407

SAP AG CA210 3-10

SAP AG 1999

Use extended exception handling for status return

Converts status codes assigned to system process code

EDIS to EDIR

IMG activity when upgrading to 4.6x

System process code EDIR is used for notification of negative status values of status reports.

The advantage that EDIR has over EDIS is that further processing of incorrect IDocs is possible.

This activity is only required when upgrading to 4.6x. If this is a new installation then EDIR status

code is already assigned.

This item can be run as a simulation run and then as the actual run.


64/407

SAP AG CA210 3-11

SAP AG 1999

Delete Process Technology from System

Remove unnecessary process codes from system

IMG Activity:

Delete process technology in EDI processing in logistics

Trial run

Final run


65/407

SAP AG CA210 3-12

SAP AG 1999

Workflow Auto-Customizing

Configures Workflow Runtime and Development Environments

IMG Activity:

Workflow Runtime System:

Active plan version exists

Workflow administrator maintained

Workflow RFC destination configured completely

Generic decision task classified completely

Tasks for document generation fully classified

T77* tables all available

Monitoring jobs for missed deadlines is scheduled

Monitoring jobs for work items with errors is scheduled

Sending to objects and HR objects activated

PD control tables complete


66/407

SAP AG CA210 3-13

SAP AG 1999

Event Receiver Linkage

IDoc Interface

R/3 Application

Processing

Event

When IDocs are received, they are first stored in the database. In a second and independent step, they

are processed further (an exception to this rule is the port type tRFC, where processing takes place

in one step). This is made possible through the workflow event concept. When IDocs are stored in

the database, an event is created which waits for its receiver in the system. The receiver (a functionmodule) finds the event and starts further inbound processing. Through this step, the function

module has consumed the event: It is no longer there in the system. It is up to the workflow manager

to decide when the consumer starts to look for events. Thus, saving IDocs and processing them

further is separated in time (asynchronous processing).

To enable this new form of inbound processing to take place, the corresponding event must be

actively linked to the receiver.

You must therefore activate the event-receiver linkage in the IMG for the IDoc Interface.


67/407

SAP AG CA210 3-14

SAP AG 1999

IDoc Administration: Global Parameters

Allowed Agent to be notified in general (IDoc Administrator)

System Environment (Basis System)

Details of Processing

The IDoc Administrator is always notified when an error occurs during IDoc processing and no

partner profile could be found. Otherwise, the partner-specific agent (and the message-specific agent,

if required) entered in the partner profile is notified.

In the system environment, the IDoc Interface is informed whether non-Basis components exist, e.g.Message Control or application components. If these entries are not made, it is possible that the IDoc

Interface may call function modules, for example, which do not exist in the specified system (Basis

system only).

Precessing details:

The maximum number of syntax errors that can be recognized in one IDoc and therefore logged as

status records. The larger this value, the higher the probability that the error messages do not refer

to real errors, but only subsequent errors.

Whether or not inbound processing is triggered synchronously (not via the event-receiver linkage)

(port type File).

System parameters can be entered as global parameters from the IDoc Interface initial screen by

selecting Control -> IDoc Administration or from the IMG for the IDoc Interface.

You should use the F1 Help function for the entry fields.


68/407

SAP AG CA210 3-15

SAP AG 1999

IDoc Administrations: User Parameters

Tests

Documentation Tools

IDoc Lists (4.0x - 4.5x only)

IDoc Display (4.0x - 4.5x only)

Development (4.0x - 4.5x only)

User-specific parameters of the IDoc interface cannot be set in the IMG. Instead, choose transaction

code WE46 from the entrance menu of the IDoc interface.

The parameters for monitoring the IDoc data flow are display parameters.

The port value is a test parameter, which is proposed as standard by the test programs.

For the documentation tools, you should define the default documentation output, for example,

whether the individual segment fields are also to be included in the documentation of IDoc types.

You can enter a default development class for the development of IDoc types and segments. Course

BC621 contains more information about developing and defining IDoc types.

Monitoring parameters are for layout.


69/407

SAP AG CA210 3-16

SAP AG 1999

Proposal Value

Proposal Values for Partner Profile

For quick definition of the partner profile, you set up templates in the IMG.

The templates are set per partner type and direction.

Press the button templates from within the partner profile (transaction WE20) to get the templates for

your actual direction and partner type. Then, modify the defaults according to your needs.

Since partner profiles require a port, you can also define a port in the IMG. Note this item is only

valid through release 4.5x.

In the IDES system, the following message types are set for the vendor or customer, depending on

the direction:

DELINS - forecast/JIT delivery schedule

ORDCHG - change purchase order/sales order

ORDERS - purchase order/sales order

DESADV - shipping notification

INVOIC - invoice/billing document

ORDRSP - order confirmation


70/407

SAP AG CA210 3-17

SAP AG 1999

Map Long Names to Short Names

Release 4.x Release 3.X

Type LongName

XYZ01Type Short01

Release 4.0 introduced the extended namespace. IDoc interface objects (e.g. IDoc types) new to 4.0

can have longer names than before.

This fact can lead to problems when communicating with older releases, which understand only short

names. If needed, tables must be maintained which map short names to long names and vice versa.

These mapping tables are maintained in the IMG or from the development menu of the IDoc

interface. From the relevant object (IDoc types or segments), choose transaction code WE70 for

Basic IDoc types, WE71 for Extension IDoc types, WE72 for IDoc types or WE73 for Message

types. Also note the online IMG documentation.


71/407

SAP AG CA210 3-18

SAP AG 1999

General Settings: Unit Summary

You are now be able to:

State which parameters can be customized

Determine the time when the IDoc administrator is

notified


72/407

SAP AG CA210 3-19

Exercises

Unit: General Settings

Topic: Customizing in the IMG


Describe what IDoc customizing is done in the IMG for general

settings

IDocs are used to move data into and out of the SAP system. It is

therefore necessary to understand what the general customizing is for

IDoc processing no matter which direction IDocs are going. This

setup is also independent of the use of the IDoc (EDI, ALE, Internet).

1-1 How many different number ranges can be set up for IDoc processing and what are

they?

____________________________________________________________

____________________________________________________________

1-2 How many different number ranges are used for numbering IDocs?

____________________________________________________________

____________________________________________________________

1-3 What is the event receiver linkage?

____________________________________________________________

____________________________________________________________

____________________________________________________________

1-4 Which port type does not make use of the event receiver linkage?

____________________________________________________________

____________________________________________________________

1-5 Why is the IDoc Administrator important?

____________________________________________________________

____________________________________________________________


73/407

SAP AG CA210 3-20

1-6 When must the configuration for replacing the process technology with Business

Workflow be done?

____________________________________________________________

____________________________________________________________

1-7 What is the advantage of using templates for partner profiles?

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

1-8 True or False:

1-8-1 Releases of SAP older than 4.0x can understand the long names of Logical

Messages, Basic IDoc Types, Extensions, IDoc Types, and Segments?

______________________________________________________

______________________________________________________


74/407

SAP AG CA210 3-21

Exercises


Topic: User parameters

At the conclusion of these exercises, will be able to:

Configure the system for the IDoc user parameters

It is necessary to set up the user parameters for testing of IDoc

processing in the system.

2-1 Configure the IDoc administration user parameters. Select:

Output as C header file, and Test using file interface.

2-1-1 For Test using file interface use Group## for the Testport.

2-1-2 For Output as C header file use C:\Temp\ for the local directory and a local

file w/o extension name of IDoc.


75/407

SAP AG CA210 3-22

Solutions


Topic: Customizing in the IMG

1-1 Two. IDocs, and Ports

1-2 Only one number range is used to number IDocs no matter whether they are

going into or out of the SAP system. It also does not matter if the IDoc is being

used for EDI, ALE or the Internet.

1-3 If IDocs are to be processed inbound and not synchronously or through the tRFC

port, then IDocs are processed through the workfow event concept. The event

receiver linkage starts the workflow event when inbound IDocs are brought intothe SAP system.

1-4 The tRFC port does not require the event receiver linkage to be executed.

1-5 The IDoc Administrator is important because it is the party to notify when the

party to notify cannot be determined from the message specific partner profile or

the general partner profile.

1-6 When the SAP system is upgraded from 2.1x/2.2x to 3.0x and beyond.

1-7 The use of templates for partner profiles allows for fast entry of partner profiles if

all trading partners have the same messages inbound and/or outbound.

1-8 False. Starting with Release 4.0x the Logical Message, Basic IDoc Types,

Extensions, IDoc Types and Segments increases their length to 30 characters

from 6 8 characters prior to 4.0x. If IDocs are sent to earlier releases they only

know the shorter names. Thus there is a series of tables which connect long

names to short names.


76/407

SAP AG CA210 3-23

Solutions


Topic: User Parameters

2-1 From the SAP Easy Acces menu, open folders

Tools Business Communication IDoc IDoc Basis Control.

Double-click "IDoc administration".

Select the [Display Change] button and click on the Test tab.

2-1-1 For Test using file interface use enter your Group## in the TestPort field.

2-1-2 Select Documentation tab and enter the following information for C-Header

output:

C-header output

Field Name Input Data

Local directory C:\temp\

Local file w/o extension IDOC

2-1-2-2 Press the Save icon.

2-1-2-3 Return to the SAP Easy Access menu by selecting the [Back]

button.


77/407

SAP AG CA210 4-1

SAP AG 1999

Port Definitions

Contents:

Port types and their typical fields of use

Port description

Communication with older releases


78/407

SAP AG CA210 4-2

SAP AG 1999

Port Definitions: Unit Objectives

At the conclusion of this unit, you will be able to: Decide which port type to use for which system

Define the port description in the R/3 system

Configure the settings necessary for a specific port

type

Configure your R/3 system for communication with

releases earlier than 4.x


79/407

SAP AG CA210 4-3

SAP AG 1999

333

444

PartnerProfiles 555


777


Inbound Invoice

Processing 101010


Advice 121212



Payment/Remittance

Process 111111

222


IDocs in theIDocs in theBusiness ProcessBusiness Process

111

PortDefinitionsPortDefinitions

Course Overview

General Settings


Port Definitions: Course Overview Diagram (1)


80/407

SAP AG CA210 4-4

SAP AG 1999

IDoc Monitoring 16

Archiving IDocs 17

Working with an

EDI Subsystem 15


Conclusion 19

Port Definitions: Course Overview Diagram (2)


81/407

SAP AG CA210 4-5

SAP AG 1999

Port Definitions: Business Scenario

As a member of the integration team of your

company, SmartMart, you are responsible for

setting up the IDoc interface.

SmartMart uses an EDI subsystem. You must

decide which port type is adequate for your EDI

subsystem.


82/407

SAP AG CA210 4-6

SAP AG 1999

SAPApplication

IDoc Interface & ALE Services

IDocIDoc

MIME

Internet

CPI-C

IDoc &IDoc &

statusstatus

R/2

IDocIDoc

tRFC

ALEAny

IDoc &IDoc &

statusstatus

File

+ RFC

EDIAny

IDocIDoc

ABAP

Any

IDocIDoc

XML

ECAny

2.1 on 3.0 on 3.0 on 3.1 on4.5 on 4.6 on

Port Types of the IDoc Interface

The IDoc interface offers 6 different communication channels, defined by the appropriate port types,

within system R/3.

Port type File - Transfer of information via files and synchronous RFC for triggering of the

destination by the source. This allows transfer of IDoc data and the status report.

Port type tRFC - Transfer of all information via (asynchronous) transactional RFC. This is the

preferred method in ALE scenarios and allows transfer of IDoc data.

Port type CPI-C - Transfer of all information via CPI-C. This option is in use only with system R/2

coupling based on the R/2-IDoc interface as released in R/2, 5.0F. This allows transfer of IDoc data

and the status report.

Port type Internet - Transfer of all information via the Internet as MIME attachment. This allows

transfer of IDoc data.

Port type ABAP - Transfer of all information with customer specific program logic. This is thought

to be a Project-Exit for any unforeseen communication channel. IDocs are exchanged as tables with

an internal R/3 function module. This is the only port type where IDocs dont leave the R/3 system.

The function module is customer written and can do anything with the IDoc.

Port type XML - Transfer of all information via XML compatible files, including DTD if requested.

This port type is released as prototype, changes and enhancements are expected for future releases.


83/407

SAP AG CA210 4-7

SAP AG 1999

Outbound Trigger

Outbound File

Inbound File

Status File

IDoc File

Status Report

rfcexec

out.script

RFC Destination(TCP/IP Connection)

Port Description: Port Type File

The IDoc interface port description holds technical communication parameters. To make a portuseable, further parameters outside of the IDoc interface have to be set.

Name and directory of the outbound trigger (a.k.a. command file pre-4.6x) (called by rfcexec) which

starts the external system. This must be set if the R/3 system is to start, or trigger, the externalsystem (by RFC). For triggering, one needs to define an RFC destination (e.g. SERVER_EXEC).

This is done with transaction SM59 (TCP/IP connections). This setup is usually done by Basis.

Outbound - Directory name - specify a physical directory path or a logical directory path (new with

Release 4.6x). File name - determined via a static name or via a dynamic name based on a functionmodule (recommended).

Inbound - Directory name - configuration can be optional based on parameters used by the external,sending system. If the inbound parameters are set here, they serve as default parameters for the test

tools. As with the outbound parameters, a physical directory path or a logical directory path (newwith Release 4.6x) can be specified. File name - determined via a static name (most commonly used

configuration) or via a dynamic name based on a function module.

Status - Directory name - configuration can be optional based on parameters used by the external,sending system. If the status parameters are set here, they serve as default parameters for the test

tools. As with the outbound and inbound parameters, a physical directory path or a logical directory

path (new with Release 4.6x) can be specified. File name - determined via a static name (most

commonly used configuration) or via a dynamic name based on a function module.

It is important that the port exists even if it is only used for the inbound process, since the IDoc

interface only accepts known port types.


84/407

SAP AG CA210 4-8

SAP AG 1999

IDoc File

1

Write

4

Read

2

RFC

3

Call

rfcexecrfcexec

out.scriptout.script

IDoc Interface

Subsystem

1

Write

IDoc File

Status Report

startrfcstartrfc

in.scriptin.script

status.scriptstatus.script

3

RFC

2

Call

4

Read

Data Flow for file Port type (trigger)

Outbound direction:

Step 1: The IDoc interface creates a new file and fills it with one or more IDocs.

Step 2: The IDoc interface calls the C program rfcexec, handing over the path to an executable

script (e.g. out.script) and name and location of the IDoc file.

Step 3: out.script calls the external system, passing the IDoc file name and location.

Step 4: After successfully processing, the external system must delete the IDoc file.

Inbound direction for IDocs and status report:

Step 1: The external system creates an IDoc file.

Step 2: It starts the R/3 system via the C program startrfc. Startrfc contains the logon parameters

and the name of the function module, the (nbound) port and the IDoc file path. The startrfc

command can be held in an executable script (e.g. in.script). It is important that the calling system

is known as an R/3 user who has the appropriate authority to create the application documents

corresponding to the IDocs.

Step3: The R/3 system reads the IDoc file and deletes it after successfully reading and loading the

IDocs into the R/3 system IDoc tables.

The status report is processed in exactly the same manner, with the only difference being that a status

file is passed instead of an IDoc file.

"rfcexec" and "startrfc" are C routines from the RFC library delivered with the R/3 system.


85/407

SAP AG CA210 4-9

SAP AG 1999

RFC Destination

(R/3 Connection)

Port name (automatically generated)

Application Server

of the external system

Port Description: Port Type tRFC

The port description only contains the name of an already existing RFC destination. When the port is

entered, the system generates a name starting with an A and ending with a 9-digit number. The

internal number generation needs a number range, which is set in IDoc interface customizing.

Alternatively to the IDoc interface port description, tRFC ports can be (and generally are) maintainedin the ALE customizing.

The RFC destination is maintained as an R/3 connection using transaction SM59.


86/407

SAP AG CA210 4-10

SAP AG 1999

IDoc Interface

External System

RFC InterfaceRFC Interface

RFC InterfaceRFC Interface

TCP/IPTCP/IP

Data Flow for Port Type tRFC

tRFC means that one system calls a function module of another system. For IDoc exchange, this

means that the sending system is always the active system. It calls the function module in the

receiving system and passes the IDocs as arguments. The function modules of this port type are

inbound function modules. Inbound function modules are INBOUND_IDOC_ASYNCHRONOUS (new for Release 4.0) and

INBOUND_IDOC_PROCESS (older Releases). To send an IDoc to an R/3 system older than 4.0,

one must call INBOUND_IDOC_PROCESS: This is set in the Port Version.

Non-R/3 systems need the R/3 RFC library. From transaction SE37, the external RFC interface can

be generated. If a non-R/3 system is able to receive an IDoc via tRFC, it must additionally contain a

function module analoguous to INBOUND_IDOC_ASYNCHRONOUS or

INBOUND_IDOC_PROCESS.

All passed IDocs are asynchronously stored in the data base via a single COMMIT WORK

command.


87/407

SAP AG CA210 4-11

SAP AG 1999

Internet

Destination

IDoc

Internet address

Folder for Outbound IDocs

Additional mail attributes

Port Description: Internet

The most important part of the port description is the internet address (IP address). Together with the

IDoc, it is passed to the internet gateway (or the Microsoft exchange server) via SAPconnect.

Further parts of the port description are the mail attributes:

a description text which can be read as the mail body the mail title of the mail body and a folder of

the owner system where outbound IDocs can be stored for control purposes.

The general settings (IDoc administration) contain the folder where exception messages on inbound

IDocs will be stored.


88/407

SAP AG CA210 4-12

SAP AG 1999

MIME-emailMIME-emailIDocIDoc

InterfaceInterface

IDoc

File

SAPoffice

SAPconnectSAPconnectIDoc

ExternalExternal

SystemSystem

Data Flow for Port Type Internet

For internet delivery, IDocs are stored in another format (SAPoffice name: R3I), a table 255 digits

wide. This table is passed by SAPconnect to

either the internet gateway (program sendmail) or

the Microsoft exchange server.

The program sendmail is already part of a UNIX operating system. It must be bought for a Windows

NT system.

The gateway (or the Microsoft exchange server) convert the IDoc table to the MIME format.

For inbound direction, data flow proceeds exactly the opposite way. Internet IDocs appear as mail

attachments in the mailbox of the addressee.

To use this port type, the following additional parameters must be set (not part of the port

description):

A SAPconnect knot must exist for the address type INT (for routing of the internet messages)

The SAPoffice user must have an address for the address type INT to be able to receive IDocs.


89/407

SAP AG CA210 4-13

SAP AG 1999

Outbound Trigger

Outbound File IDoc File

rfcexec

out.script

RFC Destination(TCP/IP Connection)

Port Description: Port Type XML

IDoc data is written not in IDoc format, but rather in XML format in a file at operating system level.

The names of XML tags refer to the IDoc record types or IDoc segments. XML is designed to be a

self-descriptive Internet-enabled language. Tags can be defined here and recorded in aDocument

Type Definition (DTD). As a result, XML is extendible and corresponds in particular to the newdefinition of IDoc types concept. IDocs in XML format can be displayed immediately with the

corresponding Internet browser.

Name and directory of the outbound trigger file (called by rfcexec) which starts the external system.

This must be set if the R/3 system is to start, or trigger, the external system (by RFC). For

triggering, one needs to define an RFC destination (e.g. SERVER_EXEC). This is done with

transaction SM59 (TCP/IP connections). This is a set up outside of the IDoc interface.

Outbound - Directory name - specify a physical directory path or a logical directory path (new with

Release 4.6x). File name - determined via a static name or via a dynamic name based on a function

module (recommended).

Choose whether the IDocs should be written together with the corresponding DTD in the XML file.

The DTD contains the tags that are used in the XML IDoc, therefore tags are for the IDoc record

types and the individual segments. The tags are named in the same way as the individual fields.

If possible, you must replace country-specific special characters such as ,, with international

characters like ae,oe,ue. In addition, you must maintain the Conversion tableand then select Convert

special characters. You must note, however, that the character strings in the segment fields can then

change length.


90/407

SAP AG CA210 4-14

SAP AG 1999

Port Type XML, e.g. Message SYPART

The above capture was manually edited with line-wraps to enhance the readability.

The file is coded with the code page of the SAP application server.

Because some Browsers are not able to display XML files containing national characters, filters can

be defined with the port definition.

Same as with port type File rfcexec and startrfc with function module EDI_DATA_INCOMING

(rfcexec.exe and startrfc.exe on Windows NT) can be used to trigger between source and destination.


91/407

SAP AG CA210 4-15

SAP AG 1999

Field 1Field 2 Field 3

2.1/2.2

3.0/3.1

4.X

Version 3

Version 2

Version 1

Field 1 Field 2 New Field 3

Field 1 Field 2

Communication with Older Releases

IDoc Record types are defined by their structure in the ABAP dictionary.

Structure definitions have changed in different releases; for instance, the extended name space was

introduced with R/3 Release 4.0. This meant that segment names can now contain 27 digits (instead

of the former 7). This caused the field - segment name - to be longer in the data record control area.

To be able to communicate with earlier releases, the port description contains the version:

Version 1: record types are exchanged with structure of Releases 2.1/2.2

Version 2: record types are exchanged with structure of Releases 3.0/3.1

Version 3: record types are exchanged with structure of Releases 4.X

In addition for the Port type tRFC, a non-R/3 system must know the correct name of the functionmodule to be called.

The R/2 system record types always have the same structure. Therefore, no version has to be

maintained for the Port Type CPI-C.


92/407

SAP AG CA210 4-16

SAP AG 1999

Ports and Port Types

IDoc Interface

External System 1 External System 2

Port 1 (e.g. TypePort 1 (e.g. Type

file)file)Port 2 (e.g. TypePort 2 (e.g. Type

file)file)Port 3 (e.g. TypePort 3 (e.g. Type

tRFC)tRFC)

IDocIDoc IDocIDoc IDocIDoc


93/407

SAP AG CA210 4-17

SAP AG 1999

Port Definitions: Unit Summary

IDocs or status records are always exchanged withan external system via ports.

The port description defines the target system and

technical communication parameters. Furthermore,

it is here where you define which R/3-Release is

understood by the receiving system.

Further parameters (also outside of the R/3 system)

have to be set to use a port.

Generally, there are six port types representing six

different communication techniques.


94/407

SAP AG CA210 4-18

Exercises

Unit: Port Definitions

Topic: Create a File Port


Create a file port

It is necessary to set up a file type port definition to indicate the path that

the data will travel from SAP to a subsystem where the data is kept in a

file until the subsystem is ready to use it or pass it to SAP.

1-1 Create a file port type for your group for the current release of the control record.

1-2 Create the outbound file parameters using the directory path of:

\usr\sap\\SYS\global\where SID is the training system id and Function

module EDI_PATH_CREATE_USERNAME.

1-3 Create the command file parameters using the logical destination of

SERVER_EXEC,the directory path of: \usr\sap\\SYS\global\where SID

is the training system id and Shell script Converter_start.

1-4 Create the inbound file parameters using the directory path of:

\usr\sap\\SYS\global\where SID is the training system id and the Inbound

file name of Inbound.

1-5 Create the status file parameters using the directory path of:

\usr\sap\\SYS\global\where SID is the training system id and the Status file

name of Status.


95/407

SAP AG CA210 4-19

Solutions

Unit: Port Definition

Topic: Create a File Port

1-1 From the SAP Easy Acces menu, open folders

Tools Business Communication IDoc IDoc Basis IDoc

Double-click "Port Definition".

1-1-1 Select or openFilefolder and the Createicon.

1-1-2 Enter the following information:

New Entries: Overview of Created Entries


Port Group##

Description Port for group ##

Select theIDoc record types SAP Release 4.x radio button underVersion.

1-2

1-2-1 Select Outbound file tab.


Parameters for Outbound File


Directory \usr\sap\\SYS\global\

Function module EDI_PATH_CREATE_USERNAME

Outbound file Blank

Select thePhysical directoryradio button


96/407

SAP AG CA210 4-20

1-3

1-3-1 Select Outbound:Trigger tab.


Parameters for Outbound: TriggerField Name Input Data

RFC Destination SERVER_EXEC


Command File Converter_start

1-4

1-4-1 Select Inbound file tab.


Parameters for Inbound File



Function module Blank

Inbound file Inbound

1-5

1-5-1 Select the Status file tab.


Parameters for Status File



Function module Blank

Status file Status

1-5-3 Press Save icon.

1-5-4 Note the newly created Port name.

_________________________________________________________


97/407

SAP AG CA210 5-1

SAP AG 1999

Partner Profiles

Contents:

Standard

Fast Entry


98/407

SAP AG CA210 5-2

SAP AG 1999

Partner Profiles: Unit Objectives

At the conclusion of this unit, you will be able to:

Explain the purpose of the process code and the

partner profiles

Execute the partner profile transaction


99/407

SAP AG CA210 5-3

SAP AG 1999

333


555


777


Inbound Invoice

Processing 101010


Advice 121212



Payment/Remittance

Process 111111

222


IDocs in the

Business Process

111

Partner

Profiles

Course Overview

General Settings


Partner Profiles: Course Overview Diagram (1)


100/407

SAP AG CA210 5-4

SAP AG 1999

IDoc Monitoring 16

Archiving IDocs 17

Working with an

EDI Subsystem 15


Conclusion 19

Partner Profiles: Course Overview Diagram (2)


101/407

SAP AG CA210 5-5

SAP AG 1999

Partner Profiles: Business Scenario

As a member of the integration team of your

company (SmartMart or NOE Foods), you areresponsible for setting up the IDoc interface.

SmartMart must define NOE Foods as its

receiving partner for the IDoc outbound

processing. You have already set up an

appropriate port.

NOE Foods must define SmartMart as a sending

partner for the inbound direction.

In both cases, you must maintain the appropriate

partner profile of the IDoc interface.


102/407

SAP AG CA210 5-6

SAP AG 1999

Partner

Application

process code

message type

Partner

receiver of notifications

General

Partner

message

Port

IDoc Type

EDI Structurereceiver of notifications

Outbound

Partnermessage

process codereceiver of notifications

Inbound

Message Control Parameters

PartnerPartner

ProfileProfile

Structure of the partner profile

There are four parts of the partner profile:

General settings: Keys are the partner taken from the master data (2 fields: number and type).

Further fields relate to this partner in general: For instance, here you must determine one user or

position to be informed in case of errors. This user is only informed if ther

ca210 - edi interface.pdf

Documents