BC621 - SAP IDoc Interface Development)

BC621 - SAP IDoc Interface (Development)BC621

Release 4.7 15.03.2007

BC621 - SAP IDoc Interface (Development)..........................................................................................................0-1

Copyright.............................................................................................................................................................0-2

Business Integration Technologies II..............................................................................................................0-3

Course Prerequisites........................................................................................................................................0-4

Target Group....................................................................................................................................................0-5

Introduction: Contents.........................................................................................................................................1-1

Course Goals....................................................................................................................................................1-2

Course Objectives............................................................................................................................................1-3

Course Content................................................................................................................................................1-4

BC621 Course Overview Diagram..................................................................................................................1-5

Main Business Scenario...................................................................................................................................1-6

Development Environment for IDoc Types.........................................................................................................2-1


Course Overview Diagram..............................................................................................................................2-3

Components of the IDoc Process.....................................................................................................................2-4

IDoc Record Types..........................................................................................................................................2-5

IDoc Terms: Basic Type and Extensions.........................................................................................................2-6

IDoc Terms: Segment......................................................................................................................................2-7

IDoc Functions: Release and Version Creation...............................................................................................2-8

ABAP Programming Names............................................................................................................................2-9

Subsystem Names..........................................................................................................................................2-10

IDoc Definition Tools....................................................................................................................................2-11

When is Which Action Necessary?...............................................................................................................2-12

Summary........................................................................................................................................................2-13

Extension of an IDoc Type..................................................................................................................................3-1



Advantages of Customer Enhancement...........................................................................................................3-4

Basic Rules for Customer Extension...............................................................................................................3-5

Areas of Customer Extension..........................................................................................................................3-6

Steps For Extending the Data Structure...........................................................................................................3-7

Steps for Extending Processing.......................................................................................................................3-8

Output Documentation of the Extension.........................................................................................................3-9

Summary........................................................................................................................................................3-10

Erweiterung eines IDoc-Typs: Exercise........................................................................................................3-11

Extension of an IDoc Type: Solutions...........................................................................................................3-19

Development of IDoc Type.................................................................................................................................4-1

Topic Objectives..............................................................................................................................................4-2


Basic Rules for Development..........................................................................................................................4-4

Areas of Development.....................................................................................................................................4-5

Steps for the Development of a Data Structure...............................................................................................4-6

Processing Types.............................................................................................................................................4-7

Steps for Development of Outbound Processing using MC............................................................................4-8

Development Steps for Outbound Processing using the ALE Interface..........................................................4-9

Development Steps of Inbound Processing using Business Workflow.........................................................4-10

Development Steps for Inbound Processing using ALE Interface................................................................4-11

Output Documentation of New Development...............................................................................................4-12

Summary........................................................................................................................................................4-13

Appendix..............................................................................................................................................................5-1

0

SAP AG 1999

BC621 - SAP IDoc Interface (Development)

BC621BC621

SAP IDoc Interface(Development)SAP IDoc Interface(Development)

R/3 Release 4.6A January 2000 5003 5260

0.2

SAP AG 2003

Copyright 2003 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

All rights reserved.

Copyright

Trademarks: Some software products marketed by SAP AG and its distributors contain proprietary software

components of other software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered

trademarks of Microsoft Corporation. IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®,

AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,

VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide 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

SAP AG 2001

Business Integration Technologies II

Business IntegrationTechnology

BC095 3 days

Level 2 Level 3

Data Transfer

BC420 5 days

Programming with BAPIs in Visual Basic

*CA925 5 days InterfaceProgramming

Data exchange

Communication Interfaces in ABAP

BC415 2 days

Programming with BAPIs in JAVA

*CA926 5 days

SAP IDoc Interface -Development

BC621 1 daySAP IDoc InterfaceTechnology

BC620 2 days

Application Link Enabling (ALE)Technology

BC619 3 days

EDI Interface

CA210 4 days

*BC620 from 01/2002 BIT320

*BC619 from 01/2002 BIT300

*BC621 from 04/2002 BIT350

*CA925 from 01/2002 BIT525

*CA926 from 01/2002 BIT526

0.4

SAP AG 1999

Course Prerequisites

