Bit300 en Col54 Fv Part a4

BIT300 Integration Technology ALE SAP NetWeaver

Date Training Center Instructors Education Website

Participant Handbook Course Version: 2005 Q4 Course 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 A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.

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. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).

2005/Q4

Example text

Emphasized words or phrases in body text, titles of graphics, and tables

EXAMPLE TEXT

Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.

Example text

Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.

Example text

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

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

© 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


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 ............................................. 30 Synchronizing Customizing.......................................... 44 ALE and the SAP NetWeaver Exchange Infrastructure.......... 51

Unit 2: Master Data Distribution ...................................... 57 Example: Material Master ........................................... 58 Using 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 ................................138 The Usage of BAPIs in ALE ........................................145 Example: Travel Expenses .........................................155

Unit 5: Monitoring Data Distribution, Error-Handling and Archiving.................................................................. 177 IDoc Status Management ...........................................179 Error Analysis and Handling ........................................190 SAP 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


v

Contents

vi

BIT300


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

2005/Q4

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


vii

Course Overview

BIT300

SAP Software Component Information The information in this course pertains to the following SAP Software Components and releases:

viii


2005/Q4

Unit 1 ALE 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 system through 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


1

Unit 1: ALE Fundamentals

BIT300

Lesson: Basic ALE Customizing ............................................... 15 Exercise 1: Basic ALE Customizing ...................................... 25 Lesson: Intermediate Documents ............................................. 30 Exercise 2: Documentation for Basic Types ............................. 41 Lesson: Synchronizing Customizing .......................................... 44 Lesson: ALE and the SAP NetWeaver Exchange Infrastructure .......... 51

2


2005/Q4

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

List examples of business processes in distributed system landscapes Differentiate ALE from EDI

Business Example Globally-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 as customers, 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

2005/Q4


3


BIT300

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 invoices sales 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 •

• • • •

4

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


2005/Q4

BIT300


Internal Communication: Distributing Master Data with ALE 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 sales and 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 • • • •

2005/Q4

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?


5


BIT300

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

6


2005/Q4

BIT300


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

2005/Q4


7


BIT300

Lesson Summary You should now be able to: • List examples of business processes in distributed system landscapes • Differentiate ALE from EDI

8


2005/Q4

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.


Explain the terms “logical system” or “logical system name”, “message 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 to exchange 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

2005/Q4


9


BIT300

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

10


2005/Q4

BIT300


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, you normally 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.

2005/Q4


11


BIT300

Figure 9: Model View in a Distribution Model

You then need to distribute the newly created model view, in other words, make it 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.

12


2005/Q4

BIT300


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.

2005/Q4


13


BIT300

Lesson Summary You should now be able to: • Explain the terms “logical system” or “logical system name”, “message type” and “distribution model” • Explain the function of the distribution model

14


2005/Q4

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

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

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

2005/Q4


15


BIT300

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 them to Clients Each system in the system landscape must have a logical system name. This name 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 Reference IMG, 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.

16


2005/Q4

BIT300


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 structure of 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”.

2005/Q4


17


BIT300

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.

18


2005/Q4

BIT300


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 Function Calls (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.

2005/Q4


19


BIT300

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 within the 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”).

20


2005/Q4

BIT300


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

2005/Q4


21


BIT300

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.

22


2005/Q4

BIT300


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

2005/Q4


23


24

BIT300


2005/Q4

BIT300


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

2005/Q4


25


26

BIT300

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.


2005/Q4

BIT300


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.

2.

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.

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 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 for each one: in the Logical system field, you will see click Details the logical system name assigned to the client in question (CORE, SALES or PRODUCTION).


2005/Q4


27


3.

BIT300

In the distribution model for the CORE system, select all the model views containing message type MATMAS. Hint: Use the Filter model display button.

4.

5.

28

a)

Select IDoc Interface / Application Link Enabling (ALE) → Modelling 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.

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

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.


2005/Q4

BIT300


Lesson Summary You should now be able to: • 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

2005/Q4


29


BIT300

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

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

30


2005/Q4

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 hierarchical dependencies, this documentation includes the following attributes: • •

•

2005/Q4

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.


31


BIT300

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:

32

MANDT

Client

DOCNUM

Number of the IDoc

SEGNUM

