Download ppt - Ale Idoc Edi Training Ppt

Transcript
Page 1: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Main Business Scenario

Message

IDoc IDoc

Company2

Company1

SAP R/3 System SAP R/3 System

EDI Subsystem EDI Subsystem EDI Subsystem EDI Subsystem

SAP R/3 System SAP R/3 System

Page 2: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Regional installation Country-wide installation local system business objects

Distributed Business Processes

Page 3: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Distributed applications arise due to:

The globalization of markets

Company-wide business processes

Independent and autonomous business units

Reasons for Distributed Applications I

Page 4: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Distributed applications arise due to:

Availability requirements (7x24, Upgrade)

Data protection

Industry, language and country versions

Time zones

Communication with non-SAP systems

Reasons for Distributed Applications II

Page 5: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Distributed applications arise due to:

Load distribution

mySAP.com components (New Dimension Applications)

Failure risks

Use of existing systems

Reasons for Distributed Applications III

Page 6: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Document Exchange

Page 7: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

EDI and ALE

Document

IDoc

Message

IDocIDoc

SAP R/3 SystemSAP R/3 System

EDI SubsystemEDI Subsystem EDI SubsystemEDI Subsystem

SAP R/3 SystemSAP R/3 System

Page 8: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Component of EDI system

Page 9: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Structure of EDI message packet

EDI data transmission

Page 10: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

The Benefits of the EDI Process

•Reduced data entry errors

•Reduced processing cycle time

•Reduced paper work

•Data in electronic form

•Reduced inventories

•Process visibility

•Competitive advantage

Page 11: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

SAP EDI Boundaries

Page 12: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionOutbound and Inbound Processing

Outbound Processing Inbound

IDoc Interface/ALE Services

External System

SAP Application

R/3 System

Page 13: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

EDI enabled application for outbound process

Page 14: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Process Flow: Sending Data

Check partner, find port

Transfer data,process further

Post document

Generate IDoc

R/3 SystemR/3 System

External systemExternal system

Report Status

Page 15: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

IDoc Settings: Sending Data

Post document

Generate IDoc

Check partner, find port

Transfer data,process further

Archive IDoc ?Archive IDoc ?

EDI Subsystem ?EDI Subsystem ?

Partner ProfilesPartner Profiles

Port DefinitionPort Definition

DocumentationTools

DocumentationTools

R/3 SystemR/3 System

External SystemExternal System

Page 16: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Message Processing: IDocs

RSNASTED

Check MC record

Read partner profile

Call selection module(from application)

Call ALE Services

Transfer according tooutput mode

'1'/ '2' '3'/ '4'

Single IDoc Multiple IDocsvia RSEOUT00

Page 17: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Process flow and data flow in an outbound EDI process

Page 18: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Details of outbound process with message control

Page 19: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Outbound process with message control

Page 20: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

Page 21: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

External System External System Data flow

A Process Chain

Test, monitoring

Message Control, Workflow

Archive IDoc? Archive IDoc?

EDI Subsystem? EDI Subsystem?

Partner Profiles Partner Profiles

Port Definition Port Definition

Documentation Tools

Documentation Tools

IDocs in Business

Processes

R/3 System

Page 22: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Message Control and IDocs

Message determination and message processing

Condition components

Dispatch times

Page 23: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionOutbound Processing using Message

Control

IDocIDoc

MCMCrecordrecord

DocumentDocument

SAP Application

Message Control (MC)

External System

IDoc Interface / ALE Services

Page 24: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

Outbound Process

Page 25: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Outbound Processing using MessageControl

MCMCrecordrecord

DocumentDocument

SAP Application

MC

IDoc Interface/ALE Services

Find proposal

Edit

Process

Page 26: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

M e s s a g e C o n t r o l

S A P A p p l i c a t i o n

M e s s a g e D e t e r m i n a t i o n

E d i t i n g

P r o c e s s i n g ( t a b l e T N A P R )

A p p l i c a t i o n d a t a

M e s s a g e p r o p o s a l

M C r e c o r d

P r o c e s s i n g p r o g r a m ,

