BC620 - SAP Idoc Interface Technology (Englisch)

BC620 - SAP IDoc Interface (Technology) BC620

R/3 System Release 46B 25.06.2002

0

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

Copyright ........................................................................................................................................................... 0-2

Business Integration Technologies II ............................................................................................................. 0-3

Course Prerequisites ....................................................................................................................................... 0-4

Target Group .................................................................................................................................................. 0-5

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

Course Goals .................................................................................................................................................. 1-2

Course Objective(s) ........................................................................................................................................ 1-3

Course Content ............................................................................................................................................... 1-4

Course Overview Diagram ............................................................................................................................. 1-5

Main Business Scenario ................................................................................................................................. 1-6

Basic Principles .................................................................................................................................................. 2-1

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

IDoc Concept ................................................................................................................................................. 2-3

IDoc Applications .......................................................................................................................................... 2-4

EDI and ALE ................................................................................................................................................. 2-5

Process Flow: Sending Data ........................................................................................................................... 2-6

IDoc Settings: Sending Data .......................................................................................................................... 2-7

Process Flow: Receiving Data ....................................................................................................................... 2-8

IDoc Settings: Receiving Data ....................................................................................................................... 2-9

Basic Principles: Summary .......................................................................................................................... 2-10

IDocs in Business Processes .............................................................................................................................. 3-1

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

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

IDoc Record Types ........................................................................................................................................ 3-4

Control record ................................................................................................................................................ 3-5

Data Records and Segment Structures ........................................................................................................... 3-6

Status Record ................................................................................................................................................. 3-7

IDoc Record Types: Summary ....................................................................................................................... 3-8

IDoc Types ..................................................................................................................................................... 3-9

Outbound and Inbound Processing .............................................................................................................. 3-10

Outbound Processing using Message Control .............................................................................................. 3-11

Direct Outbound Processing using ALE ...................................................................................................... 3-12

Inbound Processing using Workflow ........................................................................................................... 3-13

Direct Inbound Processing using ALE ......................................................................................................... 3-14

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

IDocs in Business Processes Exercise .......................................................................................................... 3-16

IDocs in Business Processes Solutions ........................................................................................................ 3-18

Documentation Tools ......................................................................................................................................... 4-1

Documentation Tools: Unit Objectives .......................................................................................................... 4-2

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

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

Internal and External Structures ..................................................................................................................... 4-5

Output in Various Formats I .......................................................................................................................... 4-6

Output in Various Formats II ......................................................................................................................... 4-7

Documentation Tools: Summary ................................................................................................................... 4-8

Documentation Tools Exercise ...................................................................................................................... 4-9

Port Definition.................................................................................................................................................... 5-1

Port Definition: Unit Objectives .................................................................................................................... 5-2


Port Definition: Business Scenario ................................................................................................................ 5-4

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

Port Definition: Port Type .............................................................................................................................. 5-6

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

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

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

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

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

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

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

Port Definition: Internet ............................................................................................................................... 5-14

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

Port Definition: PI ........................................................................................................................................ 5-16

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

Communication with Older Releases ........................................................................................................... 5-18

Port Definition: Summary ............................................................................................................................ 5-19

Port Definition Exercise ............................................................................................................................... 5-20

Partner Profiles ................................................................................................................................................... 6-1

Partner Profiles: Unit Objectives.................................................................................................................... 6-2


Partner Profiles: Business Scenario ................................................................................................................ 6-4

Partner Profiles: Fields ................................................................................................................................... 6-5

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

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

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

Partner Profiles: Inbound Processing ............................................................................................................. 6-9

Process Codes I ............................................................................................................................................ 6-10

Process Codes II ........................................................................................................................................... 6-11

Process Codes III ......................................................................................................................................... 6-12

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

Partner Profiles Output ................................................................................................................................. 6-14

Partner Profiles: Summary ........................................................................................................................... 6-15

Partner Profiles Exercise .............................................................................................................................. 6-16

The Test Tool ..................................................................................................................................................... 7-1

Test Tool Options ........................................................................................................................................... 7-2

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

Test Tool Exercise ......................................................................................................................................... 7-4

Message Control and IDocs ............................................................................................................................... 8-1

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

Business Scenario .......................................................................................................................................... 8-3

Outbound Processing using Message Control ................................................................................................ 8-4

Message Control ............................................................................................................................................ 8-5

Condition Elements ........................................................................................................................................ 8-6

Message Processing: IDocs ............................................................................................................................ 8-7

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

Summary ........................................................................................................................................................ 8-9

Message Control and IDocs Exercise ........................................................................................................... 8-10

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

General Settings ................................................................................................................................................. 9-1

General Settings: Unit Objectives .................................................................................................................. 9-2

Customizing using the IMG ........................................................................................................................... 9-3

Number Ranges .............................................................................................................................................. 9-4

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

IDoc Administration: Global Parameters ....................................................................................................... 9-6

IDoc Administration: User Parameters .......................................................................................................... 9-7

Fast entry ........................................................................................................................................................ 9-8

Long Names - Short Names ........................................................................................................................... 9-9

General Settings: Summary .......................................................................................................................... 9-10

General Settings Exercise ............................................................................................................................ 9-11

Additional Test Programs ................................................................................................................................ 10-1

Processing Tests: Unit Objectives ................................................................................................................ 10-2

Processing Tests: Business Scenario ............................................................................................................ 10-3

Test Layers: Overview ................................................................................................................................. 10-4

Test Layers: Outbound Processing ............................................................................................................... 10-5

Test Layers: Inbound Processing ................................................................................................................. 10-6

Test Layers: Status Confirmation ................................................................................................................. 10-7

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

Processing Tests: Summary ......................................................................................................................... 10-9

A Process Chain ............................................................................................................................................... 11-1

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

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

Purchase Orders for SmartMart.................................................................................................................... 11-4

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

Standard Order for QuickDeliver ................................................................................................................. 11-6

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

A Process Chain: Summary ......................................................................................................................... 11-8

Process Chain Exercise ................................................................................................................................ 11-9

Statistics and Monitoring ................................................................................................................................. 12-1

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

Business Scenario ........................................................................................................................................ 12-3

Monitoring Programs: Overview ................................................................................................................. 12-4

Selection Fields for Monitoring ................................................................................................................... 12-5

Implementing Functions............................................................................................................................... 12-6

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

Work Item Analysis ..................................................................................................................................... 12-8

Statistics and Monitoring: Summary ............................................................................................................ 12-9

Statistics and Monitoring Exercise ............................................................................................................. 12-10

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

Workflow and IDocs ........................................................................................................................................ 13-1

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

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

Inbound Processing with Workflow ............................................................................................................. 13-4

Exception Handling with Workflow ............................................................................................................ 13-5

Exceptions in Outbound Processing ............................................................................................................. 13-6

Exceptions in Inbound Processing ............................................................................................................... 13-7

Notification Concept I .................................................................................................................................. 13-8

Notification Concept II ................................................................................................................................ 13-9

Notification Concept III ............................................................................................................................. 13-10

Maintaining an Organizational Structure ................................................................................................... 13-11

Integrated Inbox ......................................................................................................................................... 13-12

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

Workflow and IDocs Exercise ................................................................................................................... 13-14

Using an EDI Subsystem ................................................................................................................................. 14-1

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

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

Business Scenario ........................................................................................................................................ 14-4

EDI Subsystem: Responsibilities ................................................................................................................. 14-5

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

More Documentation ................................................................................................................................... 14-7

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

Using an EDI Subsystem Exercise ............................................................................................................... 14-9

Archiving ......................................................................................................................................................... 15-1

Archiving: Unit Objectives .......................................................................................................................... 15-2

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

Archiving: Business Scenario ...................................................................................................................... 15-4

Archiving Object: IDOC .............................................................................................................................. 15-5

Status Transfers in Outbound Processing ..................................................................................................... 15-6

Status Transfers in Inbound Processing ....................................................................................................... 15-7

Status Maintenance - Archiving ................................................................................................................... 15-8

Archiving: Summary .................................................................................................................................... 15-9

Course Summary ........................................................................................................................................ 15-10

Appendix .......................................................................................................................................................... 16-1

Appendix ...................................................................................................................................................... 16-2

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

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, Saarbrücken

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.

SAP AG 1999

Business Integration Technologies II

Business IntegrationTechnology

BC095 3 days

Level 2 Level 3

Building Enterprise Solutions with SAPComponents

CA150 2 days

Data Transfer

BC420 5 days

Programming with BAPIs in Visual Basic

CA925 5 days

R/3 Interface and BAPIProgramming in C++

CA927 5 days

Application Link Enabling (ALE) Technology

BC619 3 days

EDI Interface

CA210 4 days

Interface

Programming

Data Exchange

Communication Interfaces in ABAP

BC415 2 days

Programming with BAPIs in JAVA

CA926 5 days

SAP IDoc Interface -Development

BC621 1 day

SAP IDoc InterfaceTechnology

BC620 2 days

SAP AG 1999

Recommended:

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

courses SAP20 and SAP50, for example

Course Prerequisites

SAP AG 1999

Participants:

Consultants

Administrators

Project team

members

Duration: 2 days

Target Group

(C) SAP AG BC620 1-1

SAP AG 1999

Course Overview

Course Goals

Course Objective(s)

Course Content

Course Overview Diagram

Main Business Scenario

Contents:


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:


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:


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


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".


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.


SAP AG 1999

Basic Principles

IDoc concept and fundamental terms

Data flow and process flows when using the IDoc Interface

Contents:


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:


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 for Intermediate

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.


SAP AG 1999

IDoc Applications

WorkflowWorkflow

BusinessBusiness

ConnectorConnector

ElectronicElectronic

FormForm

ALEALE

EDI EDI

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


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 is

that SAP do not supply an EDI subsystem and customers must purchase such a subsystem when

other EDI standards are to be used.


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


SAP AG 1999

IDoc Settings: Sending Data

Post document

Generate IDoc


Transfer data,

process further

Archive IDoc ?Archive IDoc ?

EDI Subsystem ?EDI Subsystem ?

Partner ProfilesPartner Profiles

Port DefinitionPort Definition

Documentation

Tools

Documentation

Tools


External SystemExternal System

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 archived by SmartMart and then deleted.

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


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

inbound processing 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.


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 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


SAP AG 1999

IDoc Record Types

IDoc and IDoc type

IDoc processing: Inbound and outbound

processing

IDocs in Business Processes


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


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).


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 status

confirmation 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.


SAP AG 1999

Control record

Control record IDoc ID

Partner

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.


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.


SAP AG 1999

Status Record

Status Record IDoc ID

Status 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.


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 ID

Status information


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 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 3-11

SAP AG 1999

Outbound Processing using Message Control

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 3-12

SAP AG 1999

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

Mas

ter

IDo

cM

as

ter

IDo

c

Direct Outbound Processing using ALE

SAP Application

External System


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 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<SID> 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 3-14

SAP AG 1999

IDocIDoc

Direct Inbound Processing using ALE

IDocIDoc

SAP Application

External System


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 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 in

both inbound and outbound processing.

(C) SAP AG BC620 3-16

IDocs in Business Processes Exercise

Data for exercises:

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

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-BIKnn 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 3-17

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 have

been 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 which

they contain.

1.2 True or false:

1.2.1 In outbound processing, IDocs are always generated by the IDoc Interface

or 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 therefore

no IDocs in the external system.

(C) SAP AG BC620 3-18

IDocs 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 segments which

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 Interface

or 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 therefore

no 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 3-19


SAP AG 1999

Documentation Tools

Record types, IDoc types, segments

Output formats


SAP AG 1999

Use the documentation tools

Decide in which situations they would be useful


Documentation Tools: Unit Objectives


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.


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.


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”.


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.


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.


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 quickly

recognize the IDoc structure.


Documentation 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 require

information 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

you wish 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 object frame.

1-2 You wish to receive all the information on the IDoc type. By selecting Goto User

settings, you can check that all the display attributes are activated. Save your entries

and return to the initial screen.

1-3 When preparing for the discussion, you opt for the output format HTML page due to

the convenient navigation options. Three files are generated on your PC. If you have

not changed any of the settings, these files are ORDERS01_F.HTM,

ORDERS01_I.HTM and ORDERS01_D.HTM. File ORDERS01_F.HTM can be

opened via Internet Explorer.


SAP AG 1999

Port Definition

Port types and when they are used

Port definition parameters

Communication with Older Releases


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/2

Systems


Port Definition: Unit Objectives


SAP AG 1999



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.


SAP AG 1999

Port Definition: Business Scenario


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.


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.


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.


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.script

status.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 “startrfc”command can be included

in an executable program, here “in.script”. In step 4, the R/3 System started then processes the IDoc

file 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.


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.


SAP AG 1999

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

EDI_DC40

E1EDP01

E1EDP20

E1EDPT1

E1EDPT2

<EDI_DC40 SEGMENT="1"><TABNAM><![CDAT

A[EDI_DC40]]></TABNAM><MANDT>004</MAN

