BIT350

BIT350 ALE Enhancements

Date Training Center Instructors Education Website

Participant Handbook Date: 2002/Q2 Course Duration: 2 Day(s) Material Number: 50054652

An SAP course - use it to learn, reference it for work

Copyright Copyright © 2002 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. 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.

About this Handbook 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. 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

2002/Q2

Example text

Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.



Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

© 2002 SAP AG. All rights reserved.

iii

BIT350

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.

iv

© 2002 SAP AG. All rights reserved.

2002/Q2

Contents 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 Serialization By Message Types (Serialization Groups) ........164 Object Channel Serialization .......................................173

Unit 7: ALE Scenario with BAPI Technology ..................... 185 Generating an ALE Interface for a BAPI ..........................186 Outbound Processing ...............................................192 Inbound Processing .................................................196

2002/Q2

© 2002 SAP AG. All rights reserved.

v

Contents

BIT350

Customizing ..........................................................199

vi

© 2002 SAP AG. All rights reserved.

2002/Q2

Course Overview 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 After completing this course, you will be able to: • • •

2002/Q2

Analyze an ALE scenario for enhancement possibilities Assess the most appropriate method for enhancing a scenario Optimize Customizing settings to improve the performance of an ALE process

© 2002 SAP AG. All rights reserved.

vii

Course Overview

viii

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

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 The ALE Process and Enhancement Possibilities .............................2

2002/Q2

© 2002 SAP AG. All rights reserved.

1

Unit 1: Enhancing ALE Scenarios: Overview

BIT350

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.

Figure 1: ALE Process with Status Values

2

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: The ALE Process and Enhancement Possibilities

BIT350

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.

2002/Q2

© 2002 SAP AG. All rights reserved.

3

Unit 1: Enhancing ALE Scenarios: Overview

BIT350

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.

4

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: The ALE Process and Enhancement Possibilities

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.

2002/Q2

© 2002 SAP AG. All rights reserved.

5

Unit 1: Enhancing ALE Scenarios: Overview

BIT350

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.

6

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: The ALE Process and Enhancement Possibilities

Figure 5: Adjustment with Enhancement of the IDoc Type In this case, both Customizing settings and ABAP programming are required.

2002/Q2

© 2002 SAP AG. All rights reserved.

7

Unit 1: Enhancing ALE Scenarios: Overview

BIT350

Lesson Summary You should now be able to: • Describe the levels on which you can enhance an ALE scenario, and which activities are required

8

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit Summary

Unit Summary You should now be able to: • Describe the levels on which you can enhance an ALE scenario, and which activities are required

2002/Q2

© 2002 SAP AG. All rights reserved.

9

Unit Summary

10

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

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 B C D

2002/Q2

Field conversion Program enhancement without enhancing the IDoc type Program enhancement with enhancement of the IDoc type Enhancement of the IDoc type without program enhancement

© 2002 SAP AG. All rights reserved.

11

Test Your Knowledge

BIT350

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.

12

© 2002 SAP AG. All rights reserved.

2002/Q2

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 Exercise 2: Analyzing an Outbound Program ................................ 45

2002/Q2

© 2002 SAP AG. All rights reserved.

13

Unit 2: IDoc Processing: Technical Details

BIT350

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

Figure 6: Sending a Message: Intermediate Document

14

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: IDoc Types: Technical Details

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 type MATMAS03 (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.

2002/Q2

© 2002 SAP AG. All rights reserved.

15

Unit 2: IDoc Processing: Technical Details

BIT350

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

/

Attributes on / off

IDoc type long text, release, display release, record type versions

Segment 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

/

DocuSegment documentation is mentation displayed or hidden on / off

/

Attributes on / off

/

DocuData element mentation documentation on / off

Segment field

/

16

Field values off

© 2002 SAP AG. All rights reserved.

Internal format: Type, length, and name of the data element; external format: Length of character field; Offset of the first character in the segment

Permitted field values or value table of domains

2002/Q2

Lesson: IDoc Types: Technical Details

BIT350

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 data element describes the internal type, which is identical to the properties of the field in the corresponding database table, while the data in an IDoc segment is represented in an external type. Only character-string fields are permitted, which means the ABAP types C, N, D and T. When structuring the master IDoc, you therefore need to consider the conversion rules from the internal to the external format.

2002/Q2

© 2002 SAP AG. All rights reserved.

17

Unit 2: IDoc Processing: Technical Details

BIT350

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

Figure 10: A Segment Type and Generated Dictionary Structure

18

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: IDoc Types: Technical Details

BIT350

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

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.

2002/Q2

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.

© 2002 SAP AG. All rights reserved.

19

Unit 2: IDoc Processing: Technical Details

20

© 2002 SAP AG. All rights reserved.

BIT350

2002/Q2

Lesson: IDoc Types: Technical Details

BIT350

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 structure EKKO: To do this, choose SAP Menu → Tools →ABAP Workbench →Development →Dictionary (= transaction SE11). What is the type and length of the fields INCO1 and INCO2? Is there a structure in the Dictionary called Z1INCO##?

2.

In the segment editor, define a customer segment with the name and the fields INCO1 and INCO2, which are defined using the data elements of the same names. Save the segment. Assign this to the development class ZBIT350_##. Display the details for the data elements INCO1 and INCO2. Z1INCO##

3.

2002/Q2

Use the ABAP Dictionary to find out whether a structure with the name Z1INCO## exists.

© 2002 SAP AG. All rights reserved.

21

Unit 2: IDoc Processing: Technical Details

BIT350

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 structure EKKO: To do this, choose SAP Menu → Tools →ABAP Workbench →Development →Dictionary (= transaction SE11). What is the type and length of the fields INCO1 and INCO2? Is there a structure in the Dictionary called Z1INCO##? a) Table

b) 2.

Length

INCO1

INCO1

Char

3

INCO2

INCO2

Char

28

The structure with the name Z1INCO## does not yet exist. You will create it in the following exercise.

See the procedure Creating a segment type. Double click on the name of the data element to display the details.

Use the ABAP Dictionary to find out whether a structure with the name Z1INCO## exists. a)

22

Data Element Type

In the segment editor, define a customer segment with the name Z1INCO## and the fields INCO1 and INCO2, which are defined using the data elements of the same names. Save the segment. Assign this to the development class ZBIT350_##. Display the details for the data elements INCO1 and INCO2. a) b)

3.

Field Name

A structure with the name Z1INCO## is displayed, which contains both the data elements INCO1 and INCO2. This is generated when the segment type is saved.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: IDoc Types: Technical Details

BIT350

Lesson Summary You should now be able to: • Create a customer segment • Analyze IDoc types

2002/Q2

© 2002 SAP AG. All rights reserved.

23

Unit 2: IDoc Processing: Technical Details

BIT350

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

Figure 11: IDoc Processing: Overview

24

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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 the segment type, which describes the structure of the data part. The control part of each line has the following fields: • • •

2002/Q2

Client DOCNUM IDoc number (assigned in the ALE layer) SEGNUM Sequential number (= row number of the internal table) MANDT

© 2002 SAP AG. All rights reserved.

25

Unit 2: IDoc Processing: Technical Details

• • •

BIT350

Name of the segment type PSGNUM No. (line number) of the parent segment HLEVEL Hierarchy level SEGNAM

The data part is made up of: • •

Total length of the data part SDATA Long field of type CHAR, which contains the data in the order described by the segment type. DTINT2

The row type of the internal table is determined by the ABAP Dictionary structure type edidd.

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.

26

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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.

•

Application program Some application programs generate master IDocs directly. Technically, this can be realized in two ways: – –

2002/Q2

The application program fills an internal table in the IDoc format, and transfers this to an ALE service. The application program uses a BAPI with an ALE interface.

© 2002 SAP AG. All rights reserved.

27

Unit 2: IDoc Processing: Technical Details

BIT350

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

28

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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 with TYPE. The syntax for a structure with the name edidc_s is therefore: DATA edidc_s TYPE edidc.

•

As of release 3.0, a Dictionary type can be referenced with LIKE. The syntax for a structure with the name edidc_s is therefore: DATA edidc_s LIKE edidc.

•

For release 2.2, the syntax for a structure with the name edidc_s is as follows: DATA BEGIN OF edidc_s. INCLUDE STRUCTURE edidc. DATA END OF edidc_s.

2002/Q2

© 2002 SAP AG. All rights reserved.

29

Unit 2: IDoc Processing: Technical Details

BIT350

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 called edidd. The row type consists of a control part with the following fields: • • • • • •

Client DOCNUM IDoc number SEGNUM Segment number SEGNAM Name of the segment type PSGNUM Segment number of the parent segment HLEVEL Hierarchy level MANDT

The data part of the row type contains the field SDATA.

30

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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 with TYPE. For an internal table with the name edidd_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 name edidd_t is 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 with LIKE. The syntax for an internal table differs from the definition of a structure by the addition of OCCURS. The syntax for an internal table with the name edidd_t is therefore: DATA edidd_t LIKE edidd OCCURS 0.

•

For release 2.2, the syntax for an internal table with the name is: DATA BEGIN OF edidd_t OCCURS 0.

edidd_t

INCLUDE STRUCTURE edidd. DATA END OF edidd_t.

2002/Q2

© 2002 SAP AG. All rights reserved.

31

Unit 2: IDoc Processing: Technical Details

BIT350

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 field segnam. 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 the MOVE command to copy the data into the sdata field 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 MOVE command, see the keyword documentation for MOVE.

32

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

Figure 19: Outbound Program: Structure of the Master IDoc You structure a master IDoc by attaching or inserting the segments using an APPEND or INSERT statement. Note the following for the segment attributes of the IDoc type: • • • • •

2002/Q2

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)

© 2002 SAP AG. All rights reserved.

33

Unit 2: IDoc Processing: Technical Details

BIT350

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 module MASTER_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 type edidc in your program, and transfer it to the TABLES interface 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 must also be called with the addition IN UPDATE TASK.

34

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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

Figure 22: Changing the Master IDoc: Customer Enhancements Technically, these enhancements can be realized as follows: •

2002/Q2

You can recognize customer exits by the statement CUSTOMER-FUNCTION.

© 2002 SAP AG. All rights reserved.

CALL

35

Unit 2: IDoc Processing: Technical Details

• •

BIT350

In Business Transaction Events (BTEs), a function module is called that follows the naming convention OPEN_FI_PERFORM. You recognize Business Add-Ins on an interface by the naming convention IF_EX_ - A reference variable must be defined in the declaration section: DATA ref_name TYPE REF TO if_ex_. - and a method call (CALL

METHOD ref_name->...)

Outbound Processing: Creating the Communication IDoc and ALE Services

Figure 23: Outbound Processing: The ALE Layer

36

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 then saved in the database.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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 filter conditions are also determined.

•

2002/Q2

Filtering using filter objects

© 2002 SAP AG. All rights reserved.

37

Unit 2: IDoc Processing: Technical Details

BIT350

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.

38

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: ALE Process: Technical Details

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.

2002/Q2

© 2002 SAP AG. All rights reserved.

39

Unit 2: IDoc Processing: Technical Details

BIT350

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.

40

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: ALE Process: Technical Details

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.

Figure 28: Steps in the Inbound Function Module

2002/Q2

© 2002 SAP AG. All rights reserved.

41

Unit 2: IDoc Processing: Technical Details

BIT350

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 The IDoc data is evaluated in segments:

42

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

•

•

• •

A segment is read from the IDoc and entered into a structure of row type EDIDD. To enable evaluation of the segment fields, the field SDATA is copied, using a MOVE statement, 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 parameter CALL_TRANSACTION_DONE. If this field is initial, the ALE layer updates the status record and ends the LUW with a COMMIT WORK statement. 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.

2002/Q2

© 2002 SAP AG. All rights reserved.

43

Unit 2: IDoc Processing: Technical Details

44

© 2002 SAP AG. All rights reserved.

BIT350

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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 type MATMAS. This outbound program is implemented as a function module and is called MASTERIDOC_CREATE_MATMAS

2002/Q2

1.

In which line is the function module MASTER_IDOC_DISTRIBUTE called, 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 statement MOVE-CORRESPONDING. Where can you find the conversion rules for the MOVE statement in the keyword documentation?

© 2002 SAP AG. All rights reserved.

45

Unit 2: IDoc Processing: Technical Details

BIT350

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 module MASTER_IDOC_DISTRIBUTE called, which is used for passing the master IDoc to the ALE layer? a)

b)

2.

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. Choose the Source Text tab page to display the source text of the function module. Search in the source text for CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'.

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 parameter T_IDOC_DATA is assigned to the interface parameter MASTER_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 parameter T_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 called EDIDD.

Continued on next page

46

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: ALE Process: Technical Details

BIT350

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)

b) 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 statement MOVE-CORRESPONDING. Where can you find the conversion rules for the MOVE statement in the keyword documentation? a)

2002/Q2

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. The segment is added to the internal table using an APPEND statement.

Position the cursor on the statement MOVE-CORRESPONDING, and use the F1 function key to navigate to the keyword documentation.

© 2002 SAP AG. All rights reserved.

47

Unit 2: IDoc Processing: Technical Details

BIT350

Lesson Summary You should now be able to: • Analyze the outbound and inbound programs of an ALE scenario • Identify enhancement possibilities

48

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit Summary

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

2002/Q2

© 2002 SAP AG. All rights reserved.

49

Unit Summary

50

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

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 B C D

2002/Q2

An internal table of row type EDIDD with segments A control record as a structure with row type EDIDC, with information on the message type and the IDoc type. The current status records for the IDoc In the master IDoc, the name of the segment type that the structure of the data part describes, for each segment.

© 2002 SAP AG. All rights reserved.

51

Test Your Knowledge

BIT350

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 (field sdata). 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.

52

© 2002 SAP AG. All rights reserved.

2002/Q2

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

2002/Q2

© 2002 SAP AG. All rights reserved.

53

Unit 3: Adjusting a Scenario Using Field Conversion

BIT350

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 the sdata field of a segment to the ALE service field conversion, where rules can be stored for

54

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Field Conversions

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.

2002/Q2

© 2002 SAP AG. All rights reserved.

55

Unit 3: Adjusting a Scenario Using Field Conversion

BIT350

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.

56

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Field Conversions

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

2.

A name for the conversion rule A description The name of the segment for which the rule is to be defined

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.

2002/Q2

© 2002 SAP AG. All rights reserved.

57

Unit 3: Adjusting a Scenario Using Field Conversion

58

© 2002 SAP AG. All rights reserved.

BIT350

2002/Q2

BIT350

Lesson: Field Conversions

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 vendor T-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 ). Enter YBIT350_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 vendor T-BIL##. Where can you find the following entries in your order?: Sender Partner type Partner no. Partner function Recipient Partner type Partner no. Partner function

3.

Find which segment and which field contain the order number.

Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

59

Unit 3: Adjusting a Scenario Using Field Conversion

60

BIT350

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 rule BIT350_ALPHA exists in the system. According to your decision in question 3, set this in outbound or inbound processing of the IDoc for the message type ORDERS.

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.

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Field Conversions

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 vendor T-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 ). Enter YBIT350_ME21_## as a test case and execute it. a)

