Idoc 198 Pages

7/30/2019 Idoc 198 Pages

1/198

BC620 - SAP IDoc Interface (Technology)

BC620

R/3 System Release 46B 25.06.2002

0

7/30/2019 Idoc 198 Pages

2/198

BC620 - SAP IDoc Interface (Technology)................................................................................................................1

Copyright.................................................................................................................................................................2

Business Integration Technologies II..................................................................................................................3

Course Prerequisites............................................................................................................................................4

Target Group.......................................................................................................................................................5

Course Overview.....................................................................................................................................................1

Course Goals.......................................................................................................................................................2

Course Objective(s).............................................................................................................................................3

Course Content....................................................................................................................................................4

Course Overview Diagram..................................................................................................................................5

Main Business Scenario......................................................................................................................................6

Basic Principles.......................................................................................................................................................1

Topic Objectives.................................................................................................................................................2

IDoc Concept.......................................................................................................................................................3

IDoc Applications...............................................................................................................................................4

EDI and ALE.......................................................................................................................................................5

Process Flow: Sending Data................................................................................................................................6

IDoc Settings: Sending Data...............................................................................................................................7

Process Flow: Receiving Data.............................................................................................................................8

IDoc Settings: Receiving Data............................................................................................................................9

Basic Principles: Summary...............................................................................................................................10

IDocs in Business Processes...................................................................................................................................1

IDocs in Business Processes: Course Objectives................................................................................................2

Business scenario................................................................................................................................................3

IDoc Record Types..............................................................................................................................................4

Control record.....................................................................................................................................................5

Data Records and Segment Structures................................................................................................................6

Status Record.......................................................................................................................................................7

IDoc Record Types: Summary............................................................................................................................8

IDoc Types..........................................................................................................................................................9

Outbound and Inbound Processing...................................................................................................................10

Outbound Processing using Message Control...................................................................................................11

Direct Outbound Processing using ALE...........................................................................................................12

Inbound Processing using Workflow................................................................................................................13

Direct Inbound Processing using ALE..............................................................................................................14

IDocs in Business Processes: Summary............................................................................................................15

IDocs in Business Processes Exercise...............................................................................................................16

IDocs in Business Processes Solutions.............................................................................................................18

Documentation Tools..............................................................................................................................................1

Documentation Tools: Unit Objectives...............................................................................................................2

Overview Diagram (Sending Data).....................................................................................................................3

Business scenario................................................................................................................................................4

7/30/2019 Idoc 198 Pages

3/198

Internal and External Structures..........................................................................................................................5

Output in Various Formats I................................................................................................................................6

Output in Various Formats II..............................................................................................................................7

Documentation Tools: Summary........................................................................................................................8

Documentation Tools Exercise...........................................................................................................................9

Port Definition.........................................................................................................................................................1Port Definition: Unit Objectives.........................................................................................................................2


Port Definition: Business Scenario.....................................................................................................................4

IDoc Interface: Port Types..................................................................................................................................5

Port Definition: Port Type ..................................................................................................................................6

Process Flow: Port Type File (with Triggering).................................................................................................7

Port Type XML: Flat File and XML File............................................................................................................8

Port Type XML: Flat File and XML File (2)......................................................................................................9

Port Definition - Port Type tRFC......................................................................................................................10

Process Flow: Port Type tRFC..........................................................................................................................11

Port Definition: CPI-C (R/2 System)................................................................................................................12

Process Flow: Port Type CPI-C........................................................................................................................13

Port Definition: Internet....................................................................................................................................14

Process Flow: Port Type Internet......................................................................................................................15

Port Definition: PI.............................................................................................................................................16

Process Flow: Port Type PI...............................................................................................................................17

Communication with Older Releases................................................................................................................18Port Definition: Summary.................................................................................................................................19

Port Definition Exercise....................................................................................................................................20

Partner Profiles........................................................................................................................................................1

Partner Profiles: Unit Objectives.........................................................................................................................2


Partner Profiles: Business Scenario.....................................................................................................................4

Partner Profiles: Fields........................................................................................................................................5

Checking Partner Profiles....................................................................................................................................6

Partner Profiles: Outbound Processing I.............................................................................................................7

Partner Profiles: Outbound Processing II............................................................................................................8

Partner Profiles: Inbound Processing..................................................................................................................9

Process Codes I.................................................................................................................................................10

Process Codes II................................................................................................................................................11

Process Codes III...............................................................................................................................................12

Outbound Modes: Port Type File......................................................................................................................13

Partner Profiles Output......................................................................................................................................14

Partner Profiles: Summary................................................................................................................................15

Partner Profiles Exercise...................................................................................................................................16

The Test Tool..........................................................................................................................................................1

7/30/2019 Idoc 198 Pages

4/198

Test Tool Options................................................................................................................................................2

Test Tool Options (2)..........................................................................................................................................3

Test Tool Exercise...............................................................................................................................................4

Message Control and IDocs....................................................................................................................................1

Message Control and IDocs: Unit Objectives.....................................................................................................2

Business Scenario................................................................................................................................................3Outbound Processing using Message Control.....................................................................................................4

Message Control..................................................................................................................................................5

Condition Elements.............................................................................................................................................6

Message Processing: IDocs.................................................................................................................................7

Dispatch Times in Outb. Procg using MC..........................................................................................................8

Summary.............................................................................................................................................................9

Message Control and IDocs Exercise................................................................................................................10

Message Control and IDocs: Solution...............................................................................................................11

General Settings......................................................................................................................................................1

General Settings: Unit Objectives.......................................................................................................................2

Customizing using the IMG................................................................................................................................3

Number Ranges...................................................................................................................................................4

Event-Receiver Linkage......................................................................................................................................5

IDoc Administration: Global Parameters............................................................................................................6

IDoc Administration: User Parameters...............................................................................................................7

Fast entry.............................................................................................................................................................8

Long Names - Short Names................................................................................................................................9General Settings: Summary...............................................................................................................................10

General Settings Exercise..................................................................................................................................11

Additional Test Programs........................................................................................................................................1

Processing Tests: Unit Objectives.......................................................................................................................2

Processing Tests: Business Scenario...................................................................................................................3

Test Layers: Overview........................................................................................................................................4

Test Layers: Outbound Processing......................................................................................................................5

Test Layers: Inbound Processing........................................................................................................................6

Test Layers: Status Confirmation........................................................................................................................7

When to Test Which Function?...........................................................................................................................8

Processing Tests: Summary................................................................................................................................9

A Process Chain......................................................................................................................................................1

A Process Chain: Unit Objectives.......................................................................................................................2

A Process Chain: Business Scenario...................................................................................................................3

Purchase Orders for SmartMart...........................................................................................................................4

EDI-Relevant Master Data in Purchasing...........................................................................................................5

Standard Order for QuickDeliver........................................................................................................................6

EDI-Specific Master Data in Sales......................................................................................................................7

A Process Chain: Summary.................................................................................................................................8

7/30/2019 Idoc 198 Pages

5/198

Process Chain Exercise.......................................................................................................................................9