Recommended: Basis BC 400 - ABAPWorkbench Basics

Required: Basis BC620 - IDoc Interface (Standard)

0.5

SAP AG 1999

Target Group

ABAP Developers

Consultants

Notes to the user The training materials are not teach-yourself programs. They complement the course instructor's

explanations. On the sheets, there is space for you to write down additional information.

1

SAP AG 1999

Course Goals

Course Objective(s)

Course Content

Course Overview Diagram

Main Business Scenario

Introduction: Contents

(C) SAP AG BC621 1

1.2

SAP AG 1999

At the conclusion of this course, you will be able to:

Extend IDoc types

Define new IDoc types

Course Goals

(C) SAP AG BC621 2

1.3

SAP AG 1999

At the conclusion of this course, you will be able to:Build and extend the data structure of IDoc types

Use the IDoc type editor and segment editor

Use customer exits to process IDoc types

Course Objectives

(C) SAP AG BC621 3

1.4

SAP AG 1999

Unit 1 Introduction

Unit 2 Development Environment for IDoc Types

Unit 3 Extension of IDoc Types

Unit 4 Development of IDoc Types

Preface

Appendix

Course Content

(C) SAP AG BC621 4

1.5

SAP AG 1999

Introduction

11 Development Environment for IDoc Types

Extension ofIDoc Types

Development of IDoc Types

BC621 Course Overview Diagram

(C) SAP AG BC621 5

1.6

SAP AG 1999

Enterprise trading company A wants Vendor B to ship their material orders via EDI.Herrmann & Riemer will die entsprechenden Bestellungen gleich elektronisch verbuchen.Als Grundlage wollen die Unternehmen den IDoc-Typ ORDLGT01 verwenden, der aber eventuell noch den Bedürfnissen entsprechend erweitert werden muß. Als Projektteammitglied informieren Sie sich also über die Entwicklungsmöglichkeiten, die die IDoc-Schnittstelle bietet.

Message

IDocIDoc

Vendor BEnterprise trading company A

SAP R/3 SystemSAP R/3 System

EDI SubsystemEDI Subsystem EDI SubsystemEDI Subsystem

SAP R/3 SystemSAP R/3 System

Main Business Scenario

Enterprise trading company A wants vendor B to ship their material orders via EDI. Vendor B would like to electronically update the placed orders immediately. As a basis for this transaction, A & B intend to use IDoc type ORDLGT01. However, IDoc type ORDLGT01 needs to be extended to meet their needs. Your task as a member of the project team is to research the possibilities of the development of the IDoc Interface.

(C) SAP AG BC621 6

2

SAP AG 1999

Data Structures:

IDoc Record Types

IDoc Types

IDoc Segments

Development and Extension

Development Environment for IDoc Types

(C) SAP AG BC621 1

2.2

SAP AG 1999

Understand the development environment for IDoc types

Describe the functionality of the development environment for IDoc types

Explain the difference between development and extensions

Course Objectives

(C) SAP AG BC621 2

2.3

SAP AG 1999

Introduction

22

Development Environment for IDoc Types

Extension ofIDoc Types

Development of IDoc Types


(C) SAP AG BC621 3

2.4

SAP AG 1999

Function module

Program

Report

Business Workflow

Function module

IDoc Interface

Application

Segment type

Segment

IDoc Type

Segment name

Outbound P

rocessin

gIn

bound Pro

cessing

Data structure

Components of the IDoc Process

The IDoc Interface consists of a data structure (the IDoc type) and process programs for this data structure.

The Subsystem Interface is built through the data structure. The process programs are inserted between SAP application and interface.

In outbound processing you should be able to read the master and movement data as well as be able to format it into an IDoc format.In inbound processing you can generate or change application data from the IDoc format.

(C) SAP AG BC621 4

2.5

SAP AG 1999

Control Record

Data Records

IDoc IDPartnerIDoc Type and Logical MessageExternal Structure

Control Part Application Data

Status Records IDoc IDStatus Information

IDoc Record Types

Every IDoc in the SAP database consists of:One control record,Data records, containing the application data in the segments describing the hierarchy. These segments are in a hierarchy sequence,Status records, which monitor specific IDoc steps. The further the IDoc is in its process the more status records it has.

