ALE Fundamentals

BIT300Integration Technology ALE

SAP NetWeaver

Date

Training Center

Instructors

Education Website

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

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

Copyright

Copyright © 2006 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose withoutthe express permission of SAP AG. Additionally this publication and its contents are providedsolely for your use, this publication and its contents may not be rented, transferred or sold withoutthe express permission of SAP AG. The information contained herein may be changed withoutprior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Trademarks

� Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® areregistered 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 trademarksof Citrix Systems, Inc.

� HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, WorldWide 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.comare trademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. All other products mentioned are trademarks or registered trademarks oftheir respective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLYDISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDINGWITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR APARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE,INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTSCONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANYKIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOSTPROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDEDSOFTWARE COMPONENTS.

g200672943835

About This HandbookThis handbook is intended to complement the instructor-led presentation of thiscourse, and serve as a source of reference. It is not suitable for self-study.

Typographic ConventionsAmerican English is the standard used in this handbook. The followingtypographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude field names, screen titles, pushbuttons as wellas menu names, paths, and options.

Also used for cross-references to other documentationboth internal (in this documentation) and external (inother locations, such as SAPNet).

Example text Emphasized words or phrases in body text, titles ofgraphics, and tables

EXAMPLE TEXT Names of elements in the system. These includereport names, program names, transaction codes, tablenames, and individual key words of a programminglanguage, when surrounded by body text, for exampleSELECT and INCLUDE.

Example text Screen output. This includes file and directory namesand their paths, messages, names of variables andparameters, and passages of the source text of aprogram.

Example text Exact user entry. These are words and characters thatyou enter in the system exactly as they appear in thedocumentation.

<Example text> Variable user entry. Pointed brackets indicate that youreplace these words and characters with appropriateentries.

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

About This Handbook BIT300

Icons in Body TextThe 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�spresentation.

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

ContentsCourse Overview ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Course Goals .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiCourse Objectives ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Unit 1: ALE Fundamentals..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Cross-System Business Processes .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3The Distribution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Basic ALE Customizing ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Intermediate Documents .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Synchronizing Customizing.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44ALE and the SAP NetWeaver Exchange Infrastructure.. . . . . . . . . 51

Unit 2: Master Data Distribution ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Example: Material Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Using Change Pointers.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Data Filtering and Reducing the Scope of Data .. . . . . . . . . . . . . . . . . 80

Unit 3: Distributing Transaction Data: Message Control .... . . 103Message Control and IDoc Generation .. . . . . . . . . . . . . . . . . . . . . . . . . .104Example: Purchase Order Processing.. . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Unit 4: Distributing Transaction Data: BAPIs ..... . . . . . . . . . . . . . . . 137Business Object Types and BAPIs ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138The Usage of BAPIs in ALE ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145Example: Travel Expenses .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

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

IDoc Status Management .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179Error Analysis and Handling ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190SAP Workflow in ALE Environment .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212Archiving IDocs.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228

Unit 6: Appendix ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Renaming Logical Systems.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236IDoc Recovery Following Database Error . . . . . . . . . . . . . . . . . . . . . . . .241

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

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

Contents BIT300

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

Course OverviewThis course explains how to use Application Link Enabling (ALE) usingpredefined example scenarios. You will learn how to configure ALE scenariosand how to control data exchange between systems.

Target AudienceThis course is intended for the following audiences:

� Consultants� Project team members

Course PrerequisitesRequired Knowledge

� SAPTEC (Fundamentals of SAP Web AS)

Recommended Knowledge

� BIT100 (SAP NetWeaver Process Integration)

Course GoalsThis course will prepare you to:

� Create a system landscape for using different ALE scenarios (distributingmaster data and transaction data)

� Control data exchange between systems in a distributed system landscape� Correctly assess the capabilities and limitations of ALE

Course ObjectivesAfter completing this course, you will be able to:

� Set up a distribution model for exchanging master and transaction databetween systems

� Create partner profiles for data exchange in enterprises and for electroniccommunication with business partners

� Determine the scope of data to be distributed, depending on its type andrecipient

� Monitor data exchange between systems

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

Course Overview BIT300

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

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

Unit 1ALE Fundamentals

Unit OverviewIn this unit, you will first learn about the possible applications of ALE inenterprises. You will then find out which basic settings you need to make inCustomizing and applications to use ALE.

Unit ObjectivesAfter 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 ContentsLesson: Cross-System Business Processes ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Lesson: The Distribution Model .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

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

Unit 1: ALE Fundamentals BIT300

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

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

Lesson: Synchronizing Customizing .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Lesson: ALE and the SAP NetWeaver Exchange Infrastructure .. . . . . . . . . 51

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

BIT300 Lesson: Cross-System Business Processes

Lesson: Cross-System Business Processes

Lesson OverviewThis lesson introduces examples of the application and use of ALE.

Lesson ObjectivesAfter completing this lesson, you will be able to:

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

Business ExampleGlobally-active enterprises usually structure their business using multiple clientsin an SAP system, often also using multiple SAP systems. Frequently, these arejoined by systems for specific applications from other providers. You need toclarify how the parties involved in this kind of system group exchange data witheach other.

Enterprise Structure and Business ProcessesAn enterprise's head office, subsidiaries and sales and distribution branches areoften technically separate systems. Each subsystem communicates not only withthe other members of the system group but also with business partners, such ascustomers, vendors, banks and public authorities.

Figure 1: The Enterprise as a Whole and External Parties

In the example illustrated above, the master data for the overall enterprise networkis created and changed in the head office only. New master data and changesto existing data are regularly sent to the downstream systems of the sales anddistribution branch and production. The central purchasing department orders



from vendors, the sales and distribution branch receives orders from customersand sends these to production to be manufactured. Communication is to beelectronic throughout all the processes.

Figure 2: Example: Sales Order Processing

The customer sends a purchase order to the sales and distribution branch. The SDbranch'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 productionsystem, an order is generated from this data. Depending on the agreementsbetween the two enterprise areas, the production system confirms the order fromthe SD branch and announces delivery of the ordered material amounts. The SDbranch can now confirm the customer's order in turn and notify the customer of aconsignment of goods. After the goods have been delivered, production invoicessales and distribution for them. SD then, in turn, presents the customer with aninvoice for the delivered goods.

Preparatory Steps for Mapping Cross-System Business Processes

� Analysis of the enterprise's organizational structure and the mapping of itstechnical systems: which SAP systems or clients make up the enterprise'ssystem landscape? Are there any non-SAP systems involved?

� Listing the software products installed in each participating system� Describing the business processes that need to be mapped in the system

landscape� Breaking these processes down into individual steps� Distributing the individual steps of the overall process to the participating

systems or business partners



Internal Communication: Distributing Master Data withALEALE 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 systemsin the enterprise network. The master data is distributed from this maintenancesystem to the downstream systems; the data records are forwarded in electronicform to each of the recipients. A typical example of this is centralized masterdata administration.

Figure 3: Example: Centralized Material Master Administration

In the scenario illustrated above, all the material masters are created in thehead office and distributed from there to the downstream systems of salesand distribution and production. However, sales and distribution should onlyreceive the master records for finished products, whereas production shouldreceive material master data for both finished products and raw materials. Whenconfiguring the ALE scenario, it is therefore important to pay attention to thedistribution hierarchy and also to take into account the fact that not every recipientreceives all the data. In a different scenario, the departments in the receivingsystem 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 thereneeds to be a guarantee that values changed locally cannot be overwritten if thedata records are transferred again.

Basic Questions when Planning Centralized Master Data Distribution

� Which master data is maintained in which system?� To which systems must the master data then be distributed?� How often is the data distributed, and when?� Do all the recipients receive all the data in its entirety?



Communication with External Parties: Purchase OrderHandling with EDIYou want to communicate electronically not only within the enterprise, but alsowith your business partners. In this way, the data from an order created in yourown system can be electronically transferred to a vendor, who, in turn, sends anorder confirmation, shipping confirmation and finally an invoice.

Figure 4: Example: Purchase Order Processing

Generally, data exchange with external parties (that is, business partners, banks, orgovernment agencies) is carried out using Electronic Data Interchange (EDI),not ALE. An electronic document is sent in an SAP-specific format from anSAP system to an EDI subsystem, called a converter. The subsystem convertsthis document to an EDI document, and sends it to the supplier. The unit on�Distributing Transaction Data: Message Control� contains more informationabout the differences between ALE and EDI.

Separating Systems for Legal Reasons: HumanResourcesOften, to comply with data protection legislation, a separate system is set upfor human resources (HR). In this system, HR master data is managed, payrollaccounting is processed and other sensitive data is retained. Unauthorized access



to this data is supposed to be prevented (or at least made difficult) by technicallyseparating the HR system from the other systems in the enterprise network. Otherpossible 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, thislatter also requires HR master data for paying salaries and wages or reimbursingtravel costs. Cost centers and other account assignment objects are also requiredin 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 expensesare transferred to head office from the HR system for posting in Accounting.



Lesson Summary

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


BIT300 Lesson: The Distribution Model

Lesson: The Distribution Model

Lesson OverviewThe distribution model is the core component of ALE, as it determines whichsender transfers which data to which recipients. It is made up of assignments oflogical system names and message types. This lesson explains all three terms andthe function each one plays in ALE scenarios.


� Explain the terms �logical system� or �logical system name�, �messagetype� and �distribution model�

� Explain the function of the distribution model

Business ExampleYou have analyzed your business processes and the existing system landscape.You want to familiarize yourself with the configuration of an ALE scenario, usingthe example of centralized master data administration as a basis.

Logical System NameOnce you have determined which parts of the enterprise should use ALE toexchange data with each other, define logical system names for every clientinvolved in the system group and, if applicable, for all external systems (if this hasnot 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 anon-SAP system in the system landscape. If the name refers to a client, assignthe name to the client in the next step. To guarantee that the logical system nameis unique and to simplify the assignment, SAP recommends using the naming



convention <System name>CLNT<Client key>. In the example illustrated below,the SAP system has the key G23. Clients 800, 810 and 811 are used. Thus, forexample, client 800 receives the logical system name G23CLNT800.

Note: The terms �logical system name� and �logical system� are usedinterchangeably.

Figure 7: Logical System Names

In certain cases, it could be useful not to use SAP's recommended conventionfor logical system names. The training clients for this course have �descriptive�names: the logical system name for head office is CORE, sales and distribution iscalled SALES and production is PRODUCTION. Naming the systems in thisway is an alternative to the SAP convention if the assignment of clients to logicalsystem names is frequently changed.

Caution: Changing the logical system name is a serious intervention, asthis name is included in numerous application tables (see lesson on �BasicALE Customizing� and appendix �Renaming Logical Systems�).

Message TypeWhen configuring an ALE scenario, in addition to assigning logical systemnames, 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, youneed to name the type of data (material masters) with what is known as amessagetype (MATMAS). Message types are therefore essentially keys, comparable tological system names, which indicate data that can be exchanged between systemsin ALE or EDI scenarios.



Figure 8: Logical Systems and Message Types

Both elements � the logical system name and message type � are linked to eachother in the distribution model, in order to determine which sender sends whichdata to which recipient. In the example illustrated above, the head office (CORElogical system) distributes material masters (MATMAS message type) to sales anddistribution (SALES logical system) and production (PRODUCTION logicalsystem).

Note: In some ALE scenarios, �Business Application ProgrammingInterfaces� (BAPIs) are used instead of message types. You will learnabout how to use BAPIs in ALE in the unit: �Distributing TransactionData: BAPIs�.

Distribution Model and Model ViewsIf you want data to be sent from one logical system to another, you specify in thedistribution model which message type is to be sent from which logical systemto which logical system(s). The distribution model bundles all the assignmentsof senders, recipients and data to be sent. If you set up a new ALE scenario, younormally create a new model view for this scenario in the distribution model ofone of systems involved. In this model view, you name the sender and recipientusing their logical system names and then add the message type describing thetype of data that is to be sent.



Figure 9: Model View in a Distribution Model

You then need to distribute the newly created model view, in other words, makeit known to the other systems involved. In the example shown above, the modelview �master data� was created in the CORE logical system. However, this alsoaffects the logical systems SALES and PRODUCTION. They receive copies ofthe new model view. You can distribute a model view to the partner systems usingALE, subject to certain conditions (explained below). It is, however, also possibleto transport a model view to other systems.

Figure 10: Distributing Model Views

Note: To ensure that data remains consistent, you should maintain thedistribution model centrally in one logical system and then distribute ortransport its views to the other affected logical systems.



You can find the distribution model in the IMG via SAP NetWeaver→ SAP WebApplication Server→ IDoc Interface / Application Link Enabling (ALE)→Modelling and Implementing Business Processes→ Maintain Distribution Modeland Distribute Views.



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


BIT300 Lesson: Basic ALE Customizing

Lesson: Basic ALE Customizing

Lesson OverviewThis lesson introduces basic ALE Customizing. In addition to this, you will learnwhere to find information about the ALE scenarios provided by SAP.


� 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 ExampleYou want to use ALE to exchange data between two SAP systems. You thereforewant to get an overview of the Customizing settings needed to set up ALEscenarios. You also want to check if there is a standard ALE scenario that wouldbe suited to your purposes.

ALE Customizing in the Implementation GuideYou can find all the basic Customizing settings in an SAP system's ImplementationGuide (IMG) under SAP NetWeaver→ SAP Web Application Server→ IDocInterface / Application Link Enabling (ALE). You can also call this section of theIMG directly by calling transaction SALE.

Figure 11: Transaction SALE



In the area Modelling and Implementing Business Processes, you will findextensive documentation about ALE scenarios, which you can use in manydifferent applications (→ Configure Predefined ALE Business Processes). If, forexample, you are interested in possible uses of ALE in human resources, go toModelling and Implementing Business Processes→ Configure Predefined ALEBusiness Processes→ Human Resources. Depending on the application, youwill find, in addition to a description of the scenario and the substeps needed toconfigure it, supporting functions, such as �auto-Customizing� or a program forchecking the completeness and internal consistency of your settings.

Defining Logical System Names and Assigning themto ClientsEach system in the system landscape must have a logical system name. Thisname uniquely identifies the logical system in the system landscape. You can thenassign this name to the client of an SAP system.

Figure 12: Defining Logical Systems

You can define logical system names in Customizing. In the SAP ReferenceIMG, choose SAP NetWeaver → SAP Web Application Server → IDocInterface/Application Link Enabling (ALE)→ Logical Systems→ Define LogicalSystem.

Hint: You can also call the table of logical system names directly, usingtransaction code BD54.



You can find the assignment of logical system names to clients in the IMG, viaSAP NetWeaver→ SAP Web Application Server→ IDoc Interface/ApplicationLink 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 TypesIn ALE, message types indicate the data that is to be exchanged between eachof two systems. MATMAS, for example, represents material records. Thematerial master data to be distributed is transported in an electronic intermediatedocument (IDoc) from the sender system to the recipient system. This IDoccontains the data from the master record in an SAP-specific format. The structureof the document is determined in a basic type. The basic type defines theformatting structure of the data record that is to be sent. Generally, the nameof the IDoc basic type is the same as the name of the message type but with aversion number added to it. The current version of the basic type for message typeMATMAS, 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'srelease 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 anoverview 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 thelesson on �Intermediate Documents�.



Creating Model Views in the Distribution ModelIn the distribution model of a logical system, you define for each of your ALEscenarios 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 toSAP NetWeaver→ SAP Web Application Server→ IDoc Interface / ApplicationLink Enabling (ALE)→ Modelling and Implementing Business Processes→Maintain Distribution Model and Distribute Views or call the distribution modeldirectly 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 therecipient and a message type. You can assign logical systems for different messagetypes as well as the sender and recipient roles in the same model view.



Figure 15: Distribution Model

To ensure the consistency of the data across the system landscape and beyond, it isadvisable to maintain the different views of a distribution model in one centralsystem, and distribute them or transport them to the partner systems (see below).

RFC Destinations and PortsIn ALE scenarios, the systems involved exchange data via Remote FunctionCalls (RFC). From one SAP system, an RFC calls a function module in anotherSAP system. RFCs make it possible to exchange data between different SAPsystems or between one SAP system and a non-SAP system. In non-SAP systems,specially-programmed functions are called instead of function modules; theinterface of these functions simulates a function module.



Figure 16: Defining RFC Destinations

For your ALE scenarios, you create RFC destinations for all the partner systems ineach system involved. To do this, select in the ALE Customizing IDoc Interface /Application Link Enabling (ALE)→ Communication→ Create RFC Connectionsor use transaction SM59. In the RFC destinations, specify a target host, IPaddresses, and (if applicable) the system number and user and logon data for�remote login� in the target system. Thus the RFC destination contains all thetechnical information that the calling system needs to call the partner from withinthe network.

Hint: If you give the RFC destination the same name as the logical targetsystem, you can have the system carry out certain settings automaticallylater on.

In order to use ALE scenarios later on, the RFC must be assigned to a port. Thesender uses the port to determine the communication channel to the recipient. Youcan create ports manually or � if the logical target system and the RFC destinationhave the same name � have the sender system create them.

Note: There are different types of port in SAP systems. ALE always usesRFC ports. In EDI scenarios, you can also use file ports in addition toRFC ports (see lesson on �Intermediate Documents�).



Transferring IDocs Using tRFCTo ensure that RFC functions can be executed reliably, securely, and independentlyof 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 isonly executed once in the RFC server system.

In transactional RFC calls, the data that belongs to an RFC function must be savedtemporarily in the SAP database in the RFC client system. Once the processingis complete, this must be confirmed to the calling ABAP program. The tRFCcomponent 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 thetRFC interface is implemented in such a way that the client or server programsmust perform a number of administration functions on the RFC API basis toensure that the function module is executed only once.

If a connection error occurs during a synchronous RFC, the client repeats thecall without knowing whether the processing has already taken place. The tRFCsolves this problem as tRFC calls can be transferred even if the target system isnot available. In these cases, the data is saved locally in the sender system andtransmitted later. In SAP R/3 or SAP ECC, automatic job scheduling is used forthis purpose. The job starts the corresponding function module(s) in the targetsystem at a later time.

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



In the SAP system, you can set tRFC parameters for the relevant connection intable RFCDES (for connection types T, 3, I) (SM59):

� Suppress batch job in the event of communication errors (manual start withtransaction SM58 required)

� Number of connection attempts� Interval in minutes between repeated attempts to transfer data

Partner ProfilesIn ALE scenarios, application programs check the system's distribution modelwhen they are called, in order to identify the recipient of each message preparedin IDoc format. ALE scenarios require partner profiles for every combinationof recipient system and message type. These profiles are also necessary forprocessing inbound IDocs. There is always an outbound and an inbound partnerprofile 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 typefrom the outbound partner profile, so that it can create an IDoc with the data thatis to be distributed. On the other, the sender system uses the port assigned to thepartner profile to find the RFC destination that enables it to call the recipientsystem. In addition to this, the partner profile determines whether the IDoc is sentimmediately or not until later.

From the inbound partner profile, the recipient system reads how and when thedata from the inbound IDoc is to be transferred to the relevant application. As arule, what is known as a process code is used to find a function module for theinbound processing of the IDoc.



For a model view to be distributed to all the partner systems, the sender systemmust contain outbound partner profiles for message type SYNCH for all theaffected recipient systems. This message type is used only for determining theRFC destination for the target system. If the name of the logical target system andits RFC destination are the same, the sender system can automatically create a portwith the appropriate RFC destination and generate the partner profiles for themessage types of a model view. The authorization object for distributing modelviews is B_ALE_MODL.

Note: The lesson on �Intermediate Documents� explains how to createand change ports and partner profiles.



Exercise 1: Basic ALE Customizing

Exercise ObjectivesAfter 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 ExampleYou want to use ALE to exchange data between two SAP systems. You thereforewant to get an overview of the Customizing settings needed to set up ALEscenarios. You also want to check if there is a standard ALE scenario that wouldbe suited to your purposes.

Task:First, look in the IMG documentation to see if there are any ALE scenarios formaster data distribution between SAP systems. Next, check the assignment of thelogical system names CORE, SALES and PRODUCTION to the three trainingclients mentioned by your instructor. Then take a look at the distribution modelfor the CORE logical system.

1. Search in the IMG documentation for ALE scenarios for master datadistribution. To do this, use the IMG section IDoc Interface / ApplicationLink Enabling (ALE) (transaction SALE).

2. In one of the three clients for the mySAP ERP logistics and accountingsystem, check the assignment of the logical system names to the three clients.Make a note of the assignment:

Logical system ClientCORESALESPRODUCTION

3. In the distribution model for the CORE system, select all the model viewscontaining message typeMATMAS.

Hint: Use the Filter model display button.

Continued on next page



4. From the distribution model, display the CORE system's partner profiles forthe SALES and PRODUCTION systems. Check the detail settings for theMATMAS message type.

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



Solution 1: Basic ALE CustomizingTask:First, look in the IMG documentation to see if there are any ALE scenarios formaster data distribution between SAP systems. Next, check the assignment of thelogical system names CORE, SALES and PRODUCTION to the three trainingclients mentioned by your instructor. Then take a look at the distribution modelfor the CORE logical system.

1. Search in the IMG documentation for ALE scenarios for master datadistribution. To do this, use the IMG section IDoc Interface / ApplicationLink Enabling (ALE) (transaction SALE).

a) Select IDoc Interface / Application Link Enabling (ALE)→ Modellingand Implementing Business Processes→ Configure Predefined ALEBusiness Processes→ Logistics→ Master Data Distribution.

b) You will find IMG activities for setting up various master datadistribution scenarios.

2. In one of the three clients for the mySAP ERP logistics and accountingsystem, check the assignment of the logical system names to the three clients.Make a note of the assignment:

Logical system ClientCORESALESPRODUCTION

a) Choose IDoc Interface Application Link Enabling (ALE)→ BasicSettings→ Logical Systems→ Assign Logical System to Client.

b) One by one, select the table entries for the three training clients andclick Details for each one: in the Logical system field, you will seethe logical system name assigned to the client in question (CORE,SALES or PRODUCTION).




3. In the distribution model for the CORE system, select all the model viewscontaining message type MATMAS.

Hint: Use the Filter model display button.

a) Select IDoc Interface / Application Link Enabling (ALE)→ Modellingand Implementing Business Processes→ Maintain Distribution Modeland Distribute Views.

b) Click on the Filter model displays button, enter MATMAS in theMessage Type field and select Execute : the system will only displaymodel views containing message typeMATMAS.

4. From the distribution model, display the CORE system's partner profiles forthe SALES and PRODUCTION systems. Check the detail settings for theMATMAS message type.

a) In the distribution model's menu, select Environment→ Changepartner profile.

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

c) In the outbound parameters, select the entry for message typeMATMAS and click on DetailScreenOutb.Parameter : the SALESport and theMATMAS05 basic type are assigned here. The IDocsshould be sent immediately.

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

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

