BIT300 Integration Technology ALE

7/18/2019 BIT300 Integration Technology ALE

http://slidepdf.com/reader/full/bit300-integration-technology-ale 1/259

BIT300Integration Technology ALE

SAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 2005 Q4Course Duration: 3 Day(s)

Material Number: 50078127

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



Copyright

Copyright © 2006 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. Additionally this publication and its contents are provided

solely for your use, this publication and its contents may not be rented, transferred or sold 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 APARTICULAR 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.

g200672943835



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

American English is the standard used in this handbook. The following

typographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude 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, tablenames, and individual key words of a programming

language, when surrounded by body text, for example

SELECT and INCLUDE.

Example text Screen output. This includes file and directory names

and their paths, messages, names of variables and

parameters, and passages of the source text of a

program.

Example text Exact user entry. These are words and characters that

you enter in the system exactly as they appear in the

documentation.

<Example text> Variable user entry. Pointed brackets indicate that you

replace these words and characters with appropriate

entries.

2005/Q4 © 2006 SAP AG. All rights reserved. iii



About This Handbook BIT300

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 © 2006 SAP AG. All rights reserved. 2005/Q4



Contents

Course Overview ....... ....... ....... ....... ....... ...... ....... ....... .. vii

Course Goals ....... ........ ........ ........ ........ ....... ........ .....vii

Course Objectives ... .... ... .... .... .... .... .... .... ... .... ... .... .... .vii

Unit 1: ALE Fundamentals.... ... .... ... .... ... .... ... .... ... .... ... .... . 1

Cross-System Business Processes ..................................3

The Distribution Model ... .... .... .... ... .... .... .... .... .... .... ... .... 9

Basic ALE Customizing ... .... ... .... ... .... ... .... .... .... ... .... ... 15

Intermediate Documents............................................. 30Synchronizing Customizing.. ... .. ... ... .. ... .. ... ... .. .. ... ... .. ... . 44

ALE and the SAP NetWeaver Exchange Infrastructure.. . . . .. . .. 51

Unit 2: Master Data Distribution...................................... 57

Example: Material Master ........................................... 58Using Change Pointers............................................... 75

Data Filtering and Reducing the Scope of Data .. .. .. .. .. .. .. .. .. 80

Unit 3: Distributing Transaction Data: Message Control ... .. . 103

Message Control and IDoc Generation . .. .. .. .. .. .. .. .. .. .. .. .. .. 104

Example: Purchase Order Processing. .. .. .. .. .. .. .. .. .. .. .. .. .. . 119

Unit 4: Distributing Transaction Data: BAPIs .................... 137

Business Object Types and BAPIs ................................138The Usage of BAPIs in ALE ........................................ 145Example: Travel Expenses.........................................155

Unit 5: Monitoring Data Distribution, Error-Handling andArchiving.................................................................. 177

IDoc Status Management...........................................179

Error Analysis and Handling. ... .. ... ... .. ... .. ... ... .. .. ... ... .. ... 190SAP Workflow in ALE Environment ............................... 212

Archiving IDocs. .. . . .. . . .. . . . .. . . . .. . .. . . . .. . . . .. . .. . . . . .. . . .. . . .. . . . .228

Unit 6: Appendix . ....... ....... ....... ....... ....... ....... ....... ...... 235

Renaming Logical Systems... .. ... ... .. ... .. ... ... .. ... .. ... ... .. .. 236

IDoc Recovery Following Database Error ........................ 241

Index ....................................................................... 249

2005/Q4 © 2006 SAP AG. All rights reserved. v

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Contents BIT300

vi © 2006 SAP AG. All rights reserved. 2005/Q4



Course Overview

This course explains how to use Application Link Enabling (ALE) using

predefined example scenarios. You will learn how to configure ALE scenarios

and how to control data exchange between systems.

Target Audience

This course is intended for the following audiences:

• Consultants

• Project team members

Course Prerequisites

Required Knowledge

• SAPTEC (Fundamentals of SAP Web AS)

Recommended Knowledge

• BIT100 (SAP NetWeaver Process Integration)

Course Goals

This course will prepare you to:

• Create a system landscape for using different ALE scenarios (distributing

master data and transaction data)

• Control data exchange between systems in a distributed system landscape

• Correctly assess the capabilities and limitations of ALE

Course Objectives

After completing this course, you will be able to:

• Set up a distribution model for exchanging master and transaction data

between systems

• Create partner profiles for data exchange in enterprises and for electronic

communication with business partners

• Determine the scope of data to be distributed, depending on its type and

recipient

• Monitor data exchange between systems

2005/Q4 © 2006 SAP AG. All rights reserved. vii



Course Overview BIT300

SAP Software Component Information

The information in this course pertains to the following SAP Software Componentsand releases:

viii © 2006 SAP AG. All rights reserved. 2005/Q4



Unit 1ALE Fundamentals

Unit Overview

In this unit, you will first learn about the possible applications of ALE in

enterprises. You will then find out which basic settings you need to make in

Customizing and applications to use ALE.

Unit Objectives

After completing this unit, you will be able to:

• List examples of business processes in distributed system landscapes

• Differentiate ALE from EDI

• Explain the terms “logical system” or “logical system name”, “message

type” and “distribution model”

• Explain the function of the distribution model

• Define logical system names and assign them to clients in SAP systems,

where applicable

• Explain the terms “IDoc” and “basic type”

• Determine the assignment of message types to basic types

• Complete a view in a distribution model

• Explain the function of RFC destinations, ports and partner profiles

• Explain and differentiate between the terms “basic type”, “master IDoc”

and “communications IDoc”

• Determine the details of basic types

• Describe the process from the creation of an IDoc in the sender systemthrough to processing in the target system

• Describe methods for adjusting Customizing settings in SAP system

landscapes

• Explain how ALE scenarios are integrated into SAP XI

Unit Contents

Lesson: Cross-System Business Processes .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .3

Lesson: The Distribution Model..................................................9

2005/Q4 © 2006 SAP AG. All rights reserved. 1

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 1: ALE Fundamentals BIT300

Lesson: Basic ALE Customizing............................................... 15

Exercise 1: Basic ALE Customizing .. ... ... .. ... .. .. ... ... .. ... .. ... ... .. 25

Lesson: Intermediate Documents .. ... ... .. ... .. ... ... .. ... .. ... ... .. .. ... ... . 30Exercise 2: Documentation for Basic Types ............................. 41

Lesson: Synchronizing Customizing .......................................... 44

Lesson: ALE and the SAP NetWeaver Exchange Infrastructure .......... 51

2 © 2006 SAP AG. All rights reserved. 2005/Q4

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



BIT300 Lesson: Cross-System Business Processes

Lesson: Cross-System Business Processes

Lesson Overview

This lesson introduces examples of the application and use of ALE.

Lesson Objectives

After completing this lesson, you will be able to:



Business ExampleGlobally-active enterprises usually structure their business using multiple clients

in an SAP system, often also using multiple SAP systems. Frequently, these are

joined by systems for specific applications from other providers. You need to

clarify how the parties involved in this kind of system group exchange data with

each other.

Enterprise Structure and Business Processes

An enterprise's head office, subsidiaries and sales and distribution branches are

often technically separate systems. Each subsystem communicates not only with

the other members of the system group but also with business partners, such ascustomers, vendors, banks and public authorities.

Figure 1: The Enterprise as a Whole and External Parties

In the example illustrated above, the master data for the overall enterprise network

is created and changed in the head office only. New master data and changes

to existing data are regularly sent to the downstream systems of the sales and

distribution branch and production. The central purchasing department orders





from vendors, the sales and distribution branch receives orders from customers

and sends these to production to be manufactured. Communication is to be

electronic throughout all the processes.

Figure 2: Example: Sales Order Processing

The customer sends a purchase order to the sales and distribution branch. The SD

branch's system creates an order from the data in this purchase order and then an

(internal) purchase order, which it sends to production's system. In the production

system, an order is generated from this data. Depending on the agreements

between the two enterprise areas, the production system confirms the order from

the SD branch and announces delivery of the ordered material amounts. The SD

branch can now confirm the customer's order in turn and notify the customer of a

consignment of goods. After the goods have been delivered, production invoicessales and distribution for them. SD then, in turn, presents the customer with an

invoice for the delivered goods.

Preparatory Steps for Mapping Cross-System Business Processes

• Analysis of the enterprise's organizational structure and the mapping of its

technical systems: which SAP systems or clients make up the enterprise's

system landscape? Are there any non-SAP systems involved?

• Listing the software products installed in each participating system

• Describing the business processes that need to be mapped in the system

landscape• Breaking these processes down into individual steps

• Distributing the individual steps of the overall process to the participating

systems or business partners





Internal Communication: Distributing Master Data withALE

ALE can be used within an enterprise for central master data administration

(among other uses): master data is created and changed in only one of the systems

in the enterprise network. The master data is distributed from this maintenance

system to the downstream systems; the data records are forwarded in electronic

form to each of the recipients. A typical example of this is centralized master

data administration.

Figure 3: Example: Centralized Material Master Administration

In the scenario illustrated above, all the material masters are created in the

head office and distributed from there to the downstream systems of salesand distribution and production. However, sales and distribution should only

receive the master records for finished products, whereas production should

receive material master data for both finished products and raw materials. When

configuring the ALE scenario, it is therefore important to pay attention to the

distribution hierarchy and also to take into account the fact that not every recipient

receives all the data. In a different scenario, the departments in the receiving

system are responsible for the maintenance of certain portions of a master record.

In this case, the master record should not be transferred in its entirety, or there

needs to be a guarantee that values changed locally cannot be overwritten if the

data records are transferred again.

Basic Questions when Planning Centralized Master Data Distribution

• Which master data is maintained in which system?

• To which systems must the master data then be distributed?

• How often is the data distributed, and when?

• Do all the recipients receive all the data in its entirety?





Communication with External Parties: Purchase Order Handling with EDI

You want to communicate electronically not only within the enterprise, but also

with your business partners. In this way, the data from an order created in your

own system can be electronically transferred to a vendor, who, in turn, sends an

order confirmation, shipping confirmation and finally an invoice.

Figure 4: Example: Purchase Order Processing

Generally, data exchange with external parties (that is, business partners, banks, or

government agencies) is carried out using Electronic Data Interchange (EDI),

not ALE. An electronic document is sent in an SAP-specific format from an

SAP system to an EDI subsystem, called a converter. The subsystem converts

this document to an EDI document, and sends it to the supplier. The unit on

“Distributing Transaction Data: Message Control” contains more information

about the differences between ALE and EDI.

Separating Systems for Legal Reasons: Human

Resources

Often, to comply with data protection legislation, a separate system is set up

for human resources (HR). In this system, HR master data is managed, payroll

accounting is processed and other sensitive data is retained. Unauthorized access





to this data is supposed to be prevented (or at least made difficult) by technically

separating the HR system from the other systems in the enterprise network. Other

possible reasons for separating human resources are:

• Independence during technical upgrades

• Independence when installing Support Packages that effect (human

resource-related) legal changes (known as Legal Change Patches)

• Better performance

Figure 5: Separate System for Human Resources

Since Accounting is one of the systems included in the head office system, this

latter also requires HR master data for paying salaries and wages or reimbursingtravel costs. Cost centers and other account assignment objects are also required

in both systems. Thus even in the case of a separate Human Resources system,

master data distribution is useful. The results from the payroll or travel expenses

are transferred to head office from the HR system for posting in Accounting.





Lesson Summary

You should now be able to:• List examples of business processes in distributed system landscapes





BIT300 Lesson: The Distribution Model

Lesson: The Distribution Model

Lesson Overview

The distribution model is the core component of ALE, as it determines which

sender transfers which data to which recipients. It is made up of assignments of

logical system names and message types. This lesson explains all three terms and

the function each one plays in ALE scenarios.

Lesson Objectives



type” and “distribution model”• Explain the function of the distribution model

Business Example

You have analyzed your business processes and the existing system landscape.

You want to familiarize yourself with the configuration of an ALE scenario, using

the example of centralized master data administration as a basis.

Logical System Name

Once you have determined which parts of the enterprise should use ALE toexchange data with each other, define logical system names for every client

involved in the system group and, if applicable, for all external systems (if this has

not already been done).

Figure 6: Example of a Scenario to be Mapped

The logical system name uniquely identifies the client of an SAP system or a

non-SAP system in the system landscape. If the name refers to a client, assign

the name to the client in the next step. To guarantee that the logical system name

is unique and to simplify the assignment, SAP recommends using the naming





convention <System name>CLNT<Client key>. In the example illustrated below,

the SAP system has the key G23. Clients 800, 810 and 811 are used. Thus, for

example, client 800 receives the logical system name G23CLNT800.

Note: The terms “logical system name” and “logical system” are used

interchangeably.

Figure 7: Logical System Names

In certain cases, it could be useful not to use SAP's recommended convention

for logical system names. The training clients for this course have “descriptive”

names: the logical system name for head office is CORE, sales and distribution is

called SALES and production is PRODUCTION. Naming the systems in this

way is an alternative to the SAP convention if the assignment of clients to logical

system names is frequently changed.

Caution: Changing the logical system name is a serious intervention, as

this name is included in numerous application tables (see lesson on “Basic

ALE Customizing” and appendix “Renaming Logical Systems”).

Message Type

When configuring an ALE scenario, in addition to assigning logical system

names, you also need to indicate the types of data that are to be exchanged: if,

for example, you want to distribute material masters with ALE in the future, you

need to name the type of data (material masters) with what is known as a message

type (MATMAS). Message types are therefore essentially keys, comparable to

logical system names, which indicate data that can be exchanged between systems

in ALE or EDI scenarios.





Figure 8: Logical Systems and Message Types

Both elements – the logical system name and message type – are linked to each

other in the distribution model, in order to determine which sender sends which

data to which recipient. In the example illustrated above, the head office (CORE

logical system) distributes material masters (MATMAS message type) to sales and

distribution (SALES logical system) and production (PRODUCTION logical

system).

Note: In some ALE scenarios, “Business Application Programming

Interfaces” (BAPIs) are used instead of message types. You will learn

about how to use BAPIs in ALE in the unit: “Distributing Transaction

Data: BAPIs”.

Distribution Model and Model Views

If you want data to be sent from one logical system to another, you specify in the

distribution model which message type is to be sent from which logical system

to which logical system(s). The distribution model bundles all the assignments

of senders, recipients and data to be sent. If you set up a new ALE scenario, younormally create a new model view for this scenario in the distribution model of

one of systems involved. In this model view, you name the sender and recipient

using their logical system names and then add the message type describing the

type of data that is to be sent.





Figure 9: Model View in a Distribution Model

You then need to distribute the newly created model view, in other words, makeit known to the other systems involved. In the example shown above, the model

view “master data” was created in the CORE logical system. However, this also

affects the logical systems SALES and PRODUCTION. They receive copies of

the new model view. You can distribute a model view to the partner systems using

ALE, subject to certain conditions (explained below). It is, however, also possible

to transport a model view to other systems.

Figure 10: Distributing Model Views

Note: To ensure that data remains consistent, you should maintain the

distribution model centrally in one logical system and then distribute or

transport its views to the other affected logical systems.





You can find the distribution model in the IMG via SAP NetWeaver ! SAP Web

Application Server ! IDoc Interface / Application Link Enabling (ALE)!

Modelling and Implementing Business Processes! Maintain Distribution Model and Distribute Views.





Lesson Summary

You should now be able to:• Explain the terms “logical system” or “logical system name”, “message






BIT300 Lesson: Basic ALE Customizing

Lesson: Basic ALE Customizing

Lesson Overview

This lesson introduces basic ALE Customizing. In addition to this, you will learn

where to find information about the ALE scenarios provided by SAP.

Lesson Objectives



where applicable





Business Example

You want to use ALE to exchange data between two SAP systems. You therefore

want to get an overview of the Customizing settings needed to set up ALE

scenarios. You also want to check if there is a standard ALE scenario that would

be suited to your purposes.

ALE Customizing in the Implementation Guide

You can find all the basic Customizing settings in an SAP system's Implementation

Guide (IMG) under SAP NetWeaver ! SAP Web Application Server ! IDoc

Interface / Application Link Enabling (ALE). You can also call this section of the

IMG directly by calling transaction SALE.

Figure 11: Transaction SALE





In the area Modelling and Implementing Business Processes, you will find

extensive documentation about ALE scenarios, which you can use in many

different applications (! Configure Predefined ALE Business Processes). If, for example, you are interested in possible uses of ALE in human resources, go to

Modelling and Implementing Business Processes! Configure Predefined ALE

Business Processes! Human Resources. Depending on the application, you

will find, in addition to a description of the scenario and the substeps needed to

configure it, supporting functions, such as “auto-Customizing” or a program for

checking the completeness and internal consistency of your settings.

Defining Logical System Names and Assigning themto Clients

Each system in the system landscape must have a logical system name. Thisname uniquely identifies the logical system in the system landscape. You can then

assign this name to the client of an SAP system.

Figure 12: Defining Logical Systems

You can define logical system names in Customizing. In the SAP ReferenceIMG, choose SAP NetWeaver ! SAP Web Application Server ! IDoc

Interface/Application Link Enabling (ALE) ! Logical Systems! Define Logical

System.

Hint: You can also call the table of logical system names directly, using

transaction code BD54.





You can find the assignment of logical system names to clients in the IMG, via

SAP NetWeaver ! SAP Web Application Server ! IDoc Interface/Application

Link Enabling (ALE) ! Logical Systems! Assign Logical System to Client .

Hint: You can also call this table directly, using a transaction code

(SCC4).

Message Types and Basic Types

In ALE, message types indicate the data that is to be exchanged between each

of two systems. MATMAS, for example, represents material records. The

material master data to be distributed is transported in an electronic intermediate

document (IDoc) from the sender system to the recipient system. This IDoc

contains the data from the master record in an SAP-specific format. The structureof the document is determined in a basic type. The basic type defines the

formatting structure of the data record that is to be sent. Generally, the name

of the IDoc basic type is the same as the name of the message type but with a

version number added to it. The current version of the basic type for message type

MATMAS, for example, is MATMAS05.

Figure 13: Message Type and Basic Type

To find out which version of the basic type is best suited to your SAP system's

release level, see the table Output Types and Assignment to IDoc Types. To do this,in the SAP Easy Access Menu, go to Tools! ALE ! ALE Development ! IDoc

! IDoc Type Development ! IDoc Type for Message (transaction WE82). For an

overview of all the message types, go to Tools! ALE ! ALE Development !

Logical Messages (transaction WE81).

Note: The structure and use of IDocs is described in more detail in the

lesson on “Intermediate Documents”.





Creating Model Views in the Distribution Model

In the distribution model of a logical system, you define for each of your ALE

scenarios which logical system sends what type of data to which partner system.

You can create new model views in Customizing. To do this, in the IMG, go to

SAP NetWeaver ! SAP Web Application Server ! IDoc Interface / Application

Link Enabling (ALE)! Modelling and Implementing Business Processes!

Maintain Distribution Model and Distribute Views or call the distribution model

directly via transaction BD64.

Figure 14: Distribution Model Maintenance in the IMG

To create a new model view, enter the logical system names of the sender and the

recipient and a message type. You can assign logical systems for different message

types as well as the sender and recipient roles in the same model view.





Figure 15: Distribution Model

To ensure the consistency of the data across the system landscape and beyond, it is

advisable to maintain the different views of a distribution model in one central

system, and distribute them or transport them to the partner systems (see below).

RFC Destinations and Ports

In ALE scenarios, the systems involved exchange data via Remote FunctionCalls (RFC). From one SAP system, an RFC calls a function module in another

SAP system. RFCs make it possible to exchange data between different SAP

systems or between one SAP system and a non-SAP system. In non-SAP systems,

specially-programmed functions are called instead of function modules; the

interface of these functions simulates a function module.





Figure 16: Defining RFC Destinations

For your ALE scenarios, you create RFC destinations for all the partner systems in

each system involved. To do this, select in the ALE Customizing IDoc Interface /

Application Link Enabling (ALE) ! Communication! Create RFC Connections

or use transaction SM59. In the RFC destinations, specify a target host, IP

addresses, and (if applicable) the system number and user and logon data for

“remote login” in the target system. Thus the RFC destination contains all the

technical information that the calling system needs to call the partner from withinthe network.

Hint: If you give the RFC destination the same name as the logical target

system, you can have the system carry out certain settings automatically

later on.

In order to use ALE scenarios later on, the RFC must be assigned to a port. The

sender uses the port to determine the communication channel to the recipient. You

can create ports manually or – if the logical target system and the RFC destination

have the same name – have the sender system create them.

Note: There are different types of port in SAP systems. ALE always uses

RFC ports. In EDI scenarios, you can also use file ports in addition to

RFC ports (see lesson on “Intermediate Documents”).





Transferring IDocs Using tRFC

To ensure that RFC functions can be executed reliably, securely, and independently

of RFC server or RFC server system availability, the transactional RFC (tRFC)

was introduced in SAP R/3 3.0. This ensures that the function module called is

only executed once in the RFC server system.

In transactional RFC calls, the data that belongs to an RFC function must be saved

temporarily in the SAP database in the RFC client system. Once the processing

is complete, this must be confirmed to the calling ABAP program. The tRFC

component in the SAP system handles everything else.

Figure 17: Transactional RFC

As a database on an external system is not always available, the connection to the

tRFC interface is implemented in such a way that the client or server programs

must perform a number of administration functions on the RFC API basis to

ensure that the function module is executed only once.

If a connection error occurs during a synchronous RFC, the client repeats the

call without knowing whether the processing has already taken place. The tRFC

solves this problem as tRFC calls can be transferred even if the target system is

not available. In these cases, the data is saved locally in the sender system andtransmitted later. In SAP R/3 or SAP ECC, automatic job scheduling is used for

this purpose. The job starts the corresponding function module(s) in the target

system at a later time.

Note: An external tRFC client needs to repeat the calls itself at a later time.





In the SAP system, you can set tRFC parameters for the relevant connection in

table RFCDES (for connection types T, 3, I) (SM59):

• Suppress batch job in the event of communication errors (manual start with

transaction SM58 required)

• Number of connection attempts

• Interval in minutes between repeated attempts to transfer data

Partner Profiles

In ALE scenarios, application programs check the system's distribution model

when they are called, in order to identify the recipient of each message prepared

in IDoc format. ALE scenarios require partner profiles for every combination

of recipient system and message type. These profiles are also necessary for

processing inbound IDocs. There is always an outbound and an inbound partner

profile for each message type in an ALE scenario.

Figure 18: Partner Profiles

On the one hand, the sender system reads the basic type for the message type

from the outbound partner profile, so that it can create an IDoc with the data that

is to be distributed. On the other, the sender system uses the port assigned to the

partner profile to find the RFC destination that enables it to call the recipient

system. In addition to this, the partner profile determines whether the IDoc is sent

immediately or not until later.

From the inbound partner profile, the recipient system reads how and when the

data from the inbound IDoc is to be transferred to the relevant application. As a

rule, what is known as a process code is used to find a function module for the

inbound processing of the IDoc.





For a model view to be distributed to all the partner systems, the sender system

must contain outbound partner profiles for message type SYNCH for all the

affected recipient systems. This message type is used only for determining theRFC destination for the target system. If the name of the logical target system and

its RFC destination are the same, the sender system can automatically create a port

with the appropriate RFC destination and generate the partner profiles for the

message types of a model view. The authorization object for distributing model

views is B_ALE_MODL.

Note: The lesson on “Intermediate Documents” explains how to create

and change ports and partner profiles.





Exercise 1: Basic ALE Customizing

Exercise Objectives

After completing this exercise, you will be able to:

• Find information about ALE scenarios supplied by SAP

• Determine which logical system names are allocated to which clients

• Check distribution model views and partner profiles

Business Example

You want to use ALE to exchange data between two SAP systems. You therefore

want to get an overview of the Customizing settings needed to set up ALE

scenarios. You also want to check if there is a standard ALE scenario that would

be suited to your purposes.

Task:

First, look in the IMG documentation to see if there are any ALE scenarios for

master data distribution between SAP systems. Next, check the assignment of the

logical system names CORE, SALES and PRODUCTION to the three training

clients mentioned by your instructor. Then take a look at the distribution model

for the CORE logical system.

1. Search in the IMG documentation for ALE scenarios for master data

distribution. To do this, use the IMG section IDoc Interface / Application Link Enabling (ALE) (transaction SALE).

2. In one of the three clients for the mySAP ERP logistics and accounting

system, check the assignment of the logical system names to the three clients.

Make a note of the assignment:

Logical system Client

CORE

SALES

PRODUCTION

3. In the distribution model for the CORE system, select all the model views

containing message type MATMAS.

Hint: Use the Filter model display button.

Continued on next page





4. From the distribution model, display the CORE system's partner profiles for

the SALES and PRODUCTION systems. Check the detail settings for the

MATMAS message type.

5. Check the corresponding inbound partner profiles in the SALES system.





Solution 1: Basic ALE Customizing

Task:

First, look in the IMG documentation to see if there are any ALE scenarios for

master data distribution between SAP systems. Next, check the assignment of the

logical system names CORE, SALES and PRODUCTION to the three training

clients mentioned by your instructor. Then take a look at the distribution model

for the CORE logical system.

1. Search in the IMG documentation for ALE scenarios for master data

distribution. To do this, use the IMG section IDoc Interface / Application

Link Enabling (ALE) (transaction SALE).

a) Select IDoc Interface / Application Link Enabling (ALE)! Modelling

and Implementing Business Processes! Configure Predefined ALE

Business Processes! Logistics! Master Data Distribution.

b) You will find IMG activities for setting up various master data

distribution scenarios.

2. In one of the three clients for the mySAP ERP logistics and accounting

system, check the assignment of the logical system names to the three clients.

Make a note of the assignment:

Logical system Client

CORESALES

PRODUCTION

a) Choose IDoc Interface Application Link Enabling (ALE)! Basic

Settings! Logical Systems! Assign Logical System to Client .

b) One by one, select the table entries for the three training clients and

click Details for each one: in the Logical system field, you will see

the logical system name assigned to the client in question (CORE,

SALES or PRODUCTION).






3. In the distribution model for the CORE system, select all the model views

containing message type MATMAS.

Hint: Use the Filter model display button.


and Implementing Business Processes! Maintain Distribution Model

and Distribute Views.

b) Click on the Filter model displays button, enter MATMAS in the

Message Type field and select Execute : the system will only display

model views containing message type MATMAS.

