Ale Idoc Edi Training

Siemens Information Systems Ltd.
Global network of innovaion
Main Business Scenario
Company1
Company2
SAP R/3 System

IDoc
SAP R/3 System

IDoc
EDI Subsystem
Message
EDI Subsystem


Reasons for Distributed Applications I
Distributed applications arise due to: The globalization of markets Company-wide business processes Independent and autonomous business units

Reasons for Distributed Applications II
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 III
Distributed applications arise due to: Load distribution mySAP.com components (New Dimension Applications) Failure risks Use of existing systems

Document Exchange

EDI and ALE
Document
SAP R/3 System

IDoc
IDoc
SAP R/3 System

IDoc
EDI Subsystem
Message
EDI Subsystem

Component of EDI system

EDI data transmission
Structure of EDI message packet

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

SAP EDI Boundaries

Global network of innovaion Outbound and Inbound Processing
SAP Application
IDoc Interface/ALE Services

R/3 System
External System
Outbound Processing Inbound

EDI enabled application for outbound process

Process Flow: Sending Data

R/3 System Post document
Generate IDoc
Report Status
Check partner, find port
Transfer data, process further External system

IDoc Settings: Sending Data

R/3 System
Post document
Archive Archive IDoc IDoc ? ?
Generate IDoc
Partner Partner Profiles Profiles
Port Port Definition Definition
External System EDI EDI Subsystem Subsystem ? ?

Transfer data, process further
Documentation Documentation Tools Tools

Message Processing: IDocs
Check MC record Read partner profile Call selection module (from application) Call ALE Services Transfer according to output mode '1'/ '2' Single IDoc '3'/ '4' Multiple IDocs via RSEOUT00
R S N A S T E D

Process flow and data flow in an outbound EDI process

Details of outbound process with message control

Outbound process with message control


R/3 System
IDocs in Business Processes
Archive Archive IDoc? IDoc?

Test, monitoring Message Control, Workflow A Process Chain
EDI EDI Subsystem? Subsystem?
External System Data flow

Message Control and IDocs
Message determination and message processing Condition components Dispatch times

Global network of innovaion Outbound Processing using Message
Control
SAP Application
Document
Message Control (MC)

MC record
IDoc Interface / ALE Services

IDoc
External System

Outbound Process
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 Processing using Message Control
SAP Application
Document
Find proposal Edit Process
MC
MC record
IDoc Interface/ALE Services

Global network of innovaion Message Control
SAP Application
Editing
Application data
Message Determination
MC record
Message proposal
Processing (table TNAPR) Processing program, for example RSNASTED

Output, for example IDoc

Condition Elements
SAP Application
1:n
Procedure
m:n
Output Type
n:1
Access Sequence
m:n
Condition Table

Direct Outbound Processing using ALE
SAP Application
Ma st er ID oc
IDoc Interface / ALE Services

Comm. IDoc Comm. IDoc Comm. IDoc
External System

Direct outbound service

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.

Details of outbound process without Message control

Technical flow: Outbound process without message control

Process Flow: Receiving Data

External System Send data to R/3 System transfer
R/3 System Check port & partner, Generate IDoc Post document
ok? No ok? No
Error handling

Global network of innovaion IDoc
Settings: Receiving Data

External System
Send data to R/3 System
EDI EDI Subsystem Subsystem ? ?
Documentation Documentation Tools Tools Port Port Definition, Definition, Partner Partner Profiles Profiles
Check port & partner, generate IDoc Post document
Error handling R/3 System

Process flow and data flow in an inbound EDI process

The inbound process using a direct function module

Direct Inbound Processing using ALE
External System
IDoc
IDoc Interface & ALE Services
IDoc
SAP Application

Direct inbound processing using ALE

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.

Technical flow of inbound process using direct function module

Inbound Processing using Workflow
External System
IDoc
IDoc Interface & ALE Services

IDoc + process
SAP Business Workflow