b) In the menu, select Environment→ Change partner profile, open thefolder for partner type LS and select the CORE partner.

c) Select the inbound parameters for the entry for message typeMATMASand click on DetailScreenInboundParameter : process codeMATMis assigned here. The IDocs should be processed immediately.



Lesson Summary

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

where applicable� 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



Lesson: Intermediate Documents

Lesson OverviewIn ALE scenarios, the systems involved exchange data in the form of intermediatedocuments (IDocs). This lesson deals with the structure of IDocs, presents variouspossible ways of generating IDocs and gives you an overview of the wholeprocess, from IDoc creation in the sender system, through to the processing of thedata in the recipient system.


� 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 ExampleYou want to use ALE to exchange data between two SAP systems and, by doingso, find out more about the technical implementation of ALE scenarios.

Structure of an IDoc: The Basic TypeIn ALE scenarios, data sent between two SAP systems or between SAP systemsand 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 enhancedfor 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: eachbasic 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 partnerprofiles for sender and recipient, the appropriate basic type is assigned toone message type (see the lesson on �Basic ALE Customizing�).

The example illustrated below shows a section from the structure of the basictype MATMAS05.


BIT300 Lesson: Intermediate Documents

Figure 19: The Basic Type

The basic type structures the formatting of the application data that is to be sent.Among other things, it specifies which data is stored in which location (rowand offset). It also determines the order in which application data belongs to amessage. An IDoc's data is organized in rows. The rows make up the segments ofan IDoc, which are, in turn, composed of segment fields. The row structure of anIDoc segment is determined by a segment type. For every segment field, the fieldname is stored along with the technical properties and semantics of the field. IDocsegments can be hierarchically related to one another.

An IDoc does not have to contain all the segments of its segment type, and asegment type can have more than one segment. Whether an IDoc must contain aparticular segment, and how many segments are permitted for a segment type, isdetermined in the IDoc type.

Note: For an overview of the segment structure of a basic type, seetransaction WE30 (IDoc Type Development).

The structure of the basic types provided by SAP is documented in detail in SAPR/3 and mySAP ERM. To call this documentation, go to Tools→ ALE→ ALEAdministration→ Services→ Documentation→ IDoc Types and Segments orcall transaction WE60.

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

� IDoc type attributes: information, such as the first release of the IDoc type.� Segment type attributes: this includes the information about whether a

segment is �required� or �optional� and the minimum or maximum numberof segments allowed for a segment type.

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



In addition to this, the documentation generally contains information aboutearmarking a segment field for organizational or business needs.

Note: The basic types provided by SAP can be enhanced to suit thecustomer's needs. The BIT350 training course deals with enhancing IDocbasic types (ALE enhancements).

The Master IDocThe application programs that you use in ALE scenarios always begin bygenerating an internal table based on the IDoc basic type and using an ABAPprogram; this table is called amaster IDoc. The application data is formatted lineby line according to the basic type and then inserted in this internal table. Aninternal table is a data object in an ABAP program that exists only during theruntime 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 metainformation for the line, and the actual data part. The most important informationin the control part is the name of the segment type that describes the structure ofthe data part.

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

MANDT ClientDOCNUM Number of the IDocSEGNUM Consecutive number (line number in internal table)



SEGNAM Name of the segment typePSGNUM Line number of the parent segmentHLEVEL Hierarchy level

The data part consists of the following fields:

DTINT2 Overall length of data partSDATA 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 structuretype EDIDD.

The Communications IDocLater in the application program run, the system uses the data from the masterIDoc to generate a communications IDoc, an intermediate document thatis saved to the database and then sent. When the system or documentationrefers to an �IDoc�, they are generally referring to this communications IDoc.Every communications IDoc consists of exactly one control record and multipledata records and status records.

Figure 21: Structure of a Communication IDoc



The important part of the control record is the IDoc number, which is assignedinternally in the system. This number is unique within a logical system. You definethe value range in each system using a number range interval. The control recordalso contains the key fields of the partner profiles, and the last processing status.

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

The status records contain the processing steps of the IDoc. They log the stationsthat the IDoc has run through from when it was created to when it was sent; thishelps you to monitor data distribution between systems.

Creating IDocsApplication programs create IDocs in different ways. The figure below coversthe four basic forms of IDoc creation:



Figure 22: How is an IDoc Created?

� Dedicated transactions: the preconfigured ALE scenarios for centralizedmaster data administration use application transactions that were specificallyprogrammed for creating IDocs. These transactions are brought together inthe umbrella term �Shared Master Data� (SMD).

� Message control: some logistical applications in SAP R/3 and mySAP ERMuse message control to output the data from their documents. Formatting thedocument data in IDoc format is one of the message output options.

� Application programs: some application programs generate IDocs directlyby filling an internal table in IDoc format and further processing it.

� Business Application Programming Interfaces (BAPIs): the applicationprogram uses a BAPI with an ALE interface.

Note: In later units, you will become familiar with examples of IDocgeneration using SMD, message control and BAPIs. In each lesson in thisunit, you will also learn about how you can use these instruments foryour ALE scenarios.

Exchanging Data with IDocs: Overview of the ProcessData exchange using IDocs begins in the sender system when an intermediatedocument is created in IDoc format and ends when the data transported by theIDoc is posted in an application in the target system. In the process, certain stationsare processed, which the sender and target systems each mark with status values.



Figure 23: The IDoc's Path and Status Values

� Regardless of how the IDoc was created, it is first saved to the sendersystem's database (status value 01).

� If all the information required for sending has been obtained from therecipient, then the IDoc receives the status �ready for dispatch� (status value30).

� If the outbound partner profiles specify that the IDoc is to be transferredimmediately to the port stored in the relevant message type, then the IDoc issent and receives a corresponding status (status value 03). However, it is alsopossible to send multiple IDocs bundled together at a later time.

� The IDoc is saved to the target system's database (status value 50).� If all information about further processing is known, the IDoc can be

transferred to the application (status value 64).� If the inbound partner profiles specify that the IDoc is to be transferred to

the application immediately, the target system attempts to post the IDoc data(status value 62). If the inbound processing is successful, the IDoc receivesstatus value 53.

Note: You will find out about other status values in the unit on�Monitoring Data Processing, Error Handling and Archiving�.

Exchanging Data with IDocs: Process SubstepsFirst, the application program generates a master IDoc containing the applicationdata.



Figure 24: Generating a Master IDoc

The master IDoc is transferred to what is known as the ALE layer. The ALE layeris the ALE-specific part of the application program.

The ALE layer checks the distribution model to determine the recipient(s) ofthe message.

Figure 25: Recipient Determination in the ALE Layer



Next in the program's run, the sender system checks the outbound partner profilesfor the message type used. For each recipient, a communication IDoc is createdaccording to the basic type and is saved to the database.

In order to be able to send the communications IDoc to the recipient, the sendersystem 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 theprogram 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 communicationlayer. However, for performance reasons, it is often better to first save the IDocsto the database and then to process them collectively later. The partner profiledetermines whether a communications IDoc is sent to the port immediately ornot until later.

Metaphorically speaking, the communications IDoc is like a letter that is to be sentto one or more recipients. The letter is copied and a copy is placed in an envelopefor each recipient. The sender and recipient are noted on the envelope. Then it isplaced in an out-tray whose contents are later put in a mailbox.

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



Figure 27: Port Types

The port type tRFC is short for �transactional Remote Function Call�. Thetechnology of the transactional RFC ensures that the recipient receives thedocument once and once only. If the recipient cannot be reached at the time ofsending, 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 targetsystem. In ALE scenarios, data transfer is via tRFC.

Not every partner system is able to interpret the RFC protocol. In EDI scenariosinvolving a converter, a file port is often used, for this reason. The IDoc is storedfor this file port as a sequential file at the operating system level in such a waythat the target system can access it. A corresponding path in the file systemis entered in the port.

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



Figure 28: Inbound Processing in the Recipient System

Depending on the defaults in the partner profiles, the IDoc is either transferredto the ALE layer immediately or not until later by a program for backgroundprocessing.

The ALE layer uses the partner profile to determine a transaction code thatcontrols how the IDoc is processed further. Generally speaking, the data istransferred to the application by a function module. However, a workflow couldalso be started instead.



Exercise 2: Documentation for BasicTypes

Exercise ObjectivesAfter completing this exercise, you will be able to:� Display documentation about basic types in mySAP ERP

Business ExampleYou want to use ALE to exchange data between two SAP systems and, by doingso, find out more about the technical implementation of ALE scenarios.

Task:You want to learn about the structure of theMATMAS05 basic type, so that youcan use the �Central Material Master Management� ALE scenario.

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

2. Find segment type E1MARMM (Material master units of measure) anddisplay the structure. Which segment type is dependent on E1MARMM?

3. Change your user settings so that, in future, the link to the documentationfor individual segment fields is displayed next to the link to the structureof the corresponding segment type.



Solution 2: Documentation for BasicTypesTask:You want to learn about the structure of theMATMAS05 basic type, so that youcan use the �Central Material Master Management� ALE scenario.

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

a) Select Tools → ALE → ALE Administration → Services →Documentation→ IDoc Types and Segments.

b) In the Basic type field, enter MATMAS05 and select HTML Format .

2. Find segment type E1MARMM (Material master units of measure) anddisplay 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 belowthe status information about segment type E1MARMM to call a listof segment fields.

b) Segment type E1MARMM (Material master EAN code) is dependenton segment type E1MARMM.

3. Change your user settings so that, in future, the link to the documentationfor individual segment fields is displayed next to the link to the structureof the corresponding segment type.

a) Choose Back to exit the HTML display.

b) In the transaction's menu, select Goto→ User Settings, click onDisplay <-> Change , set the Documentation Output indicator andsave 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 callinformation about the individual segment fields.



Lesson Summary

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


through to processing in the target system



Lesson: Synchronizing Customizing

Lesson OverviewData exchange across system boundaries requires the basic configurations of theapplications involved in the sending and target systems to be aligned with eachother. This lesson deals with synchronizing Customizing for the purposes of ALE.


� Describe methods for adjusting Customizing settings in SAP systemlandscapes

Business ExamplePreviously, you modeled your business processes in one particular system. In thefuture, you want to outsource a subprocess to a second system. You want to beable to assess the consequences and give yourself an overview of the differentmethods for aligning the system configuration.

Consequences of Distributing Applications AcrossTwo SystemsIf all applications are integrated in one system, the programs access the samedatabase. In this type of system, the consistency of the data is guaranteed becauseevery item of logical information is stored in only one database table, and allprograms retrieve data directly from the database. As soon as one application isseparated from the rest of the applications by being installed in another system, theapplications need to communicate via interfaces. The Customizing settings andmaster data must be consistent in all the communicating systems.


BIT300 Lesson: Synchronizing Customizing

Figure 29: Distributing Applications Across Two Systems

In ALE scenarios, IDocs are used to exchange application data between thesystems involved in a process. This exchange can only work if an IDoc containsonly field values that are also defined in the target system, unless these are fieldsfor which unrestricted data entry is planned. However, in most of the fields in themaster data and documents for SAP applications, only the field values pre-definedin Customizing are allowed. This means that, before you distribute the data, youneed to make sure that these catalogs of values match in both the sending andtarget systems. If you cannot (or do not wish to) match the systems, deviatingfield values need to be replaced by values from the target system during furtherprocessing of either the outbound or the inbound IDoc.

Business Process in One SystemA business process often consists of multiple single steps. Within a businessprocess, an agent can be responsible for more than one step. However, processsteps can also be carried out by different agents. Applications in SAP canbe affected by more than one partial solution. Once a process step has beenprocessed, the newly created or changed data is saved to the database. The agentfor the next process step needs to be informed, and the data required for executingthe next step needs to be transferred.



Figure 30: Business Process in One System: Example

The example shown above illustrates a sales order being processed in an SAP R/3or SAP ECC system. Agent 1, a sales employee, records the customer's order inthe system. The system (agent 2) automatically creates the shipment for this salesorder. A further employee (agent 3) creates a transfer order so that the productthat is to be shipped is removed from storage. Once the product has been removedfrom 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, theinvoice for the customer. This process therefore involves not only various agentsbut also various subsolutions (sales, delivery processing, warehouse managementand inventory management).

Business Processes in Multiple SystemsIf a business process extends across not only various subsolutions but also acrossdifferent systems, then specific data needs to be forwarded to the next agent. InALE scenarios, an IDoc functions as a �container� for this data.



Figure 31: Business Processes in Two Systems: Example

The figure illustrates the same process as the last one. The difference to the firstexample 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 anIDoc. There, it is processed further in the stock removal step. After this procedurehas been completed, the warehouse management system creates a second IDocwith all the data necessary for continuing the shipment process in the first system.

Note: This is a simplified representation of the �Decentralized WarehouseManagement System� ALE scenario.

Synchronizing Customizing Settings with ALEIn addition to distributing master data and transaction data, you can also use ALEto align the Customizing settings between systems (in preparation for distributingmaster and transaction data). Message type CONDA2 is available in the SAP R/3and SAP ECC systems for this purpose (ALE: Synchronization of CustomizingData). The core of this function is an automatic alignment of selected Customizingobjects in two SAP systems: this alignment generates transport requests for allthe changes.

Note: In systems released before SAP R/3 4.6A, use message typeCONDAT instead.

To optimize the use of ALE for Customizing synchronization, one logicalsystem in the system landscape is identified as the central Customizing system.Changes to certain Customizing tables are made in this system only. You can



determine exactly which objects should only be changed in the context of ALEdistribution. You group together these objects, known as ALE Customizingobjects, into distribution groups, which are automatically assigned to the logicalmaintenance system. You then need to distribute these distribution groups to thetarget systems. It is now no longer possible (or only partly possible, depending onthe particular configuration) to carry out any changes in the target system to theobjects contained in the distribution groups.

Note: You can distribute all client-dependent Customizing objects ofcategory CUST. Each object can be assigned to one distribution group,and one only.

All the Customizing settings you need for cross-system Customizing comparisonand subsequent synchronization can be found with transaction SALE. In themenu, select IDoc Interface/Application Link Enabling (ALE)→ Modellingand 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 youwill find a program for matching Customizing tables in the sending and targetsystems, known as the �Customizing Cross-System Viewer� (transaction SCU0),and transaction for generating and further processing ALE transport requests forCustomizing synchronization. The sending system creates IDocs of message typeCONDA2 for the transport requests: these IDocs contain the core informationabout each request. Inbound processing of these IDocs controls the importing ofrequest data in the target system: either a workflow is sent to the responsibleadministrator requesting him or her to carry out the import, or the import is carriedout automatically by a program executed in the background.

Note: The ALE transport request can be consolidated by a dedicatedtransaction (BDXL) with transport requests for exporting the changes tothe quality assurance and production systems.

Synchronizing Customizing Settings with the SAPSolution ManagerAs an alternative to distributing Customizing settings with ALE as described inthe previous section, you can use the SAP Solution Manager: this is an extensiveset of instruments for configuring and operating SAP solutions. The SAP SolutionManager includes two components for synchronizing Customizing settingsbetween SAP systems: the Customizing Scout and Customizing distribution.The Customizing Scout compares the configurations of multiple SAP systemsand displays the differences. The comparison can � as in ALE � be carried outinteractively or in the background, and periodically, if required. After the settingshave been matched, the Customizing distribution instrument can create transportrequests for each changed Customizing object in the maintenance system and



distribute the requests automatically to the downstream systems. It is, however,also possible to distribute manually. Certain Customizing objects are predefined inthe SAP Solution Manager as synchronization objects.

Converting Field Values: Cross-System CompanyCodesIt is not always either possible or desirable to standardize Customizing in a systemlandscape. 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. Thesubsidiary 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 ALEscenarios. These are freely-definable keys that are each assigned to one �genuine�company code, in other words, a company code used in the application. Whencreating a communications IDoc containing the field Company Code in one of itssegments, 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 assignedcross-system company code. The target system carries out the same operation inreverse: it replaces the cross-system company code with the �genuine� companycode, in order to create or change the customer master. You can find the tablesfor defining cross-system company codes and linking them to the company codesused in the applications under transaction SALE, via IDoc Interface / ApplicationLink Enabling (ALE)→ Modelling and Implementing Business Processes→Global Organizational Units→ Cross-System Company Codes. You need to carryout similar settings for the business areas.

Caution: You need to define and assign at least one cross-systemcompany code in the sending and target systems, even if the companycode keys are identical. If this setting is missing, IDoc processing fails.The outbound IDoc receives status 29 (Error in ALE Service) and theinbound IDoc receives the corresponding status 65.

There are only a few cases where you can convert field values directly usingCustomizing 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 usethe Field Conversion tool. This allows either the sending or the target systemto change the content of IDoc segment fields during runtime of the applicationprogram in question. Field conversion is based on rules and allows for a moredifferentiated data changing procedure than that provided by exchanging valueson the basis of Customizing table entries.

Note: The configuration of field conversion is one of the topics coveredin the BIT350 training course (ALE Enhancements).



Lesson Summary

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

landscapes


BIT300 Lesson: ALE and the SAP NetWeaver Exchange Infrastructure

Lesson: ALE and the SAP NetWeaver ExchangeInfrastructure

Lesson Overview


� Explain how ALE scenarios are integrated into SAP XI

Business ExampleYou have already set up some ALE scenarios in your system landscape and areconsidering using SAP NetWeaver Exchange Infrastructure to exchange databetween the systems involved and with third parties.

The SAP NetWeaver Exchange InfrastructureThe Exchange Infrastructure from SAP NetWeaver (SAP XI) enables youto realize cross-system business processes. SAP XI makes it possible to linksystems from various providers in different versions and implemented in differentprogramming languages (Java, ABAP, and so on). SAP XI is based on an openarchitecture and supports the protocols, data formats and interfaces used in SAPand 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 necessarymapping between different data formats. Messages are processed within SAPXI in the form of XML documents. Any systems that do not directly supportthis data format can be linked to XI with SAP XI adapters. There are a varietyof adapters for this purpose; these are provided either by SAP itself or by SAP'spartner companies.

Note: Adapters need to be configured for the connection to a system. Thisconfiguration is carried out in the form of a communication channel.A communication channel defines the rules of inbound and outboundmessage processing.



In addition to the Integration Server, SAP XI consists of a series of componentswith various different tasks, introduced briefly below:

� The Integration Repository is the directory of message interfaces involvedin data exchange. The mappings between the interfaces are stored here aswell.

� The configuration is stored in the Integration Directory; in other words, therouting information about which message is to be sent from which system towhich 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 XIThe Integration Server uses the IDoc adapter to connect back-end systems thatare to send or receive IDocs. The IDoc adapter is a part of the ABAP side of theIntegration Server and communicates with the back-end system via transactionalRFC (tRFC).

The IDoc adapter converts IDoc data records into IDoc XML, which is then usedfor processing in the Integration Server. The IDoc adapter also has to convertinformation from the sending and target systems, since these are present in theIntegration Server in the form of business systems that are stored in the SLD. Alogical system name can be assigned to these business systems.



The IDoc adapter requires IDoc type metadata for conversion between IDoc andIDoc XML. You need to define a port in transaction IDX1 in the Integration Serverto enable the IDoc adapter to access data in the backend repository: this IDX1 portreferences an RFC destination (type 3), which refers to the back-end system.

Note: After it is accessed, the IDoc type metadata is held in a cache whichcan be seen on the Integration Server via transaction IDX2, where it canalso be manually deleted.

The interfaces for the systems involved in data exchange are stored in theIntegration Repository so that they can be used for mapping and routing. IDoctypes 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 softwarecomponent version to which the IDoc type belongs and into which it is to beimported. Then the metadata is loaded via RFC call from back-end systeminto the Integration Repository. The name of the IDoc type is stored in theIntegration Repository in the form: <message type>.<IDoc type>, for exampleMATMAS.MATMAS05.

For an IDoc to be sent from the Integration Server to the back-end system, thereneeds to be a communications channel (of the type �Receiver IDoc�) stored in theIntegration Directory, containing technical information about the connection to theback-end system. The communication channel specifies, on the one hand, an RFCdestination for sending the IDoc and, on the other hand, a reference to the IDX1port, which references an RFC destination for accessing the IDoc type metadata.

Note: No communication channel needs to be stored for IDocs sent fromthe back-end system to the IDoc adapter. However, an IDX1 port is alsoneeded here to access the metadata.

In a scenario where IDocs are to be exchanged with the Integration Server, youneed to carry out the following steps on the Integration Server:

� SLD: assign a logical system name to the business system assigned to theback-end system

� Integration Repository: import the IDoc type� Integration Server (ABAP): create an RFC destination to the back-end

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

destination (transaction IDX1)� Integration Directory: create a communication channel of the type �Receiver

IDoc�



Figure 33: XI IDoc Adapter

The configuration in the back-end system consists of the usual ALE configurationobjects (distribution model, partner profiles, port, RFC destination). The RFCdestination that refers to the Integration Server in order to send IDocs there is oftype 3 (�connection to R/3 system�) because the IDoc adapter is on the ABAPside of the Integration Server.

Note: The ALE inbound function module IDOC_INBOUND_ASYN-CHRONOUS checks whether it has been executed on the IntegrationServer and, if it has, then it transfers the received IDoc as an XMLdocument to XI processing and not ALE processing.

If you do not want to use any logical system names in the IDoc for the senderand recipient information in the control record, but other partner types such ascustomer or vendor instead, then the IDoc adapter can also reassign these typesinto 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 assignedthis partner type in the Integration Directory using what is known as a partnerobject as an identifier.



Lesson Summary

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


Unit Summary BIT300

Unit SummaryYou 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�


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 2Master Data Distribution

Unit OverviewThe decision to manage master data centrally is one of the main reasons forusing ALE. In this unit you will learn about all the settings needed for setting upa central master data administration.


� Describe the configuration of an ALE scenario for distributing materialmaster 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 ContentsLesson: Example: Material Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

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

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

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


Unit 2: Master Data Distribution BIT300

Lesson: Example: Material Master

Lesson OverviewDistributing master data is one of the applications of ALE. This lesson introducesthe �Shared Master Data� instrument for distributing master data, using thematerial master as an example.


� Describe the configuration of an ALE scenario for distributing materialmaster data

� Distribute material masters

Business ExampleIn the future, you want all material masters for the entire corporate network tobe stored in the central system only and for them to be sent from there to thedownstream sales branch and production systems.

Central Material Master AdministrationOne method of keeping the master data consistent in a system landscape is tomaintain the master data in a central system, and replicate it to the downstreamsystems at regular intervals. It is either not at all possible, or only possible to alimited extent, to change data in these latter systems.

Figure 34: Example Scenario


BIT300 Lesson: Example: Material Master

In the example illustrated above, the material masters for the enterprise are createdand changed in the head office (central system). New material masters andchanges to existing data are regularly sent to the downstream systems for the salesand distribution branch and production.

Note: The lesson on �Using Change Pointers� deals with distributingchanges to the master data at regular intervals.