4. From the distribution model, display the CORE system's partner profiles for

the SALES and PRODUCTION systems. Check the detail settings for theMATMAS message type.

a) In the distribution model's menu, select Environment ! Change

partner profile.

b) Open the folder for partner type LS (logical system) and select the

entry for the SALES partner.

c) In the outbound parameters, select the entry for message type

MATMAS and click on DetailScreenOutb.Parameter : the SALES

port and the MATMAS05 basic type are assigned here. The IDocs

should be sent immediately.

5. Check the corresponding inbound partner profiles in the SALES system.

a) Call the distribution model as in step 3 a).

b) In the menu, select Environment ! Change partner profile, open the

folder for partner type LS and select the CORE partner.

c) Select the inbound parameters for the entry for message type MATMAS

and click on DetailScreenInboundParameter : process code MATM

is assigned here. The IDocs should be processed immediately.





Lesson Summary

You should now be able to:• Define logical system names and assign them to clients in SAP systems,

where applicable









Lesson: Intermediate Documents

Lesson Overview

In ALE scenarios, the systems involved exchange data in the form of intermediate

documents (IDocs). This lesson deals with the structure of IDocs, presents various

possible ways of generating IDocs and gives you an overview of the whole

process, from IDoc creation in the sender system, through to the processing of the

data in the recipient system.

Lesson Objectives


• Explain and differentiate between the terms “basic type”, “master IDoc”and “communications IDoc”


• Describe the process from the creation of an IDoc in the sender system

through to processing in the target system

Business Example

You want to use ALE to exchange data between two SAP systems and, by doing

so, find out more about the technical implementation of ALE scenarios.

Structure of an IDoc: The Basic Type

In ALE scenarios, data sent between two SAP systems or between SAP systems

and non-SAP systems is transported in the form of Intermediate Documents

(IDocs). The structure of an IDoc is specified by the basic type or IDoc type.

Basic types are linked to message types. A basic type can be compatibly enhanced

for a new release, in the same way as the interfaces of an ABAP function module.

This means that there are often various basic types for one message type: each

basic type represents a version of the same basic pattern.

Note: Message types specify the type of data that is to be distributed.

They are included in distribution model views. In the outbound partner

profiles for sender and recipient, the appropriate basic type is assigned to

one message type (see the lesson on “Basic ALE Customizing”).

The example illustrated below shows a section from the structure of the basic

type MATMAS05.




BIT300 Lesson: Intermediate Documents

Figure 19: The Basic Type

The basic type structures the formatting of the application data that is to be sent.

Among other things, it specifies which data is stored in which location (row

and offset). It also determines the order in which application data belongs to a

message. An IDoc's data is organized in rows. The rows make up the segments of

an IDoc, which are, in turn, composed of segment fields. The row structure of an

IDoc segment is determined by a segment type. For every segment field, the field

name is stored along with the technical properties and semantics of the field. IDoc

segments can be hierarchically related to one another.

An IDoc does not have to contain all the segments of its segment type, 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.

Note: For an overview of the segment structure of a basic type, see

transaction WE30 ( IDoc Type Development ).

The structure of the basic types provided by SAP is documented in detail in SAP

R/3 and mySAP ERM. To call this documentation, go to Tools! ALE ! ALE

Administration! Services! Documentation! IDoc Types and Segments or

call transaction WE60.

In addition to information about the IDoc segments and their hierarchicaldependencies, this documentation includes the following attributes:

• IDoc type attributes: information, such as the first release of the IDoc type.

• Segment type attributes: this includes the information about whether a

segment is “required” or “optional” and the minimum or maximum number

of segments allowed for a segment type.

• Segment field attributes: technical and semantic properties of a field.





In addition to this, the documentation generally contains information about

earmarking a segment field for organizational or business needs.

Note: The basic types provided by SAP can be enhanced to suit the

customer's needs. The BIT350 training course deals with enhancing IDoc

basic types (ALE enhancements).

The Master IDoc

The application programs that you use in ALE scenarios always begin by

generating an internal table based on the IDoc basic type and using an ABAP

program; this table is called a master IDoc. The application data is formatted line

by line according to the basic type and then inserted in this internal table. An

internal table is a data object in an ABAP program that exists only during the

runtime of the program. Internal tables are, therefore, not saved to the database.

Figure 20: Structure of a Master IDoc

Each line in the internal table 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 that describes the structure of

the data part.

The control section of every row consists of the following fields:

MANDT Client

DOCNUM Number of the IDoc

SEGNUM Consecutive number (line number in internal table)





SEGNAM Name of the segment type

PSGNUM Line number of the parent segment

HLEVEL Hierarchy level

The data part consists of the following fields:

DTINT2 Overall length of data part

SDATA Long field of type CHAR. Contains the data in the structure,

which is described by the segment type.

The line type of the internal table is determined by the ABAP Dictionary structure

type EDIDD.

The Communications IDoc

Later in the application program run, the system uses the data from the master

IDoc to generate a communications IDoc, an intermediate document that

is saved to the database and then sent. When the system or documentation

refers to an “IDoc”, they are generally referring to this communications IDoc.

Every communications IDoc consists of exactly one control record and multiple

data records and status records.

Figure 21: Structure of a Communication IDoc





The 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. You define

the value range in each system using a number range interval. The control recordalso contains the key fields of the partner profiles, and the last processing status.

The data records in the communications IDoc correspond to the lines in the

master IDoc.

The status records contain the processing steps of the IDoc. They log the stations

that the IDoc has run through from when it was created to when it was sent; this

helps you to monitor data distribution between systems.

Creating IDocs

Application programs create IDocs in different ways. The figure below covers

the four basic forms of IDoc creation:





Figure 22: How is an IDoc Created?

• Dedicated transactions: the preconfigured ALE scenarios for centralized

master data administration use application transactions that were specifically

programmed for creating IDocs. These transactions are brought together in

the umbrella term “Shared Master Data” (SMD).

• Message control: some logistical applications in SAP R/3 and mySAP ERM

use message control to output the data from their documents. Formatting the

document data in IDoc format is one of the message output options.

• Application programs: some application programs generate IDocs directly

by filling an internal table in IDoc format and further processing it.

• Business Application Programming Interfaces (BAPIs): the application

program uses a BAPI with an ALE interface.

Note: In later units, you will become familiar with examples of IDoc

generation using SMD, message control and BAPIs. In each lesson in this

unit, you will also learn about how you can use these instruments for

your ALE scenarios.

Exchanging Data with IDocs: Overview of the Process

Data exchange using IDocs begins in the sender system when an intermediatedocument is created in IDoc format and ends when the data transported by the

IDoc is posted in an application in the target system. In the process, certain stations

are processed, which the sender and target systems each mark with status values.





Figure 23: The IDoc's Path and Status Values

• Regardless of how the IDoc was created, it is first saved to the sender

system's database (status value 01).

• If all the information required for sending has been obtained from the

recipient, then the IDoc receives the status “ready for dispatch” (status value

30).

• If the outbound partner profiles specify that the IDoc is to be transferred

immediately to the port stored in the relevant message type, then the IDoc is

sent and receives a corresponding status (status value 03). However, it is also

possible to send multiple IDocs bundled together at a later time.

• The IDoc is saved to the target system's database (status value 50).

• If all information about further processing is known, the IDoc can be

transferred to the application (status value 64).

• If the inbound partner profiles specify that the IDoc is to be transferred to

the application immediately, the target system attempts to post the IDoc data

(status value 62). If the inbound processing is successful, the IDoc receivesstatus value 53.

Note: You will find out about other status values in the unit on

“Monitoring Data Processing, Error Handling and Archiving”.

Exchanging Data with IDocs: Process Substeps

First, the application program generates a master IDoc containing the application

data.





Figure 24: Generating a Master IDoc

The master IDoc is transferred to what is known as the ALE layer. The ALE layer

is the ALE-specific part of the application program.

The ALE layer checks the distribution model to determine the recipient(s) of

the message.

Figure 25: Recipient Determination in the ALE Layer





Next in the program's run, the sender system checks the outbound partner profiles

for the message type used. For each recipient, a communication IDoc is created

according to the basic type and is saved to the database.

In order to be able to send the communications IDoc to the recipient, the sender

system uses the outbound partner profile to determine the port (in other words,

the communication channel) via which the IDoc is to reach the target system.

Then the IDoc is converted into the format suitable for the port. This part of the

program is also known as the communication layer.

Figure 26: Further Processing in the Communication Layer

The ALE layer can pass a communications IDoc directly to the communication

layer. However, for performance reasons, it is often better to first save the IDocs

to the database and then to process them collectively later. The partner profile

determines whether a communications IDoc is sent to the port immediately or

not until later.

Metaphorically speaking, the communications IDoc is like a letter that is to be sent

to one or more recipients. The letter is copied and a copy is placed in an envelopefor each recipient. The sender and recipient are noted on the envelope. Then it is

placed in an out-tray whose contents are later put in a mailbox.

Two types of port are used for sending IDocs: tRFC ports and file ports.





Figure 27: Port Types

The port type tRFC is short for “transactional Remote Function Call”. The

technology of the transactional RFC ensures that the recipient receives the

document once and once only. If the recipient cannot be reached at the time of

sending, the system attempts to establish the connection again at regular intervals.

The document is only deleted from the tRFC queue when it has reached the target

system. In ALE scenarios, data transfer is via tRFC.

Not every partner system is able to interpret the RFC protocol. In EDI scenarios

involving a converter, a file port is often used, for this reason. The IDoc is stored

for this file port as a sequential file at the operating system level in such a way

that the target system can access it. A corresponding path in the file system

is entered in the port.

The IDoc is initially saved to the database in the recipient system.





Figure 28: Inbound Processing in the Recipient System

Depending on the defaults in the partner profiles, the IDoc is either transferred

to the ALE layer immediately or not until later by a program for background

processing.

The ALE layer uses the partner profile to determine a transaction code that

controls how the IDoc is processed further. Generally speaking, the data istransferred to the application by a function module. However, a workflow could

also be started instead.





Exercise 2: Documentation for Basic

TypesExercise Objectives


• Display documentation about basic types in mySAP ERP

Business Example

You want to use ALE to exchange data between two SAP systems and, by doing

so, find out more about the technical implementation of ALE scenarios.

Task:

You want to learn about the structure of the MATMAS05 basic type, so that you

can use the “Central Material Master Management” ALE scenario.

1. From the application menu, display the documentation for the basic type

MATMAS05.

2. Find segment type E1MARMM ( Material master units of measure) and

display the structure. Which segment type is dependent on E1MARMM?

3. Change your user settings so that, in future, the link to the documentation

for individual segment fields is displayed next to the link to the structure

of the corresponding segment type.





Solution 2: Documentation for Basic

TypesTask:

You want to learn about the structure of the MATMAS05 basic type, so that you

can use the “Central Material Master Management” ALE scenario.

1. From the application menu, display the documentation for the basic type

MATMAS05.

a) Select Tools ! ALE ! ALE Administration ! Services !

Documentation! IDoc Types and Segments.

b) In the Basic type field, enter MATMAS05 and select HTML Format .2. Find segment type E1MARMM ( Material master units of measure) and

display the structure. Which segment type is dependent on E1MARMM?

a) Segment type E1MARMM is dependent on segment type E1MARAM

( Material master general data). Click on the Structure link below

the status information about segment type E1MARMM to call a list

of segment fields.

b) Segment type E1MARMM ( Material master EAN code) is dependent

on segment type E1MARMM.

3. Change your user settings so that, in future, the link to the documentation

for individual segment fields is displayed next to the link to the structureof the corresponding segment type.

a) Choose Back to exit the HTML display.

b) In the transaction's menu, select Goto! User Settings, click on

Display <-> Change , set the Documentation Output indicator and

save your changes.

c) Check the changed setting by displaying the HTML display again:

you can now access a Documentation link which you can use to call

information about the individual segment fields.





Lesson Summary

You should now be able to:• Explain and differentiate between the terms “basic type”, “master IDoc”









Lesson: Synchronizing Customizing

Lesson Overview

Data exchange across system boundaries requires the basic configurations of the

applications involved in the sending and target systems to be aligned with each

other. This lesson deals with synchronizing Customizing for the purposes of ALE.

Lesson Objectives



landscapes

Business Example

Previously, you modeled your business processes in one particular system. In the

future, you want to outsource a subprocess to a second system. You want to be

able to assess the consequences and give yourself an overview of the different

methods for aligning the system configuration.

Consequences of Distributing Applications AcrossTwo Systems

If all applications are integrated in one system, the programs access the samedatabase. In this type of system, the consistency of the data is guaranteed because

every item of logical information is stored in only one database table, and all

programs retrieve data directly from the database. As soon as one application is

separated from the rest of the applications by being installed in another system, the

applications need to communicate via interfaces. The Customizing settings and

master data must be consistent in all the communicating systems.




BIT300 Lesson: Synchronizing Customizing

Figure 29: Distributing Applications Across Two Systems

In ALE scenarios, IDocs are used to exchange application data between the

systems involved in a process. This exchange can only work if an IDoc contains

only field values that are also defined in the target system, unless these are fields

for which unrestricted data entry is planned. However, in most of the fields in the

master data and documents for SAP applications, only the field values pre-defined

in Customizing are allowed. This means that, before you distribute the data, you

need to make sure that these catalogs of values match in both the sending and

target systems. If you cannot (or do not wish to) match the systems, deviating

field values need to be replaced by values from the target system during further

processing of either the outbound or the inbound IDoc.

Business Process in One System

A business process often consists of multiple single steps. Within a business

process, an agent can be responsible for more than one step. However, process

steps can also be carried out by different agents. Applications in SAP can

be affected by more than one partial solution. Once a process step has been

processed, the newly created or changed data is saved to the database. The agent

for the next process step needs to be informed, and the data required for executingthe next step needs to be transferred.





Figure 30: Business Process in One System: Example

The example shown above illustrates a sales order being processed in an SAP R/3

or SAP ECC system. Agent 1, a sales employee, records the customer's order in

the system. The system (agent 2) automatically creates the shipment for this sales

order. A further employee (agent 3) creates a transfer order so that the product

that is to be shipped is removed from storage. Once the product has been removed

from storage, the system (agent 2) posts the goods issue so that the sales employee(agent 1) can end the process by creating the billing document, in other words, the

invoice for the customer. This process therefore involves not only various agents

but also various subsolutions (sales, delivery processing, warehouse management

and inventory management).

Business Processes in Multiple Systems

If a business process extends across not only various subsolutions but also across

different systems, then specific data needs to be forwarded to the next agent. In

ALE scenarios, an IDoc functions as a “container” for this data.





Figure 31: Business Processes in Two Systems: Example

The figure illustrates the same process as the last one. The difference to the first

example is that warehouse management is outsourced to a second SAP system.

The shipment data from the first system is transferred to the second system in an

IDoc. There, it is processed further in the stock removal step. After this procedure

has been completed, the warehouse management system creates a second IDoc

with all the data necessary for continuing the shipment process in the first system.

Note: This is a simplified representation of the “Decentralized Warehouse

Management System” ALE scenario.

Synchronizing Customizing Settings with ALE

In addition to distributing master data and transaction data, you can also use ALE

to align the Customizing settings between systems (in preparation for distributing

master and transaction data). Message type CONDA2 is available in the SAP R/3

and SAP ECC systems for this purpose ( ALE: Synchronization of Customizing

Data). The core of this function is an automatic alignment of selected Customizingobjects in two SAP systems: this alignment generates transport requests for all

the changes.

Note: In systems released before SAP R/3 4.6A, use message type

CONDAT instead.

To optimize the use of ALE for Customizing synchronization, one logical

system in the system landscape is identified as the central Customizing system.

Changes to certain Customizing tables are made in this system only. You can





determine exactly which objects should only be changed in the context of ALE

distribution. You group together these objects, known as ALE Customizing

objects, into distribution groups, which are automatically assigned to the logicalmaintenance system. You then need to distribute these distribution groups to the

target systems. It is now no longer possible (or only partly possible, depending on

the particular configuration) to carry out any changes in the target system to the

objects contained in the distribution groups.

Note: You can distribute all client-dependent Customizing objects of

category CUST. Each object can be assigned to one distribution group,

and one only.

All the Customizing settings you need for cross-system Customizing comparison

and subsequent synchronization can be found with transaction SALE. In the

menu, select IDoc Interface/Application Link Enabling (ALE) ! Modelling

and Implementing Business Processes! Synchronization of Customizing Data.

You can call the relevant application transactions in SAP Easy Access via Tools

! ALE ! ALE Administration! Services! Customizing Data. Here you

will find a program for matching Customizing tables in the sending and target

systems, known as the “Customizing Cross-System Viewer” (transaction SCU0),

and transaction for generating and further processing ALE transport requests for

Customizing synchronization. The sending system creates IDocs of message type

CONDA2 for the transport requests: these IDocs contain the core information

about each request. Inbound processing of these IDocs controls the importing of

request data in the target system: either a workflow is sent to the responsible

administrator requesting him or her to carry out the import, or the import is carriedout automatically by a program executed in the background.

Note: The ALE transport request can be consolidated by a dedicated

transaction (BDXL) with transport requests for exporting the changes to

the quality assurance and production systems.

Synchronizing Customizing Settings with the SAPSolution Manager

As an alternative to distributing Customizing settings with ALE as described in

the previous section, you can use the SAP Solution Manager

: this is an extensive

set of instruments for configuring and operating SAP solutions. The SAP Solution

Manager includes two components for synchronizing Customizing settings

between SAP systems: the Customizing Scout and Customizing distribution.

The Customizing Scout compares the configurations of multiple SAP systems

and displays the differences. The comparison can – as in ALE – be carried out

interactively or in the background, and periodically, if required. After the settings

have been matched, the Customizing distribution instrument can create transport

requests for each changed Customizing object in the maintenance system and





distribute the requests automatically to the downstream systems. It is, however,

also possible to distribute manually. Certain Customizing objects are predefined in

the SAP Solution Manager as synchronization objects.

Converting Field Values: Cross-System CompanyCodes

It is not always either possible or desirable to standardize Customizing in a system

landscape. If, for example, a logical system represents an enterprise's subsidiary,

then the keys for the organizational units will normally differ, at least in part. The

subsidiary will be assigned to a different company code than the parent company.

For this reason, you use what are known as cross-system company codes in ALE

scenarios. These are freely-definable keys that are each assigned to one “genuine”

company code, in other words, a company code used in the application. Whencreating a communications IDoc containing the field Company Code in one of its

segments, the sending system replaces the company code key from the application

(such as a customer master that is to be distributed) with the key for the assigned

cross-system company code. The target system carries out the same operation in

reverse: it replaces the cross-system company code with the “genuine” company

code, in order to create or change the customer master. You can find the tables

for defining cross-system company codes and linking them to the company codes

used in the applications under transaction SALE, via IDoc Interface / Application

Link Enabling (ALE)! Modelling and Implementing Business Processes!

Global Organizational Units! Cross-System Company Codes. You need to carry

out similar settings for the business areas.

Caution: You need to define and assign at least one cross-system

company code in the sending and target systems, even if the company

code keys are identical. If this setting is missing, IDoc processing fails.

The outbound IDoc receives status 29 ( Error in ALE Service) and the

inbound IDoc receives the corresponding status 65.

There are only a few cases where you can convert field values directly using

Customizing tables before the IDoc is sent or before IDoc inbound processing.

For all other field values that need to be replaced by other values, you can use

the Field Conversion tool. This allows either the sending or the target system

to change the content of IDoc segment fields during runtime of the application program in question. Field conversion is based on rules and allows for a more

differentiated data changing procedure than that provided by exchanging values

on the basis of Customizing table entries.

Note: The configuration of field conversion is one of the topics covered

in the BIT350 training course (ALE Enhancements).





Lesson Summary

You should now be able to:• Describe methods for adjusting Customizing settings in SAP system

landscapes




BIT300 Lesson: ALE and the SAP NetWeaver Exchange Infrastructure

Lesson: ALE and the SAP NetWeaver Exchange

Infrastructure

Lesson Overview

Lesson Objectives



Business Example

You have already set up some ALE scenarios in your system landscape and areconsidering using SAP NetWeaver Exchange Infrastructure to exchange data

between the systems involved and with third parties.

The SAP NetWeaver Exchange Infrastructure

The Exchange Infrastructure from SAP NetWeaver (SAP XI) enables you

to realize cross-system business processes. SAP XI makes it possible to link

systems from various providers in different versions and implemented in different

programming languages (Java, ABAP, and so on). SAP XI is based on an open

architecture and supports the protocols, data formats and interfaces used in SAP

and non-SAP systems.SAP XI consists of an Integration Server that acts as a central message bus,

receiving and forwarding (routing) messages, thereby carrying out the necessary

mapping between different data formats. Messages are processed within SAP

XI in the form of XML documents. Any systems that do not directly support

this data format can be linked to XI with SAP XI adapters. There are a variety

of adapters for this purpose; these are provided either by SAP itself or by SAP's

partner companies.

Note: Adapters need to be configured for the connection to a system. This

configuration is carried out in the form of a communication channel.

A communication channel defines the rules of inbound and outboundmessage processing.





In addition to the Integration Server, SAP XI consists of a series of components

with various different tasks, introduced briefly below:

• The Integration Repository is the directory of message interfaces involved

in data exchange. The mappings between the interfaces are stored here as

well.

• The configuration is stored in the Integration Directory; in other words, the

routing information about which message is to be sent from which system to

which other system.

• The systems themselves are stored in the System Landscape Directory

(SLD) in the form of business systems. In addition to system information,

the SLD also contains the information about the products and software used.

Figure 32: Components of SAP NetWeaver Exchange Infrastructure

ALE Scenarios and SAP XI

The Integration Server uses the IDoc adapter to connect back-end systems that

are to send or receive IDocs. The IDoc adapter is a part of the ABAP side of the

Integration Server and communicates with the back-end system via transactional

RFC (tRFC).

The IDoc adapter converts IDoc data records into IDoc XML, which is then used

for processing in the Integration Server. The IDoc adapter also has to convert

information from the sending and target systems, since these are present in theIntegration Server in the form of business systems that are stored in the SLD. A

logical system name can be assigned to these business systems.





The IDoc adapter requires IDoc type metadata for conversion between IDoc and

IDoc XML. You need to define a port in transaction IDX1 in the Integration Server

to enable the IDoc adapter to access data in the backend repository: this IDX1 portreferences an RFC destination (type 3), which refers to the back-end system.

Note: After it is accessed, the IDoc type metadata is held in a cache which

can be seen on the Integration Server via transaction IDX2, where it can

also be manually deleted.

The interfaces for the systems involved in data exchange are stored in the

Integration Repository so that they can be used for mapping and routing. IDoc

types therefore need to be imported into the Integration Repository. To do this,

the data for the connection to the back-end system is assigned to the software

component version to which the IDoc type belongs and into which it is to be

imported. Then the metadata is loaded via RFC call from back-end system

into the Integration Repository. The name of the IDoc type is stored in the

Integration Repository in the form: <message type>.<IDoc type>, for example

MATMAS.MATMAS05.

For an IDoc to be sent from the Integration Server to the back-end system, there

needs to be a communications channel (of the type “Receiver IDoc”) stored in the

Integration Directory, containing technical information about the connection to the

back-end system. The communication channel specifies, on the one hand, an RFC

destination for sending the IDoc and, on the other hand, a reference to the IDX1

port, which references an RFC destination for accessing the IDoc type metadata.

Note: No communication channel needs to be stored for IDocs sent from

the back-end system to the IDoc adapter. However, an IDX1 port is also

needed here to access the metadata.

In a scenario where IDocs are to be exchanged with the Integration Server, you

need to carry out the following steps on the Integration Server:

• SLD: assign a logical system name to the business system assigned to the

back-end system

• Integration Repository: import the IDoc type

• Integration Server (ABAP): create an RFC destination to the back-end

system (transaction SM59)• Integration Server (ABAP): create a port with a reference to the RFC

destination (transaction IDX1)

• Integration Directory: create a communication channel of the type “Receiver

IDoc”





Figure 33: XI IDoc Adapter

The configuration in the back-end system consists of the usual ALE configuration

objects (distribution model, partner profiles, port, RFC destination). The RFC

destination that refers to the Integration Server in order to send IDocs there is of

type 3 (“connection to R/3 system”) because the IDoc adapter is on the ABAP

side of the Integration Server.

Note: The ALE inbound function module IDOC_INBOUND_ASYN-

CHRONOUS checks whether it has been executed on the Integration

Server and, if it has, then it transfers the received IDoc as an XML

document to XI processing and not ALE processing.

If you do not want to use any logical system names in the IDoc for the sender

and recipient information in the control record, but other partner types such as

customer or vendor instead, then the IDoc adapter can also reassign these types

into the business systems required in the Integration Server. For this to happen,

the business system that corresponds to the back-end system needs to be assigned

this partner type in the Integration Directory using what is known as a partner

object as an identifier.





Lesson Summary

You should now be able to:• Explain how ALE scenarios are integrated into SAP XI




Unit Summary BIT300

Unit Summary

You should now be able to:







where applicable



• Complete a view in a distribution model• Explain the function of RFC destinations, ports and partner profiles

• Explain and differentiate between the terms “basic type”, “master IDoc”






landscapes





Unit 2 Master Data Distribution

Unit Overview

The decision to manage master data centrally is one of the main reasons for

using ALE. In this unit you will learn about all the settings needed for setting up

a central master data administration.

Unit Objectives


• Describe the configuration of an ALE scenario for distributing material

master data

• Distribute material masters

• Explain the use of change pointers in master data distribution and set them

up in the system

• Describe different methods for filtering data in IDoc processing

• Create a reduced message type and use it in the distribution process

Unit Contents

Lesson: Example: Material Master ... ... .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. 58

Procedure: Creating and Distributing a Model View .. .. .. .. .. .. .. .. .. .. 67Exercise 3: Master Data Distribution...................................... 69

Lesson: Using Change Pointers .. .. ... ... .. ... .. ... ... .. ... ... .. .. ... .. ... ... . 75Lesson: Data Filtering and Reducing the Scope of Data .. .. .. .. .. .. .. .. .. . 80

Exercise 4: Using a Reduced Message Type .. .. .. .. .. .. .. .. .. .. .. .. .. . 93


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 2: Master Data Distribution BIT300

Lesson: Example: Material Master

Lesson Overview

Distributing master data is one of the applications of ALE. This lesson introduces

the “Shared Master Data” instrument for distributing master data, using the

material master as an example.

Lesson Objectives



master data


Business Example