2.

The CATT automatically creates an order for your vendor T-BIL## . An IDoc is created for the message type ORDERS.

Call the status monitor (transaction BD87), and display your IDoc. On the selection screen for the partner system, enter your vendor T-BIL##. Where can you find the following entries in your order?: Sender Partner type Partner no. Partner function Recipient Partner type

Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

61

Unit 3: Adjusting a Scenario Using Field Conversion

BIT350

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

3.

b)

Partner no.

T-BIL##

Partner function

LF

Path: SAP Menu → Tools → Business Communication → IDoc Basis → Documentation → IDoc Types. IDoc Type: ORDERS03 The order number is in the segment E1EDK01 in the field BELNR.

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)

5.

LI

Find which segment and which field contain the order number. a)

4.

Partner type

The rules must be defined in the appropriate system and client.

A conversion rule BIT350_ALPHA exists in the system. According to your decision in question 3, set this in outbound or inbound processing of the IDoc for the message type ORDERS. a)

Maintain the rule BIT350_ALPHA for the sending field BELNR and the conversion routine ALPHA, and then assign these to the message type ORDERS, as described in the procedure Setting a Conversion Rule.

Continued on next page

62

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Field Conversions

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

2002/Q2

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. Display the data records of the IDoc. If the fields have been converted, the content of the field BELNR is displayed in the segment E1EDK01 with initial zeros.

© 2002 SAP AG. All rights reserved.

63

Unit 3: Adjusting a Scenario Using Field Conversion

BIT350

Lesson Summary You should now be able to: • Adjust an ALE scenario using field conversions

64

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit Summary

Unit Summary You should now be able to: • Adjust an ALE scenario using field conversions

2002/Q2

© 2002 SAP AG. All rights reserved.

65

Unit Summary

66

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

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

2002/Q2

© 2002 SAP AG. All rights reserved.

67

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

Figure 33: Adjustment Using Program Enhancements

68

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

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.

2002/Q2

© 2002 SAP AG. All rights reserved.

69

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

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

The following provides a brief introduction to all three methods.

70

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

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.

Figure 36: Customer Exit: Call Syntax The SAP application programmer defines the function module call using the ABAP statement CALL CUSTOMER-FUNCTION 'nnn'. 'nnn' represents a three-digit number. The SAP application programmer also creates the

2002/Q2

© 2002 SAP AG. All rights reserved.

71

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

corresponding function module and function group. The function module is in a function group whose name begins with an X (X-function group). The function module name follows the naming convention: EXIT__

The statement CALL CUSTOMER-FUNCTION is 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__E (or OPEN_FI_PERFORM__P). The function module OPEN_FI_PERFORM_ (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.

72

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

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 module OPEN_FI_PERFORM__E or OPEN_FI_PERFORM__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.

2002/Q2

© 2002 SAP AG. All rights reserved.

73

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

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

74

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

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

•

Search for the call of an enhancement method in the inbound or outbound program –

2002/Q2

You can recognize a customer exit by the statement

CALL

CUSTOMER-FUNCTION.

© 2002 SAP AG. All rights reserved.

75

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

–

BIT350

You can recognize Business Transaction Events by a function module with the naming convention OPEN_FI_PERFORM_

–

You can recognize Business Add-Ins on an interface by the naming convention IF_EX_. You can recognize this in the definition part of the program by the variable definition DATA TYPE REF TO if_ex_. and a method call with the syntax CALL 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: •

76

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.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

•

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 document in the target system. You have chosen the old material number BISMT field. This is contained in the segment type E1MARAM, and is saved in the database table MARA when a material master is changed.

2002/Q2

© 2002 SAP AG. All rights reserved.

77

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

Figure 43: Example: Outbound Processing for MATMAS The function module MASTERIDOC_CREATE_MATMAS is responsible for structuring the master IDoc in outbound processing of the ALE scenario for distributing master data. During processing of the segment type E1MARAM, no enhancement is called before the segment is attached to the master IDoc. Immediately after inserting the segment E1MARAM, 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 the EXIT function 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 module EXIT_SAPLMV01_002.

78

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

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

Figure 45: Creating a Customer Enhancement Project To implement an enhancement, first start the project administration function (transaction CMOD), and enter a name for the enhancement project. SAP recommends that you use a naming convention, for example, by adding the name of the transaction or the module pool to the name of the project. The project name uniquely identifies the enhancement in the

2002/Q2

© 2002 SAP AG. All rights reserved.

79

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

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.

Figure 47: Editing Components

80

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

Under Components, all components are displayed that belong to the entered enhancements. Double click on the component to display it.

Figure 48: Editing a Function Module Exit In the function module, an INCLUDE statement with an include name is available in the customer namespace. To implement the customer exit, first create this customer include using forward navigation. Enter the ABAP source text in the include. You have access to all the interface parameters of the function module. You can define local help variables in the include. To create global variables for the function group, first program an ABAP statement that uses the variables, and then create the definition using forwards navigation (select the names of the variables by double-clicking). You cannot change the function module itself, particularly the interface.

2002/Q2

© 2002 SAP AG. All rights reserved.

81

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

Figure 49: Activating and Documenting an Enhancement Project Activating an enhancement project affects all components. Once the project has been successfully activated, it has the status active. When the project is activated, all programs, screens, and menu interfaces contained in the components belonging to the project are regenerated (programs are only generated when they are started). After activation, the enhancements are visible in the application functions. You can use the Deactivate function to undo activation of an enhancement project. The project then has the status Inactive.

Figure 50: Test Processing To test processing, you can customize ALE so that the IDoc is sent back to the same system. You can then test the scenario using different clients. If the target client is in another SAP system, you first have to transport the development objects of the enhancement into the target system.

82

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

Exercise 4: Enhancing Inbound Processing Exercise Objectives After completing this exercise, you will be able to: • Enhance an ALE scenario when transferring additional fields is not necessary

Business Example A scenario for ordering materials has been deliberately simplified for this exercise. Some facts have been omitted compared to the standard scenario. You want to create the order for another SAP system. For the outbound order, the message type ORDLGT is available with an outbound function module for message control. For the incoming order, an inbound function module for the message type ORDLGT is available. To create an order in the target system, you need to implement an enhancement.

Task Use a program enhancement to ensure that the IDoc for the simplified ordering scenario with message type ORDLGT is processed without errors in inbound processing. 1.

Change the partner profile for the partner T-BIL##. Change the outbound parameters for the message type ORDERS: Delete the settings for message control (tab page NAST)Change the outbound parameters for the message type ORDLGT: Message control: Application EF Message type NEU Process code ORDLGT_OUT_##

2.

Create an order using a CATT. Choose System → Services → CATT → Record (= transaction SCEM. . Select and execute the test case YBIT350_ME21_##.

3.

Display the IDoc in the transaction BD87. What status does the IDoc have in the target system?

4.

Can the problem be solved using an enhancement? Consider at which point you need to make the enhancement. Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

83

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

84

BIT350

5.

In project management (transaction CMOD), create the project BIT##. Select the SAP enhancement BIT350## for the project. Which components are affected by inbound processing? Analyze the interface: Which parameters are transferred to the enhancement, and which parameters does the enhancement return to the program?

6.

At which point is the customer exit called? In which program is the Call Customer-Function call? Is the original function call in the BIT350_Input_## function module?

7.

How can you use the Customer Exit to enter the value TA in the field AUART in structure xvbak, if the segment field E1HEAD AUART contains the value NB? Enter the enhancement code in the inbound component.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

Solution 4: Enhancing Inbound Processing Task Use a program enhancement to ensure that the IDoc for the simplified ordering scenario with message type ORDLGT is processed without errors in inbound processing. 1.

Change the partner profile for the partner T-BIL##. Change the outbound parameters for the message type ORDERS: Delete the settings for message control (tab page NAST)Change the outbound parameters for the message type ORDLGT: Message control: Application EF Message type NEU Process code ORDLGT_OUT_## a)

2.

Note that you can only set up message control for ORDLGT if you have already deleted it in ORDERS.

Create an order using a CATT. Choose System → Services → CATT → Record (= transaction SCEM. . Select and execute the test case YBIT350_ME21_##. a)

3.

Display the IDoc in the transaction BD87. What status does the IDoc have in the target system? a)

4.

Note the number of the generated IDoc.

The IDoc has status 51 with the status text: Entry NB not available.

Can the problem be solved using an enhancement? Consider at which point you need to make the enhancement. a) b)

The problem can be solved using an enhancement that converts the incorrect application document type NB into the correct application document type TA. Technically, the enhancement can be made in both inbound and outbound processing. However, because the application document type NB (new order) is correct for the role of the ordering party, and the application document type TA for the order recipient, the enhancement should be made in the target system. In an EDI scenario, the subsystem would carry out this conversion. Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

85

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

5.

In project management (transaction CMOD), create the project BIT##. Select the SAP enhancement BIT350## for the project. Which components are affected by inbound processing? Analyze the interface: Which parameters are transferred to the enhancement, and which parameters does the enhancement return to the program? a)

b)

If you choose Components, two EXIT function modules are displayed. Double click to display the details. Choose the Properties tab page. You can tell from the short text which component is used in inbound processing, and which in outbound processing. The EXIT function module for inbound processing is called EXIT_SAPLIB##_002. Import parameter: PI_VBAK621 Export parameter:

6.

BIT350

PI_VBAK621

At which point is the customer exit called? In which program is the Call Customer-Function call? Is the original function call in the BIT350_Input_## function module? a) b)

The program: LIB00F01 is, however, a subprogram. To find the inbound function module, you need to call the where-used list more than once. The original function call is in the function module BIT350_Input_##. Hint: You can also use the following method to find the function module of call customer-function: •

• •

In the Object Navigator (transaction SE80), enter the function group IB## , and the function module BC621_Input_## . Find Call customer function Double click on 002. Note the name of the function module.

Continued on next page

86

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

7.

How can you use the Customer Exit to enter the value TA in the field in structure xvbak, if the segment field E1HEAD AUART contains the value NB? Enter the enhancement code in the inbound component. AUART

a) b)

Return to the EXIT function module EXIT_SAPLIB##_002. In the source code, double click on the name of the include and recreate it. Enhancement code for the inbound component: 1

*-----------------------------------------------------*

2

*INCLUDE ZXBIT350##U02

3

*-----------------------------------------------------*

4 5 6 7

pe_vbak621 = pi_vbak621.

8 9

IF pe_vbak621-auart = 'NB'.

10 11 12

2002/Q2

pe_vbak621-auart = ‘TA’. ENDIF.

© 2002 SAP AG. All rights reserved.

87

Unit 4: Adjusting a Scenario Without Enhancing the IDoc Type

BIT350

Lesson Summary You should now be able to: • Enhance an ALE scenario, when you do not need to transfer additional fields

88

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit Summary

Unit Summary You should now be able to: • Enhance an ALE scenario, when you do not need to transfer additional fields

2002/Q2

© 2002 SAP AG. All rights reserved.

89

Unit Summary

90

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

Test Your Knowledge 1.

Which statement enables you to recognize a customer exit in the calling program?

2.

Which statement enables you to recognize a Business Add-In (BAdI) in the calling program?

3.

How do you recognize a Business Transaction Event (BTE) in the calling program?

4.

You want to enhance the outbound processing of an ALE scenario. The change affects the segment E1APPLXPL. Several enhancements are offered in the outbound program. What conditions does an enhancement need to fulfill before you can use it? Choose the correct answer(s).

A

The call cannot be made until the function module has been called. The call must be made before the function module MASTER_IDOC_DISTRIBUTE is called. The master IDoc must be transferred to the enhancement, but it cannot be changed in the enhancement. The interface enables a change to the master IDoc, or the program updates the master IDoc after the enhancement is called. MASTER_IDOC_DISTRIBUTE

B C D

2002/Q2

© 2002 SAP AG. All rights reserved.

91

Test Your Knowledge

BIT350

Answers 1.

Which statement enables you to recognize a customer exit in the calling program? Answer:

2.

CALL CUSTOMER-FUNCTION

Which statement enables you to recognize a Business Add-In (BAdI) in the calling program? Answer: Prerequisite: A reference variable is defined in the program that refers to an interface with the naming convention IF_EX_. You will then recognize a Business Add-In by the call of an interface method. DATA exit_ref TYPE REF TO IF_EX_. ... CALL METHOD exit_ref->method EXPORTING IMPORTING .

3.

How do you recognize a Business Transaction Event (BTE) in the calling program? Answer: By the function module call, which uses the naming convention OPEN_FI_PERFORM_.

4.

You want to enhance the outbound processing of an ALE scenario. The change affects the segment E1APPLXPL. Several enhancements are offered in the outbound program. What conditions does an enhancement need to fulfill before you can use it? Answer: B, D The point at which the call is made, and the interface, must be configured so that the master IDoc can be changed. They must therefore be called before the function module MASTER_IDOC_DISTRIBUTE, either due to transfer of the master IDoc by CHANGING or TABLES, or due to the program updating the master IDoc with information from the enhancement after the enhancement is called.

92

© 2002 SAP AG. All rights reserved.

2002/Q2

Unit 5 Adjusting a Scenario With Enhancement of the IDoc Type Unit Overview You want to enhance a supplied ALE scenario using a customer's own fields. You have already analyzed the outbound and inbound program and examined it for enhancement possibilities. To implement the enhancement, you need to create a segment type, define an enhancement for the IDoc type, and implement enhancements in the outbound module and the inbound module.

Unit Objectives After completing this unit, you will be able to: • • • • • •

Create an enhancement for an IDoc type and enhance it using a customer segment List the steps required for implementing an enhancement in inbound processing List the steps required for implementing an enhancement in outbound processing Test an enhanced scenario List what you need to check when transporting into the quality system landscape Describe which additional checks are necessary if you want to enhance a scenario for customer tables

Unit Contents Defining an Enhancement for the IDoc Type ................................. 96 Procedure: Creating an Enhancement for an IDoc Type ..................100 Exercise 5: Enhancing the IDoc Type ........................................101 Enhancements in Inbound Processing .......................................106 Exercise 6: Enhancing Inbound Processing.................................111 Enhancements in Outbound Processing: Adjusting the Master IDoc ....114

2002/Q2

© 2002 SAP AG. All rights reserved.

93

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Exercise 7: Enhancing Outbound Processing...............................119 Test, Transport, and Customizing .............................................123 Procedure: Testing in a Development System with Two Clients ..........125 Procedure: Testing in a Development System with One Client ...........126 Procedure: Testing in a Single Client From Two Different SAP Systems 127 Exercise 8: Testing the Enhancement........................................129 Enhancements for Customer Tables..........................................132

Figure 51: Adjustment by Enhancing the IDoc Type

94

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

Figure 52: Example: A Table Append for MARA

2002/Q2

© 2002 SAP AG. All rights reserved.

95

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Lesson: Defining an Enhancement for the IDoc Type Lesson Overview To enhance an ALE scenario that includes the transfer of additional fields, you first need to enhance the IDoc type. This unit uses the example of fields in a table append to discuss all the steps required for enhancing an IDoc type.

Lesson Objectives After completing this lesson, you will be able to: •