An IDoc that has been exchanged with an external system, will only containThe control record andThe 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

SAP AG 1999

IDoc Terms: Basic Type and Extensions

Basic typeBasic type

IDoc typeIDoc type==

Basic typeBasic type

IDoc typeIDoc type

ExtensionExtension

==

++

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 typeCIMTYPName of extension

Examples: IDoc type ORDERS01 from standard system, not extended:

The field IDOCTYP has the value ORDERS01The field CIMTYP is empty

IDoc type ORDERS01 from standard system, extended by customers:The field IDOCTYP has the value ORDERS01The field CIMTYP has the value of the name of the extension

(C) SAP AG BC621 6

2.7

SAP AG 1999

IDoc Terms: Segment

Segment type/partner/cccccSegment type/partner/ccccc

Segment name/partner/ccccc000Segment name/partner/ccccc000

Segment name/partner/ccccc001

Segment typeE1cccccSegment typeE1ccccc

Segment nameE2ccccc000Segment nameE2ccccc000



Version 1e.g. 3.0A

Version 2e.g. 3.0C

Version 14e.g.7.7x

Segment name/partner/ccccc013

A segment consists of one SAP release independent segment type At least one SAP release dependent segment name (segment definition).

Segment types are structures in the dictionary. They are used as internal names in the SAP System. An external system, for example an EDI subsystem, can recognize the version of the current segment

by the segment name. Segment types are a maximum of 27 digits. Segment names are derived from the segment types by

adding 3 digits (starting with 000). The naming conventions are preserved through the IDoc definition tools.

SAP segments differ from this rule: Segment types start with “E1”, segment names with “E2“ and additionally have a version number. The customer can also use the namespace "Z1"/ "Z2" or a customer prefix. Partners always use a

prefix. All segment fields are of type CHAR. Thus all SAP data types with similar characters are permitted,

for example NUMC or CLNT.

(C) SAP AG BC621 7

2.8

SAP AG 1999

By releasing segments and IDoc types, the external interface is "frozen" and given unique names for these objects for an external partner system.

There can only be one segment version for each SAP Release (for example 4.0B).

The IDoc definition tools control the release. After each release, further development leads to new versions.

Changes must be made in accordance with strict rules so that the interface remains compatible.

IDoc Functions: Release and Version Creation

The version of an IDoc type or segment is created at a maintenance level. The last version remains the current one in all following maintenance levels. The current version is only replaced by the development of a new version.

All old versions remain in the system so that it is possible to reduce the current version to an older version at any time. This enables the subsystems to be kept compatible even after an upgrade.

Segment version: New fields can only be added to an existing segment. By doing this the structure of segment types gets extended. A new segment name is formed.

Version of an IDoc type: You may only add new segments. A new IDoc type is created. A new version of an existing segment alone does not lead to a new version of IDoc type.

Note for outbound processing: In the partner profiles the versions are listed as follows: IDoc type: By entering the IDoc type. Segment: By entering an SAP Release. This leads to the reduction of all segments which are used in the

IDoc type to an older version, that is, to the current version stated in the release. If the field remains empty, the current version of all segments relating to the current release is used.

Note for inbound processing: No settings are necessary or possible. The IDoc Interface recognizes the version and processes the data accordingly.

(C) SAP AG BC621 8

2.9

SAP AG 1999

ABAP Programming Names

Control record, EDIDC

Status record, EDIDS & EDI_DS

Data records, EDIDD, displayed as a segment tree

E1TLSUM

E1HDADR

E1ITSCH

E1HDDOC

E1ITDOC

Parent segment

Child segment

E1ITSCH

C 5

E1ITDOC

M 1

C 99

M 1

C 5

C 1

"IDoc Type"

ABAP programming exclusively uses the segment types of the segments, for example in the TABLES statement.

Segment types implemented in the SAP standard system start with prefix "E1".

(C) SAP AG BC621 9

2.10

SAP AG 1999

Subsystem Names

Control record, EDI_DC40

Status record, EDI_DS40

Data records, displayed as a segment tree

E2TLSUM000

E2HDADR000

E1ITSCH

E2HDDOC000

E1ITDOC

Parent segment

Child segment