Consecutive number (line number in internal table)


2005/Q4

BIT300


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

2005/Q4


33


BIT300

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

34


2005/Q4

BIT300


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

2005/Q4


35


BIT300

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

36


2005/Q4

BIT300


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

2005/Q4


37


BIT300

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

38


2005/Q4

BIT300


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.

2005/Q4


39


BIT300

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 is transferred to the application by a function module. However, a workflow could also be started instead.

40


2005/Q4

BIT300


Exercise 2: Documentation for Basic Types Exercise Objectives After completing this exercise, you will be able to: • 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.

2005/Q4

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.


41


BIT300

Solution 2: Documentation for Basic Types 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.

2.

3.

42

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

.

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.

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. to exit the HTML display.

a)

Choose Back

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.


2005/Q4

BIT300


Lesson Summary You should now be able to: • 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 system through to processing in the target system

2005/Q4


43


BIT300

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

Describe methods for adjusting Customizing settings in SAP system 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 Across Two Systems If all applications are integrated in one system, the programs access the same database. 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.

44


2005/Q4

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 executing the next step needs to be transferred.

2005/Q4


45


BIT300

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.

46


2005/Q4

BIT300


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

2005/Q4


47


BIT300

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 logical maintenance 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 carried out 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 SAP Solution 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

48


2005/Q4

BIT300


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 Company Codes 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. When creating 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).

2005/Q4


49


BIT300

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

50


2005/Q4

BIT300

Lesson: ALE and the SAP NetWeaver Exchange Infrastructure

Lesson: ALE and the SAP NetWeaver Exchange Infrastructure Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •

Explain how ALE scenarios are integrated into SAP XI

Business Example You have already set up some ALE scenarios in your system landscape and are considering 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 outbound message processing.

2005/Q4


51


BIT300

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 the Integration Server in the form of business systems that are stored in the SLD. A logical system name can be assigned to these business systems.

52


2005/Q4

BIT300


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 port references 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: ., 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: • • • • •

2005/Q4

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”


53


BIT300

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

54


2005/Q4

BIT300


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

2005/Q4


55

Unit Summary

BIT300

Unit Summary You should now 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 system through 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

56


2005/Q4

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

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 .................... 67 Exercise 3: Master Data Distribution...................................... 69 Lesson: Using Change Pointers ............................................... 75 Lesson: Data Filtering and Reducing the Scope of Data ................... 80 Exercise 4: Using a Reduced Message Type ........................... 93

2005/Q4


57

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.


Describe the configuration of an ALE scenario for distributing material master data Distribute material masters

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

58


2005/Q4

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

2005/Q4


59


BIT300

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

60


2005/Q4

BIT300


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

2005/Q4


61


BIT300

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.

62


2005/Q4

BIT300


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)

2005/Q4


63


BIT300

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

64


2005/Q4

BIT300


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.

2005/Q4


65


BIT300

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.

66


2005/Q4

BIT300


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. Continued on next page

2005/Q4


67


5.

BIT300

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

68

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) suitable inbound 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.


2005/Q4

BIT300


Exercise 3: Master Data Distribution Exercise Objectives After completing this exercise, you will be able to: • 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


2005/Q4


69


BIT300

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.

70

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.


2005/Q4

BIT300


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

2.

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.

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?


2005/Q4


71


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

4.

BIT300

.

One master IDoc and one communication IDoc have been created.

Send your material again without specifying a target system. How many master IDocs and communication IDocs were created? Master IDocs

1

Communication IDocs

2

a)


b)

Re-enter your material MATALE-## and the message type MATMAS but leave the Logical System field blank. Click on Execute .

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.


72


2005/Q4

BIT300


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.

2005/Q4

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.

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)


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.


73


BIT300

Lesson Summary You should now be able to: • Describe the configuration of an ALE scenario for distributing material master data • Distribute material masters

74


2005/Q4

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.


Explain the use of change pointers in master data distribution and set them 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

2005/Q4


75


BIT300

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 system also 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 change documents and the corresponding message type.

76


2005/Q4

BIT300


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

2005/Q4


77


BIT300

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.

78


2005/Q4

BIT300


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

2005/Q4


79


BIT300

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.


Describe different methods for filtering data in IDoc processing Create a reduced message type and use it in the distribution process

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