In the future, you want all material masters for the entire corporate network to

be stored in the central system only and for them to be sent from there to the

downstream sales branch and production systems.

Central Material Master Administration

One method of keeping the master data consistent in a system landscape is to

maintain the master data in a central system, and replicate it to the downstreamsystems at regular intervals. It is either not at all possible, or only possible to a

limited extent, to change data in these latter systems.

Figure 34: Example Scenario




BIT300 Lesson: Example: Material Master

In the example illustrated above, the material masters for the enterprise are created

and changed in the head office (central system). New material masters and

changes to existing data are regularly sent to the downstream systems for the salesand distribution branch and production.

Note: The lesson on “Using Change Pointers” deals with distributing

changes to the master data at regular intervals.

There are standard ALE scenarios for distributing master data; these are

documented in the SAP Library and in the IMG. You can use transaction SALE to

find descriptions of how to set up certain master data distribution scenarios. To

do this, go to IDoc Interface / Application Link Enabling (ALE) ! Modelling

and Implementing Business Processes! Configure Predefined ALE Business

Processes! Logistics! Master Data Distribution. For more information, follow

menu path IDoc Interface / Application Link Enabling (ALE)! Modelling and

Implementing Business Processes! Master Data Distribution. In this section

of the IMG, you can carry out the Customizing settings for your master data

distribution scenarios described in this lesson.

You need to answer the following questions before you configure any distribution

scenario:

• Which system is which master data maintained in?

• When and how often should the master data be replicated to which

downstream systems?

• If there is more than one target system, are all changes to the master data

relevant to all target systems?

• Which Customizing settings need to be synchronized in the systems

involved?

Configuration of the Central Material Master Administration

The figure below illustrates the most important elements in the example scenario:





Figure 35: Basic Settings for the ALE Scenario

The head office's logical system is called CORE. The sales and distribution

branch's logical system is called SALES and the logical system for production

is called PRODUCTION. The message type for distributing material masters

is MATMAS.

First, use this information to create a new view in the distribution model of

one of the system's involved. In the training scenario, CORE is the maintenancesystem for all model views. In the new view, you need to specify the behavior

of the sender and the recipient and inform the system about what type of data is

to be distributed.

Figure 36: Maintaining the Distribution Model and Distributing Views

To ensure consistency, you should maintain the distribution model centrally, and

distribute or transport the relevant views to the other participating systems.





If RFC destinations already exist with the same names as the logical target

systems, you can now have the system create the outbound partner profiles for

the new model view. When it generates partner profiles, the system automaticallycreates an entry for the message type MATMAS and also an entry for message

type SYNCH for each profile ( ALE:Dummy Message Type for Determination of

RFC Destinations). This message type is not used for generating IDocs: it is only

used for determining the RFC destination of the relevant target system. The entry

for message type SYNCH is a prerequisite for distributing model views.

Note: If your RFC destinations have different names to the target systems

to which they lead, you need to first create the entry for message type

SYNCH manually and then assign the RFC destination you require using

the relevant port. After you have done this, you can have the system

generate the remaining partner profiles.

Partners of the type “logical system” (LS) are always created for ALE scenarios.

The name of the partner is always the same as the logical system name.

Figure 37: Partner Profile: Partner Type

The figure below schematically represents the most important settings at the

outbound partner profile level:





Figure 38: Partner Profile (Outbound)

In the outbound partner profile for a message type, store the following information:

• Receiver port: in ALE scenarios, the sending and target systems exchange

data via RFC. You therefore need to use a port of the type “transactional

RFC” in the outbound partner profiles for ALE scenarios; the RFC

destination of this RFC leads to the target system, the partner in the profiles.

• Output mode: You can choose between Transfer IDoc Immed. and Collect

IDocs.

• Package size: If you choose Transfer IDoc Immed., the IDocs are sent

individually. If you choose Collect IDocs, multiple IDocs are collected in

packages and sent together. Collecting IDocs to send together can improve

performance. As a guideline, we recommended collecting between 20 and

100, depending on the size of the IDocs.

• Basic type: in this field, you need to enter the IDoc type that is compatible

with the target system's release level.

Note: If you select the Collect IDocs output mode, you need to execute

the RSEOUT00 program to transfer the IDocs to the communication

layer. This program is usually scheduled as a periodic background job.

After you have created the outbound partner profiles for the target systems, you

can distribute the new model view to these systems.





Figure 39: Distributing the Model View

After you have successfully distributed the model view to the SALES and

PRODUCTION systems, you can display the copies in their respective distribution

models. In the last step, you have the system generate the inbound partner profiles

with the CORE sending system, or you can store the data manually.

Figure 40: Partner Profile (Inbound)





In the inbound partner profile for a message type, store the following information:

• Process code: the process code is a key that refers either to a function

module or a workflow for processing the IDocs. The process code for

message type MATMAS is MATM. If you double-click on the process code

key, a screen appears containing the information as to which function module

or which workflow is used for inbound IDoc processing. As a rule, function

modules are used in ALE scenarios.

Note: There can be more than one process code for a message

type (and, accordingly, more than one inbound function module

or workflow). For information about which process codes are

assigned to which message types, see the Inbound process code

table (transaction WE42).

• Processing mode: you can choose between Trigger by background programand Trigger immediately. If you choose Trigger by background program, the

IDocs are transferred to the ALE layer using the RBDAPP01 program. This

program is usually scheduled as a periodic background job.

Figure 41: Processing Times

You can define variants for the RSEOUT00 and RBDAP001 programs for

collective background IDoc processing. You can find both programs in the IMG

via transaction SALE, by going to IDoc Interface / Application Link Enabling

(ALE)! System Monitoring ! IDoc Processing ! Dispatch Collected IDocs

or Update IDocs in Receiver System.





You can check the current status of IDocs in SAP R/3 or mySAP ERM by using

a status monitor. You can call this monitor with transaction BD87 or the menu

path Tools! ALE ! ALE Administration! Monitoring ! IDoc Display!Status Monitor .

Note: Monitoring IDoc processing is covered along with error-handling in

the unit “Monitoring Data Distribution, Error-Handling and Archiving”.

Sending and Requesting Master Data

The “Share Master Data” tool offers you a variety of application transactions for

generating IDocs for distributing master data. You can find these transactions via

menu path Tools! ALE ! Master Data Distribution. You can also call all of the

SMD transactions directly using transaction BALM.

Figure 42: Sending Master Data

You can send material masters directly using transaction BD10, for example

(menu path: Tools! ALE ! Master Data Distribution! Cross-Application!

Material ). In this transaction, you can either specify a target system or get the

system to determine the recipient itself from the distribution model. If you do not

specify a target system, the sending system might generate multiple IDocs.

In ALE scenarios, master data is normally sent from the maintenance system to

the downstream systems. However, with cross-application master data (material,

customer, vendor), it is also possible to retrieve data.





Figure 43: Retrieving Master Data

Message type MATFET, for example, is used for fetching material masters. This

message type is linked to the corresponding views in the distribution model (see

figure). In the application menu, you can find transaction BD11 via Tools!

ALE ! Master Data Distribution! Cross-Application! Material ! Get ; the

target system can use this transaction to request material masters from the sending

system. Message type MATMAS is used for sending the material master IDocs.





Creating and Distributing a Model View

Use

You want (as part of an ALE scenario) to create a new model view in your central

maintenance system's distribution model or enhance an existing model view.

Procedure

1. In the IMG, select SAP NetWeaver ! SAP Web Application Server ! IDoc

Interface / Application Link Enabling (ALE)! Modelling and Implementing

Business Processes! Maintain Distribution Model and Distribute Views.

Switch from display to change mode by clicking on Display <-> Change .

2. Click on the Create model view button and, in the window that then appears,

enter a short description of your model view and a technical name for identifying the model view. Confirm your entries with Enter and save to

create the new model view.

3. Select your new model view and click on the Add message type button. In

the window that now appears, enter both the sender's and recipient's logical

system names and a message type of your choice. Confirm these entries

with Enter ; this will return you to the distribution model, where you can

save the changes.

If you want to link a BAPI to the model view instead of a message type, click

on the Add BAPI button. Add the sender's and recipient's logical system

names (in other words, the method call's target system), enter the description

(not the key) of the business object type you want to use and the appropriate

method. Then confirm your entries with Enter .

4. To distribute the model view to a partner system, there must be outbound

partner profiles with the partner for message type SYNCH. To check if these

exist, select (in the distribution model's menu) Environment ! Change

partner profile. In the folder for partner type LS, search for an entry for your

partner system and check the outbound parameters. If you do not find an

entry for message type SYNCH, add one manually by assigning a recipient

port containing an entry for the RFC destination leading to the partner

system. The basic type has SYNCHRON as its key.

Hint: If the recipient system's logical system name is the same as the

name of the RFC destination leading to it, you can have the system

automatically create the outbound partner profiles for message type

SYNCH and for all of the model view's other message types. To

do this, select (in the distribution model's menu) Environment !

Generate partner profiles.






5. Distribute the new (or changed) model view by selecting the relevant entry

in the distribution model and going in the menu to Edit ! Model view!

Distribute. If there is more than one possible recipient for the data beingdistributed and you only want to send the model view to one particular

recipient, deselect the entries for the other recipients in the Distribute Model

Views window that now appears.

You then receive a log that informs you whether the new (or changed) model

view was successfully distributed or not.

6. If you have not already done so, create the outbound partner profiles for

the message types you have just added to the model view. If there are

outbound partner profiles for message type SYNCH (see step 4), you can

have the system generate all the partner profiles for all the other message

types ( Environment ! Generate partner profiles). If you create an outbound

partner profile manually, you need to assign a recipient port with the

appropriate RFC destination and a basic type, in addition to the message type.

Caution: When selecting the version, bear in mind the recipient

system's release status, since the basic type needs to be recognized in

the target system as well.

You also need to decide whether the IDocs should be sent immediately or

later.

7. In order to be able to use your new (or changed) model view in an ALE

scenario, you now have to create (or have the system generate) suitableinbound partner profiles in the target system. In the inbound partner profiles,

you need an appropriate process code for the message type; this code must

be linked to the function model or workflow for inbound processing. If you

have the system generate the inbound partner profiles, you should check that

it has assigned the right process code for your scenario.





Exercise 3: Master Data Distribution

Exercise Objectives


• Send a material master

• Display an IDoc in the status monitor

Business Example

In the future, you want all material masters for the entire corporate network to

be stored in the central system only and for them to be sent from there to the

downstream sales branch and production systems.

Task:

Create a material master in the CORE logical system and send it in IDoc format

to the PRODUCTION and SALES logical systems. Check the inbound and

outbound processing for each in the status monitor.

1. Create the Basic Data 1 and 2 for material MATALE-## with a description

of your choice. The material should belong to the Mechanical Engineering

industry sector and to material type Finished product . The base unit of

measure is a piece (PC).

Hint: “##” is your group number

2. First send your new material using the relevant transaction in the “Shared

Master Data” instrument to the PRODUCTION logical system. How many

master IDocs and how many communication IDocs were created?

Master IDocs

Communication IDocs

3. Send your material again without specifying a target system. How many

master IDocs and communication IDocs were created?

Master IDocs

Communication IDocs






4. How is the number of IDocs to be sent determined?

5. Display the outbound IDocs for message type MATMAS in the status

monitor in the CORE logical system. What status do the IDocs have?

Hint: If you want to access one specific IDoc, enter the business

object type StandardMaterial and your material number

(MATALE-##) as the object keys on the status monitor's initial

screen.

6. Next, display the IDocs in the status monitors for each of the two recipient

systems: PRODUCTION and SALES. What status do these IDocs have?

Also check the material masters yourself.





Solution 3: Master Data Distribution

Task:

Create a material master in the CORE logical system and send it in IDoc format

to the PRODUCTION and SALES logical systems. Check the inbound and

outbound processing for each in the status monitor.

1. Create the Basic Data 1 and 2 for material MATALE-## with a description

of your choice. The material should belong to the Mechanical Engineering

industry sector and to material type Finished product . The base unit of

measure is a piece (PC).

Hint: “##” is your group number

a) Select Logistics! Materials Management ! Material Master !

Material ! Create (General)! Immediately.

b) Enter material number MATALE-##, select the industry sector

Mechanical Engineering and material type Finished product and

confirm your entries with Enter .

c) Select the views Basic Data 1 and Basic Data 2 and click Enter again.

d) Assign a material description of your choice and add the base unit of

measure PC ( piece). You do not need to make any entries in the Basic

Data 2 view. Save to create the material master.2. First send your new material using the relevant transaction in the “Shared

Master Data” instrument to the PRODUCTION logical system. How many

master IDocs and how many communication IDocs were created?






Master IDocs 1

Communication IDocs 1

a) Select Tools! ALE ! Master Data Distribution! Cross-Application

! Material ! Send .

b) Enter the following data:

Material MATALE-##

Message type MATMAS

Logical system PRODUCTION

Then select Execute .

c) One master IDoc and one communication IDoc have been created.

3. Send your material again without specifying a target system. How many

master IDocs and communication IDocs were created?

Master IDocs 1

Communication IDocs 2


! Material ! Send .

b) Re-enter your material MATALE-## and the message type MATMAS

but leave the Logical System field blank. Click on Execute .

4. How is the number of IDocs to be sent determined?

Answer: The number of communication IDocs depends on the number of

receiver systems. If the recipient system is specified in the send transaction,

only one communication IDoc is created. If you do not specify any recipient

system, then the target systems are determined from the distribution model.

This could mean that more than one communication IDoc is created. The

number of master IDocs always conforms to the number of master records

that are to be sent.






5. Display the outbound IDocs for message type MATMAS in the status

monitor in the CORE logical system. What status do the IDocs have?

Hint: If you want to access one specific IDoc, enter the business

object type StandardMaterial and your material number

(MATALE-##) as the object keys on the status monitor's initial

screen.

a) Select Tools! ALE ! ALE Administration! Monitoring ! IDoc

Display! Status Monitor .

b) In the Message type field, enter the value MATMAS and choose Execute

.

c) Under Outbound IDocs, you should see your IDocs with status 03.

d) Select the entry for message type MATMAS and click on the Display

IDocs button: you receive a list of all the IDocs for this message type.

e) Select one of your IDocs and click Display IDocs again.

6. Next, display the IDocs in the status monitors for each of the two recipient

systems: PRODUCTION and SALES. What status do these IDocs have?

Also check the material masters yourself.

a) Select Tools! ALE ! ALE Administration! Monitoring ! IDoc


b) In the Message type field, enter the value MATMAS and choose Execute

.

c) Under Inbound IDocs, you should see your IDocs with status 53.

d) Select the entry for message type MATMAS and click on the Display

IDocs button: you receive a list of all the IDocs for this message type.

e) Select one of your IDocs and click Display IDocs again.

f) Select Logistics! Materials Management ! Material Master !

Material ! Display! Display Current .

g) Enter your material number (MATALE-##) and click on Enter : both

views are created.





Lesson Summary

You should now be able to:• Describe the configuration of an ALE scenario for distributing material

master data





BIT300 Lesson: Using Change Pointers

Lesson: Using Change Pointers

Lesson Overview

You can always change master data at any time over its lifespan. If you have

centralized master data distribution, you need to ensure that any changes are

promptly transferred to the downstream systems. In this lesson, you will learn

about distributing changes to the master data using change pointers.

Lesson Objectives



up in the system

Business Example

In your enterprise, master data is created and changed in one central system.

You need to ensure that any changes are promptly forwarded to the sales and

distribution and production systems.

Distributing Master Data Changes

In this example, the system landscape is made up of the head office, a sales and

distribution branch and production:

Figure 44: Example Scenario





All master data is created and, where necessary, changed in the head office's

logical system. Newly created and changed master records should be distributed

to sales and production logical systems at regular intervals, so that these systemalso work with up-to-date data.

Change Pointers

Many application programs create change documents for each change made

to their objects (master data and documents). These change documents record

changes to the application objects, normally specifying the person who made the

change and the time of the change. These change documents can be used in ALE

to set what are known as change pointers, which allow the sending system to

select all changed data records and send only these to the target systems.

Figure 45: Change Documents and Change Pointers

With master data distribution using the “Shared Master Data” instrument, you

can specify in Customizing whether a message type works with the change

pointer function or not. The change pointer creates a connection between changedocuments and the corresponding message type.





When it creates or changes a master record, the application program queries

whether the change pointer mechanism is activated or not. If the function is

active, a change pointer is saved to the database together with the applicationdocument and the change document.

Note: To view the change documents, use the report RSSCD100. You

can also call the change documents from the application transaction

in question. To view the change pointers, see the database table view

BDCPV.

Figure 46: Generating IDocs from Change Pointers

You can evaluate change pointers by using the program RBDMIDOC. This

program is usually scheduled as a periodic background job. You can start the

program for testing purposes with transaction BD21 (menu path: Tools! ALE !

ALE Administration! Services! Change Pointers! Evaluate).

The application provides a function module which selects the change pointers,

and creates a master IDoc for each modified application document relevant

for distribution, which it then transfers to the ALE layer. You can display the

assignment of message type and function module for evaluating the the change

pointer with transaction BD60 (menu path: Tools! ALE ! ALE Development

! IDoc! Engineering Change Management ! Define Function Module for

Evaluation).

If you want to distribute master data, first check if the change pointer function is

activated in general (in other words, for the clients in your SAP system). Then

activate change pointer updating for all the message types you want to use in your

distribution scenarios. You can find the relevant table in the IMG via transaction





SALE, by selecting menu path IDoc Interface / Application Link Enabling (ALE)

! Modelling and Implementing Business Processes! Master Data Distribution

! Replication of Modified Data! Activate Change Pointers – Generally or Activate Change Pointers for Message Types.





Lesson Summary

You should now be able to:• Explain the use of change pointers in master data distribution and set them

up in the system





Lesson: Data Filtering and Reducing the Scope of Data

Lesson Overview

In ALE scenarios, not all recipient systems should always receive all of the

sending system's data. This lesson presents various options for controlling the

amount of data that is sent.

Lesson Objectives




Business Example

In your enterprise, master data is created and changed in the head office. However,

the sales branch and production do not always receive the same data. Furthermore,

the various departments in sales and production should be able to supplement

certain sections of master data in their own systems.

Segment Filtering

If you do not want a recipient to receive the complete data record in an IDoc, you

can use segment filtering. Segment filtering is an application-independent ALEservice which ensures that individual segments are deleted from the data part

before the communications IDoc is saved to the database.

Figure 47: Segment Filtering

You can use segment filtering to:

• Reduce the dataset to the information that is required by the target system

• Ensure that detail data maintained in the target system is not overwritten

If you would like to use segment filtering in an ALE scenario, you should first

check the structure of the basic type you are going to use to determine the keys for

the segments you would like to delete. If, for example, you want the sales area

data for the customer masters (basic type DEBMAS0x) to be created in the sales




BIT300 Lesson: Data Filtering and Reducing the Scope of Data

branch system, you can use segment filtering to delete segment group E1KNVVM

( Master customer master sales data) from all communications IDocs for message

type DEBMAS and recipient “Sales”. The customer masters are then distributedto sales without the sales area data.

Note: If you select a segment group – that is, a segment with its

subsegments – for segment filtering, all the subsegments are deleted from

the communications IDoc.

Figure 48: IMG: Segment Filtering

You can set up segment filtering in the IMG with transaction SALE, via IDoc

Interface / Application Link Enabling (ALE)! Modelling and Implementing

Business Processes! Master Data Distribution! Scope of Data for Distribution

! Filter IDoc Segments. In this table, specify the message type and the target

system and the segments to be deleted. The next communications IDoc for the

message type and recipient specified will be generated without these segments.

The figure below schematically illustrates the process flow for IDoc outbound

processing with segment filtering.

Figure 49: Outbound Processing with Segment Filtering





Filter Objects

The following sections introduce filter options that, unlike segment filtering as

described above, are application-dependent. You therefore need to check in each

individual case if the option is available for your ALE scenario.

Many applications are designed to be used with filter objects. These objects

are application data (often organizational units and groupings) whose individual

characteristics can determine whether a communications IDoc is created for a

recipient in the first place, or which parts of the data record being distributed are

contained in the communications IDoc.

Figure 50: Filtering Using Filter Objects

If you work with filter objects in ALE scenarios, you have to define conditions that

need to be fulfilled for specific application data to be included in a communications

IDoc. If the filter object corresponds to a required segment of the basic type in

question, then a communications IDoc is only created if the condition is fulfilled.

In the example illustrated below, material masters (message type MATMAS) are

distributed at regular intervals from the head office to sales and distribution and

production. However, sales and distribution is only supposed to receive material

masters for finished products whereas production requires the master records for

the finished parts and the raw materials.





Figure 51: Example: Distribution Depending on Material Type

The “material type” is one of the filter objects designed for material masters. The

material type groups together materials according to their physical properties, such

as finished products, trading goods and raw materials. In basic type MATMAS0x,

the segment field for material type (MTART) is part of a segment marked as

required. If you now use the material type as a filter object for IDocs of message

type MATMAS in the model view for distributing the material masters to sales,

and assign the finished products material type key (FERT), you are guaranteeing

that only material masters of this material type will be distributed to sales. The

sending system does not generate any communications IDocs for material masters

of other material types, if the recipient is “Sales”. If a filter object refers to anoptional segment of the basic type in question, the segment and its subsegments

are deleted from the IDoc if a field value does not fulfill a condition that is

maintained in the distribution model.

Note: Customers can enhance the list of filter objects provided by SAP

with their own filter objects. The tables required for this can be found in

the application menu along the path Tools! ALE ! ALE Development

! IDoc! Data Filtering .

The figure below schematically represents the required Customizing settings:





Figure 52: Distribution Model: Creating Filter Groups

Conditions within a filter group are linked to each other by “AND” logic. You can

create more than one filter group for each message type in the distribution model.

These filter groups are linked to each other by “OR” logic.

Figure 53: Outbound IDoc Processing with Filter Objects





The filter objects are evaluated in the ALE layer. If filter values are specified for a

message type in a distribution model, the system uses them to derive a condition.

If the condition is met, the communications IDoc is transferred unchanged. If thecondition is not met, the affected rows are deleted from the data part.

Classification

Logistics applications in SAP R/3 or SAP ECC systems can use classification, a

cross-application function, independently of ALE scenarios. Classification allows

you to group application data (generally master data or documents) by fairly

freely-definable criteria. You can use these groupings for the targeted selection of

specific data records, for example. In the ALE context, however, classification

fulfills a different purpose: the membership of a data record to a specific class

determines how it is distributed.

Figure 54: Filtering Using Classification

If you would like to use classification as a filter method in an ALE scenario, you

first need to carry out some basic settings in the class system itself. You need to

mark one class type as the “distribution class type” and create at least one class

for grouping your data in this class type. Then you can add the ALE-specific

settings. You can activate the use of classification in an ALE scenario in the filter object area of a model view (see above).





Figure 55: Distribution Using Classes

To configure classification for ALE scenarios, call transaction SALE (in the IMG)

and select IDoc Interface / Application Link Enabling (ALE)! Modelling and

Implementing Business Processes! Master Data Distribution! Distribution

Using Object Classes. You assign application data to classes yourself in the

application in question. You classify material masters, for example, by creating a

corresponding “view”; that is, a data screen. If a material master record does not

belong to the distribution class specified for the target system, it is not distributedto that system.

Reduced Message Types

Some applications have such flexible programs for inbound and outbound

processing that you can choose whether or not each optional segment field is to be

transferred. To do this, you create what is known as a reduced message type in the

customer namespace as a copy of a message type supplied by SAP; then you select

the fields whose content you want to be transferred to a particular target system.

Figure 56: Filtering with Reduced Message Types





You can use these reduced message types in all ALE scenarios where the

distributed data is not processed in the sending system only. In this kind of

scenario, for example, the sales branch could independently change the materialmasters after they had been initially transferred from head office. Sending these

master records again would result in all the fields that had been changed in the

sales system being overwritten: the sales personnel's work would have been

wasted. If, on the other hand, a reduced message type without these fields is used

in this scenario, then the locally maintained data is protected from overwriting

because the fields – contained in the segment but not selected – are filled with a

“no-data” character (/).

The incoming function module ensures that only the fields activated in the reduced

message type are written to the target system's database. Segment fields that are

absolutely necessary for useful processing in the target system are marked as

“required” in the application.

Figure 57: Prerequisites for Using Reduced Message Types

Before you can use reduced message types, the application must have the

following functions:

• Outbound function module: an ALE function checks whether or not a

reduced message type should be used. When the master IDoc is generated, a“no-data” character (/) is entered in all fields that are not to be transferred.

• Inbound function module: each segment is checked to see which fields

have a “no-data” character. These fields are not written to the database.

This enables you to maintain specific detail data in the local systems, and

to ensure that data is not “accidentally” overwritten with an initial value

when master data is replicated.

• Message type: the message type is marked as “reducible”.





To create a reduced message type, call transaction SALE and go to IDoc Interface

/ Application Link Enabling (ALE)! Modelling and Implementing Business

Processes! Master Data Distribution! Scope of Data for Distribution! Message Reduction! Create Reduced Message Type.

Figure 58: Creating a Reduced Message Type

When you create a new reduced message type, it is based on the most current IDoc

type. First the required segments are selected and then only the fields in these

segments that are marked in a standard SAP system as required fields. These

segments and fields are marked with a green background.

Select a segment by highlighting it and clicking on the Select button. Note: when

you select a segment, only fields that are defined in a standard SAP system as

required fields will be selected. To select additional fields for a selected segment,

navigate to the detail view. In the detail view, first select the additional fields, then

click on Select again. Optional segments or fields that have not yet been selected

are marked with a red background. Optional segments or fields that have already

been selected are colored white.

Caution: You have to click on the Select button before you can exit the

detail screen by selecting Enter . If you select fields and then click on

Enter immediately, your selection is not saved.

If you would like to use the change pointer function (see the lesson on “Using

Change Pointers”) for a reduced message type, you need to set the corresponding

indicator for this reduced message type. To do this, call transaction SALE and





go to IDoc Interface / Application Link Enabling (ALE) ! Modelling and

Implementing Business Processes! Master Data Distribution ! Message

Reduction! Create Reduced Message Type.

Using Reduced Message Types

• Create reduced message type

• Select required fields

• Save and assign a change request

• Activate change pointers (if applicable)

Reduced message types must be recognized in all participating sending and target

systems.

Figure 59: Transporting Reduced Message Types

Because message types are cross-client Customizing objects, they are transported

using a workbench request. You can generate a transport request for any reduced

message type. To do this, go to

Application Link Enabling (ALE)! Modelling and Implementing Business

Processes! Master Data Distribution! Scope of Data for Distribution!

Message Reduction! Generate Transport Request for Message Type.





Figure 60: Outbound Processing with Reduced Message Types

The same program is responsible for generating IDocs for a reduced message

type as for generating IDocs for the template message type. When creating a

master IDoc, the application program first determines detail information about

the reduced message type being used. An ALE function module is used to enter

“/” in the inactive fields of the master IDoc. The master IDoc is then transferred

to the ALE layer.





Figure 61: Inbound Processing with Reduced Message Types

The same inbound function module is used for inbound processing as for an

IDoc for the template message type. The system checks all optional segments to

determine if they contain “/”. Only fields that do not contain “/” are written to

the database.





Exercise 4: Using a Reduced Message

TypeExercise Objectives


• Create a reduced data type

• Create and distribute a view in the distribution model

• Create outbound and inbound partner profiles

Business Example

In your enterprise, material masters are created in the head office and sent to production (and elsewhere). The local business department makes changes to

specific data views, which you want to protect from being overwritten when the

master records are sent again.

Task:

Create a reduced message type as a copy of MATMAS and connect it to your

distribution model. Then test the configuration by sending a material master.

1. In the CORE logical system, create a reduced message type ZMATMAS##

with reference to message type MATMAS. In addition to the segments

E1MARAM ( Master material general data) and E1MAKTM ( Master material short texts), the reduced message type should contain the following

segments and segment fields:

E1MARAM ERNAM (Created by)

BISMT (Old material number )

BRGEW (Gross weight )

NTGEW ( Net weight )

GEWEI (Weight unit )

E1MTXHM Select all

E1MTXLM Select all

Caution: In the segment E1MARAM, ensure the fields LAEDA

( Date of last change), AENAM ( Last changed by), VOLUM

(Volume) and VOLEH (Volume unit ) are not selected.






2. You want to use the change pointer function for your reduced message type

in the future. Set the appropriate indicator.

3. In the CORE logical system's distribution model, create a new model view,

TRAINING##, with CORE as its sender and PRODUCTION as its

recipient. Use your reduced message type, ZMATMAS##, from the first

task.

4. Now have the system generate the outbound partner profiles for message type

ZMATMAS## in the CORE logical system. What basic type is proposed?

Basic type: ______________________

5. If the PRODUCTION logical system is in a different physical system than

the CORE logical system, then you need to define the reduced message

type ZMATMAS## in this system as well before you can distribute the

TRAINING## model view.

Hint: You can also transport the reduced message type to the target

system.

6. Distribute your TRAINING## model view to the PRODUCTION partner

system. In the PRODUCTION system, generate the inbound partner profiles

for message type ZMATMAS##. Which process code is proposed?

Process code: _____________

7. Change some values in your material MATALE-## in the CORE logicalsystem. Make sure you change the volume and the volume unit.

8. Send the changed material directly to the PRODUCTION logical system.

Display the outbound and inbound IDocs in the status monitor for each

system. Did the settings you made in task 1 produce the desired effect?

Hint: Use your reduced message type ZMATMAS##.

9. Display the material MATALE-## in the PRODUCTION system. Which

changes have been transferred from the CORE system?

10. Now change the Old material number field in your MATALE-## materialand then have the system evaluate the change pointers for message type

ZMATMAS##. How many communications IDocs are created?

11. Check the result in the CORE and PRODUCTION systems' status

monitors. In the segment E1MARAM, what is in the fields Old material

number ( BISMT ), Date of last change ( LAEDA), and Last changed by

( AENAM ), and why?





Solution 4: Using a Reduced Message

TypeTask:

Create a reduced message type as a copy of MATMAS and connect it to your

distribution model. Then test the configuration by sending a material master.

1. In the CORE logical system, create a reduced message type ZMATMAS##

with reference to message type MATMAS. In addition to the segments

E1MARAM ( Master material general data) and E1MAKTM ( Master

material short texts), the reduced message type should contain the following

segments and segment fields:

E1MARAM ERNAM (Created by)

BISMT (Old material number )

BRGEW (Gross weight )

NTGEW ( Net weight )

GEWEI (Weight unit )

E1MTXHM Select all

E1MTXLM Select all






Caution: In the segment E1MARAM, ensure the fields LAEDA

( Date of last change), AENAM ( Last changed by), VOLUM(Volume) and VOLEH (Volume unit ) are not selected.

a) In the CORE logical system, call transaction SALE and go to IDoc