There are standard ALE scenarios for distributing master data; these aredocumented in the SAP Library and in the IMG. You can use transaction SALE tofind descriptions of how to set up certain master data distribution scenarios. Todo this, go to IDoc Interface / Application Link Enabling (ALE)→ Modellingand Implementing Business Processes→ Configure Predefined ALE BusinessProcesses→ Logistics→Master Data Distribution. For more information, followmenu path IDoc Interface / Application Link Enabling (ALE)→ Modelling andImplementing Business Processes→ Master Data Distribution. In this sectionof the IMG, you can carry out the Customizing settings for your master datadistribution scenarios described in this lesson.

You need to answer the following questions before you configure any distributionscenario:

� 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 MasterAdministrationThe figure below illustrates the most important elements in the example scenario:



Figure 35: Basic Settings for the ALE Scenario

The head office's logical system is called CORE. The sales and distributionbranch's logical system is called SALES and the logical system for productionis called PRODUCTION. The message type for distributing material mastersis MATMAS.

First, use this information to create a new view in the distribution model ofone of the system's involved. In the training scenario, CORE is the maintenancesystem for all model views. In the new view, you need to specify the behaviorof the sender and the recipient and inform the system about what type of data isto be distributed.

Figure 36: Maintaining the Distribution Model and Distributing Views

To ensure consistency, you should maintain the distribution model centrally, anddistribute or transport the relevant views to the other participating systems.



If RFC destinations already exist with the same names as the logical targetsystems, you can now have the system create the outbound partner profiles forthe new model view. When it generates partner profiles, the system automaticallycreates an entry for the message type MATMAS and also an entry for messagetype SYNCH for each profile (ALE:Dummy Message Type for Determination ofRFC Destinations). This message type is not used for generating IDocs: it is onlyused for determining the RFC destination of the relevant target system. The entryfor message type SYNCH is a prerequisite for distributing model views.

Note: If your RFC destinations have different names to the target systemsto which they lead, you need to first create the entry for message typeSYNCH manually and then assign the RFC destination you require usingthe relevant port. After you have done this, you can have the systemgenerate 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 theoutbound partner profile level:



Figure 38: Partner Profile (Outbound)

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

� Receiver port: in ALE scenarios, the sending and target systems exchangedata via RFC. You therefore need to use a port of the type �transactionalRFC� in the outbound partner profiles for ALE scenarios; the RFCdestination of this RFC leads to the target system, the partner in the profiles.

� Output mode: You can choose between Transfer IDoc Immed. and CollectIDocs.

� Package size: If you choose Transfer IDoc Immed., the IDocs are sentindividually. If you choose Collect IDocs, multiple IDocs are collected inpackages and sent together. Collecting IDocs to send together can improveperformance. As a guideline, we recommended collecting between 20 and100, depending on the size of the IDocs.

� Basic type: in this field, you need to enter the IDoc type that is compatiblewith the target system's release level.

Note: If you select the Collect IDocs output mode, you need to executethe RSEOUT00 program to transfer the IDocs to the communicationlayer. This program is usually scheduled as a periodic background job.

After you have created the outbound partner profiles for the target systems, youcan distribute the new model view to these systems.



Figure 39: Distributing the Model View

After you have successfully distributed the model view to the SALES andPRODUCTION systems, you can display the copies in their respective distributionmodels. In the last step, you have the system generate the inbound partner profileswith the CORE sending system, or you can store the data manually.

Figure 40: Partner Profile (Inbound)



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

� Process code: the process code is a key that refers either to a functionmodule or a workflow for processing the IDocs. The process code formessage type MATMAS isMATM. If you double-click on the process codekey, a screen appears containing the information as to which function moduleor which workflow is used for inbound IDoc processing. As a rule, functionmodules are used in ALE scenarios.

Note: There can be more than one process code for a messagetype (and, accordingly, more than one inbound function moduleor workflow). For information about which process codes areassigned to which message types, see the Inbound process codetable (transaction WE42).

� Processing mode: you can choose between Trigger by background programand Trigger immediately. If you choose Trigger by background program, theIDocs are transferred to the ALE layer using the RBDAPP01 program. Thisprogram is usually scheduled as a periodic background job.

Figure 41: Processing Times

You can define variants for the RSEOUT00 and RBDAP001 programs forcollective background IDoc processing. You can find both programs in the IMGvia transaction SALE, by going to IDoc Interface / Application Link Enabling(ALE)→ System Monitoring→ IDoc Processing→ Dispatch Collected IDocsor Update IDocs in Receiver System.



You can check the current status of IDocs in SAP R/3 or mySAP ERM by usinga status monitor. You can call this monitor with transaction BD87 or the menupath Tools→ ALE→ ALE Administration→ Monitoring→ IDoc Display→Status Monitor.

Note: Monitoring IDoc processing is covered along with error-handling inthe unit �Monitoring Data Distribution, Error-Handling and Archiving�.

Sending and Requesting Master DataThe �Share Master Data� tool offers you a variety of application transactions forgenerating IDocs for distributing master data. You can find these transactions viamenu path Tools→ ALE→ Master Data Distribution. You can also call all of theSMD 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 thesystem to determine the recipient itself from the distribution model. If you do notspecify a target system, the sending system might generate multiple IDocs.

In ALE scenarios, master data is normally sent from the maintenance system tothe downstream systems. However, with cross-application master data (material,customer, vendor), it is also possible to retrieve data.



Figure 43: Retrieving Master Data

Message typeMATFET, for example, is used for fetching material masters. Thismessage type is linked to the corresponding views in the distribution model (seefigure). In the application menu, you can find transaction BD11 via Tools→ALE→ Master Data Distribution→ Cross-Application→ Material→ Get; thetarget system can use this transaction to request material masters from the sendingsystem. Message type MATMAS is used for sending the material master IDocs.



Creating and Distributing a Model ViewUseYou want (as part of an ALE scenario) to create a new model view in your centralmaintenance system's distribution model or enhance an existing model view.

Procedure1. In the IMG, select SAP NetWeaver→ SAP Web Application Server→ IDoc

Interface / Application Link Enabling (ALE)→ Modelling and ImplementingBusiness 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 foridentifying the model view. Confirm your entries with Enter and save tocreate the new model view.

3. Select your new model view and click on the Add message type button. Inthe window that now appears, enter both the sender's and recipient's logicalsystem names and a message type of your choice. Confirm these entrieswith Enter; this will return you to the distribution model, where you cansave the changes.

If you want to link a BAPI to the model view instead of a message type, clickon the Add BAPI button. Add the sender's and recipient's logical systemnames (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 appropriatemethod. Then confirm your entries with Enter.

4. To distribute the model view to a partner system, there must be outboundpartner profiles with the partner for message type SYNCH. To check if theseexist, select (in the distribution model's menu) Environment→ Changepartner profile. In the folder for partner type LS, search for an entry for yourpartner system and check the outbound parameters. If you do not find anentry for message type SYNCH, add one manually by assigning a recipientport containing an entry for the RFC destination leading to the partnersystem. The basic type has SYNCHRON as its key.

Hint: If the recipient system's logical system name is the same as thename of the RFC destination leading to it, you can have the systemautomatically create the outbound partner profiles for message typeSYNCH and for all of the model view's other message types. Todo this, select (in the distribution model's menu) Environment→Generate partner profiles.




5. Distribute the new (or changed) model view by selecting the relevant entryin the distribution model and going in the menu to Edit→ Model view→Distribute. If there is more than one possible recipient for the data beingdistributed and you only want to send the model view to one particularrecipient, deselect the entries for the other recipients in the Distribute ModelViews window that now appears.

You then receive a log that informs you whether the new (or changed) modelview was successfully distributed or not.

6. If you have not already done so, create the outbound partner profiles forthe message types you have just added to the model view. If there areoutbound partner profiles for message type SYNCH (see step 4), you canhave the system generate all the partner profiles for all the other messagetypes (Environment→ Generate partner profiles). If you create an outboundpartner profile manually, you need to assign a recipient port with theappropriate RFC destination and a basic type, in addition to the message type.

Caution: When selecting the version, bear in mind the recipientsystem's release status, since the basic type needs to be recognized inthe target system as well.

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

7. In order to be able to use your new (or changed) model view in an ALEscenario, you now have to create (or have the system generate) suitableinbound partner profiles in the target system. In the inbound partner profiles,you need an appropriate process code for the message type; this code mustbe linked to the function model or workflow for inbound processing. If youhave the system generate the inbound partner profiles, you should check thatit has assigned the right process code for your scenario.



Exercise 3: Master Data Distribution

Exercise ObjectivesAfter completing this exercise, you will be able to:� Send a material master� Display an IDoc in the status monitor

Business ExampleIn the future, you want all material masters for the entire corporate network tobe stored in the central system only and for them to be sent from there to thedownstream sales branch and production systems.

Task:Create a material master in the CORE logical system and send it in IDoc formatto the PRODUCTION and SALES logical systems. Check the inbound andoutbound processing for each in the status monitor.

1. Create the Basic Data 1 and 2 for materialMATALE-## with a descriptionof your choice. The material should belong to the Mechanical Engineeringindustry sector and to material type Finished product. The base unit ofmeasure is a piece (PC).

Hint: �##� is your group number

2. First send your new material using the relevant transaction in the �SharedMaster Data� instrument to the PRODUCTION logical system. How manymaster IDocs and how many communication IDocs were created?

Master IDocsCommunication IDocs

3. Send your material again without specifying a target system. How manymaster IDocs and communication IDocs were created?

Master IDocsCommunication IDocs




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

5. Display the outbound IDocs for message typeMATMAS in the statusmonitor in the CORE logical system. What status do the IDocs have?

Hint: If you want to access one specific IDoc, enter the businessobject type StandardMaterial and your material number(MATALE-##) as the object keys on the status monitor's initialscreen.

6. Next, display the IDocs in the status monitors for each of the two recipientsystems: PRODUCTION and SALES. What status do these IDocs have?Also check the material masters yourself.



Solution 3: Master Data DistributionTask:Create a material master in the CORE logical system and send it in IDoc formatto the PRODUCTION and SALES logical systems. Check the inbound andoutbound processing for each in the status monitor.

1. Create the Basic Data 1 and 2 for materialMATALE-## with a descriptionof your choice. The material should belong to the Mechanical Engineeringindustry sector and to material type Finished product. The base unit ofmeasure is a piece (PC).

Hint: �##� is your group number

a) Select Logistics→ Materials Management→ Material Master→Material→ Create (General)→ Immediately.

b) Enter material number MATALE-##, select the industry sectorMechanical Engineering and material type Finished product andconfirm 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 ofmeasure PC (piece). You do not need to make any entries in the BasicData 2 view. Save to create the material master.

2. First send your new material using the relevant transaction in the �SharedMaster Data� instrument to the PRODUCTION logical system. How manymaster IDocs and how many communication IDocs were created?




Master IDocs 1Communication IDocs 1

a) Select Tools→ ALE→ Master Data Distribution→ Cross-Application→ Material→ Send.

b) Enter the following data:

Material MATALE-##

Message type MATMAS

Logical system PRODUCTION

Then select Execute .

c) One master IDoc and one communication IDoc have been created.

3. Send your material again without specifying a target system. How manymaster IDocs and communication IDocs were created?

Master IDocs 1Communication IDocs 2


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

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

Answer: The number of communication IDocs depends on the number ofreceiver systems. If the recipient system is specified in the send transaction,only one communication IDoc is created. If you do not specify any recipientsystem, then the target systems are determined from the distribution model.This could mean that more than one communication IDoc is created. Thenumber of master IDocs always conforms to the number of master recordsthat are to be sent.




5. Display the outbound IDocs for message typeMATMAS in the statusmonitor in the CORE logical system. What status do the IDocs have?

Hint: If you want to access one specific IDoc, enter the businessobject type StandardMaterial and your material number(MATALE-##) as the object keys on the status monitor's initialscreen.

a) Select Tools→ ALE→ ALE Administration→ Monitoring→ IDocDisplay→ 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 typeMATMAS and click on the DisplayIDocs button: you receive a list of all the IDocs for this message type.

e) Select one of your IDocs and click Display IDocs again.

6. Next, display the IDocs in the status monitors for each of the two recipientsystems: PRODUCTION and SALES. What status do these IDocs have?Also check the material masters yourself.

a) Select Tools→ ALE→ ALE Administration→ Monitoring→ IDocDisplay→ Status Monitor.

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 typeMATMAS and click on the DisplayIDocs 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: bothviews are created.



Lesson Summary

You should now be able to:� Describe the configuration of an ALE scenario for distributing material

master data� Distribute material masters


BIT300 Lesson: Using Change Pointers

Lesson: Using Change Pointers

Lesson OverviewYou can always change master data at any time over its lifespan. If you havecentralized master data distribution, you need to ensure that any changes arepromptly transferred to the downstream systems. In this lesson, you will learnabout distributing changes to the master data using change pointers.


� Explain the use of change pointers in master data distribution and set themup in the system

Business ExampleIn 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 anddistribution and production systems.

Distributing Master Data ChangesIn this example, the system landscape is made up of the head office, a sales anddistribution branch and production:

Figure 44: Example Scenario



All master data is created and, where necessary, changed in the head office'slogical system. Newly created and changed master records should be distributedto sales and production logical systems at regular intervals, so that these systemalso work with up-to-date data.

Change PointersMany application programs create change documents for each change madeto their objects (master data and documents). These change documents recordchanges to the application objects, normally specifying the person who made thechange and the time of the change. These change documents can be used in ALEto set what are known as change pointers, which allow the sending system toselect 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, youcan specify in Customizing whether a message type works with the changepointer function or not. The change pointer creates a connection between changedocuments and the corresponding message type.



When it creates or changes a master record, the application program querieswhether the change pointer mechanism is activated or not. If the function isactive, a change pointer is saved to the database together with the applicationdocument and the change document.

Note: To view the change documents, use the report RSSCD100. Youcan also call the change documents from the application transactionin question. To view the change pointers, see the database table viewBDCPV.

Figure 46: Generating IDocs from Change Pointers

You can evaluate change pointers by using the program RBDMIDOC. Thisprogram is usually scheduled as a periodic background job. You can start theprogram 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 relevantfor distribution, which it then transfers to the ALE layer. You can display theassignment of message type and function module for evaluating the the changepointer with transaction BD60 (menu path: Tools→ ALE→ ALE Development→ IDoc→ Engineering Change Management→ Define Function Module forEvaluation).

If you want to distribute master data, first check if the change pointer function isactivated in general (in other words, for the clients in your SAP system). Thenactivate change pointer updating for all the message types you want to use in yourdistribution scenarios. You can find the relevant table in the IMG via transaction



SALE, by selecting menu path IDoc Interface / Application Link Enabling (ALE)→ Modelling and Implementing Business Processes→ Master Data Distribution→ Replication of Modified Data→ Activate Change Pointers � Generally orActivate Change Pointers for Message Types.



Lesson Summary

You should now be able to:� Explain the use of change pointers in master data distribution and set them

up in the system



Lesson: Data Filtering and Reducing the Scope of Data

Lesson OverviewIn ALE scenarios, not all recipient systems should always receive all of thesending system's data. This lesson presents various options for controlling theamount 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 ExampleIn 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 supplementcertain sections of master data in their own systems.

Segment FilteringIf you do not want a recipient to receive the complete data record in an IDoc, youcan use segment filtering. Segment filtering is an application-independent ALEservice which ensures that individual segments are deleted from the data partbefore 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 firstcheck the structure of the basic type you are going to use to determine the keys forthe segments you would like to delete. If, for example, you want the sales areadata for the customer masters (basic type DEBMAS0x) to be created in the sales


BIT300 Lesson: Data Filtering and Reducing the Scope of Data

branch system, you can use segment filtering to delete segment group E1KNVVM(Master customer master sales data) from all communications IDocs for messagetype DEBMAS and recipient �Sales�. The customer masters are then distributedto sales without the sales area data.

Note: If you select a segment group � that is, a segment with itssubsegments � for segment filtering, all the subsegments are deleted fromthe communications IDoc.

Figure 48: IMG: Segment Filtering

You can set up segment filtering in the IMG with transaction SALE, via IDocInterface / Application Link Enabling (ALE)→ Modelling and ImplementingBusiness Processes→Master Data Distribution→ Scope of Data for Distribution→ Filter IDoc Segments. In this table, specify the message type and the targetsystem and the segments to be deleted. The next communications IDoc for themessage type and recipient specified will be generated without these segments.The figure below schematically illustrates the process flow for IDoc outboundprocessing with segment filtering.

Figure 49: Outbound Processing with Segment Filtering



Filter ObjectsThe following sections introduce filter options that, unlike segment filtering asdescribed above, are application-dependent. You therefore need to check in eachindividual case if the option is available for your ALE scenario.

Many applications are designed to be used with filter objects. These objectsare application data (often organizational units and groupings) whose individualcharacteristics can determine whether a communications IDoc is created for arecipient in the first place, or which parts of the data record being distributed arecontained in the communications IDoc.

Figure 50: Filtering Using Filter Objects

If you work with filter objects in ALE scenarios, you have to define conditions thatneed to be fulfilled for specific application data to be included in a communicationsIDoc. If the filter object corresponds to a required segment of the basic type inquestion, then a communications IDoc is only created if the condition is fulfilled.In the example illustrated below, material masters (message type MATMAS) aredistributed at regular intervals from the head office to sales and distribution andproduction. However, sales and distribution is only supposed to receive materialmasters for finished products whereas production requires the master records forthe finished parts and the raw materials.



Figure 51: Example: Distribution Depending on Material Type

The �material type� is one of the filter objects designed for material masters. Thematerial type groups together materials according to their physical properties, suchas finished products, trading goods and raw materials. In basic type MATMAS0x,the segment field for material type (MTART) is part of a segment marked asrequired. If you now use the material type as a filter object for IDocs of messagetype MATMAS in the model view for distributing the material masters to sales,and assign the finished products material type key (FERT), you are guaranteeingthat only material masters of this material type will be distributed to sales. Thesending system does not generate any communications IDocs for material mastersof other material types, if the recipient is �Sales�. If a filter object refers to anoptional segment of the basic type in question, the segment and its subsegmentsare deleted from the IDoc if a field value does not fulfill a condition that ismaintained in the distribution model.

Note: Customers can enhance the list of filter objects provided by SAPwith their own filter objects. The tables required for this can be found inthe application menu along the path Tools→ ALE→ ALE Development→ IDoc→ Data Filtering.

The figure below schematically represents the required Customizing settings:



Figure 52: Distribution Model: Creating Filter Groups

Conditions within a filter group are linked to each other by �AND� logic. You cancreate more than one filter group for each message type in the distribution model.These filter groups are linked to each other by �OR� logic.

Figure 53: Outbound IDoc Processing with Filter Objects



The filter objects are evaluated in the ALE layer. If filter values are specified for amessage type in a distribution model, the system uses them to derive a condition.If the condition is met, the communications IDoc is transferred unchanged. If thecondition is not met, the affected rows are deleted from the data part.

ClassificationLogistics applications in SAP R/3 or SAP ECC systems can use classification, across-application function, independently of ALE scenarios. Classification allowsyou to group application data (generally master data or documents) by fairlyfreely-definable criteria. You can use these groupings for the targeted selection ofspecific data records, for example. In the ALE context, however, classificationfulfills a different purpose: the membership of a data record to a specific classdetermines how it is distributed.

Figure 54: Filtering Using Classification

If you would like to use classification as a filter method in an ALE scenario, youfirst need to carry out some basic settings in the class system itself. You need tomark one class type as the �distribution class type� and create at least one classfor grouping your data in this class type. Then you can add the ALE-specificsettings. You can activate the use of classification in an ALE scenario in the filterobject area of a model view (see above).



Figure 55: Distribution Using Classes

To configure classification for ALE scenarios, call transaction SALE (in the IMG)and select IDoc Interface / Application Link Enabling (ALE)→ Modelling andImplementing Business Processes→ Master Data Distribution→ DistributionUsing Object Classes. You assign application data to classes yourself in theapplication in question. You classify material masters, for example, by creating acorresponding �view�; that is, a data screen. If a material master record does notbelong to the distribution class specified for the target system, it is not distributedto that system.

Reduced Message TypesSome applications have such flexible programs for inbound and outboundprocessing that you can choose whether or not each optional segment field is to betransferred. To do this, you create what is known as a reduced message type in thecustomer namespace as a copy of a message type supplied by SAP; then you selectthe fields whose content you want to be transferred to a particular target system.

Figure 56: Filtering with Reduced Message Types



You can use these reduced message types in all ALE scenarios where thedistributed data is not processed in the sending system only. In this kind ofscenario, for example, the sales branch could independently change the materialmasters after they had been initially transferred from head office. Sending thesemaster records again would result in all the fields that had been changed in thesales system being overwritten: the sales personnel's work would have beenwasted. If, on the other hand, a reduced message type without these fields is usedin this scenario, then the locally maintained data is protected from overwritingbecause 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 reducedmessage type are written to the target system's database. Segment fields that areabsolutely 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 thefollowing functions:

� Outbound function module: an ALE function checks whether or not areduced 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 fieldshave a �no-data� character. These fields are not written to the database.This enables you to maintain specific detail data in the local systems, andto ensure that data is not �accidentally� overwritten with an initial valuewhen master data is replicated.

� Message type: the message type is marked as �reducible�.



To create a reduced message type, call transaction SALE and go to IDoc Interface/ Application Link Enabling (ALE)→ Modelling and Implementing BusinessProcesses→ 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 IDoctype. First the required segments are selected and then only the fields in thesesegments that are marked in a standard SAP system as required fields. Thesesegments and fields are marked with a green background.

Select a segment by highlighting it and clicking on the Select button. Note: whenyou select a segment, only fields that are defined in a standard SAP system asrequired 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, thenclick on Select again. Optional segments or fields that have not yet been selectedare marked with a red background. Optional segments or fields that have alreadybeen selected are colored white.

Caution: You have to click on the Select button before you can exit thedetail screen by selecting Enter. If you select fields and then click onEnter immediately, your selection is not saved.

If you would like to use the change pointer function (see the lesson on �UsingChange Pointers�) for a reduced message type, you need to set the correspondingindicator for this reduced message type. To do this, call transaction SALE and



go to IDoc Interface / Application Link Enabling (ALE)→ Modelling andImplementing Business Processes→ Master Data Distribution→ MessageReduction→ 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 targetsystems.

Figure 59: Transporting Reduced Message Types

Because message types are cross-client Customizing objects, they are transportedusing a workbench request. You can generate a transport request for any reducedmessage type. To do this, go to

Application Link Enabling (ALE)→ Modelling and Implementing BusinessProcesses→ Master Data Distribution→ Scope of Data for Distribution→Message Reduction→ Generate Transport Request for Message Type.



Figure 60: Outbound Processing with Reduced Message Types