Statistics and Monitoring........................................................................................................................................1

Statistics and Monitoring: Unit Objectives.........................................................................................................2

Business Scenario................................................................................................................................................3

Monitoring Programs: Overview........................................................................................................................4

Selection Fields for Monitoring..........................................................................................................................5Implementing Functions......................................................................................................................................6

Status Group: Monitor/Statistics.........................................................................................................................7

Work Item Analysis............................................................................................................................................8

Statistics and Monitoring: Summary...................................................................................................................9

Statistics and Monitoring Exercise....................................................................................................................10

Statistics and Monitoring: Solution...................................................................................................................12

Workflow and IDocs...............................................................................................................................................1

Workflow and IDocs: Unit Objectives................................................................................................................2

Workflow and IDocs: Business Scenario............................................................................................................3

Inbound Processing with Workflow....................................................................................................................4

Exception Handling with Workflow...................................................................................................................5

Exceptions in Outbound Processing....................................................................................................................6

Exceptions in Inbound Processing......................................................................................................................7

Notification Concept I.........................................................................................................................................8

Notification Concept II........................................................................................................................................9

Notification Concept III.......................................................................................................................... ........ ..10

Maintaining an Organizational Structure..........................................................................................................11Integrated Inbox................................................................................................................................................12

Workflow and IDocs: Summary.......................................................................................................................13

Workflow and IDocs Exercise..........................................................................................................................14

Using an EDI Subsystem.........................................................................................................................................1

Using an EDI Subsystem: Unit Objectives.........................................................................................................2

Overview Diagram (Receiving Data)..................................................................................................................3

Business Scenario................................................................................................................................................4

EDI Subsystem: Responsibilities........................................................................................................................5

Required Fields in IDoc Inb. Processing: Control Record..................................................................................6

More Documentation...........................................................................................................................................7

Using an EDI Subsystem: Summary...................................................................................................................8

Using an EDI Subsystem Exercise......................................................................................................................9

Archiving.................................................................................................................................................................1

Archiving: Unit Objectives.................................................................................................................................2


Archiving: Business Scenario.............................................................................................................................4

Archiving Object: IDOC.....................................................................................................................................5

Status Transfers in Outbound Processing............................................................................................................6

Status Transfers in Inbound Processing..............................................................................................................8

7/30/2019 Idoc 198 Pages

6/198

Status Maintenance - Archiving..........................................................................................................................9

Archiving: Summary.........................................................................................................................................10

Course Summary...............................................................................................................................................11

Appendix.................................................................................................................................................................1

Appendix.............................................................................................................................................................2

7/30/2019 Idoc 198 Pages

7/198

0

SAP AG 1999

BC620 - SAP IDoc Interface (Technology)

SAP AG

BC620BC620SAP IDoc

Interface

(Technology)

SAP IDoc

Interface

(Technology)

Release: 4.6A Status: January 2000

Mat. No.: 5003 4022

7/30/2019 Idoc 198 Pages

8/198

0.2

SAP AG 2001

Copyright 2001 SAP AG. All rights reserved.

Neither this training manual nor any part thereof may

be copied or reproduced in any form or by any means,

or translated into another language, without the prior

consent of SAP AG. The information contained in this

document is subject to change and supplement without prior

notice.

All rights reserved.

Copyright

Trademarks:

Microsoft , Windows , NT , PowerPoint , WinWord , Excel , Project , SQL-Server ,Multimedia Viewer , Video for Windows , Internet Explorer , NetShow , and HTML Help are registered trademarks of Microsoft Corporation.

Lotus ScreenCam is a registered trademark of Lotus Development Corporation. Vivo and VivoActive are registered trademarks of RealNetworks, Inc. ARIS Toolset is a registered Trademark of IDS Prof. Scheer GmbH, 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, andALE/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.

7/30/2019 Idoc 198 Pages

9/198

0.3

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

Interface

Programming

Data Exchange

CommunicationInterfaces 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

7/30/2019 Idoc 198 Pages

10/198

0.4

SAP AG 1999

Recommended:

Basic knowledge of the R/3 System, as gained from

courses SAP20 and SAP50, for example

Course Prerequisites

7/30/2019 Idoc 198 Pages

11/198

0.5

SAP AG 1999

Participants:

Consultants

Administrators

Project team

members

Duration: 2 days

Target Group

7/30/2019 Idoc 198 Pages

12/198

1

SAP AG 1999

Course Overview

Course Goals

Course Objective(s)

Course Content

Course Overview Diagram

Main Business Scenario

Contents:

(C) SAP AG BC620 1

7/30/2019 Idoc 198 Pages

13/198

1.2

SAP AG 1999

Understand the possibilities offered by the

IDoc Interface for electronic data transfer

Use the IDoc Interface

Course Goals

This course will enable you to:

(C) SAP AG BC620 2

7/30/2019 Idoc 198 Pages

14/198

1.3

SAP AG 1999

Course Objective(s)

Configure the IDoc Interface

Trace the processing of IDocs in the

system

Select and use the correct IDoc types for

your business processes

At the conclusion of this course, you will be

able to:

(C) SAP AG BC620 3

7/30/2019 Idoc 198 Pages

15/198

1.4

SAP AG 1999

Course Content

Unit 9 General Settings

Unit 10 Further Test Programs

Unit 11 A Process Chain

Unit 12 Statistics and Monitoring

Unit 13 Workflows and IDocs

Unit 14 Using an EDI Subsystem

Unit 15 Archiving

Unit 1 Course Overview

Unit 2 Basic Principles

Unit 3 IDocs in Business Process

Unit 4 Documentation Tools

Unit 5 Port Definition

Unit 6 Partner Profiles

Unit 7 The Test Tool

Unit 8 MC and IDocs

Preface and Introduction

Exercises

Solutions

Appendix

(C) SAP AG BC620 4

7/30/2019 Idoc 198 Pages

16/198

1.5

SAP AG 1999

External SystemExternal System

Course Overview Diagram

Data flow

A Process Chain

Test,

monitoring

Message

Control,

Workflow

Archive IDoc?Archive IDoc?

EDI Subsystem?EDI Subsystem?

Partner ProfilesPartner Profiles

Port DefinitionPort Definition

Documentation

Tools

Documentation

Tools

IDocs in Business

Processes

R/3 System

The units can be divided as follows:

Units which describe how to configure the IDoc Interface

Units which describe the data flow in the R/3 System and between R/3 Systems and external

systems

The unit "Test" describes an important step in the process of configuring the IDoc Interface. The

emphasis is placed on the implementation of the test programs in the data flow.

The unit "General Settings" describes Customizing activities which, for example, create templates

for configuring the IDoc Interface. You should therefore consider this chapter to be more advanced

than the other "configuration chapters".

(C) SAP AG BC620 5

7/30/2019 Idoc 198 Pages

17/198

1.6

SAP AG 1999

Main Business Scenario

Message

IDocIDoc

QuickDeliverSmartMart

SAP R/3 SystemSAP R/3 System

EDI SubsystemEDI Subsystem EDI SubsystemEDI Subsystem