Create an enhancement for an IDoc type and enhance it using a customer segment

Business Example The material master has been enhanced. In addition to the fields allocated by SAP, information on the cheapest competitor product is entered and saved in the application documents. To achieve this, the table MARA has been enhanced by the addition of a table append from the APPEND structure YBIT350. This enhancement should also take effect in the ALE scenario for material master distribution. The customer fields are to be transferred with the IDoc for the message type MATMAS. In the first step, you need to create a segment that contains all additional fields. You want to create an enhancement for the IDoc type in which the customer segment is added as a subsegment of the segment E1MARAM. Hint: For more information on enhancing the material master, see note 44410.

96

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Defining an Enhancement for the IDoc Type

BIT350

Figure 53: Adjustment by Enhancing the IDoc Type If you want to enhance a standard ALE scenario to transfer additional fields, you need to enhance the IDoc type.

Figure 54: Example: Customer Segment Z1BIT350 The APPEND structure contains the following fields:

2002/Q2

Field name

Description

zzartnr

Article number

zzproducer

Manufacturer

Data element

© 2002 SAP AG. All rights reserved.

Type

Length

97

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

Field name

Description

zzprice

Price

zzcurrency

Currency

zzdate

Date

Data element

BIT350

Type

Length

The fields are in internal format, but the IDoc can only contain fields in external format. When creating a segment type, enter the fields (with the same names where possible) and the corresponding data element. The segment editor then automatically calculates the correct length in external format.

Enhancing an IDoc Type You can enhance an SAP IDoc type by adding customer segments. The customer segments are added to an SAP segment as subsegments. When SAP makes compatible enhancements to SAP segments by adding extra fields, further SAP developments and their enhancements are automatically available after upgrading to a new release. The SAP IDoc type is therefore called a basic type, while the term IDoc type is used to describe both the basic type and the enhancement.

Figure 55: Compatible Enhancement of an IDoc Type

98

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Defining an Enhancement for the IDoc Type

Figure 56: Compatible Further Development of the Basic Type

2002/Q2

© 2002 SAP AG. All rights reserved.

99

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Creating an Enhancement for an IDoc Type 1.

Start the IDoc editor. Choose SAP Menu → Tools → Business Communication→ IDoc Basis→ Development → IDoc Types (= transaction WE30)

2.

Choose Extension, and enter a name for the enhancement. Remember to use the customer namespace. (initial character Z or Y, or /abbreviation/, if you have your own namespace)

3.

Choose Create. If this is the first enhancement you have created for the basic type, choose Create New in the subsequent dialog box, and enter the basic type that you want to enhance. Enter a short description and choose Continue. A tree structure is displayed, showing all the segments of the basic type.

4.

Select a segment to which you want to add a customer segment as a subsegment, and choose Create. Enter the name of the additional segment, and enter the attributes. Choose Continue.

5.

When you have inserted all the segments, save the enhancement. Assign a customer development class and a transport request.

6.

Use transaction WE82 to assign the enhancement to the message type. Choose Change followed by the New Entries icon. Enter the message type, basic type, enhancement, and release.

Result You have created an IDoc type that contains your enhancement and all the segments of the basic type.

100

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Defining an Enhancement for the IDoc Type

BIT350

Exercise 5: Enhancing the IDoc Type Exercise Objectives After completing this exercise, you will be able to: • Create an enhancement for the IDoc type ORDLGT01, and attach a customer segment as a subsegment to an SAP segment

Business Example A scenario for ordering materials has been deliberately simplified for this exercise. Some functions have been omitted from the standard scenario. You want to create the order for another SAP system. For the outbound order, the message type ORDLGT is available with an outbound function module for message control. For the incoming order, an inbound function module for the message type ORDLGT is available. In this scenario, the two fields of the purchase order header, INCO1 and INCO2, are not transferred. You want to enhance the scenario by adding these additional fields. In the first step, you enhance the IDoc types.

Task Ensure that both fields of the purchasing document header (table EKKO) are contained as 'Incoterms' in the IDoc. If necessary, enhance the IDoc by adding the appropriate customer segment. 1.

In the IDoc type ORDLGT01, search for a field with the following semantics: Short text: Incoterms Definition: Standard business contract forms that correspond to the rules of the International Chamber of Commerce (ICC). Use: Incoterms determine particular internationally recognized rules with which sales and procurement staff must comply to ensure that goods are successfully dispatched. Example: If goods are sent via a port of shipment, the appropriate incoterm could be "FOB" (Free on Board). You can enter more specific information (such as the name of the port of shipment) in the second incoterms field: For example, FOB Hamburg.

2.

When creating an order, two fields are filled that correspond to the semantics described in task 1. These fields are called INCO1 and INCO2. Find the data elements for these two fields. They are stored in the table for the purchase order header EKKO.

Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

101

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

3.

Check whether the segment Z1INCO## contains segment fields with semantics determined by the data element that you found in task 2. If it does not, change the segment accordingly.

4.

Release the segment Z1INCO## and display the segment documentation.

5.

Create an enhancement ZEXTEN## for the IDoc type ORDLGT01. Insert the segment Z1INCO## as a subsegment of E1HEAD in the enhancement ZEXTEN##. Ensure that Z1INCO## is a mandatory segment. Save the enhancement and assign it to the development class ZBIT350_##.

6.

Assign the enhanced IDoc type to the message type ORDLGT. Choose Environment→ IDoc Type/Message (= transaction WE82). Path: SAP Menu → Tools → Business Communication → IDoc Basis → Development → IDoc Type/Message. Find entries for the message type ORDLGT. Insert a new entry for ORDLGT.

102

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Defining an Enhancement for the IDoc Type

BIT350

Solution 5: Enhancing the IDoc Type Task Ensure that both fields of the purchasing document header (table EKKO) are contained as 'Incoterms' in the IDoc. If necessary, enhance the IDoc by adding the appropriate customer segment. 1.

In the IDoc type ORDLGT01, search for a field with the following semantics: Short text: Incoterms Definition: Standard business contract forms that correspond to the rules of the International Chamber of Commerce (ICC). Use: Incoterms determine particular internationally recognized rules with which sales and procurement staff must comply to ensure that goods are successfully dispatched. Example: If goods are sent via a port of shipment, the appropriate incoterm could be "FOB" (Free on Board). You can enter more specific information (such as the name of the port of shipment) in the second incoterms field: For example, FOB Hamburg. a)

Use the IDoc documentation to display the IDoc type ORDLGT01. To do this, choose SAP Menu → Tools → Business Communication→ IDoc Basis→ Documentation → IDoc Types ORDLGT01

2.

When creating an order, two fields are filled that correspond to the semantics described in task 1. These fields are called INCO1 and INCO2. Find the data elements for these two fields. They are stored in the table for the purchase order header EKKO. a)

3.

does not contain any fields with the above semantics.

Display the transparent table EKKO in the ABAP Dictionary (transaction SE11). Search for fields called INCO1 or INCO2. The data elements always have the same name as the field.

Check whether the segment Z1INCO## contains segment fields with semantics determined by the data element that you found in task 2. If it does not, change the segment accordingly. a)

Navigate to the segment editor. To do this, choose SAP Menu → Tools → Business Communication→ IDoc Basis→ Development → IDoc Segments (= transaction WE31). Double click on the segment name to display the details.

Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

103

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

4.

Release the segment Z1INCO## and display the segment documentation. a) b)

5.

Return to the initial screen of the segment editor. Choose Edit→ Set Release to release the segment. To display the segment Z1INCO##, choose SAP Menu → Tools → Business Communication → IDoc Basis → Documentation → IDoc Segments(= transaction WE62). Repeat the steps from task 1 to display the documentation.

Create an enhancement ZEXTEN## for the IDoc type ORDLGT01. Insert the segment Z1INCO## as a subsegment of E1HEAD in the enhancement ZEXTEN##. Ensure that Z1INCO## is a mandatory segment. Save the enhancement and assign it to the development class ZBIT350_##. a) b)

6.

BIT350

See the procedure Creating an Enhancement for an IDoc Type. To display ORDLGT01, choose SAP Menu → Tools → Business Communication → IDoc Basis → Development → IDoc Types (= transaction WE30)

Assign the enhanced IDoc type to the message type ORDLGT. Choose Environment→ IDoc Type/Message (= transaction WE82). Path: SAP Menu → Tools → Business Communication → IDoc Basis → Development → IDoc Type/Message. Find entries for the message type ORDLGT. Insert a new entry for ORDLGT. a) b)

104

Choose Position to find entries for the message type ORDLGT. Choose Change, followed by New Entries. Create an entry for the message type ORDLGT, basic type ORDLGT01, and enhancement ZEXTEN## for release 4.6C.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Defining an Enhancement for the IDoc Type

BIT350

Lesson Summary You should now be able to: • Create an enhancement for an IDoc type and enhance it using a customer segment

2002/Q2

© 2002 SAP AG. All rights reserved.

105

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Lesson: Enhancements in Inbound Processing Lesson Overview In order to enhance an ALE scenario that includes the transfer of additional fields, you have enhanced an IDoc type. This lesson discusses all the steps required for enhancing inbound processing. It is assumed that the application enhancement is based on a table append, and that the database change, including the append fields, is therefore included in the SAP standard. You want to enhance inbound processing so that the contents of the segment fields in the customer segment are copied to the corresponding fields in the application. The field types used mean that conversions are required that exceed the type conversion of the MOVE statement.

Lesson Objectives After completing this lesson, you will be able to: •

List the steps required for implementing an enhancement in inbound processing

Business Example The material master has been enhanced. In addition to the fields allocated by SAP, information on the cheapest competitor product is also entered and saved in the application documents. To achieve this, the database table MARA has been enhanced by the addition of a table append from the APPEND structure YBIT350. This enhancement should also take effect in the ALE scenario for material master distribution. The customer fields should be transferred with the IDoc for the message type MATMAS. For this purpose, an enhancement of the IDoc type MATMAS03 has been created, which contains an additional segment as a subsegment of E1MARAM. You want to enhance inbound processing in this way, on the condition that the fields of this segment are filled. The fields of the segment are to be converted to internal format and saved in the append fields for the database table MARA, together with the material master application document. If possible, you want to achieve this using an enhancement. In the first step, you need to check whether an enhancement that you can use to make your adjustment is available in the inbound function module of the application . This enhancement must be processed at a point when the IDoc data is known, but the application document has not yet been written. You therefore only need to consider enhancements in the inbound function module of the application. Application documents are often realized using update function modules, in which enhancements can also be possible. These enhancements cannot be used, because the IDoc data is not recognized in the update function module.

106

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Inbound Processing

BIT350

Figure 57: ALE Services 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.

2002/Q2

© 2002 SAP AG. All rights reserved.

107

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Figure 58: Enhancement for Append Fields in Inbound Processing In this scenario, an application table has been enhanced using a table append. In the inbound program, a structure must exist for the application data in internal format. This structure normally has the same row type as the application table in which the application document is saved. In this case, the fields of the append structure are automatically available in the structure. Before you can use an enhancement for inbound processing, the following requirements must be met: • •

•

The enhancement must be processed before the application document is written. The interface must contain a structure as an IMPORT parameter and as an EXPORT or CHANGING parameter, with the same row type as the application table. Alternatively, it can contain a TABLES parameter, with the row type of the application table. The data records of the IDoc, or at least the customer segment, must be transferred to an IMPORT parameter of the enhancement.

You then need to program the conversions, consistency checks, and field mapping from the fields of your customer segment into the fields of the APPEND structure. The normal conversion rules apply here.

108

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Inbound Processing

BIT350

Figure 59: Example: Enhancements in Inbound Processing For transparency and consistency in the diagrams, the variables have descriptive names: A structure with the line type EDIDD is called edidd_s, and a structure that has the same row type as the database table mara, is called mara. There is no naming convention for variables in inbound programs. You therefore need to use the typing to determine the name of the corresponding variables. For the inbound program IDOC_INPUT_MATMAS01 for the message type MATMAS, the header line of the internal table IDOC_DATA is used instead of edidd_s. The function module exit call in this program is: CALL CUSTOMER-FUNCTION '002' EXPORTING MESSAGE_TYPE

= IDOC_CONTRL-MESTYP

F_CUST_SEGMENT

= USER_SEGMENTS

TABLES

RES_FIELDS

= T_RES_FIELDS

CHANGING

F_MARA_UEB

= I_MARA_UEB

EXCEPTIONS APPLICATION_ERROR = 1 OTHERS

= 2.

The name of the message type (parameter MESSAGE_TYPE) and a row of the IDoc with a customer segment (parameter USER_SEGMENTS) is transferred to the enhancement, and a row of type MARA is filled with SAP fields and transferred to the enhancement. If append fields are defined, these can be filled in the enhancement and are returned to the program.

2002/Q2

© 2002 SAP AG. All rights reserved.

109

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Figure 60: Example: Enhancements in Inbound Processing: Details In the enhancement, the field sdata can be copied, with the data of the customer segment, into a structure that is typed with the row type of the customer segment type. The fields must then be converted to internal format, and copied to the target fields of the append structure.

110

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Inbound Processing

BIT350

Exercise 6: Enhancing Inbound Processing Exercise Objectives After completing this exercise, you will be able to: • Enhance inbound processing for the message type ORDLGT so that the fields of the additional customer segment are also saved in the application document.

Business Example A scenario for ordering materials has been deliberately simplified for this exercise. Some of the functions from the standard scenario have been omitted. You want to create the order for another SAP system. For the outbound order, the message type ORDLGT is available with an outbound function module for message control. For the incoming order, an inbound function module for the message type ORDLGT is available. In this scenario, the two fields of the purchase order header, INCO1 and INCO2, are not transferred. You want to enhance the scenario by the addition of these fields. You have already enhanced the IDoc type, and you now want to enhance inbound processing.

Task Implement the enhancement for inbound processing.

2002/Q2

1.

A customer exit is available in the inbound function module The interface contains a structure with the two fields and . INCO1 INCO2 If they are not initial, the inbound program writes both fields in the inbound application document. Check the interface of the enhancement. Which steps do you need to implement to ensure that the customer segment fields are written from the IDoc into the application document? Which conversions are required?

2.

Implement the enhancement.

BIT350_INPUT_##.

© 2002 SAP AG. All rights reserved.

111

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Solution 6: Enhancing Inbound Processing Task Implement the enhancement for inbound processing. 1.

A customer exit is available in the inbound function module BIT350_INPUT_##. The interface contains a structure with the two fields INCO1 and INCO2. If they are not initial, the inbound program writes both fields in the inbound application document. Check the interface of the enhancement. Which steps do you need to implement to ensure that the customer segment fields are written from the IDoc into the application document? Which conversions are required? a)

b)

c) 2.

The export interface parameter pe_vbak621 contains the two fields INCO1 and INCO2, which are typed with the data elements, in the same way as they are entered for the segment fields of the segment Z1INCO##. The whole data part of the IDoc is transferred to the enhancement as the TABLES parameter pt_idoc_data_records. The row with the customer segment must be read from the internal table pt_idoc_data_records. Copy the field sdata into a structure with the segment type Z1INCO##. Then copy the fields of this structure into the same fields of the export parameter pe_vbak621. Because both fields are only text fields, no conversion is necessary.