80


2005/Q4

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

2005/Q4


81


BIT300

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.

82


2005/Q4

BIT300


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

2005/Q4


83


BIT300

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

84


2005/Q4

BIT300


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 the condition 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).

2005/Q4


85


BIT300

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

86


2005/Q4

BIT300


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

•

•

2005/Q4

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


87


BIT300

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

88


2005/Q4

BIT300


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.

2005/Q4


89


BIT300

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.

90


2005/Q4

BIT300


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.

2005/Q4


91


92


BIT300

2005/Q4

BIT300


Exercise 4: Using a Reduced Message Type Exercise Objectives After completing this exercise, you will be able to: • 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.


2005/Q4


93


BIT300

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 logical system. 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-## material and 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?

94


2005/Q4

BIT300


Solution 4: Using a Reduced Message Type 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


2005/Q4


95


BIT300

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.

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.

.

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.


96


2005/Q4

BIT300


3.

4.

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

Select IDoc Interface / Application Link Enabling (ALE) → Modelling 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.

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.


2005/Q4


97


5.

BIT300

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.

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.

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


98


2005/Q4

BIT300


7.

8.

Change some values in your material MATALE-## in the CORE logical system. Make sure you change the volume and the volume unit. a)

Select Logistics → Materials Management → Material Master → 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.

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##. a)


b)

Enter the material master MATALE-##, message type ZMATMAS## and the logical system PRODUCTION and then select Execute .

c)


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

.


2005/Q4


99


9.

BIT300

Display the material MATALE-## in the PRODUCTION system. Which changes have been transferred from the CORE system? a)

Select Logistics → Materials Management → Material Master → 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?

100

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## in the PRODUCTION system: the Old material number field contains the changes you made, the Date of last change and Last changed by fields contain “/”.


2005/Q4

BIT300


Lesson Summary You should now be able to: • Describe different methods for filtering data in IDoc processing • Create a reduced message type and use it in the distribution process

2005/Q4


101

Unit Summary

BIT300

Unit Summary You should now be able to: • 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

102


2005/Q4

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

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............................104 Exercise 5: Partner Profiles and Condition Record .................... 113 Lesson: Example: Purchase Order Processing ............................ 119 Exercise 6: Sending a Purchase Order to a Vendor ...................125 Exercise 7: Optional: ALE Scenario “Stock Transfer Between Distributed Systems” ......................................................129

2005/Q4


103

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.


Differentiate ALE and EDI Describe the basic functions of message control 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 respective recipient 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

104


2005/Q4

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.

2005/Q4


105


BIT300

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

106


2005/Q4

BIT300


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 created using 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 the company. 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.

2005/Q4


107


BIT300

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 the operating 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 to employees 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.

108


2005/Q4

BIT300


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

2005/Q4


109


BIT300

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 are dependent on one another. The illustration below shows the inner hierarchy of the condition elements using the example of message control for Purchasing:

110


2005/Q4

BIT300


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 access sequence (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).

2005/Q4


111


BIT300

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 and which 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.)

112


2005/Q4

BIT300


Exercise 5: Partner Profiles and Condition Record Exercise Objectives After completing this exercise, you will be able to: • 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 message in IDoc format by means of EDI. The IDoc should be generated immediately after a purchase order is created.


2005/Q4


113


4.

BIT300

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.

114


2005/Q4

BIT300


Solution 5: Partner Profiles and Condition Record 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. 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.

.

.


2005/Q4


115


2.

3.

BIT300

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.

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.


116


2005/Q4

BIT300


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.

2005/Q4

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


117


BIT300

Lesson Summary You should now be able to: • Differentiate ALE and EDI • Describe the basic functions of message control • Explain how message control is used to generate IDocs

118


2005/Q4

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


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

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.

2005/Q4


119


BIT300

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

120


2005/Q4

BIT300


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

2005/Q4


121


BIT300

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 IDoc Generation 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 from the application document (menu entry Goto → Messages or button Messages in the initial screen).

122


2005/Q4

BIT300


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.

2005/Q4


123


BIT300

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

124


2005/Q4

BIT300


Exercise 6: Sending a Purchase Order to a Vendor Exercise Objectives After completing this exercise, you will be able to: • 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.

2005/Q4