In order to reduce costs, the company SmartMart wishes to send purchase orders to QuickDeliver via

EDI. QuickDeliver wishes to immediately post these purchase orders electronically. Both companies

have R/3 Systems and must configure their IDoc Interface accordingly. The IDocs are to be

translated into another EDI standard form.

(C) SAP AG BC620 6

7/30/2019 Idoc 198 Pages

18/198

2

SAP AG 1999

Basic Principles

IDoc concept and fundamental terms

Data flow and process flows when using the IDoc Interface

Contents:

(C) SAP AG BC620 1

7/30/2019 Idoc 198 Pages

19/198

2.2

SAP AG 1999

Explain the terms IDoc, EDI and ALE

Identify the basic steps in IDoc processing

Topic Objectives

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

(C) SAP AG BC620 2

7/30/2019 Idoc 198 Pages

20/198

2.3

SAP AG 1999

IDoc Concept

Message-oriented

Asynchronous

System 1

Document

System 2

IDoc Document

IDoc is an SAP standard format for data transfer between systems. IDoc stands forIntermediate

Document. It is intermediate in two respects:

Message-oriented- Data is also stored in applications, only in other formats (the application

documents). The IDoc communicates between these application documents, as the language

spoken by both applications. It is not important whether the application is programmed by SAP or

by another third-party system.

Asynchronous - Data can be stored in IDocs before an application document is created. This is

important, for instance, when incorrect data is transferred: In this case, the application document is

only created when the data is corrected.

The IDoc Interface is available in the R/3 System from Release 2.1A onwards and in the R/2 System

from Release 5.0F.

(C) SAP AG BC620 3

7/30/2019 Idoc 198 Pages

21/198

2.4

SAP AG 1999

IDoc Applications

WorkflowWorkflow

BusinessBusinessConnectorConnector

ElectronicElectronic

FormForm

ALEALE

EDIEDI

SubsystemSubsystem

R/3 SystemR/3 System


OtherOther

Systems...Systems...

InternetInternet

IntranetIntranet

IDocIDoc

Examples of systems or applications which use IDocs:

ALE: Application Link Enabling

EDI: Electronic Data Interchange

Business Connector: Sending business documents using the Internet

(C) SAP AG BC620 4

7/30/2019 Idoc 198 Pages

22/198

2.5

SAP AG 1999

EDI and ALE

Document

IDoc

Message

IDocIDoc


EDI SubsystemEDI Subsystem EDI SubsystemEDI Subsystem


Two special IDoc application areas should be defined:

EDI: Electronic data interchange between different companies

ALE: Electronic data interchange between different systems within one company

Systems can exchange IDocs either directly (for example R/3 with R/3) or have them translated into

other standards (for example UN/EDIFACT or ANSI X.12) by EDI subsystems.

The application which uses IDocs (for EDI or ALE) must be able to write data to IDocs, or read data

from IDocs, or both.

The IDoc format is valid as an EDI standard when used for EDI. However, translating IDocs into

other standards has the advantage of allowing communication with more partners.

Within the R/3 System, only IDoc formats are used. All translations into other EDI Standards are

performed by an EDI subsystem. The advantage is that SAP applications only have to recognize the

IDoc format - not several EDI standards - and are therefore easier to maintain. The disadvantage isthat SAP do not supply an EDI subsystem and customers must purchase such a subsystem when

other EDI standards are to be used.

(C) SAP AG BC620 5

7/30/2019 Idoc 198 Pages

23/198

2.6

SAP AG 1999

Process Flow: Sending Data

Check partner, find port

Transfer data,

process further

Post document

Generate IDoc


External systemExternal system

In the following examples, data flow is always seen from the point of view of the R/3 System.

Therefore, if data is sent via IDocs from an R/3 System to an external system, the process is called

outbound processing or simply outbound.

Outbound processing includes:

Posting the application document

Generating the corresponding outbound IDoc

Finding the partner and the port

Transfer of the IDoc to the external System via the port

(C) SAP AG BC620 6

7/30/2019 Idoc 198 Pages

24/198

2.7

SAP AG 1999

IDoc Settings: Sending Data

Post document

Generate IDoc


Transfer data,

process further

Archive IDoc ?Archive IDoc ?

EDI Subsystem ?EDI Subsystem ?



Documentation

Tools

Documentation

Tools



SmartMart must configure the IDoc Interface for outbound processing:

SmartMart defines the system which will receive IDocs and the technical parameters via the port

definition.

SmartMart defines QuickDeliver as a partner for message type ORDERS in the partner profiles

and enters the port which has already been defined.

Outbound IDocs created in the R/3 System should be archivedby SmartMart and then deleted.

The documentation tools inform the EDI Subsystem which IDoc types are to be recognized.

(C) SAP AG BC620 7

7/30/2019 Idoc 198 Pages

25/198

2.8

SAP AG 1999

Process Flow: Receiving Data

Error handling

ok?

ok?

No

No

Check port & partner,

Generate IDoc

Send data to

R/3 System

transfer

Post document



Receiving data from an external system and the subsequent processing in the R/3 System is called

inboundprocessing or also inbound.

Inbound processing includes:

Receiving IDoc data from an external system via an inbound port

Creating the inbound IDoc

Finding the correct processing type via the partner profiles

Creating the application document

If an error occurs, error handling (more general: exception handling) is triggered. Exception

handling is a different kind of processing and is not part of inbound processing. There is also

exception handling for outbound processing but it is less important: For outbound processing you

should usually presume that the data being sent is correct.

(C) SAP AG BC620 8

7/30/2019 Idoc 198 Pages

26/198

2.9

SAP AG 1999

IDoc Settings: Receiving Data

Error handling

Send data to

R/3 System

Check port & partner,

generate IDoc

Post document

Port Definition,

Partner Profiles

Port Definition,

Partner ProfilesArchive IDoc ?Archive IDoc ?

Documentation

Tools

Documentation

Tools




QuickDeliver must configure the IDoc Interface for inbound processing:

The documentation tools inform the EDI Subsystem which IDoc types are to be recognized.

The port name must be maintained in the port definition before IDocs can be accepted by the R/3

System.

In the partner profiles, QuickDeliver enters SmartMart as a partner for inbound processing and the

message type ORDERS. In addition, agents responsible for error processing are entered here,

specifically for partners and messages.

Like SmartMart, QuickDeliver wishes to archive and subsequently delete inbound IDocs which have

been generated.

(C) SAP AG BC620 9

7/30/2019 Idoc 198 Pages

27/198

2.10

SAP AG 1999

IDoc is an SAP standard for data transfer between

systems.

Known implementation areas for IDocs: ALE and

EDI scenarios

The IDoc Interface facilitates both IDoc processing

and flexible error/exception handling

Basic Principles: Summary

(C) SAP AG BC620 10

7/30/2019 Idoc 198 Pages

28/198

3

SAP AG 1999

IDoc Record Types

IDoc and IDoc type

IDoc processing: Inbound and outbound

processing

IDocs in Business Processes