Document
SAP Application

Inbound processing using workflow

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.

Technical details of inbound process via workflow

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", "CPIC"). 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.

Exception Handling with Workflow
R/3 System Check partner, generate IDoc
Post document
ok?
No
ok?
Express Message
Error handling
No

Exception Handling
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.

Triggering the inbound SAP EDI process from subsystem

Global network Output of innovaion
in Various Formats
? ? ?
Begin End
XML
typedef struct z2incodx000 z2incodx0 00

Solutions for IDoc Development
SAP Solutions R/3, BW, APO, ...

EDI Intermediate Documents (IDoc) ALE
File Port (IDOC flat file format)
File Port (XML flat file format)
tRFC Port
Mail Attachment
3rd-party products (e.g. Message Handler, EDI Subsystem, ALE Converter)
SAP Business Connector (see next Chapter)
Customer Development

Conversions Global network of innovaion for Messages between ERP Systems
Different kinds of conversions are possible Which one to use depends on the relationship between the partners
Without Conversion ALE Converter EDI Subsystem
SAP System R/3
SAP System R/3

IDoc
SAP System R/3

IDoc
EDI Subsystem
IDoc
ALE Converter
?
EDI
Converter
?
SAP System R/3
ERP System
ERP System

IDoc Concept
System 1
Document
System 2 IDoc
Document
Message-oriented Asynchronous

IDoc Applications
Business Connector Internet Intranet ALE IDoc R/3 System EDI Subsystem
R/2 System
Workflow
Electronic Form
Other Systems...

IDoc Record Types
Control record
Data records
Status records

Control record
Control record
IDoc ID Partner IDoc type and logical message External structure

Data Records and Segment Structures
Data record
Control part, contains segment names Application data
Field 1 Field 2 ...
Segment

Global network of innovaion Status Record
Status Record
IDoc ID Status information

IDoc Record Types: Summary
Control record
IDoc ID Partner IDoc type and logical message External structure
Data records
Control part Application data
Status records
IDoc ID Status information

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.

IDoc Types
Control Record Data records, represented as a segment tree E1HDDOC

M 1
E1TLSUM
C 1
E1HDADR
C 5
E1ITDOC
Elternsegment M 1
E1ITSCH E1ITSCH
C 99
Kindsegment
Status Records

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

Basic Principles: Summary
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

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.

Global network of innovaion Relationship between Message Type and IDoc Type
1. Order Message type: ORDERS IDoc type : ORDERS01 (3.0A) ORDERS02 (3.0D) ORDERS03 (4.0A) ORDERS04 (4.5A) 2. Order confirmation Message type: ORDRSP IDoc type : ORDERS0x 3. Delivery Message type: DESADV IDoc type : DESADV01 (3.0A) DELVRY01 (4.0A) DELVRY02 (4.5A) 4. Billing document Message type: INVOIC IDoc type : INVOIC01 (3.0A) INVOIC02 (4.0A)
Customer
Sales

Internal and External Structures
Segment
E1...
Field 1
Field 2 Re lea se 3.0
Field 3
Field 4
internal external
E2...001
Field 1
Field 2
SAP AG 1999

Development Environment for IDoc Types
Data Structures:

IDoc Record Types IDoc Types IDoc Segments
Development and Extension

Global network Components of innovaion
of the IDoc Process
Application
Function module Program Report IDoc Type Business Workflow Function module
Inbound Processing
Segment
Outbound Processing
Segment type Segment name
IDoc Interface
Data structure

Global network IDoc Terms: of innovaion
Basic Type and Extensions
Basic type = IDoc type Basic type Extension IDoc type
+ =

Global network application document. of innovaion
The IDoc type is a hierarchy consisting of segments and complex data structures which can receive an
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 type CIMTYP 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

