ale idoc edi training ppt
DESCRIPTION
pptTRANSCRIPT
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
Siemens Information Systems Ltd.
Global networkof innovaion
Regional installation Country-wide installation local system business objects
Distributed Business Processes
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
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Document Exchange
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
Siemens Information Systems Ltd.
Global networkof innovaion
Component of EDI system
Siemens Information Systems Ltd.
Global networkof innovaion
Structure of EDI message packet
EDI data transmission
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
Siemens Information Systems Ltd.
Global networkof innovaion
SAP EDI Boundaries
Siemens Information Systems Ltd.
Global networkof innovaionOutbound and Inbound Processing
Outbound Processing Inbound
IDoc Interface/ALE Services
External System
SAP Application
R/3 System
Siemens Information Systems Ltd.
Global networkof innovaion
EDI enabled application for outbound process
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
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Process flow and data flow in an outbound EDI process
Siemens Information Systems Ltd.
Global networkof innovaion
Details of outbound process with message control
Siemens Information Systems Ltd.
Global networkof innovaion
Outbound process with message control
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Message Control and IDocs
Message determination and message processing
Condition components
Dispatch times
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Outbound Processing using MessageControl
MCMCrecordrecord
DocumentDocument
SAP Application
MC
IDoc Interface/ALE Services
Find proposal
Edit
Process
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
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
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Details of outbound process without Message control
Siemens Information Systems Ltd.
Global networkof innovaion
Technical flow: Outbound process without message control
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Process flow and data flow in an inbound EDI process
Siemens Information Systems Ltd.
Global networkof innovaion
The inbound process using a direct function module
Siemens Information Systems Ltd.
Global networkof innovaion
IDocIDoc
Direct Inbound Processing using ALE
IDocIDoc
SAP Application
External System
IDoc Interface & ALE Services
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
Siemens Information Systems Ltd.
Global networkof innovaion
Technical flow of inbound process using direct function module
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Technical details of inbound process via workflow
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.
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Triggering the inbound SAP EDI process from subsystem
Siemens Information Systems Ltd.
Global networkof innovaion
Output in Various Formats
Begin
…
End
typedef struct z2incodx000
… z2incodx0 00
?
? ? ?
XML
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)
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
Siemens Information Systems Ltd.
Global networkof innovaion
IDoc Concept
Message-oriented
Asynchronous
System 1
Document
System 2
IDoc Document
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
Siemens Information Systems Ltd.
Global networkof innovaion
IDoc Record Types
Status records
Data records
Control record
Siemens Information Systems Ltd.
Global networkof innovaion
Control record
Control record IDoc IDPartnerIDoc type and logical messageExternal structure
Siemens Information Systems Ltd.
Global networkof innovaion
Data Records and Segment Structures
Data record
Control part, containssegment names
Application data
Field 2Field 1 ...
Segment
Siemens Information Systems Ltd.
Global networkof innovaionStatus Record
Status Record IDoc IDStatus information
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
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.
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
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
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
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.
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Data Structures:
IDoc Record Types
IDoc Types
IDoc Segments
Development and Extension
Development Environment for IDoc Types
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
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
==
++
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
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
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.
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
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.
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
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
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
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
Siemens Information Systems Ltd.
Global networkof innovaionPort Definition
Port types and when they are used
Port definition parameters
Communication with Older Releases
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
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
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.
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)
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
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.
Siemens Information Systems Ltd.
Global networkof innovaion
Port Type XML: Flat File and XML File
EDI_DC40 004000000000030702346B 3013 ORDERS01...
E2EDP0100500400000000003070230000210000000200E2EDP2000400000000003070230000220000210323...
E2EDPT1001004000000000030702300002600002103BESTDE2EDPT2001 004000000000030702300002700002604Thisis
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.
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>
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.
Siemens Information Systems Ltd.
Global networkof innovaionPort Definition - Port Type tRFC
RFC destination(R/3 connection)
Port name (assigned automatically)
Application server forreceiving system
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".
Siemens Information Systems Ltd.
Global networkof innovaion
Process Flow: Port Type tRFC
IDoc Interface
External System
RFC Interface
RFC Interface
TCP/IP
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.
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
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).
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
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
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.
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.
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Test Tool Options
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.
Siemens Information Systems Ltd.
Global networkof innovaion
Test Tool Options (2)
Function Module
Directcall
(inboundonly)
Generatefile
Standard processingMass test
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
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
Siemens Information Systems Ltd.
Global networkof innovaion
Test Layers: Outbound Processing
Application
MC
WE15
WE14, WE19
ExternalSystem
IDoc Interface
MC
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.
Siemens Information Systems Ltd.
Global networkof innovaion
Test Layers: Inbound Processing
InboundIDoc file
Application
IDoc Interface
Workflow
OutboundIDoc file
WE12
WE16
WE19
File System
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.
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
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.
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