E2ITSCH000

C 5

E2ITDOC000

M 1

C 99

M 1

C 5

C 1

"IDoc Type"

The segment names of the segments are exclusively visible by the subsystem. Segment names implemented in the SAP standard system start with prefix "E2".

(C) SAP AG BC621 10

2.11

SAP AG 1999

IDoc Definition Tools

IDoc Type Editor

WE30

E1HDDOCSegment editor

WE31

Design and definition of IDoc types and their segments are supported by the IDoc definition tools through the following:

Testing of the formal design rulesSimple 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

SAP AG 1999

When is Which Action Necessary?

The IDoc type required is available and meets all requirements:

No action needed!

The IDoc type required is present but does not meet all requirements:

Action: Customer extension!

The IDoc type required is not available or it is present but does not meet all the requirements:

Action: Development!

The customer extension, that is, the development of an extension does not represent a modification. Since all actions are captured in their own namespace, the extension can automatically be expanded to new versions of the extended IDoc type.

The customer development is totally independent of the standard. The necessary processes can easily be activated as table entries using the process codes.

(C) SAP AG BC621 12

2.13

SAP AG 1999

An IDoc type is a complex data structure composed of segments.

Segment types are structures in the ABAP data repository.

IDoc types and their processing can be extended in the appropriate positions by customers.

Summary

(C) SAP AG BC621 13

3

SAP AG 1999

Extension of the data structure

Extension of Outbound Processing

Extension of Inbound Processing

Extension of an IDoc Type

We will take a look at the outgoing orders process (Enterprise A is placing an electronic order with Vendor B) as well as the incoming customer order process (order being electronically processed by the customer service department of Vendor B).

The course uses a sample IDoc type (ORDLGT01) for purchase orders and sales orders. This IDoc type only consists of a segment for the document header and the item. The course does not correct any errors in order to emphasize all important aspects of the IDoc type extensions.

The IDoc type ORDLGT01 with logical message ORDLGT does not support transmission of specialist's name or delivery conditions. In this lesson, this information will be added to the IDoc type.

(C) SAP AG BC621 1

3.2

SAP AG 1999

Create IDoc Segment

Extend an IDoc Type

Implement a customer exit in outbound processing

Implement a customer exit in inbound processing

Course Objectives

(C) SAP AG BC621 2

3.3

SAP AG 1999


Implementation

33

Development environment forIDoc types

Extension of an IDoc type

Development of IDoc type

(C) SAP AG BC621 3

3.4

SAP AG 1999

The coding provided in the standard system for processing is used.

Developments and corrections of the coding delivered in the standard system are therefore automatically available.

Extension is less time consuming than new development.

Advantages of Customer Enhancement

(C) SAP AG BC621 4

3.5

SAP AG 1999

Additional customer fields are recorded in their own customer segments.

Customer segments depend on SAP segments (successor or child relationships).

The processing of customer segments is exclusively implemented in the customer exits of the coding provided in the standard system.

Basic Rules for Customer Extension

(C) SAP AG BC621 5

3.6

SAP AG 1999

Function Module

Program

Report

Business Workflow

Function Module

IDoc Interface

Application

Segment Type

Segment

IDoc Type

Segment Name

Data structure in the WEDI area menu

Outbound and inbound processing: Typically through transaction "CMOD", otherwise through individual technique

Documentation: In the WEDI area menu

Areas of Customer Extension

(C) SAP AG BC621 6

3.7

SAP AG 1999

Combine the required fields and their data types in the dictionary.

Definition of required segments,segment editor.

Definition of extension, IDoc type editor.

Assignment of a logical message to the IDoc type, surrounding field menu of IDoc type editor.

Steps For Extending the Data Structure

In the segment editor you assign a name to each field and enter a data element that describes the field in the application (documentation). The editor calculates the necessary character length of the field in the segment from the data element.

Segment editor, transaction WE31. In the IDoc type editor you build a complex data structure from the single segments. There you

determine the order and the hierarchical relationship of the segments. In addition, you assign a status (optional/mandatory) as well as the number of repetitions per segment and segment group.The IDoc API tests that the generated program (outbound processing: SAP processing, inbound processing: subsystem) conforms to these characteristics. Violations of these characteristics are recorded through the IDoc status syntax error (outbound: “26”, inbound processing: “60”).