Interface / Application Link Enabling (ALE) ! Modelling and

Implementing Business Processes! Master Data Distribution!

Message Reduction! Create Reduced Message Type.

b) In the Reduced message type field, enter the value ZMATMAS## and

choose Create .

c) Enter the template message type MATMAS and select Enter . Add a

description of your choice and click on Enter again.

d) Select the segment E1MARAM and then Choose .

e) Select the ERNAM, BISMT, BRGEW, NTGEW and GEWEI fields,

click on the Select button and then Enter .

f) Display the substructure of the E1MARAM segment, select the

E1MTXHM segment ( Master material long text header and click

on the Select button.

g) Display the substructure of the E1MTXHM segment, select the

E1MTXLM subsegment ( Master material long text line and click on

the Select button again.

h) Save to create the reduced message type. A query appears for a

workbench request for transporting the message type to other systems

later. Choose Create Request , enter a short description of your

choice and create the request by saving it.

2. You want to use the change pointer function for your reduced message type

in the future. Set the appropriate indicator.

a) Exit the overview of the reduced message type's segments in order to

return to the maintenance transaction's initial screen.

b) Click on the Activate change pointers button.






3. In the CORE logical system's distribution model, create a new model view,

TRAINING##, with CORE as its sender and PRODUCTION as its

recipient. Use your reduced message type, ZMATMAS##, from the firsttask.


and Implementing Business Processes! Maintain Distribution Model

and Distribute Views and switch to change mode ( ).

b) Click on the Create model view button, enter a short text of your choice

and the technical name TRAINING## and confirm your entries with

Enter .

c) Select the model view and click on the Add message type button.

d) Enter CORE as the sender, PRODUCTION as the receiver and

ZMATMAS## as the message type, and then select Enter . Create the

new model view by saving it.

4. Now have the system generate the outbound partner profiles for message type

ZMATMAS## in the CORE logical system. What basic type is proposed?

Basic type: ______________________

a) Select your new model view and in the menu, go to Environment !

Generate partner profile.

b) Choose Execute : you receive a log containing a message to the effect

that outbound partner profiles for message type ZMATMAS## and the

partner PRODUCTION have been created. Exit the log with Back .

c) Display one of the two new partner profiles via Environment ! Change

partner profile: select the partner PRODUCTION (partner type LS).

d) Select the outbound parameters for message type ZMATMAS## and

click on DetailScreenOutb.Parameter : the basic type MATMAS05

is assigned here.






5. If the PRODUCTION logical system is in a different physical system than

the CORE logical system, then you need to define the reduced message

type ZMATMAS## in this system as well before you can distribute theTRAINING## model view.

Hint: You can also transport the reduced message type to the target

system.

a) In the PRODUCTION logical system, go to IDoc Interface /

Application Link Enabling (ALE)! Modelling and Implementing

Business Processes! Master Data Distribution! Message Reduction

! Create Reduced Message Type.

b) Create the reduced message type ZMATMAS## as described in step 1.

6. Distribute your TRAINING## model view to the PRODUCTION partner

system. In the PRODUCTION system, generate the inbound partner profiles

for message type ZMATMAS##. Which process code is proposed?

Process code: _____________

a) Select your model view and in the menu, go to Edit ! Model view

! Distribute.

b) Confirm the system selection with Enter : you will receive a message

informing you that your model view was successfully distributed.

c) Switch to the PRODUCTION logical system and call the distributionmodel from there as well, to check if the copy of your model view is

available.

d) Select the model view, on the menu bar choose Environment !

Generate partner profiles and then Execute .

e) Go back to the distribution model and select Environment ! Change

partner profile to check the inbound partner profile for message type

ZMATMAS##.

f) Mark the partner CORE, in the inbound parameters, select the entry

ZMATMAS## and click on DetailScreenInboundParameter : the

process code MATM is assigned here.






7. Change some values in your material MATALE-## in the CORE logical

system. Make sure you change the volume and the volume unit.


Material ! Change! Immediately.

b) Enter T-MATALE-## as your material number and click on Enter .

c) Select the Basic Data 1 view and click on Enter again.

d) Enter a value in each of the fields Old material number , Gross weight

and Weight unit , for example. Also add a volume with a suitable unit

of measure. Save your changes.

8. Send the changed material directly to the PRODUCTION logical system.

Display the outbound and inbound IDocs in the status monitor for each

system. Did the settings you made in task 1 produce the desired effect?

Hint: Use your reduced message type ZMATMAS##.


! Material ! Send .

b) Enter the material master MATALE-##, message type ZMATMAS##

and the logical system PRODUCTION and then select Execute .

c) Select Tools! ALE ! ALE Administration! Monitoring ! IDoc


d) Enter the message type ZMATMAS## and select Execute .

e) Select the entry under ZMATMAS## and click on the Display IDocs

button.

f) On the next screen, select your IDoc and then click again on the

Display IDocs button.

g) Display the data records and select the segment E1MARAM, to check

that the system has placed “no-data” characters in the unselected

optional fields. You should also be able to see this character in the

fields that you did not select in your reduced message type: VOLUM

(Volume) and VOLEH (Volume unit ).






9. Display the material MATALE-## in the PRODUCTION system. Which

changes have been transferred from the CORE system?


Material ! Display! Display Current .

b) Enter T-MATALE-## as your material number and click on Enter .

c) Select the Basic Data 1 view and click again on Enter : the entries in

the Volume and Volume unit fields were not transferred.

d) Check the inbound IDoc in the status monitor as described in steps

8. c) to g).

10. Now change the Old material number field in your MATALE-## material

and then have the system evaluate the change pointers for message type

ZMATMAS##. How many communications IDocs are created?

a) Call the material master as described in step 7 to change it.

b) Enter a value in the Old material number field and save the change.

c) Select Tools! ALE ! ALE Administration! Services! Change

Pointers! Evaluate.

d) Enter your message type ZMATMAS## and select Execute .

e) IDocs are generated for all materials that were changed since the

change pointer function was activated for your message type.

11. Check the result in the CORE and PRODUCTION systems' status

monitors. In the segment E1MARAM, what is in the fields Old material

number ( BISMT ), Date of last change ( LAEDA), and Last changed by

( AENAM ), and why?

a) First call one of the outbound IDocs for message type ZMATMAS##

in the status monitor in the CORE system. Proceed as in step 8.

b) The change you have made is visible in the field Old material number ,

because you selected this field in your reduced message type. The fields

Date of last change and Last changed by, contain “/”. This is because

you did not select these fields when creating the reduced message type.

c) To finish, display an inbound IDoc for message type ZMATMAS## inthe PRODUCTION system: the Old material number field contains

the changes you made, the Date of last change and Last changed by

fields contain “/”.





Lesson Summary

You should now be able to:• Describe different methods for filtering data in IDoc processing





Unit Summary BIT300

Unit Summary



master data



up in the system






Unit 3 Distributing Transaction Data:

Message Control

Unit Overview

Transaction data (documents, postings) can also be distributed beyond system boundaries using ALE. Message control is one of the methods you can use to

implement cross-system processes. However, you can also use it for electronic

communication with business partners (suppliers, customers).

Unit Objectives


• Differentiate ALE and EDI

• Describe the basic functions of message control

• Explain how message control is used to generate IDocs• Create a purchase order and check the events of your message determination

• Describe the cross-system purchase order process

• Explain the most important Customizing settings for this process

Unit Contents

Lesson: Message Control and IDoc Generation............................104Exercise 5: Partner Profiles and Condition Record .. .. .. .. .. .. .. .. .. .. 113

Lesson: Example: Purchase Order Processing ............................ 119Exercise 6: Sending a Purchase Order to a Vendor .. .. .. .. .. .. .. .. .. .125

Exercise 7: Optional: ALE Scenario “Stock Transfer BetweenDistributed Systems” ... .... .... .... ... .... ... .... .... .... ... .... .... .... ..129


http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 3: Distributing Transaction Data: Message Control BIT300

Lesson: Message Control and IDoc Generation

Lesson Overview

This lesson tells you about message control as an instrument for distributing

transaction data in the IDoc format.

Lesson Objectives




• Explain how message control is used to generate IDocs

Business Example

Up to now, your company has sent purchase orders to suppliers by post in paper

form. For the future, you want to convert this process to electronic communication.

In addition, you want the purchase orders of the sales branch to be automatically

converted into orders after they are received by head office.

ALE and EDI: a Comparison

For ALE and EDI scenarios you always use the same instrument: the data, such

as purchase orders, order confirmations or invoices, are sent to the respectiverecipient in the IDoc format, or are recevied by your system as IDocs and are

subsequently transferred to the target applications.

Figure 62: EDI: Purchase Order at a Vendor




BIT300 Lesson: Message Control and IDoc Generation

Up to now, the purchase orders at a vendor in our example company have been

processed on paper: the purchasing employees create purchase orders in the

system at head office, possibly on the basis of purchase requisitions from other departments, and send them by post to the vendor. However, in the future the

vendor should receive the purchase order data electronically in an EDI standard

format.

In many cases, the external vendors are not part of the company network.

Therefore, the electronic communication with them is often by means of

intermediary subsystems, known as EDI converters. SAP provides an

open interface to such systems (CA-EDI). The EDI subsystems assume the

responsibility for all EDI-specific tasks, such as data conversion, partner profile

management and process monitoring.

Figure 63: Communication by Means of an EDI Subsystem

The SAP application sends an IDoc to the subsystem. In the case of a purchase

order, the message type is ORDERS. The subsystem reads the IDoc and converts

it into an EDI document. This document is sent to the vendor, whose EDI

converter converts the incoming data into a format that can be processed in the

vendor's ERP system. Often an order is automatically created from the data of

the purchase order received.





Figure 64: Port Types

Many subsystems are capable of communicating with SAP systems by means of

tRFC. However, if your subsystem cannot decrypt RFC protocols, you usually use

a port of the “file” type. The directory of the operating system, in which incoming

and outgoing data is to be saved, is entered in the detailed settings for this port.

Partner profiles for EDI scenarios must always refer to partners of the partner

types LI (vendor) or KU (customer), while the partners in ALE scenarios are

always logical systems (partner type LS).

Figure 65: Partner Profile: Partner Type LI





Thus, for the EDI scenario represented in the first illustration of the lesson, partner

profiles of partner type LI would be required. When creating such partner profiles,

you always refer to the vendor master data. Therefore, if the vendor was createdusing the key T-BIL00, the EDI partner is also called T-BIL00.

Figure 66: Partner Functions

The “vendor” business partner can have various functions with regard to thecompany. During a procurement procedure, a vendor is first the recipient of the

purchase order, then the goods supplier, later the invoicing party and finally the

payment recipient. A partner does not always carry out all the functions himself.

Thus a party other than the purchase order recipient can deliver the goods. For

this reason, logistical appliations in SAP R/3 and SAP ECC systems work with

partner functions that are assigned in the partner master data and can be changed

in the application documents, if necessary.





Figure 67: Partner Profile for EDI

Therefore, when creating partner profiles for EDI partners, in contrast to ALE,

you always have to enter the respective function in which a partner is sending

or receiving a message.

For EDI scenarios, the distribution model you were introduced to as an important

ALE element does not play any role. The application programs determine

the recipient of the message from the respective application document. The

communication IDoc is then created on the basis of the parameters in the partner

profiles and processed further - for example, it is stored as a sequential file on theoperating system level.

Message Control: Introduction

The application mySAP ERP Procurement already enables you to send a purchase

order by means of a printed form or in IDoc format. For this, the application

uses a cross-application function packet, the message control. In SAP systems,

a message is information that is output in various formats. The purchase order

printed on paper or sent as an IDoc is only one of many examples of the use of

message control in logistics applications. You can also send the information

contained in your SAP R/3 or SAP ECC documents as a fax or an e-mail toemployees or partners. The format in which the message is output is determined

by the transmission medium, which you define in advance or which you can -

depending on the default settings - specify in individual cases before the output.





Figure 68: Transmission Medium

Every time you save a new or altered purchasing document (for example, a request

for quotation, a purchase order or an outline agreement), the system checks

whether a message has to be created for this document, and in which format - that

is, by means of which transmission medium - this message is to be output.

The individual message, such as the IDoc with the purchase order data, is always

created on the basis of a message type which is defined in the Customizing of

the respective application. Message types are keys to which the most important

control parameters for determining and subsequently outputting messages are

linked. For example, the message type for outputting purchase document data is

called NEU (new printing of purchase order ).





Figure 69: Message Types

Message types are application-specific. Every application that uses the message

control is indicated by a two-character key. For example, Purchasing, which is

responsible for the purchase order processing, has the key EF. To get an overview

of all the applications that use the message control, you use transaction NACE.

With this transaction (message types button) you can also call up the list of all the

message types defined for an application.

Message Determination

The message control works with the condition type, a method of enabling the

system to find application objects on the basis of previously defined conditions.

The condition type is used in many applications in SAP R/3 and SAP ECC.

Examples are the price determination in Purchasing and Sales and the batch

determination in the overall logistics. The system also finds messages on the basis

of condition records, which are combinations of conditions under which a certain

message is to be output in a certain format.

The condition type works with what are known as condition elements, which aredependent on one another. The illustration below shows the inner hierarchy of the

condition elements using the example of message control for Purchasing:





Figure 70: Message Control: Condition Elements

The respective application program (for example, “create purchase

order”) specifies the application (for example, EF). The suitable output

determination procedure (for example, RMBEF1), which groups

together message types on the basis of various perspectives, is found

by means of Customizing tables, depending on the application. Thus,

for example, the document type can decide on the procedure to be used.

Every message type of a procedure (for example, NEU) is assigned an accesssequence (for example, 0001). Access sequences group together condition

tables. These condition tables contain, in various arrangements, all the document

fields that are to function as conditions for determining the messages in the

application document. In the example shown, the access sequence 0001 contains

three condition tables which are checked in the sequence specified in the access

sequence. The first condition table in this sequence (27) contains the fields

purchasing organization and vendor . If you now want to define conditions for the

determination of the message type NEU, the system now asks you, on the basis of

the assigned access sequence, for the “key combination”, that is, for the desired

combination of fields according to the condition table. Depending on the selection,

you then have to make certain entries, such as for the purchasing organization

and the vendor. In this way you specify, for example, that the message NEU is

always output in IDoc format when the purchase order is from the purchasing

organization 1000 for the business partner T-BIL00 in his function as vendor (LF).





Along with the transmission medium (see above), you also always have to enter a

processing time in the condition record. You have a choice of three processing

times:

• Immediate transmission when the document is created (4)

• Subsequent transmission by means of a job (1 and 2)

• Subsequent transmission triggered by the user by means of a dedicated

transaction (3)

If you select the transmission medium “EDI” in the condition record, you must

create appropriate partner profiles for the partner entered there and his function.

If you want to use the transmission medium “ALE”, in addition to the partner

profiles there must also be a corresponding model view in the distribution model.

Figure 71: Message Determination in the Purchase Order

When creating a purchase order, the application program checks in the message

determination whether a message is to be created. If the transmission medium is

“EDI” or “ALE”, the system checks whether suitable partner profiles exist andwhich IDoc type is specified for the data output. If the message determination is

successful, a message is created. All messages are stored in the database table

NAST. Based on the IDoc basic type specified in the partner profiles, the program

RSNAST00 creates a communication IDoc from the data of the purchase order.

(If, on the other hand, “print output” were specified, then the corresponding form

would be filled.)





Exercise 5: Partner Profiles and Condition

RecordExercise Objectives


• Set up partner profiles for the EDI communication with a vendor

• Create a message determination record

Business Example

In the future, you want to send purchase orders to one of your vendors by means

of EDI.

Task:

Create partner profiles for the vendor and then a suitable determination record for

the message type of the purchase order data output.

1. Create partner profiles with the vendor T-K515D## for the message

type ORDERS. Use the IDoc basic type ORDERS05 and the file port

SUBSYSTEM. The IDocs should be transferred to the subsystem together,

but this should not be started by the SAP system. The appropriate message

type has the key NEU. You work on the application level of Purchasing.

Which process code is specified? Assign yourself as the agent in the case

of an error.

Process code: _______________

Hint: Please also remember the partner type and the partner function.

2. Get the system to check the partner profiles you have just created.

3. In the application menu of Purchasing (purchase orders), create a

determination record for the message type NEU. Messages of this message

type should always be output if the purchasing organization 1000 orders

goods from the vendor T-K515D##. The system should output the messagein IDoc format by means of EDI. The IDoc should be generated immediately

after a purchase order is created.






4. Optional: How do you proceed if you also have an agreement with your

vendor T-K515D## that in future he should send you order confirmations

by EDI for your purchase orders?

Hint: If necessary, use the input help for the Message type field to

look for a suitable message type using the short description “Order

confirmation”. You can also use the short description to determine

the appropriate process code.





Solution 5: Partner Profiles and Condition

RecordTask:

Create partner profiles for the vendor and then a suitable determination record for

the message type of the purchase order data output.

1. Create partner profiles with the vendor T-K515D## for the message

type ORDERS. Use the IDoc basic type ORDERS05 and the file port

SUBSYSTEM. The IDocs should be transferred to the subsystem together,

but this should not be started by the SAP system. The appropriate message

type has the key NEU. You work on the application level of Purchasing.

Which process code is specified? Assign yourself as the agent in the case

of an error.

Process code: _______________

Hint: Please also remember the partner type and the partner function.

a) Choose Tools! ALE ! ALE Administration! Runtime Settings

! Partner Profiles.

b) Choose Create , enter the partner number T-K515D## and the

partner type LI and save your entries.

c) In the output parameter area, choose Create output parameter .

d) Add the partner function LF and on the Outbound Options tab page,

add the message type ORDERS, the receiver port SUBSYSTEM and the

IDoc basic type ORDERS05. If they are not already selected, choose

Collect IDocs and Do not start subsystem.

e) Choose the Message Control tab page and here choose Add row .

f) Enter the application EF and the message type NEU. In the input help

for the field Process Code, ME10 (ORDERS: Purchase order ) appears.

Press Enter to accept this key.

g) Select the Post Processing: Permitted Agent tab page to assign your user BIT300-## (agent type US) and a notification language of your

choice. Save these changes.






2. Get the system to check the partner profiles you have just created.

a) If necessary, open the folder for the partner type LI and select your

vendor T-K515D##.

b) Choose Check , then choose Execute in the window displayed:

you obtain a detailed log of the check on your settings.

3. In the application menu of Purchasing (purchase orders), create a

determination record for the message type NEU. Messages of this message

type should always be output if the purchasing organization 1000 orders

goods from the vendor T-K515D##. The system should output the message

in IDoc format by means of EDI. The IDoc should be generated immediately

after a purchase order is created.

a) Choose Logistics! Materials Management ! Purchasing ! Master

Data! Messages! Purchase Order ! Create.

b) Enter the output type NEU and choose Enter .

c) Choose the key combination Purchasing Output Determination: Purch.

Org./Vendor for EDI and confirm your choice with Enter .

d) Enter the purchasing organization 1000, the vendor T-K515D##,

the partner function LF, the medium 6 and the time 4. Create the

determination record by saving.

Hint: If you leave the Language field empty, the system uses

the language of the vendor in his master record.






4. Optional: How do you proceed if you also have an agreement with your

vendor T-K515D## that in future he should send you order confirmations

by EDI for your purchase orders?

Hint: If necessary, use the input help for the Message type field to

look for a suitable message type using the short description “Order

confirmation”. You can also use the short description to determine

the appropriate process code.

a) Choose Tools! ALE ! ALE Administration! Runtime Settings

! Partner Profiles.

b) Open the folder for the partner type LI and select your vendor

T-K515D##.c) In the inbound parameter area, select Create inbound parameters

and first enter the partner role LF again.

d) Call up the input help for the field Message type and open the details

in the Restrictions tab page by clicking on the small triangle in the

bar below the tab page.

e) In the field Short text , enter *Order confirmation* and press

Enter to confirm: The system prompts you with, among other things,

the message type ORDRSP ( Purchase order/Order confirmation).

Select the default and accept it with Enter .

f) Now call up the input help for the field Process code and follow theshort description of the process: The suitable process code has the

key ORDR (ORDRSP Sales order confirmation). Accept it with a

double-click and save your changes.





Lesson Summary

You should now be able to:• Differentiate ALE and EDI






BIT300 Lesson: Example: Purchase Order Processing

Lesson: Example: Purchase Order Processing

Lesson Overview

This lesson tells you about IDoc generation by means of the message control,

using the example of a purchase order. In addition, you will also be introduced to

one of the ALE scenarios provided (“stock transfer between distributed systems”).

Lesson Objectives


• Create a purchase order and check the events of your message determination



Business Example

The sales branch regularly orders stock replenishments at head office for

processing its customer orders; head office is where the main warehouse of the

company is located. In the future, these purchase orders should be sent to head

office using ALE and be automatically converted into orders there. The sales

branch receives an electronic order confirmation by return. The purchase orders

at vendors are also created electronically by head office, but by means of an

EDI connection.

Message Control: Transmission Media “ALE” and“EDI”

Logistical applications in SAP R3 and SAP ECC systems can use the message

control to generate IDocs for sending transaction data. The system transfers the

data of an application document into the fields of the IDoc on the basis of the

respective IDoc basic type. Then the IDoc can be sent to either a business partner

or another logical system within the company.





Figure 72: Example: Sending a Message in EDI Format

Here you see the transmission of an IDoc to an external vendor by means of an

EDI converter. Therefore, the transmission medium “EDI” (6) was entered in the

message determination record. In addition, there must also be partner profiles

for the partner type “vendor” (LI) to which a receiver port is assigned, which

represents a connection to the EDI converter, or which contains a directory for

storing IDocs as sequential files.

Figure 73: Partner Profiles with an External Vendor





If, on the other hand, the transmission medium of the determination records

is “ALE” (A), then suitable partner profiles with a logical system (partner type

LS) must be created. The field Partner role remains empty. The settings for thegeneration of an IDoc (IDoc basic type and process code) are identical. The port

is usually a tRFC port.

Figure 74: Partner Profile with a Logical System

