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
BC619 3 days Application Link Enabling (ALE) Technology BC620 2 days SAP IDoc Interface Technology BC095 3 days CA210 EDI Interface 4 days BC621 1 day SAP IDoc Interface Development
*BC619 from 01/2002 BIT300 *BC620 from 01/2002 BIT320 *BC621 from 04/2002 BIT350

Level 3

Data exchange

Business Integration Technology

BC420 Data Transfer

5 days BC415 2 days Communication Interfaces in ABAP *CA926 5 days Programming with BAPIs in JAVA

*CA925 5 days Programming with BAPIs in Visual Basic

*CA925 from 01/2002 BIT525 *CA926 from 01/2002 BIT526

Interface Programming

SAP AG 2001

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

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

1.4
Course Content

Preface Unit 1 Unit 2 Unit 3 Unit 4 Introduction Development Environment for IDoc Types Extension of IDoc Types Development of IDoc Types

Appendix

SAP AG 1999

(C) SAP AG

BC621

1.5
BC621 Course Overview Diagram

Development of IDoc Types

Extension of IDoc Types

Development Environment for IDoc Types

Introduction

SAP AG 1999

(C) SAP AG

BC621

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 Bedrfnissen entsprechend erweitert werden mu. Als Projektteammitglied informieren Sie sichalso SAP R/3 System SAP R/3 System ber die Entwicklungsmglichkeiten, 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

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

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

2.4
Components of the IDoc Process

Application
Function module Program Report IDoc Type Business Workflow Function module

Ou

tb

n ou

o Pr

ce

g in s s

Segment

In

u bo

nd

e oc r P

g in s s

Segment type

Segment name

IDoc Interface

ta Da
SAP AG 1999

str

e tur c u

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

2.5
IDoc Record Types

Control Record

IDoc ID Partner IDoc Type and Logical Message External Structure

Data Records
Control Part Application Data

Status Records

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

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

2.7
IDoc Terms: Segment

Segment type E1ccccc

Segment name E2ccccc000 Segment name E2ccccc001

Version 1 e.g. 3.0A

Version 2 e.g. 3.0C

Segment name /partner/ccccc000 Segment type /partner/ccccc Segment name /partner/ccccc001

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

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

2.9
ABAP Programming Names

Control record, EDIDC

"IDoc Type"

Data records, EDIDD, displayed as a segment tree E1HDDOC

M 1

E1TLSUM
C 1

E1HDADR
C 5

E1ITDOC
Parent M segment 1

E1ITSCH E1ITSCH
C 99
Child segment

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

2.10
Subsystem Names

Control record, EDI_DC40 Data records, displayed as a segment tree

E2HDDOC000 M 1

"IDoc Type"

E2TLSUM000 C 1

E1ITDOC E2HDADR000 E2ITDOC000

C 5
Parent segment M 1

E1ITSCH E2ITSCH000
C 99
Child segment

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

Segment editor WE31

E1HDDOC

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

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

3.3
Course Overview Diagram

Development of IDoc type

Extension of an IDoc type Development environment for IDoc types Implementation

SAP AG 1999

(C) SAP AG

BC621

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

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

3.6
Areas of Customer Extension

Application
Function Module Program Report IDoc Type Business Workflow Function Module

Data structure in the WEDI area menu Outbound and inbound processing: Typically through transaction "CMOD", otherwise through individual technique Documentation: In the WEDI area menu

Segment

Segment Type

Segment Name

IDoc Interface

SAP AG 1999

(C) SAP AG

BC621

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

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

3.9
Output Documentation of the Extension

Begin End
XML

typedefine struct edi_dc {} 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

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 Customer: Material Vendor Purchasing Organization Purchasing Group Plant Vendor: Material Sold-to party Order Type Sales Organization Distribution Channel Division nn is your group number SH-100 T-BIKnn TA 1020 22 00 1020 22 00 SH-100 1110 SH-100 T-BILnn 1000 001 1100 SH-100 1014 1000 001 1100 Data in Training System Data in IDES System