Implement the enhancement. a)

DATA edidd_s TYPE edidd. DATA z1inco##_s TYPE z1inco##.

READ TABLE pt_idoc_data_records INTO edidd_s WITH KEY segnam = 'Z1INCO##'. IF sy-subrc = 0. MOVE edidd_s-sdata TO z1inco##_s. MOVE z1inco##_s-inco1 TO pe_vbak621-inco1. MOVE z1inco##_s-inco2 TO pe_vbak621-inco2. ENDIF.

112

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Inbound Processing

BIT350

Lesson Summary You should now be able to: • List the steps required for implementing an enhancement in inbound processing

2002/Q2

© 2002 SAP AG. All rights reserved.

113

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Lesson: Enhancements in Outbound Processing: Adjusting the Master IDoc Lesson Overview In order to enhance an ALE scenario that includes the transfer of additional fields, you have enhanced an IDoc type. This lesson discusses all the steps required for enhancing outbound processing. It is assumed that the enhancement is based on a table append, and that current data is entered in the append fields. You want to enhance outbound processing so that the contents of the table append fields are copied into the corresponding segment fields, and the segment is inserted into the master IDoc. The field types used mean that conversions are required that exceed the automatic type conversion of the MOVE statement.

Lesson Objectives After completing this lesson, you will be able to: •

List the steps required for implementing an enhancement in outbound processing

Business Example The material master has been enhanced. In addition to the fields allocated by SAP, information on the cheapest competitor product is also entered and saved in the application documents. To achieve this, the database table MARA has been enhanced by the addition of a table append from the APPEND structure YBIT350. This enhancement should also take effect in the ALE scenario for material master distribution. The customer fields are to be transferred with the IDoc for the message type MATMAS. For this purpose, an enhancement of the IDoc type MATMAS03 has been created that contains an additional segment as a subsegment of E1MARAM. In the outbound program that structures the master IDoc for the IDoc type MATMAS03, you now want to fill the additional customer segment and insert it into the master IDoc. If possible, you want to achieve this using an enhancement. In many applications, it is already possible to enhance an ALE scenario using customer fields. Immediately after attaching an SAP segment to the master IDoc, an enhancement is provided. You can then use this enhancement to fill a customer segment. Application development can enable this in the following ways: •

114

The application calls an enhancement that returns a structure of the type EDIDD to the program. In the enhancement, enter the name of your segment type in the field SEGNAM, and enter the data for the

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Outbound Processing: Adjusting the Master IDoc

BIT350

•

segment in the field SDATA. Immediately after the enhancement, the program checks whether the structure contains a permitted customer segment, and attaches the segment to the master IDoc. The application calls an enhancement that is contained in the master IDoc as the interface parameter TABLES. In this example, you enter the segment data into a structure of type EDIDD, and insert it beneath the parent segment in the master IDoc.

You also need to change the control record before the function module is called: Enter the enhancement in the field CIMTYP. You have the following options for doing this: MASTER_IDOC_DISTRIBUTE

•

•

The enhancement of the application contains an EXPORT parameter, which is used to transfer the name of the enhancement to the application program. The application program copies this name into the corresponding field of the control record before calling the function module MASTER_IDOC_DISTRIBUTE. The enhancement contains a CHANGING parameter for the control record. In this case, you can copy the name of the enhancement directly into the field CIMTYP of this parameter in the enhancement.

Figure 61: Example: Enhancement in the Program MASTERIDOC_CREATE_MATMAS

In our example scenario, an enhancement for customer segments of the segment E1MARAM is planned in the outbound program MASTERIDOC_CREATE_MATMAS. You can fill the segment and attach it to the master IDoc in this enhancement. Using the interface, enter the name of

2002/Q2

© 2002 SAP AG. All rights reserved.

115

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

your enhancement to the IDoc type MATMAS03. The application program copies this name into the control record before it calls the function module MASTER_IDOC_DISTRIBUTE.

Figure 62: Implementing the Enhancement in Outbound Processing In this example scenario, you want to fill the customer segment Z1BIT350 with values from the table append for the table MARA. In the outbound program MASTERIDOC_CREATE_MATMAS, a customer exit is called after the segment E1MARAM has been created and the segment has been inserted in the master IDoc (line 251): APPEND T_IDOC_DATA. *

.....Customer exit

CALL CUSTOMER-FUNCTION '002' EXPORTING MESSAGE_TYPE = MESSAGE_TYPE SEGMENT_NAME = C_SEGNAM_E1MARAM F_MARA

= MARA IMPORTING

IDOC_CIMTYPE = IDOC_CIMTYPE TABLES IDOC_DATA

= T_IDOC_DATA.

The names of the message type and the current segment type are transferred to the enhancement. The parameter F_MARA is used to transfer the row of the database table MARA (including the fields of the table append) to the enhancement. Some lines previously, this structure is filled using SELECT SINGLE * FROM MARA. The fields of the table append are therefore not only contained in the structure MARA, but are also filled with the current field values from the database table of the sending system. It is therefore unnecessary to re-access the database table MARA within the enhancement.

116

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Outbound Processing: Adjusting the Master IDoc

BIT350

Within the enhancement, you need the following data objects: •

Internal table for the master IDoc The application program transfers the master IDoc using the TABLES parameter IDOC_DATA. TABLES parameters technically act in the same way as CHANGING parameters. You can contact the data object directly using the parameter name.

•

Structure for the customer segment with row type EDIDD

Fill this segment with the required data from the control part and the data part, and attach it to the master IDoc. Because the master IDoc is transferred as the TABLES parameter IDOC_DATA, and TABLES parameters are always internal tables with header lines, you can use the header line. We explicitly define a help structure with the name EDIDD_S. •

Structure with the row type of the segment type This structure contains all fields of the customer segment with the data types of the external format. This help structure simplifies the conversion from internal to external format.

•

Structure with application data, with the row type of the database table MARA This structure is transferred to the enhancement as the IMPORT parameter F_MARA.

Within the enhancement, you need to carry out the following steps: • • • • • •

2002/Q2

Convert the fields of the table append into external format Copy the field contents in external format into the corresponding fields of the structure with the segment type Copy the structure with the segment type into the field sdata of the structure with row type edidd Copy the name of the segment type into the field segnam of the structure with the row type edidd. Attach this structure to the internal table idoc_data. Enter the name of the IDoc type enhancement in the export parameter idoc_cimtype.

© 2002 SAP AG. All rights reserved.

117

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Entering an Enhancement in the Partner Profile

Figure 63: Sender: Partner Profile (Outbound) In the partner profile, enter the name of the enhancement in the settings for outbound processing.

118

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Outbound Processing: Adjusting the Master IDoc

BIT350

Exercise 7: Enhancing Outbound Processing Exercise Objectives After completing this exercise, you will be able to: • Enhance the outbound processing for the message type ORDLGT so that an additional segment is inserted

Business Example A scenario for ordering materials has been deliberately simplified for this exercise. Some of the functions from the standard scenario have been omitted. You want to create the order for another SAP system. For the outbound order, the message type ORDLGT is available with an outbound function module for message control. For the incoming order, an inbound function module for the message type ORDLGT is available. In this scenario, the two fields of the purchase order header, INCO1 and INCO2, are not transferred. You want to enhance the scenario by the addition of these fields. You have already enhanced the IDoc type, and you now want to enhance outbound processing.

Task Find an enhancement for the outbound processing of ORDLGT, which you can use to insert a segment in the master IDoc. Implement the enhancement. 1.

Check whether you can use the components for outbound processing from the customer exit BIT350## to enhance the master IDoc by adding your customer segment. Which conditions does the scenario require of the interface for the enhancement components? Hint: Message control uses the settings in the partner profile to determine whether an enhancement is entered for the IDoc type. In this case, it enters the name of the enhancement in the CIMTYP field of the control record. You therefore do not need to change the control record in this scenario.

2.

2002/Q2

In project management (transaction CMOD), change your project BIT##. Enhance the components for outbound processing so that the master IDoc is changed according to your IDoc type enhancement. Activate the include and the enhancement.

© 2002 SAP AG. All rights reserved.

119

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Solution 7: Enhancing Outbound Processing Task Find an enhancement for the outbound processing of ORDLGT, which you can use to insert a segment in the master IDoc. Implement the enhancement. 1.

Check whether you can use the components for outbound processing from the customer exit BIT350## to enhance the master IDoc by adding your customer segment. Which conditions does the scenario require of the interface for the enhancement components? Hint: Message control uses the settings in the partner profile to determine whether an enhancement is entered for the IDoc type. In this case, it enters the name of the enhancement in the CIMTYP field of the control record. You therefore do not need to change the control record in this scenario. a)

There is only one enhancement in the outbound function module. You can use this enhancement if the following requirements are met: •

•

Both the fields INCO1 and INCO2, together with the values for the current order from the database table EKKO, must be transferred from the program to the enhancement. The parameter PI_EKKO is used for this. The master IDoc must be transferred to the enhancement so it can be changed in the enhancement, and then returned to the program. The TABLES parameter PT_IDOC_DATA_RECORDS carries out this task.

Continued on next page

120

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements in Outbound Processing: Adjusting the Master IDoc

BIT350

2.

In project management (transaction CMOD), change your project Enhance the components for outbound processing so that the master IDoc is changed according to your IDoc type enhancement. Activate the include and the enhancement.

BIT##.

a)

Replace ## in the following source text with your group number and compare it to your solution. Because the enhancement function module occurs immediately after the segment E1HEAD is filled, the internal table is created by attaching the customer segment. If this is not guaranteed, you also need to check in the source text that the customer segment is inserted in the line following the parent segment. The following source text is therefore sufficient: DATA z1inco##_s TYPE z1inco##. DATA edidd_s TYPE edidd. z1inco##_s-inco1 = pi_ekko-inco1. z1inco##_s-inco2 = pi_ekko-inco2. MOVE z1inco##_s TO edidd_s-sdata. edidd_s-segnam = 'Z1INCO##'. APPEND edidd_s TO pt_idoc_data_records.

In general, you should only insert a customer segment if the parent segment is contained in the internal table. If you haven't checked exactly at which point the enhancement is called, it is safer to insert the customer segment beneath the parent segment using an INSERT statement. The source text would then be: DATA z1inco##_s TYPE z1inco##. DATA edidd_s TYPE edidd. DATA tabix LIKE sy-tabix. * Check whether parent segment is available and * copy index in system field SY-TABIX

READ TABLE pt_idoc_data_records WITH KEY segnam = 'E1HEAD' TRANSPORTING NO FIELDS IF sy-subrc = 0. z1inco##_s-inco1 = pi_ekko-inco1. z1inco##_s-inco2 = pi_ekko-inco2. MOVE z1inco##_s TO edidd_s-sdata. edidd_s-segnam = 'Z1INCO##'. tabix = sy-tabix + 1. INSERT edidd_s INTO pt_idoc_data_records INDEX tabix. ENDIF.

2002/Q2

© 2002 SAP AG. All rights reserved.

121

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Lesson Summary You should now be able to: • List the steps required for implementing an enhancement in outbound processing

122

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Test, Transport, and Customizing

BIT350

Lesson: Test, Transport, and Customizing Lesson Overview You have enhanced an ALE scenario, including enhancement of the IDoc type, inbound processing, and outbound processing. To test whether the enhanced scenario works, you need to enter the enhancement in the outbound partner profile of the sender system. This lesson discusses Customizing and transport topics to enable you to test the scenario in a distributed system landscape. It also describes the different options for system landscapes.

Lesson Objectives After completing this lesson, you will be able to: • •

Test an enhanced scenario List what you need to check when transporting into the quality system landscape

Business Example You want to test the enhanced ALE scenario as realistically as possible, but you only have access to one SAP system with multiple clients. To judge whether this is sufficient for your requirements, you want to examine the different possibilities for representing your productive system landscape in your test system landscape.

Figure 64: Testing Processing

2002/Q2

© 2002 SAP AG. All rights reserved.

123

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

The system landscape determines which activities you need to perform to test the enhancement using your scenario. You have various options for doing this. The most important cases are summarized in the following procedures.

124

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Test, Transport, and Customizing

BIT350

Testing in a Development System with Two Clients Prerequisites • • •

•

You are developing the enhancements in a development system, in the client NNN. You have implemented and activated the enhancements. A logical system name is assigned to each client NNN and MMM. You want to send the IDocs from the client NNN to the client MMM. In the following procedures, the development system is called DEV and the logical system names are DEVCLNTNNN and DEVCLNTMMM. The application Customizing settings have been made so you can test the scenario to be enhanced. This includes all the settings for the sending system in client NNN, and all the settings for the receiving system in client MMM. A partner with these Customizing settings exists in the partner profile.

Procedure 1.

In the development system, create a destination that leads to client MMM.

2.

In client NNN, set up a port of type tRFC that references the RFC destination from step 1.

3.

Maintain the distribution model in client NNN. Enter the logical system as the sending system, and the logical system DEVCLNTMMM as the target system. DEVCLNTNNN

4.

In client NNN, set up the outbound partner profile. Select the partner and partner type determined by the application. If the IDoc is generated using message control, you also need to consider the message control settings. For the same partner, also maintain outbound parameters for the message type SYNCH with the same RFC destination. This is a prerequisite for the Track IDocs function in the status monitor.

5.

In client NNN, set up the inbound partner profile. To determine which partner to maintain the inbound partner profile for, the simplest method is to generate an IDoc using the application program, and analyze the control record of the IDoc in the status monitor. On the Partner tab page, you can find the information in the Sender Information group box. Note the partner, partner type, and partner role.

6.

2002/Q2

Use transaction WE42 in client MMM to check whether the inbound process codes are available. If not, use Transport Customizing or Compare Customizing with the view cluster VED_TMSG1.

© 2002 SAP AG. All rights reserved.

125

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Testing in a Development System with One Client Prerequisites • • •

• •

You are developing the enhancements in a development system, in client NNN. You have implemented and activated the enhancements. A logical system name is assigned to the client. In the following procedures, the development system is called DEV, and the logical system name is DEVCLNTNNN. The application Customizing settings have been made so you can test the scenario to be enhanced. A partner with these Customizing settings exists in the partner profile.

Procedure

126

1.

In the development system, create a destination that leads to client NNN.

2.

In client NNN, set up a port of type tRFC that references the RFC destination from step 1.

3.

Maintain the distribution model in client NNN. Enter the logical system DEVCLNTNNN as the sending system, and a logical system that is not assigned to a client as the target system.

4.

In client NNN, set up the outbound partner profile. Select the partner and partner type determined by the application. If the IDoc is generated using message control, you also need to consider the message control settings. For the same partner, also maintain outbound parameters for the message type SYNCH with the same RFC destination. This is a prerequisite for the Track IDocs function in the status monitor.

5.

In client NNN, set up the inbound partner profile. The simplest way of determining which partner to maintain the inbound partner profile for is to generate an IDoc using the application program, and analyze the control record of the IDoc in the status monitor. On the Partner tab page, you can find the information in the Sender Information group box. Note the partner, partner type, and partner role.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Test, Transport, and Customizing