IDoc type editor, transaction WE30.

(C) SAP AG BC621 7

3.8

SAP AG 1999

Definition of a project,project management, attribute

Choosing the "correct" customer exits,project management, SAP extensions

Implementation of the selected customer exits, project management, extension components

Outbound processing: reading of the SAP database and data in "IDoc format"

Inbound processing: writing data from the "IDoc format" into the SAP database

Activate project in project management

Steps for Extending Processing

Project management, transaction CMOD, radio button Attribute.Enter a project name and select Create.Enter short text and select Save.Choose SAP Extensions.

Project management, transaction CMOD, radio button SAP Extensions.Find customer exit through the development class (F4 Help).Select the required SAP extensions and choose Copy.Select Save and return to the initial screen of the transaction (F3).

Project management, transaction CMOD, radio button Extension components.Select Change.Position the cursor on a component and choose Edit component.Double-click the include in the program editor and follow the instructions in the window. Before saving the program, don't forget syntax testing.Activate the project after returning to the initial screen of the transaction.

(C) SAP AG BC621 8

3.9

SAP AG 1999

Output Documentation of the Extension

Begin

…

End

typedefine struct edi_dc

{…}

edi_dc

XML

The documentation tools are started from the initial node of the IDoc Interface by selecting Documentation. In addition, the parser output format has its own menu point for record types as well as IDoc types.

Automatic formats are:Simple, readable with a parser begin..end-Declaration sequence.C-header.Meta IDoc from type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types).Meta data for IDocs in XML format.

Navigation-compatible formats are:The tree display in the R/3 System.HTML file (three files, the *_ f-file is the frame that should be loaded by the browser and the index *_i and actual documentation *_d).

Documentation, IDoc record types: Transaction WE61 Documentation, IDoc types: Transaction WE60 Documentation, IDoc type (parser): Transaction WE63

(C) SAP AG BC621 9

3.10

SAP AG 1999

An extension can be limited to processing.

Normally an extension encompasses the data structure as well as the processing.

Extended data structures can be communicated to the subsystem by the documentation tools.

Summary

(C) SAP AG BC621 10

3.11Erweiterung eines IDoc-Typs: ExerciseData Used in the Exercises

Training System: The instructor will inform you (for example I40)

Client: The instructor will inform you (for example 400)

User: BC621-nn

Password: KURS

Port: SUBSYSTEM of Type ”Data” (pre programmed)

Data Data in Training System Data in IDES System

Customer:

Material SH-100 SH-100

Vendor T-BILnn 1014

Purchasing Organization 1000 1000

Purchasing Group 001 001

Plant 1100 1100

Vendor:

Material SH-100 SH-100

Sold-to party T-BIKnn 1110

Order Type TA

Sales Organization 1020 1020

Distribution Channel 22 22

Division 00 00

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:

Recipient, Port: SAP<SID>, System ID of SAP system, for example SAPT80

Sender, Port: SUBSYSTEM

Sender, Partner Number: T-BIKnn

Sender, Partner Type: KU

Sender, Partner Function: AG