If you want to use the message control to distribute transaction data, there must

be a process code for the outbound processing. This process code is used to

determine the function module that subsequently uses the entry created by the

message determination in the table NAST (“NAST record”) to determine the

relevant application data and create the master IDoc.

Note: The attribute With ALE services in the process code is used to

control whether you can adapt the IDoc using the ALE services “segment

filtering” and “field conversion”. If this attribute is not set, the master

IDoc is transferred unchanged into the data section of the communication

IDoc and stored on the database.

For ALE scenarios in which transaction data is to be sent with the aid of message

control, you must create or expand corresponding views in the distribution model

of the maintenance system and then distribute them to the respective receiving

systems.





Figure 75: Model View for the Distribution of Purchase Orders

In the example shown, Sales and Distribution - that is, the logical system SALES

- sends purchase orders (message type ORDERS) to head office (logical system

CORE). After receiving and checking the purchase orders, head office sends order

confirmations (message type ORDRSP) to Sales and Distribution.

Message Determination in Ordering and IDocGeneration

When creating a purchase order, the system performs message determination on

the basis of the application-specific Customizing settings for message control.

If this determination is successful, you can immediately call up the result fromthe application document (menu entry Goto! Messages or button Messages in

the initial screen).





Figure 76: IDoc Generation using Message Control

If the transmission medium “ALE” or “EDI” is assigned in the determination

record, a master IDoc is created from the NAST record on the basis of the

outbound parameters of the corresponding partner profiles. The transaction code

controls which application function module is used to generate this IDoc. The

application document key is transferred from the NAST record to this application

function module. The module reads the document data and transfers it into the

segment fields of the master IDoc. If the processing time 4 was entered in the

determination record, the system executes the program RSNAST00 immediately

after you save, in order to generate an IDoc from the NAST record. If the

processing time 1 is specified, only a NAST record is created for now. The

program RSNAST00 must be planned as a background job or be started manually.

In the program RSNAST00, the master IDoc is transferred as the data section of

the communications IDoc, and a control record and a status record are added to

it. The communication IDoc is then saved on the database and, depending on the

settings in the partner profiles, sent immediately or later.

ALE Scenario: Stock Transfer Between Two Systems

In SAP R/3 or SAP ECC systems, you will find support for the configuration of an

ALE scenario “Stock transfer between two systems”. You can use this scenario

if sales branches or production sites are separated from one another or from the

central warehouse or the central Sales and Distribution not only physically, but

also in terms of the systems involved.





Figure 77: Scenario: Stock Transfer Between Two Systems

With this scenario, you can represent the following basic process: The branch

orders goods from head office. The incoming purchase order in IDoc format

(message type ORDERS) is automatically converted into a sales order by

the receiving system. The logical system of head office also automatically

sends an order confirmation (message type ORDRSP) to the branch. The

inbound processing of the order confirmation is updated in the purchase

order: The purchasing area agent usually sees the document number of thesales order of head office on the document item level of his purchase order.

At head office, if the goods are available, a delivery is created for the sales order.

The message control can be used to automatically send a shipping notification in

IDoc format for this delivery (message type DESADV) to the branch. Depending

on the settings in the system of the branch, an inbound delivery - an additional

SAP document - is created there during the IDoc inbound processing, or else a

corresponding note is entered in the purchase order. After the goods are shipped to

the branch, the head office can also transfer the invoice electronically (message

type INVOIC). If the inbound processing of the IDoc at the branch is successful,

an incoming invoice is automatically posted.





Exercise 6: Sending a Purchase Order to

a Vendor Exercise Objectives


• Send a purchase order in IDoc format to an external vendor

Business Example

The central purchasing department of the company orders goods from a vendor by

means of an EDI connection.

Task:

Create a purchase order to an external vendor in the system at company

headquarters and check whether an IDoc was generated with the data of this

purchase order.

1. In the CORE system, create a purchase order at the vendor T-K515D## for

100 pcs. of the material T-M15A## for the plant 1000. You work for the

purchasing organization 1000 and the purchasing group 001 in the company

code 1000. Which message type is found, and how is the message to be

processed?

Message type: _______ Transmission medium: _______

2. Check the outbound processing of the IDoc in the purchase order. What

status does the IDoc have? Also note the IDoc number.

Status: ____

Number: ________________

3. Display your IDoc in the status monitor as well and send it. What status does

the IDoc have now? What is the text for this status?

Hint: You will find the text under the heading Error text .





Solution 6: Sending a Purchase Order to

a Vendor Task:

Create a purchase order to an external vendor in the system at company

headquarters and check whether an IDoc was generated with the data of this

purchase order.

1. In the CORE system, create a purchase order at the vendor T-K515D## for

100 pcs. of the material T-M15A## for the plant 1000. You work for the

purchasing organization 1000 and the purchasing group 001 in the company

code 1000. Which message type is found, and how is the message to be

processed?

Message type: _______

Transmission medium: _______

a) Choose Logistics! Materials Management ! Purchasing !

Purchase Order ! Create! Vendor/Supplying Plant Known.

b) Enter the vendor T-K515D## and confirm your entry with Enter .

c) On the Org.data tab page, enter the purchasing organization 1000, the

purchasing group 001 and the company code 1000.

d) Choose Item overview , enter the material T-M15A##, the order

quantity 100 and the plant 1000 and confirm these entries with Enter .

e) Choose the Output button: The output type NEU was found. The

message is to be output by means of EDI (transmission medium 6).

f) Create the purchase order by saving.

2. Check the outbound processing of the IDoc in the purchase order. What

status does the IDoc have? Also note the IDoc number.

Status: ____






Number: ________________


Purchase Order ! Display.

b) Choose the Messages button: The message should have the status

Successfully processed . Choose Back .

c) In the menu, choose System! Services for Object and then Display

links : The number of the outbound IDoc is displayed.

d) Double-click the number of the IDoc to call it up for display. It has the

status 30 ( IDoc is ready to be sent ).

3. Display your IDoc in the status monitor as well and send it. What status does

the IDoc have now? What is the text for this status?

Hint: You will find the text under the heading Error text .

a) Choose Tools! ALE ! ALE Administration! Monitoring ! IDoc


b) Enter the number from step 2 in the field IDoc number and choose

Execute .

c) Select the row under the output type ORDERS and choose the Process

button.

d) Confirm the message on your selection with Enter : The IDoc nowhas the status 03 ( Data passed to port OK ). The “error text” is: IDoc

written to file. You can also find out the file path using the Error long

text button.





Exercise 7: Optional: ALE Scenario

“Stock Transfer Between DistributedSystems”

Exercise Objectives


• Create a sales order from a purchase order using ALE

Business Example

Sales and Distribution regularly orders stock replenishments at head office for

processing its customer orders; head office is where the main warehouse of thecompany is located. These purchase orders are sent to head office using ALE and

are automatically converted into sales orders there.

Task:

Create a purchase order with head office in the Sales and Distribution system,

check the results of the message determination, and then display the automatically

created order in the head office system. Also check the updating of the purchase

order after the order confirmation is received.

1. In the SALES system, create a purchase order of the document type NB

(normal order ) at the vendor CORE for 100 pcs. of the material DPC1002.You are ordering with the authorization of the purchasing organization 1000

for the plant 1000. You belong to the purchasing group 001. The responsible

company code is 1000. Check the results of the message determination:

Which message type was found? Which transmission medium is used? Make

a note of the document number of the purchase order.

Message type: ________

Transmission medium: ______

Number of the purchase order: _________________

2. Display the outbound IDoc in the status monitor of the SALES sender

system. Search for the IDoc using the business object type PurchaseOrder

and your document number from step 1. Check the content of individual

segments and compare them with your purchase order.

3. In the CORE system, check whether a sales order was created for the

purchase order of the SALES system. Use your purchase order number

from step 1 as the search criterion. Make a note of the document number of

the order: ______________






4. Was an order confirmation also created in the CORE system and sent to the

SALES system? Check the results of the message determination in the order.

5. In the CORE system, you now display the outbound IDoc for the order

confirmation using the object services in the order. Then check the purchase

order in the SALES system: What has changed?

Hint: In the purchase order, check the Confirmations tab page on

the document item level.





Solution 7: Optional: ALE Scenario “Stock

Transfer Between Distributed Systems”Task:

Create a purchase order with head office in the Sales and Distribution system,

check the results of the message determination, and then display the automatically

created order in the head office system. Also check the updating of the purchase

order after the order confirmation is received.

1. In the SALES system, create a purchase order of the document type NB

(normal order ) at the vendor CORE for 100 pcs. of the material DPC1002.

You are ordering with the authorization of the purchasing organization 1000

for the plant 1000. You belong to the purchasing group 001. The responsible

company code is 1000. Check the results of the message determination:

Which message type was found? Which transmission medium is used? Make

a note of the document number of the purchase order.

Message type: ________

Transmission medium: ______

Number of the purchase order: _________________


Purchase Order ! Create! Vendor/Supplying Plant Known.

b) Enter the vendor CORE, and on the Org.data tab page, on the documentheader level, enter the purchasing organization 1000, the purchasing

group 001 and the company code 1000.

Hint: If the document levels (header or item) are not visible,

choose Header or Item overview .

c) On the document item level, enter the material DPC1002, the order

quantity 100 and the plant 1000. Confirm your entries with Enter .

d) Choose the Output button: The output type NEU was found. The

transmission medium is A. Create the purchase order by saving.






2. Display the outbound IDoc in the status monitor of the SALES sender

system. Search for the IDoc using the business object type PurchaseOrder

and your document number from step 1. Check the content of individualsegments and compare them with your purchase order.



b) In the field Business object , enter PurchaseOrder, and in the field

Object key enter the purchase order number from step 1, then choose

Execute .

c) An IDoc for the message type ORDERS should be found under

Outbound IDocs. Select the entry underneath the message type and

choose the Display IDocs button.

d) Select the IDoc and choose the Display IDocs button again. Open the

Data records folder to display the segments of the IDoc.

3. In the CORE system, check whether a sales order was created for the

purchase order of the SALES system. Use your purchase order number

from step 1 as the search criterion. Make a note of the document number of

the order: ______________

a) Choose Logistics! Sales and Distribution! Sales! Order !

Change.

b) In the Search criteria area, enter your purchase order number from step

1 in the corresponding field and choose Perform search.c) Select the search result and accept it with Enter : You now enter the

overview screen of the order that was created from the data of the

purchase order.

4. Was an order confirmation also created in the CORE system and sent to the

SALES system? Check the results of the message determination in the order.

a) In the menu of the order, select Extras! Output ! Header ! Edit .

b) The system found the output type BA00 (Order Acknowl.) and

immediately processed it into an IDoc when creating the order.






5. In the CORE system, you now display the outbound IDoc for the order

confirmation using the object services in the order. Then check the purchase

order in the SALES system: What has changed?

Hint: In the purchase order, check the Confirmations tab page on

the document item level.

a) Choose System! Services for Object and then choose Display links .

b) Double-click the number of the outbound IDoc of the message type

ORDRSP to call up the IDoc for display.

c) In the system SALES, choose Logistics! Materials Management !

Purchasing ! Purchase Order ! Display.

d) Select the tab page Confirmations on the document item level: In the

Order confirmation field you will see the document number of the sales

order from the CORE system.





Lesson Summary

You should now be able to:• Create a purchase order and check the events of your message determination






BIT300 Unit Summary

Unit Summary





• Create a purchase order and check the events of your message determination






Unit Summary BIT300




Unit 4 Distributing Transaction Data: BAPIs

Unit Overview

This unit explains how transaction data in a system landscape can be distributed

in ALE using preconfigured interfaces to business object types, the Business

Application Programming Interfaces (BAPIs).

Unit Objectives


• Explain the terms “business object type” and “BAPI”

• Determine business object types and BAPIs using the BAPI Explorer, and

also determine detailed information on BAPIs

• Enter Customizing settings for synchronous BAPI calls

• Enter Customizing settings for asynchronous BAPI calls using the ALE

interface

• To describe the configuration of the ALE scenario “Transferring the

accounting results of the travel expenses to Accounting”.

Unit Contents

Lesson: Business Object Types and BAPIs. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..138Lesson: The Usage of BAPIs in ALE.. ... .. ... .. ... ... .. ... ... .. .. ... .. ... ... 145

Lesson: Example: Travel Expenses... ... .. ... ... .. ... .. ... ... .. .. ... .. ... ... 155Exercise 8: Trip Cost Accounting with Two Systems ..................161

Exercise 9: ALE Scenario for Setting Up Travel Expenses .. . . . .. . .. .165


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 4: Distributing Transaction Data: BAPIs BIT300

Lesson: Business Object Types and BAPIs

Lesson Overview

This lesson introduces business object types and BAPIs. You will find out how

to search for and find BAPIs, and how to recognise whether an asynchronous

ALE interface exists for a BAPI.

Lesson Objectives





Business Example

You want to set up a business process in a distributed system landscape. For this

purpose, you look for corresponding inbound interfaces in receiving systems and

check whether these interfaces have been used in a pre-defined ALE scenario.

What is a Business Object Type?

Integration scenarios are important for the design phase of distributed business

processes. For the technical integration, it is necessary to have a more in-depthunderstanding of the underlying technology (business objects and options for

accessing business objects).




BIT300 Lesson: Business Object Types and BAPIs

Figure 78: Business Object Type - Definition

The business object types are an important part of the Internet Business Framework

and are prerequisites for interoperability. Business object types cover a wide

spectrum of SAP business data and processes, and they can be used by means of

standardized methods - the BAPIs. The business object types and their BAPIs thus

provide an object-oriented view of the business functions in SAP systems.

Figure 79: Business Object Type - Representation

To achieve this encapsulation, business object types are created as entities with

different layers: At the center of the business object type is the kernel, which

represents the inherent data of the object.





The second layer, the integrity layer, represents the business logic of the object. It

comprises of the business rules for the consistent embedding in the environment

and the constraints with regard to the values and areas relating to the businessobject type.

The third layer, the interface layer, describes the implementation and structure of

the business object type, and defines the object's interface to the outside world.

The fourth and outermost layer of a business object type is the access layer. This

layer defines the technologies that can be used for external access to the data of the

object type - for example, COM/DCOM (Component Object Model/Distributed

Component Object Model).

Figure 80: Examples of SAP Business Object Types

Every individual business object belongs to a specific business object type,

depending on its properties. For example, all the employees of a company belong

to the business object type “employee”. An employee with the employee number

4711 is an instance of the business object type “employee” and is designated

a business object.





Figure 81: Business Object Repository (BOR)

All the business object types and their methods are defined in the Business Object

Repository (BOR) within SAP systems. The BOR was first introduced in SAP R/3

3.0, at the same time as the introduction of the business object types and the SAP

Workflow. In SAP R/3 3.0, the BOR was mainly used by the SAP Workflow.

The BOR contains two categories of object types:

• Business object types

These are the business object types already discussed. In the BOR,

the business object types are hierarchically assigned to the application

components, such as Sales and Distribution and Materials Management.

• Technical object types

These are elements such as texts, work items, archived documents, as well as

development and modeling objects.

With the introduction of the BAPIs in SAP R/3 3.1, the importance of BOR

increased. It is now the central point of access to the business object types and

their BAPIs in SAP systems for external applications.

What is a BAPI?

External applications can access business objects in SAP systems through

standardized, platform-independent interfaces - BAPIs. The business object types

and their BAPIs provide an object-oriented view of the business processes and

data in an SAP System.





Figure 82: Interfaces of Business Object Types

A BAPI is a standard interface that provides access to the business data and

business processes of business object types in SAP systems.

For example, the functions that are implemented with the business object type

“material” include a check for the material's availability. Therefore, the business

object type “material” has a BAPI with the name “Material.CheckAvailability”.

Figure 83: How is a BAPI implemented in an SAP system?

You can use the BAPI Explorer to obtain information on business object types

and their related BAPIs. In the application menu, choose Tools! Business

Framework ! BAPI Explorer or call the transaction BAPI directly.





Figure 84: BAPI Explorer

The display of the BAPI Explorer is divided into a hierarchy area and a detail

window. The component hierarchy is displayed in the hierarchy area. You can

open the folders of the application components and obtain the business object

types belonging to each respective component. If you open the directory of a

business object type, you see a subtree with its key attributes and its API methods.

(API stands for Application Programming Interface.)





Lesson Summary

You should now be able to:• Explain the terms “business object type” and “BAPI”






BIT300 Lesson: The Usage of BAPIs in ALE

Lesson: The Usage of BAPIs in ALE

Lesson Overview

This lesson shows how BAPIs can be used in an ALE scenario to realize

synchronous checks and queries and asynchronous data exchanges.

Lesson Objectives




interface

Business Example

You want to configure an ALE scenario in which the transaction data is distributed

using BAPIs.

Synchronous Communication with BAPIs

Since SAP R/3 4.6, BAPIs are realized as function modules. You can use the

BAPI Explorer to navigate to the display of the function module for the selected

BAPI in the “Function Builder”:

Figure 85: BAPI Function Modules

BAPIs can be used for the synchronous communication between two systems.





Figure 86: Synchronous call of a BAPI

For the synchronous call of a BAPI within an ALE scenario, the following steps

must be realized in the application program:

1. Querying the distribution model:

The application program determines the receiver and, if applicable, filter

values for filter objects from the distribution model. If the BAPI is not

contained in the distribution model, it is usually called up locally.

2. Determination of the RFC destination:

If the logical system in which the BAPI is to be called is known, the

application program of the calling system determines the RFC destination for

this remote system from a table, which you can find by using the transaction

BD97 or in the IMG in the Customizing of the ALE (transaction SALE) by

means of the path IDoc Interface / Application Link Enabling (ALE) !

Communication! Determine RFC Destinations for Method Calls.

3. Calling up the BAPI function module using RFC:

The calling system transfers the application data by means of RFC by callingup the BAPI function module in the target system.





Figure 87: RFC Destinations for Synchronous Method Calls

You can use the transaction BD97 to assign a standard destinationfor BAPIs to a target system. All BAPI calls for which no specific

destination has been entered use this destination. The RFC user for the

standard destination must have the appropriate application authorizations.

You can also maintain a destination for each method call for every target system.

In this case, you can assign the authorizations of the RFC user more precisely.

In the distribution model, you can add BAPIs to the individual model views using

the Add BAPIs button.

Figure 88: Distribution Model: Adding BAPIs

Along with the sending and receiving systems, you enter in the model view the

name of the business object type involved and the desired method, that is, theBAPI. In the fields Business object type and Method you enter the name from the

BAPI Explorer and not the technical names of the business object types from

the “Business Object Builder”.





Asynchronous Communication with BAPIs

Figure 89: Asynchronous Call of a BAPI in the Target System

In order to call a BAPI asynchronously in the target system, an IDoc is sent to thetarget system. This contains the interface parameters of the BAPI, and in the case

of instance methods, the key fields of the business object. In the target system, the

BAPI function module is called locally with the parameters from the IDoc.

Figure 90: ALE Interface of a BAPI

You go to the display of the ALE interface of a BAPI by clicking on the ALE

message type in the detail view of of the BAPI Explorer. In this way you call the

transaction BDBG, with which you can display the existing ALE interfaces of

BAPIs, but can also generate new interfaces.

In the transaction BDBG, you select the Display interface button to display the

automatically generated elements of the ALE interface of a BAPI.





Figure 91: ALE Interface of a BAPI

The following elements are part of the generated ALE interface of a BAPI:

• Message type:

Message types of the ALE interface of BAPIs are not directly assigned to

a model view. They are used exclusively in the partner profiles between

sending and receiving systems. The BAPIs themselves are assigned in the

distribution model (see above).

• IDoc type: The IDoc type is the basis of the IDoc required for theasynchronous communication with BAPIs.

• Segment types: The elementary import parameters are grouped together

in a segment type. A segment type is created for every structured import

parameter.

• Function module for ALE output: In the outbound function module, the

interface parameters are copied into the IDoc segments and a master IDoc is

created. Then a function module is called that transfers this master IDoc to

the ALE layer.

• Function module for ALE input: The inbound function module copies the

contents of the segment fields onto the related interface parameters and calls

the BAPI function module locally in the target system.





Figure 92: Outbound Processing of an IDoc for a BAPI Call

The following steps are carried out in the application program:

1. After the application data is determined, the receiving system and any filter

values for filter objects from the distribution model of the sending system

are determined.

2. Subsequently, the generated outbound function module of the ALE interface

of the BAPI is called. This module creates the master IDoc and transfers

it to the ALE layer.

The communication IDoc is created in the same way as in the non-BAPI-based

ALE scenarios: For the message type of the BAPI, there must be partner profiles

with the recipient system in which the generated IDoc basic type of the ALE

scenario of the BAPI, and a suitable RFC port, are assigned.





Figure 93: Sending the Communication IDoc

The communication IDoc is sent by means of RFC immediately or later, depending

on the specifications in the partner profiles with the receiving system.

Figure 94: Inbound Processing of an IDoc for a BAPI Call





In the receiving system, the IDoc is stored on the database. Depending on the

setting in the partner profiles, it is either transferred to the application immediately,

or processed later as by the program RBDAPP01 as a background job.

By means of the BAPI process code in the partner profiles, the ALE detects learns

that the input function module of the ALE interface generated for the BAPI is to

be called. The inbound function module copies the contents of the segment fields

of the IDoc onto the BAPI interface parameters and then calls the BAPI function

module locally.

Figure 95: Outbound Partner Profile in the Sending System

If possible, generate the partner profiles of BAPI-based ALE scenarios from the

distribution model. The system then enters the message type and IDoc type

relevant to the BAPI.





Figure 96: Inbound Partner Profile in the Receiving System

Also generate the partner profile in the receiving system from the distribution

model: The system assigns the process code BAPI.





Lesson Summary

You should now be able to:• Enter Customizing settings for synchronous BAPI calls


interface




BIT300 Lesson: Example: Travel Expenses

Lesson: Example: Travel Expenses

Lesson Overview

This lesson explains the configuration of the ALE scenario “Transferring the

accounting results of the travel expenses to Accounting”. This scenario uses

BAPIs for both the synchronous and the asynchronous communication.

Lesson Objectives




Business Example

Your company has moved the human resources to its own system. The employees

enter the costs for their business trips in the Travel Management of this system. In

the future, the results of the travel expenses are to be transferred to the Accounting

system using ALE.

Travel Expenses: Process

The Travel Management is part of the mySAP ERP Financials application, but

it also affects human resources. For this reason, you will find the application

transactions for using the functions of Travel Management in the reporting menus

of both applications.

It is not absolutely necessary to systematically separate the Travel Management

from the other applications of Accounting. However, it is not infrequently

assigned to the separately operated system for human resources (in the example

HR_TRAVEL). If the systems are thus separated, then the results of the travel

expenses must be transferred to the Accounting system (in the example: CORE)

for posting and for the subsequent payout of reimbursement amounts. In SAP

R/3 and SAP EEC, you are provided with the pre-configured ALE scenario

“Transferring the accounting results of the travel expenses to Accounting” for

this process.





Figure 97: Travel Expenses: Posting Procedure

The figure illustrates the posting procedure of the process. It comprises the

following individual steps:

• Entering the trip costs: In the Travel Management, the employee entersthe details (start and end of trip, destination, expenses for accommodation,

transport, and so on) of his business trip (“Create trip”).

• Authorization of trip: The supervisor or personnel department employee

authorizes the reimbursement of costs (“Authorize trip”).

• Accounting of trip: The personnel department gets the system to calculate

the reimbursement amounts. Among other things, this step takes into account

the daily rates for calculating expenses stored in the system (“Settle trip”).

• Creating the posting run: When creating what is known as the posting

run, the trip cost management system performs synchronous BAPI calls.

In this way it checks, among other things, whether the accounts on which

the postings are to be made, the account assignment objects of Controllingdetermined in the travel expenses, and the vendor master records required

for the reimbursement of expenses, exist in the Accounting system for the

personnel numbers of the employees on the trip.

• Checking the posting run: In order to ensure that postings are allowed to

be made on the accounts and account assignment objects of Accounting

at the time of the actual settlement data transfer, the Travel Management

system can perform additional synchronous BAPI calls.





• Posting the posting run: Finally, the Travel Management system transfers

the results of the settlement to the Accounting system. The BAPIs used

by the system in this step are called asynchronously, in the course of IDoc

inbound processing.

Note: A posting run is a kind of “container” for the documents in which

the the results of the travel expenses are kept. Every posting run is given a

unique, sequential number by the system.

Required Presettings

For the ALE scenario “Transferring the accounting results of the travel expenses

to Accounting” to function, a necessary prerequisite is the advance distribution of the master data required in both systems (personnel master data, cost centers). In

addition, the Customizing in the areas involved must be synchronized.

Figure 98: Master Data Distribution

You will find more detailed information on these settings in IMG through

transaction SALE. Then choose IDoc Interface / Application Link Enabling (ALE)

! Modelling and Implementing Business Processes! Configure Predefined ALE

Business Processes! Human Resources! HR <-> AC ! Set Up Trip Costs

Transfer to FI .





Details of the Posting Run for the Travel Expenses

To be able to create a posting run in the system of the Travel Management, you

transfer the relevant BAPIs (see figure below) into a corresponding view of the

distribution model in the maintenance system and assign the target system of these

synchronous method calls an RFC destination using the transaction BD97.

Figure 99: Model View: Creating a Posting Run

To check a posting run, you also transfer the relevant BAPIs into a view of the

distribution model and assign the target system of the synchronous method call an

RFC destination using the transaction BD97.





Figure 100: Model View: Checking a Posting Run

To post a posting run in the Accounting system, you transfer the relevant BAPIs

into a view of the distribution model and generate the partner profiles for the IDoc

generation in the sending and receiving systems.

Figure 101: Model View: Posting a Posting Run





When you display the trip transfer documents in the Travel Management system

after transferring the posting run to the Accounting system, a traffic light will tell

you whether the data transfer was successful.





Exercise 8: Trip Cost Accounting with Two

SystemsExercise Objectives


• Transfer trip costs from the Human Resources system to the Accounting

system within the SAP Travel Management

Business Example

Your company has moved the human resources to its own system. Business trips

are recorded in the SAP Travel Management of this system and subsequently

transferred to the Accounting system for reimbursement purposes.

Task:

In the logical system HR_TRAVEL, enter the data of a business trip, settle this

business trip, and transfer the settlement data to the logical system CORE for

posting in Accounting.

Caution: When the trip costs are being transferred to Accounting,

the system checks that the receiver is unique. Therefore, a test run is