The same program is responsible for generating IDocs for a reduced messagetype as for generating IDocs for the template message type. When creating amaster IDoc, the application program first determines detail information aboutthe 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 transferredto the ALE layer.



Figure 61: Inbound Processing with Reduced Message Types

The same inbound function module is used for inbound processing as for anIDoc for the template message type. The system checks all optional segments todetermine if they contain �/�. Only fields that do not contain �/� are written tothe database.



Exercise 4: Using a Reduced MessageType

Exercise ObjectivesAfter 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 ExampleIn your enterprise, material masters are created in the head office and sent toproduction (and elsewhere). The local business department makes changes tospecific data views, which you want to protect from being overwritten when themaster records are sent again.

Task:Create a reduced message type as a copy ofMATMAS and connect it to yourdistribution 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 typeMATMAS. In addition to the segmentsE1MARAM (Master material general data) and E1MAKTM (Mastermaterial short texts), the reduced message type should contain the followingsegments and segment fields:

E1MARAM ERNAM (Created by)BISMT (Old material number)BRGEW (Gross weight)NTGEW (Net weight)GEWEI (Weight unit)

E1MTXHM Select allE1MTXLM Select all

Caution: In the segment E1MARAM, ensure the fields LAEDA(Date of last change), AENAM (Last changed by), VOLUM(Volume) and VOLEH (Volume unit) are not selected.




2. You want to use the change pointer function for your reduced message typein 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 itsrecipient. Use your reduced message type, ZMATMAS##, from the firsttask.

4. Now have the system generate the outbound partner profiles for message typeZMATMAS## in the CORE logical system. What basic type is proposed?

Basic type: ______________________

5. If the PRODUCTION logical system is in a different physical system thanthe CORE logical system, then you need to define the reduced messagetype ZMATMAS## in this system as well before you can distribute theTRAINING## model view.

Hint: You can also transport the reduced message type to the targetsystem.

6. Distribute your TRAINING## model view to the PRODUCTION partnersystem. In the PRODUCTION system, generate the inbound partner profilesfor message type ZMATMAS##. Which process code is proposed?

Process code: _____________

7. Change some values in your materialMATALE-## in the CORE logicalsystem. Make sure you change the volume and the volume unit.

8. Send the changed material directly to the PRODUCTION logical system.Display the outbound and inbound IDocs in the status monitor for eachsystem. Did the settings you made in task 1 produce the desired effect?

Hint: Use your reduced message type ZMATMAS##.

9. Display the materialMATALE-## in the PRODUCTION system. Whichchanges have been transferred from the CORE system?

10. Now change the Old material number field in yourMATALE-## materialand then have the system evaluate the change pointers for message typeZMATMAS##. How many communications IDocs are created?

11. Check the result in the CORE and PRODUCTION systems' statusmonitors. In the segment E1MARAM, what is in the fields Old materialnumber (BISMT), Date of last change (LAEDA), and Last changed by(AENAM), and why?



Solution 4: Using a Reduced MessageTypeTask:Create a reduced message type as a copy ofMATMAS and connect it to yourdistribution 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 typeMATMAS. In addition to the segmentsE1MARAM (Master material general data) and E1MAKTM (Mastermaterial short texts), the reduced message type should contain the followingsegments and segment fields:

E1MARAM ERNAM (Created by)BISMT (Old material number)BRGEW (Gross weight)NTGEW (Net weight)GEWEI (Weight unit)

E1MTXHM Select allE1MTXLM Select all




Caution: In the segment E1MARAM, ensure the fields LAEDA(Date of last change), AENAM (Last changed by), VOLUM(Volume) and VOLEH (Volume unit) are not selected.

a) In the CORE logical system, call transaction SALE and go to IDocInterface / Application Link Enabling (ALE)→ Modelling andImplementing Business Processes→ Master Data Distribution→Message Reduction→ Create Reduced Message Type.

b) In the Reduced message type field, enter the value ZMATMAS## andchoose Create .

c) Enter the template message type MATMAS and select Enter. Add adescription 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 theE1MTXHM segment (Master material long text header and clickon the Select button.

g) Display the substructure of the E1MTXHM segment, select theE1MTXLM subsegment (Master material long text line and click onthe Select button again.

h) Save to create the reduced message type. A query appears for aworkbench request for transporting the message type to other systemslater. Choose Create Request , enter a short description of yourchoice and create the request by saving it.

2. You want to use the change pointer function for your reduced message typein the future. Set the appropriate indicator.

a) Exit the overview of the reduced message type's segments in order toreturn to the maintenance transaction's initial screen.

b) Click on the Activate change pointers button.




3. In the CORE logical system's distribution model, create a new model view,TRAINING##, with CORE as its sender and PRODUCTION as itsrecipient. Use your reduced message type, ZMATMAS##, from the firsttask.

a) Select IDoc Interface / Application Link Enabling (ALE)→ Modellingand Implementing Business Processes→ Maintain Distribution Modeland Distribute Views and switch to change mode ( ).

b) Click on the Create model view button, enter a short text of your choiceand the technical name TRAINING## and confirm your entries withEnter.

c) Select the model view and click on the Add message type button.

d) Enter CORE as the sender, PRODUCTION as the receiver andZMATMAS## as the message type, and then select Enter. Create thenew model view by saving it.

4. Now have the system generate the outbound partner profiles for message typeZMATMAS## 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 effectthat outbound partner profiles for message type ZMATMAS## and thepartner PRODUCTION have been created. Exit the log with Back .

c) Display one of the two new partner profiles via Environment→ Changepartner profile: select the partner PRODUCTION (partner type LS).

d) Select the outbound parameters for message type ZMATMAS## andclick on DetailScreenOutb.Parameter : the basic typeMATMAS05is assigned here.




5. If the PRODUCTION logical system is in a different physical system thanthe CORE logical system, then you need to define the reduced messagetype ZMATMAS## in this system as well before you can distribute theTRAINING## model view.

Hint: You can also transport the reduced message type to the targetsystem.

a) In the PRODUCTION logical system, go to IDoc Interface /Application Link Enabling (ALE)→ Modelling and ImplementingBusiness Processes→Master Data Distribution→Message Reduction→ Create Reduced Message Type.

b) Create the reduced message type ZMATMAS## as described in step 1.

6. Distribute your TRAINING## model view to the PRODUCTION partnersystem. In the PRODUCTION system, generate the inbound partner profilesfor 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 messageinforming you that your model view was successfully distributed.

c) Switch to the PRODUCTION logical system and call the distributionmodel from there as well, to check if the copy of your model view isavailable.

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→ Changepartner profile to check the inbound partner profile for message typeZMATMAS##.

f) Mark the partner CORE, in the inbound parameters, select the entryZMATMAS## and click on DetailScreenInboundParameter : theprocess codeMATM is assigned here.




7. Change some values in your materialMATALE-## in the CORE logicalsystem. 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 weightand Weight unit, for example. Also add a volume with a suitable unitof measure. Save your changes.

8. Send the changed material directly to the PRODUCTION logical system.Display the outbound and inbound IDocs in the status monitor for eachsystem. Did the settings you made in task 1 produce the desired effect?

Hint: Use your reduced message type ZMATMAS##.


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

c) Select Tools→ ALE→ ALE Administration→ Monitoring→ IDocDisplay→ Status Monitor.

d) Enter the message type ZMATMAS## and select Execute .

e) Select the entry under ZMATMAS## and click on the Display IDocsbutton.

f) On the next screen, select your IDoc and then click again on theDisplay IDocs button.

g) Display the data records and select the segment E1MARAM, to checkthat the system has placed �no-data� characters in the unselectedoptional fields. You should also be able to see this character in thefields that you did not select in your reduced message type: VOLUM(Volume) and VOLEH (Volume unit).




9. Display the materialMATALE-## in the PRODUCTION system. Whichchanges 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 inthe Volume and Volume unit fields were not transferred.

d) Check the inbound IDoc in the status monitor as described in steps8. c) to g).

10. Now change the Old material number field in yourMATALE-## materialand then have the system evaluate the change pointers for message typeZMATMAS##. 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→ ChangePointers→ Evaluate.

d) Enter your message type ZMATMAS## and select Execute .

e) IDocs are generated for all materials that were changed since thechange pointer function was activated for your message type.

11. Check the result in the CORE and PRODUCTION systems' statusmonitors. In the segment E1MARAM, what is in the fields Old materialnumber (BISMT), Date of last change (LAEDA), and Last changed by(AENAM), and why?

a) First call one of the outbound IDocs for message type ZMATMAS##in the status monitor in the CORE system. Proceed as in step 8.

b) The change you have made is visible in the field Old material number,because you selected this field in your reduced message type. The fieldsDate of last change and Last changed by, contain �/�. This is becauseyou did not select these fields when creating the reduced message type.

c) To finish, display an inbound IDoc for message type ZMATMAS## inthe PRODUCTION system: the Old material number field containsthe changes you made, the Date of last change and Last changed byfields contain �/�.



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


Unit Summary BIT300

Unit SummaryYou 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


Unit 3Distributing Transaction Data:

Message Control

Unit OverviewTransaction data (documents, postings) can also be distributed beyond systemboundaries using ALE. Message control is one of the methods you can use toimplement cross-system processes. However, you can also use it for electroniccommunication with business partners (suppliers, customers).


� 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 ContentsLesson: Message Control and IDoc Generation.. . . . . . . . . . . . . . . . . . . . . . . . . . .104

Exercise 5: Partner Profiles and Condition Record .. . . . . . . . . . . . . . . . . . .113Lesson: Example: Purchase Order Processing .. . . . . . . . . . . . . . . . . . . . . . . . . . .119

Exercise 6: Sending a Purchase Order to a Vendor .. . . . . . . . . . . . . . . . . .125Exercise 7: Optional: ALE Scenario �Stock Transfer BetweenDistributed Systems� .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129


Unit 3: Distributing Transaction Data: Message Control BIT300

Lesson: Message Control and IDoc Generation

Lesson OverviewThis lesson tells you about message control as an instrument for distributingtransaction 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 ExampleUp to now, your company has sent purchase orders to suppliers by post in paperform. 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 automaticallyconverted into orders after they are received by head office.

ALE and EDI: a ComparisonFor ALE and EDI scenarios you always use the same instrument: the data, suchas purchase orders, order confirmations or invoices, are sent to the respectiverecipient in the IDoc format, or are recevied by your system as IDocs and aresubsequently transferred to the target applications.

Figure 62: EDI: Purchase Order at a Vendor


BIT300 Lesson: Message Control and IDoc Generation

Up to now, the purchase orders at a vendor in our example company have beenprocessed on paper: the purchasing employees create purchase orders in thesystem at head office, possibly on the basis of purchase requisitions from otherdepartments, and send them by post to the vendor. However, in the future thevendor should receive the purchase order data electronically in an EDI standardformat.

In many cases, the external vendors are not part of the company network.Therefore, the electronic communication with them is often by means ofintermediary subsystems, known as EDI converters. SAP provides anopen interface to such systems (CA-EDI). The EDI subsystems assume theresponsibility for all EDI-specific tasks, such as data conversion, partner profilemanagement 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 purchaseorder, the message type is ORDERS. The subsystem reads the IDoc and convertsit into an EDI document. This document is sent to the vendor, whose EDIconverter converts the incoming data into a format that can be processed in thevendor's ERP system. Often an order is automatically created from the data ofthe purchase order received.



Figure 64: Port Types

Many subsystems are capable of communicating with SAP systems by means oftRFC. However, if your subsystem cannot decrypt RFC protocols, you usually usea port of the �file� type. The directory of the operating system, in which incomingand 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 partnertypes LI (vendor) or KU (customer), while the partners in ALE scenarios arealways logical systems (partner type LS).

Figure 65: Partner Profile: Partner Type LI



Thus, for the EDI scenario represented in the first illustration of the lesson, partnerprofiles of partner type LI would be required. When creating such partner profiles,you always refer to the vendor master data. Therefore, if the vendor was createdusing the key T-BIL00, the EDI partner is also called T-BIL00.

Figure 66: Partner Functions

The �vendor� business partner can have various functions with regard to thecompany. During a procurement procedure, a vendor is first the recipient of thepurchase order, then the goods supplier, later the invoicing party and finally thepayment 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. Forthis reason, logistical appliations in SAP R/3 and SAP ECC systems work withpartner functions that are assigned in the partner master data and can be changedin the application documents, if necessary.



Figure 67: Partner Profile for EDI

Therefore, when creating partner profiles for EDI partners, in contrast to ALE,you always have to enter the respective function in which a partner is sendingor receiving a message.

For EDI scenarios, the distribution model you were introduced to as an importantALE element does not play any role. The application programs determinethe recipient of the message from the respective application document. Thecommunication IDoc is then created on the basis of the parameters in the partnerprofiles and processed further - for example, it is stored as a sequential file on theoperating system level.

Message Control: IntroductionThe application mySAP ERP Procurement already enables you to send a purchaseorder by means of a printed form or in IDoc format. For this, the applicationuses a cross-application function packet, the message control. In SAP systems,a message is information that is output in various formats. The purchase orderprinted on paper or sent as an IDoc is only one of many examples of the use ofmessage control in logistics applications. You can also send the informationcontained in your SAP R/3 or SAP ECC documents as a fax or an e-mail toemployees or partners. The format in which the message is output is determinedby the transmission medium, which you define in advance or which you can -depending on the default settings - specify in individual cases before the output.



Figure 68: Transmission Medium

Every time you save a new or altered purchasing document (for example, a requestfor quotation, a purchase order or an outline agreement), the system checkswhether a message has to be created for this document, and in which format - thatis, 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 alwayscreated on the basis of a message type which is defined in the Customizing ofthe respective application. Message types are keys to which the most importantcontrol parameters for determining and subsequently outputting messages arelinked. For example, the message type for outputting purchase document data iscalled NEU (new printing of purchase order).



Figure 69: Message Types

Message types are application-specific. Every application that uses the messagecontrol is indicated by a two-character key. For example, Purchasing, which isresponsible for the purchase order processing, has the key EF. To get an overviewof 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 themessage types defined for an application.

Message DeterminationThe message control works with the condition type, a method of enabling thesystem 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 batchdetermination in the overall logistics. The system also finds messages on the basisof condition records, which are combinations of conditions under which a certainmessage is to be output in a certain format.

The condition type works with what are known as condition elements, which aredependent on one another. The illustration below shows the inner hierarchy of thecondition elements using the example of message control for Purchasing:



Figure 70: Message Control: Condition Elements

The respective application program (for example, �create purchaseorder�) specifies the application (for example, EF). The suitable outputdetermination procedure (for example, RMBEF1), which groupstogether message types on the basis of various perspectives, is foundby means of Customizing tables, depending on the application. Thus,for example, the document type can decide on the procedure to be used.Every message type of a procedure (for example, NEU) is assigned an accesssequence (for example, 0001). Access sequences group together conditiontables. These condition tables contain, in various arrangements, all the documentfields that are to function as conditions for determining the messages in theapplication document. In the example shown, the access sequence 0001 containsthree condition tables which are checked in the sequence specified in the accesssequence. The first condition table in this sequence (27) contains the fieldspurchasing organization and vendor. If you now want to define conditions for thedetermination of the message type NEU, the system now asks you, on the basis ofthe assigned access sequence, for the �key combination�, that is, for the desiredcombination of fields according to the condition table. Depending on the selection,you then have to make certain entries, such as for the purchasing organizationand the vendor. In this way you specify, for example, that the message NEU isalways output in IDoc format when the purchase order is from the purchasingorganization 1000 for the business partner T-BIL00 in his function as vendor (LF).



Along with the transmission medium (see above), you also always have to enter aprocessing time in the condition record. You have a choice of three processingtimes:

� 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 mustcreate appropriate partner profiles for the partner entered there and his function.If you want to use the transmission medium �ALE�, in addition to the partnerprofiles 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 messagedetermination whether a message is to be created. If the transmission medium is�EDI� or �ALE�, the system checks whether suitable partner profiles exist andwhich IDoc type is specified for the data output. If the message determination issuccessful, a message is created. All messages are stored in the database tableNAST. Based on the IDoc basic type specified in the partner profiles, the programRSNAST00 creates a communication IDoc from the data of the purchase order.(If, on the other hand, �print output� were specified, then the corresponding formwould be filled.)



Exercise 5: Partner Profiles and ConditionRecord

Exercise ObjectivesAfter 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 ExampleIn the future, you want to send purchase orders to one of your vendors by meansof EDI.

Task:Create partner profiles for the vendor and then a suitable determination record forthe message type of the purchase order data output.

1. Create partner profiles with the vendor T-K515D## for the messagetype ORDERS. Use the IDoc basic type ORDERS05 and the file portSUBSYSTEM. The IDocs should be transferred to the subsystem together,but this should not be started by the SAP system. The appropriate messagetype has the key NEU. You work on the application level of Purchasing.Which process code is specified? Assign yourself as the agent in the caseof 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 adetermination record for the message type NEU. Messages of this messagetype should always be output if the purchasing organization 1000 ordersgoods from the vendor T-K515D##. The system should output the messagein IDoc format by means of EDI. The IDoc should be generated immediatelyafter a purchase order is created.




4. Optional: How do you proceed if you also have an agreement with yourvendor T-K515D## that in future he should send you order confirmationsby EDI for your purchase orders?

Hint: If necessary, use the input help for the Message type field tolook for a suitable message type using the short description �Orderconfirmation�. You can also use the short description to determinethe appropriate process code.



Solution 5: Partner Profiles and ConditionRecordTask:Create partner profiles for the vendor and then a suitable determination record forthe message type of the purchase order data output.

1. Create partner profiles with the vendor T-K515D## for the messagetype ORDERS. Use the IDoc basic type ORDERS05 and the file portSUBSYSTEM. The IDocs should be transferred to the subsystem together,but this should not be started by the SAP system. The appropriate messagetype has the key NEU. You work on the application level of Purchasing.Which process code is specified? Assign yourself as the agent in the caseof 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 thepartner 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 theIDoc basic type ORDERS05. If they are not already selected, chooseCollect 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 helpfor 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 youruser BIT300-## (agent type US) and a notification language of yourchoice. Save these changes.




2. Get the system to check the partner profiles you have just created.

a) If necessary, open the folder for the partner type LI and select yourvendor T-K515D##.

b) Choose Check , then choose Execute in the window displayed:you obtain a detailed log of the check on your settings.

3. In the application menu of Purchasing (purchase orders), create adetermination record for the message type NEU. Messages of this messagetype should always be output if the purchasing organization 1000 ordersgoods from the vendor T-K515D##. The system should output the messagein IDoc format by means of EDI. The IDoc should be generated immediatelyafter a purchase order is created.

a) Choose Logistics→ Materials Management→ Purchasing→ MasterData→ 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 thedetermination record by saving.

Hint: If you leave the Language field empty, the system usesthe language of the vendor in his master record.




4. Optional: How do you proceed if you also have an agreement with yourvendor T-K515D## that in future he should send you order confirmationsby EDI for your purchase orders?

Hint: If necessary, use the input help for the Message type field tolook for a suitable message type using the short description �Orderconfirmation�. You can also use the short description to determinethe appropriate process code.

a) Choose Tools→ ALE→ ALE Administration→ Runtime Settings→ Partner Profiles.

b) Open the folder for the partner type LI and select your vendorT-K515D##.

c) In the inbound parameter area, select Create inbound parametersand first enter the partner role LF again.

d) Call up the input help for the field Message type and open the detailsin the Restrictions tab page by clicking on the small triangle in thebar below the tab page.

e) In the field Short text, enter *Order confirmation* and pressEnter to confirm: The system prompts you with, among other things,the message type ORDRSP (Purchase order/Order confirmation).Select the default and accept it with Enter.

f) Now call up the input help for the field Process code and follow theshort description of the process: The suitable process code has thekey ORDR (ORDRSP Sales order confirmation). Accept it with adouble-click and save your changes.



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


BIT300 Lesson: Example: Purchase Order Processing

Lesson: Example: Purchase Order Processing

Lesson OverviewThis 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 toone 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 ExampleThe sales branch regularly orders stock replenishments at head office forprocessing its customer orders; head office is where the main warehouse of thecompany is located. In the future, these purchase orders should be sent to headoffice using ALE and be automatically converted into orders there. The salesbranch receives an electronic order confirmation by return. The purchase ordersat vendors are also created electronically by head office, but by means of anEDI connection.

Message Control: Transmission Media �ALE� and�EDI�Logistical applications in SAP R3 and SAP ECC systems can use the messagecontrol to generate IDocs for sending transaction data. The system transfers thedata of an application document into the fields of the IDoc on the basis of therespective IDoc basic type. Then the IDoc can be sent to either a business partneror another logical system within the company.



Figure 72: Example: Sending a Message in EDI Format

Here you see the transmission of an IDoc to an external vendor by means of anEDI converter. Therefore, the transmission medium �EDI� (6) was entered in themessage determination record. In addition, there must also be partner profilesfor the partner type �vendor� (LI) to which a receiver port is assigned, whichrepresents a connection to the EDI converter, or which contains a directory forstoring IDocs as sequential files.

Figure 73: Partner Profiles with an External Vendor



If, on the other hand, the transmission medium of the determination recordsis �ALE� (A), then suitable partner profiles with a logical system (partner typeLS) must be created. The field Partner role remains empty. The settings for thegeneration of an IDoc (IDoc basic type and process code) are identical. The portis 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 mustbe a process code for the outbound processing. This process code is used todetermine the function module that subsequently uses the entry created by themessage determination in the table NAST (�NAST record�) to determine therelevant application data and create the master IDoc.

Note: The attribute With ALE services in the process code is used tocontrol whether you can adapt the IDoc using the ALE services �segmentfiltering� and �field conversion�. If this attribute is not set, the masterIDoc is transferred unchanged into the data section of the communicationIDoc and stored on the database.

For ALE scenarios in which transaction data is to be sent with the aid of messagecontrol, you must create or expand corresponding views in the distribution modelof the maintenance system and then distribute them to the respective receivingsystems.



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 systemCORE). After receiving and checking the purchase orders, head office sends orderconfirmations (message type ORDRSP) to Sales and Distribution.

Message Determination in Ordering and IDocGenerationWhen creating a purchase order, the system performs message determination onthe basis of the application-specific Customizing settings for message control.If this determination is successful, you can immediately call up the result fromthe application document (menu entry Goto→ Messages or button Messages inthe initial screen).



Figure 76: IDoc Generation using Message Control

If the transmission medium �ALE� or �EDI� is assigned in the determinationrecord, a master IDoc is created from the NAST record on the basis of theoutbound parameters of the corresponding partner profiles. The transaction codecontrols which application function module is used to generate this IDoc. Theapplication document key is transferred from the NAST record to this applicationfunction module. The module reads the document data and transfers it into thesegment fields of the master IDoc. If the processing time 4 was entered in thedetermination record, the system executes the program RSNAST00 immediatelyafter you save, in order to generate an IDoc from the NAST record. If theprocessing time 1 is specified, only a NAST record is created for now. Theprogram 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 ofthe communications IDoc, and a control record and a status record are added toit. The communication IDoc is then saved on the database and, depending on thesettings in the partner profiles, sent immediately or later.