125


BIT300

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

2.

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.

Check the outbound processing of the IDoc in the purchase order. What status does the IDoc have? Also note the IDoc number. Status: ____


126


2005/Q4

BIT300


Number: ________________

3.

a)

Choose Logistics → Materials Management → Purchasing → 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).

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.

2005/Q4

a)

Choose Tools → ALE → ALE Administration → Monitoring → IDoc Display → Status Monitor.

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


127


128


BIT300

2005/Q4

BIT300


Exercise 7: Optional: ALE Scenario “Stock Transfer Between Distributed Systems” Exercise Objectives After completing this exercise, you will be able to: • 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 the company 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: ______________ Continued on next page

2005/Q4


129


BIT300

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.

130


2005/Q4

BIT300


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: _________________ a)

Choose Logistics → Materials Management → Purchasing → Purchase Order → Create → Vendor/Supplying Plant Known.

b)

Enter the vendor CORE, and on the Org.data tab page, on the document header 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.


2005/Q4


131


2.

3.

4.

BIT300

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


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.

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.

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.


132


2005/Q4

BIT300


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.

2005/Q4

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.


.

133


BIT300

Lesson Summary You should now be able to: • 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

134


2005/Q4

BIT300

Unit Summary

Unit Summary You should now be able to: • 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

2005/Q4


135

Unit Summary

136

BIT300


2005/Q4

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

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 .................................138 Lesson: The Usage of BAPIs in ALE.........................................145 Lesson: Example: Travel Expenses..........................................155 Exercise 8: Trip Cost Accounting with Two Systems ..................161 Exercise 9: ALE Scenario for Setting Up Travel Expenses ...........165

2005/Q4


137

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.


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

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-depth understanding of the underlying technology (business objects and options for accessing business objects).

138


2005/Q4

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.

2005/Q4


139


BIT300

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

140


2005/Q4

BIT300


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.

2005/Q4


141


BIT300

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.

142


2005/Q4

BIT300


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

2005/Q4


143


BIT300

Lesson Summary You should now be able to: • 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

144


2005/Q4

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.


Enter Customizing settings for synchronous BAPI calls Enter Customizing settings for asynchronous BAPI calls using the ALE 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.

2005/Q4


145


BIT300

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 calling up the BAPI function module in the target system.

146


2005/Q4

BIT300


Figure 87: RFC Destinations for Synchronous Method Calls

You can use the transaction BD97 to assign a standard destination for 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, the BAPI. 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”.

2005/Q4


147


BIT300

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

148


2005/Q4

BIT300


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

• •

•

•

2005/Q4

IDoc type: The IDoc type is the basis of the IDoc required for the asynchronous 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.


149


BIT300

Figure 92: Outbound Processing of an IDoc for a BAPI Call

The following steps are carried out in the application program: 1.

2.

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

150


2005/Q4

BIT300


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

2005/Q4


151


BIT300

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.

152


2005/Q4

BIT300


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.

2005/Q4


153


BIT300

Lesson Summary You should now be able to: • Enter Customizing settings for synchronous BAPI calls • Enter Customizing settings for asynchronous BAPI calls using the ALE interface

154


2005/Q4

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.


To describe the configuration of the ALE scenario “Transferring the accounting results of the travel expenses to Accounting”.

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.

2005/Q4


155


BIT300

Figure 97: Travel Expenses: Posting Procedure

The figure illustrates the posting procedure of the process. It comprises the following individual steps:

•

• •

•

•

156

Entering the trip costs: In the Travel Management, the employee enters the 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 Controlling determined 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.


2005/Q4

BIT300


•

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.

2005/Q4


157


BIT300

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.

158


2005/Q4

BIT300


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

2005/Q4


159


BIT300

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.

160


2005/Q4

BIT300


Exercise 8: Trip Cost Accounting with Two Systems Exercise Objectives After completing this exercise, you will be able to: • 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 the BAPIs required for the ALE scenario, must therefore be performed after this exercise.

2005/Q4

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.


161


BIT300

Solution 8: Trip Cost Accounting with Two Systems 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 the BAPIs required for the ALE scenario, must therefore be performed after this exercise. 1.

2.

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

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.

to call up the screen for entering the trip costs.

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.


162


2005/Q4