(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: Recipient, Port: Sender, Port: Sender, Partner Number: Sender, Partner Type: Sender, Partner Function: SAP<SID>, System ID of SAP system, for example SAPT80 SUBSYSTEM T-BIKnn KU AG

(C) SAP 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. 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. Now activate your project. 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: Sender, Port: Sender, Partner Number: Sender, Partner Type: Sender, Partner Function: SAP<SID>, System ID of SAP system, for example SAPT80 SUBSYSTEM T-BIKnn KU AG

2-2

2-3 2-4

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. Activate your project. 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. 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.

3-2 3-3

3-4

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. In the segment editor, test that your definition is correct. Ignore the warning that the segment has not yet been released. Define the extension ZEXTENnn in the IDoc type editor. Extend the basic IDoc type ORDLGT01 by segment Z1INCOnn. Add to the logical message ORDLGT the basic type ORDLGT01 with the extension ZEXTENnn in the IDoc type editor. 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.

4-2

4-3

4-4

4-5

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. Activate your project. In partner agreement for vendor T-BILnn, in the outbound parameter table change the IDoc type from basic IDoc type ORDLGT01 to extension ZEXTENnn. 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. 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.

5-2 5-3

5-4

5-5

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. Activate your project. 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: Sender, Port: Sender, Partner Number: Sender, Partner Type: Sender, Partner Function: SAP<SID>, System ID of SAP system, for example SAPT80 SUBSYSTEM T-BIKnn KU AG

6-2 6-3

The generated IDoc contains the status 53 (application document posted). 6-4 Check the order to see if it contains the delivery conditions. The condition text should contain the string from the customer exit.

(C) SAP AG

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

(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 The extension ZEXTENnn consists of standard segments E1HEAD and E1ITEM. The customer segment Z1INCOnn, as child segment depends on standard segment E1HEAD.

4-2

(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. 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. " Exercise 2 " Exercise 6

(C) SAP AG

BC621

23

4
Development of IDoc Type

Development of the data structure Processing example

SAP AG 1999

(C) SAP AG

BC621

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

4.3
Course Overview Diagram

Development of IDoc type

Extension of an IDoc type Development environment for IDoc types Implementation

SAP AG 1999

(C) SAP AG

BC621

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.5
Areas of Development

Application
Function Module Program Report IDoc Type Business Workflow Function Module

Data structure: in the WEDI area menu Outbound and inbound processing: in the Object Browser "SE80" Documentation: in the WEDI menu

Segment

Segment Type

Segment Name

IDoc Interface

SAP AG 1999

(C) SAP AG

BC621

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

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

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

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 Tables

MASTER_IDOC_CONTROL like EDIDC 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

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
XML

typedefine struct edi_dc {} 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 Access sequence Basic type Condition element An access identifies the document fields used by the system when searching for a condition record. Sequence used by Message Control to access condition records when searching for messages. IDoc type supplied by SAP. Basic types can be modified by customers to create a new, upward-compatible IDoc type. 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. 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). 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. The part of an IDoc which contains the application data. An IDoc usually contains more than one data record. = 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. 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. 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. Contains all fields which can be selected as key fields for condition tables in Message Control. = port type file 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. Definition of formats (IDoc types, previously: intermediate structures) and methods (port definitions) for electronic data exchange between SAP Systems and partner BC621 1

Condition record

Control record Data record EDI

EDI message

EDI standard

Field catalog File interface Hierarchy level

IDoc interface (C) SAP AG

systems. IDoc type Inbound processing 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. 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. The part of an IDoc type which contains important application data and must therefore exist in an IDoc for an actual business process. Rules for assigning the data elements of an EDI message type to the fields of an IDoc type. Business process (for example, a purchase order), which is transferred in IDoc format between an SAP System and an external system. 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. 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. = MC record. Log record for the MC table which describes the send status of a message in Message Control. 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. 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. Contains specific IDocs to be sent for port type file. Conversion and processing of SAP document data from posting a document to sending the data in IDoc format. 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". 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. 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). 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 BC621 2

Mandatory segment Mapping Message Message Control

Message determination

Message status record Notification

Optional segment

Outbound file Outbound processing Partner

Partner profile

Procedure

Process code

(C) SAP AG

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 Status 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. 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. File which contains the status records sent to the IDoc Interface by the EDI subsystem for outbound messages. 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 Transmission file Converts internal data formats (IDocs) into EDI messages and vice versa. The translator is a component of the EDI Subsystem. 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).

Status file Status group

(C) SAP AG

BC621

Important Menu Paths

ALE Registration
IDoc initial node: DevelopmentMessage/Application object

Archiving
ToolsAdministration, AdministrationData archiving

Maintaining Archiving Status

IDoc initial node: ControlMaintain status values

IDoc Administration
IDoc initial node: ControlIDoc Administration

Display IDoc
IDoc initial node: IDocDisplay IDoc

IDoc Initial Node

ToolsBusiness Communication, IDocIDoc Basis

IDoc Statistics
IDoc initial node: IDocIDoc Statistics

IDoc Type Editor

IDoc initial node: DevelopmentIDoc types

Partner Profile
IDoc initial node: IDocPartner profile

Port Definition
IDoc initial node: IDocPort DefinitionMaintain RFC destination IDoc initial node: IDocIDoc destination

Segment Editor
IDoc initial node: DevelopmentIDoc segments

Processing Tests
IDoc initial node: Test<menu option according to the required function>

Message Allocation IDoc Type

IDoc initial node: DevelopmentIDoc type/message

(C) SAP AG

BC621

5.2Examples for Unit 4

Examples "Steps for development of outbound processing using MC":
Purchase order, MM IDoc type Logical message Function module Outbound process code: ORDERS01 ORDERS IDOC_OUTPUT_ORDERS ME10

Order confirmation, SD IDoc type Logical message Function module Outbound process code: ORDERS01 ORDRSP IDOC_OUTPUT_ORDRSP SD10

Inbound process code: TXT1 Example "Development steps of inbound processing by Business Workflow": Text message, inbound
IDoc type: Logical message: Object with method: One-step task: Inbound process code: TXTRAW01 TXTRAW IDOCTXTRAW.MAILCREATE TS30000008 TXT1

Examples "Development steps for inbound processing using ALE Interface"

Customer order, SD Transaction IDoc type Logical message Function module Inbound process code Object with method One-step task VA01 ORDERS01 ORDERS IDOC_INPUT_ORDERS ORDE IDOCORDERS.INPUTFOREGROUND TS00008046

This function module starts the command CALL TRANSACTION and thus an implicit COMMIT WORK (case 1 in the slide). This is the ALE layer (transaction BD51). VA01 calls IDOC_INPUT_OPEN and IDOC_INPUT_CLOSE in order to write the IDoc status in the same LUW (it is "ALE-compatible). If errors occur, foreground processing is possible. (C) SAP AG BC621 5

Order acknowledgment, MM IDoc type Logical message Function module Inbound process code Object with method One-step task ORDERS01 ORDRSP IDOC_INPUT_ORDRSP ORDR IDOCORDRSP.INPUTFOREGROUND 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.

(C) SAP AG

BC621