ALE Scenario: Stock Transfer Between Two SystemsIn SAP R/3 or SAP ECC systems, you will find support for the configuration of anALE scenario �Stock transfer between two systems�. You can use this scenarioif sales branches or production sites are separated from one another or from thecentral warehouse or the central Sales and Distribution not only physically, butalso in terms of the systems involved.



Figure 77: Scenario: Stock Transfer Between Two Systems

With this scenario, you can represent the following basic process: The branchorders goods from head office. The incoming purchase order in IDoc format(message type ORDERS) is automatically converted into a sales order bythe receiving system. The logical system of head office also automaticallysends an order confirmation (message type ORDRSP) to the branch. Theinbound processing of the order confirmation is updated in the purchaseorder: The purchasing area agent usually sees the document number of thesales order of head office on the document item level of his purchase order.At head office, if the goods are available, a delivery is created for the sales order.The message control can be used to automatically send a shipping notification inIDoc format for this delivery (message type DESADV) to the branch. Dependingon the settings in the system of the branch, an inbound delivery - an additionalSAP document - is created there during the IDoc inbound processing, or else acorresponding note is entered in the purchase order. After the goods are shipped tothe branch, the head office can also transfer the invoice electronically (messagetype INVOIC). If the inbound processing of the IDoc at the branch is successful,an incoming invoice is automatically posted.



Exercise 6: Sending a Purchase Order toa Vendor

Exercise ObjectivesAfter completing this exercise, you will be able to:� Send a purchase order in IDoc format to an external vendor

Business ExampleThe central purchasing department of the company orders goods from a vendor bymeans of an EDI connection.

Task:Create a purchase order to an external vendor in the system at companyheadquarters and check whether an IDoc was generated with the data of thispurchase order.

1. In the CORE system, create a purchase order at the vendor T-K515D## for100 pcs. of the material T-M15A## for the plant 1000. You work for thepurchasing organization 1000 and the purchasing group 001 in the companycode 1000. Which message type is found, and how is the message to beprocessed?

Message type: _______

Transmission medium: _______

2. Check the outbound processing of the IDoc in the purchase order. Whatstatus 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 doesthe IDoc have now? What is the text for this status?

Hint: You will find the text under the heading Error text.



Solution 6: Sending a Purchase Order toa VendorTask:Create a purchase order to an external vendor in the system at companyheadquarters and check whether an IDoc was generated with the data of thispurchase order.

1. In the CORE system, create a purchase order at the vendor T-K515D## for100 pcs. of the material T-M15A## for the plant 1000. You work for thepurchasing organization 1000 and the purchasing group 001 in the companycode 1000. Which message type is found, and how is the message to beprocessed?

Message type: _______

Transmission medium: _______

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

b) Enter the vendor T-K515D## and confirm your entry with Enter.

c) On the Org.data tab page, enter the purchasing organization 1000, thepurchasing group 001 and the company code 1000.

d) Choose Item overview , enter the material T-M15A##, the orderquantity 100 and the plant 1000 and confirm these entries with Enter.

e) Choose the Output button: The output type NEU was found. Themessage is to be output by means of EDI (transmission medium 6).

f) Create the purchase order by saving.

2. Check the outbound processing of the IDoc in the purchase order. Whatstatus does the IDoc have? Also note the IDoc number.

Status: ____




Number: ________________

a) Choose Logistics→ Materials Management→ Purchasing→Purchase Order→ Display.

b) Choose the Messages button: The message should have the statusSuccessfully processed. Choose Back .

c) In the menu, choose System→ Services for Object and then Displaylinks : The number of the outbound IDoc is displayed.

d) Double-click the number of the IDoc to call it up for display. It has thestatus 30 (IDoc is ready to be sent).

3. Display your IDoc in the status monitor as well and send it. What status doesthe IDoc have now? What is the text for this status?

Hint: You will find the text under the heading Error text.

a) Choose Tools→ ALE→ ALE Administration→ Monitoring→ IDocDisplay→ Status Monitor.

b) Enter the number from step 2 in the field IDoc number and chooseExecute .

c) Select the row under the output type ORDERS and choose the Processbutton.

d) Confirm the message on your selection with Enter: The IDoc nowhas the status 03 (Data passed to port OK). The �error text� is: IDocwritten to file. You can also find out the file path using the Error longtext button.



Exercise 7: Optional: ALE Scenario�Stock Transfer Between DistributedSystems�

Exercise ObjectivesAfter completing this exercise, you will be able to:� Create a sales order from a purchase order using ALE

Business ExampleSales and Distribution regularly orders stock replenishments at head office forprocessing its customer orders; head office is where the main warehouse of thecompany is located. These purchase orders are sent to head office using ALE andare 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 automaticallycreated order in the head office system. Also check the updating of the purchaseorder 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 1000for the plant 1000. You belong to the purchasing group 001. The responsiblecompany code is 1000. Check the results of the message determination:Which message type was found? Which transmission medium is used? Makea 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 sendersystem. Search for the IDoc using the business object type PurchaseOrderand your document number from step 1. Check the content of individualsegments and compare them with your purchase order.

3. In the CORE system, check whether a sales order was created for thepurchase order of the SALES system. Use your purchase order numberfrom step 1 as the search criterion. Make a note of the document number ofthe order: ______________




4. Was an order confirmation also created in the CORE system and sent to theSALES system? Check the results of the message determination in the order.

5. In the CORE system, you now display the outbound IDoc for the orderconfirmation using the object services in the order. Then check the purchaseorder in the SALES system: What has changed?

Hint: In the purchase order, check the Confirmations tab page onthe document item level.



Solution 7: Optional: ALE Scenario �StockTransfer 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 automaticallycreated order in the head office system. Also check the updating of the purchaseorder 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 1000for the plant 1000. You belong to the purchasing group 001. The responsiblecompany code is 1000. Check the results of the message determination:Which message type was found? Which transmission medium is used? Makea 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 documentheader level, enter the purchasing organization 1000, the purchasinggroup 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 orderquantity 100 and the plant 1000. Confirm your entries with Enter.

d) Choose the Output button: The output type NEU was found. Thetransmission medium is A. Create the purchase order by saving.




2. Display the outbound IDoc in the status monitor of the SALES sendersystem. Search for the IDoc using the business object type PurchaseOrderand your document number from step 1. Check the content of individualsegments and compare them with your purchase order.


b) In the field Business object, enter PurchaseOrder, and in the fieldObject key enter the purchase order number from step 1, then chooseExecute .

c) An IDoc for the message type ORDERS should be found underOutbound IDocs. Select the entry underneath the message type andchoose the Display IDocs button.

d) Select the IDoc and choose the Display IDocs button again. Open theData records folder to display the segments of the IDoc.

3. In the CORE system, check whether a sales order was created for thepurchase order of the SALES system. Use your purchase order numberfrom step 1 as the search criterion. Make a note of the document number ofthe order: ______________

a) Choose Logistics→ Sales and Distribution→ Sales→ Order→Change.

b) In the Search criteria area, enter your purchase order number from step1 in the corresponding field and choose Perform search.

c) Select the search result and accept it with Enter: You now enter theoverview screen of the order that was created from the data of thepurchase order.

4. Was an order confirmation also created in the CORE system and sent to theSALES 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.) andimmediately processed it into an IDoc when creating the order.




5. In the CORE system, you now display the outbound IDoc for the orderconfirmation using the object services in the order. Then check the purchaseorder in the SALES system: What has changed?

Hint: In the purchase order, check the Confirmations tab page onthe document item level.

a) Choose System→ Services for Object and then choose Display links .

b) Double-click the number of the outbound IDoc of the message typeORDRSP 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 theOrder confirmation field you will see the document number of the salesorder from the CORE system.



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


BIT300 Unit Summary

Unit SummaryYou 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


Unit Summary BIT300


Unit 4Distributing Transaction Data: BAPIs

Unit OverviewThis unit explains how transaction data in a system landscape can be distributedin ALE using preconfigured interfaces to business object types, the BusinessApplication Programming Interfaces (BAPIs).


� 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 ContentsLesson: Business Object Types and BAPIs .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138Lesson: The Usage of BAPIs in ALE.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145Lesson: Example: Travel Expenses... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

Exercise 8: Trip Cost Accounting with Two Systems ... . . . . . . . . . . . . . . .161Exercise 9: ALE Scenario for Setting Up Travel Expenses .. . . . . . . . . .165


Unit 4: Distributing Transaction Data: BAPIs BIT300

Lesson: Business Object Types and BAPIs

Lesson OverviewThis lesson introduces business object types and BAPIs. You will find out howto search for and find BAPIs, and how to recognise whether an asynchronousALE 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 ExampleYou want to set up a business process in a distributed system landscape. For thispurpose, you look for corresponding inbound interfaces in receiving systems andcheck 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 businessprocesses. For the technical integration, it is necessary to have a more in-depthunderstanding of the underlying technology (business objects and options foraccessing business objects).


BIT300 Lesson: Business Object Types and BAPIs

Figure 78: Business Object Type - Definition

The business object types are an important part of the Internet Business Frameworkand are prerequisites for interoperability. Business object types cover a widespectrum of SAP business data and processes, and they can be used by means ofstandardized methods - the BAPIs. The business object types and their BAPIs thusprovide 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 withdifferent layers: At the center of the business object type is the kernel, whichrepresents the inherent data of the object.



The second layer, the integrity layer, represents the business logic of the object. Itcomprises of the business rules for the consistent embedding in the environmentand the constraints with regard to the values and areas relating to the businessobject type.

The third layer, the interface layer, describes the implementation and structure ofthe 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. Thislayer defines the technologies that can be used for external access to the data of theobject type - for example, COM/DCOM (Component Object Model/DistributedComponent 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 belongto the business object type �employee�. An employee with the employee number4711 is an instance of the business object type �employee� and is designateda business object.



Figure 81: Business Object Repository (BOR)

All the business object types and their methods are defined in the Business ObjectRepository (BOR) within SAP systems. The BOR was first introduced in SAP R/33.0, at the same time as the introduction of the business object types and the SAPWorkflow. 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 applicationcomponents, such as Sales and Distribution and Materials Management.

� Technical object types

These are elements such as texts, work items, archived documents, as well asdevelopment and modeling objects.

With the introduction of the BAPIs in SAP R/3 3.1, the importance of BORincreased. It is now the central point of access to the business object types andtheir BAPIs in SAP systems for external applications.

What is a BAPI?External applications can access business objects in SAP systems throughstandardized, platform-independent interfaces - BAPIs. The business object typesand their BAPIs provide an object-oriented view of the business processes anddata in an SAP System.



Figure 82: Interfaces of Business Object Types

A BAPI is a standard interface that provides access to the business data andbusiness 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 businessobject 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 typesand their related BAPIs. In the application menu, choose Tools→ BusinessFramework→ BAPI Explorer or call the transaction BAPI directly.



Figure 84: BAPI Explorer

The display of the BAPI Explorer is divided into a hierarchy area and a detailwindow. The component hierarchy is displayed in the hierarchy area. You canopen the folders of the application components and obtain the business objecttypes belonging to each respective component. If you open the directory of abusiness object type, you see a subtree with its key attributes and its API methods.(API stands for Application Programming Interface.)



Lesson Summary

You should now be able to:� Explain the terms �business object type� and �BAPI�� Determine business object types and BAPIs using the BAPI Explorer, and

also determine detailed information on BAPIs


BIT300 Lesson: The Usage of BAPIs in ALE

Lesson: The Usage of BAPIs in ALE

Lesson OverviewThis lesson shows how BAPIs can be used in an ALE scenario to realizesynchronous 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 ExampleYou want to configure an ALE scenario in which the transaction data is distributedusing BAPIs.

Synchronous Communication with BAPIsSince SAP R/3 4.6, BAPIs are realized as function modules. You can use theBAPI Explorer to navigate to the display of the function module for the selectedBAPI in the �Function Builder�:

Figure 85: BAPI Function Modules

BAPIs can be used for the synchronous communication between two systems.



Figure 86: Synchronous call of a BAPI

For the synchronous call of a BAPI within an ALE scenario, the following stepsmust be realized in the application program:

1. Querying the distribution model:

The application program determines the receiver and, if applicable, filtervalues for filter objects from the distribution model. If the BAPI is notcontained 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, theapplication program of the calling system determines the RFC destination forthis remote system from a table, which you can find by using the transactionBD97 or in the IMG in the Customizing of the ALE (transaction SALE) bymeans of the path IDoc Interface / Application Link Enabling (ALE)→Communication→ Determine RFC Destinations for Method Calls.

3. Calling up the BAPI function module using RFC:

The calling system transfers the application data by means of RFC by callingup the BAPI function module in the target system.



Figure 87: RFC Destinations for Synchronous Method Calls

You can use the transaction BD97 to assign a standard destinationfor BAPIs to a target system. All BAPI calls for which no specificdestination has been entered use this destination. The RFC user for thestandard 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 usingthe Add BAPIs button.

Figure 88: Distribution Model: Adding BAPIs

Along with the sending and receiving systems, you enter in the model view thename of the business object type involved and the desired method, that is, theBAPI. In the fields Business object type and Method you enter the name from theBAPI Explorer and not the technical names of the business object types fromthe �Business Object Builder�.



Asynchronous Communication with BAPIs

Figure 89: Asynchronous Call of a BAPI in the Target System

In order to call a BAPI asynchronously in the target system, an IDoc is sent to thetarget system. This contains the interface parameters of the BAPI, and in the caseof instance methods, the key fields of the business object. In the target system, theBAPI 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 ALEmessage type in the detail view of of the BAPI Explorer. In this way you call thetransaction BDBG, with which you can display the existing ALE interfaces ofBAPIs, but can also generate new interfaces.

In the transaction BDBG, you select the Display interface button to display theautomatically generated elements of the ALE interface of a BAPI.



Figure 91: ALE Interface of a BAPI

The following elements are part of the generated ALE interface of a BAPI:

� Message type:

Message types of the ALE interface of BAPIs are not directly assigned toa model view. They are used exclusively in the partner profiles betweensending and receiving systems. The BAPIs themselves are assigned in thedistribution model (see above).

� IDoc type: The IDoc type is the basis of the IDoc required for theasynchronous communication with BAPIs.

� Segment types: The elementary import parameters are grouped togetherin a segment type. A segment type is created for every structured importparameter.

� Function module for ALE output: In the outbound function module, theinterface parameters are copied into the IDoc segments and a master IDoc iscreated. Then a function module is called that transfers this master IDoc tothe ALE layer.

� Function module for ALE input: The inbound function module copies thecontents of the segment fields onto the related interface parameters and callsthe BAPI function module locally in the target system.



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

The following steps are carried out in the application program:

1. After the application data is determined, the receiving system and any filtervalues for filter objects from the distribution model of the sending systemare determined.

2. Subsequently, the generated outbound function module of the ALE interfaceof the BAPI is called. This module creates the master IDoc and transfersit to the ALE layer.

The communication IDoc is created in the same way as in the non-BAPI-basedALE scenarios: For the message type of the BAPI, there must be partner profileswith the recipient system in which the generated IDoc basic type of the ALEscenario of the BAPI, and a suitable RFC port, are assigned.



Figure 93: Sending the Communication IDoc

The communication IDoc is sent by means of RFC immediately or later, dependingon the specifications in the partner profiles with the receiving system.

Figure 94: Inbound Processing of an IDoc for a BAPI Call



In the receiving system, the IDoc is stored on the database. Depending on thesetting 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 learnsthat the input function module of the ALE interface generated for the BAPI is tobe called. The inbound function module copies the contents of the segment fieldsof the IDoc onto the BAPI interface parameters and then calls the BAPI functionmodule locally.

Figure 95: Outbound Partner Profile in the Sending System

If possible, generate the partner profiles of BAPI-based ALE scenarios from thedistribution model. The system then enters the message type and IDoc typerelevant to the BAPI.



Figure 96: Inbound Partner Profile in the Receiving System

Also generate the partner profile in the receiving system from the distributionmodel: The system assigns the process code BAPI.



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


BIT300 Lesson: Example: Travel Expenses

Lesson: Example: Travel Expenses

Lesson OverviewThis lesson explains the configuration of the ALE scenario �Transferring theaccounting results of the travel expenses to Accounting�. This scenario usesBAPIs for both the synchronous and the asynchronous communication.


� To describe the configuration of the ALE scenario �Transferring theaccounting results of the travel expenses to Accounting�.

Business ExampleYour company has moved the human resources to its own system. The employeesenter the costs for their business trips in the Travel Management of this system. Inthe future, the results of the travel expenses are to be transferred to the Accountingsystem using ALE.

Travel Expenses: ProcessThe Travel Management is part of the mySAP ERP Financials application, butit also affects human resources. For this reason, you will find the applicationtransactions for using the functions of Travel Management in the reporting menusof both applications.

It is not absolutely necessary to systematically separate the Travel Managementfrom the other applications of Accounting. However, it is not infrequentlyassigned to the separately operated system for human resources (in the exampleHR_TRAVEL). If the systems are thus separated, then the results of the travelexpenses must be transferred to the Accounting system (in the example: CORE)for posting and for the subsequent payout of reimbursement amounts. In SAPR/3 and SAP EEC, you are provided with the pre-configured ALE scenario�Transferring the accounting results of the travel expenses to Accounting� forthis process.



Figure 97: Travel Expenses: Posting Procedure

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

� Entering the trip costs: In the Travel Management, the employee entersthe details (start and end of trip, destination, expenses for accommodation,transport, and so on) of his business trip (�Create trip�).

� Authorization of trip: The supervisor or personnel department employeeauthorizes the reimbursement of costs (�Authorize trip�).

� Accounting of trip: The personnel department gets the system to calculatethe reimbursement amounts. Among other things, this step takes into accountthe daily rates for calculating expenses stored in the system (�Settle trip�).

� Creating the posting run: When creating what is known as the postingrun, the trip cost management system performs synchronous BAPI calls.In this way it checks, among other things, whether the accounts on whichthe postings are to be made, the account assignment objects of Controllingdetermined in the travel expenses, and the vendor master records requiredfor the reimbursement of expenses, exist in the Accounting system for thepersonnel numbers of the employees on the trip.

� Checking the posting run: In order to ensure that postings are allowed tobe made on the accounts and account assignment objects of Accountingat the time of the actual settlement data transfer, the Travel Managementsystem can perform additional synchronous BAPI calls.



� Posting the posting run: Finally, the Travel Management system transfersthe results of the settlement to the Accounting system. The BAPIs usedby the system in this step are called asynchronously, in the course of IDocinbound processing.

Note: A posting run is a kind of �container� for the documents in whichthe the results of the travel expenses are kept. Every posting run is given aunique, sequential number by the system.

Required PresettingsFor the ALE scenario �Transferring the accounting results of the travel expensesto Accounting� to function, a necessary prerequisite is the advance distribution ofthe master data required in both systems (personnel master data, cost centers). Inaddition, 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 throughtransaction SALE. Then choose IDoc Interface / Application Link Enabling (ALE)→ Modelling and Implementing Business Processes→ Configure Predefined ALEBusiness Processes→ Human Resources→ HR <-> AC→ Set Up Trip CostsTransfer to FI.



Details of the Posting Run for the Travel ExpensesTo be able to create a posting run in the system of the Travel Management, youtransfer the relevant BAPIs (see figure below) into a corresponding view of thedistribution model in the maintenance system and assign the target system of thesesynchronous 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 thedistribution model and assign the target system of the synchronous method call anRFC destination using the transaction BD97.



Figure 100: Model View: Checking a Posting Run

To post a posting run in the Accounting system, you transfer the relevant BAPIsinto a view of the distribution model and generate the partner profiles for the IDocgeneration in the sending and receiving systems.

Figure 101: Model View: Posting a Posting Run



When you display the trip transfer documents in the Travel Management systemafter transferring the posting run to the Accounting system, a traffic light will tellyou whether the data transfer was successful.



Exercise 8: Trip Cost Accounting with TwoSystems

Exercise ObjectivesAfter 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 ExampleYour company has moved the human resources to its own system. Business tripsare recorded in the SAP Travel Management of this system and subsequentlytransferred to the Accounting system for reimbursement purposes.

Task:In the logical system HR_TRAVEL, enter the data of a business trip, settle thisbusiness trip, and transfer the settlement data to the logical system CORE forposting in Accounting.

Caution: When the trip costs are being transferred to Accounting,the system checks that the receiver is unique. Therefore, a test run isperformed with the model view that the instructor created. Exercise 2,in which you create a new view in the distribution model with all theBAPIs required for the ALE scenario, must therefore be performed afterthis exercise.

1. In the HR_TRAVEL system, create a new trip for the employee with thepersonnel number 60995##. Enter the costs for accommodation and taxis.The trip was in the previous week and took two days. Write down thenumber of the trip: ___________

2. Approve the reimbursement of the trip costs you have just entered and thenperform 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 systemCORE.

5. Then display the inbound IDoc in the status monitor of the logical systemCORE. You can also directly access your IDoc using the transaction IDocSearch for Contents (transaction code WE09). Using the IDoc basic typeACC_EMPLOYEE_PAY01, select the segment E1BPACHE06, segmentfield USERNAME, and enter your user BIT300-## as an additional searchcriteria.



Solution 8: Trip Cost Accounting with TwoSystemsTask:In the logical system HR_TRAVEL, enter the data of a business trip, settle thisbusiness trip, and transfer the settlement data to the logical system CORE forposting in Accounting.

Caution: When the trip costs are being transferred to Accounting,the system checks that the receiver is unique. Therefore, a test run isperformed with the model view that the instructor created. Exercise 2,in which you create a new view in the distribution model with all theBAPIs required for the ALE scenario, must therefore be performed afterthis exercise.

1. In the HR_TRAVEL system, create a new trip for the employee with thepersonnel number 60995##. Enter the costs for accommodation and taxis.The trip was in the previous week and took two days. Write down thenumber of the trip: ___________

a) Choose Human Resources→ Travel Management→ Travel Expenses→ Travel Expense Manager.

b) Enter the personnel number 60995## and confirm the entry withEnter.

c) Choose Create to call up the screen for entering the trip costs.

d) Enter a date in each of the fields Start and Finish. Next, in theExpTy field, enter HOTL and in the Amount field the total cost of theaccommodation. Confirm these entries with Enter.

e) In the Description field, enter a text of your choice and select Enteragain to leave the detail screen.

f) Next, in the ExpTy field, enter TAXI and in the Amount an amountof your choice. Create the trip by saving and make a note of the tripnumber.

2. Approve the reimbursement of the trip costs you have just entered and thenperform 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 settlementperiod and make a note of the period.




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

a) Choose Human Resources→ Travel Management→ Travel Expenses→ Periodic Processing→ Transfer to Accounting→ Create PostingRun.