BIT300


3.

4.

5.

2005/Q4

Create a posting run with the data for your trip. a)

Choose Human Resources → Travel Management → Travel Expenses → 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.

Now transfer the settlement results to Accounting in the logical system CORE. a)

Choose Human Resources → Travel Management → Travel Expenses → Periodic Processing → Transfer to Accounting → Manage Posting Runs.

b)

Select Execute

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.

to display your posting run from step 3.

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


163


164


BIT300

2005/Q4

BIT300


Exercise 9: ALE Scenario for Setting Up Travel Expenses Exercise Objectives After completing this exercise, you will be able to: • 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 trips are 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


2005/Q4


165


3.

BIT300

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

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


166


2005/Q4

BIT300


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.

2005/Q4

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.


167


BIT300

Solution 9: ALE Scenario for Setting Up Travel Expenses 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.

2.

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

.

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.


168


2005/Q4

BIT300


BAPI

Message type

AcctngEmplyeeExpnses.Post

ACC_EMPLOYEE_EXP

AcctngEmplyeePaybles.Post

ACC_EMPLOYEE_PAY

AcctngEmplyeeRcvbles.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. a)

Call the transaction SALE and choose IDoc Interface / Application Link 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.


2005/Q4


169


2.

BIT300

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

3.

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.

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##. a)

Call the transaction SALE and choose IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → 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.


170


2005/Q4

BIT300


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, this could 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.


2005/Q4


171


3.

4.

BIT300

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

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


172


2005/Q4

BIT300


5.

2005/Q4

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 or Enter. field, enter your logical system CORE## and choose Find

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.


173


BIT300

Lesson Summary You should now be able to: • To describe the configuration of the ALE scenario “Transferring the accounting results of the travel expenses to Accounting”.

174


2005/Q4

BIT300

Unit Summary

Unit Summary You should now be able to: • 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”.

2005/Q4


175

Unit Summary

176

BIT300


2005/Q4

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

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 ..................185 Exercise 11: ALE Audit ....................................................187 Lesson: Error Analysis and Handling ........................................190 Procedure: Problem: The IDoc Was Not Created......................196 Procedure: 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 ......................................200 Procedure: Problem: The IDoc was Received by the Receiving System, but was not Posted ..............................................201

2005/Q4


177

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 ........223 Lesson: Archiving IDocs .......................................................228

178


2005/Q4

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.


Use the status monitor efficiently Set up and use the ALE audit

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

2005/Q4


179


BIT300

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

180


2005/Q4

BIT300


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

2005/Q4


181


BIT300

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.

182


2005/Q4

BIT300


Setting up the ALE Audit 1.

2.

3. 4.

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. 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. Distribute the changes message views again and generate the partner profiles in all the systems involved. Include the program RBDSTATE for sending the audit confirmations.

Figure 106: ALE Audit: Status Values

2005/Q4


183


BIT300

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

184


2005/Q4

BIT300


Exercise 10: Monitoring IDocs in the Status Monitor Exercise Objectives After completing this exercise, you will be able to: • 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.

2005/Q4

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.


185


BIT300

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.

2.

186

In the CORE system, check whether the PRODUCTION system is assigned an RFC destination for dialogs. a)

Call the transaction SALE and choose IDoc Interface / Application Link Enabling (ALE) → Communication → Determine RFC Destinations for Method Calls.

b)

In the menu of the transaction, choose Edit → Find. In the Search for or field, enter the logical system PRODUCTION and choose Find 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.

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


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.


2005/Q4

BIT300


Exercise 11: ALE Audit Exercise Objectives After completing this exercise, you will be able to: • 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##.

2005/Q4

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.


187


BIT300

Solution 11: ALE Audit Task: Test the ALE Audit using your Message Type ZMATMAS##. 1.

2.

188

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

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


2005/Q4

BIT300


Lesson Summary You should now be able to: • Use the status monitor efficiently • Set up and use the ALE audit

2005/Q4


189


BIT300

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.


Perform error analysis using the ALE status monitor Resolve errors in the IDoc processing

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 processing involves three obligatory and three optional status values:

190


2005/Q4

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

2005/Q4


191


BIT300

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: 26: 25: 29:

Error transferring data to port Syntax error in IDoc (outbound) Further processing despite syntax error (outbound) 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 type than 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.