f o r e x a m p l e R S N A S T E D

O u t p u t , f o r

e x a m p l e I D o c

Page 27: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Condition Elements

Procedure

SAP Application

Output Type

Access Sequence

Condition Table

1:n

m:n

n:1

m:n

Page 28: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

MasterIDoc

MasterIDoc

Direct Outbound Processing using ALE

SAP Application

External System

IDoc Interface / ALE Services

Page 29: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Direct outbound service

Page 30: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Details of outbound process without Message control

Page 31: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Technical flow: Outbound process without message control

Page 32: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Process Flow: Receiving Data

Error handling

ok?

ok?

No

No

Check port & partner,Generate IDoc

Send data toR/3 System

transfer

Post document

R/3 SystemR/3 System

External SystemExternal System

Page 33: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion IDoc Settings: Receiving Data

Error handling

Send data toR/3 System

Check port & partner,generate IDoc

Post document

Port Definition,Partner ProfilesPort Definition,Partner ProfilesArchive IDoc ?Archive IDoc ?

DocumentationTools

DocumentationTools

EDI Subsystem ?EDI Subsystem ?

R/3 SystemR/3 System

External SystemExternal System

Page 34: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Process flow and data flow in an inbound EDI process

Page 35: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

The inbound process using a direct function module

Page 36: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

IDocIDoc

Direct Inbound Processing using ALE

IDocIDoc

SAP Application

External System

IDoc Interface & ALE Services

Page 37: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Direct inbound processing using ALE

Page 38: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Technical flow of inbound process using direct function module

Page 39: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Inbound Processing using Workflow

DocumentDocument

IDoc +IDoc +processprocess

IDocIDoc

SAP Application

SAP Business Workflow

External System

IDoc Interface & ALE Services

Page 40: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Inbound processing using workflow

Page 41: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Technical details of inbound process via workflow

Page 42: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 43: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionException Handling with Workflow

R/3 SystemR/3 System

Check partner, generate IDoc

Post document

Error handling

ok?

ok?

No

NoMessage

Express

Page 44: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Exception Handling

Page 45: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Triggering the inbound SAP EDI process from subsystem

Page 46: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Output in Various Formats

Begin

End

typedef struct z2incodx000

… z2incodx0 00

?

? ? ?

XML

Page 47: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Solutions for IDoc Development

SAP SolutionsR/3, BW, APO, ...

File Port

(IDOCflat fileformat)

tRFC PortFile Port

(XMLflat fileformat)

MailAttachment

Intermediate Documents (IDoc)

3rd-party products(e.g. Message Handler,

EDI Subsystem,ALE Converter)

CustomerDevelopment

EDI ALE

SAP Business Connector(see next Chapter)

Page 48: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Conversions for Messages between ERP Systems

WithoutConversion

SAP System R/3

SAP System R/3

IDoc

Converter

EDI Subsystem

EDI

SAP System R/3

?

ERP System

EDI Subsystem

IDoc

ALE Converter

ALE Converter

SAP System R/3

ERP System

IDoc

?

Different kinds of conversions are possible

Which one to use depends on the relationship between thepartners

Page 49: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

IDoc Concept

Message-oriented

Asynchronous

System 1

Document

System 2

IDoc Document

Page 50: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

IDoc Applications

WorkflowWorkflow

BusinessBusinessConnectorConnector

ElectronicElectronicFormForm

ALEALE

EDIEDISubsystemSubsystem

R/3 SystemR/3 System

R/2 SystemR/2 System

OtherOtherSystems...Systems...

InternetInternetIntranetIntranet

IDocIDoc

Page 51: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

IDoc Record Types

Status records

Data records

Control record

Page 52: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Control record

Control record IDoc IDPartnerIDoc type and logical messageExternal structure

Page 53: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Data Records and Segment Structures

Data record

Control part, containssegment names

Application data

Field 2Field 1 ...

Segment

Page 54: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionStatus Record

Status Record IDoc IDStatus information

Page 55: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionIDoc Record Types: Summary

Control record

Data records