performed with the model view that the instructor created. Exercise 2,

in which you create a new view in the distribution model with all theBAPIs required for the ALE scenario, must therefore be performed after

this exercise.

1. In the HR_TRAVEL system, create a new trip for the employee with the

personnel number 60995##. Enter the costs for accommodation and taxis.

The trip was in the previous week and took two days. Write down the

number of the trip: ___________

2. Approve the reimbursement of the trip costs you have just entered and then

perform the settlement. Write down the settlement period: ___________

3. Create a posting run with the data for your trip.

4. Now transfer the settlement results to Accounting in the logical system

CORE.

5. Then display the inbound IDoc in the status monitor of the logical system

CORE. You can also directly access your IDoc using the transaction IDoc

Search for Contents (transaction code WE09). Using the IDoc basic type

ACC_EMPLOYEE_PAY01, select the segment E1BPACHE06, segment

field USERNAME, and enter your user BIT300-## as an additional search

criteria.





Solution 8: Trip Cost Accounting with Two

SystemsTask:

In the logical system HR_TRAVEL, enter the data of a business trip, settle this

business trip, and transfer the settlement data to the logical system CORE for

posting in Accounting.

Caution: When the trip costs are being transferred to Accounting,

the system checks that the receiver is unique. Therefore, a test run is

performed with the model view that the instructor created. Exercise 2,

in which you create a new view in the distribution model with all the

BAPIs required for the ALE scenario, must therefore be performed after

this exercise.

1. In the HR_TRAVEL system, create a new trip for the employee with the

personnel number 60995##. Enter the costs for accommodation and taxis.

The trip was in the previous week and took two days. Write down the

number of the trip: ___________

a) Choose Human Resources! Travel Management ! Travel Expenses

! Travel Expense Manager .

b) Enter the personnel number 60995## and confirm the entry with

Enter .c) Choose Create to call up the screen for entering the trip costs.

d) Enter a date in each of the fields Start and Finish. Next, in the

ExpTy field, enter HOTL and in the Amount field the total cost of the

accommodation. Confirm these entries with Enter .

e) In the Description field, enter a text of your choice and select Enter

again to leave the detail screen.

f) Next, in the ExpTy field, enter TAXI and in the Amount an amount

of your choice. Create the trip by saving and make a note of the trip

number.

2. Approve the reimbursement of the trip costs you have just entered and then

perform the settlement. Write down the settlement period: ___________

a) Select your trip from step 1 and choose the Approve button.

b) Then choose the Settle button. Confirm the default for the settlement

period and make a note of the period.






3. Create a posting run with the data for your trip.


! Periodic Processing ! Transfer to Accounting ! Create Posting

Run.

b) Enter the payroll area D2, choose Other period and enter the period

from step 2. Also enter the personnel number 60995## and the

number of the trip from step 1 and choose Execute .

c) If the synchronous check of the accounts, account assignment objects

and HR payee assignment for the personnel number was successful,

you will see a green traffic light for the number of the posting run.

Leave the transaction.

4. Now transfer the settlement results to Accounting in the logical system

CORE.


! Periodic Processing ! Transfer to Accounting ! Manage Posting

Runs.

b) Select Execute to display your posting run from step 3.

c) Select your posting run and choose the Post button. Answer the query

on the processing time by choosing the Post immediately button: If the

transfer was successful, you will see a green traffic light with the text

Posting run completely transferred to target system CORE .

5. Then display the inbound IDoc in the status monitor of the logical systemCORE. You can also directly access your IDoc using the transaction IDoc

Search for Contents (transaction code WE09). Using the IDoc basic type

ACC_EMPLOYEE_PAY01, select the segment E1BPACHE06, segment

field USERNAME, and enter your user BIT300-## as an additional search

criteria.

a) In the CORE system, choose Tools! ALE ! ALE Administration

! Monitoring ! IDoc Display! Status Monitor to call the status

monitor, or Tools! ALE ! ALE Administration! Services! IDoc

Search for Contents to go to transaction WE09.

b) In the field Basic type enter ACC_EMPLOYEE_PAY01, in the fieldSearch in segment enter E1BPACHE06, in the field Search in field enter

USERNAME and in the field For value enter your user BIT300-##

and choose Execute .

c) Click on the number of the IDoc to display the details.





Exercise 9: ALE Scenario for Setting Up

Travel ExpensesExercise Objectives


• Determine BAPIs using the BAPI Explorer

• Check the ALE interface belonging to a BAPI

• Set up an ALE scenario with BAPIs

Business Example

Your company has moved the human resources to its own system. Business tripsare recorded in the SAP Travel Management of this system and subsequently

transferred to the Accounting system for reimbursement purposes.

Task 1:

In the IMG documentation, search for the description of the ALE scenario

“Transferring the accounting results of the travel expenses to Accounting” and

make a note of the BAPIs required for this scenario.

1. In the IMG documentation, search for the description of the ALE scenario

“Transferring the accounting results of the travel expenses to Accounting”.

2. Which BAPIs are involved in the transfer of the trip costs to Accounting?

Make a note of the BAPIs for the business object types used for the steps

“Create posting run”, “Check posting run” and “Post posting run”.

Business object type Method (BAPI)

AcctngServices

Vendor

Customer

AcctngEmplyeePaybles

AcctngEmplyeeRcvbles

AcctngEmplyeeExpnses






3. In the BAPI Explorer, check for which of the BAPIs entered in the above

table there is an ALE interface. Note the names of the assigned message

types.

BAPI Message type

Task 2:

In the logical system CORE, define a new logical system CORE## and then

create a model view with this logical system as the target system of the methodcalls determined in the first task.

Hint: To be able to perform this exercise with different exercise groups,

we have to use a little trick: All the groups are to set up the distribution

between the systems HR_TRAVEL and CORE. However, just like

message types, BAPIs may only appear in one view of the distribution

model in the relationship between two logical systems. For this reason,

you use the logical system CORE## as the target system, but you enter a

port to which an RFC destination of the system CORE is assigned.

1. In the logical system CORE, you define the logical system CORE##, butyou do not assign it to any client.

2. Is this logical system name now known in the logical system HR_TRAVEL?

If applicable, also create CORE## in HR_TRAVEL.

3. In the distribution model of the system CORE, create a new view withthe short text BIT300BAPI## and the technical name BAPI##. Add the

BAPIs that you determined in the first task. The sender is the system

HR_TRAVEL, and the receiver the system CORE##.






Task 3:

Distribute the new model view to the system HR_TRAVEL and there you create

the corresponding partner profiles. You also add an RFC destination to the system

CORE## for synchronous method calls.

1. Distribute the new model view to the logical system HR_TRAVEL and

check the result.

Caution: Do not distribute the view to the logical system CORE##,

because this logical system is not assigned to a client.

2. In the logical system HR_TRAVEL, create outbound partner profiles with

the partner CORE## for the message type SYNCH. The receiving port is

CORE with the RFC destination of the same name.

3. In the logical system HR_TRAVEL, you now generate the outbound partner

profiles with the system CORE## for the three asynchronous method calls,

or you create them manually.

4. In the logical system CORE, check the inbound partner profiles with the

logical system HR_TRAVEL for the message types for asynchronous

communication. Which process code is assigned? Why do you not need any

separate inbound partner profiles for the logical system CORE##?

5. In the HR_TRAVEL system, which RFC destination do you have to assign

to the logical system CORE## for synchronous method calls? Add the

corresponding entry.





Solution 9: ALE Scenario for Setting Up

Travel ExpensesTask 1:

In the IMG documentation, search for the description of the ALE scenario

“Transferring the accounting results of the travel expenses to Accounting” and

make a note of the BAPIs required for this scenario.

1. In the IMG documentation, search for the description of the ALE scenario

“Transferring the accounting results of the travel expenses to Accounting”.

a) Call the transaction SALE and choose IDoc Interface / Application Link

Enabling (ALE)! Modelling and Implementing Business Processes!

Configure Predefined ALE Business Processes! Human Resources! HR <-> AC ! Set Up Trip Costs Transfer to FI ! Travel Management

and Accounting are Release 4.5A or Later .

b) Choose Documentation for IMG activity .

2. Which BAPIs are involved in the transfer of the trip costs to Accounting?

Make a note of the BAPIs for the business object types used for the steps

“Create posting run”, “Check posting run” and “Post posting run”.

Business object type Method (BAPI)

AcctngServices PreCheckPayrollAccountAssign

Vendor Find

Customer Find

AcctngEmplyeePaybles Check

Post

AcctngEmplyeeRcvbles Check

Post

AcctngEmplyeeExpnses Check

Post

3. In the BAPI Explorer, check for which of the BAPIs entered in the above

table there is an ALE interface. Note the names of the assigned message

types.






BAPI Message type

AcctngEm plyeeExpnses.Post ACC_EMPLOYEE _EXP

AcctngEm plyeePaybles.Post ACC_EMPLOYEE _PAY

AcctngEm plyeeRcvbles.Post ACC_EMPLOYEE _REC

a) Choose Tools! Business Framework ! BAPI Explorer .

b) Select the tab page Alphabetical and expand each of the

entries for the business object types AcctngEmplyeeExpnses,

AcctngEmplyeePaybles and AcctngEmplyeeRcvbles.

c) Select each respective entry for the method Post: You will find the

message type on the tab page Detail in the field ALE message type.

Task 2:

In the logical system CORE, define a new logical system CORE## and then

create a model view with this logical system as the target system of the method

calls determined in the first task.

Hint: To be able to perform this exercise with different exercise groups,

we have to use a little trick: All the groups are to set up the distribution

between the systems HR_TRAVEL and CORE. However, just like

message types, BAPIs may only appear in one view of the distribution

model in the relationship between two logical systems. For this reason,you use the logical system CORE## as the target system, but you enter a

port to which an RFC destination of the system CORE is assigned.

1. In the logical system CORE, you define the logical system CORE##, but

you do not assign it to any client.


Enabling (ALE)! Basic Settings! Logical Systems! Define Logical

System. Confirm the message about client independence with Enter .

b) Choose the New entries button, enter the logical system name CORE##

and a name of your choice and save your entry.

c) In the screen prompting the workbench request, choose Create Request

, enter a short description of your choice and choose Save . Then

choose Continue or Enter and leave the table.






2. Is this logical system name now known in the logical system HR_TRAVEL?

If applicable, also create CORE## in HR_TRAVEL.

Answer: This depends on whether you are working with one or more SAP

systems in the course.

• If you are using clients in two SAP systems: The logical system name

CORE## must also be defined in the logical system HR_TRAVEL.

• If you are only using clients of one SAP system: The logical system

name CORE## is already known in the system HR_TRAVEL, because

the logical system names are saved in a cross-client table.

3. In the distribution model of the system CORE, create a new view with

the short text BIT300BAPI## and the technical name BAPI##. Add the

BAPIs that you determined in the first task. The sender is the system

HR_TRAVEL, and the receiver the system CORE##.



Maintain Distribution Model and Distribute Views.

b) Switch to the change mode (Switching between display and edit modes

) and choose the Create model view button.

c) Enter the short text BIT300BAPI## and the technical name BAPI##

and choose Enter .

d) Select the view and choose the Add BAPI button.

e) Enter the sender HR_TRAVEL, the receiver CORE##, the object name

AcctngEmplyeeExpnses and the method Check, and confirm

your entries with Enter .

f) In this way, you add the remaining BAPIs that you require for the ALE

scenario. Create the new model view by saving.

Task 3:

Distribute the new model view to the system HR_TRAVEL and there you create

the corresponding partner profiles. You also add an RFC destination to the system

CORE## for synchronous method calls.

1. Distribute the new model view to the logical system HR_TRAVEL and

check the result.






Caution: Do not distribute the view to the logical system CORE##,

because this logical system is not assigned to a client.

a) In the distribution model of the system CORE, select the new model

view and choose Edit ! Model view! Distribute.

b) In the next screen, deselect the entry for the logical system CORE##

and confirm the change with Enter . You receive a log of the successful

distribution of the view to the system HR_TRAVEL.

c) In the system HR_TRAVEL, call the distribution model for display, as

described in task 2.

Hint: If your BAPI## view has not been distributed, thiscould be because the message type SYNCH does not exist

in the partner profiles of the system CORE with the system

HR_TRAVEL, or because the RFC destination does not lead

to the client of the system HR_TRAVEL.

2. In the logical system HR_TRAVEL, create outbound partner profiles with

the partner CORE## for the message type SYNCH. The receiving port is

CORE with the RFC destination of the same name.

a) In the system HR_TRAVEL, in the menu of the distribution model,

choose Environment ! Change Partner Profile.

b) Choose Create , enter the partner number CORE## and the partner

type LS and create the new partner by saving.

c) In the outbound parameter area, choose Create outbound parameter

, and in the message type SYNCH, enter the receiving port CORE and

the IDoc type SYNCHRON . Choose the immediate IDoc transfer and

save your changes. Leave the partner profile maintenance.






3. In the logical system HR_TRAVEL, you now generate the outbound partner

profiles with the system CORE## for the three asynchronous method calls,

or you create them manually.

a) Select your model view and in the menu of the distribution model,

choose Environment ! Generate Partner Profile.

b) Then choose Environment ! Change Partner Profile to check the

automatically created partner profiles.

c) To create the partner profiles manually, choose Environment ! Change

Partner Profile.

d) Select the partner CORE## and in the outbound parameter area, choose

Create Outbound Parameter .

e) Enter the message type ACC_EMPLOYEE_EXP, the port CORE andthe IDoc type ACC_EMPLOYEE_EXP01, select the immediate

processing, and create the partner profiles by saving. Proceed in

the same way with the message types ACC_EMPLOYEE_REC

and ACC_EMPLOYEE_PAY. The corresponding IDoc types are

ACC_EMPLOYEE_REC01 and ACC_EMPLOYEE_PAY01

respectively.

4. In the logical system CORE, check the inbound partner profiles with the

logical system HR_TRAVEL for the message types for asynchronous

communication. Which process code is assigned? Why do you not need any

separate inbound partner profiles for the logical system CORE##?

Answer: In the inbound partner profiles for the message types

ACC_EMPLOYEE_EXP, ACC_EMPLOYEE_PAY and

ACC_EMPLOYEE_REC, the process code BAPI is assigned.

Because the logical system CORE## is not assigned to any client, but rather

the system HR_TRAVEL actually calls the system CORE## on the basis of

the assignment of the receiving port CORE in the outbound partner profiles

with CORE##, no inbound partner profiles are required for CORE##.






5. In the HR_TRAVEL system, which RFC destination do you have to assign

to the logical system CORE## for synchronous method calls? Add the

corresponding entry.

a) Because the logical system name CORE## is not assigned to any

client, you must assign the RFC destination CORE to the logical

system of the same name.

b) Call the transaction SALE and choose IDoc Interface / Application Link

Enabling (ALE)! Communication! Determine RFC Destinations

for Method Calls.

c) In the menu of the transaction, choose Edit ! Find . In the Search for

field, enter your logical system CORE## and choose Find or Enter .

d) Click on the system name to return to the system overview at the position of the corresponding entry.

e) Select your logical system CORE## and choose the button Standard

Dest. for BAPIs. Enter the RFC destination CORE, choose Enter , and

save the change.





Lesson Summary

You should now be able to:• To describe the configuration of the ALE scenario “Transferring the





BIT300 Unit Summary

Unit Summary







interface






Unit Summary BIT300




Unit 5 Monitoring Data Distribution,Error-Handling and Archiving

Unit Overview

This unit handles various different tasks that arise from the implementation of

ALE and EDI scenarios. You will learn how to monitor the evolution of an IDoc,

how to correct errors and then how to archive IDocs that are no longer needed.

Unit Objectives


• Use the status monitor efficiently

• Set up and use the ALE audit

• Perform error analysis using the ALE status monitor

• Resolve errors in the IDoc processing

• Check workflow settings for the error handling of IDocs

• Understand the settings for process codes

• Describe the notification concept

• Monitor the IDoc processing using the SAP Workflow

• Describe the IDoc archiving procedure

• Set the archivable statuses in the system

Unit Contents

Lesson: IDoc Status Management . ... .. ... ... .. ... ... .. ... .. .. ... ... .. ... .. .179

Exercise 10: Monitoring IDocs in the Status Monitor .................. 185Exercise 11: ALE Audit .. .... ... .... .... .... ... .... .... .... .... .... .... ... .187

Lesson: Error Analysis and Handling ........................................190Procedure: Problem: The IDoc Was Not Created......................196Procedure: Problem: The IDoc was Created, but was not Sent ..... 199

Procedure: Problem: The IDoc was Successfully Sent, but it was not

Received by the Receiving System . .. .. ... .. .. ... .. ... ... .. .. ... ... .. ... 200Procedure: Problem: The IDoc was Received by the Receiving

System, but was not Posted ..............................................201


http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 5: Monitoring Data Distribution, Error-Handling and Archiving BIT300

Exercise 12: Error Analysis and Handling... .. .. .. .. .. .. .. .. .. .. .. .. .. ..203

Lesson: SAP Workflow in ALE Environment .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..212

Exercise 13: Processing an Incorrect IDoc from a Work Item. ... . . . .223Lesson: Archiving IDocs .. ... .... ... .... ... .... ... .... .... .... .... .... ... .... ..228


http://-/?-

http://-/?-

http://-/?-

http://-/?-



BIT300 Lesson: IDoc Status Management

Lesson: IDoc Status Management

Lesson Overview

This lesson provides you with more detailed information on the IDoc status

monitor. You also learn how the sender system uses the ALE audit to obtain

information about the further processing of IDocs in the receiving system.

Lesson Objectives




Business Example

You are using various ALE scenarios and have to monitor the data distribution.

Errors in the IDoc outbound and inbound processing should be detected early. You

are also looking for options to call information in the sender system about the

further processing of IDocs in the receiving system.

IDoc Status Management

The status monitor provides you with an overview of the outbound and inbound

IDocs from the perspective of the logical system by executing the transaction(transaction code BD87). From SAP R/3 4.6C on, the status monitor displays all

IDocs, even those that were processed correctly.

Because you usually do not want to display all the IDocs that have not been

archived yet at the same time, the status monitor provides you with various

selection criteria for displaying specific documents:

• IDoc numbers

• Creation date and time

• Change date and time

• IDoc status

• Partner systems

• Message types

• Business object types and object keys

The IDocs determined on the basis of the selection specifications are first grouped

in the status monitor in terms of direction (outbound or inbound). They are also

grouped into status groups. For example, all the outbound IDocs for a message

type that were successfully transferred to a tRFC port are grouped into status group

03. Each status value is assigned to a traffic light symbol. Successfully processed





IDocs are displayed with green traffic light symbols in the status monitor, not yet

(completely) processed IDocs with yellow traffic light symbols and incorrectly

processed IDocs with red traffic light symbols.

Figure 102: Status Groups

The assignment of a status to a traffic light symbol can be changed. To do this,

you call transaction WE47. Status values are grouped together into status groups.

The traffic light symbols are assigned to status groups in a table that you cancall using transaction WELI.

Note: In SAP R/3 4.7, you will find these transactions with the menu path

Tools! Business Communication! IDoc Basis! Control ! Status.

In SAP ECC 5.0, you call the transactions from the IMG (transaction

SALE) by choosing IDoc Interface / Application Link Enabling (ALE)!

System Monitoring ! Set IDoc Status Display! Process IDoc Status

Values or Process Status Groups.

In Settings! Hierarchy in the menu of the status monitor you can choose whether

to highlight the message type or the status value.

Displaying and Monitoring IDocs

Use the button Display IDocs to call a list of all the IDocs for a message type.





Figure 103: Displaying IDocs

By double-clicking on one of the IDoc numbers in this list you enter the display

of the document itself. Here you can check the control record, the data records

and the status records.

Under certain conditions, you can also call and display from the sender system an

IDoc in the receiver system. This function (“Monitor IDocs”) is also available in

the status monitor by pressing the corresponding button.

Figure 104: Monitoring IDocs





To use this function, the following preconditions must be fulfilled:

• In the outbound partner profiles with the respective receiving system, there

must be parameters for the message type SYNCH.

• The RFC user entered in the RFC destination which is assigned to the port

of the outbound partner profile for the message type SYNCH must have

the authorization “Execute” in the receiving system for the function group

BDMT for the authorization object S_RFC.

• In the sending system, an RFC destination for dialogs must be assigned to

the receiver system. You can make this assignment in the IMG by calling the

transaction SALE and choosing IDoc Interface / Application Link Enabling

(ALE)! Communication! Determine RFC Destinations for Method Calls.

• The RFC user must be a dialog user in the receiving system with the

corresponding authorizations for the authorization object S_IDOCMONI.

ALE Audit

The function “ALE Audit” provides the sending system with information about

the processing status of an IDoc in the receiving system.

Figure 105: ALE Audit: Model View

The receiving system uses the asynchronous IDoc interface in order to send

back status information to the sending system of an IDoc. The message type of

the confirmation is ALEAUD. The receiving system creates its own IDoc with

status information on IDocs that it received for certain message types within a

specific period. This audit confirmation is usually sent periodically by means of a

background job, but it can also be triggered directly from the status monitor.





Setting up the ALE Audit

1. Add the message type ALEAUD to all the relevant model views. The

receiving system of the IDocs, whose status values are to be transferred in

the audit, is the sending system for the message type ALEAUD.

2. If required, you can filter by message type. A corresponding filter object

exists. Enter as filter values all the message types for which you want

to create an audit message.

3. Distribute the changes message views again and generate the partner profiles

in all the systems involved.

4. Include the program RBDSTATE for sending the audit confirmations.

Figure 106: ALE Audit: Status Values





The status value of an outbound IDoc in the sending system after the successful

inbound processing of the confirmation IDoc for the message type ALEAUD,

depends on the status of the corresponding inbound IDoc in the receiving systemat the time of execution of the program RBDSTATE:

• If the inbound IDoc in the receiving system has the status 53 (application

document posted ), then the corresponding outbound IDoc in the sending

system gets the status 41 (application document created in target system).

• If the IDoc has reached the receiving system with the status 64 ( IDoc is ready

for transfer to the application) or 62 ( IDoc transferred to application), but

the data has not been posted in the application yet, then the corresponding

IDoc in the sending system is given the status 39 ( IDoc in target system).

Therefore, status 39 only means that the IDoc has reached the receiving

system. Status 39 does not tell you whether the IDoc still has status 64

because the program RBDAPP01 was not started yet, or whether an error

has occurred.

• If the IDoc was processed incorrectly in the receiving system, and if this

error cannot be corrected - for example, if the IDoc was sent to the wrong

receiving system - then the IDoc can be changed to status 68. In this case,

the status of the related IDoc in the sending system is set to status 40

(application document in target system not created ).

You will find the functions of the ALE Audit in the menu of the status monitor

through the path Goto! ALE Audit . You can send confirmations directly (by

starting the program RBDSTATE), create statistical evaluations, and delete audit

statistics that are no longer required.





Exercise 10: Monitoring IDocs in the

Status Monitor Exercise Objectives


• Use the status monitor to monitor IDocs in your receiving system

Business Example

You have set up various ALE scenarios in your system landscape. Now you want

to check whether the IDocs sent for test purposes have arrived in the respective

receiving systems without logging on to these receiving systems.

Task:

In the logical system CORE, display IDocs for the message type MATMAS

and check whether they have been processed successfully in the logical system

PRODUCTION. However, first check the assignment of an RFC destination for

dialogs to the logical system PRODUCTION.

1. In the CORE system, check whether the PRODUCTION system is assigned

an RFC destination for dialogs.

2. In the CORE system, call the status monitor and select the IDocs of the

message type MATMAS that have been created since the start of the course.Use the function “Monitor IDocs” to determine the status of these IDocs

in the receiving system PRODUCTION. Display one of the IDocs in the

PRODUCTION system.





Solution 10: Monitoring IDocs in the

Status Monitor Task:

In the logical system CORE, display IDocs for the message type MATMAS

and check whether they have been processed successfully in the logical system

PRODUCTION. However, first check the assignment of an RFC destination for

dialogs to the logical system PRODUCTION.

1. In the CORE system, check whether the PRODUCTION system is assigned

an RFC destination for dialogs.


Enabling (ALE)! Communication! Determine RFC Destinations for Method Calls.

b) In the menu of the transaction, choose Edit ! Find . In the Search for

field, enter the logical system PRODUCTION and choose Find or

Enter .

c) Click on the system name to return to the system overview at

the position of the corresponding entry: The logical system

PRODUCTION is assigned the RFC destination for dialogs of the

same name.

2. In the CORE system, call the status monitor and select the IDocs of the

message type MATMAS that have been created since the start of the course.Use the function “Monitor IDocs” to determine the status of these IDocs

in the receiving system PRODUCTION. Display one of the IDocs in the

PRODUCTION system.



b) Enter the message type MATMAS, the partner system PRODUCTION ,

and as the change date, the starting date of the course, and choose

Execute .

c) Select the entry (or one of the entries) underneath the message type and

choose the Monitor IDocs button.

d) Check the status of the IDoc(s): If the inbound processing was

successful, you will find the status 53 beside the IDoc number.

e) Double-click on the number of the inbound IDoc in the PRODUCTION

system: You enter the display of the IDoc in the receiving system.





Exercise 11: ALE Audit

Exercise Objectives


• Use the functions of the ALE Audit.

Business Example

You want to be able to detect by the status value of an ALE scenario in the sending

system whether the transfer of the data to the corresponding application in the

receiving system was successful, or whether errors occurred.

Task:Test the ALE Audit using your Message Type ZMATMAS##.

1. Send an IDoc with the status confirmations from the system PRODUCTION

to the system CORE. Only send confirmations for IDocs for your reduced

message type ZMATMAS##, namely, for all those created since the start of

the course.

2. Check the result of the confirmation in the status monitor of the CORE

system and display one of the IDocs involved.





Solution 11: ALE Audit

Task:

Test the ALE Audit using your Message Type ZMATMAS##.

1. Send an IDoc with the status confirmations from the system PRODUCTION

to the system CORE. Only send confirmations for IDocs for your reduced

message type ZMATMAS##, namely, for all those created since the start of

the course.

a) In the PRODUCTION system, choose Tools! ALE ! ALE

Administration! Monitoring ! IDoc Display! Status Monitor .

b) Enter the Message Type ZMATMAS##. Also enter the start date of

the course as the first change date and choose Execute . (You mayalso select all the IDocs if you want. The selection for the audit is not

made until the next step.)

c) In the menu of the status monitor, choose Goto! ALE Audit ! Send

