BC621 - SAP IDoc Interface (Development) BC621
Release 4.7 15.03.2007
BC621 - SAP IDoc Interface (Development).............................................................................................................1 Copyright.................................................................................................................................................................2 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 Topic Objectives.................................................................................................................................................2 Course Overview Diagram..................................................................................................................................3 Basic Rules for Development..............................................................................................................................4 Areas of Development.........................................................................................................................................5 Steps for the Development of a Data Structure...................................................................................................6
Processing Types.................................................................................................................................................7 Steps for Development of Outbound Processing using MC...............................................................................8 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 Appendix.................................................................................................................................................................1
0 BC621 - SAP IDoc Interface (Development)
BC621 SAP IDoc Interface (Development) SAP AG 1999
R/3 Release 4.6A January 2000 5003 5260
0.2 Copyright
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.
SAP AG 2003
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 Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.
0.3 Business Integration Technologies II Level 2
Level 3 BC619 3 days Application Link Enabling (ALE) Technology BC620 2 days SAP IDoc Interface Technology
BC095
3 days
Business Integration Technology
CA210
4 days
EDI Interface
BC420
Data exchange
*BC619 from 01/2002 BIT300 *BC620 from 01/2002 BIT320 *BC621 from 04/2002 BIT350
5 days
Data Transfer *CA925 5 days Programming with BAPIs in Visual Basic *CA925 from 01/2002 BIT525 *CA926 from 01/2002 BIT526
SAP AG 2001
BC621 1 day SAP IDoc Interface Development
BC415 2 days Communication Interfaces in ABAP *CA926 5 days Programming with BAPIs in JAVA
Interface Programming
0.4 Course Prerequisites
Recommended: Basis BC 400 - ABAP Workbench Basics Required: Basis BC620 - IDoc Interface (Standard)
SAP AG 1999
0.5 Target Group
ABAP Developers Consultants
SAP AG 1999
Notes to the user The training materials are not teach-yourself programs. They complement the course instructor's explanations. On the sheets, there is space for you to write down additional information.
1 Introduction: Contents
Course Goals Course Objective(s) Course Content Course Overview Diagram Main Business Scenario
SAP AG 1999
(C) SAP AG
BC621
1
1.2 Course Goals
At the conclusion of this course, you will be able to: Extend IDoc types Define new IDoc types
SAP AG 1999
(C) SAP AG
BC621
2
1.3 Course Objectives
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
(C) SAP AG
BC621
3
1.4 Course Content
Preface Unit 1
Introduction
Unit 2
Development Environment for IDoc Types
Unit 3
Extension of IDoc Types
Unit 4
Development of IDoc Types
Appendix
SAP AG 1999
(C) SAP AG
BC621
4
1.5 BC621 Course Overview Diagram
Development of IDoc Types
Extension of IDoc Types
1
Development Environment for IDoc Types
Introduction
SAP AG 1999
(C) SAP AG
BC621
5
1.6 Main Business Scenario
Enterprise trading Enterprise trading company A
company A wants Vendor Vendor B 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 SieSAP sichalso SAP R/3 System R/3 System über die Entwicklungsmöglichkeiten, die die IDoc-Schnittstelle bietet. IDoc IDoc EDI Subsystem
Message
EDI Subsystem
SAP AG 1999
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 development of the IDoc Interface.
(C) SAP AG
BC621
6
2 Development Environment for IDoc Types
Data Structures:
IDoc Record Types
IDoc Types
IDoc Segments
Development and Extension
SAP AG 1999
(C) SAP AG
BC621
1
2.2 Course Objectives
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
(C) SAP AG
BC621
2
2.3 Course Overview Diagram
Development of IDoc Types
2 Extension of IDoc Types Development Environment for IDoc Types Introduction
SAP AG 1999
(C) SAP AG
BC621
3
2.4 Components of the IDoc Process
Application Function module
Business Workflow
Program Report
Ou
tb
n ou
d
o Pr
ce
g in s s
Function module IDoc Type
In
Segment
Segment type
u bo
nd
e oc r P
g in s s
Segment name
IDoc Interface
ta Da
str
e tur c u
SAP AG 1999
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. In inbound processing you can generate or change application data from the IDoc format.
(C) SAP AG
BC621
4
2.5 IDoc Record Types
Control Record
IDoc ID Partner IDoc Type and Logical Message External Structure
Data Records Control Part
Status Records
Application Data
IDoc ID Status Information
SAP AG 1999
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.
(C) SAP AG
BC621
5
2.6 IDoc Terms: Basic Type and Extensions
Basic type =
IDoc type
+
Basic type Extension
=
IDoc type
SAP AG 1999
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 The field CIMTYP has the value of the name of the extension
(C) SAP AG
BC621
6
2.7 IDoc Terms: Segment
Segment type E1ccccc
Segment name /partner/ccccc000 Segment type /partner/ccccc
Segment name /partner/ccccc001
Segment name E2ccccc000
Version 1 e.g. 3.0A
Segment name E2ccccc001
Version 2 e.g. 3.0C
Segment name E2ccccc013
Version 14 e.g.7.7x
Segment name /partner/ccccc013
SAP AG 1999
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.
(C) SAP AG
BC621
7
2.8 IDoc Functions: Release and Version Creation
By releasing segments and IDoc types, the external interface is "frozen" and given unique names for these objects for an external partner system. There can only be one segment version for each SAP Release (for example 4.0B). The IDoc definition tools control the release.After each release, further development leads to new versions. Changes must be made in accordance with strict rules so that the interface remains compatible.
SAP AG 1999
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.
(C) SAP AG
BC621
8
2.9 ABAP Programming Names
"IDoc Type"
Control record, EDIDC
Data records, EDIDD, displayed as a segment tree E1HDDOC M
E1TLSUM
1
C
E1HDADR C
5
1
E1ITDOC Parent M segment 1
E1ITSCH E1ITSCH C
99
Child segment
C
5
Status record, EDIDS & EDI_DS
SAP AG 1999
ABAP programming exclusively uses the segment types of the segments, for example in the TABLES statement. Segment types implemented in the SAP standard system start with prefix "E1".
(C) SAP AG
BC621
9
2.10 Subsystem Names
"IDoc Type"
Control record, EDI_DC40 Data records, displayed as a segment tree E2HDDOC000 M
E2TLSUM000
1
C
1
E1ITDOC E2HDADR000 E2ITDOC000 C
5
Parent segment M 1
E1ITSCH E2ITSCH000 C
99
Child segment
C
5
Status record, EDI_DS40
SAP AG 1999
The segment names of the segments are exclusively visible by the subsystem. Segment names implemented in the SAP standard system start with prefix "E2".
(C) SAP AG
BC621
10
2.11 IDoc Definition Tools
IDoc Type Editor
WE30
E1HDDOC
Segment editor WE31
SAP AG 1999
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) The segment editor permits the definition of segments for later use in the IDoc type editor.
(C) SAP AG
BC621
11
2.12 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 itis present but does not meet all the requirements: Action: Development!
SAP AG 1999
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 be activated as table entries using the process codes.
(C) SAP AG
BC621
12
2.13 Summary
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
(C) SAP AG
BC621
13
3 Extension of an IDoc Type
Extension of the data structure Extension of Outbound Processing Extension of Inbound Processing
SAP AG 1999
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.
(C) SAP AG
BC621
1
3.2 Course Objectives
Create IDoc Segment Extend an IDoc Type Implement a customer exit in outbound processing Implement a customer exit in inbound processing
SAP AG 1999
(C) SAP AG
BC621
2
3.3 Course Overview Diagram
3
Development of IDoc type
Extension of an IDoc type Development environment for IDoc types Implementation
SAP AG 1999
(C) SAP AG
BC621
3
3.4 Advantages of Customer Enhancement
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
(C) SAP AG
BC621
4
3.5 Basic Rules for Customer Extension
Additional customer fields are recorded in their own customer segments. Customer segments depend on SAP segments (successor or child relationships). The processing of customer segments is exclusively implemented in the customer exits of the coding provided in the standard system.
SAP AG 1999
(C) SAP AG
BC621
5
3.6 Areas of Customer Extension
Application Function Module
Business Workflow
Program
Function Module
Report
IDoc Type
Segment
Segment Type
Data structure in the WEDI area menu Outbound and inbound processing: Typically through transaction "CMOD", otherwise through individual technique Documentation: In the WEDI area menu
Segment Name
IDoc Interface
SAP AG 1999
(C) SAP AG
BC621
6
3.7 Steps For Extending the Data Structure
Combine the required fields and their data types in the dictionary. Definition of required segments, segment editor. Definition of extension, IDoc type editor. Assignment of a logical message to the IDoc type, surrounding field menu of IDoc type editor.
SAP AG 1999
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”). IDoc type editor, transaction WE30.
(C) SAP AG
BC621
7
3.8 Steps for Extending Processing
Definition of a project, project management, attribute Choosing the "correct" customer exits, project management, SAP extensions Implementation of the selected customer exits, project management, extension components
Outbound processing: reading of the SAP database and data in "IDoc format"
Inbound processing: writing data from the "IDoc format" into the SAP database
Activate project in project management
SAP AG 1999
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. Activate the project after returning to the initial screen of the transaction.
(C) SAP AG
BC621
8
3.9 Output Documentation of the Extension
Begin … End
typedefine struct edi_dc XML
{…} edi_dc
SAP AG 1999
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
(C) SAP AG
BC621
9
3.10 Summary
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.
SAP AG 1999
(C) SAP AG
BC621
10
3.11Erweiterung
eines IDoc-Typs: Exercise
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
Material
SH-100
SH-100
Vendor
T-BILnn
1014
Purchasing Organization
1000
1000
Purchasing Group
001
001
Plant
1100
1100
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
Customer:
Vendor:
nn is your group number
(C) SAP AG
BC621
11
Unit: Extension of an IDoc Type
• 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:
(C) SAP AG
Recipient, Port:
SAP, System ID of SAP system, for example SAPT80
Sender, Port:
SUBSYSTEM
Sender, Partner Number:
T-BIKnn
Sender, Partner Type:
KU
Sender, Partner Function:
AG
BC621
12
A corresponding inbound partner profile is already available. Select Execute. The inbound IDoc generated gets status 51 with the error “document type NB unknown”.
(C) SAP AG
BC621
13
Unit: Extension of an IDoc Type 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, System ID of SAP system, for example SAPT80
Sender, Port:
SUBSYSTEM
Sender, Partner Number:
T-BIKnn
Sender, Partner Type:
KU
Sender, Partner Function:
AG
nn is the number of your group (from 01 to 18)
(C) SAP AG
BC621
14
Unit: Extension of an IDoc Type 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.
nn is the number of your group (from 01 to 18)
(C) SAP AG
BC621
15
Unit: Extension of an IDoc Type 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.
nn is the number of your group (from 01 to 18)
(C) SAP AG
BC621
16
Unit: Extension of an IDoc Type 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.
nn is the number of your group (from 01 to 18)
(C) SAP AG
BC621
17
Unit: Extension of an IDoc Type 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, System ID of SAP system, for example SAPT80
Sender, Port:
SUBSYSTEM
Sender, Partner Number:
T-BIKnn
Sender, Partner Type:
KU
Sender, Partner Function:
AG
The generated IDoc contains the status 53 (application document posted). 6-4
(C) SAP AG
Check the order to see if it contains the delivery conditions. The condition text should contain the string from the customer exit.
BC621
18
3.12Extension of an IDoc Type: Solutions Unit: Extension of an IDoc Type Topic: Extension of Inbound Processing
2-1 Program code for outbound processing extension: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
*----------------------------------------------------------------------* * INCLUDE ZXDIXU02 *----------------------------------------------------------------------* data: h_e1head like e1head.
" Exercise 2
pe_vbak621 = pi_vbak621. * Exercise 2 loop at pt_idoc_data_records where segnam = 'E1HEAD'. h_e1head = pt_idoc_data_records-sdata. if h_e1head-auart = 'NB'. pe_vbak621-auart = 'TA'. endif. endloop.
(C) SAP AG
BC621
19
Unit: Extension of an IDoc Type Topic: Extension of Outbound Processing
3-1 Program code for outbound processing extension: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
*----------------------------------------------------------------------* * INCLUDE ZXDIXU01 *----------------------------------------------------------------------* data: k_e1head like e1head.
" Exercise 3
loop at pt_idoc_data_records where segnam = 'E1HEAD'. * Exercise 3 k_e1head = pt_idoc_data_records-sdata. k_e1head-name = pi_ekko-ernam. pt_idoc_data_records-sdata = k_e1head. modify pt_idoc_data_records. endloop.
(C) SAP AG
BC621
20
Unit: Extension of an IDoc Type 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.
(C) SAP AG
BC621
21
Unit: Extension of an IDoc Type Topic: Extension of Outbound Processing
5-1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Program code for outbound processing extension (extended INCLUDE from exercise 3):
*----------------------------------------------------------------------* * INCLUDE ZXDIXU01 *----------------------------------------------------------------------* data: k_e1head like e1head. data: k_z1inco like z1incodx.
" Exercise 3 " Exercise 5
loop at pt_idoc_data_records where segnam = 'E1HEAD'. * Exercise 3 k_e1head = pt_idoc_data_records-sdata. k_e1head-name = pi_ekko-ernam. pt_idoc_data_records-sdata = k_e1head. modify pt_idoc_data_records. * Exercise 5 clear pt_idoc_data_records. clear k_z1inco. k_z1inco-inco1 = pi_ekko-inco1. k_z1inco-inco2 = pi_ekko-inco2. pt_idoc_data_records-segnam = 'Z1INCODX'. pt_idoc_data_records-sdata = k_z1inco. append pt_idoc_data_records. endloop.
(C) SAP AG
BC621
22
Unit: Extension of an IDoc Type Topic: Extension of Inbound Processing
6-1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Program code for inbound processing extension (extended INCLUDE from exercise 2):
*----------------------------------------------------------------------* * INCLUDE ZXDIXU02 *----------------------------------------------------------------------* data: h_e1head like e1head. data: h_z1inco like z1incodx.
" Exercise 2 " Exercise 6
pe_vbak621 = pi_vbak621. * Exercise 2 loop at pt_idoc_data_records where segnam = 'E1HEAD'. h_e1head = pt_idoc_data_records-sdata. if h_e1head-auart = 'NB'. pe_vbak621-auart = 'TA'. endif. endloop. * Exercise 6 loop at pt_idoc_data_records where segnam = 'Z1INCODX'. h_z1inco = pt_idoc_data_records-sdata. pe_vbak621-inco1 = h_z1inco-inco1. * pe_vbak621-inco2 = h_z1inco-inco2. pe_vbak621-inco2 = ‘Test BC621-DX’. endloop.
(C) SAP AG
BC621
23
4 Development of IDoc Type
Development of the data structure Processing example
SAP AG 1999
(C) SAP AG
BC621
1
4.2 Topic Objectives
Create IDoc segments Develop new IDoc types Template for IDoc outbound processing Template for IDoc inbound processing
SAP AG 1999
(C) SAP AG
BC621
2
4.3 Course Overview Diagram
4
Development of IDoc type
Extension of an IDoc type Development environment for IDoc types Implementation
SAP AG 1999
(C) SAP AG
BC621
3
4.4 Basic Rules for Development
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.
SAP AG 1999
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).
(C) SAP AG
BC621
4
4.5 Areas of Development
Data structure: in the WEDI area menu
Application Function Module
Business Workflow
Program
Function Module
Report
IDoc Type
Documentation: in the WEDI menu
Segment
Segment Type
Outbound and inbound processing: in the Object Browser "SE80"
Segment Name
IDoc Interface
SAP AG 1999
(C) SAP AG
BC621
5
4.6 Steps for the Development of a Data Structure
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
SAP AG 1999
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). IDoc type editor, transaction WE30.
(C) SAP AG
BC621
6
4.7 Processing Types
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
(C) SAP AG
BC621
7
4.8 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
SAP AG 1999
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.
(C) SAP AG
BC621
8
4.9 Development Steps for Outbound Processing using the ALE Interface
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.
SAP AG 1999
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.
(C) SAP AG
BC621
9
4.10 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
SAP AG 1999
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.
(C) SAP AG
BC621
10
4.11 Development Steps for Inbound Processing using ALE Interface
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
SAP AG 1999
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: The process code for the IDoc Interface is defined via transaction WE42. As of this point, transaction BD67 branches to establish the connection to the ALE layer. In case of an error (IDoc trigger event) and the connection of IDoc and application document, information is stored in a table. For examples, see the appendix.
(C) SAP AG
BC621
11
4.12 Output Documentation of New Development
Begin … End
typedefine struct edi_dc XML
{…} edi_dc
SAP AG 1999
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
(C) SAP AG
BC621
12
4.13 Summary
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
SAP AG 1999
(C) SAP AG
BC621
13
5Appendix 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.
File interface
= port type “file”
Hierarchy level
Determines the position of a segment in a tree segment. A segment carries business data in an IDoc. Dependencies in the application data can be represented in this tree structure, that is, the various hierarchy levels.
IDoc interface
Definition of formats (IDoc types, previously: intermediate structures) and methods (port definitions) for electronic data exchange between SAP Systems and partner
(C) SAP AG
BC621
1
systems. IDoc type
SAP format in which data for a business process is to be transferred. An IDoc is a real business process formatted according to a certain IDoc type.
Inbound processing
Conversion and processing of data for a business process from the time the data is received in IDoc format to the posting of the corresponding document(s) in the SAP application.
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. Example: Most EDI subsystems read IDocs in the form of sequential files, that is, the port type 'file' is used.
Procedure
A group of messages. A procedure is searched for messages which are to be processed for the specified data configuration (for example, sent electronically or printed).
Process code
Another name for a defined processing type, for example a function module or an SAP Business Workflow task. In contrast, a defined IDoc type (standard format for data communication) is usually assigned to a certain process code. If the process type for this IDoc type is to be changed, you should assign the corresponding process code to the new processing type. Without this process code, this IDoc type
(C) SAP AG
BC621
2
must be assigned to the new processing code directly. Record type
An IDoc type consists of the following three record types: - 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).
(C) SAP AG
BC621
3
Important Menu Paths 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→