192


2005/Q4

BIT300


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

• • • •

2005/Q4

50: 64: 62: 53:

IDoc added IDoc is ready for transfer to the application IDoc transferred to application Application document posted


193


BIT300

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

• • • • •

194

56: 60: 61: 65: 51:

Incorrect IDoc added Syntax error in IDoc (inbound) Further processing despite syntax error (inbound) Error in ALE service Application document not posted


2005/Q4

BIT300


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.

2005/Q4


195


BIT300

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


196


2005/Q4

BIT300


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 the details 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? Continued on next page

2005/Q4


197


BIT300

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.

198


2005/Q4

BIT300


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.

2005/Q4


199


BIT300

Problem: The IDoc was Successfully Sent, but it was not 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 influence other 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. You can 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.

200


2005/Q4

BIT300


Problem: The IDoc was Received by the Receiving System, 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): Continued on next page

2005/Q4


201


BIT300

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 and choosing 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).

202


2005/Q4

BIT300


Exercise 12: Error Analysis and Handling Exercise Objectives After completing this exercise, you will be able to: • 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 receiving system.


2005/Q4


203


4.

BIT300

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.


204


2005/Q4

BIT300


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.

2005/Q4

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.


205


BIT300

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.


206


2005/Q4

BIT300


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.

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)


d)

Enter your message type ZMATMAS## and choose Execute 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.

: The

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: __________ a)


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.

.


2005/Q4


207


4.

BIT300

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.


208


2005/Q4

BIT300


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

: The

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.


2005/Q4


209


2.

210

BIT300

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


.

2005/Q4

BIT300


Lesson Summary You should now be able to: • Perform error analysis using the ALE status monitor • Resolve errors in the IDoc processing

2005/Q4


211


BIT300

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

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

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 specific applications, 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.

212


2005/Q4

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, only after 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.

2005/Q4


213


BIT300

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

214


2005/Q4

BIT300


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

2005/Q4


215


• •

• • •

•

BIT300

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.

216


2005/Q4

BIT300


Figure 114: Process Codes for Errors in the Inbound IDoc

• • •

•

As in the outbound processing, the process code EDIM applies when it has not been possible to create an IDoc. EDII and EDIY correspond to the outbound process codes EDIO and EDIX. You can use the IDoc type TXTRAW01 to send messages of your choice in text format. This technique is used, for example, if an exception has occurred in the external system and the SAP system is to be informed of this exception. If it was not possible to read a status file of the external system, the process code EDIL becomes active. In the exception handling, the error message of the SAP system is displayed.

If errors occur while the application documents are being posted (for example, because Customizing settings are not synchronous), a different technique is used for the error handling. Instead of the relatively rigid reaction by means of process codes, the application uses the more flexible event concept. In the case of an exception, an event is triggered which can start 1 to n tasks and send corresponding work items. Note: The tasks supplied by SAP for errors during posting in the application usually have the name suffix “error” - for example, MATMAS_error or ORDERS_error. For IDocs created by BAPI calls, in the case of an error, the task IDOC_APPL_Er (TS20000051) provided by SAP is used. This task is also started by an event. All selected agents now receive the notification as a work item (as a concrete "instance" of the workflow task) in their integrated inbox. "Repairs", and therefore further processing of the work item with errors, are only possible from this inbox.

2005/Q4


217


BIT300

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

218


2005/Q4

BIT300


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 Structure In 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).

2005/Q4


219


BIT300

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.

220


2005/Q4

BIT300


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.

2005/Q4


221


BIT300

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 item found to the IDoc display.

222


2005/Q4

BIT300


Exercise 13: Processing an Incorrect IDoc from a Work Item Exercise Objectives After completing this exercise, you will be able to: • 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 the system 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##.

2005/Q4

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, and add the missing settings.

4.

Then try to start the processing of the IDoc again. What status does the IDoc have now?


223


BIT300

Solution 13: Processing an Incorrect IDoc from a Work Item 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 the system PRODUCTION. a)

Call the transaction SALE and choose IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → 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.


224


2005/Q4

BIT300


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

: Your


2005/Q4


225


3.

4.

226

BIT300

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, and add 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.

Then try to start the processing of the IDoc again. What status does the IDoc 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 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).