Global network IDoc Terms: of innovaion
Segment
Segment name E2ccccc000 Segment type E1ccccc Segment name E2ccccc001
Version 1 e.g. 3.0A
Version 2 e.g. 3.0C
Segment name /partner/ccccc000 Segment name E2ccccc013 Segment type /partner/ ccccc Segment name /partner/ccccc001
Version 14 e.g.7.7x
Segment name /partner/ccccc013

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.

IDoc Functions: Release and Version Creation
By releasing segments and IDoc types, the external interface is "frozen" and given unique names for these objects for an external partner system. There can only be one segment version for each SAP Release (for example 4.0B). The IDoc definition tools control the release.After each release, further development leads to new versions. Changes must be made in accordance with strict rules so that the interface remains compatible.
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 Global network version. of innovaion 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.

GlobalBasic network of innovaion
Rules for Customer Extension
Additional customer fields are recorded in their own customer segments. Customer segments depend on SAP segments (successor or child relationships). The processing of customer segments is exclusively implemented in the customer exits of the coding provided in the standard system.

Global network Areas of innovaion
of Customer Extension
Application
Function Module Program Report IDoc Type Business Workflow Function Module
Data structure in the WEDI area menu Outbound and inbound processing: Typically through transaction "CMOD", otherwise through individual technique Documentation: In the WEDI area menu
Segment
Segment Type
Segment Name
IDoc Interface

Steps Global network of innovaion For Extending the Data Structure
Combine the required fields and their data types in the dictionary. Definition of required segments, segment editor. Definition of extension, IDoc type editor. Assignment of a logical message to the IDoc type, surrounding field menu of IDoc type editor.

GlobalSteps network of innovaion
for Extending Processing
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 database and data in "IDoc format" Inbound processing: writing data from the "IDoc format" into the SAP database
Activate project in project management

Port Definition
Port types and when they are used Port definition parameters Communication with Older Releases

Global network Overview of innovaion
Diagram (Sending Data)

R/3 System Post document
Generate IDoc
Port Definition
External System
EDI EDI Subsystem Subsystem ? ?

IDoc Interface: Global network of innovaion Port Types
IDoc Interface
IDoc/ status IDoc/ status
IDoc
IDoc
IDoc
IDoc
File
XML
tRFC
Internet
CPI-C
PI
External System
R/2 System

Global network different transmission methods. These are the port types: of innovaion
Ports are the channels via which the IDocs are exchanged. The IDoc Interface supports six
"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.

Port Definition: Port Type "File"
RFC destination (TCP/IP connection)
rfcexec out.script
Command file Outbound file Inbound file Status file

IDoc file Status report

Global network Process of innovaion
Flow: Port Type File (with Triggering)
IDoc Interface
Write RFC
4
Read
IDoc file Status report
3
RFC
startrfc in.script status.script
1
IDoc file
2
rfcexec out.script
Read
Call
1
Write
2
Call
3 External System

Global network of 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 startrfccommand 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.

Port Type Global network of innovaion 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.

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.

Global network Port Definition of innovaion
- Port Type tRFC
RFC destination (R/3 connection)

Application server for receiving system
Port name (assigned automatically)

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

Process Global network of innovaion Flow: Port Type tRFC
IDoc Interface
RFC Interface
TCP/IP
RFC Interface
External System

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 nonR/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.

Communication with Older Releases
Differences in IDoc record types
Field 1
Field 3
Field 2
4.X
Field 1
Field 2
New field 3
3.0/3.1
Field 1
Field 2
2.1/2.2

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

Global network Overview of innovaion
Diagram (Sending Data)
R/3 System
Post document
Generate IDoc
Partner Profiles
EDI EDI Subsystem? Subsystem?

Partner Global network of innovaion Profiles: Fields
Partner Permitted agents General Partner Message Port IDoc type EDI structure Permitted agents Outbound Processing Process code Logical message Partner Message Process code Permitted agents Inbound Processing MC parameters
Partner Application

The IDoc partner profile is divided into four areas:
Global network of innovaion 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.

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