IDoc IDPartnerIDoc type and logical messageExternal structure

Control part Application data

Status records IDoc IDStatus information

Page 56: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion 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!

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.

Page 57: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionIDoc 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

Page 58: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

IDOC TYPE

Page 59: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

Page 60: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 61: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

SalesCustomer

1. Order

Message type: ORDERSIDoc type : ORDERS01 (3.0A)

ORDERS02 (3.0D) ORDERS03 (4.0A)

ORDERS04 (4.5A)

2. Order confirmation

Message type: ORDRSPIDoc type : ORDERS0x

3. Delivery

Message type: DESADVIDoc type : DESADV01 (3.0A)

DELVRY01 (4.0A) DELVRY02 (4.5A)

4. Billing document

Message type: INVOICIDoc type : INVOIC01 (3.0A)

INVOIC02 (4.0A)

Relationship between Message Type and IDocType

Page 62: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

SAP AG 1999

Release3.0

Internal and External Structures

Field 1 Field 2

Field 1 Field 2 Field 3 Field 4

Segment

internal

external

E1...

E2...001

Page 63: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Data Structures:

IDoc Record Types

IDoc Types

IDoc Segments

Development and Extension

Development Environment for IDoc Types

Page 64: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Function module

Program

Report

Business Workflow

Function module

IDoc Interface

Application

Segmenttype

Segment

IDoc Type

Segmentname

Outbound Processing

Inbound Processing

Data structure

Components of the IDoc Process

Page 65: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionIDoc Terms: Basic Type and Extensions

Basic typeBasic type

IDoc typeIDoc type==

Basic typeBasic type

IDoc typeIDoc type

ExtensionExtension

==

++

Page 66: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

The IDoc type is a hierarchy consisting of segments and complex data structures which can receive an application document.

There is a formal distinction between basic types and extensions.

The specific document in "IDoc format" is called an IDoc and has a specific IDoc type.

An extension expands a basic type (SAP standard) by a customer specific segment, which are directly or indirectly dependent of basic type segments. The segments of the basic type are represented by the roots and the sub-trees, formed by the customer segments.

The control record identifies the IDoc type using the following fields:IDOCTYP Name of the basic typeCIMTYP Name of extension

Examples:

IDoc type ORDERS01 from standard system, not extended:

The field IDOCTYP has the value ORDERS01

The field CIMTYP is empty

IDoc type ORDERS01 from standard system, extended by customers:

The field IDOCTYP has the value ORDERS01

The field CIMTYP has the value of the name of the extension

Page 67: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionIDoc Terms: Segment

Segment type /partner/ cccccSegment type /partner/ ccccc

Segment name /partner/ccccc000Segment name /partner/ccccc000

Segment name /partner/ccccc001

Segment type E1cccccSegment type E1ccccc

Segment name E2ccccc000Segment name E2ccccc000

Segment name E2ccccc001Segment name E2ccccc001

Segment name E2ccccc013Segment name E2ccccc013

Version 1e.g. 3.0A

Version 2e.g. 3.0C

Version 14e.g.7.7x

Segment name /partner/ccccc013

Page 68: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

A segment consists of one

SAP release independent segment type

At least one SAP release dependent segment name (segment definition).

Segment types are structures in the dictionary. They are used as internal names in the SAP System.

An external system, for example an EDI subsystem, can recognize the version of the current segment by the segment name.

Segment types are a maximum of 27 digits. Segment names are derived from the segment types by adding 3 digits (starting with 000). The naming conventions are preserved through the IDoc definition tools.

SAP segments differ from this rule:

Segment types start with “E1”, segment names with “E2“ and additionally have a version number.

The customer can also use the namespace "Z1"/ "Z2" or a customer prefix. Partners always use a prefix.

All segment fields are of type CHAR. Thus all SAP data types with similar characters are permitted, for example NUMC or CLNT.

Page 69: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

By releasing segments and IDoc types, the externalinterface is "frozen" and given unique names forthese objects for an external partner system.

There can only be one segment version for each SAPRelease (for example 4.0B).