(C) SAP AG BC620 1

7/30/2019 Idoc 198 Pages

29/198

3.2

SAP AG 1999


IDocs in Business Processes:Course Objectives

Explain the difference between IDocs and

IDoc types

Describe the structure of an IDoc

Determine where in the business process or

the process chain the IDoc was created

(C) SAP AG BC620 2

7/30/2019 Idoc 198 Pages

30/198

3.3

SAP AG 1999

Business scenario

As a member of the implementation team for

your company (SmartMart or QuickDeliver), you

are responsible for configuring the IDoc

Interface. You must therefore understand the

basic principles behind the interface:the IDoc

format and how to embed the interface in both

outbound processing (SmartMart) and inbound

processing (QuickDeliver).

(C) SAP AG BC620 3

7/30/2019 Idoc 198 Pages

31/198

3.4

SAP AG 1999

IDoc Record Types

Status records

Data records

Control record

Each IDoc in the SAP database consists of:

One control record

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

segments.

Status records which determine the defined processing steps for the IDoc. As a result, the

number of status records for an IDoc increases as processing continues.

An IDoc for transmission to or from an external system, however, only consists of:

One control record

The data records

If the external system is to inform the R/3 System of the progress of the IDocs which were sent, a

status confirmation message is sent. The R/3 System then appends the status records which were

received to the corresponding outbound IDoc in the database. The R/3 System can also send statusconfirmation messages for IDocs. However, this is only possible via the special IDoc type

SYSTAT01, that is, no control records or data records are sent in this case. The status information is

therefore located in the data records for each IDoc!

Summary: IDocs which are transmitted between two different systems are always 'smaller' than the

IDocs in the R/3 System because they do not contain status records.

(C) SAP AG BC620 4

7/30/2019 Idoc 198 Pages

32/198

3.5

SAP AG 1999

Control record

Control record IDoc IDPartner

IDoc type and logical message

External structure

An important part of the control record is the IDoc ID, a 16-digit number which is assigned

automatically by the system. This number is used as a unique identifier for the IDoc in the R/3

System. Status confirmations also refer to this number.

The control record also contains the key fields for partner profiles: Partner and logical message (3

fields each), as well as a flag indicating whether it involves a test partner. For inbound IDocs, these

key fields determine the dependent parameters of the inbound partner profile, for example, how

inbound IDocs should be processed in the R/3 System.

The three key fields for the partner (recipient) are:

Partner number (internal number from master data in the R/3 System)

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

Partner function (important in outbound processing using Message Control, otherwise optional)

The three fields for logical messages are:Message type (corresponds to UN/EDIFACT messages if possible)

Message variant (optional)

Message function (optional)

Other fields relate to the control record, for example conversion to another EDI standard via an EDI

subsystem or an external EDI message archive.

(C) SAP AG BC620 5

7/30/2019 Idoc 198 Pages

33/198

3.6

SAP AG 1999

Data Records and Segment Structures

Data record

Control part, contains

segment names

Application data

Field 2Field 1 ...

Segment

Segment names are stored in the control part of a data record. This segment is defined as a structure

in the R/3 System.

As a result of the segment name being stored in the control part, a structure is assigned to the

unstructured section of the application data by applying the "network of application fields". This

always happens when an application reads data from an IDoc or when the application writes data to

an IDoc.

The data type of the segment fields is character.

If possible, ISO codes are used for coded fields.

(C) SAP AG BC620 6

7/30/2019 Idoc 198 Pages

34/198

3.7

SAP AG 1999

Status Record

Status Record IDoc IDStatus information

The IDoc number of the IDoc to which the status record refers is an important part of the status

record. This allows the IDoc relevant to a status conformation message to be identified in the system

and the returned status records can therefore be appended.

The first status information during processing is taken from the status value or status. This is used as

a basis for the exception handling.

More detailed information can be obtained from three fields which are used to name R/3 messages in

the standard system. If an error occurs during IDoc processing in the R/3 System, a corresponding

error message can be stored in the status record via the status value "incorrect". Example - message

SAPE0133 ("error during RFC with port X"):

SAP: R/3 message, displayed in a standard window (field STAMQU)

E0: Message class as defined in table T100 (field STAMID)

133: Message number as defined in table T100 (field STAMNO).If the first three characters refer to an external system, special messages can be displayed for the

system. However, the display must be programmed specifically and a link to the program must be

included to table TEDE3.

Other fields in the status record include the creation date, creation time and name of the program

which discovered the error during IDoc processing.

(C) SAP AG BC620 7

7/30/2019 Idoc 198 Pages

35/198

3.8

SAP AG 1999

IDoc Record Types:Summary

Control record

Data records

IDoc ID

Partner

IDoc type and logical message

External structure

Control part Application data

Status records IDoc IDStatus information

(C) SAP AG BC620 8

7/30/2019 Idoc 198 Pages

36/198

3.9

SAP AG 1999

IDoc Types

Control Record

Status Records

Data records, represented as a segment tree

E1TLSUM

E1HDADR

E1ITSCH

E1HDDOC

E1ITDOC

Elternsegment

Kindsegment

E1ITSCH

C 5

E1ITDOC

M 1

C 99

M 1

C 5

C 1

Each business process (for example a purchase order) usually corresponds to a certain IDoc type,

which can include the relevant data.

An IDoc type is defined by the segments, their hierarchy, sequence and frequency of use. This

information is contained in the control part of the data records.

The segment hierarchy can be represented in tree form as parent and child segments. This allows the

application data to be structured.

Summary: IDoc types are special data structures for special applications or messages. If such a

structure contains application data, an IDoc is created (the instance of the IDoc type).

(C) SAP AG BC620 9

7/30/2019 Idoc 198 Pages

37/198

3.10

SAP AG 1999

Outbound and Inbound Processing

Outbound Processing Inbound

IDoc Interface/ALE Services

External System

SAP Application

R/3 System

Directions are always defined from R/3. Therefore, in the outbound direction, data is sent from the

application to the external system via the IDoc Interface. For the inbound direction, the opposite is

true.

For inbound processing, the external system must be assigned certain authorizations. Documents

(IDocs and application documents) are to be created in the R/3 System.

Different options are available for both inbound and outbound processing. These options are

explained in the following slides.

(C) SAP AG BC620 10

7/30/2019 Idoc 198 Pages

38/198

3.11

SAP AG 1999

Outbound Processing using MessageControl

IDocIDoc

MCMC

recordrecord

DocumentDocument

SAP Application

Message Control (MC)

External System

IDoc Interface / ALE Services

During outbound processing using Message Control, the application sends IDocs to the IDoc

Interface via Message Control. The IDocs can be processed further (for example filtered) by the ALE

services, if required, before being sent to the port.

The IDoc Interface sends each IDoc to the subsequent system according to the technical port

definition. Examples of various port types:

External system = R/3 System: usually transactional RFC (standard ALE scenario)

External system = EDI subsystem: Usually the file interface

(C) SAP AG BC620 11

7/30/2019 Idoc 198 Pages

39/198

3.12