BIT350

Testing in a Single Client From Two Different SAP Systems Use This is the most realistic test situation. It requires transport of the development objects that belong to the enhancement. You therefore have to release the development request before testing.

Prerequisites • •

•

•

You are developing the enhancements in a development system, in client NNN. You have implemented and activated the enhancements. A logical system name is assigned to the clients NNN and MMM. You want to send the IDocs from the client NNN to the client MMM. In the following procedures, the development system is called DEV, and the logical system names are DEVCLNTNNN and DEVCLNTMMM. The application Customizing settings have been made so you can test the scenario being enhanced. This includes all the settings for the sending system in client NNN, and all the settings for the receiving system in client MMM. A partner with these Customizing settings exists in the partner profile.

Procedure 1.

In the development system, create a destination that leads to client MMM.

2.

In client NNN, set up a port of type tRFC that references the RFC destination from step 1.

3.

Maintain the distribution model in client NNN. Enter the logical system as the sending system, and the logical system DEVCLNTMMM as the target system. DEVCLNTNNN

4.

In client NNN, set up the outbound partner profile. Select the partner and partner type determined by the application. If the IDoc is generated using message control, you also need to consider the message control settings. For the same partner, also maintain outbound parameters for the message type SYNCH with the same RFC destination. This is a prerequisite for the Track IDocs function in the status monitor.

5.

In client NNN, set up the inbound partner profile. The simplest way of determining which partner to maintain the inbound partner profile for is to generate an IDoc using the application program, and analyze Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

127

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

the control record of the IDoc in the status monitor. On the Partner tab page, you can find the information in the Sender Information group box. Note the partner, partner type, and partner role. 6.

Use transaction WE42 in client MMM to check whether the inbound process codes are available. If not, use Transport Customizing or Compare Customizing with the view cluster VED_TMSG1.

Figure 65: Sender: Partner Profile (Outbound) For an enhancement of an IDoc type to be used in a distribution scenario, the following prerequisites must be met: • • • • •

128

The enhancement for the IDoc has been created. Additional segments are permitted. The IDoc type is assigned to a message type. In addition to the basic type, the enhancement is also entered in the partner profile. At runtime, the master IDoc is enhanced by additional segments. At runtime, the name of the enhancement is entered in the CIMTYP field of the IDoc.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Test, Transport, and Customizing

BIT350

Exercise 8: Testing the Enhancement Exercise Objectives After completing this exercise, you will be able to: • Test the enhancement you have created in the previous exercises.

Business Example A scenario for ordering materials has been deliberately simplified for this exercise. Some of the functions from the standard scenario have been omitted. You want to create the order for another SAP system. For the outbound order, the message type ORDLGT is available with an outbound function module for message control. For the incoming order, an inbound function module for the message type ORDLGT is available. In this scenario, the two fields of the purchase order header, INCO1 and INCO2, are not transferred. You want to enhance the scenario by adding these fields. You have finished implementing the enhancement and now want to test the scenario.

Task Check whether all the required settings have been made for the enhancement. Then create an order, and check whether the generated IDocs have been processed without errors in inbound processing and outbound processing. 1.

Using transaction WE82, check whether your enhancement ZEXTEN## has been assigned to the message type ORDLGT, the basic type ORDLGT01, and Release 4.6C. If it has not, make these assignments.

2.

Make the appropriate change in the outbound partner profile for the partner T-BIL## by entering the enhancement.

3.

Test the scenario using the CATT from the exercise in Unit 3: Use the CATT to create an order. Choose System → Services → CATT → Record (= transaction SCEM. ). Enter the test case YBIT350_ME21_##, and execute it. Use transaction BD87 to check whether the outbound and inbound IDocs now contain the fields INCO1 and INCO2.

2002/Q2

© 2002 SAP AG. All rights reserved.

129

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Solution 8: Testing the Enhancement Task Check whether all the required settings have been made for the enhancement. Then create an order, and check whether the generated IDocs have been processed without errors in inbound processing and outbound processing. 1.

Using transaction WE82, check whether your enhancement ZEXTEN## has been assigned to the message type ORDLGT, the basic type ORDLGT01, and Release 4.6C. If it has not, make these assignments. a)

2.

Make the appropriate change in the outbound partner profile for the partner T-BIL## by entering the enhancement. a)

3.

Follow the procedure Creating an Enhancement for an IDoc Type in the lesson Defining an Enhancement for an IDoc Type.

In transaction WE20: Change the outbound parameter for ORDLGT. Enter your enhancement ZEXTEN##.

Test the scenario using the CATT from the exercise in Unit 3: Use the CATT to create an order. Choose System → Services → CATT → Record (= transaction SCEM. ). Enter the test case YBIT350_ME21_##, and execute it. Use transaction BD87 to check whether the outbound and inbound IDocs now contain the fields INCO1 and INCO2. a)

130

Select your IDoc(s) using the partner T-BIL##. Display the data records of the outbound IDoc and the inbound IDoc. Check whether your segment Z1INCO## is attached beneath the segment E1HEAD, and whether the fields INCO1 and INCO2 are included and filled.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Test, Transport, and Customizing

BIT350

Lesson Summary You should now be able to: • Test an enhanced scenario • List what you need to check when transporting into the quality system landscape

2002/Q2

© 2002 SAP AG. All rights reserved.

131

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

Lesson: Enhancements for Customer Tables Lesson Overview If the ALE scenario enhancement is based on an application enhancement with customer database tables, you also need to program the updates of the database tables. To guarantee consistency, the method for the database changes must be adjusted to the method of the standard scenario. This requires detailed knowledge of the SAP transaction concept. This lesson describes the points at which you need to make changes.

Lesson Objectives After completing this lesson, you will be able to: •

Describe which additional checks are necessary if you want to enhance a scenario for customer tables

Business Example You have enhanced an SAP application. Customer database tables have been created within this enhancement. The enhanced application is involved in a distributed business process. You therefore want to enhance an ALE scenario so that the additional fields are also transferred. An enhancement that is based on additional customer tables instead of table appends requires more work.

Figure 66: Adjustment by Enhancing the IDoc Type

132

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Enhancements for Customer Tables

Figure 67: Enhancement for Append Fields in Inbound Processing If the application is based on append fields for SAP database tables, you normally do not need to change the function module that contains the database changes. In an enhancement, you only need to ensure that the append fields of the corresponding structure or internal table (in internal format) are filled before the database change is made.

Figure 68: Enhancement for Customer Tables

2002/Q2

© 2002 SAP AG. All rights reserved.

133

Unit 5: Adjusting a Scenario With Enhancement of the IDoc Type

BIT350

For customer database tables, you also need to implement the OPEN_SQL statement that leads to the database table update. Ideally, you can use the function modules that have already been created for the application enhancement. For the ALE scenario, however, you need to adjust the method that is used to update the SAP database tables of the same LUW.

Figure 69: Enhancement Using Customer Update Module If the SAP tables are refreshed by update, you also need to refresh the customer tables using update. This normally means that you program an update function module, and call this from the enhancement using the addition IN UPDATE TASK. For an enhancement like this, you should have basic knowledge of the SAP transaction concept. Hint: The easiest way to find out whether an inbound function module generates SAP application documents by update is to execute a where-used list for the export parameter IN_UPDATE_TASK. If this parameter in the function module is set to 'X', then an update is implemented.

134

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Enhancements for Customer Tables

BIT350

Lesson Summary You should now be able to: • Describe which additional checks are necessary if you want to enhance a scenario for customer tables

2002/Q2

© 2002 SAP AG. All rights reserved.

135

Unit Summary

BIT350

Unit Summary You should now be able to: • Create an enhancement for an IDoc type and enhance it using a customer segment • List the steps required for implementing an enhancement in inbound processing • List the steps required for implementing an enhancement in outbound processing • Test an enhanced scenario • List what you need to check when transporting into the quality system landscape • Describe which additional checks are necessary if you want to enhance a scenario for customer tables

136

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

Test Your Knowledge 1.

You can enhance any SAP IDoc type by inserting the additional segment as a subsegment. Determine whether this statement is true or false.

True False 2.

To enhance an ALE scenario, you only need to enhance the IDoc type. Determine whether this statement is true or false.

True False 3.

Which steps do you need to program to provide the fields of an append structure with data from an IDoc segment?

4.

Fields from application structures can be copied into the segment fields of an IDoc using the MOVE statement. Because the MOVE statement uses automatic type conversion, no additional conversion is necessary. Determine whether this statement is true or false.

True False 5.

To test an enhanced ALE scenario Choose the correct answer(s).

A B C

D

2002/Q2

The test landscape, in terms of the systems and clients, must be identical to the productive system landscape. Systems are required that have the same application Customizing as the productive systems. As many (logical) productive systems as possible that are involved in the ALE scenario should be represented by one client in the test landscape. The development objects and Customizing settings that have been created or changed in the enhancement must first be transported into the test systems.

© 2002 SAP AG. All rights reserved.

137

Test Your Knowledge

6.

BIT350

If the application table of an ALE scenario is generated using asynchronous update, you also have to asynchronously update the database tables that you want to update in the same LUW. Determine whether this statement is true or false.

True False

138

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

Answers 1.

You can enhance any SAP IDoc type by inserting the additional segment as a subsegment. Answer: True Logically, the enhancement usually affects an SAP segment.

2.

To enhance an ALE scenario, you only need to enhance the IDoc type. Answer: False In outbound processing, you also need to use program enhancements to ensure that the additional segment is filled and inserted into the master IDoc. In inbound processing, you usually need to use a program enhancement to ensure that additional fields are written to the database.

3.

Which steps do you need to program to provide the fields of an append structure with data from an IDoc segment? Answer: First you need to copy the field sdata of the IDoc segment into a structure typed with the segment type. You can then access the individual fields without having to program offsets. The field contents must be converted from the external format into the internal format, and finally you can copy them into the fields of the append structure.

4.

Fields from application structures can be copied into the segment fields of an IDoc using the MOVE statement. Because the MOVE statement uses automatic type conversion, no additional conversion is necessary. Answer: False IDoc fields must always have an external format. Type conversion is therefore required for some fields. Examples: Units must be entered in ISO codes. Amounts must have the correct decimalization. Numbers must be entered left-justified into IDoc fields.

2002/Q2

© 2002 SAP AG. All rights reserved.

139

Test Your Knowledge

5.

BIT350

To test an enhanced ALE scenario Answer: B, C, D Ideally, you would have a threefold system landscape, with three identical levels for development, testing, and productive operation. If this is not possible for cost reasons, at least enough clients should be available in the test systems to represent the different logical systems of the productive landscape. Whatever the system landscape, testing is never carried out in the development system. The development objects and Customizing settings therefore have to be transported.

6.

If the application table of an ALE scenario is generated using asynchronous update, you also have to asynchronously update the database tables that you want to update in the same LUW. Answer: True If the application documents are generated by asynchronous processing, the inbound function module of the application must set the parameter IN_UPDATE_TASK to X.

140

© 2002 SAP AG. All rights reserved.

2002/Q2

Unit 6 Optimization of ALE Processes Unit Overview Optimization of ALE processes can be necessary for various reasons: •

If performance problems occur. You are looking for ways to improve runtime

•

Update procedures lead to inconsistencies between different systems. You are looking for options to serialize inbound processing

•

You want to distribute master data that is interdependent, but which is distributed by different message types. You are therefore looking for ways to ensure that IDocs for different message types are processed in a particular order in inbound processing.

This unit explains which settings you can use to ensure that IDocs are processed in packages, or in parallel. You will become familiar with three different serialization mechanisms. Within this context, you will also be shown how to check whether a scenario requires serialization, and which mechanism can be used for serialization. For dependent master data, you will learn how to implement serialization using message types (serialization groups).

Unit Objectives After completing this unit, you will be able to: • • • • •

2002/Q2

Describe the settings required for sending or processing IDocs in packages Describe the prerequisites for package processing Describe the settings required for sending or processing IDocs using parallel processing Describe time stamp serialization Check whether a scenario uses time stamp serialization

© 2002 SAP AG. All rights reserved.

141

Unit 6: Optimization of ALE Processes

• • • •

BIT350

Describe how you can ensure serialized processing of dependent master data for different message types Set up serialization by message types (serialization groups) Describe object channel serialization Make the appropriate Customizing settings to activate or deactivate object channel serialization for a scenario

Unit Contents Package Processing ............................................................143 Parallel Processing .............................................................148 Procedure: Defining a Server Group .........................................154 Serialization By Time Stamp ..................................................156 Procedure: Enhancing an ALE Scenario By Time Stamp Serialization .159 Exercise 9: Analyzing an ALE Scenario for Time Stamp Serialization...161 Serialization By Message Types (Serialization Groups) ...................164 Procedure: Creating a Serialization Group ..................................167 Object Channel Serialization ..................................................173

142

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Package Processing

Lesson: Package Processing Lesson Overview You can use package processing to improve the performance of ALE scenarios. This lesson describes which Customizing settings you can make to enable processing of IDocs in packages.

Lesson Objectives After completing this lesson, you will be able to: • •

Describe the settings required for sending or processing IDocs in packages Describe the prerequisites for package processing

Business Example You have noticed that lots of small IDocs are being sent, despite the fact that sending is triggered by background processing. This has created a large number of transaction IDs. You want to group these IDocs together logically and send them as packages to the target system. Inbound processing in the target system is enabled by an inbound program that is capable of mass processing, but the IDocs are still processed individually. You want to transfer multiple IDocs to this inbound program.

Package Processing When Sending via a tRFC Port

Figure 70: Sending Individual IDocs by tRFC

2002/Q2

© 2002 SAP AG. All rights reserved.

143

Unit 6: Optimization of ALE Processes

BIT350

If you enter package size 1 in the partner profile, a transaction ID is generated for each IDoc when IDocs are passed to the communication layer. This transaction ID is then sent to the target system using tRFC. Sending with tRFC involves the following steps: 1.

The IDoc is read from the database. A transaction ID is generated. On the figure Sending Individual IDocs by tRFC, this is number 123456. The IDoc is stored in RFC format under the transaction ID in the tRFC queue.

2.

An RFC connection to the target system is established. If possible, the data package for the transaction ID (here 123456) is transported to the target system.

3.

As soon as the target system has successfully received the data package, it is stored in the database.

4.

The receiving system automatically sends a success message to the sender system.

5.

Immediately after the success message has arrived, the data package for the corresponding transaction ID is deleted from the tRFC queue.

If transfer is not possible, the data package remains in the tRFC queue. To check the content of the tRFC queue, use transaction SM58. If the target system cannot be contacted, the connection is re-established after m minutes. m is determined in the system settings. To check the general settings for the tRFC queue, see transaction SM58. Choose Execute to go from the selection screen to the list, and choose Info → System Settings to display a dialog box with the required information. This system setting can be overridden by a local setting in each RFC destination. Display the RFC destination (for example, using transaction SM59). Choose Destination → tRFC Options.

144

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Package Processing