GlobalPartner network of innovaion
Profiles: Outbound Processing I
SAP Application
Document
MC settings MCMC settings

MC record
Document
General+outbound General+outbound IDoc Interface / ALE Services

IDoc
Receiving System

Global network of innovaion Partner
Profiles: Outbound Processing II
Partner: QD ; Appl : EF; OtptType : NEW
Object type, language,...
MC record
Partner: QD ; Appl : EF; OtptType : NEW
Process code: ME10 Message: ORDERS MC settings
Partner: QD; Port: SUBSYSTEM IDoc type: ORDERS01
Output type: ORDERS

Permitted agent: EDI agent for partner QuickDeliver (QD) (purchase orders)
General Outbound

Test Tool Options

Global network of 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.

Tool GlobalTest network of innovaion Options (2)
Function Module
(in Dir bo ec un t d cal on l ly)
Mass test
Standard processing
Ge ne rat e fil e

Test Layers: Global network of innovaion Overview
Application MC
WE15
Workflow
WE19 , WE18
IDoc Interface
WE14, WE19 WE16 WE17
External System
Outbound IDoc file
WE12
Inbound IDoc file
Status confirm.
File System
WE18

IDOC TEST TOOLS

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.

GlobalTest network Layers: of innovaion
Outbound Processing
Application MC MC
WE15
IDoc Interface
WE14, WE19
External System

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.


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.

Global network of innovaion Test Layers:
Status Confirmation
Application Workflow
WE19 , WE18
IDoc Interface
WE16 WE17
Outbound file with SYSTAT01
WE12
Inbound file with SYSTAT01
Status confirm.
File System
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.

Global network to When of innovaion
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

Ale Idoc Edi Training

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ale Idoc Edi Training

Caricato da

Copyright:

Formati disponibili

Siemens Information Systems Ltd.

Global network of innovaion

Main Business Scenario

SAP R/3 System

SAP R/3 System

Siemens Information Systems Ltd.

Siemens Information Systems Ltd.

Reasons for Distributed Applications I

Siemens Information Systems Ltd.

Distributed applications arise due to:

Siemens Information Systems Ltd.

Reasons for Distributed Applications III

Siemens Information Systems Ltd.

Siemens Information Systems Ltd.

EDI and ALE

SAP R/3 System

SAP R/3 System

Siemens Information Systems Ltd.

Component of EDI system

Siemens Information Systems Ltd.

EDI data transmission

Structure of EDI message packet

Siemens Information Systems Ltd.

Data in electronic form

Siemens Information Systems Ltd.

SAP EDI Boundaries

Siemens Information Systems Ltd.

IDoc Interface/ALE Services

Siemens Information Systems Ltd.

EDI enabled application for outbound process

Siemens Information Systems Ltd.

Process Flow: Sending Data

Check partner, find port

Transfer data, process further External system

Siemens Information Systems Ltd.

IDoc Settings: Sending Data

Archive Archive IDoc IDoc ? ?

Partner Partner Profiles Profiles

Check partner, find port

Port Port Definition Definition

External System EDI EDI Subsystem Subsystem ? ?

Documentation Documentation Tools Tools

Siemens Information Systems Ltd.

Siemens Information Systems Ltd.

Process flow and data flow in an outbound EDI process

Siemens Information Systems Ltd.

Details of outbound process with message control

Siemens Information Systems Ltd.

Outbound process with message control

Siemens Information Systems Ltd.

Siemens Information Systems Ltd.

Archive Archive IDoc? IDoc?

Partner Partner Profiles Profiles

Port Port Definition Definition

EDI EDI Subsystem? Subsystem?

External System Data flow

Documentation Documentation Tools Tools

Siemens Information Systems Ltd.

Message Control and IDocs

Message determination and message processing Condition components Dispatch times

Siemens Information Systems Ltd.

Message Control (MC)

IDoc Interface / ALE Services