Audit Confirmations.

d) In the field Confirmations to system, enter CORE, in the field Message

type, enter ZMATMAS##, and in the fields Date IDoc changed , enter the

date on which the course started and today's date. Choose Execute. .

e) Confirm the message regarding the generation of the Audit IDoc, go

back to the initial screen of the status monitor and refresh the display

by choosing Refresh IDoc Display : In the area of the IDoc outbound processing you will see an entry for the message type ALEAUD.

2. Check the result of the confirmation in the status monitor of the CORE

system and display one of the IDocs involved.

a) In the system CORE, call the status monitor as described in step

3 a), enter the message type ZMATMAS##; and choose Execute .

Your outbound IDocs for the message type ZMATMAS## now

have different status values. If the processing was successful in the

application in the PRODUCTION system, you will see the status

41, otherwise you see the status 39, which may also mean, however,

that your IDoc has not been transferred to the application yet. If theoutbound processing contained errors, the status is set to 40.

b) Select the entry underneath the message type and choose the Display

IDocs button.

c) Select an IDoc and choose the Display IDocs button again. Open the

folder of the status records in order to monitor the updating of the

status values.





Lesson Summary

You should now be able to:• Use the status monitor efficiently






Lesson: Error Analysis and Handling

Lesson Overview

IDoc processing does not always work at once. Configuration errors in the ALE

area and in the affected application itself can lead to errors in the IDoc generation

or the further IDoc processing. This lesson will show you how to systematically

analyze errors and then resolve them.

Lesson Objectives




Business Example

You have set up various ALE scenarios. An administrator is to take over the

error handling in the future. You want to get an overview of the options for error

analysis and error resolution.

IDoc Outbound Processing

In the outbound processing, an IDoc goes through various phases, the results of

which are represented by status values. Successful IDoc outbound processinginvolves three obligatory and three optional status values:




BIT300 Lesson: Error Analysis and Handling

Figure 107: Status Values for Error-Free IDoc Outbound Processing

• 01: IDoc created

• 30: IDoc is ready for sending (ALE service)

• 03: Data passed to port OK

Whether or not the sender system sends an IDoc at once depends on thespecifications in the respective outbound partner profile. If the Group IDocs

option is selected there, the IDocs are only transferred to the receiving port of the

partner profile after the program RSEOUT00 is executed. Therefore, status 30 is

always an intermediate status.

Status 03 only informs you that the IDoc data was successfully transferred to the

port. You only find out whether the IDoc was actually received by the receiving

system when you run the program RBDMOIND. This program, which is intended

for regular background processing with jobs, checks whether there are still IDocs

in the tRFC queue. All the IDocs no longer contained in this queue are given the

status 12 (Sending OK ).

If you have set up the ALE Audit, then there are also the following status values:

• 39: IDoc in target system (ALE service)

• 41: Application document created in receiving system

For the ALE Audit, the program RBDSTATE must be executed in the receiving

system. This program is also intended for regular background processing with

jobs. Status 39 informs you in the sending system that an IDoc has been stored

on the database in the receiving system, but that it has not been transferred to the

application yet. Therefore, the IDoc can have the status 64 or 62 in the receiving





system. Status 41, on the other hand, indicates an IDoc whose data has been

successfully posted in the corresponding application of the receiving system

(status 53).

If errors occur in the IDoc outbound processing, the sender system sets one of the

following status values:

Figure 108: Status Values for Incorrect IDoc Outbound Processing

• 02: Error transferring data to port

• 26: Syntax error in IDoc (outbound)

• 25: Further processing despite syntax error (outbound)

• 29: Error in ALE service

Status 02 is set instead of status 03 if an error occurs during the transfer to the port.

The sender system determines the transaction code EDIO and on the basis of the

assigned workflow task, sends a workflow item to the agent responsible. After

the error is resolved, the IDoc can be transferred to the port again from this work

item or from the IDoc status monitor.

Status 26 indicates that the IDoc is missing a segment which the IDoc basic

type specifies is required, that there are more segments for a segment typethan specified in the IDoc basic type, or that there is some other breach of the

specifications of the IDoc basic type. If the indicator Terminate the processing

if syntax error occurs is not set in the outbound partner profile, the IDoc is still

transferred to status 30 and processed further. However, if the indicator is set, the

sender system determines the transaction code EDIX and sends a work item in

accordance with the assigned workflow task. It is possible to trigger the further

processing of the IDoc despite a syntax error. The IDoc first gets the status 25 and

is then switched to status 02.





If outbound partner profiles are competely missing or incomplete, the system

gives the IDoc involved the status 29. This status is also assigned if a global

company code or a business area is missing. If the IDoc is processed again after the missing settings are added, the system logs this as editing of the IDoc and

creates a copy of the original, which is kept for documentation purposes, even in

its incorrect form. The copy is given status 30 and the original gets status 33

(Original of an IDoc that has been edited ).

IDoc Inbound Processing

In the inbound processing, an IDoc also goes through various phases, the results

of which are represented by status values. Successful IDoc inbound processing

involves four obligatory status values:

Figure 109: Status Values for Error-Free IDoc Inbound Processing

• 50: IDoc added

• 64: IDoc is ready for transfer to the application

• 62: IDoc transferred to application

• 53: Application document posted





Whether or not the receiving system transfers an IDoc to the application at once

depends on the settings in the respective inbound partner profile. If the Start

in background job option is selected there, the IDoc is only transferred to theapplication after the program RBDAPP01 is executed.

Note: In scenarios such as this, the RFC user only requires the

authorization to store IDocs on the database. Required are the RFC

authorizations for the function groups EDIN and ERFC (authorization

object S_RFC) and the authorization for the authorization object

B_ALE_RECV with the desired message types. The user for the

background processing of the program RBDAPP01 must have

authorizations to read the IDoc from the database (authorization object

S_IDOCMONI) and the application authorizations to post the data by

means of the application program.

If errors occur in the IDoc inbound processing, the sender system sets one of the

following status values:

Figure 110: Status Values for Incorrect IDoc Inbound Processing

• 56: Incorrect IDoc added

• 60: Syntax error in IDoc (inbound)

• 61: Further processing despite syntax error (inbound)

• 65: Error in ALE service

• 51: Application document not posted





Status 56 usually tells you that the inbound partner profile is missing for the

message type.

If the indicator Terminate the processing if syntax error occurs is set in the inbound

partner profile, an IDoc with a syntax error is given the status 60. The system

sends the responsible agent a work item on the basis of the workflow task assigned

to the process code EDIY. If the syntax check is not activated, then the incorrect

IDoc is moved directly from status 60 to status 64. If an IDoc with a syntax error

with status 60 is processed further, it is first given status 61 and then status 64.

The system sets status 65 if a global company code or a business area is missing.

If the transfer of the IDoc data to the corresponding application fails, then the

IDoc is given status 51 in most cases. A number of logistical applications have

their own status (52 and 54), but they all indicate an error in the processing of the

IDoc data in the application program itself. Work items are sent to the responsible

agents. Depending on the application, such an IDoc can also be processed “in

the foregound”, meaning interactively. Missing or incorrect values can then be

added or corrected manually.

The end of this lesson you will find suggestions for systematic error analysis,

with information on resolving errors.





Problem: The IDoc Was Not Created

Prerequisites

An ALE scenario has been configured. You know the message type of the

scenario and the program with which the IDoc outbound processing is carried out.

However, no IDoc has been created in the sending system.

Procedure

1. Analyze the type of the outbound processing.

Is the IDoc to be created by means of the message control? You can use

transaction WE64 to find the message types for IDoc scenarios that were

created using the message control.

Is the scenario involved a master data distribution scenario, in which change

pointers are to be evaluated? You can use transaction SALE to find message

types for ALE scenarios that work with change pointers by choosing IDoc

Interface / Application Link Enabling (ALE) ! Modelling and Implementing

Business Processes! Master Data Distribution! Replication of Modified

Data. If you have created a reduced message type which is not in this list

for a message type that is in this list, then you proceed as follows: Choose

IDoc Interface / Application Link Enabling ! Modelling and Implementing

Business Processes! Master Data Distribution ! Scope of Data for

Distribution ! Message Reduction! Create Reduced Message Type

(transaction BD53). Select the reduced message type and choose the button

Activate change pointers.

If the IDoc is to be created using message control, then proceed with step 2.

In a scenario in which change pointers are to be evaluated, you proceed with

step 3. In all other cases, you can proceed directly to step 4.

2. Master data distribution using the SMD tool

Has a change pointer been set for the change document whose data is to

be distributed in an IDoc?

If the master data has been changed since the last time IDocs were created

from change pointers, there should be change documents as well as change

pointers. You can view the change documents with the program RSSCD100.

You can check the change pointers in the database table BDCPV.

Has the program RBDMIDOC been started?

The program RBDMIDOC is usually scheduled as a regular background job.

This program triggers the generation of IDocs from change pointers. Make

sure that the correct message type is selected in the selection screen. Check






whether the report was scheduled with the correct variant, and when it was

last run. For test purposes, you can also start this program using transaction

BD21.

3. IDoc generation using message control

Was the message determination and processing successful?

The message determination is usually linked to an application document,

such as a purchase order, an order or an invoice. Call up the document whose

data should have been sent in IDoc format in the display or change mode and

check the result of the message determination. In most documents, you can

call up this information with the menu entries Goto or Extras. In purchasing

documents, there is a separate button Messages. Check whether the message

was found, and whether it was processed successfully (green traffic light

symbol). Usually you can also call up a processing log for display from thedetails of the message determination.

Are the condition records maintained correctly?

If the expected message was not found in the document, check the

determination record (condition record) for the message type. It is possible

that there is no corresponding determination record for the key combination

in the document. If you are not familiar with the application involved, you

can also search for determination records using transaction NACE. If the

message was found, but not processed correctly, check the transmission

medium and the transmission time. To generate IDocs, the transmission

medium A (ALE) or 6 (EDI) must be entered in the determination record.

Do corresponding partner profiles exist?

Call the transaction WE20 or choose Tools! ALE ! Runtime Settings

! Partner Profiles. Search for the partner: In EDI scenarios, the partner

must be created for partner type LI (vendor) or KU (customer), and in ALE

scenarios for partner type LS (logical system). In EDI scenarios, always

check the partner function too: Does it match the partner function of the

determination record? Have outbound parameters been created for the

respective message type? Is the required data entered in these parameters

(application, message type, process code)?

Has the program RSNAST00 been started?Often, the message is not immediately processed by the program RSNAST00,

but at a later date by means of a background job or an application-specific

transaction. The program triggers the generation of IDocs from messages in

the message control. If the transmission time in the condition record is not 4,

but 1,2 or 3, then the program RSNAST00 must be started in a separate step.

4. Is the distribution model maintained correctly?






Does the distribution model of the sending system contain a view with the

required message type or BAPI? If your distribution model contains many

views, you can also use the menu entry Edit ! Filter Display or the button Filter model display to make a selection based on message type or business

object type. If necessary, add the missing view or the missing message type

or missing BAPI in the maintenance system and transport or distribute this

view to the systems involved.

Is the model view still valid?

The validity of model views is limited. If necessary, check whether your

views can still be used at the present time. To do this, double-click the name

of the model view.

Are filters defined for the message by means of filter objects?

Check the affected view in your distribution model. If filter objects are

entered, then the values entered for the filter object must match the values

transferred with the IDoc from the application. It is possible that the filter

object refers to a required segment in the IDoc basic type. If the conditions

for the field values are not fulfilled, no communication IDoc is created.

Is the filtering performed by means of classification? Is the class in the

sending system assigned to the logical system of the receiver? Is the master

data to be distributed assigned to the distribution class?

In the distribution model, check whether a filter group is created in the view

involved. If the indicator Dependent on class membership is set, then the

filtering is performed by means of the classification. Then choose IDoc Interface / Application Link Enabling (ALE) ! Modelling and Implementing

Business Processes! Master Data Distribution! Distribution Using

Object Classes! Assign Classes to Receiving Logical System. If necessary,

check in the master data to be distributed whether the view Classification is

created, and whether it refers to the correct class.





Problem: The IDoc was Created, but was not Sent

Prerequisites

An ALE scenario has been configured. An IDoc has been created in the sending

system, but it was not sent.

Procedure

1. Outbound partner profile is missing (status 29):

Use transaction WE20 to check whether the sending system has an outbound

partner profile with the receiving system for the message type involved. If

not, generate the missing partner profile from the corresponding view of

the distribution model and check the settings or create the partner profile

manually.

2. IDoc remains in status 30:

Use transaction WE20 to check in the sending system the outbound partner

profile with the receiving system for the message type involved. If the

output mode Group IDocs is selected there, the program RSEOUT00 must

be executed first. Check whether this program is planned as a job for the

background processing and whether the message type involved is scheduled

in a variant. For test purposes you can start the report manually or select the

IDoc in the monitor (transaction BD87) and trigger the sending by means of

the button Execute.

3. Error in the data transfer to the port (status 02):

In the control record of the IDoc, check which port it was sent through.

Call up the IDoc for display. In the Technical short info area, the field Port

provides you with the name of the port which was determined by means of

the partner profile. Check the attributes of this port using transaction WE21.

If the port has been configured incorrectly, you can correct this error here

and send the IDoc again. If, on the other hand, an incorrect port is entered

in the partner profile, then you correct the partner profile. In IDocs that

have already been sent, you can manually change the value of the port in

the control record. To do this, double-click the control record in the IDoc

display and choose Control Record ! Display -> Change. The change mode

appears. Choose the Partner tab page and enter the correct port in the field Port . You can then resend the IDoc.





Problem: The IDoc was Successfully Sent, but it wasnot Received by the Receiving System

Prerequisites

An IDoc was sent to a receiving system through a tRFC port. The IDoc has the

status 03 in the sending system, but it did not reach the receiving system. Report

RBDMOIND does not result in a status change.

Procedure

1. From the IDoc display, you can use the object link to check whether a tRFC

ID is entered. If such an ID exists, then the IDoc was transferred to the

fRFC level. If a Display button appears, then the data packet is still in the

tRFC queue. You can use this button to navigate directly into the tRFC

queue (transaction SM58). Examine the error message for the corresponding

entry in the fRFC queue.

Hint: One cause could be authorization restrictions for the user

entered in the RFC destination. The user could possibly be blocked

because of multiple incorrect logons, or there may be an incorrect

password stored in the RFC destination. Therefore, you must

also check the RFC destination in the sending system and the

authorizations of the user entered there in the receiving system.

Note that usually the RFC destination and the RFC user are used by

various programs. Changing the properties can therefore influenceother ALE scenarios.

2. When you have resolved the error, you can manually trigger the processing

in the tRFC queue: To do this, select the entry and choose Edit ! Execute

LUW . Depending on the settings, the RFC level starts this processing

automatically after a few minutes.

Hint: You can check the general settings for the tRFC using

transaction SM58. Choose Execute to go from the selection

screen to the list and choose Information! System Setting to

navigate to a dialog window with the desired information. Youcan use a local setting to override this system setting in every RFC

destination. Navigate to the display of the RFC destination (for

example, by means of transaction SM59). There, choose Destination

! tRFC Options.





Problem: The IDoc was Received by the ReceivingSystem, but was not Posted

Prerequisites

An IDoc was received by the receiving system, but it does not have status 53 yet.

Procedure

1. Inbound partner profile is missing (status 56)

If the status text states that the partner profile is missing, you add it manually

or have it generated by the system from the distribution model. If necessary,

you can determine from the control record of the incorrect IDoc which

logical system was the sender.

2. IDoc remains in status 64 (the IDoc is ready to be transferred to the

application):

If the indicator Start through background program is set in the partner

profile, then the IDoc is generally transferred to the application by the

program RBDAPP01. Choose System! Services! Jobs! Job Overview,

and in the field ABAP program name, enter RBDAPP01. Then choose the

button Execute: You are told when and at what intervals the program has

been scheduled as a background job. For testing purposes, you can start it

manually or you can transfer the IDoc from the status monitor directly to

the application. If the IDoc is always to be transferred to the application

immediately, then you set the indicator Start immediately in the partner profile.

3. IDoc is in status 51:

Check whether there is more detailed information on the cause of the error

in the long text of the error message for the status. In general, you require

knowledge of the application for the error search. Two technical errors are

often the cause of incorrect IDoc processing in the application:

• Incorrect process code in the partner profile: If the status text / error

text is “ No function module for inbound process code xy”, then there is

an incorrect process code in the partner profile.

• Authorizations missing: Does the RFC user (for immediate processing)or the batch user (for background processing) have the required

authorizations?

You can have incorrect IDocs with status 51 processed after the error is

resolved by executing the program RBDMANI2 ( Posting incorrect IDocs).

This program can be scheduled as a background job.

4. No (active) partner profile exists (status 63):






You have the option to set the partner profile for a partner to inactive. In the

receiving system, check the partner profile with the sending system, by

entering transaction WE20 and calling the partner profiles for display andchoosing the tab page Classification on the header level. If the partner status

is “I”, then the partner is inactive. You can change the value to A (active).





Exercise 12: Error Analysis and Handling

Exercise Objectives


• Find the causes of errors in the IDoc processing

• Correct these errors

Business Example

In the logical system CORE , you have created or changed master data and

distributed it to the receiving systems PRODUCTION and SALES. The data

transfer was not always successful. You check the situation in the status monitor

and resolve the errors.

Task 1: Analysis of the IDoc Status Values

In the case of incorrect IDoc processing, you can analyze the status values of the

IDoc involved to determine in which part of the process an error occurred. Which

status values belong to which (error) situation?

1. The IDoc was not created.

2. The IDoc was created, but was not sent.

3. The IDoc was successfully sent, but it was not received by the receivingsystem.






4. The IDoc was received by the receiving system, but was not processed yet.

Task 2: Postprocessing of an Incorrect IDoc

The IDoc inbound processing can fail because of discrepancies between the

application-specific Customizing settings in the sending and receiving systems.

The IDoc is given the status 51 (application document not posted ). In this exercise

you will learn how to postprocess an incorrect IDoc so that its data can be posted

in the application.

1. In the logical system CORE, add the division 99 to your material master

MATALE-##.

2. Send the changed material to the logical system PRODUCTION and display

the outbound IDoc in the status monitor. What status does the outbound IDoc

have? What status does the inbound IDoc have in the receiving system?

Hint: Use the function “Monitor IDocs” in the system CORE

to gain information about the inbound processing in the system

PRODUCTION.

3. In the system PRODUCTION, call up and display the IDoc in the status

monitor and find out the cause of the processing error. Make a note of the

number of the IDoc: __________

4. What conclusion do you draw from the error message? What options do

you have for solving the problem?

5. Call the incorrect IDoc for display, switch to the change mode, and replace

the value 99 in the field DIVISION with a value defined in the system

PRODUCTION.

Hint: In doing this, use the input help for the field DIVISION .






6. Now try to transfer the IDoc to the application again. What happens? Check

the status records of your IDoc.

Task 3: Setting a Deletion Flag for an IDoc

In some cases, it is no longer possible, or is not desirable, to handle an error by

correcting system settings or editing the IDoc. You want the IDoc to be archived

unchanged. In such cases, you can flag the IDoc for deletion so that it can be

archived at the next opportunity.

1. Send your changed material MATALE-## from the system CORE to the

system PRODUCTION again and call up the status monitor there.

2. In the system PRODUCTION, your IDoc has the status 51 again. Instead of

editing it, you now set a deletion flag for the subsequent archiving.





Solution 12: Error Analysis and Handling

Task 1: Analysis of the IDoc Status Values

In the case of incorrect IDoc processing, you can analyze the status values of the

IDoc involved to determine in which part of the process an error occurred. Which

status values belong to which (error) situation?

1. The IDoc was not created.

Answer: No status value: An IDoc only gets a status once it has been saved

on the database.

2. The IDoc was created, but was not sent.

Answer: Both status 30 ( IDoc is ready to be sent) and status 02 ( Error in the

data transfer to port ) could apply here.

3. The IDoc was successfully sent, but it was not received by the receiving

system.

Answer: The IDoc has the status 03 (data passed to port OK ) and also,

if the program RBDMOIND was executed after it was sent, the status 12

( sending process OK ).

4. The IDoc was received by the receiving system, but was not processed yet.

Answer: If the ALE Audit is set up, the IDoc in the sending system has the

status 39 ( IDoc in target system). In the receiving system the IDoc has the

status 64 ( IDoc is ready for transfer to the application).

Task 2: Postprocessing of an Incorrect IDoc

The IDoc inbound processing can fail because of discrepancies between the

application-specific Customizing settings in the sending and receiving systems.

The IDoc is given the status 51 (application document not posted ). In this exercise

you will learn how to postprocess an incorrect IDoc so that its data can be posted

in the application.

1. In the logical system CORE, add the division 99 to your material master

MATALE-##.

a) Choose Logistics! Materials Management ! Material Master !

Material ! Change! Immediately.

b) Enter the material number MATALE-## and choose Enter .

c) Select the view Basic data 1 and choose Enter .

d) In the field Division, enter 99 and save the change.






2. Send the changed material to the logical system PRODUCTION and display

the outbound IDoc in the status monitor. What status does the outbound IDoc

have? What status does the inbound IDoc have in the receiving system?

Hint: Use the function “Monitor IDocs” in the system CORE

to gain information about the inbound processing in the system

PRODUCTION.

a) Choose Tools! ALE ! Master Data Distribution!Cross-Application

! Material ! Send .

b) Enter your material MATALE-##, your reduced message type

ZMATMAS## and the logical system PRODUCTION and choose

Execute .c) Choose Tools! ALE ! ALE Administration! Monitoring ! IDoc


d) Enter your message type ZMATMAS## and choose Execute : The

IDoc has the status 03.

e) Select the entry underneath the message type and choose the button

Monitor IDocs: In the system PRODUCTION, the IDoc has the

status 51.

3. In the system PRODUCTION, call up and display the IDoc in the status

monitor and find out the cause of the processing error. Make a note of the

number of the IDoc: __________



b) Enter your message type ZMATMAS## and choose Execute .

c) Select the entry underneath the message type and choose the Display

IDocs button.

d) Select the IDoc and choose the button Display status long text : You

will see that an application log has been written from which you can

obtain more detailed information about the problem.

e) Copy the number of the log and click on Execute.

f) In the field Ext. number of the application log , enter this number and

choose Execute .

g) Double-click on the entry with the red traffic light ( Problem Class:

Very Important): You will see that the value 99 is not permitted for

the field MARA-SPART (division). Leave the log and the display of

the error long text.






4. What conclusion do you draw from the error message? What options do

you have for solving the problem?

Answer: Division 99, which you entered in the material master in the

sending system before the distribution, is not defined in the receiving system.

Therefore, the Customizing settings of the two systems are inconsistent.

Now you can either also define division 99 in the receiving system and have

the IDoc processed again, or you can edit the IDoc and have a value defined

in the receiving system for the field Division transferred to the application.

In the exercise, you edit your IDoc.

5. Call the incorrect IDoc for display, switch to the change mode, and replace

the value 99 in the field DIVISION with a value defined in the system

PRODUCTION.

Hint: In doing this, use the input help for the field DIVISION .

a) Choose the button Display IDocs.

b) Open the tab page Data records and double-click on the symbol to the

left of the segment E1MARAM.

c) Choose Display Data Record -> Change and confirm the information

that your changes have been saved in the database with Enter .

d) Navigate to the field DIVISION and call up the input help. Use a

double-click to accept one of the entries in the list of permitted values.

Save this change, leave the data record editor, and then leave the

IDoc display.






6. Now try to transfer the IDoc to the application again. What happens? Check

the status records of your IDoc.

a) Go back to the status monitor and choose Refresh IDoc display : The

system sets the status 69 ( IDoc has been edited ).

b) Select the entry for your edited IDoc and choose the button Process:

The status of the IDoc has been changed from 69 to 53.

c) Choose the button Display IDoc again and open the folder Status

records: You see that after the editing, your IDoc has been reset to

status 51 and then transferred to the application again.

d) Go from the IDoc display back to the status monitor: The system has

created a second IDoc and assigned to it the status 70 (original of an

IDoc that has been edited ). The long text is: “This IDoc has been

stored as the original of an edited document .” Thus, the system keeps a

copy of the incorrect IDoc as it was before the editing.

e) Call up the edited IDoc for display again, open the folder of the status

records and double-click on the symbol to the left of the status long text

for the status 69: You will see which user edited this IDoc in which

segment, and which number the copy with the original data has.

f) Leave the IDoc display, select your IDoc and choose the button Display

relationships: A screen appears with the two IDoc numbers.

Task 3: Setting a Deletion Flag for an IDoc

In some cases, it is no longer possible, or is not desirable, to handle an error by

correcting system settings or editing the IDoc. You want the IDoc to be archived

unchanged. In such cases, you can flag the IDoc for deletion so that it can be

archived at the next opportunity.

1. Send your changed material MATALE-## from the system CORE to the

system PRODUCTION again and call up the status monitor there.

a) Proceed in the way described in the second task in step 2, in order to

distribute your material MATALE-##.

b) Find the incorrect IDoc in the system PRODUCTION in the status

monitor (see step 3): It has the status 51 again.






2. In the system PRODUCTION, your IDoc has the status 51 again. Instead of

editing it, you now set a deletion flag for the subsequent archiving.

a) Select your IDoc in the status monitor and choose Edit ! Restrict

and process.

b) Remove the indicator Background proc. and choose Execute .

c) Choose the button Deletion flag and confirm the confirmation prompt

with Enter : A message appears that your IDoc has been flagged for

deletion.

d) Check the result in the status monitor: The IDoc now has the status

68 (error, no further processing ).





Lesson Summary

You should now be able to:• Perform error analysis using the ALE status monitor






Lesson: SAP Workflow in ALE Environment

Lesson Overview

In this lesson you learn how to use the SAP Workflow for IDoc inbound

processing, error handling and active monitoring.

Lesson Objectives






Business Example

You have configured ALE scenarios in your system landscape. If errors occur, an

administrator or an employee of the business department should be informed by

means of the SAP Workflow.

Using the SAP Workflow in ALE Scenarios

The SAP Workflow is a tool for the automation of business processes within an

SAP system, but also beyond system boundaries. It is not connected to specificapplications, but functions independently in all applications. The primary aim is to

provide the correct agent with a task at the correct time.

In ALE scenarios, you can use the functions of the SAP Workflow for the IDoc

inbound processing, as an alternative to inbound function modules, for monitoring

the inbound and outbound IDocs during ongoing operation, and for processing