Figure 71: Sending Packages Using tRFC In the partner profile, you can enter a package size n > 1. n IDocs for one transaction ID are then grouped together. A clever choice of package size can optimize runtime behavior.

Package Processing in Inbound Processing In inbound processing, creating packages also only makes sense for IDocs of the same type. The following variants exist for inbound package processing:

Figure 72: Package Processing Using a Loop

2002/Q2

© 2002 SAP AG. All rights reserved.

145

Unit 6: Optimization of ALE Processes

BIT350

The inbound program of the ALE layer (in background processing, for example, RBDAPP01) provides a selection parameter in which you can choose a package size, n. The program reads the IDoc from the database and calls the corresponding inbound program in a loop that can be executed n times. Each time the loop is executed, one IDoc is transferred to the inbound program. After the nth loop, the LUW is ended by the COMMIT WORK statement. The inbound function module does not have to meet any specific requirements. This type of package processing can therefore be used for all IDocs and is a generic service of the ALE layer.

Figure 73: Package Processing by Inbound Function Modules Capable of Mass Processing The selection parameter of the inbound program also determines the package size here. The program reads n IDocs and groups the control records and the data records together in an internal table, which it passes to the inbound function module. The inbound function module is then technically able to write application documents to the database using array updates. This depends on the implementation of the application inbound function module. The ALE layer chooses this variant for package processing if the inbound module is marked as capable of mass processing. For an inbound module, you can determine this attribute using transaction BD51.

146

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Package Processing

Lesson Summary You should now be able to: • Describe the settings required for sending or processing IDocs in packages • Describe the prerequisites for package processing

2002/Q2

© 2002 SAP AG. All rights reserved.

147

Unit 6: Optimization of ALE Processes

BIT350

Lesson: Parallel Processing Lesson Overview If you use parallel processing effectively, it can improve the performance of an SAP system, by leading to a more balanced work process load. This lesson explains the points in the process at which you can use Customizing settings to enable parallel processing. Hint: Always choose the parameters for optimizing performance by parallel processing in close collaboration with the system administrators. To ensure that you choose suitable values, you also need to consider current profile parameters.

Lesson Objectives After completing this lesson, you will be able to: •

Describe the settings required for sending or processing IDocs using parallel processing

Business Example In your company, some ALE scenarios suffer from performance problems. Before hiring a consultant for the "fine tuning", you want to understand the different principles you can use for parallel processing.

Parallel Processing when Generating IDocs Generation of IDocs can by triggered by a variety of mechanisms. In each mechanism, an ABAP program is run at a particular time that creates a master IDoc and sends it to the ALE layer. Each ABAP program is processed and interpreted by an ABAP Virtual Machine of a work process. There is normally more than one work process on each application server. The attributes of a work process determine whether it is responsible for online programs or for background programs. Scheduling a program as a background job not only means that the program is started at a particular point in time, but also that processing occurs in a different group of work processes. Each user who starts an ABAP program is assigned the next free dialog work process. As soon as a screen is sent, the work process is re-released ready for the next user. The process is similar in background processing. As soon as a work process becomes free, it processes the program for the next job on the list. In this way, when the system is being utilized to its full capacity, as

148

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Parallel Processing

many programs are processed as there are work processes available. The decisive factor for performance is therefore that the relationship between the number of dialog work processes and the number of batch work processes corresponds to the demand for dialog work processes and batch work processes. Some programs that you can schedule in the background support parallel processing. Parts of the program are stored externally in dialog work processes. This is beneficial if the programs are scheduled at night, when dialog work processes are generally not overloaded. It can, however, block any users who are logged on. The different mechanisms are introduced below.

Figure 74: Parallel Processing when Generating IDocs •

Generating IDocs Directly from an Online Program –

without parallel processing Programs that only generate a few IDocs do not normally support parallel processing. All IDocs are generated in the dialog work process that is currently using the online program. This is valid for one instance of the program. If more than one user starts the program simultaneously, or if one user starts the program in several windows at the same time, one instance of the program is generated each time, and is processed independently of the other instances. This generally requires parallel processing.

–

with parallel processing Some programs that directly trigger IDoc generation are designed for generating many IDocs. Parallel processing is implemented within the program. You can normally recognize

2002/Q2

© 2002 SAP AG. All rights reserved.

149

Unit 6: Optimization of ALE Processes

BIT350

this because it will have a selection parameter for a server group, and a selection parameter for the number of application documents that are to be processed in one process. Many programs for directly sending master data are implemented in this way. For examples of programs of this type, see SAP Menu → Tools → ALE → Master Data Distribution. •

Generating IDocs from change pointers The program RBDMIDOC is normally scheduled as a background program. No parallel processing is implemented in this program. It is processed in one work process for each message type. The message type is entered as a selection parameter. The program must therefore be scheduled for more than one message type. Parallel processing can be delayed by a job chain or a serialization mechanism.

•

IDoc generation from message control There are also two variants here –

–

150

The Customizing setting Processing by periodic job (time 1) in the condition record has the effect that the IDoc is only generated from a message record by the program RSNAST00. This program is normally scheduled in the background and does not have parallel processing implemented. It provides a range of different selection parameters. The Customizing setting Process Immediately (when application document is saved) (time 4) in the condition record causes generation of the IDoc to be triggered immediately. In this case, only one IDoc is generated and parallel processing is therefore not necessary.

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Parallel Processing

Parallel Processing for Sending (tRFC Port)

Figure 75: Parallel Processing for Sending (tRFC Port) Parallel processing is automatically used for every package when sending using a tRFC port. It uses (almost) all dialog work processes. Any online users working on the application server used at the time of sending are blocked. There is no option for entering a server group. A profile parameter is obligatory for the number of dialog work processes that must remain free for online users. Hint: A dialog work process is always used for sending a tRFC package. This is independent of whether sending is triggered from an online program or from a background program. When sending a package using tRFC, the communication layer establishes a synchronous RFC connection to the receiving system. The receiving system thus also requires a simultaneous dialog work process. There should therefore be at least as many dialog work processes available on the application server of the receiving system as there are in the sender system.

2002/Q2

© 2002 SAP AG. All rights reserved.

151

Unit 6: Optimization of ALE Processes

BIT350

Parallel Processing in Inbound Processing

Figure 76: Parallel Processing in Inbound Processing In inbound processing, you need to separate the following cases: •

Process Immediately is set in the partner profile for the inbound IDoc. The IDoc is passed to the application in the current dialog work process. The IDoc is processed individually, and the question regarding parallelization in the ALE inbound program is not relevant.

•

Process by Background Job is set in the partner profile for the inbound IDoc. Inbound processing is then normally triggered by a background program, RBDAPP01. This program allows you to use both package processing and parallel processing by specifying server groups.

Server Groups Server groups are used to control which application server or which instance is used for processing. For each server group, you can choose parameters that control, for example, how many of the dialog work processes are not to be used for parallel processing. This ensures that online users are not completely blocked. In parallel processing, the parameters of an RFC server group override the profile parameters of the instance. If more than one instance is assigned to one RFC server group, a

152

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Parallel Processing

query is sent to the message server before every parallel processing call. The message server selects the instance with the least load. Processing then occurs using a dialog work process of this selected instance.

2002/Q2

© 2002 SAP AG. All rights reserved.

153

Unit 6: Optimization of ALE Processes

BIT350

Defining a Server Group

154

1.

To navigate to RFC server group maintenance, choose Tools → Administration → Administration → Network → RFC Destinations (= transaction SM59), followed by RFC → RFC Groups.

2.

Choose Create or Edit → Create Assignment. Enter a name for the RFC server group. Use the search help to select the required instance. Use the field help to look up the meaning of the parameters, and maintain the values.

3.

If an additional instance is assigned to the RFC server group, repeat step 2. Enter the same name but choose a different instance. Maintain the parameters.

4.

Save the changes.

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Parallel Processing

Lesson Summary You should now be able to: • Describe the settings required for sending or processing IDocs using parallel processing

2002/Q2

© 2002 SAP AG. All rights reserved.

155

Unit 6: Optimization of ALE Processes

BIT350

Lesson: Serialization By Time Stamp Lesson Overview Serialization by time stamp is intended for ALE scenarios in which an application document can be changed more than once. In the target system, this prevents a status, which has just been updated by an IDoc, being overwritten by an older status because it has been overtaken during IDoc transfer. In this case, inbound processing must be suppressed. This lesson discusses the runtime behavior of time stamp serialization. You will learn how to recognize which scenarios have implemented time stamp serialization.

Lesson Objectives After completing this lesson, you will be able to: • •

Describe time stamp serialization Check whether a scenario uses time stamp serialization

Business Example Time stamp serialization is only implemented if multiple versions of an application document are posted in quick succession. In this case, IDocs overtaking each other can lead to irreparable inconsistencies in the target system. Example: The application document is changed at 10:00, and the change is sent by IDoc to the target system. For some reason, however, it is not processed immediately in the target system. At 11:00, the application document is changed again and the change is sent by IDoc. This IDoc is processed immediately. At 11.30, RBDAPP01 is scheduled in the target system to process hanging IDocs. Without serialization, this means that the old status (from 10:00) is reinstated. Hint: If you operate a scenario with time stamp serialization, an entry is written in the serialization table BDSER in the target system for every application document. We therefore recommend that you run the report RBDSRCLR regularly to clear old entries from the table.

156

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Time Stamp

BIT350

Figure 77: Serialization By Time Stamp: Runtime Behavior

2002/Q2

1.

Immediately before the IDoc is saved to the database in the sender system, a time stamp is written in the SERIAL field of the control record. This time stamp is sent in the control record, together with the IDoc, to the target system.

2.

In the inbound function module of the application, the function module IDOC_SERIALIZATION_CHECK is used to check whether a serialization entry for the key of the IDoc already exists in the table BDSER. If it does, the time stamp of the last processed IDoc is stored there.

3.

If the time stamp of the current IDoc is older than the time stamp in the serialization table, inbound processing for this IDoc is cancelled. The IDoc is assigned an error status in the inbound function module.

4.

Status information and serialization information is returned to the ALE layer. The ALE layer updates the serialization table BDSER and the status of the IDoc in the database.

© 2002 SAP AG. All rights reserved.

157

Unit 6: Optimization of ALE Processes

BIT350

Figure 78: Serialization By Time Stamp: Serialization Object Type To determine the message types for which time stamp serialization is supported, you can use the following methods: 1.

Use transaction BD57 to check whether an ALE object type is assigned to the message type as a serialization object type.

2.

Use transaction BD59 to check whether segment fields are defined as key fields for time stamp serialization.

3.

Use transaction WE64 to check the inbound function modules for the message type. Navigate to the inbound function module on the Table Parameters tab page. Select the interface parameter SERIALIZATION_INFO, and call the where-used list. If no usage is found, no time stamp serialization is implemented. If a list is displayed, check whether the internal table SERIALIZATION_INFO is filled at a selected point in the program. Hint: For an overview of inbound function modules that use time stamp serialization, you can also execute a where-used list for the function module IDOC_SERIALIZATION_CHECK for each program.

158

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Time Stamp

BIT350

Enhancing an ALE Scenario By Time Stamp Serialization 1.

Check whether you can use an enhancement in the inbound function module for the message type of the scenario. The enhancement must transfer an internal table of the row type BDI_SER to the inbound function module, and the inbound function module must supply its table interface parameter SERIALIZATION_INFO with this information. If the inbound function module does not fulfill this prerequisite, you can only make the enhancement by modification using the modification assistant.

2.

Analyze which key words uniquely identify the application document. Find the database table, and find a structure or transparent table that contains this database table with these key words as a foreign key. Example: Material master data is stored in the database table MARA with the key field MATNR. A customer structure ZMARA contains the fields MANDT and MATNR. For the field MATNR, the transparent table MARA is entered as a check table.

3.

Use transaction BD95 to create an ALE object type in the customer namespace. Assign the structure field that you found in step 2. Example: ALE object type ZMATMAS, table name ZMARA, field name MATNR.

4.

Use transaction BD57 to assign the ALE object type to the message type as a serialization object type. Example: In the row for the message type MATMAS, enter ZMATMAS in the serialization object type column.

5.

Use transaction BD59 to assign the segment fields to the message type for the serialization object type that contains the key fields at runtime. The sequence must be the same as the sequence of key fields in the check table.

6.

Enhance the inbound function module for the message type. Use the function module IDOC_SERIALIZATION_CHECK to obtain current serialization information for the IDoc. Check whether the IDoc has been overtaken. If it has, add the required status value to the status Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

159

Unit 6: Optimization of ALE Processes

BIT350

table, and add the serialization information to the internal table SERIALIZATION_INFO. The database table BDSER is updated by the ALE layer, as long as the table SERIALIZATION_INFO contains at least one entry.

160

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Time Stamp

BIT350

Exercise 9: Analyzing an ALE Scenario for Time Stamp Serialization Exercise Objectives After completing this exercise, you will be able to: • Examine the ALE scenario for the message type BLAREL for time stamp serialization

Business Example You want to analyze whether and how time stamp serialization is implemented for a scenario.

Task Check the extent to which the ALE scenario for the message type BLAREL supports time stamp serialization.

2002/Q2

1.

Check whether a serialization object type is assigned to the message type BLAREL.

2.

Examine the serialization object type that you have found. At runtime, which segment fields contain the value that is used as a key?

3.

Analyze the inbound function module for the message type BLAREL. In which line is the function module IDOC_SERIALIZATION_CHECK called?

4.

Check whether the entries are contained in the database table BDSER.

© 2002 SAP AG. All rights reserved.

161

Unit 6: Optimization of ALE Processes

BIT350

Solution 9: Analyzing an ALE Scenario for Time Stamp Serialization Task Check the extent to which the ALE scenario for the message type BLAREL supports time stamp serialization. 1.

Check whether a serialization object type is assigned to the message type BLAREL. a) b)

2.

Examine the serialization object type that you have found. At runtime, which segment fields contain the value that is used as a key? a)

3.

b)

In transaction WE64, display an overview of all the process codes, sorted by message type. Choose Inbound messages and the message type BLAREL. The process code BLAR defines inbound processing using the function module IDOC_INPUT_BLAREL. Double click on the name of the function module to navigate to the Function Builder. In the Function Builder, choose the Source code tab page. To search for strings in the source code, choose Find. Enter IDOC_SERIALIZATION_CHECK and choose Continue. Line 40 is displayed, in which the function module is called.

Check whether the entries are contained in the database table BDSER. a)

162

You can use transaction BD59 to display the assignments between the ALE object type and the segment field for the message type BLAREL. For the key of the serialization object type, two key fields are specified, as well as the sequence of the key fields for the whole key: The first key field is called EBELN and is in the segment type E1RDOCU; the second key field is called EBELP, and also belongs to the segment type E1RDOCU.

Analyze the inbound function module for the message type BLAREL. In which line is the function module IDOC_SERIALIZATION_CHECK called? a)

4.

You can use transaction BD57 to display the assignments between message types and ALE object types. You can use the Position button to search for message types. Enter BLAREL and choose Continue. The ALE object type EBELP is entered in the Serialization Object Type column.

Start the Data Browser (transaction SE16) and enter the table BDSER. Then choose Execute.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Time Stamp