DT><DOCNUM>0000000000307023</DOCNUM>

...

<E1EDP01 SEGMENT="1"><POSEX>00010 </POS

EX><ACTION>001</ACTION><PSTYP>0</PSTYP

><MENGE>23.000</MENGE>...

...

<E1EDP20 SEGMENT="1"><WMENG>23.000 </W

MENG><EDATU>19990622</EDATU></E1EDP2>

...

<E1EDPT1 SEGMENT="1"><TDID>BEST</TDID>

<TSSPRAS>D</TSSPRAS>...

...

...

<E1EDPT2 SEGMENT="1"><TDLINE>This is the

purchase order text.</TDLINE>...

...

</E1EDPT1> </E1EDP01>

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 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 5-11

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 or

INBOUND_IDOC_PROCESS.

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

command.

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

(C) SAP AG BC620 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 RFC

destination is created with the transaction SM59 and contains the logon data (name, password). The

host 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 unit on the R/2

side in a sideinfo-file of this gateway. The logical unit is part of the network architecture SNA and

identifies computers or also programs to be started.

Besides the target system, the port definition also contains technical parameters like the buffer size

of the CPI-C data buffer or a flag showing whether the R/2 System should send a confirmation of

receipt.

Note that for this port type not only the name, but rather also technical parameters are also important

for 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 sending

and 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 5-13

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 5-14

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 5-15

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 (sendmail program), 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 the Help on the

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

(C) SAP AG BC620 5-16

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 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 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 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 the

IDoc Interface, represented by the six different port

types.

(C) SAP AG BC620 5-20

Port 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 made

to connect the EDI subsystem to the R/3 System via the file (port type

"File").

1-1 Create a new port: From the initial node of the IDoc Interface, select IDoc Port

definition, choose File and select Create.

You should use the port name PORT-nn. As the first test does not involve triggering,

you only have to maintain the Outbound file tab page. Ensure that the file names can

be generated dynamically. Select the logical directory EDI_GLOBAL_PATH and a

suitable function module. Leave the Outbound file field empty.

From the Outbound file tab page, check the settings using the corresponding

pushbutton (check icon). Save your entries.

<SID> is the 3-character system ID (for example I40)

nn is the number of your group (01 to 18)


SAP AG 1999

Partner Profiles

Standard partner profiles

Checking Partner Profiles

Fast entry


SAP AG 1999

Partner Profiles: Unit Objectives


Explain the purpose of partner profiles and

process codes

Maintain partner profiles


SAP AG 1999



Post document

Generate IDoc


Transfer data,

process further


EDI Subsystem?EDI Subsystem?

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,

use EDI subsystems and must configure their IDoc Interface accordingly.

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

outbound):

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

enters the port which has already been defined.


SAP AG 1999

Partner Profiles: Business Scenario

SmartMart must define QuickDeliver as a partner.

You have already configured a suitable port in the

port definition.

In outbound processing, QuickDeliver is the partner

for the purchase order. In outbound processing, it

is the partner for the order acknowledgment.


The IDoc partner profile is divided into four areas:

General partner profile: Contains partner data from the master data as a key (2 fields: Number and type).

Additional general parameters: For example, "party to be notified" when an error occurs if no special settings

have been entered (in outbound or inbound).

Outbound partner profile (general): 3 keys are used - partner (3 fields: number, type, function), logical message