incorrect IDocs.

IDoc Inbound Processing Using SAP Workflow

A process code for the IDoc inbound processing can refer to a task or a workflow.




BIT300 Lesson: SAP Workflow in ALE Environment

Figure 111: IDoc Inbound Processing Using Workflow

For the inbound IDoc, a workflow can be started by means of a process code.

You can define such a workflow freely and assign it to the desired process code.

Examples of the use of such workflows are:

• You want to generate an application document automatically from the IDoc.

Subsequently, the application document is to be passed to an employee for

checking.

• The IDoc is to be checked and, if necessary, changed before the application

document is created. In this case, the IDoc is edited, not the application

document.

• The IDoc or the application document is to be forwarded to one or more

agents.

• New (outbound) IDocs are to be sent on the basis of the inbound IDoc.

• The receipt of an IDoc is to trigger some other action.

You will find an example of a workflow-based IDoc inbound processing in the

ALE scenario “Stock Transfer Between Distributed Systems”. For the usual

inbound processing of IDocs with purchase order data, the specified process code

is ORDE, to which a function module is assigned for the transfer of data to the

application. In certain cases, however, the order is not to be created automatically

in the receiving system, but rather by a business department employee, onlyafter the puchase order data has been checked. Such cases use the process code

ORDE_BY_WORKFLOW, which refers to a workflow and not to a function

module. In this way, the IDoc inbound processing can be performed interactively.

The employee can not only check the data, but can also make changes.





IDoc Monitoring with Workflow Connection

The active monitoring of inbound and outbound IDocs is usually scheduled as a

periodic background job. The monitoring evaluates whether the number of IDocs

with a particular status exceeds a previously defined threshold value. During

the selection run, the IDocs that fulfill the selection criteria are evaluated. If the

currect status value of an IDoc corresponds to the status in the selection screen,

this IDoc is evaluated as critical. If the number of critical IDocs exceeds the

threshold value entered, then this situation is evaluated as critical and a status

confirmation is triggered automatically. The task “ ActiveIDocMonitoring ”

(TS4508518) is started and a work item is sent to the recipient that is determined.

You can use the program RSEIDOCA to perform the active monitoring. For

this purpose, you must define a variant (menu path: Tools! ALE ! ALE

Administration! Services! Periodic Processing ! Schedule IDoc Monitoring

with Workflow Connection).

Error Handling with SAP Workflow

The exception and error handling in the ALE environment is always realized

through a workflow. In the case of an exception, one or more agents are informed

of the error situation by means of a work item, and they are provided with the

IDoc involved.

Figure 112: Error Handling with Workflow

The respective agents responsible are entered in the partner profiles or the settings

for the IDoc administration, and the general potential agents are entered in the task

definition. If an organization model is maintained in your company, along with

users you can also assign positions or organization units as agents (see below).





Behind the exception handling cases of the IDoc interface that are delivered by

SAP, there are individual tasks. They are started by means of the process codes of

the error handling. These process codes are subdivided into system and status process codes.

If you set the express indicator in the detailed settings of a process code, the agents

of the corresponding task immediately receive an express message on their screens

when there is a new work item in their inbox.

The figure below shows the exception handling in the IDoc outbound processing:

Figure 113: Process Codes for Errors in the Outbound IDoc





• The process code EDIM applies to outbound and inbound processing. It

applies when it has not been possible to create an IDoc yet.

• EDIN is used for outbound processing by means of message control: You

can use the NAST record to branch to the application document from the

work item.

• EDIO reacts to an outbound IDoc for which a general processing error

has occurred.

• EDIX reacts to an outbound IDoc for which a syntax error has occurred.

• EDIP reacts to an IDoc stack (batch run of the report RSEOUT00) for

which a processing error has occurred which affects all the IDocs to the

same degree (example: a non-existant port). The work item sent when the

corresponding task is started allows you to correct the error and trigger the processing of the IDoc stack again.

• If an error status is confirmed by the external system, then a task for the error

handling is also started by means of the status process code EDIS. With the

status process code EDIR you can also trigger the outbound processing again

after you have corrected the error.

Hint: The process code EDIR is new to SAP R/3 4.6A. It replaces

the process code EDIS. During an upgrade, you must explicitly

perform the change to EDIR in IMG.

You can define additional exception handling cases for the status confirmation

and identify them using process codes.

The inbound exception handling corresponds to the outbound exception handling.

Corresponding process codes are used to start tasks for which a work item is

sent to the agents that are determined.





Authorization Concept

In the case of an exception, a task is started by means of a process code. A work

item is created as an instance of this task. In order to determine the correct agent

for the work item, the system requires two quantities of agents, the “potential”

and the “permitted” agents. The intersection of these quantities filters out the

recipients of the work item.

Figure 115: Determining the Work Item Agents

In every partner profile for ALE or EDI scenarios, you must assign the partner a

permitted agent for the error and exception handling. You can also enter for eachmessage type a permitted agent that differs from this higher-level agent. In the

case of an error (for example, an inbound IDoc with a syntax error), the system

first tries to determine an agent for the combination of partner and message type.

If no specific agent exists for the message type which contains the error, then the

agent assigned to the partner is notified. If there are no partner profiles with the

partner, the system then tries to determine the IDoc administrator. Therefore,

for situations in which the system cannot find any partner profiles, you should

nominate an agent in the general settings for the IDoc administration, so that an

employee will be notified if an error occurs. For this purpose, call transaction

SALE and choose IDoc Interface / Application Link Enabling (ALE)! Basic

Settings! IDoc Administration.





Figure 116: Agent Search in the ALE Environment

When a task is started, a rule entered for the task is used to determine the group of

potential agents, on the basis of the task definition. Then the system determines

the intersection of the potential and permitted agents on the basis of the partner

profiles and the IDoc Administration. All the permitted agents receive the work

item for the task. The work item is put into the inbox of the recipient's SAP

Business Workplace. The item provides him with direct access to the incorrect

IDoc, and he can begin the error processing immediately.

The tasks of the IDoc error handling are classified as general tasks in SAP R/3 or

SAP ECC, in the Workflow Customizing (transaction SWU3). With this setting,

every user is a potential agent, and all the permitted agents receive the work item.

If there are a number of recipients for a work item, as soon as the first agent

accesses it, the work item is deleted from the inboxes of the other recipients.

You can enter users or elements of the organizational management, such as

positions or organization units, as permitted agents. The use of elements of the

organization management increases the flexibility for organizational changes.

Maintenance of an Organizational StructureIn the automatic Workflow Customizing (transaction SWU3), the workflows

for IDoc processing supplied by SAP which are located in the task group

TG74500044, are declared to be “general”. They can thus be processed by all

users. The restriction to the relevant agents for IDoc errors is effected by an

intersection with the permitted agents for the IDoc interface (see above).





Figure 117: Organizational Structure

If you use elements of an organizational model to define the permitted agents,

you can, for example, assign a whole group of agents to the respective level by

entering a correspondingly occupied organization unit or position. You can also

switch to the organizational responsibility centrally in the maintenance of the

organizational model, by means of a simple reassignment. This saves you the

effort of searching all the levels of the IDoc interface.

Note: The use of such organizational models is independent of the use

of the application mySAP ERP Human Capital Management. The basic

system provides everyone with the required tool (simple maintenance of

the organizational management – transactions PPOC, PPOM, PPOS).

In the simple maintenance, you create the hierarchical structure of your

organizational model, starting with the root organizational unit. In a further step,

you create the required positions and assign them to the desired organizational

units. In the last step, you assign users to the positions as position holders.

Processing Work Items in the SAP Business Workplace

The SAP Business Workplace integrates workflow functions into general office

functions. There, along with work items, you also receive mails, documents and

deadline messages. The agents receive the work items intended for them in the

inbox of their Business Workplace. You reach the Business Workplace through

transaction SBWP.





Figure 118: SAP Business Workplace

From there, you choose the folder Inbound and the area Workflow to go to the

worklist display. You will see all the active work items. You double-click to

start the execution of the selected work item. If one of the recipients has called

up the work item for processing in this way, it is deleted from the inboxes of

the other recipients.

If an express indicator is set in the settings for the process codes, then the

recipients of the work items receive an express notification, no matter where they

currently are in the SAP system. From the express notification, they can then

navigate directly to their Business Workplace and react quickly.

Tools of the Workflow Administration

When you are working with workflow support, you can also use tools of the

workflow administration if required - for example, if a work item has an incorrect

status and you want to restart the workflow after removing the cause of the error,

or if a workitem has no recipient and the administrator who finds it is to process

it himself or forward it to the actual person responsible. You may also want to

search directly for work items whose deadline has been exceeded.





Work items that were created within the IDoc exception handling are critical.

Therefore, you require tools in order to quickly detect and resolve technical or

organizational errors. The most widely-used tools are the following transactions:

• Transaction SWI1 ( selection report for work items) for finding incorrect

work items

• Transaction SWPR (workflow restart after error ) for the restart of an

incorrect work item after the error has been resolved

• Transaction SWI2_DEAD (work items with exceeded deadline) for finding

work items with exceeded deadlines

• Transaction SWI2_ADM1 (work items without agent ) for finding work items

with no recipient

The transactions listed are for finding work items for specific tasks, thus enabling

you to find IDoc-relevant work items. You can then branch from the work itemfound to the IDoc display.





Exercise 13: Processing an Incorrect IDoc

from a Work ItemExercise Objectives


• Process an incorrect IDoc from a work item

Business Example

You have configured ALE scenarios in your system landscape. If errors occur,

an administrator or an employee of the business department should be quickly

informed by means of a workflow.

Task:

Transfer the message type ZCREMAS## into your model view TRAINING##,

generate the outbound partner profiles with the partner system PRODUCTION

and distribute the model view again. Then send a vendor master and check the

inbound IDoc. Find the corresponding work item and remove the error by means

of the work item processing.

1. In the logical system CORE, in your model view TRAINING##, add an

entry for the message type ZCREMAS##. The sender is the logical system

CORE, and the receiver is PRODUCTION. Generate the outbound partner

profiles for this message type and distribute your model view again to thesystem PRODUCTION.

2. Send the master record of the vendor T-K515D## from the system CORE to

the system PRODUCTION. Check the inbound IDoc in the status monitor

of the receiving system. What status does it have? Make a note of the

number of the IDoc: ________________

Hint: Use the message type ZCREMAS##.

3. Check in the system PRODUCTION whether your inbox in the SAP

Business Workplace contains a work item for this IDoc. Display the IDocfrom the attachment of the work item, determine the cause of the error, and

add the missing settings.

4. Then try to start the processing of the IDoc again. What status does the

IDoc have now?





Solution 13: Processing an Incorrect IDoc

from a Work ItemTask:

Transfer the message type ZCREMAS## into your model view TRAINING##,

generate the outbound partner profiles with the partner system PRODUCTION

and distribute the model view again. Then send a vendor master and check the

inbound IDoc. Find the corresponding work item and remove the error by means

of the work item processing.

1. In the logical system CORE, in your model view TRAINING##, add an

entry for the message type ZCREMAS##. The sender is the logical system

CORE, and the receiver is PRODUCTION. Generate the outbound partner

profiles for this message type and distribute your model view again to the

system PRODUCTION.



Maintain Distribution Model and Distribute Views.

b) Switch to the change mode (Switching between display and change

mode ) and in your model view TRAINING## select the entry

for the receiving system PRODUCTION and choose the button Add

message type.

c) Enter the message type ZCREMAS## and choose Enter . Save your changes.

d) Select your model view TRAINING##, and in the menu of the

distribution model, choose Environment ! Generate Partner Profile

and in the next screen, choose Execute : Outbound parameters are

created for the message type ZCREMAS##. Leave the log display.

e) Select your model view TRAINING## and in the menu of the

distribution model, choose Edit ! Model View! Distribute. Deselect

the entry for the logical system SALES and choose Enter .






2. Send the master record of the vendor T-K515D## from the system CORE to

the system PRODUCTION. Check the inbound IDoc in the status monitor

of the receiving system. What status does it have? Make a note of thenumber of the IDoc: ________________

Hint: Use the message type ZCREMAS##.

a) Choose Tools! ALE ! Master Data Distribution!Cross-Application

! Vendor ! Send .

b) In the field Account number of the vendor , enter T-K515D##, in the

field Message type, enter ZCREMAS## and in the field Target system,

enter PRODUCTION and choose Execute . A master IDoc and a

communication IDoc are created.c) In the PRODUCTION system, choose Tools! ALE ! ALE

Administration! Monitoring ! IDoc Display! Status Monitor .

d) Enter your message type ZCREMAS## and choose Execute : Your

IDoc has the status 03 (incorrect IDoc added ).

e) Select the entry and click on the Display IDocs button. Make a note of

the number of the IDoc.






3. Check in the system PRODUCTION whether your inbox in the SAP

Business Workplace contains a work item for this IDoc. Display the IDoc

from the attachment of the work item, determine the cause of the error, andadd the missing settings.

a) Choose Menu! Business Workplace.

b) Choose Inbox!Workflow! Grouped according to content . Search

the list for your IDoc from step 2 e) and select it so that your work item

appears in the detail window on the right half of the screen.

c) Choose Execute , and in the next screen (the status display of the

IDoc) choose the button IDoc display.

d) Open the folder Status records and double-click on the symbol beside

the status long text ( EDI: Inbound partner profile does not exist ).

e) The error analysis tells you that the inbound partner profiles with

the partner PRODUCTION are missing for the message type

ZCREMAS##. Click on the text “ Execute function”.

f) The system takes you to the transaction for maintaining partner profiles.

Select the system CORE in the folder of the partner type LS, and in the

inbound parameter area, choose Create inbound parameter .

g) Enter the message type ZCREMAS## and the process code CRE1 and

save the change. Leave the maintenance of the partner profiles, close

the display of the status long text and leave the IDoc display.

4. Then try to start the processing of the IDoc again. What status does theIDoc have now?

a) In the status record display, choose the button Process: A message tells

you that your IDoc was processed successfully.

b) Confirm the message with Enter and choose Refresh : The work item

has been deleted from your inbox.

c) Call up the status monitor again. You will find a description of the

procedure in step 2 c). If your status monitor was still open in another

mode, choose Refresh IDoc display : The IDoc now has the status 53

(application document posted ).





Lesson Summary

You should now be able to:• Check workflow settings for the error handling of IDocs








Lesson: Archiving IDocs

Lesson Overview

This lesson shows you how to archive IDocs using transaction SARA, and the

options for displaying archived IDocs. Additional reorganization options in the

IDoc environment are also shown.

Lesson Objectives




Business Example

You have set up various ALE scenarios and want to archive the IDocs that have

been processed successfully. You also want to delete from the database table

entries for IDoc connections and processed change pointers.

Archiving IDocs

IDocs cannot be directly deleted from the database, but only within the data

archiving process. The data archiving takes place in two steps: Firstly, archive

files are written for the IDocs selected for archiving, then the correspondingdatabase entries are deleted.

Figure 119: Archiving IDocs - First Step: Writing Archive Files




BIT300 Lesson: Archiving IDocs

The archiving is realized by means of an archiving object, which provides all the

functions required for archiving a business object, especially the necessary write

and delete programs. The archiving object for archiving IDocs is called IDOC.

After setting the desired Customizing options, you can use transaction SARA to

start the data archiving with the archiving object IDOC by creating a variant of the

write program with the desired selection values, maintaining the start data and the

spool parameters, and starting the execution.

Depending on the Customizing setting, the second step of the data archiving - the

deletion of the corresponding database entries - is either carried out automatically

directly after the write run, or it is started manually with transaction SARA.

Figure 120: Archiving IDocs - Second Step: Deleting IDocs from the

Database

In the selection for the deletion run, you can only choose archive files that have

already been written. This ensures that no data is deleted from the database

for which no archive files exist yet. You also maintain the start date and spool

parameters and start the execution here. From transaction SARA you can navigate

directly to the job overview and view the log for the respective run there. The

actual archiving is complete when the delete run is finished.

You can display the archived IDocs with transaction WE09. However, you can

also call them up for display with the archive information system (transactionSARI). A prerequisite for this is that an active archive information structure must

exist, which you have filled either implicitly with the deletion run, or explicitly

with transaction SARI.

Note: In an SAP R/3 or SAP ECC system you will find the archive

information structure SAP_IDOC_001 for this purpose. However, you

can also create user-defined archive information structures on the basis of

the field catalog of the same name.





Archivability Criterion: IDoc Status

The IDoc status is the only archivability criterion which the write program checks

for the archiving object IDOC. You can use transaction WE47 to display the IDoc

statuses which are indicated as archivable.

Figure 121: Status Maintenance - Archiving

The following two figures provide you with an overview of the standard settings

for archivable IDocs in outbound as well as inbound processing.

Figure 122: Archivable Status Values in Outbound Processing





You can determine the meanings of the individual statuses directly in transaction

WE47 in the detailed view of the status, or in transaction BD87 in the input help

for the field Status.

The following status values are indicated as archivable in outbound processing:

03 Data passed to port OK

12 Dispatch OK

31 Error, no further processing

39 IDoc in receiving system (ALE service)

40 Application document not created in target system

41 Application document created in target system

It is sometimes necessary to change these standard settings, for example if you set

ALE audit for all message types, and status 03 is therefore not a final status value.

If an error occurs that cannot (or should not) be corrected, you can transfer the

IDocs from any status with errors to status 31 (error - no further processing )

and then archive it.

To transfer an incorrect IDoc to status 31, proceed as follows: In transaction

BD87, select the entry with the incorrect IDoc. Choose Edit ! Restrict and

process, remove the indicator Background processing and in the next screen

choose the button Delete flag and confirm the confirmation prompt with Enter .

Figure 123: Archivable Status Values in Inbound Processing





The following status values are indicated as archivable in inbound processing:

53 Application document posted

68 Error, no further processing

Deleting Links with IDocs

There may be links between IDocs and other objects. In the status monitor

(transaction BD87), you can display these link relationships. For example, an

outbound IDoc can be linked to an inbound IDoc, an edited IDoc or an application

document.

As the number of IDocs increases, it is not only the table of data records that

gets big. The tables in which the links are updated also increase in size, so thatobsolete entries should be deleted from them from time to time. Since SAP R/3

4.6B, the program RSDLDREL has been available. You can use this program to

delete application links stored in the table IDOCREL. In contrast to the archiving

process, this results in them being lost forever. Since SAP Web Application Server

6.20, it is possible to archive the links as well when archiving IDocs. Since SAP

Web Application Server 6.40, the links are archived automatically along with

the IDocs. If you no longer need the links, you can still delete this data with the

program RSRLDREL before archiving.

Reorganizing Change Pointers

If you are using the change pointer mechanism to create large numbers of IDocs,

you fill the corresponding database tables. Because change pointers are obsolete

after they are processed, you should regularly delete the table entries that are no

longer required. The program RBDCPCLR is provided for this purpose. You

can call this program using transaction BD22. It deletes change pointer entries

from the database tables.

You can select obsolete and/or processed change pointers. It is also possible

to make a selection based on the date and time. You can display in advance

a list of the change pointer entries selected in the test mode. Obsolete

change pointers are those created before the date and time specified by

you in the selection screen. The change pointers you have selected as

obsolete are deleted, whether or not they have already been processed.

Processed change pointers are those processed before the date and time specified

by you in the selection screen. Therefore, only the change pointers already

processed are deleted.





Lesson Summary

You should now be able to:• Describe the IDoc archiving procedure





Unit Summary BIT300

Unit Summary















Unit 6 Appendix

Unit Overview

In this appendix, you will find information about renaming logical systems and

about courses of action for identifying and resending lost IDocs after a database

breakdown.

Unit Objectives


• Explain the correct procedure for changing logical system names

• Describe the IDoc recovery procedure and the settings required for this

function

Unit Contents

Lesson: Renaming Logical Systems . ... .. .. ... .. ... ... .. ... ... .. ... .. ... ... .236Lesson: IDoc Recovery Following Database Error.........................241


http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 6: Appendix BIT300

Lesson: Renaming Logical Systems

Lesson Overview

This lesson explains why it is problematic to rename logical systems and how

logical system names can be changed, if required.

Lesson Objectives



Business Example

When setting up an SAP system, you used a name that no longer complies with

your current naming conventions. So you want to check whether it is possible to

change the logical system name now, and which is the best procedure to follow.

Renaming Logical Systems

Logical systems have a technical name up to 10 characters long and an explanatory

short text. The definition of logical systems is a Customizing activity of ALE.

Since SAP R/3 4.5A, certain applications require the assignment of a logical

system name to the client.

Figure 124: Logical Systems




BIT300 Lesson: Renaming Logical Systems

Application documents in which the field Logical system has remained empty,

or which are saved with the current logical system name of your client, are

interpreted as local documents by the client.

If the logical system name of a client is changed, the modeling of the ALE

message flow may become inconsistent. Application documents created before

the logical system name was changed are classified as external documents after

the change, and can therefore often no longer be found.

ALE provides a tool for renaming logical systems in application tables, the

transaction BDLS.

Figure 125: Conversion of Logical System Names

Client and database copies are often used to set up a development and test

landscape. If users are managed centrally, the participating logical systems must

have unique names. Within an independent SAP system, any logical system

names can be assigned.

Caution: You are strongly advised against changing the names of logical

systems in production systems, since this may lead to data losses anddata inconsistency.





Figure 126: What is the Problem?

Figure 127: How Are Logical System Names Changed?




BIT300 Lesson: Renaming Logical Systems

For information on changing the logical system name of a client, see the SAP

library or go to the Customizing in ALE and choose IDoc Interface / Application

Link Enabling (ALE)! Basic Settings! Logical Systems! Convert Logical System Names in Application Tables.

Note: An appropriate authorization is required for the execution of the

program (authorization object B_ALE_LSYS).

You are advised to start the conversion in test mode. If you set the indicator Test

run, all relevant tables will be analyzed and the number of entries contained in the

tables will be determined. These will then be output in a list. If the new logical

system name is already available in the relevant tables, the system queries whether

the conversion is to be continued or not. You must check the table in which this

logical system name was found and determine whether you want to perform the

conversion for these entries. If you do not want to convert these entries, cancel

the conversion.

Figure 128: Conversion - Points to Observe





Lesson Summary

You should now be able to:• Explain the correct procedure for changing logical system names




BIT300 Lesson: IDoc Recovery Following Database Error

Lesson: IDoc Recovery Following Database Error

Lesson Overview

This lesson tells you when and how to use the functions for IDoc recovery.

Lesson Objectives



function

Business Example

During an IDoc transfer, the database of the receiving system crashed. You want

to use the IDoc recovery to restart the transfer of all the IDocs which could not be

saved on the database of the receiving system.

IDoc Recovery Following Database Error

Figure 129: IDoc Recovery Following Database Error

The IDoc recovery uses two transactions:

• Transaction BDRC for determining the recovery objects

• Transaction BDRL for processing the recovery objects





Figure 130: IDoc Recovery - Procedure I

Before the transaction is started, the following entries are added to the distribution

model in a model view: (S1 is the system affected by the database crash.)

S1 sends RCYFET to S2

S1 receives RCYRSP from S2

S1 sends RCYLST to S2

The model view created in the system S1 is distributed to the system S2. The

partner profiles are generated in both systems.

The transaction is started in system S1. The participating system S2 is chosen.

The system settings in S1 and S2 are checked. If the check ran successfully, the

recovery objects are determined (F8). Finally, the system reports that 1 IDoc has

been set up for the message type RCYFET.

As soon as the IDocs for the message types RCYFET, RCYRSP and RCYLST

have been successfully posted in both systems S1 and S2, the next step of

“processing recovery objects” can be started.We recommend using the ALE audit technology for message type RCYFET from

the partner system in order to inform the recovered system that the activity was

performed in this partner system.





Figure 131: IDoc Recovery - Procedure II

All participating systems are provided with information on the date and time of the

reset system by using message type RCYFET. IDocs, which were exchanged with

the reset system, are selected here and confirmed with message type RCYRSP.

The IDocs that are missing in this system and the further activities that are to be

carried out are determined in the reset system. This information is sent to the partner systems in IDocs for the message type RCYLST, in order to derive the

activities for certain objects in the partner systems.





Figure 132: IDoc Recovery - Procedure III





Lesson Summary

You should now be able to:• Describe the IDoc recovery procedure and the settings required for this

function




Unit Summary BIT300

Unit Summary




function




BIT300 Course Summary

Course Summary


• Set up a distribution model for exchanging master and transaction data

between systems

• Create partner profiles for data exchange in enterprises and for electronic

communication with business partners

• Determine the scope of data to be distributed, depending on its type and

recipient

• Monitor data exchange between systems




Course Summary BIT300




Index

AAccess sequence, 111Adapter , 51ALE Customizing object, 47ALE layer , 37Archiving object, 229

BBAPI, 139, 145BAPI Explorer , 145Basic type, 17, 30, 80, 82, 88Business object, 138Business Object Repository,

141Business object type, 138

CChange documents, 76Change pointers, 76, 88Classification, 85Communication layer , 38Communications IDoc, 33Condition table, 111Condition type, 110Control record, 33Cross-system company code,

49Customizing, 45

D

Data record, 33Distribution group, 47Distribution model, 60, 121,

146, 158Distribution Model, 18

EEDI converter , 105Event, 217

FField value conversion, 49File port, 39Filter group, 84Filter object, 82

GGlobal company code, 195

IIDoc, 17, 30, 45, 148, 159,

179IDoc basic type, 119, 192IDoc status, 35, 190

LLogical system, 9, 16, 60, 121

M

Master IDoc, 32, 123Message, 108Message category, 148Message control, 108, 119Message type, 10, 17, 30, 60,

76, 80, 86, 109, 111reduced, 86

Model view, 11, 18, 60

OOrganizational management,

219

Output determination procedure, 111

PPartner function, 107Partner profile, 22, 34, 61,

106, 120, 150, 159, 191,218

Partner type, 106Port, 20, 38, 106, 120, 191




Index BIT300

Port type, 106Process code, 22, 40, 64, 121,

192, 212Processing time, 112

RRemote Function Call (RFC),

19, 21RFC destination, 19, 61, 146,

158

SSAP Solution Manager , 48SAP Workflow, 212

Segment, 31, 80Segment field, 31

Segment filtering, 80Segment type, 31, 87Status record, 33

TTransmission medium, 120tRFC port, 39tRFC queue, 39

WWork Item, 192, 214




Feedback

BIT300 Integration Technology ALE

Documents

Transcript of BIT300 Integration Technology ALE