SAP AG 1999

Comm. IDocComm. IDocComm. IDocComm. IDoc Comm. IDocComm. IDoc

MasterIDoc

MasterIDoc

Direct Outbound Processing using ALE

SAP Application

External System

IDoc Interface / ALE Services

During direct outbound processing, the ALE services are always called. These services:

Filter the IDoc: Data not required for the communication is removed from the IDoc

Change the (segment) version: if the recipient only recognizes an earlier version of the IDoc

type, the version can be changed here. This means that less data is transported, as later versions

of IDoc types can only contain more data than former versions and never less.

Determine the IDoc recipient using a maintained distribution model, in case the application

itself did not specify the recipient.

Duplicate the IDoc, if required, for distribution models.

The ALE services create one (or more) communication IDoc(s) from one master IDoc (which is

transferred to function module MASTER_IDOC_DISTRIBUTE).Only communication IDocs are

saved in the database.

(C) SAP AG BC620 12

7/30/2019 Idoc 198 Pages

40/198

3.13

SAP AG 1999

Inbound Processing using Workflow

DocumentDocument

IDoc +IDoc +

processprocess

IDocIDoc

SAP Application

SAP Business Workflow

External System

IDoc Interface & ALE Services

The external system sends IDocs to the R/3 System. The R/3 System is addressed via the port name

SAP for example SAPC11 for an R/3 System called C11.

If the IDoc Interface recognizes the external system, the inbound IDocs are accepted and checked,

that is, a syntax check is performed and the system checks whether the sender is entered as a partner.

The IDoc is sent to the application via SAP Business Workflow according to the settings in the

partner profile.

If required, the IDoc can be processed by the ALE services before being saved in the database as an

inbound IDoc.

(C) SAP AG BC620 13

7/30/2019 Idoc 198 Pages

41/198

3.14

SAP AG 1999

IDocIDoc

Direct Inbound Processing using ALE

IDocIDoc

SAP Application

External System

IDoc Interface & ALE Services

Until the partner profile settings are read, direct inbound processing works in the same way as

inbound processing via workflow:

The IDoc is passed directly to the application function module according to the partner profile

settings.

You can also set the process code (see the Partner Profiles unit) so that the ALE services are always

called during direct inbound processing. As in the case of outbound processing, these services are

responsible for filtering and version changes. However, IDocs cannot be duplicated during inbound

processing.

When using an ALE service, the end result is only ever stored in the database. This is the

application IDoc, in contrast to the inbound communication IDoc.

(C) SAP AG BC620 14

7/30/2019 Idoc 198 Pages

42/198

3.15

SAP AG 1999

IDocs in Business Processes:Summary

Each IDoc in the R/3 database consists of one control

record and several data and status records.Only

control records and data records are exchanged with

external systems.

There are various IDoc types which are distinguished

by their segments and their order.This information is

stored in the control part of the data records.

Different processing options are available for IDocs inboth inbound and outbound processing.

(C) SAP AG BC620 15

7/30/2019 Idoc 198 Pages

43/198

3.16IDocs in Business Processes Exercise

Data for exercises:

Training system: Will be announced by the instructor (for exampleI40)

Client: 400

User: BC620-nn

Password: KURS

Ports: SUBSYSTEM of type File (default)

Data Data in training system Data in IDES

Customer side:Material SH-100 SH-100

Vendor T-BILnn 1014

Purchasing organization 1000 1000

Purchasing group 001 001

Plant 1100 1100

Vendor side:

Material SH-100 SH-100

Sold-to party T-BIK nn 1110

Order type TA

Sales organization 1020 1020

Distribution channel 22 22

Division 00 00

Delivering plant 1100 1100

nn is your group number

(C) SAP AG BC620 16

7/30/2019 Idoc 198 Pages

44/198

Unit: IDocs in Business Processes

Explain terms

Define IDoc structure

1.1 True or false:1.1.1 IDocs are always used for process chains.

1.1.2 IDocs are intermediate documents: When the application documents havebeen created, the IDocs are deleted from the R/3 System.

1.1.3 IDoc types describe how IDocs are structured.

1.1.4 There are basic rules for IDoc structures.

1.1.5 The differences between IDoc types involve more than the segments whichthey contain.

1.2 True or false:

1.2.1 In outbound processing, IDocs are always generated by the IDoc Interfaceor by the application.

1.2.2 In inbound processing, IDocs are always generated by the IDoc Interface.

1.2.3 Exception handling via workflow is not possible in outbound processing.

1.2.4 An external system has its own formats for IDoc data. There are thereforeno IDocs in the external system.

(C) SAP AG BC620 17

7/30/2019 Idoc 198 Pages

45/198

3.17IDocs in Business Processes Solutions

Unit: IDocs in Business Processes

1.1 True or false:

1.1.1 IDocs are always used for process chains.

false: Process chains can also be used within the R/3 System (for example

workflow) and can therefore be used without IDocs.

1.12 IDocs are intermediate documents: When the application documents have

been created, the IDocs are deleted from the R/3 System.

false: IDocs can only be deleted from the system when they have been

archived. The phrase intermediate document does not refer to the "life

expectancy" of an IDoc.

1.1.3 IDoc types describe how IDocs are structured.

true

1.1.4 There are basic rules for IDoc structures.

true

1.1.5 The differences between IDoc types involve more than the segmentswhich they contain.

false: IDoc types are only defined by their segments. IDocs, however, can

be distinguished by the IDoc type and their contents.

1.2 True or false:

1.2.1 In outbound processing, IDocs are always generated by the IDoc Interfaceor by the application.

true

1.2.2 In inbound processing, IDocs are always generated by the IDoc Interface.

true

1.2.3 Exception handling via workflow is not possible in outbound processing.

false: Exception handling exists for processing errors or syntax errors

when dealing with both inbound and outbound processing.

1.2.4 An external system has its own formats for IDoc data. There are thereforeno IDocs in the external system.

false: The IDoc format must at least be recognized by the external system.

In addition, "external systems" can be R/3 Systems or R/2 Systems, in

which case IDocs are always stored in the system.

(C) SAP AG BC620 18

7/30/2019 Idoc 198 Pages

46/198

4

SAP AG 1999

Documentation Tools

Record types, IDoc types, segments

Output formats

(C) SAP AG BC620 1

7/30/2019 Idoc 198 Pages

47/198

4.2

SAP AG 1999

Use the documentation tools

Decide in which situations they would be useful


Documentation Tools:Unit Objectives

(C) SAP AG BC620 2

7/30/2019 Idoc 198 Pages

48/198

4.3

SAP AG 1999

Overview Diagram (Sending Data)


Post document

Generate IDoc


Transfer data,

process further



Documentation

Tools

Documentation

Tools




SmartMart must configure the IDoc Interface for outbound processing:

Using the documentation tools, SmartMart sends information about the structure of IDoc Type

ORDERS01 to the EDI subsystem.

(C) SAP AG BC620 3

7/30/2019 Idoc 198 Pages

49/198

4.4

SAP AG 1999

Business scenario