The IDoc definition tools control the release.Aftereach release, further development leads to newversions.

Changes must be made in accordance with strictrules so that the interface remains compatible.

IDoc Functions: Release and Version Creation

Page 70: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

The version of an IDoc type or segment is created at a maintenance level. The last version remains the current one in all following maintenance levels. The current version is only replaced by the development of a new version.

All old versions remain in the system so that it is possible to reduce the current version to an older version at any time. This enables the subsystems to be kept compatible even after an upgrade.

Segment version:

New fields can only be added to an existing segment.

By doing this the structure of segment types gets extended.

A new segment name is formed.

Version of an IDoc type:

You may only add new segments.

A new IDoc type is created.

A new version of an existing segment alone does not lead to a new version of IDoc type.

Note for outbound processing: In the partner profiles the versions are listed as follows:

IDoc type: By entering the IDoc type.

Segment: By entering an SAP Release. This leads to the reduction of all segments which are used in the IDoc type to an older version, that is, to the current version stated in the release. If the field remains empty, the current version of all segments relating to the current release is used.

Note for inbound processing: No settings are necessary or possible. The IDoc Interface recognizes the version and processes the data accordingly.

Page 71: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Additional customer fields are recorded in their owncustomer segments.

Customer segments depend on SAP segments(successor or child relationships).

The processing of customer segments is exclusivelyimplemented in the customer exits of the codingprovided in the standard system.

Basic Rules for Customer Extension

Page 72: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Function Module

Program

Report

Business Workflow

Function Module

IDoc Interface

Application

SegmentType

Segment

IDoc Type

Segment Name

Data structure in the WEDIarea menu

Outbound and inboundprocessing: Typically throughtransaction "CMOD", otherwisethrough individual technique

Documentation: In the WEDIarea menu

Areas of Customer Extension

Page 73: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Combine the required fields and their datatypes in the dictionary.

Definition of required segments,segment editor.

Definition of extension, IDoc type editor.

Assignment of a logical message to theIDoc type, surrounding field menu of IDoctype editor.

Steps For Extending the Data Structure

Page 74: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Definition of a project,project management, attribute

Choosing the "correct" customer exits,project management, SAP extensions

Implementation of the selected customer exits,project management, extension components

Outbound processing: reading of the SAP databaseand data in "IDoc format"

Inbound processing: writing data from the "IDocformat" into the SAP database

Activate project in project management

Steps for Extending Processing

Page 75: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionPort Definition

Port types and when they are used

Port definition parameters

Communication with Older Releases

Page 76: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Overview Diagram (Sending Data)

R/3 SystemR/3 System

Post document

Generate IDoc

Check partner, find port

Transfer data,process further

Archive IDoc ?Archive IDoc ?

EDI Subsystem ?EDI Subsystem ?

DocumentationTools

DocumentationTools

Partner ProfilesPartner Profiles

Port DefinitionPort Definition

External SystemExternal System

Page 77: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

IDoc Interface: Port Types

IDoc Interface

CPI-C

R/2 SystemExternal System

File

IDoc/IDoc/statusstatus

IDoc/IDoc/statusstatus

PI

IDocIDoc

?

XML

IDocIDoc

tRFC

IDocIDoc

Internet

IDocIDoc

Page 78: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 79: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Port Definition: Port Type "File"

Command file

Outbound file

Inbound file

Status file

IDoc file

Status report

rfcexec

out.script

RFC destination(TCP/IP connection)

Page 80: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionProcess Flow: Port Type File (with Triggering)

1

Write

IDoc file

4

Read

2

RFC

3

Call

rfcexec

out.script

1

Write

IDoc fileStatus report

startrfc

in.scriptstatus.script

3

RFC

2

Call

4

Read

IDoc Interface

External System

Page 81: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion 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.

Page 82: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Port Type XML: Flat File and XML File

EDI_DC40 004000000000030702346B 3013 ORDERS01...

E2EDP0100500400000000003070230000210000000200E2EDP2000400000000003070230000220000210323...

E2EDPT1001004000000000030702300002600002103BESTDE2EDPT2001 004000000000030702300002700002604Thisis