(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


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:






nn is the number of your group (from 01 to 18)

(C) SAP AG BC621 14


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.


(C) SAP AG BC621 15


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.


(C) SAP AG BC621 16



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


(C) SAP AG BC621 17



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






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



2-1 Program code for outbound processing extension:

1 *----------------------------------------------------------------------*2 * INCLUDE ZXDIXU023 *----------------------------------------------------------------------*45 data: h_e1head like e1head. " Exercise 267 pe_vbak621 = pi_vbak621.89 * Exercise 210 loop at pt_idoc_data_records11 where segnam = 'E1HEAD'.12 h_e1head = pt_idoc_data_records-sdata.13 if h_e1head-auart = 'NB'.14 pe_vbak621-auart = 'TA'.15 endif.16 endloop.

(C) SAP AG BC621 19



3-1 Program code for outbound processing extension:

1 *----------------------------------------------------------------------*2 * INCLUDE ZXDIXU013 *----------------------------------------------------------------------*45 data: k_e1head like e1head. " Exercise 367 loop at pt_idoc_data_records8 where segnam = 'E1HEAD'.9 * Exercise 310 k_e1head = pt_idoc_data_records-sdata.11 k_e1head-name = pi_ekko-ernam.12 pt_idoc_data_records-sdata = k_e1head.13 modify pt_idoc_data_records.14 endloop.

(C) SAP AG BC621 20


Topic: Extension of the Data Structure (IDoc Type)

4-1 Segment Z1INCOnn contains two fields:INCO1 with data element INCO1 in export length 3INCO2 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



5-1 Program code for outbound processing extension (extended INCLUDE from exercise 3):

1 *----------------------------------------------------------------------*2 * INCLUDE ZXDIXU013 *----------------------------------------------------------------------*45 data: k_e1head like e1head. " Exercise 36 data: k_z1inco like z1incodx. " Exercise 578 loop at pt_idoc_data_records9 where segnam = 'E1HEAD'.10 * Exercise 311 k_e1head = pt_idoc_data_records-sdata.12 k_e1head-name = pi_ekko-ernam.13 pt_idoc_data_records-sdata = k_e1head.14 modify pt_idoc_data_records.15 * Exercise 516 clear pt_idoc_data_records.17 clear k_z1inco.18 k_z1inco-inco1 = pi_ekko-inco1.19 k_z1inco-inco2 = pi_ekko-inco2.20 pt_idoc_data_records-segnam = 'Z1INCODX'.21 pt_idoc_data_records-sdata = k_z1inco.22 append pt_idoc_data_records.23 endloop.

(C) SAP AG BC621 22



6-1 Program code for inbound processing extension (extended INCLUDE from exercise 2):

1 *----------------------------------------------------------------------*2 * INCLUDE ZXDIXU023 *----------------------------------------------------------------------*45 data: h_e1head like e1head. " Exercise 26 data: h_z1inco like z1incodx. " Exercise 678 pe_vbak621 = pi_vbak621.910 * Exercise 211 loop at pt_idoc_data_records12 where segnam = 'E1HEAD'.13 h_e1head = pt_idoc_data_records-sdata.14 if h_e1head-auart = 'NB'.15 pe_vbak621-auart = 'TA'.16 endif.17 endloop.1819 * Exercise 620 loop at pt_idoc_data_records21 where segnam = 'Z1INCODX'.22 h_z1inco = pt_idoc_data_records-sdata.23 pe_vbak621-inco1 = h_z1inco-inco1.24 * pe_vbak621-inco2 = h_z1inco-inco2.25 pe_vbak621-inco2 = ‘Test BC621-DX’.26 endloop.

(C) SAP AG BC621 23

4

SAP AG 1999

Development of the data structure

Processing example

Development of IDoc Type

(C) SAP AG BC621 1

4.2

SAP AG 1999

Create IDoc segments

Develop new IDoc types

Template for IDoc outbound processing

Template for IDoc inbound processing

Topic Objectives

(C) SAP AG BC621 2

4.3

SAP AG 1999

Implementation

44

Development environment for IDoc types

Extension of an IDoc type

Development of IDoc type


(C) SAP AG BC621 3

4.4

SAP AG 1999

Segments are formed as logical units based on the (application) fields. They are reusable "modules" of IDoc development.

Segment groups are formed as logical units from segments.

IDoc types are derived from segments and segment groups.They are the data structure of an application document for the transmission.

During development IDoc types are created as basic IDoc types.

The business process itself is not identified through an IDoc type, but rather through the logical message.

Basic Rules for Development

In the segment editor you assign a name to the field and enter a data element that describes the field in the application (documentation). The editor calculates the necessary character length for the field using the data element. Examples: Logical unit segment:

• An address consists of the fields street, postal code and city.• Contact person consists of the field's first name, last name and telephone number.

Logical unit of segment group:• A company address consists of an address (logical unit segment) as well as several contact persons (logical unit segment) in this company.

You build a complex data structure from the single segments in the IDoc type editor. There you determine the order and the hierarchical relationship of the segments. In addition, you assign a status (optional/mandatory) as well as the number of repetitions per segment and segment group.The IDoc API tests that the generated program (outbound processing: SAP processing, inbound processing: subsystem) conforms to these characteristics. Violations of these characteristics are recorded through the IDoc status syntax error (outbound: 26, inbound 60).

(C) SAP AG BC621 4

4.5

SAP AG 1999

Application

Function Module

Program

Report

Business Workflow

Function Module

IDoc Interface

Segment Type

Segment

IDoc Type

Segment Name

Data structure: in the WEDI area menu

Outbound and inbound processing: in the Object Browser "SE80"

Documentation: in the WEDI menu

Areas of Development

(C) SAP AG BC621 5

4.6

SAP AG 1999

Combine the required fields and their data types in the dictionary

Definition of required segments,segment editor

Definition of basic IDoc types,IDoc type editor

Creation of a logical message, surrounding field menu of IDoc type editor

Assignment of a logical message to the IDoc type, surrounding field menu of IDoc type editor

Steps for the Development of a Data Structure

In the segment editor you assign a name to the field and enter a data element that describes the field in the application (documentation). The editor calculates the necessary character length for the field using the data element.

Segment editor, transaction WE31. You build a complex data structure from the single segments in the IDoc type editor. There you

determine the order and the hierarchical relationship of the segments. In addition, you assign a status (optional/mandatory) as well as the number of repetitions per segment and segment group.The IDoc API tests that the generated program (outbound processing: SAP processing, inbound processing: subsystem) conforms to these characteristics. Violations of these characteristics are recorded through the IDoc status syntax error (outbound: 26, inbound 60).

IDoc type editor, transaction WE30.

(C) SAP AG BC621 6

4.7

SAP AG 1999

Outbound processing using

Message Control (MC) ?

ALE Interface (FM MASTER_IDOC_DISTRIBUTE)?

Inbound processing using

Business Workflow (single step or multistep task) ?

ALE Interface (function module) ?

Processing Types

(C) SAP AG BC621 7

4.8

SAP AG 1999

Steps for Development of Outbound Processing using MC

Checking Message Control, that is, the connection for the message default:

Condition table

Access sequence

Condition types

Procedure

Application

Implementation of a function module that makes application data available in "IDoc format"

Definition of an outbound process code

The function module must adhere to the following interface:Import OBJECT like MCCONTROL_RECORD_IN like EDIDCExport OBJECT_TYPE like WFAS1-ASGTPCONTROL_RECORD_OUT like EDIDCTables INT_EDIDD like EDIDDExceptions 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

SAP AG 1999

Implementation of a program that calls the function module MASTER_IDOC_DISTRIBUTE. Interface

Import MASTER_IDOC_CONTROL like EDIDC

Tables COMMUNICATION_IDOC_CONTROL like EDIDC MASTER_IDOC_DATA like EDIDD

For this program you have to define how the control works, specifically, if the control is to take place via a time table, event or dialog step.

Development Steps for Outbound Processing using the ALE Interface

The function module MASTER_IDOC_DISTRIBUTE has the following interface: Import MASTER_IDOC_CONTROL like EDIDC

OBJ_TYPE like SERIAL-OBJ_TYPECHNUM like SERIAL-CHNUM

Tables COMMUNICATION_IDOC_CONTROL like EDIDCMASTER_IDOC_DATA like EDIDD

Exceptions ERROR_IN_IDOC_CONTROLERROR_WRITING_IDOC_STATUSERROR_IN_IDOC_DATASENDING_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

SAP AG 1999

Development Steps of Inbound Processing using Business Workflow

Implementation of a workflow to control inbound processingThis includes:

Definition of object and method(s) in BOR

Definition of workflow

Definition of inbound process code

BOR - Business Object Repository, transaction SWO1 (Business Object Builder). Workflow, transaction PFTC until 4.0B, from 4.5 on transactions PFTC_INS, PFTC_CHG and

PFTC_DIS. Inbound process code, transaction WE42. For an example, see the appendix.

(C) SAP AG BC621 10

4.11

SAP AG 1999

Write function module that posts the IDoc as an application document

Implementation of a workflow to send messages in case of error. This includes:

Definition of object and method(s) in BOR

Definition of workflow

Maintenance of the characteristics for the function module for the ALE Call

Allocation of the function module to a logical message and to an IDoc type for the ALE Call

Definition of an inbound process code and establishing a connection with the ALE layer

Development Steps for Inbound Processing using ALE Interface

Post application document: Function module, transaction SE80. Case 1: The function module uses an internal CALL TRANSACTION which triggers a COMMIT. In this

case you must display the ALE layer in the transaction BD51. The transaction uses internal function modules IDOC_INPUT_OPEN and IDOC_INPUT_CLOSE, in order to write the IDoc status within the LUW. In case of an error, foreground processing is possible using such a function module.

Case 2: The function module uses internal APIs (Programming Interfaces) and does not release a COMMIT. In case of an error, foreground processing is not possible using such a function module.

Notification in case of error:BOR - Business Object Repository, transaction SWO1 (Business Object Builder).Workflow, transaction PFTC until 4.0B, from 4.5 on, transactions PFTC_INS, PFTC_CHG and PFTC_DIS.

Maintaining the characteristics of the function module: You must make the (technical program) characteristics of the function module called by ALE known to the ALE layer, by using transaction BD51.

Assignment of the function module: The allocation of a function module to a business process, called by ALE, has to be executed via transaction WE57.

Inbound process code and ALE Connection: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

SAP AG 1999

Output Documentation of New Development

Begin

…

End

typedefine struct edi_dc

{…}

edi_dc

XML

The documentation tools are started from the initial node of the IDoc Interface by selecting Documentation. In addition, the parser output format has its own menu point for record types as well as IDoc types.

Automatic formats are:Simple, readable with a parser begin..end-Declaration sequence.C-header.Meta IDoc from type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types).Meta data for IDocs in XML format.