(3 fields: (type, code, function) and the test flag. The partner refers to the general partner profile. Additional

parameters: For example, the outbound port and IDoc type. This means that the values for partner, message and

test flag define the port and IDoc type in a unique way.

The outbound processing values must always be maintained, regardless of the type of outbound processing

used (direct or using Message Control).

Additional parameters for outbound processing under Message Control (MC): This type of outbound

processing (applied in MM and SD) uses the MC key (from the condition record): Application key and output

type. The partner key part consists of the partner type and function and is taken from the general partner

profile. You must ensure that you enter the correct partner function, that is, the one the application uses to call

Message Control.

Caution: The output type has nothing to do with the logical message in the IDoc interface.

Inbound partner profile: The same 7 key fields which are included in the outbound partner profile are used in

this case. The partner refers to the general partner profile. Additional parameters: For example, the process

code which defines the type of inbound processing (business process). Summary: Partner, message and test

flag define the business process in a unique way.


Partner profiles can be checked for consistency. This function is reached via a pushbutton from the

partner profile initial screen.

You should ensure that both parts of the outbound partner profile are maintained: The "outbound

parameter" (general) part and the "Message Control" part: If the Message Control part is missing, a

warning is always displayed, even if this part is not required because the system cannot recognize

whether or not this part is needed. If you do not require the Message Control part, you should simply

ignore this warning message.


SAP AG 1999

Partner Profiles: Outbound Processing I

IDocIDoc

MCMC

recordrecord

DocumentDocument

DocumentDocument

SAP Application

MC

Receiving System


MC settingsMC settings

General+outboundGeneral+outbound

The company SmartMart wishes to send purchase orders from module MM to QuickDeliver. IDoc

outbound processing must therefore be configured. In the MM module, outbound processing always

takes place using Message Control (MC). As a result, SmartMart must maintain the following parts

of the partner profile for QuickDeliver:

General partner profile: Here, the name QuickDeliver is entered as the partner number using the

form in which it appears in the master data. The partner type is LI: This identifies QuickDeliver as

a vendor in the R/3 System.

Outbound processing (general): Partner number and partner type are entered from the general

settings. Additional parameter: Partner function LF (vendor): This function must be entered as it

refers to the corresponding key in the MC record. The message type is ORDERS.

Additional parameters for outbound processing under MC: The partner function and message type

are entered from the general outbound settings. MC-specific keys are the application EF

(purchasing) and the output type NEW (in contrast to change messages).

The message type is to be used productively. As a result, the test flag is not set.

Note: Only the key fields are considered here!


SAP AG 1999

Partner Profiles: Outbound Processing II

Process code: ME10

Message: ORDERS

Partner: QD; Output type: ORDERS

Port: SUBSYSTEM Permitted agent:

IDoc type: ORDERS01 EDI agent for partner

QuickDeliver (QD) (purchase orders)

General

Outbound

MC

settings

Partner: QD ; Appl: EF; OtptType : NEW Object type,

language,...

Partner: QD ; Appl: EF; OtptType : NEW

MC record

As always, the key fields determine the contents of the other fields. As a result, when SmartMart

sends an order to QuickDeliver, the partner profiles have the following effect:

Message Control (MC) creates a data record containing the application EF, output type NEW and the

partner QuickDeliver. In the MC settings for the partner profile, these key fields define the process

code ME10 and the message ORDERS.

The process code specifies the function module which inserts the order data in the IDoc type. The

message ORDERS and partner QuickDeliver are assigned to the corresponding fields in the general

partner profiles, which are the key fields in this case. They determine that the IDoc type ORDERS01

is to be used (that is, will contain the application data); as well as the outbound port.

Summary: In conclusion, the MC record determines the IDoc type, port and function module, hence

the entire outbound processing. There are other dependent fields such as "permitted agents" for

notifications.

The appendix contains a set of common combinations of MC and partner profile fields.


SAP AG 1999

Partner Profiles: Inbound Processing

Process code:

ORDR; Permitted agents: EDI

agent for partner

QuickDeliver, order

acknowledgments

IDoc

Control Record

Inb. Processing

Partner: QD; Message: ORDRSPIDoc type:

ORDERS01

Partner: QD; Message: ORDRSP

SmartMart wants to be able to receive and process EDI order acknowledgments from QuickDeliver

for their purchase orders. IDoc inbound processing must therefore be configured. As a result,

SmartMart must still maintain the inbound part of the partner profile for QuickDeliver. Partner

number and partner type are entered from the general settings. The message type is ORDRSP

(order confirmation). The message is to be received productively. As a result, the test flag is not set.

As well as these key fields, the process code ORDR is an important data field.

If QuickDeliver now sends an order acknowledgment to SmartMart, the partner profiles have the

following effect:

In the control record, the inbound IDoc contains the partner QuickDeliver and the message

ORDRSP, which are assigned to the corresponding fields in inbound processing. Together with the

test flag (also part of the control record), these key fields uniquely determine the process code.

The process code specifies the function module which reads the data from the inbound IDoc.

Summary: The IDoc type determines the inbound processing for the IDoc. There are other dependent

fields such as recipients of notifications.

(C) SAP AG BC620 6-10

SAP AG 1999

Process Codes I

Partner

Application

Mess.type

Process code

Example: MC parameters in partner profilesProcess codeFunction module (writes the application

data in an outbound IDoc)

A process code is only another name for a process carried out by a function module or a workflow.

IDocs are processed in these cases, that is data is written to the IDocs or read from the IDocs.

The partner profiles only contain the process codes, never the real name of the function module. You

can therefore replace an old process with a new one for all relevant partners in one single step:

Assigning the new process to the existing process code.

Partner profiles contain process codes for inbound and outbound processing. In addition, process

codes for error handling are configured in the IDoc Interface, which do not save any work in the

above sense. They were introduced for completeness, so that all processes connected to the IDoc

Interface can be processed via a process code.

Only one process code exists for outbound processing when Message Control (MC) is used (because

the direct way simply sends an IDoc to the IDoc Interface). This process code always identifies a

function module.

Note: Process codes are client-specific!

(C) SAP AG BC620 6-11

SAP AG 1999

Process code

Process Codes II

Partner

Message

Process code

Example: Inbound

Function module/workflow (reads data from an

inbound IDoc and processes data further)

The inbound partner profiles always contain a process code which specifies either a workflow or a

function module (direct processing).

There are two types of process codes for error handling:

System: Error handling for IDoc processing (both inbound and outbound)

Process code status: Error handling for status confirmation

All process codes are assigned to processes via the Control menu in the IDoc Interface.

See the online documentation for more information about process codes.

(C) SAP AG BC620 6-12

SAP AG 1999

Process Codes III

Documentation via messages

Process code

Message

n

m

In order to find the correct process code for your business process, search for it via the "logical"

message (for example ORDERS for a purchase order).

Then choose Documentation Process code from the initial node of the IDoc Interface.

There is an n:m relationship between process codes and message types. For new definitions of

business processes or IDoc types you determine new process codes or messages in the assignment

table (see BC621).

(C) SAP AG BC620 6-13

SAP AG 1999

Outbound Modes: Port Type File

Description

Transfer single IDoc +

start external system (trigger)

Transfer single IDoc;

no trigger

Transfer multiple IDocs + start

external system (trigger)

Transfer multiple IDocs;

no trigger

Partner

profile

The transfer time is only defined if the external system is triggered, which helps maintain data

consistency.

Non-triggered data transfer includes the danger that IDoc or status files may be processed several

times or not processed at all.

Other port types always include external system triggering (because the IDocs are not saved

temporarily in files but transferred directly). Only outbound modes which include triggering are

displayed here.

The IDoc Interface programs use sequential numbers for outbound modes: field OUTMOD has

values from 1 to 4 (read from top to bottom in the diagram).

(C) SAP AG BC620 6-14

SAP AG 1999

Partner Profiles Output

Display

Partner profiles can be displayed in the R/3 System (the same initial access as create). A link from

the Utilities menu leads to the tree output which provides a clear means of display, even for several

partners.

The tree can be printed from the menu System->List. Also check the "application help" in the

transaction.

Partner profiles can also be sent via the special IDoc type SYPART01. A partner profile for this

IDoc type with the "logical" message SYPART is therefore a prerequisite.

(C) SAP AG BC620 6-15

SAP AG 1999

Partner Profiles: Summary

Partner profiles specify which messages are sent to which

users, using which method and how they are processed.

Partners must be entered in the partner profile before IDocs can

be sent successfully.

The port (the "way") is part of the outbound partner profile.

Technical communication parameters are entered in the port

definition. Inbound ports do not require such parameters - their

technical parameters are defined by the external sending

system.

Process codes are also part of the partner profiles.

They are used for processing data.

Process codes which are defined outside the partner profile are

used in error handling.

(C) SAP AG BC620 6-16

Partner Profiles Exercise

Unit: Partner Profiles

As a member of the EDI project team for your company, enter the

company T-BILnn as the EDI vendor with whom purchase orders and

order acknowledgments are to be exchanged.

1-1 Maintain the partner profiles for your EDI vendor as follows:

Purchase orders can be sent to the EDI vendor

Order acknowledgments from the vendor can be received

The corresponding master data in the MM application has already been created for you.

1-2 From the initial node of the IDoc Interface, choose IDoc Partner Profile. Firstly,

enter the header data for the vendor. Position the mouse on the partner type LI and

choose Create. There, enter a permitted agent.

1-3 Configure the outbound processing. Choose Create outbound parameter. Enter the

vendor (code LF). The message is ORDERS. Firstly, maintain the Outbound options:

The recipient port has already been maintained as PORT-nn and represents the

connection to the EDI subsystem. In output mode choose Send IDoc immediately and

Do not start subsystem. Finally in this view, enter the data structure for the exchange as

an IDoc type. As you are going to use the standard system, select the IDoc type

ORDERS01.

As outbound processing for confirmations is determined via Message Control, you

must also maintain the Message Control tab page. The application is linked to Message

Control. In MC, the process is identified by the partner function (code LF) and the

application (application EF and message type NEU). You determine how the document

data is generated as an IDoc via the process code. You should remember that in certain

circumstances, there can be several process codes for one message. Select the most

recent version of confirmation outbound processing via process code ME10.

1-4 Now configure inbound processing for the order acknowledgment in Create inbound

parameters. The process depends on the vendor and the message. Using the

information sent to your system by the EDI subsystem in the control record, the correct

partner profile can be determined. You should therefore select the message ORDRSP

to identify the process. The actual processing of the IDoc is selected via the process

code. Select the process code ORDR.

1-5 Check the settings you have entered by selecting Partner Check.

nn is the number of your group (01 to 18).

(C) SAP AG BC620 6-17


SAP AG 1999

The Test Tool

Test Tool Options


SAP AG 1999

Test Tool Options

You always create a new test-IDoc with the test tool. However, you can use one of the IDocs

available in the database as a template and edit the copy.

You can add or delete segments and therefore create your own IDoc type in an ad hoc manner.

You can change the content of every single segment field

You can change all the control record fields

There are other possibilities if you do not want to use an IDoc as the model for editing:

You can enter data in the empty IDoc type (including the control record)

You can import an IDoc from a file.

You can even create an IDoc from nothing by simply adding segments step by step.

The test tool saves the edited IDoc as a new IDoc in the database before the actual processing test

begins.


The following options are available in the test tool for both inbound and outbound processing:

Standard processing: Your test IDoc is sent for normal inbound or outbound processing.

Mass testing: Several copies of the edited IDoc are sent for processing. If the relevant flag is not

set, only one copy is sent.

In addition, the following options are available for inbound processing:

Generate file: In the case of a port with type "File", an IDoc file is created during inbound

processing. The test tool takes over the role of the external system. Inbound processing does not

have to be triggered by the generation of the IDoc file, which means that the IDoc file is not

deleted by the system and is therefore available for further tests.

Direct call of inbound function module. This allows the function module to be debugged. If this

flag is not set, the IDoc is sent for standard processing, as in the outbound test.

Like the other test programs, the test tool has a special test status with which you can identify test

IDocs in the monitoring programs.


Test Tool Exercise

Unit: Processing Tests

Topic: Test Tool (order acknowledgment)


Use the test tool

Use IDoc display to trace IDocs

As a member of your EDI project team in purchasing, you want to test the

following as soon as possible:

Sending purchase orders

Receiving order acknowledgments

1-1 Create a purchase order for methanol (material number SH-100) from the vendor T-

BILnn by selecting Logistics Materials Management Purchasing Purchase

Order Create Vendor Known (transaction ME21).

1-2 As a member of the purchasing department, you belong to purchasing organization

1000 and purchasing group 001. The methanol is required for plant 1100 (Berlin).

Company code is 1000 (IDES AG 1000).

1-3 After the data has been entered successfully, select Header -> Messages from the menu

in the item overview to check the proposal for the output of the purchase order via

Message Control. If dispatch time 4 has been selected, an IDoc for this purchase order

is generated as soon as the data is saved.

1-4 Change to Purchase Order Display. By selecting System Links the IDoc that has

just been generated is displayed.

2-1 You can now use the purchase order IDoc that has just been generated as a template for

the inbound order acknowledgment to be tested.

2-2 From the initial node of the IDoc Interface, choose Test Test Tool. Choose Existing

IDoc and call the value help, in which you search with the recipient partner number.

Choose Create.

2-3 Select the control record (the first record) by clicking with the mouse and change the

following fields:

Recipient, Port: SAP<SID>

Sender, Port: PORT-nn

Sender, Partner number: T-BILnn


Sender, Partner type: LI

Sender, Partner function: LF

Message type: ORDRSP

Choose Continue.

2-4 As the order acknowledgment should contain at least the order number of the vendor,

create a corresponding segment. Copy segment E1EDK02 and change the following

fields:

Qualifier: 002

Document

:

For example BC620-

Test-4711

Choose Continue to close the dialog box.

2-5 The acknowledgment of your vendor now has to be assigned to the item. Create a

corresponding segment E1EDP02 directly after the item segment E1EDP01 as a

subsegment. Maintain the following fields:

Qualifier: 001

Document: Order number, in segment E1EDK02, qualifier 001, field

document

Document

item:

Document item, in segment E1EDP01, field document item

Choose Continue.

2-6 Choose Standard Inbound and then Continue.

2-7 The system changes your original order. You can display the changed order by

selecting Logistics Materials Management Purchasing Purchase Order

Display. If you double-click on the item, you will see the acknowledgment number that

has just been transferred. By selecting System Links from the item overview, you

can display the IDoc which is linked to the outbound purchase order, as well as the

IDoc which is linked to the inbound acknowledgment.

<SID> is the 3-character system ID (for example, ID3)

nn is the number of your exercise group (from 1 to 18)


SAP AG 1999

Message Control and IDocs

Message determination and message processing

Condition components

Dispatch times


SAP AG 1999

Message Control and IDocs: Unit Objectives


Explain condition components

Find examples of condition components in MM

Customizing

Display and process the proposed message from the

MM application transaction


SAP AG 1999

Business Scenario


SmartMart, you are responsible for configuring the

IDoc Interface.

A purchase order from SmartMart is firstly created as a

message by the Message Control module, before being

converted into IDoc format. You know that the basic

settings for this module exist in the standard SAP

system, but wish to find out more about other Message

Control functions.


SAP AG 1999

Outbound Processing using Message Control

MCMC

recordrecord

DocumentDocument

SAP Application

MC

IDoc Interface/ALE Services

Find proposal

Edit

Process

Message Control (MC) generates messages from application documents. The possible messages are

defined as condition records in Customizing.

From the possible messages, MC searches for those which match the current application data. This

message determination can result in several messages being found, or possibly none. In the

following example, we will presume that one message was found.

If supported by the application, this message is proposed for editing in the transaction which started

MC. When creating a purchase order, this means that the message proposal can be edited (displayed

and changed) before the purchase order is posted.

In any case, the message is generated and processed (if not deleted during the editing process): for

example, if the order is to be printed, the processing program sends the message to the printer. If the

message is to be sent as an IDoc, a special processing program is called from the IDoc Interface.

The new message is represented by a new entry in the MC table. Part of this record is the processing

status, which can have the following values: 0 = not yet processed, 1 = successfully processed, 2 =

processed with error.

Note: For reasons of clarity, this slide does not show the transfer of the IDoc to an external system,

although this is also part of outbound processing.


The process diagram shows message determination, message editing and message processing.

Message Control allows a dispatch time flag to be set, which determines whether the message is

processed immediately after the application document is created or at a later time. In the second case,

you must schedule report RSNAST00 as a job, otherwise the message remains as an MC record with

processing status 0.

The MC record refers to the document as a BOR object (BOR = Business Object Repository) which

contains all the important data for the message.

Table TNAPR contains the processing programs (RSNASTED in the case of EDI). Form routine

EDI_PROCESSING is accessed within this program.


SAP AG 1999

Condition Elements

Procedure

SAP Application

Output Type

Access Sequence

Condition Table

1:n

m:n

n:1

m:n

Message determination uses the condition technique, which is also used in SD price determination.

Messages defined in Customizing are searched in a specified sequence. The condition elements and

their hierarchy define this sequence.

The messages are records in a condition table. Several condition tables can belong to one output

type. The condition tables can be accessed according to a certain access sequence with different key

fields.

Several output types can belong to one procedure and several procedures can belong to one

application, for example the application EF (purchasing).

Therefore, if one application wishes to send EDI messages via Message Control, only the procedure

for that application and the current application object (for example the document) is searched for

corresponding messages.

The condition component "Access sequence” can be used to define whether only one message is to

be found: If this is the case, you should set the "exclusive” flag. If this flag is not set, the entire

access sequence is processed, that is, several messages have possibly been found.


SAP AG 1999

Message Processing: IDocs

R

S

N

A

S

T

E

D

Check MC record

Read partner profile

Call selection module

(from application)

Call ALE Services

Transfer according to

output mode'1'/ '2' '3'/ '4'

Single IDoc Multiple IDocs

via RSEOUT00

The transmission medium is part of the condition record (the message defined in Customizing). The

transmission media for IDoc processing with Message Control are:

"6" EDI (Electronic Data Interchange), that is, without distribution model

"A" ALE (Application Link Enabling), that is, with distribution model

The EDI program for message processing is started with these parameters: RSNASTED, with the

form routines EDI_PROCESSING or ALE_PROCESSING.

IDocs are transferred individually from program RSNASTED when using output modes "1" and "2"

(field OUTMOD in the control record).

IDocs are not transferred directly when using output modes "3" and "4" (field OUTMOD in the

control record). Instead, they are collected by the program RSEOUT00 (batch mode) and sent as a

group.


SAP AG 1999

Dispatch Times in Outb. Procg using MC

Application MC IDoc Interface External System

Real time

Fast batch

Post OUTMOD = 1

Post OUTMOD = 1

Post OUTMOD = 3

Post OUTMOD = 4

Batch

BatchVSZTP = 1

VSZTP = 1

VSZTP = 1

VSZTP = 4

You should note that there are two different dispatch times for outbound processing using Message

Control: one controlled by MC, the other by the IDoc Interface. Each of these times can be switched

between "immediately" and "later". If "later" is selected, the program must be started manually (for

test purposes) or as a batch job (in production operation), while the program is started automatically

if "immediately" is selected.

If an EDI subsystem is the external system and port type "file” is used, there is a third stop sign: The

subsystem, when it is not triggered.

Recommended combinations of stop signs (see slide):

Real time: IDocs are sent to the external system individually when the application documents are

created.

Fast batch: IDocs are sent to the external system individually when the MC selection program is

started manually or as a batch job. This can result in large amounts of data requiring inbound

processing in the EDI subsystem in a short space of time.

Batch: A stack of IDocs is sent to the external system when the IDoc Interface selection program

is started manually or as a batch job. To use the system resources efficiently, you should select the

first stop sign, the MC dispatch time "later" (1 or 2).


SAP AG 1999

Summary

Message Control is important in IDoc outbound

processing.

Messages defined in Customizing are examined in a

certain sequence to determine whether or not they

apply to the current application data. This sequence is

defined by the condition components and their

hierarchy.

IDoc-specific message processing takes place via

program RSNASTED.

Up to three different dispatch times can be defined for

outbound processing.

(C) SAP AG BC620 8-10

Message Control and IDocs Exercise

Unit: Message Control and IDocs

Topic: Condition Elements


Create an output type

Create a condition record

As a member of the EDI project team you must configure the electronic

dispatch of an order acknowledgment. For this you create an individual

output type and condition records.

1-1 Create the output type ZBnn as a copy of output type BA01 in transaction NACE.

The output type should provide the transmission medium 6 (EDI) as the default

values for the condition records.

1-2 You must transfer the processing program and routine for your transmission

medium EDI from output type BA01 . You must also ensure that the possible

partner function AG (sold-to party) is entered for your new output type.

1-3 Determine your new output type in the procedure for the sales Order messages

(application V1). Go to the navigation Control for this procedure.

1-4 Now create a condition record for output type ZBnn for your partner T-BIKnn of

sales organization 1020. You should use 6 (EDI) as the transmission medium.


(C) SAP AG BC620 8-11

Message Control and IDocs: Solution

Unit: Message Control and IDocs

Topic: Condition elements

1-1 In transaction NACE select Expert mode and choose the application V1 (sales).

Select Output types, go to change mode and select BA01.

Choose Edit Copy as...

Enter ZBnn as the target entry. In the Default values tab page change the

transmission medium, if necessary, to EDI.

When saving, you must confirm that you also want to copy all of the dependent

entries. You must still maintain the language field for the dependent entry for the

mail title (also if you do not use the transmission medium “mail”). Choose, for

example, EN (English).

Note: By copying you have also transferred the access sequence of the original

BA01, which contains a condition table. You must fill this condition table in the

last part of the exercise.

1-2 In the output types screen, select your new output type ZBnn.

In the navigation frame select the entry Processing routines by double-clicking.

Check the entry. The program RSNASTED and the form routine

EDI_PROCESSING must be determined for the transmission medium 6 (EDI).

In the navigation frame, now select the entry Partner functions.

To add the partner function AG, select New Entries and enter this function for the

transmission medium 6 (EDI).

Save your changes and return to the initial screen of transaction NACE.

1-3 In the initial screen of the transaction NACE, select the application V1 (sales).

Choose Procedures.

Select the procedure V10000 (order messages).

(C) SAP AG BC620 8-12

In the navigation frame select the entry Control by double-clicking.

Choose New Entries. Enter the following:

Level (determines the order) 1nn (100 + your group

number)

Counter (not relevant here) 1

CTyp (= output type) ZBnn

Do not enter a condition, in order to ensure that in determination your output type

is searched every time for messages.


1-4 In the initial screen of the transaction NACE, select the application V1 and choose

Condition records.

Position the mouse on ZBnn and select Condition records again.

Enter the sales organization 1020 in the selection screen and select continue.

Make the following entries in the condition table:

Customer T-BIKnn

Function AG

Transmission medium 6 (EDI)

Time 4 (immediately)

Language EN (English)

You can leave the partner field empty as the partner is determined from the

customer master data. In the present case, it is identical to the customer. Finally the

message is sent to them, here as an IDoc.


Note: The condition table is usually maintained in the sales master data as an order

message. The maintenance interface is the same as in the NACE initial access.



SAP AG 1999

General Settings

Number ranges

Event-receiver linkage

IDoc administration

Fast entry

Long names - short names


SAP AG 1999

General Settings: Unit Objectives


Configure the general parameters in the IMG

Describe when the IDoc Administrator is notified


SAP AG 1999

Customizing using the IMG

R/3 Customizing IMG

Cross-application

components

IDoc InterfaceIMG documentation

Project documentation

Project management

Activities

General parameters for the IMG can be entered via the IMG. The IMG is a set of implementation

guidelines which can be used by customers to configure the R/3 System to meet their requirements

("Customizing"). The corresponding tables are maintained via activities.

By selecting the appropriate attributes, users can display only the activities which are required in

each case. 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 Cross-application Components ->IDoc Interface.

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 and so on) as well as functions for creating your own project documentation via

