BC621
Business Integration Technologies II...3 Course Prerequisites...4 Target Group...5 Introduction: Contents...1 Course Goals...2 Course Objectives...3 Course Content...4
BC621 Course Overview Diagram...5
Main Business Scenario...6
Development Environment for IDoc Types...1
Course Objectives...2
Course Overview Diagram...3
Components of the IDoc Process...4
IDoc Record Types...5
IDoc Terms: Basic Type and Extensions...6
IDoc Terms: Segment...7
IDoc Functions: Release and Version Creation...8
ABAP Programming Names...9
Subsystem Names...10
IDoc Definition Tools...11
When is Which Action Necessary?...12
Summary...13
Extension of an IDoc Type...1
Course Objectives...2
Course Overview Diagram...3
Advantages of Customer Enhancement...4
Basic Rules for Customer Extension...5
Areas of Customer Extension...6
Steps For Extending the Data Structure...7
Steps for Extending Processing...8
Output Documentation of the Extension...9
Summary...10
Erweiterung eines IDoc-Typs: Exercise...11
Extension of an IDoc Type: Solutions...19
Development of IDoc Type...1
Development Steps for Outbound Processing using the ALE Interface...9
Development Steps of Inbound Processing using Business Workflow...10
Development Steps for Inbound Processing using ALE Interface...11
Output Documentation of New Development...12
Summary...13
SAP AG 1999
BC621 - SAP IDoc Interface (Development)
BC621
BC621
SAP IDoc Interface
(Development)
SAP IDoc Interface
(Development)
R/3
Release 4.6A January 2000 5003 5260
SAP AG 2003
Copyright 2003 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in
any form or for any purpose withoutthe express permission of
SAP AG. The information contained herein may be changed
without prior notice.
All rights reserved.
Copyright
Trademarks:
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered
trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®,
AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide
SAP AG 2001
Business Integration Technologies II
Business Integration Technology BC095 3 days
Level 2
Level 3
Data Transfer BC420 5 days Programming with BAPIs in Visual Basic*CA925 5 days Interface
Programming Data exchange Communication Interfaces in ABAP BC415 2 days Programming with BAPIs in JAVA *CA926 5 days SAP IDoc Interface -Development
BC621 1 day SAP IDoc Interface
Technology BC620 2 days Application Link Enabling (ALE) Technology BC619 3 days EDI Interface CA210 4 days *BC620 from 01/2002 BIT320 *BC619 from 01/2002 BIT300 *BC621 from 04/2002 BIT350
*CA925 from 01/2002 BIT525 *CA926 from 01/2002 BIT526
SAP AG 1999
Course Prerequisites
Recommended: Basis BC 400 - ABAP
Workbench Basics
SAP AG 1999
Target Group
ABAP Developers
Consultants
Notes to the user
The training materials are not teach-yourself programs. They complement the course instructor's
SAP AG 1999
Course Goals
Course Objective(s)
Course Content
Course Overview Diagram
Main Business Scenario
SAP AG 1999
At the conclusion of this course, you will be
able to:
Extend IDoc types
Define new IDoc types
SAP AG 1999
At the conclusion of this course, you will be able
to:
Build and extend the data structure of IDoc types
Use the IDoc type editor and segment editor
Use customer exits to process IDoc types
SAP AG 1999
Unit 1
Introduction
Unit 2
Development Environment for IDoc Types
Unit 3 Extension of IDoc Types
Unit 4 Development of IDoc Types
Preface
Appendix
SAP AG 1999 Introduction
1
1
Development Environment for IDoc Types Extension of IDoc Types Development of IDoc TypesSAP AG 1999
Enterprise trading company A wants Vendor
B to ship their material orders via EDI.
Herrmann & Riemer will die entsprechenden
Bestellungen gleich elektronisch verbuchen.
Als Grundlage wollen die Unternehmen den
IDoc-Typ ORDLGT01 verwenden, der aber
eventuell noch den Bedürfnissen
entsprechend erweitert werden muß. Als
Projektteammitglied informieren Sie sichalso
über die Entwicklungsmöglichkeiten, die die
IDoc-Schnittstelle bietet.
Message IDoc IDoc Vendor B Enterprise trading company ASAP R/3 System
SAP R/3 System
EDI Subsystem
EDI Subsystem
EDI Subsystem
EDI Subsystem
SAP R/3 System
SAP R/3 System
Main Business Scenario
Enterprise trading company A wants vendor B to ship their material orders via EDI. Vendor B would
like to electronically update the placed orders immediately. As a basis for this transaction, A & B intend to use IDoc type ORDLGT01. However, IDoc type ORDLGT01 needs to be extended to meet their needs. Your task as a member of the project team is to research the possibilities of the
SAP AG 1999
Data Structures:
IDoc Record Types IDoc Types
IDoc Segments
Development and Extension
SAP AG 1999
Understand the development environment for IDoc
types
Describe the functionality of the development
environment for IDoc types
Explain the difference between development and
extensions
SAP AG 1999 Introduction
2
2
Development Environment for IDoc TypesExtension of IDoc Types
Development of IDoc Types
SAP AG 1999 Function module Program Report Business Workflow Function module IDoc Interface Application Segment type Segment IDoc Type Segment name
Ou
tb
ou
nd
P
ro
ce
ss
ing
Inb
ou
nd
P
ro
ce
ss
ing
Da
ta
str
uc
tur
e
Components of the IDoc Process
The IDoc Interface consists of a data structure (the IDoc type) and process programs for this data
structure.
The Subsystem Interface is built through the data structure.
The process programs are inserted between SAP application and interface.
In outbound processing you should be able to read the master and movement data as well as be able to format it into an IDoc format.
SAP AG 1999
Control Record
Data Records
IDoc ID Partner
IDoc Type and Logical Message External Structure
Control Part Application Data
Status Records IDoc ID
Status Information
IDoc Record Types
Every IDoc in the SAP database consists of:
One control record,
Data records, containing the application data in the segments describing the hierarchy. These segments are in a hierarchy sequence,
Status records, which monitor specific IDoc steps. The further the IDoc is in its process the more status records it has.
An IDoc that has been exchanged with an external system, will only contain
The control record and The data records.
If the external system communicates the status of the sending IDoc with the R/3 System, this can be
carried out with a status confirmation. The R/3 System connects the received status records to the corresponding outbound IDoc in the database. The R/3 System can also transmit status confirmations about IDocs received. This, however, can only happen through the specific IDoc type SYSTAT01, that is, the control and data records are exchanged here. In this case, the status information is therefore contained in the IDoc data records.
SAP AG 1999
IDoc Terms: Basic Type and Extensions
Basic type
Basic type
IDoc type
IDoc type
=
=
Basic type
Basic type
IDoc type
IDoc type
Extension
Extension
=
=
+
+
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 type CIMTYPName 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
SAP AG 1999
IDoc Terms: Segment
Segment type /partner/ccccc Segment type /partner/ccccc Segment name /partner/ccccc000 Segment name /partner/ccccc000 Segment name /partner/ccccc001 Segment type E1ccccc Segment type E1ccccc Segment name E2ccccc000 Segment name E2ccccc000 Segment name E2ccccc001 Segment name E2ccccc001 Segment name E2ccccc013 Segment name E2ccccc013 Version 1 e.g. 3.0A Version 2 e.g. 3.0C 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,
SAP AG 1999
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.
IDoc Functions: Release and Version Creation
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
SAP AG 1999
ABAP Programming Names
Control record, EDIDC
Status record, EDIDS & EDI_DS
Data records, EDIDD, displayed as a segment tree
E1TLSUM E1HDADR E1ITSCH E1HDDOC E1ITDOC Parent segment Child segment E1ITSCH C 5 E1ITDOC M 1 C 99 M 1 C 5 C 1 "IDoc Type"
ABAP programming exclusively uses the segment types of the segments, for example in the
TABLES statement.
SAP AG 1999
Subsystem Names
Control record, EDI_DC40
Status record, EDI_DS40
Data records, displayed as a segment tree
E2TLSUM000 E2HDADR000 E1ITSCH E2HDDOC000 E1ITDOC Parent segment Child segment E2ITSCH000 C 5 E2ITDOC000 M 1 C 99 M 1 C 5 C 1 "IDoc Type"
The segment names of the segments are exclusively visible by the subsystem. Segment names implemented in the SAP standard system start with prefix "E2".
SAP AG 1999
IDoc Definition Tools
IDoc Type Editor
WE30
E1HDDOC Segment editor
WE31
Design and definition of IDoc types and their segments are supported by the IDoc definition tools
through the following:
Testing of the formal design rules
Simple usage in application of an ABAP development workbench
The IDoc type editor allows:
Definition of basic types (possible through SAP, partners and customers) Definition of extensions (only possible through customers)
SAP AG 1999
When is Which Action Necessary?
The IDoc type required is available and meets all
requirements:
No action needed!
The IDoc type required is present but does not meet all
requirements:
Action: Customer extension!
The IDoc type required is not available or it is present but
does not meet all the requirements:
Action: Development!
The customer extension, that is, the development of an extension does not represent a modification.
Since all actions are captured in their own namespace, the extension can automatically be expanded to new versions of the extended IDoc type.
The customer development is totally independent of the standard. The necessary processes can easily
SAP AG 1999
An IDoc type is a complex data structure composed
of segments.
Segment types are structures in the ABAP data
repository.
IDoc types and their processing can be extended in
the appropriate positions by customers.
SAP AG 1999
Extension of the data structure
Extension of Outbound Processing
Extension of Inbound Processing
Extension of an IDoc Type
We will take a look at the outgoing orders process (Enterprise A is placing an electronic order with
Vendor B) as well as the incoming customer order process (order being electronically processed by the customer service department of Vendor B).
The course uses a sample IDoc type (ORDLGT01) for purchase orders and sales orders. This IDoc
type only consists of a segment for the document header and the item. The course does not correct any errors in order to emphasize all important aspects of the IDoc type extensions.
The IDoc type ORDLGT01 with logical message ORDLGT does not support transmission of
specialist's name or delivery conditions. In this lesson, this information will be added to the IDoc type.
SAP AG 1999
Create IDoc Segment
Extend an IDoc Type
Implement a customer exit in outbound processing
Implement a customer exit in inbound processing
SAP AG 1999
Course Overview Diagram
Implementation
3
3
Development environment for IDoc types Extension of an IDoc type Development of IDoc typeSAP AG 1999
The coding provided in the standard system for
processing is used.
Developments and corrections of the coding
delivered in the standard system are therefore
automatically available.
Extension is less time consuming than new
development.
SAP AG 1999
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.
SAP AG 1999 Function Module Program Report Business Workflow Function Module IDoc Interface Application Segment Type Segment IDoc Type Segment Name
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
SAP AG 1999
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.
Steps For Extending the Data Structure
In the segment editor you assign a name to each field and enter a data element that describes the field
in the application (documentation). The editor calculates the necessary character length of the field in the segment from the data element.
Segment editor, transaction WE31.
In the IDoc type editor you build a complex data structure from the single segments. There you
determine the order and the hierarchical relationship of the segments. In addition, you assign a status (optional/mandatory) as well as the number of repetitions per segment and segment group.
The IDoc API tests that the generated program (outbound processing: SAP processing, inbound processing: subsystem) conforms to these characteristics. Violations of these characteristics are recorded through the IDoc status syntax error (outbound: “26”, inbound processing: “60”).
SAP AG 1999
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
Steps for Extending Processing
Project management, transaction CMOD, radio button Attribute.
Enter a project name and select Create. Enter short text and select Save. Choose SAP Extensions.
Project management, transaction CMOD, radio button SAP Extensions.
Find customer exit through the development class (F4 Help). Select the required SAP extensions and choose Copy.
Select Save and return to the initial screen of the transaction (F3).
Project management, transaction CMOD, radio button Extension components.
Select Change.
Position the cursor on a component and choose Edit component.
Double-click the include in the program editor and follow the instructions in the window. Before saving the program, don't forget syntax testing.
SAP AG 1999
Output Documentation of the Extension
Begin … End
typedefine struct edi_dc {…}
edi_dc
XML
The documentation tools are started from the initial node of the IDoc Interface by selecting
Documentation. In addition, the parser output format has its own menu point for record types as well as IDoc types.
Automatic formats are:
Simple, readable with a parser begin..end-Declaration sequence. C-header.
Meta IDoc from type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types). Meta data for IDocs in XML format.
Navigation-compatible formats are:
The tree display in the R/3 System.
HTML file (three files, the *_ f-file is the frame that should be loaded by the browser and the index *_i and actual documentation *_d).
Documentation, IDoc record types: Transaction WE61 Documentation, IDoc types: Transaction WE60 Documentation, IDoc type (parser): Transaction WE63
SAP AG 1999
An extension can be limited to processing.
Normally an extension encompasses the data
structure as well as the processing.
Extended data structures can be communicated to
the subsystem by the documentation tools.
Data Used in the Exercises
Training System: The instructor will inform you (for example I40)
Client: The instructor will inform you (for example 400)
User: BC621-nn
Password: KURS
Port: SUBSYSTEM of Type ”Data” (pre programmed)
Data
Data in Training System
Data in IDES System
Customer:
Material
SH-100
SH-100
Vendor
T-BILnn
1014
Purchasing Organization
1000
1000
Purchasing Group
001
001
Plant
1100
1100
Vendor:
Material
SH-100
SH-100
Sold-to party
T-BIKnn
1110
Order Type
TA
Sales Organization
1020
1020
Distribution Channel
22
22
Division
00
00
•
Make preparations for the extension
In the scenario send a purchase order to vendor T-BILnn. In the second
step make the purchase order the sales order from customer T-BIKnn.
In order to keep the exercises manageable, the IDoc type ORDLGT01 has been
introduced with message ORDLGT. This is a simplification of SAP standard
ORDERS01 and is only used for this course.
1-1
Prepare via Logistics -> Materials management -> Purchasing -> Purchase order
-> Create -> Vendor known (transaction ME21) a purchase order with your vendor
T-BILnn for methanol, material number SH-100. You belong to purchasing
organization 1000 and the purchasing group is 001. The methanol is being
purchased for plant 1100.
A partner profile for your partner already exists. It ensures that the IDoc is written
in a file and thus receives the status 03.
1-2
You simulate the incoming orders via the inbound modified outbound file test
program from the purchase order. You can offer default values for source,
destination and port by choosing Goto
→
User settings and selecting the port
SUBSYSTEM for the test.
Enter the following values on the tab page Sender:
Recipient, Port:
SAP<SID>, System ID of SAP
system, for example SAPT80
Topic: Extension of Inbound Processing
•
Get to know project management
•
Be able to write program code for inbound processing.
2-1
Extend the inbound processing of IDoc type ORDLGT01 to avoid errors status
“51”. Change the received error document type NB in one of the customer exits to
document type TA expected by the sales order. There is no need to extend the IDoc
type.
2-2
Create the Project BC621-nn in the project administration (transaction CMOD).
Select the SAP extension BC621Enn for the project. Write the extension code in
the inbound component.
2-3
Now activate your project.
2-4
Repeat the inbound sales order process with the help of the test program Inbound
modified outbound file derived from the already created purchase order.
Enter the following values on the tab page Sender:
Recipient, Port:
SAP<SID>, System ID of SAP
system, for example SAPT80
Sender, Port:
SUBSYSTEM
Sender, Partner Number:
T-BIKnn
Sender, Partner Type:
KU
Sender, Partner Function:
AG
Topic: Extension of Outbound Processing
•
Get to know project management
•
Be able to write the program code for outbound processing
In exercise 1 the field for Specialist name remained blank, even though it
was defined in the IDoc type. Since it has been agreed with your partner
to transfer the field, you decide to take care of the field through a
customer exit. There is no need to extend the IDoc type.
3-1
Change the Project BC621-nn in the project management (transaction CMOD) or
create it for the first time (if you have not completed exercise 2). Select the SAP
extension BC621Enn for the project. Write the program code in the extension
component for the outbound processing.
3-2
Activate your project.
3-3
Now repeat the purchase order through Logistics -> Materials management ->
Purchasing -> Purchase order -> Create -> Vendor known (transaction ME21) to
your vendor T-BILnn for methanol, material number SH-100.
3-4
Change to Purchase order
→
Display. You can display the IDoc that was just
generated from the overview screen by choosing System
→
Links. Check that the
field has now been filled with the user name.
Note: The number of filled fields is displayed in the bottom right area of the detail
display of a data record. It has increased to 8.
Topic: Extension of the Data Structure (IDoc Type)
•
Know how to use IDoc type editor
Your IDoc type ORDLGT01 does not contain any fields in order to
transfer the document header delivery conditions. You have to extend the
data structure, that is, the IDoc type, since delivery conditions have been
agreed to with your partner.
4-1
First define the customer segment Z1INCOnn in the segment editor. Customer
segment Z1INCOnn is to contain application fields INCO1 and INCO2. In the
application both fields INCO1 and INCO2 are contained in the structure EKKO.
4-2
In the segment editor, test that your definition is correct. Ignore the warning that the
segment has not yet been released.
4-3
Define the extension ZEXTENnn in the IDoc type editor. Extend the basic IDoc
type ORDLGT01 by segment Z1INCOnn.
4-4
Add to the logical message ORDLGT the basic type ORDLGT01 with the
extension ZEXTENnn in the IDoc type editor.
4-5
In the IDoc type editor, test that your definition is correct. Ignore the warning that
the IDoc type as well as the segment Z1INCOnn has not yet been released.
Topic: Extension of Outbound Processing
•
Revise project management
•
Revise programming of outbound processing
After you have completed exercise 4, extending the customer segment
Z1INCOnn of the IDoc type, in order to transfer the delivery conditions,
you now have to enter the delivery conditions in the customer segment in
a customer exit.
5-1
Change the Project BC621-nn in the project management (transaction CMOD) or
create it for the first time. Select the SAP extension BC621Enn for the project.
Write the program code in the extension component for the outbound processing.
5-2
Activate your project.
5-3
In partner agreement for vendor T-BILnn, in the outbound parameter table change
the IDoc type from basic IDoc type ORDLGT01 to extension ZEXTENnn.
5-4
Now repeat the purchase order through Logistics -> Materials management ->
Purchasing -> Purchase order -> Create -> Vendor known (transaction ME21) to
your vendor T-BILnn for methanol, material number SH-100.
5-5
Change to Purchase order
→
Display. You can display the IDoc that was just
generated from the overview screen by choosing System
→
Links. Check if
customer segment Z1INCOnn was created and filled. The IDoc has status 03, that is
a file was generated.
Topic: Extension of Inbound Processing
•
Revise project management
•
Revise programming of input process
In exercise 4, after you extended IDoc type with customer segment
Z1INCOnn. In order to receive the delivery conditions, you need to read
the customer segment with delivery conditions in the customer exit and
this needs to be transmitted to the input process (BDC).
Exercise 5 is a prerequisite for this exercise.
6-1
Change the Project BC621-nn in the project management (transaction CMOD).
Write the program code in the extension component for the outbound processing.
6-2
Activate your project.
6-3
Repeat the inbound sales order process with the help of the test program Inbound
modified outbound file derived from the already created purchase order.
Enter the following values on the tab page Sender:
Recipient, Port:
SAP<SID>, System ID of SAP
system, for example SAPT80
Sender, Port:
SUBSYSTEM
Sender, Partner Number:
T-BIKnn
Sender, Partner Type:
KU
Unit: Extension of an IDoc Type
Topic: Extension of Inbound Processing
2-1 Program code for outbound processing extension:
1 *---*
2 * INCLUDE ZXDIXU02
3 *---*
4
5 data: h_e1head like e1head.
" Exercise 2
6
7 pe_vbak621 = pi_vbak621.
8
9 * Exercise 2
10 loop at pt_idoc_data_records
11
where segnam = 'E1HEAD'.
12
h_e1head = pt_idoc_data_records-sdata.
13
if h_e1head-auart = 'NB'.
14
pe_vbak621-auart = 'TA'.
15
endif.
Topic: Extension of Outbound Processing
3-1 Program code for outbound processing extension:
1 *---*
2 * INCLUDE ZXDIXU01
3 *---*
4
5 data: k_e1head like e1head.
" Exercise 3
6
7 loop at pt_idoc_data_records
8
where segnam = 'E1HEAD'.
9 * Exercise 3
10
k_e1head = pt_idoc_data_records-sdata.
11
k_e1head-name = pi_ekko-ernam.
12
pt_idoc_data_records-sdata = k_e1head.
13
modify pt_idoc_data_records.
14 endloop.
Topic: Extension of the Data Structure (IDoc Type)
4-1
Segment Z1INCOnn contains two fields:
INCO1 with data element INCO1 in export length 3
INCO2 with data element INCO2 in export length 28
4-2
The extension ZEXTENnn consists of standard segments E1HEAD and E1ITEM.
The customer segment Z1INCOnn, as child segment depends on standard segment
E1HEAD.
Topic: Extension of Outbound Processing
5-1
Program code for outbound processing extension (extended INCLUDE from
exercise 3):
1 *---*
2 * INCLUDE ZXDIXU01
3 *---*
4
5 data: k_e1head like e1head.
" Exercise 3
6 data: k_z1inco like z1incodx.
" Exercise 5
7
8 loop at pt_idoc_data_records
9
where segnam = 'E1HEAD'.
10 * Exercise 3
11
k_e1head = pt_idoc_data_records-sdata.
12
k_e1head-name = pi_ekko-ernam.
13
pt_idoc_data_records-sdata = k_e1head.
14
modify pt_idoc_data_records.
15 * Exercise 5
16
clear pt_idoc_data_records.
17
clear k_z1inco.
18
k_z1inco-inco1 = pi_ekko-inco1.
19
k_z1inco-inco2 = pi_ekko-inco2.
20
pt_idoc_data_records-segnam = 'Z1INCODX'.
21
pt_idoc_data_records-sdata = k_z1inco.
22
append pt_idoc_data_records.
23 endloop.
Topic: Extension of Inbound Processing
6-1
Program code for inbound processing extension (extended INCLUDE from exercise
2):
1 *---*
2 * INCLUDE ZXDIXU02
3 *---*
4
5 data: h_e1head like e1head.
" Exercise 2
6 data: h_z1inco like z1incodx.
" Exercise 6
7
8 pe_vbak621 = pi_vbak621.
9
10 * Exercise 2
11 loop at pt_idoc_data_records
12
where segnam = 'E1HEAD'.
13
h_e1head = pt_idoc_data_records-sdata.
14
if h_e1head-auart = 'NB'.
15
pe_vbak621-auart = 'TA'.
16
endif.
17 endloop.
18
19 * Exercise 6
20 loop at pt_idoc_data_records
21
where segnam = 'Z1INCODX'.
22
h_z1inco = pt_idoc_data_records-sdata.
23
pe_vbak621-inco1 = h_z1inco-inco1.
24 * pe_vbak621-inco2 = h_z1inco-inco2.
25
pe_vbak621-inco2 = ‘Test BC621-DX’.
26 endloop.
SAP AG 1999
Development of the data structure
Processing example
SAP AG 1999
Create IDoc segments
Develop new IDoc types
Template for IDoc outbound processing
Template for IDoc inbound processing
SAP AG 1999 Implementation
4
4
Development environment for IDoc types Extension of an IDoc type Development of IDoc typeSAP AG 1999
Segments are formed as logical units based on the
(application) fields. They are reusable "modules" of
IDoc development.
Segment groups are formed as logical units from
segments.
IDoc types are derived from segments and segment
groups.
They are the data structure of an application document
for the transmission.
During development IDoc types are created as basic
IDoc types.
The business process itself is not identified through
an IDoc type, but rather through the logical message.
Basic Rules for Development
In the segment editor you assign a name to the field and enter a data element that describes the field
in the application (documentation). The editor calculates the necessary character length for the field using the data element. Examples:
Logical unit segment:
• An address consists of the fields street, postal code and city.
• Contact person consists of the field's first name, last name and telephone number. Logical unit of segment group:
• A company address consists of an address (logical unit segment) as well as several contact persons (logical unit segment) in this company.
You build a complex data structure from the single segments in the IDoc type editor. There you
determine the order and the hierarchical relationship of the segments. In addition, you assign a status (optional/mandatory) as well as the number of repetitions per segment and segment group.
The IDoc API tests that the generated program (outbound processing: SAP processing, inbound processing: subsystem) conforms to these characteristics. Violations of these characteristics are recorded through the IDoc status syntax error (outbound: 26, inbound 60).
SAP AG 1999 Application Function Module Program Report Business Workflow Function Module IDoc Interface Segment Type Segment IDoc Type Segment Name
Data structure:
in the WEDI area menu
Outbound and inbound
processing: in the Object
Browser "SE80"
Documentation:
in the WEDI menu
SAP AG 1999
Combine the required fields and their data
types in the dictionary
Definition of required segments,
segment editor
Definition of basic IDoc types,
IDoc type editor
Creation of a logical message, surrounding
field menu of IDoc type editor
Assignment of a logical message to the
IDoc type, surrounding field menu of IDoc
type editor
Steps for the Development of a Data Structure
In the segment editor you assign a name to the field and enter a data element that describes the field
in the application (documentation). The editor calculates the necessary character length for the field using the data element.
Segment editor, transaction WE31.
You build a complex data structure from the single segments in the IDoc type editor. There you
determine the order and the hierarchical relationship of the segments. In addition, you assign a status (optional/mandatory) as well as the number of repetitions per segment and segment group.
The IDoc API tests that the generated program (outbound processing: SAP processing, inbound processing: subsystem) conforms to these characteristics. Violations of these characteristics are recorded through the IDoc status syntax error (outbound: 26, inbound 60).
SAP AG 1999
Outbound processing using
Message Control (MC) ?
ALE Interface (FM MASTER_IDOC_DISTRIBUTE)?
Inbound processing using
Business Workflow (single step or multistep task) ? ALE Interface (function module) ?
SAP AG 1999
Steps for Development of Outbound Processing
using MC
Checking Message Control, that is, the connection
for the message default:
Condition table Access sequence Condition types Procedure Application
Implementation of a function module that makes
application data available in "IDoc format"
Definition of an outbound process code
The function module must adhere to the following interface:
Import OBJECT like MC
CONTROL_RECORD_IN like EDIDC
Export OBJECT_TYPE like WFAS1-ASGTP CONTROL_RECORD_OUT like EDIDC Tables INT_EDIDD like EDIDD
Exceptions ERROR_MESSAGE_RECEIVED
The function module cannot transmit any explicit or implicit COMMITs. Function module, transaction SE80.
Outbound process code, transaction WE41. For examples, see the appendix.
SAP AG 1999
Implementation of a program that calls the function module
MASTER_IDOC_DISTRIBUTE. Interface
Import MASTER_IDOC_CONTROL like EDIDC
Tables COMMUNICATION_IDOC_CONTROL like EDIDC
MASTER_IDOC_DATA like EDIDD
For this program you have to define how the control works,
specifically, if the control is to take place via a time table,
event or dialog step.
Development Steps for Outbound Processing
using the ALE Interface
The function module MASTER_IDOC_DISTRIBUTE has the following interface:
Import MASTER_IDOC_CONTROL like EDIDC OBJ_TYPE like SERIAL-OBJ_TYPE
CHNUM like SERIAL-CHNUM
Tables COMMUNICATION_IDOC_CONTROL like EDIDC MASTER_IDOC_DATA like EDIDD
Exceptions ERROR_IN_IDOC_CONTROL ERROR_WRITING_IDOC_STATUS ERROR_IN_IDOC_DATA
SENDING_LOGICAL_SYSTEM_UNKNOWN
Notes: The import parameter OBJ_TYPE and CHNUM will be available for the ALE Serializing as
of Release 4.5.
The program calling the function module MASTER_IDOC_DISTRIBUTE has to transmit a
COMMIT WORK. Otherwise it's possible that the IDocs will not be sent but rather will remain in the sending system.
SAP AG 1999
Development Steps of Inbound Processing using
Business Workflow
Implementation of a workflow to control inbound
processing
This includes:
Definition of object and method(s) in BOR Definition of workflow
Definition of inbound process code
BOR - Business Object Repository, transaction SWO1 (Business Object Builder).
Workflow, transaction PFTC until 4.0B, from 4.5 on transactions PFTC_INS, PFTC_CHG and
PFTC_DIS.
Inbound process code, transaction WE42. For an example, see the appendix.
SAP AG 1999
Write function module that posts the IDoc as an
application document
Implementation of a workflow to send messages in case
of error. This includes:
Definition of object and method(s) in BOR Definition of workflow
Maintenance of the characteristics for the function
module for the ALE Call
Allocation of the function module to a logical message
and to an IDoc type for the ALE Call
Definition of an inbound process code and establishing a
connection with the ALE layer
Development Steps for Inbound Processing using
ALE Interface
Post application document: Function module, transaction SE80.
Case 1: The function module uses an internal CALL TRANSACTION which triggers a COMMIT. In this case you must display the ALE layer in the transaction BD51. The transaction uses internal function modules IDOC_INPUT_OPEN and IDOC_INPUT_CLOSE, in order to write the IDoc status within the LUW. In case of an error, foreground processing is possible using such a function module.
Case 2: The function module uses internal APIs (Programming Interfaces) and does not release a COMMIT. In case of an error, foreground processing is not possible using such a function module.
Notification in case of error:
BOR - Business Object Repository, transaction SWO1 (Business Object Builder).
Workflow, transaction PFTC until 4.0B, from 4.5 on, transactions PFTC_INS, PFTC_CHG and PFTC_DIS.
Maintaining the characteristics of the function module: You must make the (technical program) characteristics
of the function module called by ALE known to the ALE layer, by using transaction BD51.
Assignment of the function module: The allocation of a function module to a business process, called by ALE,
has to be executed via transaction WE57. Inbound process code and ALE Connection:
SAP AG 1999
Output Documentation of New Development
Begin … End
typedefine struct edi_dc {…}
edi_dc
XML
The documentation tools are started from the initial node of the IDoc Interface by selecting
Documentation. In addition, the parser output format has its own menu point for record types as well as IDoc types.
Automatic formats are:
Simple, readable with a parser begin..end-Declaration sequence. C-header.
Meta IDoc from type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types). Meta data for IDocs in XML format.
Navigation-compatible formats are:
The tree display in the R/3 System.
HTML file (three files, the *_ f-file is the frame that should be loaded by the browser and the index *_i and actual documentation *_d).
Documentation, IDoc record types: Transaction WE61 Documentation, IDoc types: Transaction WE60 Documentation, IDoc type (parser): Transaction WE63
SAP AG 1999
The data structure is defined as an IDoc type
Depending on the processing course and direction,
different programming templates can be used
Outbound uses 2 methods:
Message Control and ALE
Inbound uses 2 methods:
Workflow and ALE
Glossary
Access An access identifies the document fields used by the system when searching for a condition record.
Access sequence Sequence used by Message Control to access condition records when searching for messages.
Basic type IDoc type supplied by SAP. Basic types can be modified by customers to create a new, upward-compatible IDoc type.
Condition element Part of hierarchy which is examined when searching for a message. An example is the output type which is at the top of this hierarchy: When a (new) purchase order is posted, only the messages under the node for the message type NEW are searched. Condition record Data record in which the key fields represent the condition under which the message
is "found". The remaining fields describe the message itself. Therefore, if one of the data records transferred from the application matches these key fields, the message is found and can then be processed (for example exported as a print form or as an electronic message).
Control record The part of an IDoc which contains the data for identifying the sender and recipient, as well as the structure of the IDoc itself. Each IDoc always has one control record. Data record The part of an IDoc which contains the application data. An IDoc usually contains
more than one data record.
EDI = Electronic Data Interchange. EDI (for example of business documents) between business partners, sometimes in separate countries, who may use different hardware, software and communication services. The data is formatted according to specific standards.
EDI message Standard format for a business process (for example, a purchase order) to be handled by EDI. Various EDI standards (EDIFACT or ANSI X12) can define different EDI messages for the same business process.
EDI standard General format for data to be transferred electronically. An EDI standard generally comprises:
o EDI syntax
o Data element service o Message type service
The SAP standard 'IDoc' is not yet an EDI standard, but can be compared to other EDI standards.
EDI subsystem System which converts the SAP standard IDoc into an EDI standard (for example EDIFACT, ANSI X12) and vice versa. In addition to this task (which is carried out by the EDI subsystem convertor), there are also administration activities, for example, archiving the transferred messages, and technical tasks, for example, technical connection to the subsequent system and syntax checks for formats, to be considered.
Field catalog Contains all fields which can be selected as key fields for condition tables in Message Control.
real business process formatted according to a certain IDoc type.
Inbound processing Conversion and processing of data for a business process from the time the data is received in IDoc format to the posting of the corresponding document(s) in the SAP application.
Mandatory segment The part of an IDoc type which contains important application data and must therefore exist in an IDoc for an actual business process. Mapping Rules for assigning the data elements of an EDI message type to the fields of an
IDoc type.
Message Business process (for example, a purchase order), which is transferred in IDoc format between an SAP System and an external system. Message Control Module designed to offer interfaces for further processing for applications. This
includes descriptions of the various data configurations and the required actions. An example of an action is printing a document at a certain time in German. The action is triggered when the application transfers data which matches your configuration. Message determination A check to determine whether the application data matches the condition records
(specified in Customizing). If this is the case, one or more messages are "found" and can then be processed (for example, sent electronically). In message determination, a search is made for the condition records using a predefined hierarchy. Message status record = MC record. Log record for the MC table which describes the send status of a
message in Message Control.
Notification If an error occurs (for example, an IDoc with incorrect syntax), a notification is sent to one or more users. The users responsible are defined in the IDoc Interface or indirectly via the organization model. Notifications are sent to the integrated inbox. Optional segment Part of an IDoc type which can include additional, optional data about the business
process. The segment does not therefore have to appear in an IDoc for a specific business process.
Outbound file Contains specific IDocs to be sent for port type “file”.
Outbound processing Conversion and processing of SAP document data from posting a document to sending the data in IDoc format.
Partner Communication partner for the IDoc Interface. Definition from Sales and Distribution: "An individual within or outside of your own organization who is of commercial interest and who can be contacted in the course of a business
transaction".
Partner profile Definition of the general conditions for electronic data interchange with a business partner via the IDoc Interface: which message is sent in which direction using which method?
If a partner profile does not exist, communication with a partner via the IDoc Interface is not possible.
Port Description of the channel used by the SAP system for communicating with the external system during external data interchange. There are various technical methods for implementing this type of communication (port types). The selection of the port type depends on the technical configuration of the external system.
- Control record - Data record - Status record
Segment Structure which includes the application data for an IDoc from the data records. As a result, the data can be assigned to the correct application fields. Status Processing status of an IDoc, either "generated" or "ready for sending".
An IDoc usually has several statuses which are stored in the status records and reveal information about the IDoc history. The current (processing) status is also stored in the control record for the IDoc.
Status confirmation Report from an external system about the processing status of business data received from the R/3 System in the form of status records. The status confirmation is added to the IDoc in the R/3 System in the form of status records.
Status file File which contains the status records sent to the IDoc Interface by the EDI subsystem for outbound messages.
Status group The status group contains several statuses ("milestones" in the process chain), so that the monitoring programs only have to consider these groups and not each individual status. Examples:
Group 3 = outbound: IDoc in the external system Group B = inbound: IDoc sent to the application
Status record One of three record types in an IDoc (SAP standard format for electronic exchange of application data).
Each status record contains a status which corresponds to one step in IDoc
processing. This means that the number of status records increases as the processing continues.
Translator Converts internal data formats (IDocs) into EDI messages and vice versa. The translator is a component of the EDI Subsystem. Transmission file A data packet which contains the messages to be exchanged electronically. The
messages are EDI messages, that is, they are formatted according to an EDI standard (for example EDIFACT).
The conversion of the SAP standard IDoc into the EDI standard is carried out by an external system (EDI subsystem).
ALE Registration
IDoc initial node:Development→Message/Application object
Archiving
Tools→Administration, Administration→Data archiving
Maintaining Archiving Status
IDoc initial node:Control→Maintain status values
IDoc Administration
IDoc initial node:Control→IDoc Administration
Display IDoc
IDoc initial node:IDoc→Display IDoc
IDoc Initial Node
Tools→Business Communication, IDoc→IDoc Basis
IDoc Statistics
IDoc initial node:IDoc→IDoc Statistics
IDoc Type Editor
IDoc initial node:Development→IDoc types
Partner Profile
IDoc initial node:IDoc→Partner profile
Port Definition
IDoc initial node: IDoc→Port Definition→Maintain RFC destination
IDoc initial node:IDoc→IDoc destination
Segment Editor
IDoc initial node:Development→IDoc segments
Processing Tests
IDoc initial node:Test→<menu option according to the required function>
Message Allocation – IDoc Type
Examples "Steps for development of outbound processing using MC":
Purchase order, MM
IDoc type ORDERS01
Logical message ORDERS
Function module IDOC_OUTPUT_ORDERS
Outbound process code: ME10
Order confirmation, SD
IDoc type ORDERS01
Logical message ORDRSP
Function module IDOC_OUTPUT_ORDRSP
Outbound process code: SD10
Inbound process code: TXT1
Example "Development steps of inbound processing by Business Workflow": Text
message, inbound
IDoc type: TXTRAW01
Logical message: TXTRAW
Object with method: IDOCTXTRAW.MAILCREATE
One-step task: TS30000008
Inbound process code: TXT1
Examples "Development steps for inbound processing using ALE Interface"
Customer order, SD
Transaction VA01
IDoc type ORDERS01
Logical message ORDERS
Function module IDOC_INPUT_ORDERS
Inbound process code ORDE
Object with method IDOCORDERS.INPUTFOREGROUND
Logical message ORDRSP
Function module IDOC_INPUT_ORDRSP
Inbound process code ORDR
Object with method IDOCORDRSP.INPUTFOREGROUND
One-step task TS00008075
This function module uses APIs (not a transaction) and does not start a COMMIT WORK (case 2 on the slide). If errors occur, foreground processing is not possible.
