56210370 BC621 SAP IDoc Interface Development
Post on 31-Oct-2014
48 Views
Preview:
Transcript
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
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 withoutthe express permission of SAP AG. The information contained herein may be changed without prior notice.
All rights reserved.
Copyright
Trademarks: Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered
trademarks of Microsoft Corporation. IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®,
AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide 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 sichalso ü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
Course Overview Diagram
(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
rocessing
Inbound 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
Segment nameE2ccccc001Segment nameE2ccccc001
Segment nameE2ccccc013Segment nameE2ccccc013
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
Course Overview Diagram
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
Unit: Extension of an IDoc Type
Topic: Extension of Inbound Processing
• Get to know project management
• Be able to write program code for inbound processing.
2-1 Extend the inbound processing of IDoc type ORDLGT01 to avoid errors status “51”. Change the received error document type NB in one of the customer exits to document type TA expected by the sales order. There is no need to extend the IDoc type.
2-2 Create the Project BC621-nn in the project administration (transaction CMOD). Select the SAP extension BC621Enn for the project. Write the extension code in the inbound component.
2-3 Now activate your project.
2-4 Repeat the inbound sales order process with the help of the test program Inbound modified outbound file derived from the already created purchase order.Enter the following values on the tab page Sender:
Recipient, Port: SAP<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
nn is the number of your group (from 01 to 18)
(C) SAP AG BC621 14
Unit: Extension of an IDoc Type
Topic: Extension of Outbound Processing
• Get to know project management
• Be able to write the program code for outbound processing
In exercise 1 the field for Specialist name remained blank, even though it was defined in the IDoc type. Since it has been agreed with your partner to transfer the field, you decide to take care of the field through a customer exit. There is no need to extend the IDoc type.
3-1 Change the Project BC621-nn in the project management (transaction CMOD) or create it for the first time (if you have not completed exercise 2). Select the SAP extension BC621Enn for the project. Write the program code in the extension component for the outbound processing.
3-2 Activate your project.
3-3 Now repeat the purchase order through Logistics -> Materials management -> Purchasing -> Purchase order -> Create -> Vendor known (transaction ME21) to your vendor T-BILnn for methanol, material number SH-100.
3-4 Change to Purchase order → Display. You can display the IDoc that was just generated from the overview screen by choosing System → Links. Check that the field has now been filled with the user name.
Note: The number of filled fields is displayed in the bottom right area of the detail display of a data record. It has increased to 8.
nn is the number of your group (from 01 to 18)
(C) SAP AG BC621 15
Unit: Extension of an IDoc Type
Topic: Extension of the Data Structure (IDoc Type)
• Know how to use IDoc type editor
Your IDoc type ORDLGT01 does not contain any fields in order to transfer the document header delivery conditions. You have to extend the data structure, that is, the IDoc type, since delivery conditions have been agreed to with your partner.
4-1 First define the customer segment Z1INCOnn in the segment editor. Customer segment Z1INCOnn is to contain application fields INCO1 and INCO2. In the application both fields INCO1 and INCO2 are contained in the structure EKKO.
4-2 In the segment editor, test that your definition is correct. Ignore the warning that the segment has not yet been released.
4-3 Define the extension ZEXTENnn in the IDoc type editor. Extend the basic IDoc type ORDLGT01 by segment Z1INCOnn.
4-4 Add to the logical message ORDLGT the basic type ORDLGT01 with the extension ZEXTENnn in the IDoc type editor.
4-5 In the IDoc type editor, test that your definition is correct. Ignore the warning that the IDoc type as well as the segment Z1INCOnn has not yet been released.
nn is the number of your group (from 01 to 18)
(C) SAP AG BC621 16
Unit: Extension of an IDoc Type
Topic: Extension of Outbound Processing
• Revise project management
• Revise programming of outbound processing
After you have completed exercise 4, extending the customer segment Z1INCOnn of the IDoc type, in order to transfer the delivery conditions, you now have to enter the delivery conditions in the customer segment in a customer exit.
5-1 Change the Project BC621-nn in the project management (transaction CMOD) or create it for the first time. Select the SAP extension BC621Enn for the project. Write the program code in the extension component for the outbound processing.
5-2 Activate your project.
5-3 In partner agreement for vendor T-BILnn, in the outbound parameter table change the IDoc type from basic IDoc type ORDLGT01 to extension ZEXTENnn.
5-4 Now repeat the purchase order through Logistics -> Materials management -> Purchasing -> Purchase order -> Create -> Vendor known (transaction ME21) to your vendor T-BILnn for methanol, material number SH-100.
5-5 Change to Purchase order → Display. You can display the IDoc that was just generated from the overview screen by choosing System → Links. Check if customer segment Z1INCOnn was created and filled. The IDoc has status 03, that is a file was generated.
nn is the number of your group (from 01 to 18)
(C) SAP AG BC621 17
Unit: Extension of an IDoc Type
Topic: Extension of Inbound Processing
• Revise project management
• Revise programming of input process
In exercise 4, after you extended IDoc type with customer segment Z1INCOnn. In order to receive the delivery conditions, you need to read the customer segment with delivery conditions in the customer exit and this needs to be transmitted to the input process (BDC).
Exercise 5 is a prerequisite for this exercise.
6-1 Change the Project BC621-nn in the project management (transaction CMOD). Write the program code in the extension component for the outbound processing.
6-2 Activate your project.
6-3 Repeat the inbound sales order process with the help of the test program Inbound modified outbound file derived from the already created purchase order.Enter the following values on the tab page Sender:
Recipient, Port: SAP<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
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 * 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
Unit: Extension of an IDoc Type
Topic: Extension of Outbound Processing
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
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 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
Unit: Extension of an IDoc Type
Topic: Extension of Outbound Processing
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
Unit: Extension of an IDoc Type
Topic: Extension of Inbound Processing
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
Course Overview Diagram
(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
Glossary
Access An access identifies the document fields used by the system when searching for a condition record.
Access sequence Sequence used by Message Control to access condition records when searching for messages.
Basic type IDoc type supplied by SAP. Basic types can be modified by customers to create a new, upward-compatible IDoc type.
Condition element Part of hierarchy which is examined when searching for a message. An example is the output type which is at the top of this hierarchy: When a (new) purchase order is posted, only the messages under the node for the message type NEW are searched.
Condition record Data record in which the key fields represent the condition under which the message is "found". The remaining fields describe the message itself. Therefore, if one of the data records transferred from the application matches these key fields, the message is found and can then be processed (for example exported as a print form or as an electronic message).
Control record The part of an IDoc which contains the data for identifying the sender and recipient, as well as the structure of the IDoc itself. Each IDoc always has one control record.
Data record The part of an IDoc which contains the application data. An IDoc usually contains more than one data record.
EDI = Electronic Data Interchange. EDI (for example of business documents) between business partners, sometimes in separate countries, who may use different hardware, software and communication services. The data is formatted according to specific standards.
EDI message Standard format for a business process (for example, a purchase order) to be handled by EDI. Various EDI standards (EDIFACT or ANSI X12) can define different EDI messages for the same business process.
EDI standard General format for data to be transferred electronically. An EDI standard generally comprises:
o EDI syntax
o Data element service
o Message type service
The SAP standard 'IDoc' is not yet an EDI standard, but can be compared to other EDI standards.
EDI subsystem System which converts the SAP standard IDoc into an EDI standard (for example EDIFACT, ANSI X12) and vice versa. In addition to this task (which is carried out by the EDI subsystem convertor), there are also administration activities, for example, archiving the transferred messages, and technical tasks, for example, technical connection to the subsequent system and syntax checks for formats, to be considered.
Field catalog Contains all fields which can be selected as key fields for condition tables in Message Control.
File interface = port type “file”
Hierarchy level Determines the position of a segment in a tree segment. A segment carries business data in an IDoc. Dependencies in the application data can be represented in this tree structure, that is, the various hierarchy levels.
IDoc interface Definition of formats (IDoc types, previously: intermediate structures) and methods (port definitions) for electronic data exchange between SAP Systems and partner
(C) SAP AG BC621 1
systems.
IDoc type SAP format in which data for a business process is to be transferred. An IDoc is a real business process formatted according to a certain IDoc type.
Inbound processing Conversion and processing of data for a business process from the time the data is received in IDoc format to the posting of the corresponding document(s) in the SAP application.
Mandatory segment The part of an IDoc type which contains important application data and must therefore exist in an IDoc for an actual business process.
Mapping Rules for assigning the data elements of an EDI message type to the fields of an IDoc type.
Message Business process (for example, a purchase order), which is transferred in IDoc format between an SAP System and an external system.
Message Control Module designed to offer interfaces for further processing for applications. This includes descriptions of the various data configurations and the required actions. An example of an action is printing a document at a certain time in German. The action is triggered when the application transfers data which matches your configuration.
Message determination A check to determine whether the application data matches the condition records (specified in Customizing). If this is the case, one or more messages are "found" and can then be processed (for example, sent electronically). In message determination, a search is made for the condition records using a predefined hierarchy.
Message status record = MC record. Log record for the MC table which describes the send status of a message in Message Control.
Notification If an error occurs (for example, an IDoc with incorrect syntax), a notification is sent to one or more users. The users responsible are defined in the IDoc Interface or indirectly via the organization model. Notifications are sent to the integrated inbox.
Optional segment Part of an IDoc type which can include additional, optional data about the business process. The segment does not therefore have to appear in an IDoc for a specific business process.
Outbound file Contains specific IDocs to be sent for port type “file”.
Outbound processing Conversion and processing of SAP document data from posting a document to sending the data in IDoc format.
Partner Communication partner for the IDoc Interface. Definition from Sales and Distribution: "An individual within or outside of your own organization who is of commercial interest and who can be contacted in the course of a business transaction".
Partner profile Definition of the general conditions for electronic data interchange with a business partner via the IDoc Interface: which message is sent in which direction using which method?
If a partner profile does not exist, communication with a partner via the IDoc Interface is not possible.
Port Description of the channel used by the SAP system for communicating with the external system during external data interchange. There are various technical methods for implementing this type of communication (port types). The selection of the port type depends on the technical configuration of the external system. Example: Most EDI subsystems read IDocs in the form of sequential files, that is, the port type 'file' is used.
Procedure A group of messages. A procedure is searched for messages which are to be processed for the specified data configuration (for example, sent electronically or printed).
Process code Another name for a defined processing type, for example a function module or an SAP Business Workflow task. In contrast, a defined IDoc type (standard format for data communication) is usually assigned to a certain process code. If the process type for this IDoc type is to be changed, you should assign the corresponding process code to the new processing type. Without this process code, this IDoc type
(C) SAP AG BC621 2
must be assigned to the new processing code directly.
Record type An IDoc type consists of the following three record types:
- Control record
- Data record
- Status record
Segment Structure which includes the application data for an IDoc from the data records. As a result, the data can be assigned to the correct application fields.
Status Processing status of an IDoc, either "generated" or "ready for sending".
An IDoc usually has several statuses which are stored in the status records and reveal information about the IDoc history. The current (processing) status is also stored in the control record for the IDoc.
Status confirmation Report from an external system about the processing status of business data received from the R/3 System in the form of status records. The status confirmation is added to the IDoc in the R/3 System in the form of status records.
Status file File which contains the status records sent to the IDoc Interface by the EDI subsystem for outbound messages.
Status group The status group contains several statuses ("milestones" in the process chain), so that the monitoring programs only have to consider these groups and not each individual status. Examples:
Group 3 = outbound: IDoc in the external system
Group B = inbound: IDoc sent to the application
Status record One of three record types in an IDoc (SAP standard format for electronic exchange of application data).
Each status record contains a status which corresponds to one step in IDoc processing. This means that the number of status records increases as the processing continues.
Translator Converts internal data formats (IDocs) into EDI messages and vice versa. The translator is a component of the EDI Subsystem.
Transmission file A data packet which contains the messages to be exchanged electronically. The messages are EDI messages, that is, they are formatted according to an EDI standard (for example EDIFACT).
The conversion of the SAP standard IDoc into the EDI standard is carried out by an external system (EDI subsystem).
(C) SAP AG BC621 3
Important Menu Paths
ALE Registration
IDoc initial node: Development→Message/Application object
Archiving
Tools→Administration, Administration→Data archiving
Maintaining Archiving Status
IDoc initial node: Control→Maintain status values
IDoc Administration
IDoc initial node: Control→IDoc Administration
Display IDoc
IDoc initial node: IDoc→Display IDoc
IDoc Initial Node
Tools→Business Communication, IDoc→IDoc Basis
IDoc Statistics
IDoc initial node: IDoc→IDoc Statistics
IDoc Type Editor
IDoc initial node: Development→IDoc types
Partner Profile
IDoc initial node: IDoc→Partner profile
Port Definition
IDoc initial node: IDoc→Port Definition→Maintain RFC destination
IDoc initial node: IDoc→IDoc destination
Segment Editor
IDoc initial node: Development→IDoc segments
Processing Tests
IDoc initial node: Test→<menu option according to the required function>
Message Allocation – IDoc Type
IDoc initial node: Development→IDoc type/message
(C) SAP AG BC621 4
5.2Examples for Unit 4
Examples "Steps for development of outbound processing using MC":
Purchase order, MM
IDoc type ORDERS01
Logical message ORDERS
Function module IDOC_OUTPUT_ORDERS
Outbound process code: ME10
Order confirmation, SD
IDoc type ORDERS01
Logical message ORDRSP
Function module IDOC_OUTPUT_ORDRSP
Outbound process code: SD10
Inbound process code: TXT1
Example "Development steps of inbound processing by Business Workflow": Text message, inbound
IDoc type: TXTRAW01
Logical message: TXTRAW
Object with method: IDOCTXTRAW.MAILCREATE
One-step task: TS30000008
Inbound process code: TXT1
Examples "Development steps for inbound processing using ALE Interface"
Customer order, SD
Transaction VA01
IDoc type ORDERS01
Logical message ORDERS
Function module IDOC_INPUT_ORDERS
Inbound process code ORDE
Object with method IDOCORDERS.INPUTFOREGROUND
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
Order 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
top related