: The work item

2005/Q4

BIT300


Lesson Summary You should now be able to: • 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

2005/Q4


227


BIT300

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.


Describe the IDoc archiving procedure Set the archivable statuses in the system

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 corresponding database entries are deleted.

Figure 119: Archiving IDocs - First Step: Writing Archive Files

228


2005/Q4

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 (transaction SARI). 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.

2005/Q4


229


BIT300

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

230


2005/Q4

BIT300


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

2005/Q4


231


BIT300

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

232


2005/Q4

BIT300


Lesson Summary You should now be able to: • Describe the IDoc archiving procedure • Set the archivable statuses in the system

2005/Q4


233

Unit Summary

BIT300

Unit Summary You should now be able to: • 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

234


2005/Q4

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

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 .........................................236 Lesson: IDoc Recovery Following Database Error .........................241

2005/Q4


235

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.


Explain the correct procedure for changing logical system names

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

236


2005/Q4

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 and data inconsistency.

2005/Q4


237

Unit 6: Appendix

BIT300

Figure 126: What is the Problem?

Figure 127: How Are Logical System Names Changed?

238


2005/Q4

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

2005/Q4


239

Unit 6: Appendix

BIT300

Lesson Summary You should now be able to: • Explain the correct procedure for changing logical system names

240


2005/Q4

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.


Describe the IDoc recovery procedure and the settings required for this 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: • •

2005/Q4

Transaction BDRC for determining the recovery objects Transaction BDRL for processing the recovery objects


241

Unit 6: Appendix

BIT300

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.

242


2005/Q4

BIT300


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.

2005/Q4


243

Unit 6: Appendix

BIT300

Figure 132: IDoc Recovery - Procedure III

244


2005/Q4

BIT300


Lesson Summary You should now be able to: • Describe the IDoc recovery procedure and the settings required for this function

2005/Q4


245

Unit Summary

BIT300

Unit Summary You should now be able to: • Explain the correct procedure for changing logical system names • Describe the IDoc recovery procedure and the settings required for this function

246


2005/Q4

BIT300

Course Summary

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

2005/Q4

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


247

Course Summary

248

BIT300


2005/Q4

Index A

F

Access sequence, 111 Adapter, 51 ALE Customizing object, 47 ALE layer, 37 Archiving object, 229

Field value conversion, 49 File port, 39 Filter group, 84 Filter object, 82

B

Global company code, 195

BAPI, 139, 145 BAPI Explorer, 145 Basic type, 17, 30, 80, 82, 88 Business object, 138 Business Object Repository, 141 Business object type, 138

I IDoc, 17, 30, 45, 148, 159, 179 IDoc basic type, 119, 192 IDoc status, 35, 190

L

C

Logical system, 9, 16, 60, 121

Change documents, 76 Change pointers, 76, 88 Classification, 85 Communication layer, 38 Communications IDoc, 33 Condition table, 111 Condition type, 110 Control record, 33 Cross-system company code, 49 Customizing, 45

M

D Data record, 33 Distribution group, 47 Distribution model, 60, 121, 146, 158 Distribution Model, 18

E EDI converter, 105 Event, 217

2005/Q4

G

Master IDoc, 32, 123 Message, 108 Message category, 148 Message control, 108, 119 Message type, 10, 17, 30, 60, 76, 80, 86, 109, 111 reduced, 86 Model view, 11, 18, 60

O Organizational management, 219 Output determination procedure, 111

P Partner function, 107 Partner profile, 22, 34, 61, 106, 120, 150, 159, 191, 218 Partner type, 106 Port, 20, 38, 106, 120, 191


249

Index

BIT300

Port type, 106 Process code, 22, 40, 64, 121, 192, 212 Processing time, 112

R

250

Segment, 31, 80 Segment field, 31 Segment filtering, 80 Segment type, 31, 87 Status record, 33

Remote Function Call (RFC), 19, 21 RFC destination, 19, 61, 146, 158

T

S

W

SAP Solution Manager, 48 SAP Workflow, 212

Work Item, 192, 214


Transmission medium, 120 tRFC port, 39 tRFC queue, 39

2005/Q4

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

2005/Q4


251

Bit300 en Col54 Fv Part a4

Recommend Documents