As a member of the implementation team for your

company (SmartMart or QuickDeliver), you are

responsible for configuring the IDoc Interface.

Your EDI subsystem does not yet know the structure

of the IDoc type to be used. The IDoc Interface can

export IDoc type structures in various formats, using

the documentation tools. You must know about this

function, as you can save yourself a lot of

programming work in the EDI subsystem.

(C) SAP AG BC620 4

7/30/2019 Idoc 198 Pages

50/198

4.5

SAP AG 1999

Release3

.0

Internal and External Structures

Field 1 Field 2

Field 1 Field 2 Field 3 Field 4

Segment

internal

external

E1...

E2...001

IDoc types are distinguished by their segments, that is the structure or raster laid upon the data part

of the data record. These Segments exist in both internal and external form:

Internally as a release-independent structure (SAP names begin with E1), containing all the

defined segment fields.

Externally as a release-dependent structure (SAP names begin with E2), containing only the

segment fields defined for the specified release in the partner profile.

In addition to the segments, there are also IDoc record types, in both internal (in the R/3 database)

and external (as structures sent to the external system) forms. Both have changed in different R/3

Releases. The documentation tools only export the external structures in this case.

As a result, when running the documentation tools, you have to enter the following parameters:

The version of the external record types (as entered in the port definition)

The release of the external segment(as entered in the partner profiles)

The default values are the current release number and the relevant status record version. If you

change the values, go back to the past.

(C) SAP AG BC620 5

7/30/2019 Idoc 198 Pages

51/198

4.6

SAP AG 1999

Output in Various Formats I

?

? ?

?

IDoc types, segments and record types can be displayed in user-friendly formats which can be read

by other systems. The following display options are available:

R/3 tree display: In the case of general record types, the "tree" has only one level because the

hierarchy only exists for segments and therefore for special IDoc types.

HTML file In the IDoc administration user parameters you can set whether an external browser is

to be started or whether the SAP internal HTML control should be used.

The documentation goes beyond the structure: It also relates to the data elements behind the segment

structure fields. The documentation tools can also provide information about using individual IDoc

types.

(C) SAP AG BC620 6

7/30/2019 Idoc 198 Pages

52/198

4.7

SAP AG 1999

Output in Various Formats II

Begin

End

typedef struct z2incodx000

z2incodx000

?? ?

?

XML

Machine-readable formats are:

A simple chain of begin..end declarations which can be read by a parser

C-Header

Meta-IDoc, type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types)

Meta data for IDoc types in XML format

You start the documentation tools from the initial node of the IDoc Interface from the

Documentation menu. The parser has its own menu entry, both for record types and IDoc types.

(C) SAP AG BC620 7

7/30/2019 Idoc 198 Pages

53/198

4.8

SAP AG 1999

Documentation Tools:Summary

The documentation tools describe both the

structure and the use of different IDocs.

The structure is in the structure information.

External structures are always documented,

specifically regarding how they are exchanged

with external systems.

The output formats can be read by external

systems, so that non-R/3 Systems can quicklyrecognize the IDoc structure.

(C) SAP AG BC620 8

7/30/2019 Idoc 198 Pages

54/198

4.9Documentation Tools Exercise

Unit: Documentation Tools

Topic: Output formats

At the conclusion of these exercises, you will have:

Learned about different output formats

As a member of the EDI project team for your company, you requireinformation on IDoc type ORDERS01 for two reasons:

To prepare for a project discussion about purchase order/order via EDI.

To inform your EDI subsystem provider of this data structure.

1-1 Select Documentation IDoc types from the initial node of the IDoc interface. As youwish to use the standard and have not yet extended any IDoc types, enter the IDoc type

ORDERS01 and then select Basic type in the Development objectframe.1-2 You wish to receive all the information on the IDoc type. By selecting GotoUser

settings, you can check that all the display attributes are activated. Save your entriesand return to the initial screen.

1-3 When preparing for the discussion, you opt for the output formatHTML page due tothe convenient navigation options. Three files are generated on your PC. If you havenot changed any of the settings, these files are ORDERS01_F.HTM,ORDERS01_I.HTM and ORDERS01_D.HTM. File ORDERS01_F.HTM can beopened via Internet Explorer.

(C) SAP AG BC620 9

7/30/2019 Idoc 198 Pages

55/198

5

SAP AG 1999

Port Definition

Port types and when they are used

Port definition parameters

Communication with Older Releases

(C) SAP AG BC620 1

7/30/2019 Idoc 198 Pages

56/198

5.2

SAP AG 1999

Decide which port types should be implemented

for which external systems

Enter a port definition in the R/3 System

Determine which additional steps are required for

linking to the relevant external system

Enter special settings which are required for

communication with older R/3 releases and R/2Systems


Port Definition: Unit Objectives

(C) SAP AG BC620 2

7/30/2019 Idoc 198 Pages

57/198

5.3

SAP AG 1999

Overview Diagram (Sending Data)


Post document

Generate IDoc


Transfer data,

process further



Documentation

Tools

Documentation

Tools




The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver

wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems

and must configure their IDoc Interface accordingly.

SmartMart must configure the IDoc Interface for sending data (outbound processing or simply

outbound):

SmartMart defines the system which will receive IDocs and the technical parameters via the port

definition.

(C) SAP AG BC620 3

7/30/2019 Idoc 198 Pages

58/198

5.4

SAP AG 1999

Port Definition: Business Scenario

As a member of the implementation team for

SmartMart, you are responsible for configuring

the IDoc Interface.

You must decide which port type is suitable for

the system of your partner company

QuickDeliver.

(C) SAP AG BC620 4

7/30/2019 Idoc 198 Pages

59/198

5.5

SAP AG 1999

IDoc Interface: Port Types

IDoc Interface

CPI-C

R/2 SystemExternal System

File

IDoc/IDoc/

statusstatusIDoc/IDoc/

statusstatus

PI

IDocIDoc

?

XML

IDocIDoc

tRFC

IDocIDoc

Internet

IDocIDoc

Ports are the channels via which the IDocs are exchanged. The IDoc Interface supports six different

transmission methods. These are the port types:

"File": IDocs are written in files at an operating system level. The receiving system can read the files

here. The receiving system can also be started using the synchronous RFC. Besides IDocs (that is

data and control records), status records can also be exchanged by file.

"XML": The IDocs are written in XML format in the files. As is the case with the port type "file",

the receiving system is started via RFC, but here status records are only transferred by means of the

IDoc type SYSTAT01.

"Transactional RFC" IDocs are sent as tables. Typically here, the external system is an R/3 System

(ALE scenarios).

"CPI-C" IDocs or control records are transferred according to the CPI-C protocol, in the way it is

implemented for the IDoc Interface in the R/2 System. The external system is always an R/2 System.IDocs are always exchanged by means of the CPI-C protocol in the R/2 IDoc Interface (available

from R/2 Release 5.0F). For further information see the R/2 handbook, p53.2.

"Internet": The IDocs are written in MIME format to an e-mail attachment.

"Programming Interface (PI)": IDocs are sent as tables to one of the function modules defined. You