BIT350

Lesson Summary You should now be able to: • Describe time stamp serialization • Check whether a scenario uses time stamp serialization

2002/Q2

© 2002 SAP AG. All rights reserved.

163

Unit 6: Optimization of ALE Processes

BIT350

Lesson: Serialization By Message Types (Serialization Groups) Lesson Overview In some scenarios, there are logical dependencies between different messages. Certain information and application documents must exist in the system before additional information can be entered. If this information is distributed using different message types, inbound processing can use serialization rules. To enable this, the dependent message types are grouped together in a serialization group. In the serialization group, the sequence is defined as a rule. Inbound processing of the collected IDocs for message types of the serialization group is triggered by a program that follows this rule. All the IDocs for the first message type are processed first, then all IDocs for the second message type, and so on.

Lesson Objectives After completing this lesson, you will be able to: • •

Describe how you can ensure serialized processing of dependent master data for different message types Set up serialization by message types (serialization groups)

Business Example In Logistics, material masters can be assigned to classes. If this information is distributed using an ALE scenario, the following message types are used: • • •

for material masters CLSMAS for classes CLFMAS for the assignment between material and class MATMAS

The materials and classes must exist in the system before the assignment can be entered.

164

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Message Types (Serialization Groups)

BIT350

Serialization Rule in the Target System

Figure 79: Rule in Target System To set up this scenario, carry out the following steps in the target system: 1.

Check whether a serialization group exists in the target system that contains the required message types in the correct order (here: MATMAS, CLSMAS, and CLFMAS). If one does not already exist, create a serialization group.

2.

Maintain the inbound settings for all message types of the serialization group. In transaction SALE, choose: Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Message Types → Define Inbound Processing. Note the following: •

•

2002/Q2

If you leave the Obj/Proc (PSIZE) field initial, the IDocs pass individually to the inbound function module of the application. This can lead to unnecessarily long runtimes. For more information on choosing the package size, see the Package Processing lesson. If you do not select the Parallel field, the inbound function module of the application is processed in the current work process. In this case, all IDocs are processed one after the other.

© 2002 SAP AG. All rights reserved.

165

Unit 6: Optimization of ALE Processes

•

BIT350

If you select the Parallel field, processing is parallel for every package. This only affects processing of IDocs of one message type. Serialization is therefore not affected. For more information on choosing the server group, see the Parallel Processing lesson.

3.

Check the inbound partner profile for all message types involved. If necessary, change the setting to Processing by Background Program.

4.

Check that the program RBDAPP01 is not scheduled for the message types involved. If necessary, change the variant of the program RBDAPP01 so that the affected message types are not selected.

5.

In the receiving system, schedule the program RBDSER04 for transferring IDocs to the application. Create a variant, and enter a serialization group. If necessary, restrict the logical sending systems. Try to schedule the program for a time when the system load is minimal. Note that the inbound settings (TBD41) are used for processing. If the Parallel Processing field is selected, IDocs for the message type are processed in parallel in multiple dialog work processes.

a) b) c)

Hint: To reduce the danger of blocking the system for other users, enter an RFC server group and choose a package size that is not too small.

166

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Message Types (Serialization Groups)

BIT350

Creating a Serialization Group 1.

In transaction SALE, choose: Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Message Types → Define Serialization Groups (= transaction BD44).

2.

Create a serialization group. Choose New Entries and enter a technical name and a short description.

3.

Select the serialization group, and double click on Assignment of logical messages to serial. group to display message type assignment.

4.

Choose New Entries, and assign new message types. Assign a sequence of consecutive numbers.

Serialization Rule in the Sender System: Message Type SERDAT If you want to define the serialization rule in the sending system as well as in the receiving system, you can do this by distributing an IDoc for the message type SERDAT. As in serialization using RBDSER04, the inbound partner processing for all message types of the serialization group should be set to Processing by Background Job. Processing of this IDoc is triggered by the inbound function module of the IDoc for SERDAT, instead of by the program RBDSER04. To implement this serialization, perform the following steps.

2002/Q2

© 2002 SAP AG. All rights reserved.

167

Unit 6: Optimization of ALE Processes

Figure 80: Rule in Sender System: IDoc for

SERDAT

1.

Check whether a serialization group exists in the sender system that contains the message types in the correct order (here: MATMAS, CLSMAS, and CLFMAS). If one does not already exist, create a serialization group.

2.

In the distribution model, maintain distribution for the message type SERDAT for all target systems to which you want to send messages. Distribute the distribution model to the target systems, and regenerate the partner profile in all systems involved.

3.

In the sender system, check the outbound partner profile for all message types involved (here: MATMAS, CLSMAS, CLFMAS, and SERDAT).

4.

Check the inbound partner profile in all target systems as follows: •

•

5.

168

BIT350

If necessary, change the setting to Processing in Background Program for all message types of the serialization group MATMAS, CLSMAS, and CLFMAS). For SERDAT, select Process Immediately, and the process code SERD. Inbound processing of the IDocs of the serialization group must always be triggered indirectly by the inbound processing of the IDoc for SERDAT.

Maintain the inbound settings for all message types of the serialization group. In transaction SALE, choose:

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Serialization By Message Types (Serialization Groups)

BIT350

Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Message Types → Define Inbound Processing. For more information, see the section Serialization Rule in Target System. 6.

Ensure that neither the program RBDAPP01 nor the program RBDSER04 is scheduled for the message types of the serialization group. If necessary, change the variant of the program RBDAPP01 so that the affected message types are not selected. Inbound processing of the IDoc for message types of the serialization group is triggered by inbound processing of the IDoc for the message type SERDAT.

Serialized Evaluation of Change Pointers If generation of IDocs by change pointers is supported for all message types of the serialization group, you can automate the serialization process, from creation in the sender system to processing in the target system.

Figure 81: Evaluating the Change Pointers of a Serialization Group: RBDSER01

1.

Check whether evaluation by change pointers is activated for all message types. In transaction SALE, you can check all settings as follows: •

2002/Q2

Evaluation using change pointers must be activated:

© 2002 SAP AG. All rights reserved.

169

Unit 6: Optimization of ALE Processes

BIT350

Choose Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Replication of Modified Data → Activate Change Pointers - Generally. •

Evaluation by change pointers must be set for all message types of the serialization group: Choose Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Replication of Modified Data → Activate Change Pointers for Message Types.

2.

Check the distribution model: Are the messages of the serialization group and SERDAT modelled? If necessary, enhance the distribution model by adding the missing message types.

3.

Check the outbound partner profile as follows: • •

4.

Check the inbound partner profile as follows: •

•

5.

Collect IDocs must be selected for all message types of the serialization group (here MATMAS, CLSMAS, CLFMAS). For SERDAT, Transfer IDoc immediately must be set.

If necessary, change the setting to Processing in Background Program for all message types of the serialization group (here: MATMAS, CLSMAS, and CLFMAS). For SERDAT, select Process Immediately, and the process code SERD. Inbound processing for the IDocs of the serialization group must always be triggered indirectly by the inbound processing of the IDoc for SERDAT.

Maintain the inbound settings for all message types of the serialization group. In transaction SALE, choose: Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Message Types → Define Inbound Processing . For more information, see the section Serialization Rule in Target System.

6.

170

Ensure that neither the program RBDAPP01 nor the program RBDSER04 is scheduled for the message types of the serialization group. If necessary, change the variant of the program RBDAPP01 so that the

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Serialization By Message Types (Serialization Groups)

affected message types are not selected. Inbound processing of the IDoc for message types of the serialization group is triggered by inbound processing of the IDoc for the message type SERDAT.

2002/Q2

© 2002 SAP AG. All rights reserved.

171

Unit 6: Optimization of ALE Processes

BIT350

Lesson Summary You should now be able to: • Describe how you can ensure serialized processing of dependent master data for different message types • Set up serialization by message types (serialization groups)

172

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Object Channel Serialization

BIT350

Lesson: Object Channel Serialization Lesson Overview Object channel serialization ensures that the order of messages for a particular object is always preserved on the receiving side. This means that the order in which messages are posted on the receiving side always corresponds exactly to the order determined on the sender side. The IDocs of an object channel are counted on the sender side. It is therefore possible to detect missing or overtaken IDocs on the receiving side. If the number of the IDoc that is currently in inbound processing is not the same as the expected sequential number, it is assigned a particular status value and processing is postponed.

Lesson Objectives After completing this lesson, you will be able to: • •

Describe object channel serialization Make the appropriate Customizing settings to activate or deactivate object channel serialization for a scenario

Business Example You are transferring change data regarding an ALE scenario. You do not want to transfer all the information for an application document, but only the relevant parts. You therefore need to ensure that no overtaking occurs. It is not sufficient to terminate processing if overtaking occurs, because this inconsistency cannot be easily corrected manually. Serialization by time stamp is therefore not applicable. Instead, you want to ensure that inbound processing occurs in exactly the same order as that in which the IDocs are generated. Hint: If an ALE scenario is based on BAPIs, object channel serialization is always used instead of time stamp serialization.

2002/Q2

© 2002 SAP AG. All rights reserved.

173

Unit 6: Optimization of ALE Processes

BIT350

Runtime Behavior

Figure 82: Serialization Using Object Channels 1.

When creating the master IDoc in outbound processing, the application program always uses a function module to determine a channel number. A characteristic key value for the application document is represented by a four-digit number.

2.

The application program transfers this channel number, together with the master IDoc and the control record, to the ALE layer.

3.

The ALE layer uses the Customizing settings to determine the BOR object type that is assigned to the message type.

4.

Using the key information of BOR object type and channel number, the next sequential number is determined and is written in a serialization field of the control record. The sequential number in the database table BDRGOUT is raised by one .

5.

174

In inbound processing, the system checks whether the sequential number for each BOR object type and channel number is one higher than the entry in the database table BDRGIN. If this condition is fulfilled, the IDoc is transferred to the inbound function module of the application.

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Object Channel Serialization

BIT350

If the condition is not fulfilled, the IDoc is set to the status value 66. In inbound processing using the background program RBDAPP01, all selected IDocs for which object channel serialization is activated are sorted by BOR object type and channel number before they are processed. 6.

As soon as an IDoc has been successfully processed, the counter in the database table BDFGIN for the key BOR object type and channel number is updated.

Figure 83: Serialization Field in Object Channel Serialization The serialization number of the control record is composed as follows: • •

The first 10 characters contain the technical name of a business object type. The next 4 characters are formed by a character string created by an algorithm from an application key. The application program obtains this number using the function module ALE_SERIAL_KEY2CHANNEL. A material number, for example, can be used as a key.

•

The last 6 fields are assigned a sequential number by the ALE layer. The current number in the database table BDRGOUT is used for this.

Customizing and Prerequisites Before you can activate object channel serialization, the following prerequisites must be fulfilled for an ALE scenario:

2002/Q2

© 2002 SAP AG. All rights reserved.

175

Unit 6: Optimization of ALE Processes

•

•

•

BIT350

In the outbound program of the application, the channel number must be determined for an application key before the master IDoc is transferred to the ALE layer using the function module ALE_SERIAL_KEY2CHANNEL. This number must be transferred to the ALE layer along with the master IDoc and the control record. Some ALE scenarios, which have not implemented any object channel serialization, provide an enhancement that you can use to determine the channel number. A suitable business object type must be released for object channel serialization. You can check this Customizing setting using transaction BD105. If an enhancement has been made, you can use this transaction to make a new entry. A business object type released for object channel serialization must be assigned to the message type. You can check this Customizing setting using transaction BD104. If an enhancement has been made, you can use this transaction to make a new entry.

Figure 84: Serialization Using Object Channels: Customizing To activate the object channel serialization planned for an ALE scenario, you need to make the following Customizing settings: 1.

176

Maintain the outbound settings in the sender system. In transaction SALE, choose:

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Object Channel Serialization

BIT350

Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Business Objects → Activate Outbound Business Objects. a) b)

Make an entry for every recipient and business object type. Select the field in the Ser. Flag column to activate object channel serialization for a recipient and a business object type.

2.

Maintain the inbound settings in the receiving system. In transaction SALE, choose: Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Business Objects → Activate Inbound Business Objects.

a) b)

Make an entry for every sender and business object type. Select the field in the Ser. Flag column to activate object channel serialization for a sender and a business object type.

3.

Check the consistency of the settings. In transaction SALE., choose: Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Serialization Using Business Objects → Check Consistency System-Wide.

2002/Q2

© 2002 SAP AG. All rights reserved.

177

Unit 6: Optimization of ALE Processes

BIT350

Lesson Summary You should now be able to: • Describe object channel serialization • Make the appropriate Customizing settings to activate or deactivate object channel serialization for a scenario

178

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit Summary

Unit Summary You should now be able to: • Describe the settings required for sending or processing IDocs in packages • Describe the prerequisites for package processing • Describe the settings required for sending or processing IDocs using parallel processing • Describe time stamp serialization • Check whether a scenario uses time stamp serialization • Describe how you can ensure serialized processing of dependent master data for different message types • Set up serialization by message types (serialization groups) • Describe object channel serialization • Make the appropriate Customizing settings to activate or deactivate object channel serialization for a scenario

2002/Q2

© 2002 SAP AG. All rights reserved.

179

Unit Summary

180

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

Test Your Knowledge 1.

Where do you enter the number of IDocs that are grouped together for sending in a package under one transaction ID?

2.

Where do you enter the number of IDocs that are to be processed in one LUW in inbound processing?

3.

How can you tell whether a program uses parallel processing for IDoc generation?

4.

For time stamp serialization, the application must first do the following: Choose the correct answer(s).

A

B C D

2002/Q2

Check in the inbound function module whether overtaking has occurred, and make an entry in the table parameter SERIALIZATION_INFO. In outbound processing, provide the function module MASTER_IDOC_DISTRIBUTE with the parameter SERIALIZATION_INFO. Assign an ALE object type to the message type as a serialization object type. Assign segment fields to the message type and the serialization type.

© 2002 SAP AG. All rights reserved.

181

Test Your Knowledge

5.

BIT350

You want to implement serialization using message types for two message types. You want to define the serialization rule in the sending system. What do you need to do? Choose the correct answer(s).

A B C D E F

Define a serialization group in the receiving system Create a distribution model for SERDAT and define the partner profile in the sending system and the receiving system. Maintain the inbound settings for serialization in the target system. Schedule the program RBDAPP01 in the target system for inbound processing of all IDocs of both message types. Schedule the program RBDSER04 in the target system for inbound processing of all IDocs of both message types. Define a serialization group in the sending system.

6.

You want to implement serialization using message types for two message types. You want to define the serialization rule in the sending system. What do you need to do?

7.

The outbound processing of an ALE scenario supports object channel serialization. Which Customizing settings do you need to make to update object channel serialization for this ALE scenario? Choose the correct answer(s).

A B C D E F

182

Activate each partner and object type in the sender system only. Activate each partner and object type in the receiving system only. Activate each partner and object type in the sender system and the receiving system. Assign a business object type to the message type. Assign a segment field to the business object type. Release the business object type for object channel serialization.

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

Answers 1.

Where do you enter the number of IDocs that are grouped together for sending in a package under one transaction ID? Answer: In the partner profile.