b) Enter the payroll area D2, choose Other period and enter the periodfrom step 2. Also enter the personnel number 60995## and thenumber of the trip from step 1 and choose Execute .

c) If the synchronous check of the accounts, account assignment objectsand HR payee assignment for the personnel number was successful,you will see a green traffic light for the number of the posting run.Leave the transaction.

4. Now transfer the settlement results to Accounting in the logical systemCORE.

a) Choose Human Resources→ Travel Management→ Travel Expenses→ Periodic Processing→ Transfer to Accounting→ Manage PostingRuns.

b) Select Execute to display your posting run from step 3.

c) Select your posting run and choose the Post button. Answer the queryon the processing time by choosing the Post immediately button: If thetransfer was successful, you will see a green traffic light with the textPosting run completely transferred to target system CORE.

5. Then display the inbound IDoc in the status monitor of the logical systemCORE. You can also directly access your IDoc using the transaction IDocSearch for Contents (transaction code WE09). Using the IDoc basic typeACC_EMPLOYEE_PAY01, select the segment E1BPACHE06, segmentfield USERNAME, and enter your user BIT300-## as an additional searchcriteria.

a) In the CORE system, choose Tools→ ALE→ ALE Administration→ Monitoring→ IDoc Display→ Status Monitor to call the statusmonitor, or Tools→ ALE→ ALE Administration→ Services→ IDocSearch for Contents to go to transaction WE09.

b) In the field Basic type enter ACC_EMPLOYEE_PAY01, in the fieldSearch in segment enter E1BPACHE06, in the field Search in field enterUSERNAME and in the field For value enter your user BIT300-##and choose Execute .

c) Click on the number of the IDoc to display the details.



Exercise 9: ALE Scenario for Setting UpTravel Expenses

Exercise ObjectivesAfter 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 ExampleYour company has moved the human resources to its own system. Business tripsare recorded in the SAP Travel Management of this system and subsequentlytransferred 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� andmake 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

VendorCustomerAcctngEmplyeePaybles

AcctngEmplyeeRcvbles

AcctngEmplyeeExpnses




3. In the BAPI Explorer, check for which of the BAPIs entered in the abovetable there is an ALE interface. Note the names of the assigned messagetypes.

BAPI Message type

Task 2:In the logical system CORE, define a new logical system CORE## and thencreate a model view with this logical system as the target system of the methodcalls determined in the first task.

Hint: To be able to perform this exercise with different exercise groups,we have to use a little trick: All the groups are to set up the distributionbetween the systems HR_TRAVEL and CORE. However, just likemessage types, BAPIs may only appear in one view of the distributionmodel in the relationship between two logical systems. For this reason,you use the logical system CORE## as the target system, but you enter aport to which an RFC destination of the system CORE is assigned.

1. In the logical system CORE, you define the logical system CORE##, butyou do not assign it to any client.

2. Is this logical system name now known in the logical systemHR_TRAVEL?If applicable, also create CORE## in HR_TRAVEL.

3. In the distribution model of the system CORE, create a new view withthe short text BIT300BAPI## and the technical name BAPI##. Add theBAPIs that you determined in the first task. The sender is the systemHR_TRAVEL, and the receiver the system CORE##.




Task 3:Distribute the new model view to the system HR_TRAVEL and there you createthe corresponding partner profiles. You also add an RFC destination to the systemCORE## for synchronous method calls.

1. Distribute the new model view to the logical system HR_TRAVEL andcheck the result.

Caution: Do not distribute the view to the logical system CORE##,because this logical system is not assigned to a client.

2. In the logical system HR_TRAVEL, create outbound partner profiles withthe partner CORE## for the message type SYNCH. The receiving port isCORE with the RFC destination of the same name.

3. In the logical system HR_TRAVEL, you now generate the outbound partnerprofiles 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 thelogical system HR_TRAVEL for the message types for asynchronouscommunication. Which process code is assigned? Why do you not need anyseparate inbound partner profiles for the logical system CORE##?

5. In the HR_TRAVEL system, which RFC destination do you have to assignto the logical system CORE## for synchronous method calls? Add thecorresponding entry.



Solution 9: ALE Scenario for Setting UpTravel ExpensesTask 1:In the IMG documentation, search for the description of the ALE scenario�Transferring the accounting results of the travel expenses to Accounting� andmake a note of the BAPIs required for this scenario.

1. In the IMG documentation, search for the description of the ALE scenario�Transferring the accounting results of the travel expenses to Accounting�.

a) Call the transaction SALE and choose IDoc Interface / Application LinkEnabling (ALE)→Modelling and Implementing Business Processes→Configure Predefined ALE Business Processes→ Human Resources→HR <-> AC→ Set Up Trip Costs Transfer to FI→ Travel Managementand Accounting are Release 4.5A or Later.

b) Choose Documentation for IMG activity .

2. Which BAPIs are involved in the transfer of the trip costs to Accounting?Make a note of the BAPIs for the business object types used for the steps�Create posting run�, �Check posting run� and �Post posting run�.

Business object type Method (BAPI)AcctngServices PreCheckPayrollAccountAssignVendor FindCustomer FindAcctngEmplyeePaybles Check

PostAcctngEmplyeeRcvbles Check

PostAcctngEmplyeeExpnses Check

Post

3. In the BAPI Explorer, check for which of the BAPIs entered in the abovetable there is an ALE interface. Note the names of the assigned messagetypes.




BAPI Message typeAcctngEmplyeeExpnses.Post ACC_EMPLOYEE_EXPAcctngEmplyeePaybles.Post ACC_EMPLOYEE_PAYAcctngEmplyeeRcvbles.Post ACC_EMPLOYEE_REC

a) Choose Tools→ Business Framework→ BAPI Explorer.

b) Select the tab page Alphabetical and expand each of theentries for the business object types AcctngEmplyeeExpnses,AcctngEmplyeePaybles and AcctngEmplyeeRcvbles.

c) Select each respective entry for the method Post: You will find themessage 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 thencreate a model view with this logical system as the target system of the methodcalls determined in the first task.

Hint: To be able to perform this exercise with different exercise groups,we have to use a little trick: All the groups are to set up the distributionbetween the systems HR_TRAVEL and CORE. However, just likemessage types, BAPIs may only appear in one view of the distributionmodel in the relationship between two logical systems. For this reason,you use the logical system CORE## as the target system, but you enter aport to which an RFC destination of the system CORE is assigned.

1. In the logical system CORE, you define the logical system CORE##, butyou do not assign it to any client.

a) Call the transaction SALE and choose IDoc Interface / Application LinkEnabling (ALE)→ Basic Settings→ Logical Systems→ Define LogicalSystem. Confirm the message about client independence with Enter.

b) Choose the New entries button, enter the logical system name CORE##and a name of your choice and save your entry.

c) In the screen prompting the workbench request, choose Create Request, enter a short description of your choice and choose Save . Then

choose Continue or Enter and leave the table.




2. Is this logical system name now known in the logical systemHR_TRAVEL?If applicable, also create CORE## in HR_TRAVEL.

Answer: This depends on whether you are working with one or more SAPsystems in the course.

� If you are using clients in two SAP systems: The logical system nameCORE## must also be defined in the logical system HR_TRAVEL.

� If you are only using clients of one SAP system: The logical systemname CORE## is already known in the system HR_TRAVEL, becausethe logical system names are saved in a cross-client table.

3. In the distribution model of the system CORE, create a new view withthe short text BIT300BAPI## and the technical name BAPI##. Add theBAPIs that you determined in the first task. The sender is the systemHR_TRAVEL, and the receiver the system CORE##.

a) Call the transaction SALE and choose IDoc Interface / Application LinkEnabling (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 nameAcctngEmplyeeExpnses and the method Check, and confirmyour entries with Enter.

f) In this way, you add the remaining BAPIs that you require for the ALEscenario. Create the new model view by saving.

Task 3:Distribute the new model view to the system HR_TRAVEL and there you createthe corresponding partner profiles. You also add an RFC destination to the systemCORE## for synchronous method calls.

1. Distribute the new model view to the logical system HR_TRAVEL andcheck the result.




Caution: Do not distribute the view to the logical system CORE##,because this logical system is not assigned to a client.

a) In the distribution model of the system CORE, select the new modelview 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 successfuldistribution of the view to the system HR_TRAVEL.

c) In the system HR_TRAVEL, call the distribution model for display, asdescribed in task 2.

Hint: If your BAPI## view has not been distributed, thiscould be because the message type SYNCH does not existin the partner profiles of the system CORE with the systemHR_TRAVEL, or because the RFC destination does not leadto the client of the system HR_TRAVEL.

2. In the logical system HR_TRAVEL, create outbound partner profiles withthe partner CORE## for the message type SYNCH. The receiving port isCORE 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 partnertype 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 andsave your changes. Leave the partner profile maintenance.




3. In the logical system HR_TRAVEL, you now generate the outbound partnerprofiles 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 theautomatically created partner profiles.

c) To create the partner profiles manually, choose Environment→ ChangePartner Profile.

d) Select the partner CORE## and in the outbound parameter area, chooseCreate Outbound Parameter .

e) Enter the message type ACC_EMPLOYEE_EXP, the port CORE andthe IDoc type ACC_EMPLOYEE_EXP01, select the immediateprocessing, and create the partner profiles by saving. Proceed inthe same way with the message types ACC_EMPLOYEE_RECand ACC_EMPLOYEE_PAY. The corresponding IDoc types areACC_EMPLOYEE_REC01 and ACC_EMPLOYEE_PAY01respectively.

4. In the logical system CORE, check the inbound partner profiles with thelogical system HR_TRAVEL for the message types for asynchronouscommunication. Which process code is assigned? Why do you not need anyseparate inbound partner profiles for the logical system CORE##?

Answer: In the inbound partner profiles for the message typesACC_EMPLOYEE_EXP, ACC_EMPLOYEE_PAY andACC_EMPLOYEE_REC, the process code BAPI is assigned.Because the logical system CORE## is not assigned to any client, but ratherthe system HR_TRAVEL actually calls the system CORE## on the basis ofthe assignment of the receiving port CORE in the outbound partner profileswith CORE##, no inbound partner profiles are required for CORE##.




5. In the HR_TRAVEL system, which RFC destination do you have to assignto the logical system CORE## for synchronous method calls? Add thecorresponding entry.

a) Because the logical system name CORE## is not assigned to anyclient, you must assign the RFC destination CORE to the logicalsystem of the same name.

b) Call the transaction SALE and choose IDoc Interface / Application LinkEnabling (ALE)→ Communication→ Determine RFC Destinationsfor Method Calls.

c) In the menu of the transaction, choose Edit→ Find. In the Search forfield, enter your logical system CORE## and choose Find or Enter.

d) Click on the system name to return to the system overview at theposition of the corresponding entry.

e) Select your logical system CORE## and choose the button StandardDest. for BAPIs. Enter the RFC destination CORE, choose Enter, andsave the change.



Lesson Summary

You should now be able to:� To describe the configuration of the ALE scenario �Transferring the



BIT300 Unit Summary

Unit SummaryYou 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



Unit Summary BIT300


Unit 5Monitoring Data Distribution,Error-Handling and Archiving

Unit OverviewThis unit handles various different tasks that arise from the implementation ofALE 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.


� 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 ContentsLesson: IDoc Status Management .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179

Exercise 10: Monitoring IDocs in the Status Monitor . . . . . . . . . . . . . . . . . .185Exercise 11: ALE Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187

Lesson: Error Analysis and Handling ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190Procedure: Problem: The IDoc Was Not Created.. . . . . . . . . . . . . . . . . . . . .196Procedure: Problem: The IDoc was Created, but was not Sent . . . . .199Procedure: Problem: The IDoc was Successfully Sent, but it was notReceived by the Receiving System .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200Procedure: Problem: The IDoc was Received by the ReceivingSystem, but was not Posted .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201


Unit 5: Monitoring Data Distribution, Error-Handling and Archiving BIT300

Exercise 12: Error Analysis and Handling.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203Lesson: SAP Workflow in ALE Environment ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212

Exercise 13: Processing an Incorrect IDoc from a Work Item.... . . . .223Lesson: Archiving IDocs .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228


BIT300 Lesson: IDoc Status Management

Lesson: IDoc Status Management

Lesson OverviewThis lesson provides you with more detailed information on the IDoc statusmonitor. You also learn how the sender system uses the ALE audit to obtaininformation about the further processing of IDocs in the receiving system.


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

Business ExampleYou are using various ALE scenarios and have to monitor the data distribution.Errors in the IDoc outbound and inbound processing should be detected early. Youare also looking for options to call information in the sender system about thefurther processing of IDocs in the receiving system.

IDoc Status ManagementThe status monitor provides you with an overview of the outbound and inboundIDocs 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 allIDocs, even those that were processed correctly.

Because you usually do not want to display all the IDocs that have not beenarchived yet at the same time, the status monitor provides you with variousselection 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 groupedin the status monitor in terms of direction (outbound or inbound). They are alsogrouped into status groups. For example, all the outbound IDocs for a messagetype that were successfully transferred to a tRFC port are grouped into status group03. Each status value is assigned to a traffic light symbol. Successfully processed



IDocs are displayed with green traffic light symbols in the status monitor, not yet(completely) processed IDocs with yellow traffic light symbols and incorrectlyprocessed IDocs with red traffic light symbols.

Figure 102: Status Groups

The assignment of a status to a traffic light symbol can be changed. To do this,you call transaction WE47. Status values are grouped together into status groups.The traffic light symbols are assigned to status groups in a table that you cancall using transaction WELI.

Note: In SAP R/3 4.7, you will find these transactions with the menu pathTools→ Business Communication→ IDoc Basis→ Control→ Status.In SAP ECC 5.0, you call the transactions from the IMG (transactionSALE) by choosing IDoc Interface / Application Link Enabling (ALE)→System Monitoring→ Set IDoc Status Display→ Process IDoc StatusValues or Process Status Groups.

In Settings→ Hierarchy in the menu of the status monitor you can choose whetherto highlight the message type or the status value.

Displaying and Monitoring IDocsUse the button Display IDocs to call a list of all the IDocs for a message type.



Figure 103: Displaying IDocs

By double-clicking on one of the IDoc numbers in this list you enter the displayof the document itself. Here you can check the control record, the data recordsand the status records.

Under certain conditions, you can also call and display from the sender system anIDoc in the receiver system. This function (�Monitor IDocs�) is also available inthe status monitor by pressing the corresponding button.

Figure 104: Monitoring IDocs



To use this function, the following preconditions must be fulfilled:

� In the outbound partner profiles with the respective receiving system, theremust be parameters for the message type SYNCH.

� The RFC user entered in the RFC destination which is assigned to the portof the outbound partner profile for the message type SYNCH must havethe authorization �Execute� in the receiving system for the function groupBDMT for the authorization object S_RFC.

� In the sending system, an RFC destination for dialogs must be assigned tothe receiver system. You can make this assignment in the IMG by calling thetransaction 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 thecorresponding authorizations for the authorization object S_IDOCMONI.

ALE AuditThe function �ALE Audit� provides the sending system with information aboutthe 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 sendback status information to the sending system of an IDoc. The message type ofthe confirmation is ALEAUD. The receiving system creates its own IDoc withstatus information on IDocs that it received for certain message types within aspecific period. This audit confirmation is usually sent periodically by means of abackground job, but it can also be triggered directly from the status monitor.



Setting up the ALE Audit

1. Add the message type ALEAUD to all the relevant model views. Thereceiving system of the IDocs, whose status values are to be transferred inthe audit, is the sending system for the message type ALEAUD.

2. If required, you can filter by message type. A corresponding filter objectexists. Enter as filter values all the message types for which you wantto create an audit message.

3. Distribute the changes message views again and generate the partner profilesin all the systems involved.

4. Include the program RBDSTATE for sending the audit confirmations.

Figure 106: ALE Audit: Status Values



The status value of an outbound IDoc in the sending system after the successfulinbound processing of the confirmation IDoc for the message type ALEAUD,depends on the status of the corresponding inbound IDoc in the receiving systemat the time of execution of the program RBDSTATE:

� If the inbound IDoc in the receiving system has the status 53 (applicationdocument posted), then the corresponding outbound IDoc in the sendingsystem gets the status 41 (application document created in target system).

� If the IDoc has reached the receiving system with the status 64 (IDoc is readyfor transfer to the application) or 62 (IDoc transferred to application), butthe data has not been posted in the application yet, then the correspondingIDoc in the sending system is given the status 39 (IDoc in target system).Therefore, status 39 only means that the IDoc has reached the receivingsystem. Status 39 does not tell you whether the IDoc still has status 64because the program RBDAPP01 was not started yet, or whether an errorhas occurred.

� If the IDoc was processed incorrectly in the receiving system, and if thiserror cannot be corrected - for example, if the IDoc was sent to the wrongreceiving 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 monitorthrough the path Goto→ ALE Audit. You can send confirmations directly (bystarting the program RBDSTATE), create statistical evaluations, and delete auditstatistics that are no longer required.



Exercise 10: Monitoring IDocs in theStatus Monitor

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the status monitor to monitor IDocs in your receiving system

Business ExampleYou have set up various ALE scenarios in your system landscape. Now you wantto check whether the IDocs sent for test purposes have arrived in the respectivereceiving systems without logging on to these receiving systems.

Task:In the logical system CORE, display IDocs for the message typeMATMASand check whether they have been processed successfully in the logical systemPRODUCTION. However, first check the assignment of an RFC destination fordialogs to the logical system PRODUCTION.

1. In the CORE system, check whether the PRODUCTION system is assignedan RFC destination for dialogs.

2. In the CORE system, call the status monitor and select the IDocs of themessage typeMATMAS that have been created since the start of the course.Use the function �Monitor IDocs� to determine the status of these IDocsin the receiving system PRODUCTION. Display one of the IDocs in thePRODUCTION system.



Solution 10: Monitoring IDocs in theStatus MonitorTask:In the logical system CORE, display IDocs for the message type MATMASand check whether they have been processed successfully in the logical systemPRODUCTION. However, first check the assignment of an RFC destination fordialogs to the logical system PRODUCTION.

1. In the CORE system, check whether the PRODUCTION system is assignedan RFC destination for dialogs.

a) Call the transaction SALE and choose IDoc Interface / Application LinkEnabling (ALE)→ Communication→ Determine RFC Destinationsfor Method Calls.

b) In the menu of the transaction, choose Edit→ Find. In the Search forfield, enter the logical system PRODUCTION and choose Find orEnter.

c) Click on the system name to return to the system overview atthe position of the corresponding entry: The logical systemPRODUCTION is assigned the RFC destination for dialogs of thesame name.

2. In the CORE system, call the status monitor and select the IDocs of themessage typeMATMAS that have been created since the start of the course.Use the function �Monitor IDocs� to determine the status of these IDocsin the receiving system PRODUCTION. Display one of the IDocs in thePRODUCTION system.


b) Enter the message type MATMAS, the partner system PRODUCTION,and as the change date, the starting date of the course, and chooseExecute .

c) Select the entry (or one of the entries) underneath the message type andchoose the Monitor IDocs button.

d) Check the status of the IDoc(s): If the inbound processing wassuccessful, you will find the status 53 beside the IDoc number.

e) Double-click on the number of the inbound IDoc in the PRODUCTIONsystem: You enter the display of the IDoc in the receiving system.



Exercise 11: ALE Audit

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the functions of the ALE Audit.

Business ExampleYou want to be able to detect by the status value of an ALE scenario in the sendingsystem whether the transfer of the data to the corresponding application in thereceiving system was successful, or whether errors occurred.

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

1. Send an IDoc with the status confirmations from the system PRODUCTIONto the system CORE. Only send confirmations for IDocs for your reducedmessage type ZMATMAS##, namely, for all those created since the start ofthe course.

2. Check the result of the confirmation in the status monitor of the COREsystem and display one of the IDocs involved.



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

1. Send an IDoc with the status confirmations from the system PRODUCTIONto the system CORE. Only send confirmations for IDocs for your reducedmessage type ZMATMAS##, namely, for all those created since the start ofthe course.

a) In the PRODUCTION system, choose Tools → ALE → ALEAdministration→ Monitoring→ IDoc Display→ Status Monitor.

b) Enter the Message Type ZMATMAS##. Also enter the start date ofthe course as the first change date and choose Execute . (You mayalso select all the IDocs if you want. The selection for the audit is notmade until the next step.)

c) In the menu of the status monitor, choose Goto→ ALE Audit→ SendAudit Confirmations.

d) In the field Confirmations to system, enter CORE, in the field Messagetype, enter ZMATMAS##, and in the fields Date IDoc changed, enter thedate on which the course started and today's date. Choose Execute. .

e) Confirm the message regarding the generation of the Audit IDoc, goback to the initial screen of the status monitor and refresh the displayby choosing Refresh IDoc Display : In the area of the IDoc outboundprocessing you will see an entry for the message type ALEAUD.

2. Check the result of the confirmation in the status monitor of the COREsystem and display one of the IDocs involved.

a) In the system CORE, call the status monitor as described in step3 a), enter the message type ZMATMAS##; and choose Execute .Your outbound IDocs for the message type ZMATMAS## nowhave different status values. If the processing was successful in theapplication in the PRODUCTION system, you will see the status41, otherwise you see the status 39, which may also mean, however,that your IDoc has not been transferred to the application yet. If theoutbound processing contained errors, the status is set to 40.

b) Select the entry underneath the message type and choose the DisplayIDocs button.

c) Select an IDoc and choose the Display IDocs button again. Open thefolder of the status records in order to monitor the updating of thestatus values.



Lesson Summary

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



Lesson: Error Analysis and Handling

Lesson OverviewIDoc processing does not always work at once. Configuration errors in the ALEarea and in the affected application itself can lead to errors in the IDoc generationor the further IDoc processing. This lesson will show you how to systematicallyanalyze errors and then resolve them.


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

Business ExampleYou have set up various ALE scenarios. An administrator is to take over theerror handling in the future. You want to get an overview of the options for erroranalysis and error resolution.

IDoc Outbound ProcessingIn the outbound processing, an IDoc goes through various phases, the results ofwhich are represented by status values. Successful IDoc outbound processinginvolves three obligatory and three optional status values:


BIT300 Lesson: Error Analysis and Handling

Figure 107: Status Values for Error-Free IDoc Outbound Processing

� 01: IDoc created� 30: IDoc is ready for sending (ALE service)� 03: Data passed to port OK

Whether or not the sender system sends an IDoc at once depends on thespecifications in the respective outbound partner profile. If the Group IDocsoption is selected there, the IDocs are only transferred to the receiving port of thepartner profile after the program RSEOUT00 is executed. Therefore, status 30 isalways an intermediate status.