Page 83: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 84: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

EDI_DC40

E1EDP01

E1EDP20

E1EDPT1

E1EDPT2

<EDI_DC40 SEGMENT="1"><TABNAM><![CDATA[EDI_DC40]]></TABNAM><MANDT>004</MANDT><DOCNUM>0000000000307023</DOCNUM>...<E1EDP01 SEGMENT="1"><POSEX>00010 </POSEX><ACTION>001</ACTION><PSTYP>0</PSTYP><MENGE>23.000</MENGE>......<E1EDP20 SEGMENT="1"><WMENG>23.000 </WMENG><EDATU>19990622</EDATU></E1EDP2>...<E1EDPT1 SEGMENT="1"><TDID>BEST</TDID><TSSPRAS>D</TSSPRAS>.........<E1EDPT2 SEGMENT="1"><TDLINE>This is thepurchase order text.</TDLINE>......</E1EDPT1> </E1EDP01>

Page 85: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 86: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionPort Definition - Port Type tRFC

RFC destination(R/3 connection)

Port name (assigned automatically)

Application server forreceiving system

Page 87: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

Page 88: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Process Flow: Port Type tRFC

IDoc Interface

External System

RFC Interface

RFC Interface

TCP/IP

Page 89: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 90: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

Page 91: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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

Page 92: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionOverview Diagram (Sending Data)

R/3 SystemR/3 System

Post document

Generate IDoc

Check partner, find port

Transfer data,process further

Archive IDoc ?Archive IDoc ?

EDI Subsystem?EDI Subsystem?

DocumentationTools

DocumentationTools

Partner ProfilesPartner Profiles

Port DefinitionPort Definition

Page 93: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Partner Profiles: Fields

Partner

Applicat ion

Process codeLogical message

Partner

Permitted agents

General

Outbound Processing

PartnerMessage

Process codePermitted agents

Inbound Processing

MC parameters

Partner

Message

Port

IDoc typeEDI structurePermitted agents

Page 94: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 95: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Checking Partner ProfilesPartner 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.

Page 96: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Partner Profiles: Outbound Processing I

IDocIDoc

MCMCrecordrecord

DocumentDocument

DocumentDocument

SAP Application

MC

Receiving System

IDoc Interface / ALE Services

MC settingsMC settings

General+outboundGeneral+outbound

Page 97: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionPartner 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)

GeneralOutbound

MCsettings

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

Partner: QD ; Appl: EF; OtptType : NEW

MC record

Page 98: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Test Tool Options

Page 99: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion 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.

Page 100: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Test Tool Options (2)

Function Module

Directcall

(inboundonly)

Generatefile

Standard processingMass test

Page 101: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Test Layers: Overview

InboundIDoc file

Application

IDoc Interface

WorkflowMC

OutboundIDoc file

Statusconfirm.

WE12

WE16 WE17

WE19 ,WE18WE15

WE14, WE19

File System

ExternalSystem

WE18

Page 102: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

IDOC TEST TOOLS

Page 103: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Test Layers: Outbound Processing

Application

MC

WE15

WE14, WE19

ExternalSystem

IDoc Interface

MC

Page 104: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 105: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

Test Layers: Inbound Processing

InboundIDoc file

Application

IDoc Interface

Workflow

OutboundIDoc file

WE12

WE16

WE19

File System

Page 106: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 107: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaionTest Layers: Status Confirmation

Application

IDoc Interface

Workflow

WE17

File System

Outboundfile with

SYSTAT01

WE12

WE16

WE19 ,WE18

Inbound file with

SYSTAT01

Statusconfirm.

WE18

Page 108: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

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.

Page 109: Ale Idoc Edi Training Ppt

Siemens Information Systems Ltd.

Global networkof innovaion

When to Test Which Function?

Data exchange with the file system:WE14(outbound), WE16 (inbound), WE17 (statusconfirmation, inbound)

Processing MC record:WE15

Data transfer from the IDoc Interface to additionalinbound processing:WE19

Data transfer to any port:WE14