2.

Where do you enter the number of IDocs that are to be processed in one LUW in inbound processing? Answer: In inbound processing, the background program RBDAPP01 provides a selection parameter.

Related Information You can also implement package processing for serialized inbound processing. For more information, see the documentation on serialization methods. In transaction SALE, choose Modeling and Implementing Business Processes → Master Data Distribution → Serialization for Sending and Receiving Data → Define Inbound Processing 3.

How can you tell whether a program uses parallel processing for IDoc generation? Answer: Normally these programs provide a selection parameter in which you can enter an RFC destination.

4.

For time stamp serialization, the application must first do the following: Answer: A, C, D No action is necessary in outbound processing. The ALE layer automatically provides a time stamp for the control record of the IDoc. As soon as the inbound function module returns the table parameter SERIALIZATION_INFO with values to the ALE layer, the ALE layer updates the table BDSER.

2002/Q2

© 2002 SAP AG. All rights reserved.

183

Test Your Knowledge

5.

BIT350

You want to implement serialization using message types for two message types. You want to define the serialization rule in the sending system. What do you need to do? Answer: B, C, F Inbound processing for the IDocs for both message types of the serialization group cannot be triggerred by the programs RBDAPP01 or RBDSER04. Instead, it is triggered by the inbound program for SERDAT. The serialization group in the target system is then irrelevant. If inbound processing is triggered by RBDSER04, the corresponding serialization rule from the receiving system is used, and not the rule that is transferred by SERDAT.

6.

You want to implement serialization using message types for two message types. You want to define the serialization rule in the sending system. What do you need to do? Answer: Define a serialization group in the sending system and assign both message types in the required order. In addition, define a distribution model for the message type SERDAT with the sender and receiver system of both message types. Send the distribution model to all sending and all receiving systems and generate the partner profiles. If necessary, change the outbound partner profile settings of both message types to Collect IDocs, and for SERDAT to Transfer immediately. Schedule the program RBDSER02 as a background job, and enter the serialization group as a selection parameter. In the inbound partner profile in the receiving system, select Processing by Background Program, and for SERDAT select Process Immediately and the process code SERD.

7.

The outbound processing of an ALE scenario supports object channel serialization. Which Customizing settings do you need to make to update object channel serialization for this ALE scenario? Answer: C, D, F For more information, see the Customizing and Prerequisites section.

184

© 2002 SAP AG. All rights reserved.

2002/Q2

Unit 7 ALE Scenario with BAPI Technology Unit Overview This unit explains how you can use a Business Application Programming Interface (BAPI) to implement an ALE scenario. This requires two steps: generating a BAPI-ALE interface for the BAPI, and implementing the outbound program.

Unit Objectives After completing this unit, you will be able to: • • • • • •

Describe how you can use a BAPI for an ALE scenario Analyze the interface of a BAPI Generate an ALE interface for the BAPI Implement an ALE scenario that uses the generated ALE interface Describe the runtime behavior of an ALE scenario whose implementation is based on a BAPI-ALE interface Make the Customizing settings for an ALE scenario that is implemented using a BAPI-ALE interface

Unit Contents Generating an ALE Interface for a BAPI .....................................186 Procedure: Generating a BAPI-ALE Interface ..............................189 Outbound Processing ..........................................................192 Inbound Processing.............................................................196 Customizing......................................................................199

2002/Q2

© 2002 SAP AG. All rights reserved.

185

Unit 7: ALE Scenario with BAPI Technology

BIT350

Lesson: Generating an ALE Interface for a BAPI Lesson Overview To implement an ALE scenario for a BAPI, you need to generate an ALE interface for the BAPI before you can implement the outbound program. This lesson describes all the steps required for generating the BAPI-ALE interface.

Lesson Objectives After completing this lesson, you will be able to: • • •

Describe how you can use a BAPI for an ALE scenario Analyze the interface of a BAPI Generate an ALE interface for the BAPI

Business Example You want to implement an ALE scenario that is not supplied as a standard scenario. BAPIs are available for the relevant substeps of the scenario.

ALE Interface for a BAPI To implement a distributed business process, you can use a BAPI that executes a consistent substep of a business process. In the sender system, the parameters that are required for calling the BAPI in the target system are written in an IDoc. This IDoc is sent to the target system. In the target system, the IDoc fields are assigned to the interface parameters and the BAPI is called locally.

Figure 85: Asynchronous BAPI Call in the Target System You can use the BAPI Explorer (transaction BAPI) to find information on business object types and their BAPIs. The BAPI Explorer display is split into a hierarchy area and a detail window. The component hierarchy is displayed in the hierarchy area. You can expand the application components to display the business object types for each component. If

186

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Generating an ALE Interface for a BAPI

you expand a business object type, a subtree is displayed with the key attributes and the API methods for the business object type. API stands for Application Programming Interface.

Figure 86: An ALE Interface for a BAPI In the BAPI Explorer detail view, you can double click on the ALE message type to display the ALE interface for the BAPI. This is transaction BDBG, which you can use to display and generate BAPI-ALE interfaces. To display the generated elements of the ALE interface for a BAPI, choose Display Interface. Hint: If Does Not Exist is in the ALE Message Type field, no ALE interface exists for that BAPI. If this is the case, you first need to generate an ALE interface. See the procedure Generating a BAPI-ALE interface.

2002/Q2

© 2002 SAP AG. All rights reserved.

187

Unit 7: ALE Scenario with BAPI Technology

BIT350

Figure 87: An ALE Interface for a BAPI • • •

Message type IDoc type Segment types The elemental import parameters are grouped together in a segment type. One segment type is created for every structured import parameter.

•

Function Module for ALE Outbound Processing In the outbound function module, the interface parameters are copied into the IDoc segments and a master IDoc is created. A function module is then called, which passes this master IDoc to the ALE layer.

•

Function Module for ALE Inbound Processing The inbound module copies the contents of the segment fields to the corresponding interface parameters, and calls the BAPI function module locally.

188

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Generating an ALE Interface for a BAPI

BIT350

Generating a BAPI-ALE Interface 1.

Define a function group using the Object Navigator. To do this, choose SAP Menu → Tools →ABAP Workbench →Overview →Object Navigator (= transaction SE80). Enter a new development class in the customer namespace. If necessary, create a new development class. To create a function group, choose Create → Function Group.

Figure 88: Defining a Function Group 2.

Choose a name in the customer namespace and enter a short description.

3.

From the BAPI for which you want to generate the ALE interface, go to the transaction BDBG.

Continued on next page

2002/Q2

© 2002 SAP AG. All rights reserved.

189

Unit 7: ALE Scenario with BAPI Technology

BIT350

Figure 89: Generating an ALE Interface 4.

Choose Create, and enter a name for the message type in the customer namespace.

5.

In the next screen, enter the development class in your customer development class, and the names of the function modules in the customer namespace. If you do not have your own namespace, ensure that the customer namespace for function modules begins with Z_ or Y_. The segment types are generated according to a defined naming convention that is derived from the type names of the BAPI interface parameter.

190

© 2002 SAP AG. All rights reserved.

2002/Q2

Lesson: Generating an ALE Interface for a BAPI

BIT350

Lesson Summary You should now be able to: • Describe how you can use a BAPI for an ALE scenario • Analyze the interface of a BAPI • Generate an ALE interface for the BAPI

2002/Q2

© 2002 SAP AG. All rights reserved.

191

Unit 7: ALE Scenario with BAPI Technology

BIT350

Lesson: Outbound Processing Lesson Overview When implementing an ALE scenario for a Business Application Programming Interface (BAPI), you need to generate an ALE interface for the BAPI before you can implement the outbound program. This lesson describes all steps that are required for implementing the outbound program.

Lesson Objectives After completing this lesson, you will be able to: •

Implement an ALE scenario that uses the generated ALE interface

Business Example You want to implement an ALE scenario that is not supplied as a standard scenario. BAPIs are available for the relevant substeps of the scenario.

Outbound Processing: Runtime Behavior The outbound program of the application transfers the application data required by the BAPI in the target system to carry out the substep of the business process. The data is converted into the format of the BAPI interface. Finally, the program uses a function module of the ALE layer to read the recipient and the filter from the distribution model. It then calls the generated outbound function module of the BAPI-ALE interface. After the call, the LUW must be completed with a COMMIT WORK.

192

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Outbound Processing

Figure 90: Outbound Processing for BAPI To determine the recipient from the distribution model, call the function module ALE_ASYNCH_BAPI_GET_RECEIVER.

Figure 91: Outbound Processing: Detail The generated outbound function module structures the master IDoc and passes it to the ALE layer using the function module ALE_IDOCS_CREATE. This function module corresponds to the function module MASTER_IDOC_DISTRIBUTE for ALE scenarios that are based on BAPI technology.

2002/Q2

© 2002 SAP AG. All rights reserved.

193

Unit 7: ALE Scenario with BAPI Technology

BIT350

Figure 92: ALE Process Diagram - as for IDocs After the IDoc is transferred to the ALE layer, the process is the same as in the classical IDoc method.

194

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Outbound Processing

Lesson Summary You should now be able to: • Implement an ALE scenario that uses the generated ALE interface

2002/Q2

© 2002 SAP AG. All rights reserved.

195

Unit 7: ALE Scenario with BAPI Technology

BIT350

Lesson: Inbound Processing Lesson Overview To implement an ALE scenario for a standard BAPI, you need to generate an ALE interface for the BAPI before you can implement the outbound program. This lesson discusses the runtime behavior of inbound processing. For inbound processing, no specific implementation is required.

Lesson Objectives After completing this lesson, you will be able to: •

Describe the runtime behavior of an ALE scenario whose implementation is based on a BAPI-ALE interface

Business Example You have implemented an ALE scenario that is based on a BAPI-ALE interface. You now want to understand how inbound processing works, and which Customizing settings are required in the partner profile.

Inbound Processing: Runtime Behavior The IDoc is saved in the database. By the process code BAPI, the ALE layer recognizes that this is an ALE scenario based on a generated BAPI-ALE interface. The ALE layer determines the generated inbound function module that belongs to the message type. Hint: For inbound processing by package, choose the process code BAPP.

196

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Inbound Processing

Figure 93: Inbound Processing for BAPI The inbound function module converts the data from the IDoc into the format of the corresponding BAPI interface parameter, and assigns the IDoc fields to the parameter. The module then calls the BAPI function module locally and synchronously.

2002/Q2

© 2002 SAP AG. All rights reserved.

197

Unit 7: ALE Scenario with BAPI Technology

BIT350

Lesson Summary You should now be able to: • Describe the runtime behavior of an ALE scenario whose implementation is based on a BAPI-ALE interface

198

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Customizing

Lesson: Customizing Lesson Overview To implement an ALE scenario for a standard BAPI, you have generated an ALE interface for the BAPI and implemented the outbound program. This lesson discusses which Customizing settings you need to make to guarantee distribution from a sending system to a target system.

Lesson Objectives After completing this lesson, you will be able to: •

Make the Customizing settings for an ALE scenario that is implemented using a BAPI-ALE interface

Business Example You have implemented an ALE scenario that is based on a BAPI-ALE interface. You now want to understand which Customizing settings are required to guarantee distribution from a sender system to a target system.

Figure 94: Distribution Model In the distribution model, you can use the Add BAPIs icon to insert BAPIs into your view. In addition to the sending and receiving systems, enter the name of the business object type and the method. For the business object type and the method, enter the name from the BAPI Explorer, and not the technical name of the business object type from the Business Object Builder.

2002/Q2

© 2002 SAP AG. All rights reserved.

199

Unit 7: ALE Scenario with BAPI Technology

BIT350

Figure 95: Sender: Partner Profile (Outbound) Generate the partner profile from the distribution model. The system enters the appropriate message type and IDoc type for the BAPI.

Figure 96: Receiving System: Partner Profile (Inbound)

200

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Lesson: Customizing

After you have transported or distributed the distribution model into the receiving system, you can also generate the partner profile in the receiving system from the distribution model. Enter the process code BAPI for individual processing, or BAPP for package processing.

2002/Q2

© 2002 SAP AG. All rights reserved.

201

Unit 7: ALE Scenario with BAPI Technology

BIT350

Lesson Summary You should now be able to: • Make the Customizing settings for an ALE scenario that is implemented using a BAPI-ALE interface

202

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Unit Summary

Unit Summary You should now be able to: • Describe how you can use a BAPI for an ALE scenario • Analyze the interface of a BAPI • Generate an ALE interface for the BAPI • Implement an ALE scenario that uses the generated ALE interface • Describe the runtime behavior of an ALE scenario whose implementation is based on a BAPI-ALE interface • Make the Customizing settings for an ALE scenario that is implemented using a BAPI-ALE interface

2002/Q2

© 2002 SAP AG. All rights reserved.

203

Unit Summary

204

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Test Your Knowledge

Test Your Knowledge 1.

The objects of a generated BAPI-ALE interface can only exist for customer BAPIs in the customer namespace. Determine whether this statement is true or false.

True False 2.

Which process codes do you maintain in the inbound partner profile for an ALE scenario based on a BAPI-ALE interface?

3.

For ALE scenarios based on BAPIs, you do not need to maintain a distribution model. Determine whether this statement is true or false.

True False 4.

In the distribution model, enter the BAPI in your view of the distribution model by entering the technical names of the business object and the method. You then need to determine the technical name for the BAPI from the BAPI Explorer. Determine whether this statement is true or false.

True False

2002/Q2

© 2002 SAP AG. All rights reserved.

205

Test Your Knowledge

BIT350

Answers 1.

The objects of a generated BAPI-ALE interface can only exist for customer BAPIs in the customer namespace. Answer: False If no generated ALE interface is yet available, you can generate an ALE interface for each suitable BAPI. All objects that belong to an ALE interface you have generated must be in the customer namespace.

2.

Which process codes do you maintain in the inbound partner profile for an ALE scenario based on a BAPI-ALE interface? Answer:

3.

BAPI

or BAPP for package processing.

For ALE scenarios based on BAPIs, you do not need to maintain a distribution model. Answer: False The outbound program and the ALE layer in the outbound program determine the recipients from the distribution model.

4.

In the distribution model, enter the BAPI in your view of the distribution model by entering the technical names of the business object and the method. You then need to determine the technical name for the BAPI from the BAPI Explorer. Answer: False The same name that appears in the BAPI Explorer is also entered here. The name is case-sensitive.

206

© 2002 SAP AG. All rights reserved.

2002/Q2

BIT350

Course Summary

Course Summary You should now be able to: • • •

2002/Q2

Analyze an ALE scenario for enhancement possibilities Assess the most appropriate method for enhancing a scenario Optimize Customizing settings to improve the performance of an ALE process

© 2002 SAP AG. All rights reserved.

207

Course Summary

208

BIT350

© 2002 SAP AG. All rights reserved.

2002/Q2

Feedback SAP AG has made every effort in the preparation of this course to ensure the accuracy and completeness of the materials. If you have any corrections or suggestions for improvement, please record them in the appropriate place in the course evaluation.

2002/Q2

© 2002 SAP AG. All rights reserved.

209