Status 03 only informs you that the IDoc data was successfully transferred to theport. You only find out whether the IDoc was actually received by the receivingsystem when you run the program RBDMOIND. This program, which is intendedfor regular background processing with jobs, checks whether there are still IDocsin the tRFC queue. All the IDocs no longer contained in this queue are given thestatus 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 receivingsystem. This program is also intended for regular background processing withjobs. Status 39 informs you in the sending system that an IDoc has been storedon the database in the receiving system, but that it has not been transferred to theapplication yet. Therefore, the IDoc can have the status 64 or 62 in the receiving



system. Status 41, on the other hand, indicates an IDoc whose data has beensuccessfully 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 thefollowing status values:

Figure 108: Status Values for Incorrect IDoc Outbound Processing

� 02: Error transferring data to port� 26: Syntax error in IDoc (outbound)� 25: Further processing despite syntax error (outbound)� 29: Error in ALE service

Status 02 is set instead of status 03 if an error occurs during the transfer to the port.The sender system determines the transaction code EDIO and on the basis of theassigned workflow task, sends a workflow item to the agent responsible. Afterthe error is resolved, the IDoc can be transferred to the port again from this workitem or from the IDoc status monitor.

Status 26 indicates that the IDoc is missing a segment which the IDoc basictype specifies is required, that there are more segments for a segment typethan specified in the IDoc basic type, or that there is some other breach of thespecifications of the IDoc basic type. If the indicator Terminate the processingif syntax error occurs is not set in the outbound partner profile, the IDoc is stilltransferred to status 30 and processed further. However, if the indicator is set, thesender system determines the transaction code EDIX and sends a work item inaccordance with the assigned workflow task. It is possible to trigger the furtherprocessing of the IDoc despite a syntax error. The IDoc first gets the status 25 andis then switched to status 02.



If outbound partner profiles are competely missing or incomplete, the systemgives the IDoc involved the status 29. This status is also assigned if a globalcompany code or a business area is missing. If the IDoc is processed again afterthe missing settings are added, the system logs this as editing of the IDoc andcreates a copy of the original, which is kept for documentation purposes, even inits incorrect form. The copy is given status 30 and the original gets status 33(Original of an IDoc that has been edited).

IDoc Inbound ProcessingIn the inbound processing, an IDoc also goes through various phases, the resultsof which are represented by status values. Successful IDoc inbound processinginvolves four obligatory status values:

Figure 109: Status Values for Error-Free IDoc Inbound Processing

� 50: IDoc added� 64: IDoc is ready for transfer to the application� 62: IDoc transferred to application� 53: Application document posted



Whether or not the receiving system transfers an IDoc to the application at oncedepends on the settings in the respective inbound partner profile. If the Startin background job option is selected there, the IDoc is only transferred to theapplication after the program RBDAPP01 is executed.

Note: In scenarios such as this, the RFC user only requires theauthorization to store IDocs on the database. Required are the RFCauthorizations for the function groups EDIN and ERFC (authorizationobject S_RFC) and the authorization for the authorization objectB_ALE_RECV with the desired message types. The user for thebackground processing of the program RBDAPP01 must haveauthorizations to read the IDoc from the database (authorization objectS_IDOCMONI) and the application authorizations to post the data bymeans of the application program.

If errors occur in the IDoc inbound processing, the sender system sets one of thefollowing status values:

Figure 110: Status Values for Incorrect IDoc Inbound Processing

� 56: Incorrect IDoc added� 60: Syntax error in IDoc (inbound)� 61: Further processing despite syntax error (inbound)� 65: Error in ALE service� 51: Application document not posted



Status 56 usually tells you that the inbound partner profile is missing for themessage type.

If the indicator Terminate the processing if syntax error occurs is set in the inboundpartner profile, an IDoc with a syntax error is given the status 60. The systemsends the responsible agent a work item on the basis of the workflow task assignedto the process code EDIY. If the syntax check is not activated, then the incorrectIDoc is moved directly from status 60 to status 64. If an IDoc with a syntax errorwith 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 theIDoc is given status 51 in most cases. A number of logistical applications havetheir own status (52 and 54), but they all indicate an error in the processing of theIDoc data in the application program itself. Work items are sent to the responsibleagents. Depending on the application, such an IDoc can also be processed �inthe foregound�, meaning interactively. Missing or incorrect values can then beadded or corrected manually.

The end of this lesson you will find suggestions for systematic error analysis,with information on resolving errors.



Problem: The IDoc Was Not CreatedPrerequisitesAn ALE scenario has been configured. You know the message type of thescenario and the program with which the IDoc outbound processing is carried out.However, no IDoc has been created in the sending system.

Procedure1. Analyze the type of the outbound processing.

Is the IDoc to be created by means of the message control? You can usetransaction WE64 to find the message types for IDoc scenarios that werecreated using the message control.

Is the scenario involved a master data distribution scenario, in which changepointers are to be evaluated? You can use transaction SALE to find messagetypes for ALE scenarios that work with change pointers by choosing IDocInterface / Application Link Enabling (ALE)→ Modelling and ImplementingBusiness Processes→ Master Data Distribution→ Replication of ModifiedData. If you have created a reduced message type which is not in this listfor a message type that is in this list, then you proceed as follows: ChooseIDoc Interface / Application Link Enabling→ Modelling and ImplementingBusiness Processes→ Master Data Distribution→ Scope of Data forDistribution→ Message Reduction→ Create Reduced Message Type(transaction BD53). Select the reduced message type and choose the buttonActivate 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 withstep 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 tobe distributed in an IDoc?

If the master data has been changed since the last time IDocs were createdfrom change pointers, there should be change documents as well as changepointers. 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. Makesure that the correct message type is selected in the selection screen. Check




whether the report was scheduled with the correct variant, and when it waslast run. For test purposes, you can also start this program using transactionBD21.

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 whosedata should have been sent in IDoc format in the display or change mode andcheck the result of the message determination. In most documents, you cancall up this information with the menu entries Goto or Extras. In purchasingdocuments, there is a separate button Messages. Check whether the messagewas found, and whether it was processed successfully (green traffic lightsymbol). Usually you can also call up a processing log for display from thedetails of the message determination.

Are the condition records maintained correctly?

If the expected message was not found in the document, check thedetermination record (condition record) for the message type. It is possiblethat there is no corresponding determination record for the key combinationin the document. If you are not familiar with the application involved, youcan also search for determination records using transaction NACE. If themessage was found, but not processed correctly, check the transmissionmedium and the transmission time. To generate IDocs, the transmissionmedium 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 partnermust be created for partner type LI (vendor) or KU (customer), and in ALEscenarios for partner type LS (logical system). In EDI scenarios, alwayscheck the partner function too: Does it match the partner function of thedetermination record? Have outbound parameters been created for therespective 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-specifictransaction. The program triggers the generation of IDocs from messages inthe message control. If the transmission time in the condition record is not 4,but 1,2 or 3, then the program RSNAST00 must be started in a separate step.

4. Is the distribution model maintained correctly?




Does the distribution model of the sending system contain a view with therequired message type or BAPI? If your distribution model contains manyviews, you can also use the menu entry Edit→ Filter Display or the buttonFilter model display to make a selection based on message type or businessobject type. If necessary, add the missing view or the missing message typeor missing BAPI in the maintenance system and transport or distribute thisview to the systems involved.

Is the model view still valid?

The validity of model views is limited. If necessary, check whether yourviews can still be used at the present time. To do this, double-click the nameof 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 areentered, then the values entered for the filter object must match the valuestransferred with the IDoc from the application. It is possible that the filterobject refers to a required segment in the IDoc basic type. If the conditionsfor the field values are not fulfilled, no communication IDoc is created.

Is the filtering performed by means of classification? Is the class in thesending system assigned to the logical system of the receiver? Is the masterdata to be distributed assigned to the distribution class?

In the distribution model, check whether a filter group is created in the viewinvolved. If the indicator Dependent on class membership is set, then thefiltering is performed by means of the classification. Then choose IDocInterface / Application Link Enabling (ALE)→ Modelling and ImplementingBusiness Processes→ Master Data Distribution→ Distribution UsingObject Classes→ Assign Classes to Receiving Logical System. If necessary,check in the master data to be distributed whether the view Classification iscreated, and whether it refers to the correct class.



Problem: The IDoc was Created, but was not SentPrerequisitesAn ALE scenario has been configured. An IDoc has been created in the sendingsystem, but it was not sent.

Procedure1. Outbound partner profile is missing (status 29):

Use transaction WE20 to check whether the sending system has an outboundpartner profile with the receiving system for the message type involved. Ifnot, generate the missing partner profile from the corresponding view ofthe distribution model and check the settings or create the partner profilemanually.

2. IDoc remains in status 30:

Use transaction WE20 to check in the sending system the outbound partnerprofile with the receiving system for the message type involved. If theoutput mode Group IDocs is selected there, the program RSEOUT00 mustbe executed first. Check whether this program is planned as a job for thebackground processing and whether the message type involved is scheduledin a variant. For test purposes you can start the report manually or select theIDoc in the monitor (transaction BD87) and trigger the sending by means ofthe 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 Portprovides you with the name of the port which was determined by means ofthe partner profile. Check the attributes of this port using transaction WE21.If the port has been configured incorrectly, you can correct this error hereand send the IDoc again. If, on the other hand, an incorrect port is enteredin the partner profile, then you correct the partner profile. In IDocs thathave already been sent, you can manually change the value of the port inthe control record. To do this, double-click the control record in the IDocdisplay and choose Control Record→ Display -> Change. The change modeappears. Choose the Partner tab page and enter the correct port in the fieldPort. You can then resend the IDoc.



Problem: The IDoc was Successfully Sent, but it wasnot Received by the Receiving SystemPrerequisitesAn IDoc was sent to a receiving system through a tRFC port. The IDoc has thestatus 03 in the sending system, but it did not reach the receiving system. ReportRBDMOIND does not result in a status change.

Procedure1. 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 thefRFC level. If a Display button appears, then the data packet is still in thetRFC queue. You can use this button to navigate directly into the tRFCqueue (transaction SM58). Examine the error message for the correspondingentry in the fRFC queue.

Hint: One cause could be authorization restrictions for the userentered in the RFC destination. The user could possibly be blockedbecause of multiple incorrect logons, or there may be an incorrectpassword stored in the RFC destination. Therefore, you mustalso check the RFC destination in the sending system and theauthorizations of the user entered there in the receiving system.Note that usually the RFC destination and the RFC user are used byvarious programs. Changing the properties can therefore influenceother ALE scenarios.

2. When you have resolved the error, you can manually trigger the processingin the tRFC queue: To do this, select the entry and choose Edit→ ExecuteLUW. Depending on the settings, the RFC level starts this processingautomatically after a few minutes.

Hint: You can check the general settings for the tRFC usingtransaction SM58. Choose Execute to go from the selectionscreen to the list and choose Information→ System Setting tonavigate to a dialog window with the desired information. Youcan use a local setting to override this system setting in every RFCdestination. Navigate to the display of the RFC destination (forexample, by means of transaction SM59). There, choose Destination→ tRFC Options.



Problem: The IDoc was Received by the ReceivingSystem, but was not PostedPrerequisitesAn IDoc was received by the receiving system, but it does not have status 53 yet.

Procedure1. Inbound partner profile is missing (status 56)

If the status text states that the partner profile is missing, you add it manuallyor have it generated by the system from the distribution model. If necessary,you can determine from the control record of the incorrect IDoc whichlogical system was the sender.

2. IDoc remains in status 64 (the IDoc is ready to be transferred to theapplication):

If the indicator Start through background program is set in the partnerprofile, then the IDoc is generally transferred to the application by theprogram RBDAPP01. Choose System→ Services→ Jobs→ Job Overview,and in the field ABAP program name, enter RBDAPP01. Then choose thebutton Execute: You are told when and at what intervals the program hasbeen scheduled as a background job. For testing purposes, you can start itmanually or you can transfer the IDoc from the status monitor directly tothe application. If the IDoc is always to be transferred to the applicationimmediately, then you set the indicator Start immediately in the partnerprofile.

3. IDoc is in status 51:

Check whether there is more detailed information on the cause of the errorin the long text of the error message for the status. In general, you requireknowledge of the application for the error search. Two technical errors areoften the cause of incorrect IDoc processing in the application:

� Incorrect process code in the partner profile: If the status text / errortext is �No function module for inbound process code xy�, then there isan 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 requiredauthorizations?

You can have incorrect IDocs with status 51 processed after the error isresolved by executing the program RBDMANI2 (Posting incorrect IDocs).This program can be scheduled as a background job.

4. No (active) partner profile exists (status 63):




You have the option to set the partner profile for a partner to inactive. In thereceiving system, check the partner profile with the sending system, byentering transaction WE20 and calling the partner profiles for display andchoosing the tab page Classification on the header level. If the partner statusis �I�, then the partner is inactive. You can change the value to A (active).



Exercise 12: Error Analysis and Handling

Exercise ObjectivesAfter completing this exercise, you will be able to:� Find the causes of errors in the IDoc processing� Correct these errors

Business ExampleIn the logical system CORE , you have created or changed master data anddistributed it to the receiving systems PRODUCTION and SALES. The datatransfer was not always successful. You check the situation in the status monitorand resolve the errors.

Task 1: Analysis of the IDoc Status ValuesIn the case of incorrect IDoc processing, you can analyze the status values of theIDoc involved to determine in which part of the process an error occurred. Whichstatus values belong to which (error) situation?

1. The IDoc was not created.

2. The IDoc was created, but was not sent.

3. The IDoc was successfully sent, but it was not received by the receivingsystem.




4. The IDoc was received by the receiving system, but was not processed yet.

Task 2: Postprocessing of an Incorrect IDocThe IDoc inbound processing can fail because of discrepancies between theapplication-specific Customizing settings in the sending and receiving systems.The IDoc is given the status 51 (application document not posted). In this exerciseyou will learn how to postprocess an incorrect IDoc so that its data can be postedin the application.

1. In the logical system CORE, add the division 99 to your material masterMATALE-##.

2. Send the changed material to the logical system PRODUCTION and displaythe outbound IDoc in the status monitor. What status does the outbound IDochave? What status does the inbound IDoc have in the receiving system?

Hint: Use the function �Monitor IDocs� in the system COREto gain information about the inbound processing in the systemPRODUCTION.

3. In the system PRODUCTION, call up and display the IDoc in the statusmonitor and find out the cause of the processing error. Make a note of thenumber of the IDoc: __________

4. What conclusion do you draw from the error message? What options doyou have for solving the problem?

5. Call the incorrect IDoc for display, switch to the change mode, and replacethe value 99 in the field DIVISION with a value defined in the systemPRODUCTION.

Hint: In doing this, use the input help for the field DIVISION.




6. Now try to transfer the IDoc to the application again. What happens? Checkthe status records of your IDoc.

Task 3: Setting a Deletion Flag for an IDocIn some cases, it is no longer possible, or is not desirable, to handle an error bycorrecting system settings or editing the IDoc. You want the IDoc to be archivedunchanged. In such cases, you can flag the IDoc for deletion so that it can bearchived at the next opportunity.

1. Send your changed materialMATALE-## from the system CORE to thesystem PRODUCTION again and call up the status monitor there.

2. In the system PRODUCTION, your IDoc has the status 51 again. Instead ofediting it, you now set a deletion flag for the subsequent archiving.



Solution 12: Error Analysis and HandlingTask 1: Analysis of the IDoc Status ValuesIn the case of incorrect IDoc processing, you can analyze the status values of theIDoc involved to determine in which part of the process an error occurred. Whichstatus 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 savedon 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 thedata transfer to port) could apply here.

3. The IDoc was successfully sent, but it was not received by the receivingsystem.

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 thestatus 39 (IDoc in target system). In the receiving system the IDoc has thestatus 64 (IDoc is ready for transfer to the application).

Task 2: Postprocessing of an Incorrect IDocThe IDoc inbound processing can fail because of discrepancies between theapplication-specific Customizing settings in the sending and receiving systems.The IDoc is given the status 51 (application document not posted). In this exerciseyou will learn how to postprocess an incorrect IDoc so that its data can be postedin the application.

1. In the logical system CORE, add the division 99 to your material masterMATALE-##.

a) Choose Logistics→ Materials Management→ Material Master→Material→ Change→ Immediately.

b) Enter the material number MATALE-## and choose Enter.

c) Select the view Basic data 1 and choose Enter.

d) In the field Division, enter 99 and save the change.




2. Send the changed material to the logical system PRODUCTION and displaythe outbound IDoc in the status monitor. What status does the outbound IDochave? What status does the inbound IDoc have in the receiving system?

Hint: Use the function �Monitor IDocs� in the system COREto gain information about the inbound processing in the systemPRODUCTION.

a) Choose Tools→ ALE→Master Data Distribution→Cross-Application→ Material→ Send.

b) Enter your material MATALE-##, your reduced message typeZMATMAS## and the logical system PRODUCTION and chooseExecute .

c) Choose Tools→ ALE→ ALE Administration→ Monitoring→ IDocDisplay→ Status Monitor.

d) Enter your message type ZMATMAS## and choose Execute : TheIDoc has the status 03.

e) Select the entry underneath the message type and choose the buttonMonitor IDocs: In the system PRODUCTION, the IDoc has thestatus 51.

3. In the system PRODUCTION, call up and display the IDoc in the statusmonitor and find out the cause of the processing error. Make a note of thenumber of the IDoc: __________


b) Enter your message type ZMATMAS## and choose Execute .

c) Select the entry underneath the message type and choose the DisplayIDocs button.

d) Select the IDoc and choose the button Display status long text: Youwill see that an application log has been written from which you canobtain 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 andchoose 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 forthe field MARA-SPART (division). Leave the log and the display ofthe error long text.




4. What conclusion do you draw from the error message? What options doyou have for solving the problem?

Answer: Division 99, which you entered in the material master in thesending 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 havethe IDoc processed again, or you can edit the IDoc and have a value definedin 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 replacethe value 99 in the field DIVISION with a value defined in the systemPRODUCTION.

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 theleft of the segment E1MARAM.

c) Choose Display Data Record -> Change and confirm the informationthat your changes have been saved in the database with Enter.

d) Navigate to the field DIVISION and call up the input help. Use adouble-click to accept one of the entries in the list of permitted values.Save this change, leave the data record editor, and then leave theIDoc display.




6. Now try to transfer the IDoc to the application again. What happens? Checkthe status records of your IDoc.

a) Go back to the status monitor and choose Refresh IDoc display : Thesystem 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 Statusrecords: You see that after the editing, your IDoc has been reset tostatus 51 and then transferred to the application again.

d) Go from the IDoc display back to the status monitor: The system hascreated a second IDoc and assigned to it the status 70 (original of anIDoc that has been edited). The long text is: �This IDoc has beenstored as the original of an edited document.� Thus, the system keeps acopy of the incorrect IDoc as it was before the editing.

e) Call up the edited IDoc for display again, open the folder of the statusrecords and double-click on the symbol to the left of the status long textfor the status 69: You will see which user edited this IDoc in whichsegment, and which number the copy with the original data has.

f) Leave the IDoc display, select your IDoc and choose the button Displayrelationships: A screen appears with the two IDoc numbers.

Task 3: Setting a Deletion Flag for an IDocIn some cases, it is no longer possible, or is not desirable, to handle an error bycorrecting system settings or editing the IDoc. You want the IDoc to be archivedunchanged. In such cases, you can flag the IDoc for deletion so that it can bearchived at the next opportunity.

1. Send your changed materialMATALE-## from the system CORE to thesystem PRODUCTION again and call up the status monitor there.

a) Proceed in the way described in the second task in step 2, in order todistribute your materialMATALE-##.

b) Find the incorrect IDoc in the system PRODUCTION in the statusmonitor (see step 3): It has the status 51 again.




2. In the system PRODUCTION, your IDoc has the status 51 again. Instead ofediting it, you now set a deletion flag for the subsequent archiving.

a) Select your IDoc in the status monitor and choose Edit→ Restrictand process.

b) Remove the indicator Background proc. and choose Execute .

c) Choose the button Deletion flag and confirm the confirmation promptwith Enter: A message appears that your IDoc has been flagged fordeletion.

d) Check the result in the status monitor: The IDoc now has the status68 (error, no further processing).



Lesson Summary

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



Lesson: SAP Workflow in ALE Environment

Lesson OverviewIn this lesson you learn how to use the SAP Workflow for IDoc inboundprocessing, error handling and active monitoring.


� 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 ExampleYou have configured ALE scenarios in your system landscape. If errors occur, anadministrator or an employee of the business department should be informed bymeans of the SAP Workflow.

Using the SAP Workflow in ALE ScenariosThe SAP Workflow is a tool for the automation of business processes within anSAP system, but also beyond system boundaries. It is not connected to specificapplications, but functions independently in all applications. The primary aim is toprovide the correct agent with a task at the correct time.

In ALE scenarios, you can use the functions of the SAP Workflow for the IDocinbound processing, as an alternative to inbound function modules, for monitoringthe inbound and outbound IDocs during ongoing operation, and for processingincorrect IDocs.

IDoc Inbound Processing Using SAP WorkflowA process code for the IDoc inbound processing can refer to a task or a workflow.


BIT300 Lesson: SAP Workflow in ALE Environment

Figure 111: IDoc Inbound Processing Using Workflow

For the inbound IDoc, a workflow can be started by means of a process code.You can define such a workflow freely and assign it to the desired process code.Examples of the use of such workflows are:

� You want to generate an application document automatically from the IDoc.Subsequently, the application document is to be passed to an employee forchecking.

� The IDoc is to be checked and, if necessary, changed before the applicationdocument is created. In this case, the IDoc is edited, not the applicationdocument.

� The IDoc or the application document is to be forwarded to one or moreagents.

� 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 theALE scenario �Stock Transfer Between Distributed Systems�. For the usualinbound processing of IDocs with purchase order data, the specified process codeis ORDE, to which a function module is assigned for the transfer of data to theapplication. In certain cases, however, the order is not to be created automaticallyin the receiving system, but rather by a business department employee, onlyafter the puchase order data has been checked. Such cases use the process codeORDE_BY_WORKFLOW, which refers to a workflow and not to a functionmodule. In this way, the IDoc inbound processing can be performed interactively.The employee can not only check the data, but can also make changes.



IDoc Monitoring with Workflow ConnectionThe active monitoring of inbound and outbound IDocs is usually scheduled as aperiodic background job. The monitoring evaluates whether the number of IDocswith a particular status exceeds a previously defined threshold value. Duringthe selection run, the IDocs that fulfill the selection criteria are evaluated. If thecurrect 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 thethreshold value entered, then this situation is evaluated as critical and a statusconfirmation 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. Forthis purpose, you must define a variant (menu path: Tools→ ALE→ ALEAdministration→ Services→ Periodic Processing→ Schedule IDoc Monitoringwith Workflow Connection).

Error Handling with SAP WorkflowThe exception and error handling in the ALE environment is always realizedthrough a workflow. In the case of an exception, one or more agents are informedof the error situation by means of a work item, and they are provided with theIDoc involved.

Figure 112: Error Handling with Workflow

