BIT350
ALE Enhancements
Date Training Center Instructors Education WebsiteParticipant Handbook
Date: 2002/Q2Course Duration: 2 Day(s) Material Number: 50054652
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.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Trademarks
• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint®and SQL Server®are
registered trademarks of Microsoft Corporation.
• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®,
S/390®, AS/400®, OS/390®, and OS/400®are registered trademarks of IBM
Corporation.
• ORACLE®is a registered trademark of ORACLE Corporation.
• INFORMIX®-OnLine for SAP and INFORMIX®Dynamic ServerTM are registered
trademarks of Informix Software Incorporated.
• 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.
• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
The following typographic conventions are used in this guide.
Type Style Description
Example text Words or characters that appear on the screen. These include field names, screen titles,
pushbuttons as well as menu names, paths, and options.
Also used for cross-references to other documentation both internal (in this
documentation) and external (in other locations, such as SAPNet).
Example text Emphasized words or phrases in body text, titles of graphics, and tables
EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.
Example text Screen output. This includes file and directory
names and their paths, messages, names of variables and parameters, and passages of the source text of a program.
Example text Exact user entry. These are words and characters
that you enter in the system exactly as they appear in the documentation.
Icons in Body Text
The following icons are used in this handbook.
Icon Meaning
For more information, tips, or background Note or further explanation of previous point Exception or caution
Procedures
Indicates that the item is displayed in the instructor’s presentation.
Course Overview ... vii
Course Goals ...vii
Course Objectives ...vii
Unit 1: Enhancing ALE Scenarios: Overview ... 1
The ALE Process and Enhancement Possibilities...2
Unit 2: IDoc Processing: Technical Details ... 13
IDoc Types: Technical Details ... 14
ALE Process: Technical Details... 24
Unit 3: Adjusting a Scenario Using Field Conversion ... 53
Field Conversions ... 54
Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type ... 67
Adjusting a Scenario Without Enhancing the IDoc Type... 69
Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type ... 93
Defining an Enhancement for the IDoc Type ... 96
Enhancements in Inbound Processing...106
Enhancements in Outbound Processing: Adjusting the Master IDoc ...114
Test, Transport, and Customizing ...123
Enhancements for Customer Tables ...132
Unit 6: Optimization of ALE Processes ... 141
Package Processing ...143
Parallel Processing ...148
Serialization By Time Stamp ...156
This course describes the different technical options for enhancing a standard ALE scenario, including targeted analysis of ALE scenarios for enhancement possibilities. The course introduces different enhancement methods, which vary in the amount of time and effort required and in flexibility. The second part of the course explains the options for process optimization: parallelization, package processing, and serialization. The final section demonstrates how you can implement an ALE scenario for an existing BAPI.
Target Audience
This course is intended for the following audiences: • ABAP developers and consultants
Course Prerequisites
Required Knowledge
• ABAP knowledge (updates, enhancement methods), basic knowledge of creating an ALE scenario
Recommended Knowledge
• Basic knowledge of how to create an ALE scenario
Course Goals
This course will prepare you to:
• Enhance ALE business scenarios supplied by SAP in a distributed system landscape
Course Objectives
Unit 1
Enhancing ALE Scenarios: Overview
Unit Overview
This unit introduces different scenarios that are typical of enhancement requirements. You will become familiar with different methods, which vary in the amount of time and effort required, and in flexibility.
Unit Objectives
After completing this unit, you will be able to:
• Describe the levels on which you can enhance an ALE scenario, and which activities are required
Unit Contents
Lesson: The ALE Process and Enhancement
Possibilities
Lesson Overview
This unit provides an overview of the different technical options for enhancing an ALE scenario.
Lesson Objectives
After completing this lesson, you will be able to:
• Describe the levels on which you can enhance an ALE scenario, and which activities are required
Business Example
A standard ALE scenario supplied by SAP does not meet your specific requirements. You want an overview of the different technical options for enhancing a scenario.
Overview: ALE Process with Status Values
When you send an IDoc from a sending system to a receiving system, the IDoc passes through various statuses. Typical status values are summarized in figure 1.
From a technical point of view, the status changes are as follows:
• A master IDoc is generated in the application program. This internal table contains the data to be sent.
• The master IDoc is transferred to the ALE layer. In the ALE layer, the IDoc passes through various services. The IDoc is extended by the addition of the control record and saved to the database.
• The IDoc is sent. The exact time of sending depends on the Customizing settings. Either the IDoc is transferred to the communication layer and sent immediately, or the sending is triggered by a background process.
• The IDoc is saved to the database in the target system.
• The IDoc is transferred to the application. The exact time also depends on Customizing. Either the IDoc is transferred immediately by the ALE layer to the application, or the process is triggered by a background program. In the inbound function module of the application, an application document is generated using the data from the IDoc.
To enhance ALE scenarios, you need to consider the whole sending process. You want to make changes at a certain point in this process to adapt it to your requirements. In the first step, you therefore need to identify at which point you want to intervene, and to decide which changes are required. Then consider which method to use to realize your requirements.
The following overview diagram is used throughout the course when discussing each enhancement method.
Figure 2: ALE Process: Technical View
This diagram shows the components where activities can be performed to enable adaptation of the scenario. The next three sections show three different enhancement methods, and at which point in the process these intervene.
Adjustment by Field Conversion
Field conversion is a generic service of the ALE layer. It is possible to replace field values in a segment with constants or simple variables. This method is suitable, for example, for converting German umlauts into internationally-recognized character combinations, or for the process known asα-conversion, which adds initial zeros to numeric strings.
Figure 3: Adjustment by Field Conversion
Only Customizing settings are required for field conversion. In this case, you do not need to program any ABAP code.
Adjustment Without Enhancing the IDoc Type in the
Program
For more complex changes, you can insert program enhancements into the application programs that generate an IDoc on the sender side, and write the content of the IDoc in application database tables on the receiving side. In this scenario, it is assumed that you do not need to send additional fields. The IDoc type therefore does not need to be enhanced.
Figure 4: Adaptations by Program Enhancements
The positions at which the ALE process has been modified are shown in bold in figure 4.
Adjustment With Enhancement of the IDoc Type
If you want to transfer additional fields, you can enhance the IDoc type. This is necessary, for example, if you have extended a standard SAP database table using an append structure by adding a few of your own columns, and you want to send this information to the target system using the ALE scenario supplied.
Figure 5: Adjustment with Enhancement of the IDoc Type
In this case, both Customizing settings and ABAP programming are required.
Lesson Summary
You should now be able to:
• Describe the levels on which you can enhance an ALE scenario, and which activities are required
Unit Summary
You should now be able to:
• Describe the levels on which you can enhance an ALE scenario, and which activities are required
Test Your Knowledge
1. If you want to enhance an ALE scenario and also transfer additional fields, you can use the following method(s):
Choose the correct answer(s). A Field conversion
B Program enhancement without enhancing the IDoc type C Program enhancement with enhancement of the IDoc type D Enhancement of the IDoc type without program
Answers
1. If you want to enhance an ALE scenario and also transfer additional fields, you can use the following method(s):
Answer: C
For additional fields to be transferred, they must be contained in the IDoc type. Enhancing the IDoc type by adding a customer segment enables the IDoc to accept your additional fields. The segment must, however, be filled in the outbound program and inserted into the master IDoc. You can achieve this using a program enhancement.
Unit 2
IDoc Processing: Technical Details
Unit Overview
This unit describes the implementation of ALE scenarios. This includes: • The definition of an IDoc type and the segment types used in the
IDoc type
• The tools you can use to analyze and enhance IDoc types • The tools you can use to analyze and create segment types • Programming outbound processing in the sender system • Programming inbound processing in the receiver system
Unit Objectives
After completing this unit, you will be able to: • Create a customer segment
• Analyze IDoc types
• Analyze the outbound and inbound programs of an ALE scenario • Identify enhancement possibilities
Unit Contents
IDoc Types: Technical Details ... 14
Procedure: Creating a Segment Type... 19
Exercise 1: Creating a Segment Type... 21
ALE Process: Technical Details... 24
Lesson: IDoc Types: Technical Details
Lesson Overview
If you want to enhance an ALE scenario, or if the IDoc field does not contain the expected value, you will normally need to analyse the IDoc type. This lesson contains detailed information on the structure of segments, the corresponding field types, and IDoc types.
Lesson Objectives
After completing this lesson, you will be able to: • Create a customer segment
• Analyze IDoc types
Business Example
The users responsible for an application have noticed that some
information that they have entered in the sending system is missing in the target system. An ALE distribution scenario exists that uses a particular message type and the corresponding IDoc type. You discover that the IDoc type does not transfer all the required information. You now want to check whether the IDoc type contains fields for the missing information. If it does, an enhancement is possible using field conversion or a program enhancement. If it does not, you need to enhance the IDoc type using a segment you have defined yourself.
Structuring an IDoc Type
If a business process is distributed between two SAP systems, information can be exchanged using an IDoc (Intermediate Document). The structure of an IDoc is described by the IDoc type. An IDoc type contains information such as which data is stored in which position (line and offset). The IDoc type is assigned to a message type. While the message type only contains the semantics of a message (such as material master data), the IDoc type for a message contains the exact structure of the document. The following figure shows a section of the IDoc typeMATMAS03(simplified version) .
Figure 7: The IDoc Type: Basic Structure
The IDoc type for a message type determines which application data belongs to a message, and in what order. The data is organized in rows. A segment type determines the structure of the individual rows. The segments can be hierarchically related to one another.
To display the IDoc type with documentation, choose SAP Menu→ Tools → Business Communication → IDoc Basis → Documentation → IDoc Types (transaction code WE60). A tree diagram representing the segments and their hierarchical relationships is displayed.
Hint: In transaction WE60 (documentation for an IDoc type), you
can specify which elements of the documentation you want to display. To make this setting for the whole IDoc type, choose Goto→ User Settings.
You can also choose the following icons for each segment: IDoc
type / Attributeson / off IDoc type long text, release,display release, record type versions
Seg-ment type
/ Attributes
on / off Segment type long text,external name of segment type with segment version, release, required or optional segment, minimum and maximum repetition / Docu-mentation on / off Segment documentation is displayed or hidden Seg-ment field / Attributes
on / off Internal format: Type,length, and name of the data element; external format: Length of character field; Offset of the first character in the segment
/
Docu-mentation on / off
Data element documentation
Figure 8: The IDoc Type: Detailed Information
Hint: An IDoc type for a message type can be enhanced for
compatibility with a new release. (similar to the interfaces of an ABAP function module). There can therefore be different IDoc types for one message type. Choose the IDoc type recognized in the relevant system that has the lowest release status. Each IDoc type contains information on its successor and its predecessor.
Hint: An IDoc does not have to contain all segments, and a
segment type can have more than one segment. Whether an IDoc must contain a particular segment, and how many segments are permitted for a segment type, is determined in the IDoc type. For more information, see the figure: IDoc Type: Detailed Information. The IDoc types supplied by SAP are known as basic types. Basic types can be combined with customer-defined enhancements according to strict rules.
Structure of a Segment Type
The segment type describes the row structure of a segment. The semantics and technical attributes are determined for each field. The semantics are determined by assigning a data element from the ABAP Dictionary to each segment field. The technical attributes are derived from the technical attributes of the data element. The
So that a structured field can be defined using the structure of a segment type in the inbound and outbound programs, a structure of the same name is generated in the ABAP Dictionary for each segment type.
Figure 9: A Segment Type
Creating a Segment Type
1. Start the segment editor
To do this, choose SAP Menu→ Administration → Business Communication→ IDoc Basis→ Development → IDoc Segments (=transaction WE31).
2. Enter a name according to the naming conventionZ1<segmentname>.
3. For each field, enter a field name and a corresponding data element in the ABAP Dictionary. This data element should have the same internal format and semantics as the field.
4. Choose Continue.
The length of the external format is automatically calculated. Correct this length if necessary.
5. When you have inserted all the fields, save the segment type. Assign a development class and a transport entry to the segment type. When you save, a Dictionary structure of the same name is automatically generated.
Exercise 1: Creating a Segment Type
Exercise Objectives
After completing this exercise, you will be able to: • Create a customer segment
Business Example
The users responsible for an application have noticed that some
information that they have entered in the sending system is missing in the target system. An ALE distribution scenario exists that uses a particular message type and the corresponding IDoc type. You discover that the IDoc type does not transfer all the required information. You now want to check whether the IDoc type contains fields for the missing information. If it does, an enhancement is possible using field conversion or a program enhancement. If it does not, you need to enhance the IDoc type using a segment you have defined yourself.
Task
Create a segment type in the customer namespace. You will use this segment later when enhancing an IDoc type. Also see the procedure Creating a Segment Type.
1. Use the Dictionary to analyze the structureEKKO:
To do this, choose SAP Menu → Tools →ABAP Workbench →Development →Dictionary (= transaction SE11).
What is the type and length of the fieldsINCO1andINCO2? Is there a
structure in the Dictionary calledZ1INCO##?
2. In the segment editor, define a customer segment with the name
Z1INCO##and the fieldsINCO1andINCO2, which are defined using the
data elements of the same names. Save the segment. Assign this to the development classZBIT350_##. Display the details for the data
elementsINCO1andINCO2.
3. Use the ABAP Dictionary to find out whether a structure with the name Z1INCO##exists.
Solution 1: Creating a Segment Type
Task
Create a segment type in the customer namespace. You will use this segment later when enhancing an IDoc type. Also see the procedure Creating a Segment Type.
1. Use the Dictionary to analyze the structureEKKO:
To do this, choose SAP Menu → Tools →ABAP Workbench →Development →Dictionary (= transaction SE11).
What is the type and length of the fieldsINCO1andINCO2? Is there a
structure in the Dictionary calledZ1INCO##?
a)
Table
Field Name Data Element Type Length
INCO1 INCO1 Char 3
INCO2 INCO2 Char 28
b) The structure with the nameZ1INCO##does not yet exist. You will
create it in the following exercise.
2. In the segment editor, define a customer segment with the name
Z1INCO##and the fieldsINCO1andINCO2, which are defined using the
data elements of the same names. Save the segment. Assign this to the development classZBIT350_##. Display the details for the data
elementsINCO1andINCO2.
a) See the procedure Creating a segment type.
b) Double click on the name of the data element to display the details.
3. Use the ABAP Dictionary to find out whether a structure with the name Z1INCO##exists.
a) A structure with the nameZ1INCO##is displayed, which contains
both the data elementsINCO1andINCO2. This is generated when
Lesson Summary
You should now be able to: • Create a customer segment • Analyze IDoc types
Lesson: ALE Process: Technical Details
Lesson Overview
This lesson contains the most important information on structuring programs for ALE scenarios.
Lesson Objectives
After completing this lesson, you will be able to:
• Analyze the outbound and inbound programs of an ALE scenario • Identify enhancement possibilities
Business Example
You want to enhance an ALE scenario. The requirements have already been specified, but the enhancement cannot be realized using field conversion. You are now looking for program enhancements to enhance the program in the required manner. You already know the program names of the outbound and inbound programs. The programs contain several thousand lines of programming. This unit shows you how to systematically analyze the programs.
Important Steps in an ALE Scenario and Basic Terms
1. First, an application program fills an internal table that contains the business data. The structure must be the same as the corresponding IDoc type. This internal table is called the master IDoc.
2. The application program transfers the master IDoc to the ALE layer. 3. In the ALE layer, the recipients are determined from the distribution
model, and a communication IDoc is generated for each recipient. The ALE services are used to make content changes in each communication IDoc if necessary.
4. These communication IDocs are saved to the database and sent via the communication layer to the appropriate target system.
5. In the target system, the communication IDoc is sent to an application program via the ALE layer.
Figure 12: Structure of a Master IDoc
A master IDoc is an internal table that can have any number of lines. Each line consists of a control part, which contains the meta information for the line, and the actual data part. The most important information in the control part is the name of
• SEGNAMName of the segment type
• PSGNUM No. (line number) of the parent segment
• HLEVELHierarchy level
The data part is made up of:
• DTINT2 Total length of the data part
• SDATALong field of typeCHAR, which contains the data in the order
described by the segment type.
The row type of the internal table is determined by the ABAP Dictionary structure typeedidd.
Figure 13: Structure of a Communication IDoc
Each communication IDoc in the database consists of only one control
record, several data records, and status records. The most important part
of the control record is the IDoc number, which is assigned internally in the system. This number is unique within a logical system. The value range is determined in every system using a number range interval. The control record also contains the key fields of the partner profiles, and the last processing status. The data records correspond to the master IDoc. The status records determine the processing steps of the IDoc. They keep a record of the previous states of the IDoc, for example, generated or ready for dispatch. This is therefore important data for monitoring and communication.
Outbound Processing: Creating a Master IDoc
This section discusses the main programming steps involved in the creation of a master IDoc.
Figure 14: Outbound Processing: Creating a Master IDoc
There are different mechanisms that can lead to the generation of a master IDoc:
• Master data replication using Shared Master Data (SMD)
This mechanism is based on change documents. You can schedule a report to generate IDocs for changed master data and replicate it in one or more target systems at regular intervals.
• Message control
Many applications use messages: for example, creating an order. The
generic service used for this is known as message control. You can
use message control to specify in the system whether a message is to be printed or sent electronically.
In order to understand how a master IDoc is generated, it does not matter which method is used to call the IDoc-generating program. For SMD or message control, this must be a function module with a defined interface. Otherwise, it can be implemented as a report or as a function module. The following sections focus on the elements within the application program. These elements are identical for all mechanisms.
Figure 15: When is an IDoc Generated?
In the application program, a structure must be defined that contains information for the control record. The type of this structure is defined in the ABAP Dictionary, and is calledEDIDC. Most fields in the control record
are filled by the ALE layer. At least the IDoc type and the message type must be filled in the application program. This structure is later passed to the ALE layer together with the master IDoc.
Figure 16: Outbound Program: Control Record
Hint: Because ABAP is constantly but compatibly changing,
different syntax variants can be used for defining the same structure.
To clarify the SAP programs, these variants are summarized here. • As of release 4.5, a Dictionary type can be referenced withTYPE.
The syntax for a structure with the nameedidc_sis therefore: DATA edidc_s TYPE edidc.
• As of release 3.0, a Dictionary type can be referenced withLIKE.
The syntax for a structure with the nameedidc_sis therefore: DATA edidc_s LIKE edidc.
• For release 2.2, the syntax for a struc-ture with the name edidc_s is as follows: DATA BEGIN OF edidc_s.
INCLUDE STRUCTURE edidc. DATA END OF edidc_s.
Figure 17: Outbound Program: Internal Table for Master IDoc
In the application program, an internal table must be defined that contains the application data of the master IDoc. The row type of this internal table is defined in the ABAP Dictionary, and is callededidd.
The row type consists of a control part with the following fields: • MANDTClient
• DOCNUM IDoc number
• SEGNUMSegment number
• SEGNAMName of the segment type
• PSGNUMSegment number of the parent segment
• HLEVELHierarchy level
This internal table first has to be filled according to the rules of an IDoc type, and is then passed to the ALE layer as a master IDoc.
Hint: Due to the constantly changing nature of ABAP, there are
different syntax variants that can be used for defining an internal table. To clarify the SAP programs, these variants are summarized as follows:
• As of release 4.5, a Dictionary type can be referenced withTYPE.
For an internal table with the nameedidd_t, this is as follows: DATA edidd_t TYPE STANDARD TABLE OF edidd WITH DEFAULT KEY.
• As of release 4.0, there are different table types. The table type required here is called a standard table. The syntax for an internal table with the nameedidd_tis as follows:
DATA edidd_t LIKE STANDARD TABLE OF edidd WITH DEFAULT KEY.
or, in abbreviated form:
DATA edidd_t LIKE TABLE OF edidd.
• As of release 3.0, a Dictionary type can be referenced withLIKE.
The syntax for an internal table differs from the definition of a structure by the addition ofOCCURS. The syntax for an internal
table with the nameedidd_tis therefore: DATA edidd_t LIKE edidd OCCURS 0.
• For release 2.2, the syntax for an internal table with the name
edidd_t is: DATA BEGIN OF edidd_t OCCURS 0. INCLUDE STRUCTURE edidd.
Figure 18: Outbound Program: Row Structure of the Master IDoc
The master IDoc is structured in rows. First, a segment must be filled. This requires a help structure with the row type edidd(here called
edidd_s). In the control part of the segment, at least the name of the segment type must be entered, in the fieldsegnam. The structure of the
data part must correspond to the description of this segment type. The easiest way to achieve this is to create a structure with the row type of the corresponding Dictionary structure type, and fill the fields of this structure. Note that the data must be entered in an external format. This means that all numeric fields must be converted to character format and copied, left-justified, to the target field. For more detailed information on the mapping procedures, see the ALE Programming Guide. You can then use theMOVEcommand to copy the data into thesdatafield of
the segment. For structures, this command has the effect that all characters of the structure will be copied, left-justified. For more information on the
Figure 19: Outbound Program: Structure of the Master IDoc
You structure a master IDoc by attaching or inserting the segments using anAPPENDorINSERTstatement. Note the following for the segment attributes
of the IDoc type:
• Mandatory segment: The IDoc must contain at least one row with
this segment type
• Optional segment: The IDoc does not have to contain a row with
this segment type
• Min. number: There must be at least this number of segments
• Max. number: Cannot be exceeded
• For a child segment, the parent segment must also be available (in the row before the first child segment)
Figure 20: Passing the Master IDoc to the ALE Layer
The control record and the master IDoc are transferred to the ALE layer using the function moduleMASTER_IDOC_DISTRIBUTE. The ALE layer
supplements the fields of the control part of the master IDoc. This includes numbering the segments and filling the fields for the hierarchy level, the row number of the parent segment, and the IDoc number.
Hint: The function module returns the control records of all the
communication IDocs to the program. You therefore need to define another internal table with the row typeedidcin your program,
and transfer it to theTABLESinterface of the function module. The
internal table can remain empty.
Hint: If the IDoc is to be generated in the same logical unit of work
(LUW) as the application document, and the application document is generated by update, the function module MASTER_IDOC_DISTRIBUTE
Figure 21: Example: Outbound Processing for the Message Type MATMAS
The example displayed here is a process diagram showing outbound processing for the material master message typeMATMAS.
• In Business Transaction Events (BTEs), a function module is called that follows the naming conventionOPEN_FI_PERFORM<name of BTE>.
• You recognize Business Add-Ins on an interface by the naming conventionIF_EX_<badi>- A reference variable must be defined in the
declaration section: DATA ref_name TYPE REF TO if_ex_<badi>.
- and a method call (CALL METHOD ref_name->...)
Outbound Processing: Creating the Communication
IDoc and ALE Services
Figure 23: Outbound Processing: The ALE Layer
1. The outbound program of the application passes the master IDoc to the ALE layer.
2. The ALE layer determines the recipients from the distribution model, and extends the IDoc for each recipient by adding a control record and status records - thus creating a communication IDoc for each recipient. 3. The communication IDoc runs through several ALE services and is
4. Depending on the settings in the partner profile, the communication IDoc is either immediately passed to the communication layer, or is first collected in the database. If IDocs are collected in the database, a background program triggers sending the IDocs.
Hint: If an IDoc is generated from message control, note the
following: Message control uses a process code, which is stored in the partner profile, to call an outbound function module of the application. The master IDoc is structured in this function module. The process code contains an attribute that controls whether the ALE services will be used. If you want to use an ALE service, you therefore need to check this attribute of the process code.
Figure 24: ALE Services in Outbound Processing
The following services are used when creating a communication IDoc: • Determine recipient and filter
The ALE layer reads all the recipients for the message type from the distribution model. If filter groups are defined for a recipient, the
The ALE layer checks whether the filter conditions are fulfilled for every recipient. If this is not the case, the affected segment and all subsegments are deleted from the communication IDoc. If the filter condition affects a mandatory segment, the whole communication IDoc is deleted.
• Segment filtering
The ALE layer checks whether segment filters have been defined for a logical system in transaction BD56 in the maintenance view
V_TBD20. The segments entered in this transaction are deleted from
the communication IDoc. • Field conversion
If rules are linked to a segment field using the field conversion tool, the field contents are adjusted according to the rules.
• Version change
If the current IDoc type is not entered in the partner profile, segments that have been added in later versions are deleted.
• Write IDoc and status to the database
If all services have been successfully run for a communication IDoc, it is saved to the database with status 30. A short text is generated for the status, detailing which services have made changes to the IDoc.
Inbound Processing: ALE Services
Figure 25: Inbound Processing: The ALE Layer
Inbound processing of IDocs is normally triggered by the program
RBDAPP01, which is scheduled as a background job. If Trigger immediately is
set in the partner profile for a message type, processing is automatically triggered as soon as the IDoc arrives in the target system. The IDoc first runs through the ALE services, and is then passed to the inbound function module of the application.
Figure 26: ALE Services in Inbound Processing
The following ALE services are used in inbound processing: • Determining the process code and the inbound module
The ALE layer reads the process code from the partner profile. If this process code is of type Processing by Function Module, the corresponding inbound function module is determined. If the process code has the attribute Processing with ALE Service, the following ALE services are used:
• Segment filtering
The ALE layer checks whether segment filters have been defined for a logical system in transaction BD56 in the maintenance view
V_TBD20. The segments entered in this transaction are deleted from
the communication IDoc. • Field conversion
If rules are linked to a segment field using the field conversion tool, the field contents are adjusted according to the rules.
• Write IDoc and status to the database
If all services have been successfully run for a communication IDoc, the communication IDoc is saved to the database with status 64. A short text is generated for the status, detailing which services have made changes to the IDoc.
Inbound Processing: IDoc Processing in the
Application
Figure 27: Inbound Processing in the Application
In the inbound function module, an application document is created from the application data in the IDoc and saved to the database.
The following logical steps are implemented in the inbound function module:
• Mapping external format→ internal format
The data is contained in the segment fields in the external format. Before the data can be written to the database, it must therefore be converted to the internal format. Normally, the field contents are assigned to structure fields that correspond to the row type of a database table.
• Consistency checks
Which consistency checks are performed depends on the application. • Write application documents
The application determines which method is used to generate the application documents. This can occur synchronously, or asynchronously by update.
• Update IDoc status
The function module must be programmed so that all application documents for an IDoc and the IDoc status are carried out in one logical unit (LUW: Logical Unit of Work). The application function module either updates the IDoc status in the same LUW, or it informs the ALE layer that the status has not yet been updated. In the latter case, the ALE layer performs this step.
Figure 29: Enhancements in Inbound Processing
• A segment is read from the IDoc and entered into a structure of row typeEDIDD. To enable evaluation of the segment fields, the fieldSDATA
is copied, using aMOVEstatement, to a structure that corresponds to
the segment type.
• The segment fields are assigned to the fields of an application structure. Depending on the field type, conversion to the internal format must take place before the assignment.
• Application-specific steps are then performed, such as calculations or consistency checks.
• An enhancement is normally available.
After all segments of the IDoc have been processed, the application document is written. This can happen directly using SQL statements. Normally, asynchronous processing of an update function module is triggered. The outbound function module must ensure that the IDoc status is updated in the same LUW. The function module must therefore inform the ALE layer whether the application document has been generated by asynchronous update, using the export parameter IN_UPDATE_TASK, and
whether the status record has already been changed, using the export parameterCALL_TRANSACTION_DONE. If this field is initial, the ALE layer
updates the status record and ends the LUW with aCOMMIT WORKstatement.
Hint: To avoid explaining too many aspects at once, this unit
is restricted to the inbound processing of individual IDocs. To optimize performance, you can also use package processing. This means that multiple IDocs are processed in one LUW. For more information on package processing, see the Package Processing lesson.
Exercise 2: Analyzing an Outbound
Program
Exercise Objectives
After completing this exercise, you will be able to: • Analyze the outbound program of an ALE scenario
Business Example
You want to enhance an ALE scenario. The requirements have already been specified, but the enhancement cannot be realized using field conversion. You are now looking for program enhancements to enhance the program in the required manner. You already know the program names of the outbound and inbound programs. The programs contain several thousand lines of programming. This unit will show how to systematically analyze the programs.
Task
Analyze the outbound program for the message typeMATMAS. This
outbound program is implemented as a function module and is called
MASTERIDOC_CREATE_MATMAS
1. In which line is the function moduleMASTER_IDOC_DISTRIBUTEcalled,
which is used for passing the master IDoc to the ALE layer? 2. What is the name of the internal table for the master IDoc in this
program? What is the row type of this internal table?
3. At what point in the source text does the internal table of the master IDoc appear? Use the where-used list for a data object. Navigate to the line in the program where a row is added or inserted into the internal table for the first time.
4. In line 145, field contents are copied from the application structure
MARA into the segment structure E1MARAM. Navigate to the keyword
documentation for the ABAP statementMOVE-CORRESPONDING. Where can
you find the conversion rules for theMOVEstatement in the keyword
Solution 2: Analyzing an Outbound
Program
Task
Analyze the outbound program for the message type MATMAS. This
outbound program is implemented as a function module and is called
MASTERIDOC_CREATE_MATMAS
1. In which line is the function moduleMASTER_IDOC_DISTRIBUTEcalled,
which is used for passing the master IDoc to the ALE layer? a) Start the Function Builder by choosing SAP Menu → Tools
→ABAP Workbench → Development → Function Builder (= transaction code SE37. Enter the function module
MASTERIDOC_CREATE_MATMAS, and choose Display.
b) Choose the Source Text tab page to display the source text of the function module. Search in the source text forCALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'.
2. What is the name of the internal table for the master IDoc in this program? What is the row type of this internal table?
a) The quickest way of finding this out is by analyzing the actual parameters when calling the function module
MASTER_IDOC_DISTRIBUTE. The actual parameterT_IDOC_DATAis
assigned to the interface parameterMASTER_IDOC_DATA. CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
EXPORTING MASTER_IDOC_CONTROL = F_IDOC_HEADER TABLES COMMUNICATION_IDOC_CONTROL = T_IDOC_COMM_CONTROL
MASTER_IDOC_DATA = T_IDOC_DATA EXCEPTIONS ERROR_IN_IDOC_CONTROL = 01
ERROR_WRITING_IDOC_STATUS = 02 ERROR_IN_IDOC_DATA = 03 SENDING_LOGICAL_SYSTEM_UNKNOWN = 04.
b) Double click on the name of the actual parameterT_IDOC_DATA to
navigate to the definition point of the data object. DATA: BEGIN OF T_IDOC_DATA OCCURS 10.
INCLUDE STRUCTURE EDIDD. DATA: END OF T_IDOC_DATA.
This is an older syntax variant. The row type is calledEDIDD.
3. At what point in the source text does the internal table of the master IDoc appear? Use the where-used list for a data object. Navigate to the line in the program where a row is added or inserted into the internal table for the first time.
a) Place the cursor on the name of the internal table, for example, on the actual parameter when calling the function module
MASTER_IDOC_DISTRIBUTE. Use the where-used list to obtain a list of
all positions in the program where the data object occurs. b) The segment is added to the internal table using anAPPEND
statement.
4. In line 145, field contents are copied from the application structure
MARA into the segment structure E1MARAM. Navigate to the keyword
documentation for the ABAP statementMOVE-CORRESPONDING. Where can
you find the conversion rules for theMOVEstatement in the keyword
documentation?
a) Position the cursor on the statementMOVE-CORRESPONDING, and use
Lesson Summary
You should now be able to:
• Analyze the outbound and inbound programs of an ALE scenario • Identify enhancement possibilities
Unit Summary
You should now be able to: • Create a customer segment • Analyze IDoc types
• Analyze the outbound and inbound programs of an ALE scenario • Identify enhancement possibilities
Test Your Knowledge
1. All segment fields have the type 'character string' and contain data in an external format.
Determine whether this statement is true or false. True
False
2. An ABAP Dictionary structure of the same name is generated for each segment type.
Determine whether this statement is true or false. True
False
3. A data element from the ABAP Dictionary is assigned to each segment field. This determines the semantics of the field. Determine whether this statement is true or false.
True False
4. Each segment field is of the same type as the assigned data element Determine whether this statement is true or false.
True False
5. The outbound program creates a master IDoc and transfers it to the ALE layer. In this process, the ALE layer must transfer the following information:
Choose the correct answer(s).
A An internal table of row typeEDIDDwith segments
B A control record as a structure with row typeEDIDC, with
information on the message type and the IDoc type. C The current status records for the IDoc
Answers
1. All segment fields have the type 'character string' and contain data in an external format.
Answer: True
Technically, the whole data part of the segment is grouped together in one character field (fieldsdata). It is therefore not technically possible
to permit integers or packed numbers.
2. An ABAP Dictionary structure of the same name is generated for each segment type.
Answer: True
This structure is required when typing the variables in the outbound and inbound programs.
3. A data element from the ABAP Dictionary is assigned to each segment field. This determines the semantics of the field.
Answer: True
In addition to a technical type, data elements are also assigned semantic information such as field names of different lengths, and the documentation that is displayed when a user presses F1 in an input field. The same documentation is also displayed in the documentation tool for segment types.
4. Each segment field is of the same type as the assigned data element
Answer: False
Segment fields contain character strings. The length corresponds to the length required when you convert a field with the same type as the data element into a character field.
5. The outbound program creates a master IDoc and transfers it to the ALE layer. In this process, the ALE layer must transfer the following information:
Answer: A, B, D
The status records are set by the ALE layer, because a communication IDoc with status records is written to the database for each recipient.
Unit 3
Adjusting a Scenario Using Field
Conversion
Unit Overview
You can use the field conversion tool to define rules that have an effect on the contents of segment fields. The contents of this unit include the possibilities and limitations of this method, and an introduction to the tool. The ALE service field conversion takes these rules into account at runtime.
Unit Objectives
After completing this unit, you will be able to: • Adjust an ALE scenario using field conversions
Unit Contents
Field Conversions ... 54 Procedure: Setting a Conversion Rule ... 57 Exercise 3: Field Conversion ... 59
Lesson: Field Conversions
Lesson Overview
You can use field conversion to define rules that affect the contents of segment fields. This unit covers the possibilities and limitations of this method, and introduces the tool.
Lesson Objectives
After completing this lesson, you will be able to: • Adjust an ALE scenario using field conversions
Business Example
In an IDoc for an order, the order number is transferred with no initial zeros. For some suppliers, the IDoc passes through a subsystem that expects the initial zeros. The fields must therefore be converted.
Runtime Behavior
Figure 30: Adjustment by Field Conversion
Field conversion is a part of the ALE services in both inbound processing and outbound processing. The ALE layer passes thesdatafield of a
segment fields. The segment fields are adjusted according to these rules. The data part of the segment (field: sdata) is then returned to the ALE
layer. The ALE layer overwrites the segment of the IDoc.
Figure 31: ALE Services in Outbound Processing
The figure ALE Services in Inbound Processing shows the point in the ALE services at which the field conversion is called in outbound processing.
Figure 32: ALE Services in Inbound Processing
The figure ALE Services in Inbound Processing shows the point in the ALE services at which the field conversion is called in inbound processing.
Setting a Conversion Rule
1. Create a rule.
To do this, choose the following in transaction SALE: Application Link Enabling(ALE)→ Modelling and Implementing Business Processes → Data Conversion Between Sender and Receiver → Create Rule. Enter the following data:
• A name for the conversion rule • A description
• The name of the segment for which the rule is to be defined 2. Maintain the rule you have created.
Choose Application Link Enabling(ALE)→ Modelling and Implementing Business Processes→ Data Conversion Between Sender and Receiver → Maintain Rule. Select your conversion rule and navigate to change mode. Maintain the conversion rule for the individual segment fields that are to be converted.
3. Assign the rule to a message type.
Choose Application Link Enabling(ALE)→ Modelling and Implementing Business Processes→ Data Conversion Between Sender and Receiver → Assign Rule to Message Type. Select the relevant message type, and enter it for the sender and the recipient.
Exercise 3: Field Conversion
Exercise Objectives
After completing this exercise, you will be able to:
• Implement field conversions for an ALE scenario using a conversion rule
Business Example
In an IDoc for an order, the order number is transferred with no initial zeros. For some suppliers, the IDoc passes through a subsystem that expects the initial zeros. The numbers therefore need to be converted.
Task
You want the order number to be displayed with initial zeros in your partner's system. A conversion rule already exists in the system. Maintain this rule and assign it to the message type.
1. Create an order for the vendorT-BIL## . Because you are only
interested in creating and sending the IDoc in this exercise, use a CATT for creating the order.
Choose System→ Services → CATT → Record (= transactionSCEM ). EnterYBIT350_ME21_##as a test case and execute it.
2. Call the status monitor (transaction BD87), and display your IDoc. On the selection screen for the partner system, enter your vendorT-BIL##.
Where can you find the following entries in your order?:
Sender Partner type Partner no. Partner function Recipient Partner type Partner no.
4. Decide whether field conversion should take place in the sending system or in the receiving system. What effect does this have when setting up the rules?
5. A conversion ruleBIT350_ALPHAexists in the system. According to your
decision in question 3, set this in outbound or inbound processing of the IDoc for the message typeORDERS.
6. Use the CATT described in step 1 of this task to create a new IDoc. Display this using transaction BD87. Check whether the field conversion has taken place. If you have implemented the conversion in inbound processing, perform the check in the inbound IDoc, as the conversion only takes effect in inbound processing.
Solution 3: Field Conversion
Task
You want the order number to be displayed with initial zeros in your partner's system. A conversion rule already exists in the system. Maintain this rule and assign it to the message type.
1. Create an order for the vendorT-BIL## . Because you are only
interested in creating and sending the IDoc in this exercise, use a CATT for creating the order.
Choose System→ Services → CATT → Record (= transactionSCEM ). EnterYBIT350_ME21_##as a test case and execute it.
a) The CATT automatically creates an order for your vendorT-BIL##
. An IDoc is created for the message typeORDERS.
2. Call the status monitor (transaction BD87), and display your IDoc. On the selection screen for the partner system, enter your vendorT-BIL##.
Where can you find the following entries in your order?:
Sender Partner type Partner no. Partner function Recipient Partner type
Recipient
Partner no. Partner function
a) For the entries for sender and recipient, see the control record of the IDoc:
Sender
Partner type LS
Partner no. CORE
Partner function
Recipient
Partner type LI
Partner no. T-BIL##
Partner function LF
3. Find which segment and which field contain the order number. a) Path: SAP Menu→ Tools → Business Communication → IDoc Basis
→ Documentation → IDoc Types. IDoc Type: ORDERS03
b) The order number is in the segmentE1EDK01in the fieldBELNR.
4. Decide whether field conversion should take place in the sending system or in the receiving system. What effect does this have when setting up the rules?
a) The rules must be defined in the appropriate system and client. 5. A conversion ruleBIT350_ALPHAexists in the system. According to your
decision in question 3, set this in outbound or inbound processing of the IDoc for the message typeORDERS.
a) Maintain the ruleBIT350_ALPHA for the sending fieldBELNR and the
conversion routineALPHA, and then assign these to the message
typeORDERS, as described in the procedure Setting a Conversion
Rule.
6. Use the CATT described in step 1 of this task to create a new IDoc. Display this using transaction BD87. Check whether the field conversion has taken place. If you have implemented the conversion in inbound processing, perform the check in the inbound IDoc, as the conversion only takes effect in inbound processing.
a) Check the status records of the IDoc: The message ...Fields Converted.. is displayed in outbound processing in status record 30, and in inbound processing in status record 64.
b) Display the data records of the IDoc. If the fields have been converted, the content of the fieldBELNRis displayed in the
Lesson Summary
You should now be able to:
Unit Summary
You should now be able to:
Unit 4
Adjusting a Scenario Without
Enhancing the IDoc Type
Unit Overview
To be able to enhance an ALE scenario supplied by SAP, you first need to analyze the scenario, with its IDoc type, outbound processing, and inbound processing. You need to find out which enhancements are already planned, and assess whether your requirement can be successfully realized using these enhancements. The enhancements can be used in different methods. This unit therefore summarizes which types of enhancements you can use in outbound and inbound processing. Particular attention is paid to requirements for the interface, because you cannot change the interface. An enhancement is demonstrated using an example. The example only includes requirements that do not require enhancement of the IDoc type.
Unit Objectives
After completing this unit, you will be able to:
• Enhance an ALE scenario, when you do not need to transfer additional fields
Unit Contents
Adjusting a Scenario Without Enhancing the IDoc Type... 69 Exercise 4: Enhancing Inbound Processing... 83
Lesson: Adjusting a Scenario Without Enhancing the
IDoc Type
Lesson Overview
Before you can enhance an ALE scenario supplied by SAP, you first need to analyze the scenario together with its IDoc type, outbound processing, and inbound processing. You need to find out which enhancements are already available, and assess whether your requirements can be successfully realized using these enhancements. The enhancements can be implemented using different methods. This unit summarizes which types of enhancements you can use in outbound and inbound processing. Particular attention is paid to customer requirements for the interface, because you cannot change the interface. An enhancement is demonstrated using an example.
Lesson Objectives
After completing this lesson, you will be able to:
• Enhance an ALE scenario, when you do not need to transfer additional fields
Business Example
You want to enhance a supplied ALE scenario. The enhancement cannot be realized using field conversion, but it also does not require enhancement of the IDoc type. You want to check whether suitable enhancements are available in the outbound or inbound programs. If they are, you want to implement the enhancement using the enhancement methods provided.
Figure 34: Adjustment Using Program Enhancements
Additional Information: Enhancement Methods
SAP provides the following methods for realizing an enhancement: • Using a function module exit or customer exit
• Using a Business Transaction Event (BTE) • Using a Business Add-In
Figure 35: Customer Exit: Process Flow
The figure Customer Exit: Process Flow shows the process for a customer exit. The exit function module is called at a point in the source text defined by the SAP application developer. Within the function module, users can add a function to the customer namespace using a include.
corresponding function module and function group. The function module is in a function group whose name begins with anX(X-function group).
The function module name follows the naming convention:
EXIT_<calling program>_<3–digit number>
The statementCALL CUSTOMER-FUNCTIONis not called until the corresponding
enhancement project has been activated. If the same function module is called several times, the activation is valid for all calls.
Figure 37: Business Transaction Event: Process Flow
The figure Business Transaction Event: Process Flow shows the process flow of a Business Transaction Event. A function module is called in the SAP program, which determines and processes the active implementations. These function modules have the following naming convention:
OPEN_FI_PERFORM_<nr>_E(orOPEN_FI_PERFORM_<nr>_P).
The function moduleOPEN_FI_PERFORM_<nr>(service function module)
determines all the active implementations for the corresponding
enhancement, and enters them in an internal table. The function modules found are processed in the order specified in this internal table. If necessary, the conditions under which the function module is processed in the customer namespace are also taken into account. For example, a country or an application can be entered as a condition. These conditions are also referred to as filter values.
Figure 38: BTE: Call Syntax
The figure BTE: Call Syntax shows the syntax used to call a
program enhancement for a Business Transaction Event. In the SAP application program, the function moduleOPEN_FI_PERFORM_<nr>_Eor OPEN_FI_PERFORM_<nr>_P(for process interfaces) is called. The application
transfers the interface data to this service function module. The interface is predefined by the SAP developer. The service function module also searches for active implementations and enters these in an internal table. The implemented function modules found are processed in a loop.
Figure 39: Business Add-Ins: Process Flow
The figure Business Add-Ins: Process Flow shows the process for a Business Add-In (BAdI). The figure does not show that a reference variable referring to the BAdI interface must be declared in the declaration part. An object reference is generated in the first step. This transfers the service classCL_EXITHANDLER. The exact syntax is detailed below. All preparations
are then made for using the program enhancement. In the BAdI definition, a class known as an adapter class is generated, which implements the interface. The interface method of the adapter class is called in (2). The adapter class finds all the implementations available for the BAdI, and calls the implemented methods.
Figure 40: Business Add-Ins: Call Syntax
This diagram shows the syntax required for calling a BAdI. The numbered circles correspond to the calls on the previous diagram. First, a reference variable must be defined that refers to the BAdI interface. The name of the reference variable does not necessarily have to contain the name of the BAdI. In call (1), an object reference is generated. This creates an instance of the generated adapter class. Only the methods of the interface can be contacted using this object reference. This object reference can now be used to call the required methods (2).
Finding a Suitable Enhancement
You can use the following approaches to find a suitable enhancement: • Search for an enhancement directly
Use the Repository Infosystem to search for Business Add-Ins or customer exits. Choose SAP Menu→ Tools → ABAP Workbench → Overview→ Infosystem (= transaction SE84) Repository Infosystem → Environment→ Exit Methods.
Use transaction FIBF to search for BTEs. Choose Environment→ Infosystem
– You can recognize Business Transaction Events by a function module with the naming conventionOPEN_FI_PERFORM_<name of BTE>
– You can recognize Business Add-Ins on an interface by the naming conventionIF_EX_<badi>. You can recognize this in the
definition part of the program by the variable definition DATA <ref_name> TYPE REF TO if_ex_<badi>.and a method call with the
syntaxCALL METHOD ref_name->...
When making an ALE enhancement, you always need to consider the whole scenario. Depending on where in the ALE process you want to make a change, you search for an enhancement either in outbound processing or in inbound processing.
Enhancement Options in Outbound Processing
Figure 41: Changing the Master IDoc
In a program supplied by SAP for outbound processing, various different enhancements are possible. You are looking for an enhancement for adjusting the contents of the master IDoc. You are therefore only interested in enhancements that are called before the function module
MASTER_IDOC_DISTRIBUTE. One of the following interface conditions must also
be fulfilled:
• A segment must be transferred to the enhancement and returned to the program before it is attached to the internal table of the master IDoc.
• The whole master IDoc must be returned to the enhancement and back to the program.
To enhance a scenario, you normally have to access application data that is already recognized in the program. You need to check whether this application data is transferred to an enhancement so that you do not access the database twice unnecessarily.
Enhancement Options in Inbound Processing
Figure 42: Enhancements in Inbound Processing
To change the ALE scenario on the inbound side, you only need to consider enhancements to the inbound function module, because you only need read access to the IDoc data, and the change must occur before the application document is written to the database. You can use the inbound process code to find the inbound function module. Various enhancements are available at this point. Use the interface to work out which scenario is suitable.
Example: Enhancement Using a Customer Exit
In this example, you want to change an uncritical field of the material master, and ensure that this change is replicated in the application
Figure 43: Example: Outbound Processing for MATMAS
The function moduleMASTERIDOC_CREATE_MATMASis responsible for structuring
the master IDoc in outbound processing of the ALE scenario for
distributing master data. During processing of the segment typeE1MARAM,
no enhancement is called before the segment is attached to the master IDoc. Immediately after inserting the segmentE1MARAM, a customer exit is
called, to which all the important data for our scenario is transferred. To find the enhancement belonging to the call of the customer exit, you need to know the name of theEXITfunction module. To find this name, choose
the number of the customer exit. This displays the Function Builder, where you can note the full name of the function moduleEXIT_SAPLMV01_002.
Figure 44: Finding a Customer Exit Using the Repository Infosystem
Finally, you can use the Repository Infosystem to search for a customer exit with the componentEXIT_SAPLMV01_002.
system. Use the Create pushbutton to navigate to the project attributes, and enter a short text for the enhancement project. The system enters the remaining attributes (name stamp and time stamp for creating and changing, and status).
Figure 46: Assigning SAP Enhancements to a Customer Project
You can then assign the SAP enhancement to the customer enhancement project. To do this, you enter the names of the SAP enhancements on the appropriate screen.