Navigation-compatible formats are:The tree display in the R/3 System.HTML file (three files, the *_ f-file is the frame that should be loaded by the browser and the index *_i and actual documentation *_d).

Documentation, IDoc record types: Transaction WE61 Documentation, IDoc types: Transaction WE60 Documentation, IDoc type (parser): Transaction WE63

(C) SAP AG BC621 12

4.13

SAP AG 1999

The data structure is defined as an IDoc type

Depending on the processing course and direction, different programming templates can be used

Outbound uses 2 methods:Message Control and ALE

Inbound uses 2 methods:Workflow and ALE

Summary

(C) SAP AG BC621 13

5Appendix

5.2.2Glossary

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.

(C) SAP AG BC621 1

IDoc interface Definition of formats (IDoc types, previously: intermediate structures) and methods (port definitions) for electronic data exchange between SAP Systems and partner 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

(C) SAP AG BC621 2

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

5.2.3Important 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 4

5.3Examples for Unit 4

5.3.2Examples "Steps for development of outbound processing using MC":

5.3.3Purchase order, MM

IDoc type ORDERS01

Logical message ORDERS

Function module IDOC_OUTPUT_ORDERS

Outbound process code: ME10

5.3.4

5.3.5Order confirmation, SD

IDoc type ORDERS01

Logical message ORDRSP

Function module IDOC_OUTPUT_ORDRSP

Outbound process code: SD10

5.3.6Inbound process code: TXT1

5.3.7Example "Development steps of inbound processing by Business Workflow": Text message, inbound

IDoc type: TXTRAW01

Logical message: TXTRAW

Object with method: IDOCTXTRAW.MAILCREATE

One-step task: TS30000008

Inbound process code: TXT1

5.3.8

5.3.9Examples "Development steps for inbound processing using ALE Interface"

5.3.10Customer order, SD

Transaction VA01

IDoc type ORDERS01

Logical message ORDERS

Function module IDOC_INPUT_ORDERS

Inbound process code ORDE

Object with method IDOCORDERS.INPUTFOREGROUND

One-step task 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

5.3.11Order acknowledgment, MM

IDoc type ORDERS01

Logical message ORDRSP

Function module IDOC_INPUT_ORDRSP

Inbound process code ORDR

Object with method IDOCORDRSP.INPUTFOREGROUND

One-step task TS00008075

This function module uses APIs (not a transaction) and does not start a COMMIT WORK (case 2 on the slide). If errors occur, foreground processing is not possible.

(C) SAP AG BC621 6

Documents

BC621 - SAP IDoc Interface Development)