therefore do not leave the R/3 System via a PI port. Your function module can naturally trigger or

perform an external dispatch.

(C) SAP AG BC620 5

7/30/2019 Idoc 198 Pages

60/198

5.6

SAP AG 1999

Port Definition: Port Type "File"

Command file

Outbound file

Inbound file

Status file

IDoc file

Status report

rfcexec

out.script

RFC destination

(TCP/IP connection)

Data for technical linking is determined in the port definition for the IDoc Interface. So that a port

can be used, settings outside of the IDoc Interface must be made.

The port definition for the port type "file" includes

Name and directory of files. Only the outbound file is important, as the place and name of the file

are determined by the external system during inbound processing of IDocs or a status

confirmation. However, if you do enter a parameter for the inbound IDoc and status file, the test

tool can generate default values. It is important that the port exists every time, even if it is only

used in inbound processing, as the IDoc Interface only accepts ports that it recognizes.

Instead of the outbound file, you can also store a function module, which dynamically generates

names and thus helps to prevent files from being over-written. You can also use logical file names:

You should also see the F1 Help for the field.

Name and directory of command file that is to be called from program "rfcexec" and which should

start the external system - this file must be created so that the R/3 System can start the receiving

system automatically (= trigger) as soon as it has generated an IDoc file.

If you trigger using RFC, you require the RFC destination. This is maintained with the transaction

SM59 (TCP/IP connections). It is a setting outside of the IDoc Interface.

(C) SAP AG BC620 6

7/30/2019 Idoc 198 Pages

61/198

5.7

SAP AG 1999

Process Flow: Port Type File (with Triggering)

1

Write

IDoc file

4

Read

2

RFC

3

Call

rfcexec

out.script

1

Write

IDoc file

Status report

startrfc

in.scriptstatus.script

3

RFC

2

Call

4

Read

IDoc Interface

External System

IDoc outbound:

In step 1, a new file is generated with the transferred IDocs by the IDoc Interface. In the second step,

the program rfcexec (synchronous RFC) with the path to an executable program is called (here:

out.script) and also the path to the IDoc file. out.script thus contains the path and name of the

file as an input value. In step 3, it therefore calls the external system, which reads the file in step 4.

After successful processing of the IDoc file, the external system must delete the IDoc file. The call

command in out.script depends on the external system.

IDoc inbound:

In step 1, the external system generates an IDoc file. In step 2 it starts the R/3 System in which it

executes the program "startrfc". startrfc receives the logon parameter and the names of the function

module to be executed, the port and the path to the IDoc file. The startrfccommand can be included

in an executable program, here in.script. In step 4, the R/3 System started then processes the IDocfile and deletes it after successful processing. It is important that the external system logs on to

an R/3 System with a user which has the corresponding authorization for creating application

documents.

The status report works in exactly the same way as an inbound IDoc, except that here a status file

instead of an IDoc file is transferred.

rfcexec and startrfc are example programs for the use of the RFC library and are supplied with

this.

(C) SAP AG BC620 7

7/30/2019 Idoc 198 Pages

62/198

5.8

SAP AG 1999

Port Type XML: Flat File and XML File

EDI_DC40 004000000000030702346B 3013 ORDERS01

...

E2EDP01005 00400000000003070230000210000000200

E2EDP20 00400000000003070230000220000210323

...

E2EDPT1001 004000000000030702300002600002103BESTD

E2EDPT2001 004000000000030702300002700002604This is

The IDoc data is written in a file under the port type "XML", but in XML format. Hence the port

definition and technical structure are almost identical.

Under port type "file", no structure information at all is written in the file. The individual segments

are put in a row one after another as data records and are separated with carriage return. Thus you

also speak of a "flat file".

The fields are identified by means of their position in the individual records. Such a flat file therefore

contains as many blank characters as possible so that the fields are in the right place.

(C) SAP AG BC620 8

7/30/2019 Idoc 198 Pages

63/198

5.9

SAP AG 1999

Port Type XML: Flat File and XML File (2)

EDI_DC40

E1EDP01

E1EDP20

E1EDPT1

E1EDPT2

0040000000000307023

...

00010 001023.000...

...

23.000 19990622

...

BESTD...

...

...

This is the

purchase order text....

...

The segments are also written one after another in the XML file. But they are considerably different

to a flat file:

Segments are enclosed by start and end tags and therefore do not need to be separated by carriage

return. As the fields are also enclosed by tags, the segments are only ever as long as the data

contained requires hence there are no "unnecessary" blank characters.

As the tags can be connected with one another in XML, you can display an XML file as a tree. The

SAP system IDoc structure therefore remains in the file received and can be displayed in any XML-

compatible browser.

(C) SAP AG BC620 9

7/30/2019 Idoc 198 Pages

64/198

5.10

SAP AG 1999

Port Definition - Port Type tRFC

RFC destination

(R/3 connection)

Port name (assigned automatically)

Application server for

receiving system

Only the name of an existing logical RFC destination is entered in the port definition. The system

then generates a name for this port which consists of an "A" and a 9 digit number. The automatic

number assignment requires a number range which is configured in IDoc Interface Customizing.

There you can also set whether the numbers are to be assigned internally or by an external system.

Alternatively to port definition in the IDoc Interface, you can create tRFC ports from ALE

Customizing.

The RFC destination itself is maintained with the transaction SM59 as the "R/3 connection".

(C) SAP AG BC620 10

7/30/2019 Idoc 198 Pages

65/198

5.11

SAP AG 1999

Process Flow: Port Type tRFC

IDoc Interface

External System

RFC Interface

RFC Interface

TCP/IP

For tRFC a system calls a function module in a second system. It follows for the IDoc data exchange

that the sending system is always the active system: It calls the function module in the receiving

system and transfers the IDocs as tables. The function modules are therefore inbound function

modules of the respective system.

Inbound function modules in the IDoc Interface are the function modules

INBOUND_IDOC_ASYNCHRONOUS (new for Release 4.0) and INBOUND_IDOC_PROCESS

(older releases). Therefore if you want to send IDocs from a 4.0 System to an older R/3 release, you

must call INBOUND_IDOC_PROCESS there: This is set via the port version.

Non-R/3 Systems require the R/3 RFC library. The external RFC Interface can be generated for the

function module from the development environment (transaction SE37) (menu: Utilities -> RFC

Interface -> Generate). If a non-R/3 System wants to be able to receive IDocs by tRFC, it still needs

a function module that is configured like INBOUND_IDOC_ASYNCHRONOUS orINBOUND_IDOC_PROCESS.

All IDocs transferred are saved asynchronously in the database using the single COMMIT WORK

command.

For further information see the ALE documentation (underR/3 Library->CA-Business Framework)

(C) SAP AG BC620 11

7/30/2019 Idoc 198 Pages

66/198

5.12

SAP AG 1999

Port Definition: CPI-C (R/2 System)

Host destination

RFC destination

Technical parameters

Send status records?

sideinfo-entry

Host on R/2

TXCOM entry