The respective agents responsible are entered in the partner profiles or the settingsfor the IDoc administration, and the general potential agents are entered in the taskdefinition. If an organization model is maintained in your company, along withusers you can also assign positions or organization units as agents (see below).



Behind the exception handling cases of the IDoc interface that are delivered bySAP, there are individual tasks. They are started by means of the process codes ofthe error handling. These process codes are subdivided into system and statusprocess codes.

If you set the express indicator in the detailed settings of a process code, the agentsof the corresponding task immediately receive an express message on their screenswhen there is a new work item in their inbox.

The figure below shows the exception handling in the IDoc outbound processing:

Figure 113: Process Codes for Errors in the Outbound IDoc



� The process code EDIM applies to outbound and inbound processing. Itapplies when it has not been possible to create an IDoc yet.

� EDIN is used for outbound processing by means of message control: Youcan use the NAST record to branch to the application document from thework item.

� EDIO reacts to an outbound IDoc for which a general processing errorhas 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 thesame degree (example: a non-existant port). The work item sent when thecorresponding task is started allows you to correct the error and trigger theprocessing of the IDoc stack again.

� If an error status is confirmed by the external system, then a task for the errorhandling is also started by means of the status process code EDIS. With thestatus process code EDIR you can also trigger the outbound processing againafter you have corrected the error.

Hint: The process code EDIR is new to SAP R/3 4.6A. It replacesthe process code EDIS. During an upgrade, you must explicitlyperform the change to EDIR in IMG.

You can define additional exception handling cases for the status confirmationand 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 issent to the agents that are determined.



Figure 114: Process Codes for Errors in the Inbound IDoc

� As in the outbound processing, the process code EDIM applies when it hasnot been possible to create an IDoc.

� EDII and EDIY correspond to the outbound process codes EDIO andEDIX.

� You can use the IDoc type TXTRAW01 to send messages of your choice intext format. This technique is used, for example, if an exception has occurredin 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 processcode EDIL becomes active. In the exception handling, the error message ofthe 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 isused for the error handling. Instead of the relatively rigid reaction by meansof process codes, the application uses the more flexible event concept. In thecase of an exception, an event is triggered which can start 1 to n tasks and sendcorresponding work items.

Note: The tasks supplied by SAP for errors during posting in theapplication usually have the name suffix �error� - for example,MATMAS_error or ORDERS_error. For IDocs created by BAPI calls, inthe case of an error, the task IDOC_APPL_Er (TS20000051) provided bySAP 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 thereforefurther processing of the work item with errors, are only possible from this inbox.



Authorization ConceptIn the case of an exception, a task is started by means of a process code. A workitem is created as an instance of this task. In order to determine the correct agentfor the work item, the system requires two quantities of agents, the �potential�and the �permitted� agents. The intersection of these quantities filters out therecipients 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 apermitted agent for the error and exception handling. You can also enter for eachmessage type a permitted agent that differs from this higher-level agent. In thecase of an error (for example, an inbound IDoc with a syntax error), the systemfirst 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 theagent assigned to the partner is notified. If there are no partner profiles with thepartner, the system then tries to determine the IDoc administrator. Therefore,for situations in which the system cannot find any partner profiles, you shouldnominate an agent in the general settings for the IDoc administration, so that anemployee will be notified if an error occurs. For this purpose, call transactionSALE and choose IDoc Interface / Application Link Enabling (ALE)→ BasicSettings→ IDoc Administration.



Figure 116: Agent Search in the ALE Environment

When a task is started, a rule entered for the task is used to determine the group ofpotential agents, on the basis of the task definition. Then the system determinesthe intersection of the potential and permitted agents on the basis of the partnerprofiles and the IDoc Administration. All the permitted agents receive the workitem for the task. The work item is put into the inbox of the recipient's SAPBusiness Workplace. The item provides him with direct access to the incorrectIDoc, and he can begin the error processing immediately.

The tasks of the IDoc error handling are classified as general tasks in SAP R/3 orSAP 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 agentaccesses it, the work item is deleted from the inboxes of the other recipients.

You can enter users or elements of the organizational management, such aspositions or organization units, as permitted agents. The use of elements of theorganization management increases the flexibility for organizational changes.

Maintenance of an Organizational StructureIn the automatic Workflow Customizing (transaction SWU3), the workflowsfor IDoc processing supplied by SAP which are located in the task groupTG74500044, are declared to be �general�. They can thus be processed by allusers. The restriction to the relevant agents for IDoc errors is effected by anintersection with the permitted agents for the IDoc interface (see above).



Figure 117: Organizational Structure

If you use elements of an organizational model to define the permitted agents,you can, for example, assign a whole group of agents to the respective level byentering a correspondingly occupied organization unit or position. You can alsoswitch to the organizational responsibility centrally in the maintenance of theorganizational model, by means of a simple reassignment. This saves you theeffort of searching all the levels of the IDoc interface.

Note: The use of such organizational models is independent of the useof the application mySAP ERP Human Capital Management. The basicsystem provides everyone with the required tool (simple maintenance ofthe organizational management � transactions PPOC, PPOM, PPOS).

In the simple maintenance, you create the hierarchical structure of yourorganizational model, starting with the root organizational unit. In a further step,you create the required positions and assign them to the desired organizationalunits. In the last step, you assign users to the positions as position holders.

ProcessingWork Items in the SAP BusinessWorkplaceThe SAP Business Workplace integrates workflow functions into general officefunctions. There, along with work items, you also receive mails, documents anddeadline messages. The agents receive the work items intended for them in theinbox of their Business Workplace. You reach the Business Workplace throughtransaction SBWP.



Figure 118: SAP Business Workplace

From there, you choose the folder Inbound and the area Workflow to go to theworklist display. You will see all the active work items. You double-click tostart the execution of the selected work item. If one of the recipients has calledup the work item for processing in this way, it is deleted from the inboxes ofthe other recipients.

If an express indicator is set in the settings for the process codes, then therecipients of the work items receive an express notification, no matter where theycurrently are in the SAP system. From the express notification, they can thennavigate directly to their Business Workplace and react quickly.

Tools of the Workflow AdministrationWhen you are working with workflow support, you can also use tools of theworkflow administration if required - for example, if a work item has an incorrectstatus 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 processit himself or forward it to the actual person responsible. You may also want tosearch directly for work items whose deadline has been exceeded.



Work items that were created within the IDoc exception handling are critical.Therefore, you require tools in order to quickly detect and resolve technical ororganizational errors. The most widely-used tools are the following transactions:

� Transaction SWI1 (selection report for work items) for finding incorrectwork items

� Transaction SWPR (workflow restart after error) for the restart of anincorrect work item after the error has been resolved

� Transaction SWI2_DEAD (work items with exceeded deadline) for findingwork items with exceeded deadlines

� Transaction SWI2_ADM1 (work items without agent) for finding work itemswith no recipient

The transactions listed are for finding work items for specific tasks, thus enablingyou to find IDoc-relevant work items. You can then branch from the work itemfound to the IDoc display.



Exercise 13: Processing an Incorrect IDocfrom a Work Item

Exercise ObjectivesAfter completing this exercise, you will be able to:� Process an incorrect IDoc from a work item

Business ExampleYou have configured ALE scenarios in your system landscape. If errors occur,an administrator or an employee of the business department should be quicklyinformed 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 PRODUCTIONand distribute the model view again. Then send a vendor master and check theinbound IDoc. Find the corresponding work item and remove the error by meansof the work item processing.

1. In the logical system CORE, in your model view TRAINING##, add anentry for the message type ZCREMAS##. The sender is the logical systemCORE, and the receiver is PRODUCTION. Generate the outbound partnerprofiles for this message type and distribute your model view again to thesystem PRODUCTION.

2. Send the master record of the vendor T-K515D## from the system CORE tothe system PRODUCTION. Check the inbound IDoc in the status monitorof the receiving system. What status does it have? Make a note of thenumber of the IDoc: ________________

Hint: Use the message type ZCREMAS##.

3. Check in the system PRODUCTION whether your inbox in the SAPBusiness Workplace contains a work item for this IDoc. Display the IDocfrom the attachment of the work item, determine the cause of the error, andadd the missing settings.

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



Solution 13: Processing an Incorrect IDocfrom a Work ItemTask:Transfer the message type ZCREMAS## into your model view TRAINING##,generate the outbound partner profiles with the partner system PRODUCTIONand distribute the model view again. Then send a vendor master and check theinbound IDoc. Find the corresponding work item and remove the error by meansof the work item processing.

1. In the logical system CORE, in your model view TRAINING##, add anentry for the message type ZCREMAS##. The sender is the logical systemCORE, and the receiver is PRODUCTION. Generate the outbound partnerprofiles for this message type and distribute your model view again to thesystem PRODUCTION.

a) Call the transaction SALE and choose IDoc Interface / Application LinkEnabling (ALE)→Modelling and Implementing Business Processes→Maintain Distribution Model and Distribute Views.

b) Switch to the change mode (Switching between display and changemode ) and in your model view TRAINING## select the entryfor the receiving system PRODUCTION and choose the button Addmessage type.

c) Enter the message type ZCREMAS## and choose Enter. Save yourchanges.

d) Select your model view TRAINING##, and in the menu of thedistribution model, choose Environment→ Generate Partner Profileand in the next screen, choose Execute : Outbound parameters arecreated for the message type ZCREMAS##. Leave the log display.

e) Select your model view TRAINING## and in the menu of thedistribution model, choose Edit→ Model View→ Distribute. Deselectthe entry for the logical system SALES and choose Enter.




2. Send the master record of the vendor T-K515D## from the system CORE tothe system PRODUCTION. Check the inbound IDoc in the status monitorof the receiving system. What status does it have? Make a note of thenumber of the IDoc: ________________

Hint: Use the message type ZCREMAS##.

a) Choose Tools→ ALE→Master Data Distribution→Cross-Application→ Vendor→ Send.

b) In the field Account number of the vendor, enter T-K515D##, in thefield Message type, enter ZCREMAS## and in the field Target system,enter PRODUCTION and choose Execute . A master IDoc and acommunication IDoc are created.

c) In the PRODUCTION system, choose Tools → ALE → ALEAdministration→ Monitoring→ IDoc Display→ Status Monitor.

d) Enter your message type ZCREMAS## and choose Execute : YourIDoc has the status 03 (incorrect IDoc added).

e) Select the entry and click on the Display IDocs button. Make a note ofthe number of the IDoc.




3. Check in the system PRODUCTION whether your inbox in the SAPBusiness Workplace contains a work item for this IDoc. Display the IDocfrom the attachment of the work item, determine the cause of the error, andadd the missing settings.

a) Choose Menu→ Business Workplace.

b) Choose Inbox→ Workflow→ Grouped according to content. Searchthe list for your IDoc from step 2 e) and select it so that your work itemappears in the detail window on the right half of the screen.

c) Choose Execute , and in the next screen (the status display of theIDoc) choose the button IDoc display.

d) Open the folder Status records and double-click on the symbol besidethe status long text (EDI: Inbound partner profile does not exist).

e) The error analysis tells you that the inbound partner profiles withthe partner PRODUCTION are missing for the message typeZCREMAS##. 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 theinbound parameter area, choose Create inbound parameter .

g) Enter the message type ZCREMAS## and the process code CRE1 andsave the change. Leave the maintenance of the partner profiles, closethe display of the status long text and leave the IDoc display.

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

a) In the status record display, choose the button Process: A message tellsyou that your IDoc was processed successfully.

b) Confirm the message with Enter and choose Refresh : The work itemhas been deleted from your inbox.

c) Call up the status monitor again. You will find a description of theprocedure in step 2 c). If your status monitor was still open in anothermode, choose Refresh IDoc display : The IDoc now has the status 53(application document posted).



Lesson Summary

You should now be able to:� Check workflow settings for the error handling of IDocs� Understand the settings for process codes� Describe the notification concept� Monitor the IDoc processing using the SAP Workflow



Lesson: Archiving IDocs

Lesson OverviewThis lesson shows you how to archive IDocs using transaction SARA, and theoptions for displaying archived IDocs. Additional reorganization options in theIDoc environment are also shown.


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

Business ExampleYou have set up various ALE scenarios and want to archive the IDocs that havebeen processed successfully. You also want to delete from the database tableentries for IDoc connections and processed change pointers.

Archiving IDocsIDocs cannot be directly deleted from the database, but only within the dataarchiving process. The data archiving takes place in two steps: Firstly, archivefiles are written for the IDocs selected for archiving, then the correspondingdatabase entries are deleted.

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


BIT300 Lesson: Archiving IDocs

The archiving is realized by means of an archiving object, which provides all thefunctions required for archiving a business object, especially the necessary writeand delete programs. The archiving object for archiving IDocs is called IDOC.

After setting the desired Customizing options, you can use transaction SARA tostart the data archiving with the archiving object IDOC by creating a variant of thewrite program with the desired selection values, maintaining the start data and thespool parameters, and starting the execution.

Depending on the Customizing setting, the second step of the data archiving - thedeletion of the corresponding database entries - is either carried out automaticallydirectly after the write run, or it is started manually with transaction SARA.

Figure 120: Archiving IDocs - Second Step: Deleting IDocs from theDatabase

In the selection for the deletion run, you can only choose archive files that havealready been written. This ensures that no data is deleted from the databasefor which no archive files exist yet. You also maintain the start date and spoolparameters and start the execution here. From transaction SARA you can navigatedirectly to the job overview and view the log for the respective run there. Theactual archiving is complete when the delete run is finished.

You can display the archived IDocs with transaction WE09. However, you canalso call them up for display with the archive information system (transactionSARI). A prerequisite for this is that an active archive information structure mustexist, which you have filled either implicitly with the deletion run, or explicitlywith transaction SARI.

Note: In an SAP R/3 or SAP ECC system you will find the archiveinformation structure SAP_IDOC_001 for this purpose. However, youcan also create user-defined archive information structures on the basis ofthe field catalog of the same name.



Archivability Criterion: IDoc StatusThe IDoc status is the only archivability criterion which the write program checksfor the archiving object IDOC. You can use transaction WE47 to display the IDocstatuses which are indicated as archivable.

Figure 121: Status Maintenance - Archiving

The following two figures provide you with an overview of the standard settingsfor archivable IDocs in outbound as well as inbound processing.

Figure 122: Archivable Status Values in Outbound Processing



You can determine the meanings of the individual statuses directly in transactionWE47 in the detailed view of the status, or in transaction BD87 in the input helpfor the field Status.

The following status values are indicated as archivable in outbound processing:

03 Data passed to port OK12 Dispatch OK31 Error, no further processing39 IDoc in receiving system (ALE service)40 Application document not created in target system41 Application document created in target system

It is sometimes necessary to change these standard settings, for example if you setALE 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 theIDocs 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 transactionBD87, select the entry with the incorrect IDoc. Choose Edit→ Restrict andprocess, remove the indicator Background processing and in the next screenchoose the button Delete flag and confirm the confirmation prompt with Enter.

Figure 123: Archivable Status Values in Inbound Processing



The following status values are indicated as archivable in inbound processing:

53 Application document posted68 Error, no further processing

Deleting Links with IDocsThere may be links between IDocs and other objects. In the status monitor(transaction BD87), you can display these link relationships. For example, anoutbound IDoc can be linked to an inbound IDoc, an edited IDoc or an applicationdocument.

As the number of IDocs increases, it is not only the table of data records thatgets big. The tables in which the links are updated also increase in size, so thatobsolete entries should be deleted from them from time to time. Since SAP R/34.6B, the program RSDLDREL has been available. You can use this program todelete application links stored in the table IDOCREL. In contrast to the archivingprocess, this results in them being lost forever. Since SAP Web Application Server6.20, it is possible to archive the links as well when archiving IDocs. Since SAPWeb Application Server 6.40, the links are archived automatically along withthe IDocs. If you no longer need the links, you can still delete this data with theprogram RSRLDREL before archiving.

Reorganizing Change PointersIf you are using the change pointer mechanism to create large numbers of IDocs,you fill the corresponding database tables. Because change pointers are obsoleteafter they are processed, you should regularly delete the table entries that are nolonger required. The program RBDCPCLR is provided for this purpose. Youcan call this program using transaction BD22. It deletes change pointer entriesfrom the database tables.

You can select obsolete and/or processed change pointers. It is also possibleto make a selection based on the date and time. You can display in advancea list of the change pointer entries selected in the test mode. Obsoletechange pointers are those created before the date and time specified byyou in the selection screen. The change pointers you have selected asobsolete are deleted, whether or not they have already been processed.Processed change pointers are those processed before the date and time specifiedby you in the selection screen. Therefore, only the change pointers alreadyprocessed are deleted.



Lesson Summary

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


Unit Summary BIT300

Unit SummaryYou 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


Unit 6Appendix

Unit OverviewIn this appendix, you will find information about renaming logical systems andabout courses of action for identifying and resending lost IDocs after a databasebreakdown.


� Explain the correct procedure for changing logical system names� Describe the IDoc recovery procedure and the settings required for this

function

Unit ContentsLesson: Renaming Logical Systems .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236Lesson: IDoc Recovery Following Database Error .. . . . . . . . . . . . . . . . . . . . . . . .241


Unit 6: Appendix BIT300

Lesson: Renaming Logical Systems

Lesson OverviewThis lesson explains why it is problematic to rename logical systems and howlogical system names can be changed, if required.


� Explain the correct procedure for changing logical system names

Business ExampleWhen setting up an SAP system, you used a name that no longer complies withyour current naming conventions. So you want to check whether it is possible tochange the logical system name now, and which is the best procedure to follow.

Renaming Logical SystemsLogical systems have a technical name up to 10 characters long and an explanatoryshort 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 logicalsystem name to the client.

Figure 124: Logical Systems


BIT300 Lesson: Renaming Logical Systems

Application documents in which the field Logical system has remained empty,or which are saved with the current logical system name of your client, areinterpreted as local documents by the client.

If the logical system name of a client is changed, the modeling of the ALEmessage flow may become inconsistent. Application documents created beforethe logical system name was changed are classified as external documents afterthe change, and can therefore often no longer be found.

ALE provides a tool for renaming logical systems in application tables, thetransaction BDLS.

Figure 125: Conversion of Logical System Names

Client and database copies are often used to set up a development and testlandscape. If users are managed centrally, the participating logical systems musthave unique names. Within an independent SAP system, any logical systemnames can be assigned.

Caution: You are strongly advised against changing the names of logicalsystems in production systems, since this may lead to data losses anddata inconsistency.



Figure 126: What is the Problem?

Figure 127: How Are Logical System Names Changed?


BIT300 Lesson: Renaming Logical Systems

For information on changing the logical system name of a client, see the SAPlibrary or go to the Customizing in ALE and choose IDoc Interface / ApplicationLink Enabling (ALE)→ Basic Settings→ Logical Systems→ Convert LogicalSystem Names in Application Tables.

Note: An appropriate authorization is required for the execution of theprogram (authorization object B_ALE_LSYS).

You are advised to start the conversion in test mode. If you set the indicator Testrun, all relevant tables will be analyzed and the number of entries contained in thetables will be determined. These will then be output in a list. If the new logicalsystem name is already available in the relevant tables, the system queries whetherthe conversion is to be continued or not. You must check the table in which thislogical system name was found and determine whether you want to perform theconversion for these entries. If you do not want to convert these entries, cancelthe conversion.

Figure 128: Conversion - Points to Observe



Lesson Summary

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


BIT300 Lesson: IDoc Recovery Following Database Error

Lesson: IDoc Recovery Following Database Error

Lesson OverviewThis lesson tells you when and how to use the functions for IDoc recovery.


� Describe the IDoc recovery procedure and the settings required for thisfunction

Business ExampleDuring an IDoc transfer, the database of the receiving system crashed. You wantto use the IDoc recovery to restart the transfer of all the IDocs which could not besaved on the database of the receiving system.

IDoc Recovery Following Database Error

Figure 129: IDoc Recovery Following Database Error

The IDoc recovery uses two transactions:

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



Figure 130: IDoc Recovery - Procedure I

Before the transaction is started, the following entries are added to the distributionmodel 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. Thepartner 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, therecovery objects are determined (F8). Finally, the system reports that 1 IDoc hasbeen set up for the message type RCYFET.

As soon as the IDocs for the message types RCYFET, RCYRSP and RCYLSThave 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 fromthe partner system in order to inform the recovered system that the activity wasperformed in this partner system.



Figure 131: IDoc Recovery - Procedure II

All participating systems are provided with information on the date and time of thereset system by using message type RCYFET. IDocs, which were exchanged withthe 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 becarried out are determined in the reset system. This information is sent to thepartner systems in IDocs for the message type RCYLST, in order to derive theactivities for certain objects in the partner systems.



Figure 132: IDoc Recovery - Procedure III



Lesson Summary

You should now be able to:� Describe the IDoc recovery procedure and the settings required for this

function


Unit Summary BIT300

Unit SummaryYou 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


BIT300 Course Summary

Course SummaryYou should now be able to:

� Set up a distribution model for exchanging master and transaction databetween systems

� Create partner profiles for data exchange in enterprises and for electroniccommunication with business partners

� Determine the scope of data to be distributed, depending on its type andrecipient

� Monitor data exchange between systems


Course Summary BIT300


IndexAAccess sequence, 111Adapter, 51ALE Customizing object, 47ALE layer, 37Archiving object, 229BBAPI, 139, 145BAPI Explorer, 145Basic type, 17, 30, 80, 82, 88Business object, 138Business Object Repository,141

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

Customizing, 45DData record, 33Distribution group, 47Distribution model, 60, 121,146, 158

Distribution Model, 18EEDI converter, 105Event, 217

FField value conversion, 49File port, 39Filter group, 84Filter object, 82GGlobal company code, 195IIDoc, 17, 30, 45, 148, 159,179

IDoc basic type, 119, 192IDoc status, 35, 190LLogical system, 9, 16, 60, 121MMaster IDoc, 32, 123Message, 108Message category, 148Message control, 108, 119Message type, 10, 17, 30, 60,76, 80, 86, 109, 111reduced, 86

Model view, 11, 18, 60OOrganizational management,219

Output determinationprocedure, 111

PPartner function, 107Partner profile, 22, 34, 61,106, 120, 150, 159, 191,218

Partner type, 106Port, 20, 38, 106, 120, 191


Index BIT300

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

Processing time, 112RRemote Function Call (RFC),19, 21

RFC destination, 19, 61, 146,158

SSAP Solution Manager, 48SAP Workflow, 212

Segment, 31, 80Segment field, 31Segment filtering, 80Segment type, 31, 87Status record, 33TTransmission medium, 120tRFC port, 39tRFC queue, 39WWork Item, 192, 214


FeedbackSAP AG has made every effort in the preparation of this course to ensure theaccuracy and completeness of the materials. If you have any corrections orsuggestions for improvement, please record them in the appropriate place in thecourse evaluation.


ALE Fundamentals

Documents

Transcript of ALE Fundamentals