customer notes.


SAP AG 1999

Number Ranges

IDoc Interface

[…]

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

System. This is called "internal number assignment".

In the IDoc Interface, number ranges are set for:

- IDocs: the IDoc IDs are taken from the interval

- Ports: the names of the tRFC ports are defined by the interval

- Mailbags: These are only used for communication with an R/2 System. IDocs are transmitted in

mailbags

These number ranges are maintained from the IMG node for the IDoc Interface.


SAP AG 1999

Event-Receiver Linkage

IDoc Interface

R/3 Application

Pro

ces

sin

gP

roc

es

sin

g

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

are processed further (for port types "file", "XML", "CPI-C"). This is made possible by the workflow

event concept: If IDocs are saved in the database, an event is created , which waits for the "receiver"

in the system. The "receiver" (a function module) finds the event and triggers inbound processing.

As a result of this step, the function module has used the event, which no longer exists in the system.

The Workflow Manager determines when the receiver starts to search for events: There is therefore

an interval between the data being saved and further processing being initiated (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.


SAP AG 1999

IDoc Administration: Global Parameters

SAP AG

Party to be notified (IDoc Administrator)

System environment (Basis system?)

Processing details

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, for

example Message Control or application components. If these entries are not made, it is possible that

the IDoc interface may call function modules, for example, that do not exist in the specified system

(Basis system only).

Processing details:

The maximum number of syntax errors which 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 IDoc inbound processing is triggered synchronously (not via the event-receiver

linkage) (port type File). In this case, immediately after the event of the event receiver

System parameters can be entered as "global parameters" from the initial screen of the IDoc

interface by choosing Control->IDoc Administration or can also be set from the IMG node of the

IDoc interface.

After how many data records a COMMIT WORK is initiated. You should also see the F1 Help

function for the input fields.


SAP AG 1999 SAP AG

IDoc Administration: User Parameters

Tests

Documentation Tools

Development

User-specific parameters for the IDoc interface cannot be entered from the IMG. Instead, choose

Control -> IDoc administration from the initial node of the IDoc interface.

The test parameter is the port 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 IDocs and segments. Course

BC621 contains more information about developing and defining IDoc types.


SAP AG 1999

Fast entry

Default values

During fast entry of the partner profile values, default values ("templates") are already set in the IMG

, which facilitates the maintenance of the partner profiles in the IDoc interface.

The default values are set for partner type and direction (inbound/outbound).

If you select the fast entry option for partner profiles (via the pushbutton on the initial screen, see

later unit), the values which you have entered in the IMG for the current partner type and direction

are entered as the default values. According to your requirements, you need only select and modify

these values.

You can also reach the transaction from the initial node of the IDoc interface.

In the IDES system, the following message types are maintained 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/sales confirmation


SAP AG 1999

Long Names - Short Names

Release 4.0 Release 3.X

Type

"LongNameXYZ01"Type "Short01"

Release 4.0 introduced the concept of the extended namespace. As a result, new IDoc Interface

objects which were developed for Release 4.0 (for example IDoc types) can have longer names than

before.

This fact can lead to problems when communicating with older releases which only recogníze short

names. If required, tables which can convert the long names to short names must therefore be

maintained.

These tables are maintained in the IMG or from the IDoc Interface development (path for segments

or IDoc types from the relevant editor: Environment -> Conversion -> <object name>). You should

also read the online documentation.

(C) SAP AG BC620 9-10

SAP AG 1999

General Settings: Summary

General settings are entered via the IMG. In

addition, user-specific parameters can be changed

at any time via the control menu.

The IDoc Administrator is part of the global

parameters which are maintained in IDoc

Administration. When exceptions occur, the

administrator is always notified if no partner profile

is found.

(C) SAP AG BC620 9-11

General Settings Exercise

Unit: General Settings

Topic: Fast data entry


Maintain the default values for fast entry.

As a member of the EDI project team enter the company T-BIKnn as the

EDI customer for the sales orders and order acknowledgments As you

expect further EDI customers for these messages, you want to use

corresponding proposals in Customizing.

1-1 Go to IDoc Interface Customizing (choose Basis Components Basis Services

IDoc Interface) and check the following default values:

Outbound Processing:

Parameter Value

Partner type KU

Message type ORDRSP

Partner function AG

Basic type ORDERS01

Application V1

Output type BA00

Process code SD10

Inbound Processing:

Parameter Value

Partner type KU

Message type ORDERS

Partner function AG

(C) SAP AG BC620 9-12

Process code ORDE

2-1 Now transfer these default values to the partner profiles of your customer. As a result

you can

Receive sales orders from the customer

Send order confirmations to this customer

The corresponding master data in the SD application has already been created for you.

2-2 From the initial node of the IDoc Interface, choose IDoc Partner Profile. Choose

Utilities Fast Data Entry and enter the customer number T-BIKnn. Select the

proposal for outbound processing. The logical message is ORDRSP.

2-3 Choose Utilities Fast Data Entry again but now for inbound processing. The logical

message is ORDERS. Save your entries.

2-4 Go to the outbound parameters for message ORDRSP. Replace output type BA00 with

your output type ZBnn from the exercise in the “Message Control” unit.


(C) SAP AG BC620 10-1

SAP AG 1999

Additional Test Programs

Test layers

Test programs

(C) SAP AG BC620 10-2

SAP AG 1999

Processing Tests: Unit Objectives

Use special test programs and determine when to

implement them during processing


(C) SAP AG BC620 10-3

SAP AG 1999

Processing Tests: Business Scenario




After tests have been completed successfully in

your own system and the EDI subsystem has been

connected, you wish to test data transfer.

The IDoc Interface test programs are to be used for

this purpose and this unit contains information

about using these tools.

(C) SAP AG BC620 10-4

SAP AG 1999

Test Layers: Overview

Inbound

IDoc file

Application

IDoc Interface

WorkflowMC

Outbound

IDoc file

Status

confirm.

WE12

WE16 WE17

WE19 ,

WE18WE15

WE14, WE19

File System

External

System

WE18

The arrows show the layers where the tests start. Alongside is the relevant transaction. Outbound

processing is on the left, inbound processing on the right. According to the process code (partner

profile entry), the inbound test IDocs are processed directly in the application or via a workflow.

All test programs write a special status. Hence you can determine whether or not each IDoc was

generated for test purposes.

The IDoc statistics provide an overview of all test IDocs (F5 key, also see "Statistics and

Monitoring").

The test tool (transaction WE19, see corresponding unit) is the most general tool. Both inbound and

outbound processing can be tested for one IDoc (which can even be created manually).

The other test programs require either an existing file, a message status record (MC record), or a file

in the file system (at the operating system level).

If a file port is selected in outbound processing, a complete test cycle (from outbound processing to

inbound processing) can be executed, including the file system.

(C) SAP AG BC620 10-5

SAP AG 1999

Test Layers: Outbound Processing

Application

MC

WE15

WE14, WE19

External

System

IDoc Interface

MC

When testing from MC (transaction WE15), you can test whether an IDoc is created correctly from a

generated MC record. In this case, dispatch time 1 or 2 must be configured in the message condition

record: This stops message processing, that is, the processing program RSNAST00 is not started

directly when the application document is created, and the MC record is assigned the status 0 (not

yet processed).

Transaction WE15 does nothing but start program RSNAST00, that is, trigger further processing

manually. Using this method, you can, for example, go into debugging mode or export messages,

which is not possible in other cases.

Both the IDoc test (transaction WE14) and the test tool (transaction WE19) test the transfer of one or

more IDocs to the specified port. As a prerequisite for the IDoc test, an outbound IDoc which has not

been sent to any ports must exist already (current status 30). Such an IDoc can be generated, for

example, using transaction WE15: In the corresponding partner profiles, the output mode must be

entered as "collect IDocs”, so that the IDocs are not forwarded immediately.

There are no prerequisites for the test tool.

Note: Transaction WE15 can only be used in conjunction with moving data from the applications SD

and MM. The corresponding message types are ORDERS, ORDRSP, DESADV and INVOIC, for

example. Only these modules and messages use Message Control for IDoc outbound processing.

(C) SAP AG BC620 10-6

SAP AG 1999

Test Layers: Inbound Processing

Inbound

IDoc file

Application

IDoc Interface

Workflow

Outbound

IDoc file

WE12

WE16

WE19

File System

Both the modified outbound file test (transaction WE12) and the original inbound file test (WE16)

test the transfer of an IDoc file via the IDoc Interface. WE12 changes control records to create an

inbound IDoc from an outbound IDoc, before the IDoc is sent to the IDoc Interface.

There are no prerequisites for the inbound test tool: no inbound port of type "file" is needed and no

files are required from the file system. The test tool can even create inbound IDocs if necessary.

Check the online documentation (extended help) for the test tools.

Note: WE16 erases the inbound file after the file has been read successfully. This does not apply to

outbound files, which are read by WE12 and can therefore be used for further test runs.

(C) SAP AG BC620 10-7

SAP AG 1999

Test Layers: Status Confirmation

Application

IDoc Interface

Workflow

WE17

File System

Outbound

file with

SYSTAT01

WE12

WE16

WE19 ,

WE18

Inbound

file with

SYSTAT01

Status

confirm.

WE18

You test the transfer of status confirmations in file format with "process status file" (transaction

WE17). Transaction WE18 ("generate status file") does not need a file as it is self-generating. The

IDoc display function can be used to check if the status records were written correctly to the relevant

IDoc.

Caution: As in the case of an original inbound IDoc, the status file is deleted after being read

successfully. The test can therefore be carried out only once for each file.

When a status record is received which indicates an error, a workflow is started: The (status) process

code for this purpose in the standard system is EDIS. Other process codes for other tasks/workflow

definitions for status processing can be created via Control -> Status process code and Control ->

Status maintenance from the IDoc Interface initial screen.

Status records must refer to outbound IDocs in the system, otherwise an error occurs in status

processing.

The general status confirmation for all port types and directions runs via the special IDoc type

SYSTAT01, which is processed by standard task TS300000206. This status processing therefore

always takes place via workflow. If an incorrect status is returned, a work item is generated.

SYSTAT01 can be used with all the inbound test programs. IDocs of this type must be present in file

form, except in the case of the test tool.

(C) SAP AG BC620 10-8

SAP AG 1999

When to Test Which Function?

Data exchange with the file system: WE14

(outbound), WE16 (inbound), WE17 (status

confirmation, inbound)

Processing MC record: WE15

Data transfer from the IDoc Interface to additional

inbound processing: WE19

Data transfer to any port: WE14

(C) SAP AG BC620 10-9

SAP AG 1999

Processing Tests: Summary

Special test programs require MC records, files or

existing IDocs from the database. If necessary,

automatic outbound processing must be stopped via

the output mode from the partner profile and the

dispatch time in the MC condition record.

The test tool allows general tests for inbound

processing, outbound processing and status

confirmation via SYSTAT01.

(C) SAP AG BC620 11-1

SAP AG 1999

A Process Chain

Send purchase order

Post standard order

(C) SAP AG BC620 11-2

SAP AG 1999

A Process Chain: Unit Objectives


Send a purchase order via IDoc

Receive a standard order via IDoc

Explain which EDI-specific master data must be

maintained

(C) SAP AG BC620 11-3

SAP AG 1999

A Process Chain: Business Scenario




For test purposes, IDocs are to be created by

SmartMart and sent to QuickDeliver.

(C) SAP AG BC620 11-4

For SmartMart, the data flow appears as follows:

As the purchase order is created in MM, outbound processing has to take place using Message

Control. The master data for the vendor QuickDeliver therefore contains a condition record which

uses the order to find the corresponding EDI message and writes an MC record.

The key fields in the MC record are assigned to the corresponding key fields in the partner profile

(outbound processing using Message Control). They determine the process code, which in turn

defines the outbound processing (generating an outbound IDoc using a function module).

The key fields in the partner profile (outbound processing using Message Control) are assigned to the

corresponding key fields in the partner profile (general outbound processing). This determines the

IDoc type (ORDERS01) and the port.

The IDoc Interface now knows which IDoc type to generate with which function module. The IDoc

is created. The partner profile specifies that the IDoc is immediately sent to the port.

(C) SAP AG BC620 11-5

SAP AG 1999

EDI-Relevant Master Data in Purchasing

IDoc Type ORDERS01

E1EDKA1 (PARVW = “AG”):

Partner information

E1EDP19 (QUALF= “001”):

Material number

Data record

Data record

E1EDKA1 (PARVW = "LF"):

Partner information

Data recordVendor master record :

Partner number, type,

function

Vendor master record :

Vendor account

Material master record:

Material name

Vendor material number:

Material name for vendor

MC condition record with

transmiss. medium "6" (EDI)

E1EDP19 (QUALF= “002”):

Material number

Data record

The MM master data must contain certain parameters which are sent to the order recipient via IDoc:

Apart from the partner number and type, the vendor master record must contain the partner function.

The partner function is a required field entry in the additional outbound partner profile using

Message Control (MC).

The vendor master record should contain the name which appears as the partner number in the

recipient partner profiles as the "account with vendor" (field LFB1-EIKTO). This field is compared

with the partner number value in the recipient inbound partner profile. If this field is not maintained,

additional conversions are required in the recipient system.

The vendor material information must contain the material name for the vendor, because the

recipient determines from the contents of a segment of type E1EDP19 which material has been

ordered.

The MC condition record must contain a transmission medium "6” (EDI). The recipient cannot see

this value. If another transmission medium is entered, the IDoc Interface will not be activated.

(C) SAP AG BC620 11-6

SAP AG 1999

Standard Order for QuickDeliver


Generate work item

ok?

ok?

No

No

Send data to

R/3 System

Determine processing for SmartMart data,

generate IDoc

Post standard order

External System =External System = QuickDeliverQuickDeliver EDI SubsystemEDI Subsystem

For QuickDeliver, the data flow appears as follows:

The external system (QuickDeliver EDI subsystem) calls the inbound function module for the port

type "File" in the QuickDeliver R/3 System via RFC. The inbound port is therefore defined by the

external system.

The IDoc Interface recognizes the external system if the system is defined as an inbound port. The

IDoc is then created in the database.

Control record fields in the inbound IDoc are assigned to the corresponding key fields in the inbound

partner profile. They determine inbound processing (in this case, direct processing by a function

module). This function module reads the order data and posts the document as a standard order in

SD.

Note: Do not confuse the two function modules described here: The first is called by the external

system via RFC and generates the IDoc, while the second is the application function module which

reads the data in the new inbound IDoc.

(C) SAP AG BC620 11-7

SAP AG 1999

EDI-Specific Master Data in Sales

IDoc Type ORDERS01IDoc Type ORDERS01

E1EDKA1 (PARVW = "LF"):

Partner information

E1EDP19 (QUALF= “002”):

Material number

Data record

Data record

Customer master record:

Partner number, type,

function

SD Customizing:

Assigning customer/

vendor to sales

organization

Material master record:

Material name

E1EDKA1 (PARVW = “AG”):

Partner information

Data record

The SD master data must contain EDI-specific parameters which are compared with the data from

the order IDoc:

Partner number, type and function of the sender are assigned according to the data in the partner

profile. This data must also exist in the SD master data.

The material number is transferred in a segment of type E1EDP19. This material must exist in the

material master record. The qualifier 002 in the segment shows that this is the material number for

the vendor.

If the EDI subsystem does not assign the combination of customer and vendor to a sales organization

via segments of type E1EDK14 (document header organizational data), you must maintain this

assignment yourself using the customizing transaction (VOED).

(C) SAP AG BC620 11-8

SAP AG 1999

A Process Chain: Summary

Special EDI parameters must be entered in the

application master data. These include partner

information and transmission medium "6" in the

condition record for outbound processing using

Message Control (MC).

Outbound processing using Message Control is

always applied for purchase orders from the MM

module.

(C) SAP AG BC620 11-9

Process Chain Exercise

Unit: A Process Chain

Topic: Send purchase order


Use IDoc display to trace IDocs

As a member of the EDI project team you want to simulate the message

chain from the outbound purchase order via the incoming order to the

sending and subsequent receiving of the order acknowledgment. First,

you take the role of the customer, then the vendor (incoming order and

outbound order acknowledgment) in order to act as the customer again

(incoming order acknowledgment) at the end of the message chain.

1-1 Create a purchase order for methanol (material number SH-100) from the vendor T-

BILnn by selecting Logistics Materials Management Purchasing Purchase

Order Create Vendor known (transaction ME21).

1-2 As a member of the purchasing department, you belong to purchasing organization

1000 and purchasing group 001. The methanol is required for plant 1100.

1-3 After the data has been entered successfully, select Goto Messages from the menu in

the item overview to check the proposal for the output of the purchase order via

Message Control. If dispatch time 4 has been selected, an IDoc for this purchase order

is generated as soon as the data is saved.

1-4 Change to Purchase order Display. By selecting System Links the IDoc that has

just been generated is displayed.

As Send IDoc immediately has been set in the partner profiles, the IDoc has the status

03, that is, it has been written in a file.


Topic: Incoming order

2-1 In the previous exercise, a file was created in which the data is correct but the control

record is incorrect.

(C) SAP AG BC620 11-10

2-2 Select Test -> Inbound Processing Modified Outbound File from the initial node of

the IDoc Interface (transaction WE12). This transaction allows you to change the

control record so it is correct, that is, matches the partner profile you created in the

exercise "General Settings" for your customer T-BIKnn.

You can set default values for source, destination and port, by setting your port Port-nn

for the test by choosing Goto User settings.

2-3 The sender is customer T-BIKnn, from whom you wish to receive the order. Enter T-

BIKnn as the partner number, KU as the partner type and AG as the partner function.

The logical message is ORDERS. For all other values, you can use the default values.

2-4 Choose Execute.

2-5 Choose IDoc Display IDoc or IDoc IDoc Lists to view the IDoc which you have

created. By choosing System Links the order that has just been generated is

displayed.


Topic: Send order acknowledgment

3-1 In the previous exercise you posted an order. An outbound IDoc has already been

generated by Message Control for order acknowledgment. The IDoc has the status 30,

therefore has not yet been sent by the SAP System.

3-2 Initiate the transfer of the order IDocs by choosing Test Outbound Processing from

IDoc from the initial node of the IDoc Interface. Select with the recipient partner

number.

3-3 Return to the order (transaction VA03) and check the status of the ORDRSP IDoc, and

choose System Links. If this IDoc has status 03, you have generated a file.


Topic: Receive order acknowledgment

4-1 In the previous exercise, a file was created in which the data is correct but the control

record is incorrect.

(C) SAP AG BC620 11-11

4-2 Select Test -> Inbound Processing of Modified Outbound File from the initial node of

the IDoc Interface. This transaction allows you to change the control record so it is

correct, that is, matches the partner profile you created in the exercise "partner profiles"

for your customer T-BILnn.

4-3 The sender is vendor T-BILnn, from whom you wish to receive the order

acknowledgment. Enter T-BILnn as the partner number, LI as the partner type and LF

as the partner function. The logical message is ORDRSP. For all other values, you can

use the default values.

4-4 Choose Execute.

4-5 Choose IDoc Display IDoc or IDoc IDoc Lists to view the IDoc which you have

created. By choosing System Links the purchase order that has just been changed is

displayed. If you double-click on the item, you will see the acknowledgment number

that has just been transferred.

(C) SAP AG BC620 12-1

SAP AG 1999

Statistics and Monitoring

Passive and active monitoring

Work Item Analysis

(C) SAP AG BC620 12-2

SAP AG 1999

Statistics and Monitoring: Unit Objectives


Decide when different tools should be implemented

for IDoc monitoring

Use the individual monitoring transactions

(C) SAP AG BC620 12-3

SAP AG 1999

Business Scenario




The exchange of IDocs between the two

companies is to be monitored. As a result, you

must be familiar with the IDoc monitoring tools

available for the IDoc Interface.

(C) SAP AG BC620 12-4

SAP AG 1999

Monitoring Programs: Overview

Active

monitoring

Passive monitoring

4712

4711

4713

4718

Display

"RSEIDOCM"Statistics

List, IDoc

search

When errors occur, the IDoc Interface always notifies users actively (error handling via work items).

In addition, the IDoc Interface provides four passive programs and one active program for IDoc

monitoring.

The passive monitoring tools can be ordered according to their level of detail: The IDoc statistics

assign IDocs to status groups according to their current status, for example, to the group "inbound

error within the IDoc Interface". The individual IDocs are displayed in the IDoc list. This also

applies to the IDoc search, where IDocs are selected according to values in the segment fields.

Finally, IDoc display allows direct access to an individual IDoc via the ID. Double-clicking on the

relevant entry displays more details, as usual.

The passive monitoring tools can be found in the IDoc menu from the IDoc Interface initial node.

Active monitoring (report RSEIDOCM) uses the status groups from IDoc statistics. It is possible to

define threshold values. When these values are exceeded, responsible users are notified via work

items. Active monitoring can therefore be seen as a configurable error handling function.

Active monitoring is scheduled as a job (from the R/3 initial screen, choose System -> Services ->

Jobs -> Define job). Variants are created from the ABAP editor (choose Goto -> Variants).

(C) SAP AG BC620 12-5

SAP AG 1999

Selection Fields for Monitoring

Control record

Creation

date

Change

date

Partner,

message,...

IDoc statistics

IDoc list

IDoc search

IDoc display

Active

monitoring

EDI

References

The monitoring programs are reports which select IDocs in the R/3 database according to certain

criteria from the control record.

The most important selection field is the date on which the control record was created. The IDoc

statistics tool selects according to the change date.

All monitoring programs allow selection of IDocs according to partner and message. In IDoc

statistics, this works via the extended selection.

The highest number of selection fields is offered by the IDoc display function. Apart from the IDoc

ID, users can make selections according to EDI-specific parameters, for example the transmission

file in the EDI subsystem, which allows the data flow with the EDI subsystem to be monitored.

(C) SAP AG BC620 12-6

All monitoring functions can display an individual IDoc. However, users can only access an IDoc

directly via the IDoc display function (using the IDoc ID). As the most selective tool, IDoc display is

usually used when technical questions arise (for example problems when communicating with an

EDI subsystem)

The IDoc list function has less selection fields and is therefore easier to use. As with the remaining

tools, this function is used when application questions arise (for example how to display all IDocs of

message type INVOIC).

IDoc statistics gives a broad overview and is often used for presentations because of its graphical

capabilities. To obtain statistics about "repaired" IDocs, choose the function "Evaluation history" in

the IDoc statistics. This displays all status records for the IDoc.

You can use active monitoring as an alternative to normal exception handling if a user (employee) is

only to receive a work item if a certain number of incorrect IDocs (the threshold value) are found

within a specified time period. However, note that normal exception handling still takes place.

Note that IDoc statistics selects all IDocs which have experienced a status change within the

specified time period, while active monitoring selects all IDocs created during the same period.

(C) SAP AG BC620 12-7

SAP AG 1999

Status Group: Monitor/Statistics

4 = "IDoc transfer4 = "IDoc transfer

successful"successful"

39 = "IDoc in

target system (ALE)"

12 =

"Send ok"

13 =

"Send ok"

Retransmission

ok

020406080

100

1.

Qrtl.

2.

Qrtl.

3.

Qrtl.

4.

Qrtl.

Status values for active monitoring and statistics about status groups are combined to prevent the

information becoming too complicated.

The standard R/3 System assigns a group to each status via the "qualification” (synonym for "status

group”) value. This assignment can be changed from the initial IDoc Interface menu by choosing

Control -> Maintain status values.

According to the status group the individual statuses, for example, are displayed in the IDoc list in

the traffic light colors green, yellow or red. It should therefore be clear in the standard system

whether it concerns an error status, transfer- or success status. The traffic light color assignment for

status groups can be changed by choosing Control -> Maintain status groups.

For more information about the status groups which are supplied in the standard R/3 System, you

should read the online documentation for the IDoc statistics function.

(C) SAP AG BC620 12-8

SAP AG 1999

Work Item Analysis

Usually refers to exception handling

Work items which exist in the system are listed

Application for "lost work items", for example (no user

selected)

Work items are instances of defined single-step tasks. The IDoc Interface uses them mainly for

exception handling (see corresponding unit). They therefore contain the incorrect IDoc or the

incorrect application document which was created from the inbound IDoc.

As in IDoc statistics, the work item analysis function allows work items belonging to a certain task

to be displayed. This can be useful, for example, if no user could be found for the work item, and the

work item did not therefore appear in any inbox. From the work items, you can jump to the IDoc

display function.

The work item analysis function can be accessed by choosing Tools -> Business Workflow ->

Development -> Reporting -> Work item analysis, for example the work items per task (transaction

SW12_FREQ).

(C) SAP AG BC620 12-9

SAP AG 1999

The IDoc data flow can be monitored via four passive

programs and one active program in the IDoc

interface.

Active monitoring is a function which can be

individually configured for error handling or general

exception handling.

The level of detail in the passive monitoring programs

goes as far as displaying the individual IDocs. The

least-detailed monitoring tool is the status group

display under IDoc statistics.

Statistics and Monitoring: Summary

(C) SAP AG BC620 12-10

Statistics and Monitoring Exercise

Unit: Statistics and Monitoring

Topic: Passive monitoring


Use IDoc search

Use IDoc display

You are the EDI administrator in your company. The purchasing

department has asked you the following questions:

1-1 ''Which statuses has IDoc XY, which contains a purchase order for vendor T-

BILnn, already been assigned?''

Note: Use the IDoc display function

2-1 "Which IDoc was used to send purchase order XY to vendor T-BILnn?" You have

the following information:

Direction As a purchase order is involved, the direction is "outbound".

Basic type Purchase orders are sent to the EDI subsystem in your company

via IDoc type ORDERS01.

Segment You have the number of the purchase order. From the

documentation, you know that the order number is transferred in

the field BELNR in segment E1EDK02 with the qualifier "001"

(field QUALF).

Note: Use the IDoc search function

3-1 "As a member of the purchasing department, can I access the corresponding IDocs

directly from my purchase order?"

(C) SAP AG BC620 12-11

4-1 "As a member of the purchasing department, can I access the corresponding IDocs

directly from my sales order?"

Note for exercises 3 and 4: Choose System Links from your application

document.


Topic: Active monitoring

Using active monitoring

5-1 You want to trace IDocs in status 03. Include the report RSEIDOCM.

5-2 Go into the ABAP Workbench (SE38) and enter the report.

5-3 Choose Execute. Enter the following values in the selection screen:

Recipient type US

Recipient Your name BC620nn

Start/end time before batch job Enter a meaningful value

Critical IDoc number 1

Status group 3 (contains status 03)

5-4 After executing the report you receive notification in the Business Workplace.

Execute the work item. The IDoc statistics are displayed where the current status of

the report execution is displayed. By selecting Refresh, the current status is

displayed.

(C) SAP AG BC620 12-12

Statistics and Monitoring: Solution


1-1 Search by selecting IDoc Display IDoc and entering the direction as “outbound”

and the partner number of the recipient. You have already generated the purchase

order IDoc in exercise 1 of the previous chapter.

1-2 Apart from the status which has been reached, determine which message has been put

on hold with the status value "30", that is, the values for code, message number,

message type and ID.

2-1 Search for the IDoc(s) using the IDoc search function. Select the following:

Direction 1 = “outbound”

Basic type ORDERS01

Segment You have the number of the purchase order. The number is in

field BELNR of segment E1EDK02 with the qualifier "001“.

3-1 Select Logistics Materials Management Purchasing Purchase Order

Display (transaction ME23). Enter the purchase order number and choose Continue.

From the transaction overview screen, choose System Links. The IDoc which is

linked to this purchase order is displayed and you can request more detailed

information about the IDoc by double-clicking with the mouse on the relevant entry.

4-1 Select Logistics Sales and Distribution Sales Order Display (transaction

VA03). Enter the sales order number and choose Continue. The overview screen for

the transaction is displayed. Alternatively, find the sales order via the purchase order

number from exercise 3 and the search function. Choose System Links. The IDoc

which is linked to this sales order is displayed and you can request more detailed

information about the IDoc by double-clicking on the relevant entry.

(C) SAP AG BC620 13-1

SAP AG 1999

Workflow and IDocs

Inbound processing

Exception handling

Notification concept

Organizational structure

(C) SAP AG BC620 13-2

SAP AG 1999

Workflow and IDocs: Unit Objectives


Explain how the agent responsible is informed if

an error occurs during IDoc processing

Maintain the organizational structure

(C) SAP AG BC620 13-3

SAP AG 1999

Workflow and IDocs: Business Scenario


QuickDeliver, you are responsible for configuring

the IDoc interface.

A purchase order from SmartMart is received by

QuickDeliver as an inbound IDoc of type

ORDERS01. Inbound processing is configured

using a process code as "direct via a function

module", exception handling takes place by means

of workflow. You must configure a party to be

notified if an error occurs.

(C) SAP AG BC620 13-4

SAP AG 1999

Inbound Processing with Workflow

SAP Application

DocumentDocument

IDoc +IDoc +

processprocess

Workflow


Review,

edit,

forward,

and so on.

IDoc inbound processing can include a workflow which is triggered by a process code. This

workflow is defined by the user. Examples:

An application document is created automatically from the IDoc. The application document is then

sent to a user for review.

The IDoc is edited and modified if necessary before the application document is created. In this

case, the IDoc is edited and not the application document.

The IDoc or application document is forwarded to other users or new (outbound) IDocs are sent,

using the inbound IDoc as a basis.

Note: For reasons of clarity, this slide does not show the transfer of the IDoc from the external

system, although this is also part of inbound processing.

(C) SAP AG BC620 13-5

SAP AG 1999

Exception Handling with Workflow


Check partner, generate IDoc

Post document

Error handling

ok?

ok?

No

No

Message

Express

Exception handling or error handling is always defined as a workflow. One or more agents can be

notified about the error situation. The agents are defined in the IDoc Interface and in the organization

model of your company.

SAP standard exception handling in the IDoc Interface always takes place using single-step tasks. It

is identified by means of process codes.

If you set the express indicator in the process codes maintenance, the agent responsible for the

corresponding task receives a message on their screen as soon as a new work item appears in their

integrated inbox.

The slide only shows exception handling being accessed from inbound processing. However,

exception handling can also be accessed from outbound processing.

(C) SAP AG BC620 13-6

SAP AG 1999

Exceptions in Outbound Processing

IDocIDoc

DocumentDocument

or MCor MC

recordrecord

SAP Application

or MC

IDoc Interface

External System

EDIO

EDIX

Error during IDoc

processing

Syntax error

in IDoc

Customer

EDIPError while processing

IDoc stack

EDIN...with MC

EDIM Message without IDoc

without MC...

EDISStatus confirmation

EDIR

Single-step tasks are identified by (system) process codes:

The process codes EDIM and EDIN are valid for inbound and outbound processing. No IDoc could

be created here. EDIN is used for outbound processing using Message Control: Using the MC record

you can branch from the work item to the application document.

EDIO identifies an IDoc affected by an error during outbound processing.

EDIX identifies an IDoc which contains a syntax error.

EDIP identifies a stack of outbound IDocs (from a batch run of report RSEOUT00), in which a

processing error occurred and affected all the IDocs (a non-existent port, for example). The

corresponding single-step task can be used to correct the error and send the IDoc stack for processing

again.

If the status "incorrect" is assigned to the group by the external system, a single-step task is

addressed using the status process code EDIS. Additionally, you can use code EDIR to trigger

outbound processing again after you have corrected the error.

Note: EDIR is new for the Enjoy Release and replaces the old EDIS in the standard system. When

upgrading, you must explicitly execute the change to EDIR in the IMG.

Additional exception handling for status confirmations can be defined and identified via process

codes.

(C) SAP AG BC620 13-7

SAP AG 1999

Exceptions in Inbound Processing

SAP Application

IDocIDoc

External System

EDII

EDIY

Message without IDoc

Error during IDoc

processing

Syntax error

in IDoc

ApplicationIDoc with or without

application document

Message via IDoc

IDocIDoc

IDoc Interface

EDIM

TXTRAW

EDIL...error during

status file

Exception handling via single-step tasks for inbound processing is the same as for outbound

processing. Errors which occur when posting an application document (due to incorrect data, for

example) are sometimes handled and repaired by application-specific tasks and the corresponding

process codes. Application documents can also be generated in this way.

EDIM applies as in outbound processing, EDII and EDIY are the same as the outbound process

codes EDIO and EDIX.

Any messages can be sent in text format using the IDoc type TXTRAW01. Special case: an

exception occurs in the external system and the R/3 System is to be notified of this exception.

If a status file of the external system cannot be read, the process code EDIL is activated. The SAP

System error message is displayed in exception handling.

(C) SAP AG BC620 13-8

SAP AG 1999

Notification Concept I

Role resolution

Organizational structure

Task

Partner profile

IDoc Interface

Possible agents

Permitted agents

Selected agent

The agent determined in the IDoc Interface is only the permitted agent of a workflow task. All

"possible agents" are attached to the task itself. Role resolution determines the set of agents which

are both allowed and possible agents. These agents are called the selected agents.

All selected agents now receive the notification as a work item (as an "instance" of the workflow

task) in their integrated inbox.

The IDoc Interface function module for role resolution is EDI_ROLE_FOR_PROCESSING.

The IDocs can only be "repaired" and processed further from the integrated inbox.

Note: If the tasks are defined as general tasks for notification, all users are possible agents, and the

set of selected agents is the same as the set of permitted agents.

(C) SAP AG BC620 13-9

Permitted agents are entered in the following partner profiles for the IDoc Interface: Inbound,

outbound (optional), and general (required entry field). When an error occurs (for example a syntax

error in an inbound IDoc), the most relevant permitted agent is determined: The search for the agent

responsible for the message and partner (key fields in the profiles) therefore starts in the inbound or

outbound partner profile.

If no agent could be found in the inbound or outbound profiles (either because no value had been

entered or because no inbound or outbound partner profile could be found for the current partner-

message combination), the general partner profile is searched to determine a permitted agent for the

partner.

If this search is also unsuccessful (because no general partner profile for the current partner could be

found), the search continues in IDoc Administration (general settings). If no entry is found, no users

are notified! For this reason, you should always enter an agent ("administrator") in the general

settings.

In all cases, the agent can be a single person (type US=user) or a group which must be maintained in

the PD-ORG model, either as a job or a department.

(C) SAP AG BC620 13-10

SAP AG 1999

Notification Concept III

Organizational unit

Position

belongs to

includes

includes

belongs to

holder

holds

describes

described by

describes

described by

cost center assignment

describes

Task

Job

Cost center

described by

Work center

Person/user

cost center

assignment

reports to/

is superior to

Workflow auto-customizing (transaction SWU3) includes all tasks relating to the IDoc Interface as

"general tasks", that is, all R/3 users are possible agents. If you want to restrict this number, you can

do this using an organizational structure.

The organizational structure defines a responsibility hierarchy. For example, a general organizational

unit "administrators" could exist. This organizational unit can now be assigned to several persons

who hold as many positions. This organizational unit (not an individual) could be entered as a

possible agent in the IDoc Interface.

You can also enter a position which corresponds to one person as a possible agent. The advantage is

that notifications are tied to positions, not to individuals whose responsibilities can change. This

concept can be compared to the process code and the relevant function module/workflow.

Further elements of the organizational structure which can be entered as "possible agents" for a

standard task:

Job

User: R/3 user

Work center

(C) SAP AG BC620 13-11

SAP AG 1999

Maintaining an Organizational Structure

Customizing activities

Maintenance from the Workflow

menu

If an element of the organizational structure is to be entered as a possible agent instead of a person

(R/3 user), this element must be defined. This takes place in Customizing or from the workflow area

menu (Definition): Organizational plan -> Create (transaction PPOM).

From here, elements can be defined and assigned to each other or to R/3 users.

(C) SAP AG BC620 13-12

SAP AG 1999

Integrated Inbox

Message

SAPoffice

Missed deadline

Workflow

...

The integrated inbox can be accessed directly from the IDoc area menu (IDoc -> Integrated inbox) or

via transaction SO01. Via Workflow, you access your "worklist", that is, the list of work items for

which you are entered as a "selected agent". Work items are the instances of the single-step tasks.

You can edit a work item from your worklist. As a result, the work item disappears from the

integrated inbox of all other selected agents.

(C) SAP AG BC620 13-13

SAP AG 1999

Workflow and IDocs: Summary

Normal IDoc processing via workflow is only possible for inbound

processing of certain IDoc types.

Exception handling always takes place via workflow. It is called in

outbound processing in the same way as in inbound processing.

Errors can be caused by incorrect application data or incorrect

IDoc syntax. In these cases, error handling is different.

Through the organizational structure, workflow allows users in a

defined task area to be notified, not individual users whose

responsibilities may change.

Workflow allows incorrect IDocs to be forwarded as work items "in

a controlled manner" from an integrated inbox and even to be

repaired in some cases.

(C) SAP AG BC620 13-14

Workflow and IDocs Exercise

Unit: Workflow and IDocs

Topic: Organizational structure


Maintain the organizational structure

As a member of the EDI project team, you should maintain the

organizational model for your company, so that notifications for the

individual areas of responsibility can be addressed correctly, for example

EDI administration and purchasing.

1-1 The organizational unit 50010120 ("EDI Department“) has already been created for

EDI administration. You should now assign your user to the organizational unit. To do

this, proceed as follows:

Choose Tools Business Workflow Development Definition Tools

Organizational Management Organizational Plan Change. Enter

organizational unit 50010120 and select Change. Access the Staff assignments. Place

the cursor on the required function and choose Assign holder. On the next screen, you

can now assign yourself as user BC620-nn of the organizational unit. Choose Save.

(C) SAP AG BC620 13-15

Unit: Workflow and IDocs

Topic: Notification concept

As a member of the EDI project team, you wish to test whether

notifications about errors in the control information for inbound

processing are sent to your organizational unit 50010120 (EDI

department).

2-1 This exercise continues from exercise 3 in the unit "A Process Chain" (outbound order

acknowledgment). In this exercise, a file was created in which the data is correct but

the control record is incorrect. This outbound file is to be modified to an incorrect

inbound file.

2-2 Choose Test Inbound Processing Modified Outbound File from the initial node of

the IDoc Interface. This transaction allows you to change the control record so it is

correct and matches the partner profile you maintained in the exercise "partner profiles"

for your vendor T-BILnn. However, you should intentionally make one mistake so that

a notification is generated.

2-3 The sender is vendor T-BILnn, from whom you wish to receive the sales orders. Enter

T-BILnn as the partner number. You should intentionally make one error in the partner

type and enter US (instead of LI). This results in no partner profile being found and the

IDoc administrator is notified. But this is the organizational unit 50010120.

2-4 You must still enter LF as the partner function and ORDRSP for the logical message.

Choose Execute.

2.5 Select Inbox to display the integrated inbox. Execute the work item. Look at the status

record and the logged long text. Access the control record via the tree display for the

IDoc. If you use change mode here, you can change the partner type to LI. After you

have saved your entries and gone back to the previous screen via the F3 key, you can

choose Edit Process Background Processing to continue inbound processing.

2.6 You can display the resulting IDocs via Display IDoc or IDoc Lists (select with the

partner number). One IDoc was generated as a result of the test, the other was

generated as a copy of the original IDoc immediately before the original was modified.

nn is the number of your exercise group (from 1 to 18)

(C) SAP AG BC620 14-1

SAP AG 1999

Using an EDI Subsystem

Converting to another standard

Required data in control records

More documentation

(C) SAP AG BC620 14-2

SAP AG 1999

Using an EDI Subsystem: Unit Objectives

At the conclusion of this unit, you will

be able to:

Recognize the tasks of the EDI subsystem

Describe the differences between required fields and

optional fields in control records

Understand the different ways to inform the EDI

subsystem about various IDoc formats

(C) SAP AG BC620 14-3

QuickDeliver must configure the IDoc Interface for inbound processing:

QuickDeliver connects the EDI subsystem and enters the information about which data is to be sent.

The format definitions for the inbound IDocs can be defined by the subsystem. The R/3 System is

informed that the subsystem is a port.

(C) SAP AG BC620 14-4

SAP AG 1999

Business Scenario



responsible for configuring the IDoc interface.

You wish to connect your EDI subsystem. You must

find out about the work involved in configuring the

subsystem before carrying out the work.

(C) SAP AG BC620 14-5

SAP AG 1999

EDI Subsystem: Responsibilities

Translator

Message handling

Communication

Archiving

MonitoringAddresses

Partner profile

The most important task of the EDI subsystem is converting to or from the required EDI standard;

This task is carried out by the translator as a subfunction of the EDI subsystem. The individual

criteria, for example selecting and assigning fields, are mapping components (usually customer-

specific).

Further processing, message handling, is divided into outbound processing, inbound processing and

status confirmation. In outbound processing, the messages transferred from the translator are

combined in transmission files. In the case of inbound processing, the messages are separated from

the transmission files and sent to the translator. Status confirmations depend on the selected EDI

standard: For example, standard ANSI X.12 uses functional and interchange acknowledgments to

confirm successful data transfer between EDI systems.

Physical data transfer takes place using the communication module of the EDI subsystem. This also

includes the implementation of the communication protocols, for example X.25 and X.400. The

communication module is often produced by a different supplier.

Partner profiles contain the individual settings for a partner and a process, for example mapping.

The addresses are required by the communication module.

Archiving takes place in accordance with various laws and directives. These include the guidelines

laid down by the relevant tax authorities.

When EDI processes are being monitored, certain statuses are expected to be sent to the R/3 System

as reference points to ensure integration with the applications.

(C) SAP AG BC620 14-6

SAP AG 1999

Required Fields in IDoc Inb. Processing: Control Record

IDoc

control record

Inbound

Processing

(partner

profiles)

Partner Message Test?(Number, type, function) (Type, code, function)

Partner Message Test?

Process code; Inbound processing with ALE?;

Permitted agents; And so on.

In inbound processing, the IDoc Interface assigns the key fields from the partner profiles to fields in

the control record. The values of other fields are checked explicitly in the coding.

As a result, an EDI subsystem must send certain fields with their values for IDoc inbound

processing:

Partner, message (three fields each) and test flag (1 field) must correspond to the entries in the

partner profile. This also means that the partner function value, for example, must be left empty if

the corresponding field in the partner profile is also empty.

Direction = 2 (inbound), structure = EDI_DC40 (external control record structure in Release 4.0).

An R/3 System (Release 3.x) would expect a different structure.

Sender port and recipient port

IDoc type. The IDoc Interface checks whether the IDoc type is assigned to the message

(assignments can be maintained from the initial node by selecting Development -> IDoc

type/message).

Special requirements can require additional fields:

(Customer-) extension. (see course BC621 for more information)

Logical address of sender/recipient for automatic forwarding

The IDoc Interface enters values for empty optional fields and checks the values, which can lead to

an error if the wrong value is found.

A complete list of fields can be found in the appendix.

(C) SAP AG BC620 14-7

SAP AG 1999

More Documentation

Begin

…

End

typedef struct z2incodx000

…

z2incodx000

IDoc Interface: Documentation Tools

XML

The EDI subsystem can use a parser which "understands" the appropriate output format for the IDoc

Interface. This means that the external formats (record types and IDoc types) can be recognized by

other systems.

C-headers fulfill the same purpose: They can be included in the corresponding C-programs in the

EDI subsystem.

There are also "meta-IDocs": These are two special IDoc types which describe the external formats

in their data records: The types are called

SYIDOC01 - contains the format definition of an IDoc type (that is record types and segments)

SYRECD01 - contains the format definitions of IDoc record types:

It is conceivable, for example, that an EDI subsystem only recognizes record types from releases

2.X and 3.X (that is, "versions” 1 and 2). Using SYRECD01 (record type versions 1 or 2), the new

record types for Release 4.0 (version 3) can be sent to the EDI subsystem.

Metadata can also be output for XML IDocs.

(C) SAP AG BC620 14-8

SAP AG 1999

The EDI subsystem is used mainly for converting

the IDoc format into an EDI standard (and vice

versa).

The EDI subsystem is an interface to external

systems and has its own responsibilities.

Format definitions can be defined in the EDI

subsystem in a form which can be read by other

systems.

Using an EDI Subsystem: Summary

(C) SAP AG BC620 14-9

Using an EDI Subsystem Exercise

Unit: Using an EDI Subsystem

Topic: More Documentation


Send a meta-IDoc

As a member of the EDI project team for your company, you require

information on IDoc type ORDERS01 for two reasons:

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

EDI”.

2. To inform your EDI subsystem provider of this data structure.

1-1 A machine-readable format should be generated for your subsystem provider. You

decide to transfer the information on IDoc type ORDERS01 with the aid of the

Transport IDoc. A partner profile with partner type LS and partner number

ID3CLNT400 already exists and can be used in this exercise.

Note down the number of the IDoc generated.

1-2 Choose IDoc Display IDoc or IDoc IDoc lists from the initial node of the

IDoc interface to view the IDoc which you have created. Search for "your" IDoc

number.

(C) SAP AG BC620 15-1

SAP AG 1999

Archiving

Archiving object IDOC

Status transfers

Archiving status

(C) SAP AG BC620 15-2

SAP AG 1999

Archiving: Unit Objectives


Archive IDocs

Describe a status transfer

Configure the archiving status in the system

(C) SAP AG BC620 15-3

SAP AG 1999



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:

When communication with QuickDeliver has been tested successfully, SmartMart wishes to

determine which statuses are suitable for archiving and can then be deleted from the system.

(C) SAP AG BC620 15-4

SAP AG 1999

Archiving: Business Scenario

When the business process has been completed, the

processed IDocs should be deleted from the

database.

However, you must archive the relevant IDocs before

they are deleted. The IDocs must therefore be

assigned an archiving status. When configuring the

IDoc Interface, you can determine which statuses can

be archived.

(C) SAP AG BC620 15-5

SAP AG 1999

Archiving Object: IDOC

File System

ArchivingArchiving

programsprograms

PossiblePossible

StorageStorage

IDoc Interface

IDocs which can be archived are copied from the R/3 database to one or more archive files in a file

system (at operating system level) via the archiving programs in the IDoc Interface. Settings in ADK

Customizing (Archive Development Kit, enhanced function builder application) determine whether

the IDocs are exported to an external storage medium (optical disk, for example).

In a second, separate step, all IDocs which have been archived can be deleted from the R/3 database.

The archiving programs in the IDoc Interface are called via the central archiving transaction

(SARA). This transaction provides you with the archiving object IDOC. As a result, you can see

which programs you have to call. A message and time period are entered as "variants" for the

programs (reports), and define when the IDocs are generated. The programs check whether the

current status can be archived.

The deletion job completes an archiving run. A complete archiving run therefore moves the IDocs to

an external storage medium and deletes the IDoc from the database.

(C) SAP AG BC620 15-6

Statuses can only be assigned to an IDoc in defined combinations. This slide illustrates the permitted

combinations for outbound processing: The following mean: 01 IDoc generated

02 Error while sending data to port

03 Data transfer to port OK

04 Error in EDI subsystem control information

05 Error during conversion

06 Conversion OK

07 Syntax error in EDI message

08 Syntax check OK

09 Error in interchange handling

10 Interchange handling OK

11 Error while sending

12 Send OK

14 Interch. Acknowledgment positive (EDI-Subsystem)

15 Interch. Acknowledgment negative (EDI subsystem)

16 Funct. Acknowledgment positive (EDI subsystem)

17 Funct. Acknowledgment negative (EDI subsystem)

18 EDI subsystem triggered OK

20 Error while triggering

22 Send OK, still waiting for acknowledgment (EDI subsystem)

24 EDI subsystem control information OK (EDI subsystem)

25 Further processing despite syntax error

26 Syntax error in IDoc

29 Error in ALE services

30 IDoc is ready for dispatch (ALE services)

31 Error, no further processing (deletion flag)

35 IDoc retrieved from archive

37 IDoc added with error 1

39 IDoc in target system (ALE services)

40 Application document not created in target system

41 Application document created in target system

42 IDoc from test transaction

(C) SAP AG BC620 15-7

SAP AG 1999

Status Transfers in Inbound Processing

68

71

61

50 53

52

6264

736970

60

65

56

51

63

54 57

Selected statuses can be archived in the SAP

standard system

66

74

The permitted status combinations for inbound processing are displayed above. 50 IDoc added

51 Application document not posted

52 Incomplete application document posted

53 Application document posted

54 Error during formal application check

56 Incorrect IDoc added

57 Test IDoc: Error during application check

60 Syntax error in IDoc

61 Further processing despite syntax error

62 IDoc sent to application

63 Error while sending IDoc to application

64 IDoc is ready to be sent to application

65 Error in ALE services

66 IDoc waiting for predecessor (serialization)

68 Error, no further processing (deletion flag)

69 IDoc edited

70 Original version of edited IDoc

71 IDoc retrieved from archive

73 IDoc archived

74 IDoc created from test transaction

(C) SAP AG BC620 15-8

From the initial node of the IDoc Interface, select Control -> Status maintenance (transaction WE47)

to change the attributes of an individual status. An example of an attribute is whether or not

archiving is permitted.

This transaction can also be used to find out general information about a certain status.

(C) SAP AG BC620 15-9

SAP AG 1999

Archiving: Summary

All archiving programs are addressed via the central

archiving transaction SARA. The archiving object is

IDOC.

IDocs can only be deleted if they have been archived.

The archiving run must be complete.

IDocs can only be archived if they have been

assigned a status which can be archived. The

statuses suitable for archiving can be configured in

the IDoc interface.

(C) SAP AG BC620 15-10

The IDoc Interface allows the exchange of business data between SAP applications and external

systems. The formats used for transmitting data (IDoc types) are documented.

IDocs are exchanged with external systems on a partner-specific and message-specific basis. IDoc

data flow is therefore defined via the partner profiles and the port definitions.

In outbound processing, IDocs can be collected in a group or sent to the external system

immediately.

In inbound processing, IDocs can be processed via workflow.

Exception handling for incorrect IDocs always takes place via workflow.

Monitoring programs and statistics programs are available for the IDoc data flow. Active monitoring

can be used to automatically notify the agent responsible.

IDocs which have been processed completely can be archived.

If the IDoc types in the standard system do not meet your requirements, you can add upwardly-

compatible extensions or define your own IDoc types. This is the subject of course BC621.

(C) SAP AG BC620 16-1

SAP AG 1999

This section contains supplementary material

to be used for reference

This material is not part of the standard course

Therefore, the instructor might not cover this

during the course presentation

Appendix

(C) SAP AG BC620 16-2

Appendix

Glossary

Access sequence Sequence used by Message Control to access

condition records when searching for messages.

Access An access identifies the document fields used by the system

when searching for a condition record.

Basic type IDoc type supplied by SAP. Basic types can be modified by customers to

create a new, upward-compatible IDoc type.

Condition component Part of the hierarchy which is examined

when searching for a message. Example: the message type which is

at the top of the hierarchy: when a (new) purchase order is posted,

only the messages under the node for message type NEW are

searched. Condition record Data record in which the key fields represent the condition under which the

message is "found". The remaining fields describe the message itself.

Therefore, if one of the data records transferred from the application matches

these key fields, the message is found and can be processed (e.g. exported as a

print form or as an electronic message.

Control record The part of an IDoc which contains the data for identifying the sender and

recipient, as well as the structure of the IDoc itself. Each IDoc always has one

control record.

Data record The part of an IDoc which contains the application data. An IDoc usually

contains more than one data record.

EDI = Electronic Data Interchange (e.g. documents) between business partners,

sometimes in separate countries, who may use different hardware, software

and communication services. The data is formatted according to specific

standards.

(C) SAP AG BC620 16-3

EDI message Standard format for a business process (for

example, a purchase order) to be handled by EDI. Various EDI

standards (EDIFACT or ANSI X12) can define different EDI

messages for the same business process.

EDI standard General format for data to be transferred

electronically.

An EDI standard generally comprises:

EDI syntax

Data element service

Message type service

The SAP standard 'IDoc' is not yet an EDI standard, but can be

compared to other EDI standards.

EDI subsystem System which converts the SAP standard IDoc into

an EDI standard (e.g. EDIFACT, ANSI X12) and vice versa. In

addition to this task (which is carried out by the EDI subsystem

converter), there are also administration activities, e.g. archiving

the transferred messages, and technical tasks, e.g. technical

connection to the subsequent system and syntax checks for

formats, to be considered. Field catalog Contains all fields which can be selected as key fields for condition tables in

Message Control.

File interface = port type “File”

Hierarchy level Determines the position of a segment in a tree structure. A segment carries

business data in an IDoc. Dependencies in the application data can be

represented in this tree structure, i.e. the various hierarchy levels.

IDoc Interface Definition of IDoc types and data interchange methods (port

definitions) between SAP Systems and partner systems.

IDoc type SAP format in which the data for business process is to be sent.

An IDoc is a real business process, formatted according to a

certain IDoc type.

Inbound processing Conversion and processing of data for a business process from

the time the data is received in IDoc format to the posting of the

corresponding document(s) in the SAP application.

Mapping Rules for assigning the data elements of an EDI message type to

the fields of an IDoc type.

Message Control Module designed to offer interfaces for further processing for applications.

This includes descriptions of the various data configurations and the required

actions. An example of an action is printing a document at a certain time in

German. The action is triggered when the application transfers data which

matches your configuration.

Message determination A check to determine whether the

application data matches the condition records (specified in

(C) SAP AG BC620 16-4

Customizing)". If this is the case, one or more messages are

"found" and can then be processed (e.g. sent electronically).

In message determination, a search is made for the condition

records using a predefined hierarchy.

Message status record = MC record. Log record for the MC

table which describes the send status of a message in Message

Control.

Message Business process (for example, a purchase order), which is

transferred in IDoc-Format between an SAP System and an

external system.

Notification If an error occurs (for example, an IDoc with incorrect syntax), a notification

is sent to one or more users. The users responsible are defined in the IDoc

Interface or indirectly via the organization model (PD-ORG). Notifications

are sent to the integrated inbox.

Optional segment Part of an IDoc type (standard format for data communication),

which can include additional, optional data about the business

process. The segment does not therefore have to appear in an

IDoc for a specific business process.

Outbound file Contains certain IDocs to be sent for port type “File”.

Outbound processing Conversion and processing of SAP document data from posting a document to

sending the data in IDoc format.

Partner profile Definition of the general conditions for electronic data

interchange with a business partner via the IDoc Interface: which

message is sent in which direction using which method?

If a partner profile does not exist, communication with a partner

via the IDoc Interface is not possible.

Partner Communication partner for the IDoc Interface.

Definition from SD: “An individual within or outside of your own

organization who is of commercial interest and who can be

contacted in the course of a business transaction.”

Port Description of the channel used by the SAP system for

communicating with the external system during electronic data

interchange. There are various technical methods for

implementing this type of communication (port types). The

selection of the port type depends on the technical configuration

of the external system. Example: most EDI subsystems read

IDocs in the form of sequential files, i.e. the port type 'File' is

used.

Process code Another name for a defined processing type, e.g. a function

module or an SAP Business Workflow task. In contrast, a

defined IDoc type (standard format for data communication) is

usually assigned to a certain process code. If the processing type

for this IDoc type is to be changed, you should assign the

corresponding process code to the new processing type. Without

(C) SAP AG BC620 16-5

the process code, this IDoc type must be assigned to the new

processing type directly.

Record type An IDoc type consists of the following three record types:

- Control record

- Data record

- Status record

Required segment The part of an IDoc type which contains important application data and must

therefore exist in an IDoc for an actual business process.

Schema A group of messages. A schema is searched for messages

which are to be processed for the specified data configuration (e.g.

sent electronically or printed). Segment Structure which includes the application data for an IDoc from the data

records. As a result, the data can be assigned to the correct application fields.

Status Processing status of an IDoc (SAP standard format for

electronic data interchange), for example: "generated" or "ready

for sending".

An IDoc has usually had several statuses, which are stored in the

status records and reveal information about the IDoc history. The

current (processing) status is also stored in the control record for

the IDoc.

Status confirmation Report from an external system about the

processing status of business data received from the R/3 System in

IDoc format. The status confirmation is added to the IDoc in the

R/3 System in the form of status records. Status file File which contains the status records sent to the IDoc Interface by the EDI

subsystem for outbound messages.

Status group The status group contains several statuses ("milestones" in the

process chain), so that the monitoring programs only have to

consider these groups and not each individual status. Examples:

Group 3 = outbound: IDoc in the external system

Group B = inbound: IDoc sent to application

Status record One of the three record types in an IDoc (SAP standard format for electronic

exchange of application data).

Each status record contains a status which corresponds to one step in IDoc

processing. This means that the number of status records increases as the

processing continues.

Translator Converts internal data formats (IDocs) into EDI messages and

vice versa. The translator is a component of the EDI subsystem.

Transmission file A data packet which contains the messages to be exchanged

electronically. The messages are EDI messages, i.e. they are

formatted according to an EDI standard (e.g. EDIFACT).

The conversion of the SAP standard IDoc into the EDI standard

is carried out by an external system (EDI-subsystem).

(C) SAP AG BC620 17-6

Important Menu Paths

Archiving

Tools Administration

Administration Data archiving

Display IDoc

IDoc initial screen:

IDoc Display IDoc

IDoc Administration


Control IDoc Administration

IDoc initial screen

Tools Business Communication

IDoc IDoc Basis

IDoc statistics


IDoc IDoc statistics

Maintaining an RFC destination


IDoc RFC destination

Maintaining archiving status


Control Status maintenance

Partner profile


IDoc Partner profile

Port definition


IDoc Port definition

Processing tests


Test <menu option according to the required function>

(C) SAP AG BC620 17-7

Required Fields in Inbound Processing (IDoc Control Record)

The following tables contain the fields from the IDoc control record which:

must always be entered by the external system in structure EDI_DC40

must be entered in special cases by the external system in structure EDI_DC40

may be entered by the external system in structure EDI_DC40 (optional fields). If the values are entered, they

are checked by the IDoc Interface.

Fields which must always be entered by the external system:

Field Description

TABNAM Record type (structure): = “EDIDC_40” for IDocs to be processed in Release 4.0.

DIRECT Direction: = “2” (inbound).

IDOCTYP Basic type.

MESTYP Message type, e.g. ORDERS. Assigned to one or more IDoc types in the IDoc

Interface.

SNDPOR Sender port. Must be defined as a port in the receiving R/3 System.

SNDPRN Partner number of the sender. Must correspond to a partner number from the

partner profiles.

SNDPRT Partner type of the sender. “LS” (logical system) in ALE scenarios. In non-ALE

scenarios, this value is usually “KU” (customer) or “LI” (vendor).

RCVPOR Receiver port: = “SAP<SYSID>”, where <SYSID> is the ID of the receiving R/3

System, e.g. C11.

RCVPRN Partner number of the recipient. In ALE scenarios, this value is

<SYSID>CLNT<CLNT>, where <CLNT> is the client of the receiving R/3

System and <SYSID> is defined in the field RCVPOR. In non-ALE scenarios,

this value is application-specific (e.g. the value can be the organization number).

RCVPRT Partner type of the recipient “LS” (logical system) in ALE scenarios. In non-ALE

scenarios, this value is application-specific (e.g. “SD” for the SD module).

Fields which are entered in special cases

Field Description

CIMTYP Customer extension to a basic type. Must be present in the corresponding partner

profile.

MESFCT Message function for further message division. Must be present in the

corresponding partner profile.

MESCOD Message code for further message division. Must be present in the corresponding

partner profile.

SNDPFC Partner function for further partner division. Must be present in the corresponding

partner profile.

(C) SAP AG BC620 17-8

TEST Test flag.

EXPRSS Express flag: if this flag is set, the ALE services are called immediately in IDoc

inbound processing.

Optional fields

Field Description

MANDT Client in the R/3 System. An incorrect entry causes an error.

DOCREL R/3 release version. An incorrect entry causes an error.

OUTMOD Outbound processing mode (e.g. send IDocs individually, start subsystem). Each

value is overwritten in inbound processing.

DOCNUM IDoc ID. As the inbound IDoc is generated first in the database, each value here is

overwritten by the internal IDoc ID.

CREDAT Date of IDoc generation. Handling as in DOCNUM.

CRETIM Time of IDoc generation. Handling as in DOCNUM.

(C) SAP AG BC620 17-9

Typical combinations of MC fields and fields from outbound

partner profiles

Process code and Message type are fields in the IDoc partner profiles, all other fields belong to

Message Control (MC):

Partner

function

Application Message

type

Change Message

category

Process code

LF EA NEU REQOTE ME12

LF EF NEU ORDERS ME10

LF EF NEU X ORDCHG ME11

AG V1 AN00 QUOTES

AG V1 BA00 ORDRSP

WE V2 LAVA DESADV SD05

WE V3 AUS1 EXPINV

RE V3 RD00 INVOIC SD09 (invoice)

(C) SAP AG BC620 17-10

Example: Command file (Shellscript) - Outbound

Note: in this example, a UNIX operating system is used.

#!/bin/sh

DIRWORK=/users/ediadm

cd $DIRWORK

FILE='basename $1'

date >> $DIRWORK/ediadm.trace

echo ++ run external system with file $FILE >> $DIRWORK/ediadm.trace

# insert command to start EDI subsystem here echo ++ removed IDoc file $FILE from application server >> $DIRWORK/ediadm.trace

chmod 666 $DIRWORK/ediadm.trace

(C) SAP AG BC620 17-11

Example: Command file (Shellscript) - Inbound

Note: in this example, a UNIX operating system is used.

#!/bin/sh

DIREXEC=/users/ediadm/run

DIRWORK=/users/ediadm

cd $DIRWORK

date >> $DIRWORK/ediadm.trace

echo ++ start SAP system with file $1 >> $DIRWORK/ediadm.trace

$DIREXEC/startrfc -3 -t

-d <system ID> -u <user> -p <password> -c <client>

-h <router string> -s <system number>

-g <gateway machine> -x <gateway name>

-F EDI_DATA_INCOMING

-E PATHNAME=$DIRWORK/$1

-E PORT=<subsystem>

chmod 666 $DIRWORK/ediadm.trace

Note: the script for status files only differs from the script for inbound IDocs because the

function module EDI_STATUS_INCOMING is called.