The logical destination and the host destination are determined in the port definition. The RFCdestination is created with the transaction SM59 and contains the logon data (name, password). Thehost destination indicates an entry in the R/3 internal table TXCOM.

The TXCOM entry refers to a gateway. The logical destination is assigned a logical uniton the R/2side in a sideinfo-file of this gateway. The logical unitis part of the network architecture SNA andidentifies computers or also programs to be started.

Besides the target system, the port definition also contains technical parameters like the buffer sizeof the CPI-C data buffer or a flag showing whether the R/2 System should send a confirmation ofreceipt.

Note that for this port type not only the name, but rather also technical parameters are also importantfor inbound processing. The reason for this is that the R/2 System is always passive, that is, the R/3

System also collects the IDocs from the R/2 System under inbound processing. The exact functions and configuration of this port type can be found

In the R/2 manual S53.2 (IDoc Interface). Unit 8 of the manual describes in detail how the sendingand receiving side of the CPI-C connection in an EDI subsystem are configured

In the R/3 OSS note 61524 and

In the R/2 OSS notes 52553 and 57014.

(C) SAP AG BC620 12

7/30/2019 Idoc 198 Pages

67/198

5.13

SAP AG 1999

Process Flow: Port Type CPI-C

R/2 IDoc Interface

LU 6.2

TCP/IP

2.2. Retrieve/send IDocs orRetrieve/send IDocs or

receive/send statusreceive/send status

recordsrecords

CPI-C

1.

Communication

structure

R/3 IDoc Interface

The R/2 System is always passive, the communication is always started from the R/3 System. The

data bindings supported are:

R/3 outbound, IDoc from R/3 to the R/2 (R/3 sends IDocs: from R/2 Rel. 5.0F, from R/3 Rel. 3.0)

R/3 inbound, IDoc from R/2 to R/3 (R/3 receives IDocs: from R/2 Rel. 5.0F, from R/3 Rel. 3.1)

Status report (R/3 sends exactly one status record per IDoc: from R/2 Rel. 5.0F, from R/3 Rel. 3.1)

Status report (R/3 receives exactly one status record per IDoc: from R/2 Rel. 5.0H, from R/3 Rel.

3.1)

The CPI-C protocol commands are used (Common User Programming Interface). The gateway

converts the CPI commands into:

LU 6.2 protocol commands to the R/2 side (IBM mainframe)

TCP/IP protocol commands to the R/3 side (client/server systems)

The IDocs are saved synchronously in the database.

(C) SAP AG BC620 13

7/30/2019 Idoc 198 Pages

68/198

5.14

SAP AG 1999

Port Definition: Internet

Internet address

Folder name for outbound IDocs

Additional mail attributes

Internet destination

The most important part of the port definition is the Internet address (IP address). Together with the

IDoc it is transferred via SAPconnect to the Internet gateway (or the Microsoft Exchange server).

Furthermore, the port definition contains mail attributes:

- an explanatory text which can be read first when receiving a mail as the mail body

- the title of the mail in the mail header

- the name of a folder in which IDocs to be sent can be saved in the original system for control

purposes.

The general settings (IDoc Administration) contain the name of the folder where mails with the

inbound IDocs are saved. Normal IDoc inbound processing can only be started from this folder.

(C) SAP AG BC620 14

7/30/2019 Idoc 198 Pages

69/198

5.15

SAP AG 1999

Process Flow: Port Type Internet

IDoc Interface

SAPoffice/SAPconnect

External System

IDocIDoc

MIME e-mail

For sending via the Internet, IDocs are converted to another format (SAPoffice name: R3I): a table

with 255 characters. This table is transferred by SAPconnect:

To the Internet gateway (sendmailprogram), or

To the Microsoft Exchange server.

The gateway (or the Exchange server) converts the IDoc table into MIME format.

For inbound processing, the procedure is reversed. Internet IDocs are displayed to the relevant users

as mail attachments in SAPoffice.

To use this port type, the following parameters must be entered:

A SAPconnect node for address type INT (Internet) must be configured (for forwarding and

managing Internet messages)

The user must have a SAPoffice address for address type INT to receive IDocs

The recipient of an Internet IDoc forwards this to the dummy user EDI USER (see theHelp on the

application in the port definition: Configure the SAPoffice user address for the Internet

(C) SAP AG BC620 15

7/30/2019 Idoc 198 Pages

70/198

5.16

SAP AG 1999

Port Definition: PI

Function module:

Name and description

Own

function module

in the R/3 System

For a port of type "programming interface", only enter the name of the function module to be called

for outbound processing.

In this ABAP function module you can program any type of processing. Only the interface is

standard.

The standard system includes the function module OWN_FUNCTION as an example.

(C) SAP AG BC620 16

7/30/2019 Idoc 198 Pages

71/198

5.17

SAP AG 1999

Process Flow: Port Type PI

IDoc Interface

Own function module

IDocIDoc

Outbound Processing

The IDoc Interface calls the function module and transfers the IDoc control records in table format.

Further processing (reading data, processing data, writing status records) is programmed by the user.

Inbound Processing

Your function module must call the SAP function module IDOC_INBOUND_ASYNCHRONOUS,

which saves the IDocs in the database and triggers the event. This event asynchronously starts

inbound processing.

(C) SAP AG BC620 17

7/30/2019 Idoc 198 Pages

72/198

5.18

SAP AG 1999

Communication with Older Releases

Field 1 Field 2

Field 1 Field 2

Field 2

2.1/2.2

3.0/3.1

4.X

New field 3

Field 1 Field 3

Differences in IDoc record types

The IDoc record types are defined in the dictionary by their structure.

Structures have changed in different releases, with names becoming longer and new fields being

added.

Example: For R/3 Release 3.0, the partner function was included in the control record.

To be able to communicate with earlier releases, the version is specified in the port definition:

Version 1: Record types are transferred using the Releases 2.X structure

Version 2: Structure of Release 3.X

Version 3: Structure of Release 4.X

For port type "tRFC", a non-R/3 System must also recognize the function module to be called, as

well as the correct record types: INBOUND_IDOC_ASYNCHRONOUS (new in Release 4.0) or

INBOUND_IDOC_PROCESS (older releases).

As record types in the R/2 System always have the same structure, no version must be maintained for

port type CPI-C. The structure is covered by R/3 Release 3.0/3.1 (version 2).

(C) SAP AG BC620 18

7/30/2019 Idoc 198 Pages

73/198

5.19

SAP AG 1999

Port Definition: Summary

IDocs or status records are always exchanged with an

external system via a port.

In the port definition for the IDoc Interface, users define

the target system and the technical communication

parameters. In addition, users can specify the release

status for the external system via the version entry.

Additional technical settings must also be entered (also

outside R/3), before a port can be used.

There are six basic communication techniques for theIDoc Interface, represented by the six different port

types.

(C) SAP AG BC620 19

7/30/2019 Idoc 198 Pages

74/198

5.20Port Definition Exercise

Unit: Port Definition

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

Create a port

You are a member of the EDI project team. The decision has been madeto connect t