• No results found

BIT300 Integration Technology ALE en Col54

N/A
N/A
Protected

Academic year: 2021

Share "BIT300 Integration Technology ALE en Col54"

Copied!
271
0
0

Loading.... (view fulltext now)

Full text

(1)BIT300 Partner. Use. Date Training Center Instructors. SAP. Education Website. Partner. Participant Handbook Course Version: 2005 Q4 Course Duration: 3 Day(s) Material Number: 50078127. An SAP course - use it to learn, reference it for work. Only. Internal. Use. SAP. SAP NetWeaver. Internal. Only. Integration Technology ALE.

(2) Copyright Copyright © 2006 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. Additionally this publication and its contents are provided solely for your use, this publication and its contents may not be rented, transferred or sold without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.. Partner SAP Use. •. ORACLE® is a registered trademark of ORACLE Corporation.. •. INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.. •. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.. •. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.. •. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.. •. JAVA® is a registered trademark of Sun Microsystems, Inc.. •. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.. •. SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.. Disclaimer THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.. g200672943835. Only. Internal. 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.. Partner. •. SAP. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.. Use. •. Internal. Only. Trademarks.

(3) About This Handbook This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.. American English is the standard used in this handbook. The following typographic conventions are also used.. Partner. Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options.. Example text. SAP. Description. Example text. Emphasized words or phrases in body text, titles of graphics, and tables. EXAMPLE TEXT. Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.. Example text. Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.. Example text. Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.. <Example text>. Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.. iii. Internal. Only. © 2006 SAP AG. All rights reserved.. Partner. 2005/Q4. SAP. Use. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).. Use. Type Style. Internal. Only. Typographic Conventions.

(4) About This Handbook. BIT300. Icons in Body Text The following icons are used in this handbook. Icon. Meaning. Only. Exception or caution. Indicates that the item is displayed in the instructor’s presentation.. Use. Procedures. Internal. Note or further explanation of previous point. Partner. For more information, tips, or background. SAP. SAP Only. Internal. Use. Partner. iv. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(5) Contents Course Overview ............................................................................. vii. Partner SAP. Unit 2: Master Data Distribution .......................................................... 59 Example: Material Master ................................................................. 60 Using Change Pointers .................................................................... 79 Data Filtering and Reducing the Scope of Data ........................................ 84. Unit 3: Distributing Transaction Data: Message Control.. .........................107. Unit 4: Distributing Transaction Data: BAPIs.........................................143. Unit 5: Monitoring Data Distribution, Error-Handling and Archiving ............185 IDoc Status Management................................................................. 187 Error Analysis and Handling.............................................................. 198 SAP Workflow in ALE Environment ..................................................... 222 Archiving IDocs ............................................................................ 238. Unit 6: Appendix .............................................................................247 Renaming Logical Systems .............................................................. 248 IDoc Recovery Following Database Error .............................................. 254. 2005/Q4. © 2006 SAP AG. All rights reserved.. v. Only. Business Object Types and BAPIs ...................................................... 144 The Usage of BAPIs in ALE .............................................................. 152 Example: Travel Expenses ............................................................... 162. Partner. Message Control and IDoc Generation ................................................. 108 Example: Purchase Order Processing.................................................. 123. SAP. Use. Cross-System Business Processes ........................................................ 3 The Distribution Model ....................................................................... 9 Basic ALE Customizing .................................................................... 15 Intermediate Documents................................................................... 30 Synchronizing Customizing ............................................................... 46 ALE and the SAP NetWeaver Exchange Infrastructure ............................... 53. Use. Internal. Unit 1: ALE Fundamentals ...................................................................1. Internal. Only. Course Goals.................................................................................vii Course Objectives ...........................................................................vii.

(6) Contents. BIT300. Index ............................................................................................261. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. vi. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(7) Course Overview This course explains how to use Application Link Enabling (ALE) using predefined example scenarios. You will learn how to configure ALE scenarios and how to control data exchange between systems.. Only. Internal. Target Audience This course is intended for the following audiences:. Partner. • •. Consultants Project team members. Course Prerequisites. Use. Required Knowledge •. SAPTEC (Fundamentals of SAP Web AS). SAP. •. SAP. Recommended Knowledge BIT100 (SAP NetWeaver Process Integration). Use. This course will prepare you to:. • •. Create a system landscape for using different ALE scenarios (distributing master data and transaction data) Control data exchange between systems in a distributed system landscape Correctly assess the capabilities and limitations of ALE. Only. Internal. •. Course Objectives After completing this course, you will be able to: • • •. 2005/Q4. Set up a distribution model for exchanging master and transaction data between systems Create partner profiles for data exchange in enterprises and for electronic communication with business partners Determine the scope of data to be distributed, depending on its type and recipient. © 2006 SAP AG. All rights reserved.. Partner. Course Goals. vii.

(8) Course Overview. •. BIT300. Monitor data exchange between systems. SAP Software Component Information The information in this course pertains to the following SAP Software Components and releases:. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. viii. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(9) Unit 1 Unit Overview. Unit Objectives After completing this unit, you will be able to:. SAP Use Internal. • • • •. 2005/Q4. © 2006 SAP AG. All rights reserved.. 1. Only. • • • • •. Partner. • •. 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. SAP. • • •. Use. Partner. In this unit, you will first learn about the possible applications of ALE in enterprises. You will then find out which basic settings you need to make in Customizing and applications to use ALE.. Internal. Only. ALE Fundamentals.

(10) Unit 1: ALE Fundamentals. BIT300. Unit Contents. Only. Use. Partner. Internal. Lesson: Cross-System Business Processes ....................................... 3 Lesson: The Distribution Model ...................................................... 9 Lesson: Basic ALE Customizing ................................................... 15 Exercise 1: Basic ALE Customizing .......................................... 25 Lesson: Intermediate Documents ................................................. 30 Exercise 2: Documentation for Basic Types ................................. 43 Lesson: Synchronizing Customizing .............................................. 46 Lesson: ALE and the SAP NetWeaver Exchange Infrastructure .............. 53. SAP. SAP Only. Internal. Use. Partner. 2. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(11) BIT300. Lesson: Cross-System Business Processes. Lesson: Cross-System Business Processes Lesson Overview This lesson introduces examples of the application and use of ALE.. Lesson Objectives • •. List examples of business processes in distributed system landscapes Differentiate ALE from EDI. Globally-active enterprises usually structure their business using multiple clients in an SAP system, often also using multiple SAP systems. Frequently, these are joined by systems for specific applications from other providers. You need to clarify how the parties involved in this kind of system group exchange data with each other.. SAP Use. Only. Internal. Partner. An enterprise's head office, subsidiaries and sales and distribution branches are often technically separate systems. Each subsystem communicates not only with the other members of the system group but also with business partners, such as customers, vendors, banks and public authorities.. SAP. Enterprise Structure and Business Processes. Use. Partner. Business Example. Internal. Only. After completing this lesson, you will be able to:. Figure 1: The Enterprise as a Whole and External Parties. 2005/Q4. © 2006 SAP AG. All rights reserved.. 3.

(12) Unit 1: ALE Fundamentals. BIT300. In the example illustrated above, the master data for the overall enterprise network is created and changed in the head office only. New master data and changes to existing data are regularly sent to the downstream systems of the sales and distribution branch and production. The central purchasing department orders from vendors, the sales and distribution branch receives orders from customers and sends these to production to be manufactured. Communication is to be electronic throughout all the processes.. Use. Partner. Only. Internal. Figure 2: Example: Sales Order Processing. SAP Use Internal. • • • •. 4. Analysis of the enterprise's organizational structure and the mapping of its technical systems: which SAP systems or clients make up the enterprise's system landscape? Are there any non-SAP systems involved? Listing the software products installed in each participating system Describing the business processes that need to be mapped in the system landscape Breaking these processes down into individual steps Distributing the individual steps of the overall process to the participating systems or business partners. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. •. Partner. Preparatory Steps for Mapping Cross-System Business Processes. SAP. The customer sends a purchase order to the sales and distribution branch. The SD branch's system creates an order from the data in this purchase order and then an (internal) purchase order, which it sends to production's system. In the production system, an order is generated from this data. Depending on the agreements between the two enterprise areas, the production system confirms the order from the SD branch and announces delivery of the ordered material amounts. The SD branch can now confirm the customer's order in turn and notify the customer of a consignment of goods. After the goods have been delivered, production invoices sales and distribution for them. SD then, in turn, presents the customer with an invoice for the delivered goods..

(13) BIT300. Lesson: Cross-System Business Processes. Internal Communication: Distributing Master Data with ALE ALE can be used within an enterprise for central master data administration (among other uses): master data is created and changed in only one of the systems in the enterprise network. The master data is distributed from this maintenance system to the downstream systems; the data records are forwarded in electronic form to each of the recipients. A typical example of this is centralized master data administration.. Use Internal. • • • •. 2005/Q4. Which master data is maintained in which system? To which systems must the master data then be distributed? How often is the data distributed, and when? Do all the recipients receive all the data in its entirety?. © 2006 SAP AG. All rights reserved.. 5. Only. Basic Questions when Planning Centralized Master Data Distribution. Partner. In the scenario illustrated above, all the material masters are created in the head office and distributed from there to the downstream systems of sales and distribution and production. However, sales and distribution should only receive the master records for finished products, whereas production should receive material master data for both finished products and raw materials. When configuring the ALE scenario, it is therefore important to pay attention to the distribution hierarchy and also to take into account the fact that not every recipient receives all the data. In a different scenario, the departments in the receiving system are responsible for the maintenance of certain portions of a master record. In this case, the master record should not be transferred in its entirety, or there needs to be a guarantee that values changed locally cannot be overwritten if the data records are transferred again.. SAP. SAP. Use. Partner. Only. Internal. Figure 3: Example: Centralized Material Master Administration.

(14) Unit 1: ALE Fundamentals. BIT300. Communication with External Parties: Purchase Order Handling with EDI You want to communicate electronically not only within the enterprise, but also with your business partners. In this way, the data from an order created in your own system can be electronically transferred to a vendor, who, in turn, sends an order confirmation, shipping confirmation and finally an invoice.. Use. Partner. Only. Internal. SAP. SAP. Use Internal. Separating Systems for Legal Reasons: Human Resources Often, to comply with data protection legislation, a separate system is set up for human resources (HR). In this system, HR master data is managed, payroll accounting is processed and other sensitive data is retained. Unauthorized access to this data is. 6. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. Generally, data exchange with external parties (that is, business partners, banks, or government agencies) is carried out using Electronic Data Interchange (EDI), not ALE. An electronic document is sent in an SAP-specific format from an SAP system to an EDI subsystem, called a converter. The subsystem converts this document to an EDI document, and sends it to the supplier. The unit on “Distributing Transaction Data: Message Control” contains more information about the differences between ALE and EDI.. Partner. Figure 4: Example: Purchase Order Processing.

(15) BIT300. Lesson: Cross-System Business Processes. supposed to be prevented (or at least made difficult) by technically separating the HR system from the other systems in the enterprise network. Other possible reasons for separating human resources are: • • •. Independence during technical upgrades Independence when installing Support Packages that effect (human resource-related) legal changes (known as Legal Change Patches) Better performance. Use. Only. Internal. Partner. Since Accounting is one of the systems included in the head office system, this latter also requires HR master data for paying salaries and wages or reimbursing travel costs. Cost centers and other account assignment objects are also required in both systems. Thus even in the case of a separate Human Resources system, master data distribution is useful. The results from the payroll or travel expenses are transferred to head office from the HR system for posting in Accounting.. SAP. SAP. Use. Partner. Only. Internal. Figure 5: Separate System for Human Resources. 2005/Q4. © 2006 SAP AG. All rights reserved.. 7.

(16) Unit 1: ALE Fundamentals. BIT300. Lesson Summary You should now be able to: • List examples of business processes in distributed system landscapes • Differentiate ALE from EDI. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. 8. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(17) BIT300. Lesson: The Distribution Model. Lesson: The Distribution Model Lesson Overview. Internal. Only. The distribution model is the core component of ALE, as it determines which sender transfers which data to which recipients. It is made up of assignments of logical system names and message types. This lesson explains all three terms and the function each one plays in ALE scenarios.. Lesson Objectives After completing this lesson, you will be able to:. •. Explain the terms “logical system” or “logical system name”, “message type” and “distribution model” Explain the function of the distribution model. Use. Partner. •. Business Example. SAP. SAP. You have analyzed your business processes and the existing system landscape. You want to familiarize yourself with the configuration of an ALE scenario, using the example of centralized master data administration as a basis.. Logical System Name. Use. Only. Internal. Partner. Once you have determined which parts of the enterprise should use ALE to exchange data with each other, define logical system names for every client involved in the system group and, if applicable, for all external systems (if this has not already been done).. Figure 6: Example of a Scenario to be Mapped. 2005/Q4. © 2006 SAP AG. All rights reserved.. 9.

(18) Unit 1: ALE Fundamentals. BIT300. The logical system name uniquely identifies the client of an SAP system or a non-SAP system in the system landscape. If the name refers to a client, assign the name to the client in the next step. To guarantee that the logical system name is unique and to simplify the assignment, SAP recommends using the naming convention <System name>CLNT<Client key>. In the example illustrated below, the SAP system has the key G23. Clients 800, 810 and 811 are used. Thus, for example, client 800 receives the logical system name G23CLNT800.. Only. Use. Partner. Internal. Note: The terms “logical system name” and “logical system” are used interchangeably.. Internal. Caution: Changing the logical system name is a serious intervention, as this name is included in numerous application tables (see lesson on “Basic ALE Customizing” and appendix “Renaming Logical Systems”).. 10. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. In certain cases, it could be useful not to use SAP's recommended convention for logical system names. The training clients for this course have “descriptive” names: the logical system name for head office is CORE, sales and distribution is called SALES and production is PRODUCTION. Naming the systems in this way is an alternative to the SAP convention if the assignment of clients to logical system names is frequently changed.. Partner. Use. SAP. SAP. Figure 7: Logical System Names.

(19) BIT300. Lesson: The Distribution Model. Message Type When configuring an ALE scenario, in addition to assigning logical system names, you also need to indicate the types of data that are to be exchanged: if, for example, you want to distribute material masters with ALE in the future, you need to name the type of data (material masters) with what is known as a message type (MATMAS). Message types are therefore essentially keys, comparable to logical system names, which indicate data that can be exchanged between systems in ALE or EDI scenarios.. Use. Partner. Only. Internal. Internal. Note: In some ALE scenarios, “Business Application Programming Interfaces” (BAPIs) are used instead of message types. You will learn about how to use BAPIs in ALE in the unit: “Distributing Transaction Data: BAPIs”.. Distribution Model and Model Views If you want data to be sent from one logical system to another, you specify in the distribution model which message type is to be sent from which logical system to which logical system(s). The distribution model bundles all the assignments of. 2005/Q4. © 2006 SAP AG. All rights reserved.. 11. Only. Both elements – the logical system name and message type – are linked to each other in the distribution model, in order to determine which sender sends which data to which recipient. In the example illustrated above, the head office (CORE logical system) distributes material masters (MATMAS message type) to sales and distribution (SALES logical system) and production (PRODUCTION logical system).. Partner. Use. SAP. SAP. Figure 8: Logical Systems and Message Types.

(20) Unit 1: ALE Fundamentals. BIT300. senders, recipients and data to be sent. If you set up a new ALE scenario, you normally create a new model view for this scenario in the distribution model of one of systems involved. In this model view, you name the sender and recipient using their logical system names and then add the message type describing the type of data that is to be sent.. SAP Use. Partner Only. Internal. SAP. You then need to distribute the newly created model view, in other words, make it known to the other systems involved. In the example shown above, the model view “master data” was created in the CORE logical system. However, this also affects the logical systems SALES and PRODUCTION. They receive copies of the new model view. You can distribute a model view to the partner systems using ALE, subject to certain conditions (explained below). It is, however, also possible to transport a model view to other systems.. Use. Partner. Only. Internal. Figure 9: Model View in a Distribution Model. 12. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(21) BIT300. Lesson: The Distribution Model. Use. Partner. Only. Internal. Figure 10: Distributing Model Views. SAP Use. Only. Internal. Partner. You can find the distribution model in the IMG via SAP NetWeaver → SAP Web Application Server → IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model and Distribute Views.. SAP. Note: To ensure that data remains consistent, you should maintain the distribution model centrally in one logical system and then distribute or transport its views to the other affected logical systems.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 13.

(22) Unit 1: ALE Fundamentals. BIT300. Lesson Summary You should now be able to: • Explain the terms “logical system” or “logical system name”, “message type” and “distribution model” • Explain the function of the distribution model. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. 14. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(23) BIT300. Lesson: Basic ALE Customizing. Lesson: Basic ALE Customizing Lesson Overview This lesson introduces basic ALE Customizing. In addition to this, you will learn where to find information about the ALE scenarios provided by SAP.. Lesson Objectives. Only. •. Partner. Business Example. SAP Use. Only. Internal. You can find all the basic Customizing settings in an SAP system's Implementation Guide (IMG) under SAP NetWeaver → SAP Web Application Server → IDoc Interface / Application Link Enabling (ALE). You can also call this section of the IMG directly by calling transaction SALE.. Partner. ALE Customizing in the Implementation Guide. SAP. You want to use ALE to exchange data between two SAP systems. You therefore want to get an overview of the Customizing settings needed to set up ALE scenarios. You also want to check if there is a standard ALE scenario that would be suited to your purposes.. Use. • • • •. 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. Internal. After completing this lesson, you will be able to:. 2005/Q4. © 2006 SAP AG. All rights reserved.. 15.

(24) BIT300. Figure 11: Transaction SALE. Partner SAP Use. Only. Internal. Partner. Each system in the system landscape must have a logical system name. This name uniquely identifies the logical system in the system landscape. You can then assign this name to the client of an SAP system.. SAP. Defining Logical System Names and Assigning them to Clients. Use. In the area Modelling and Implementing Business Processes, you will find extensive documentation about ALE scenarios, which you can use in many different applications (→ Configure Predefined ALE Business Processes). If, for example, you are interested in possible uses of ALE in human resources, go to Modelling and Implementing Business Processes → Configure Predefined ALE Business Processes → Human Resources. Depending on the application, you will find, in addition to a description of the scenario and the substeps needed to configure it, supporting functions, such as “auto-Customizing” or a program for checking the completeness and internal consistency of your settings.. Internal. Only. Unit 1: ALE Fundamentals. 16. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(25) BIT300. Lesson: Basic ALE Customizing. SAP Use. Hint: You can also call this table directly, using a transaction code (SCC4).. Message Types and Basic Types In ALE, message types indicate the data that is to be exchanged between each of two systems. MATMAS, for example, represents material records. The material master data to be distributed is transported in an electronic intermediate document (IDoc) from the sender system to the recipient system. This IDoc contains the data from the master record in an SAP-specific format. The structure of the document is determined in a basic type. The basic type defines the formatting structure of the data record that. 2005/Q4. © 2006 SAP AG. All rights reserved.. 17. Only. Internal. You can find the assignment of logical system names to clients in the IMG, via SAP NetWeaver → SAP Web Application Server → IDoc Interface/Application Link Enabling (ALE) → Logical Systems → Assign Logical System to Client.. Partner. Hint: You can also call the table of logical system names directly, using transaction code BD54.. SAP. You can define logical system names in Customizing. In the SAP Reference IMG, choose SAP NetWeaver → SAP Web Application Server → IDoc Interface/Application Link Enabling (ALE) → Logical Systems → Define Logical System.. Use. Partner. Only. Internal. Figure 12: Defining Logical Systems.

(26) Unit 1: ALE Fundamentals. BIT300. is to be sent. Generally, the name of the IDoc basic type is the same as the name of the message type but with a version number added to it. The current version of the basic type for message type MATMAS, for example, is MATMAS05.. SAP Use. In the distribution model of a logical system, you define for each of your ALE scenarios which logical system sends what type of data to which partner system. You can create new model views in Customizing. To do this, in the IMG, go to SAP NetWeaver → SAP Web Application Server → IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model and Distribute Views or call the distribution model directly via transaction BD64.. 18. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. Internal. Creating Model Views in the Distribution Model. Partner. Note: The structure and use of IDocs is described in more detail in the lesson on “Intermediate Documents”.. SAP. To find out which version of the basic type is best suited to your SAP system's release level, see the table Output Types and Assignment to IDoc Types. To do this, in the SAP Easy Access Menu, go to Tools → ALE → ALE Development → IDoc → IDoc Type Development → IDoc Type for Message (transaction WE82). For an overview of all the message types, go to Tools → ALE → ALE Development → Logical Messages (transaction WE81).. Use. Partner. Only. Internal. Figure 13: Message Type and Basic Type.

(27) BIT300. Lesson: Basic ALE Customizing. SAP. SAP. To create a new model view, enter the logical system names of the sender and the recipient and a message type. You can assign logical systems for different message types as well as the sender and recipient roles in the same model view.. Use. Partner. Only. Internal. Figure 14: Distribution Model Maintenance in the IMG. Only. Internal. Use. Partner. Figure 15: Distribution Model. 2005/Q4. © 2006 SAP AG. All rights reserved.. 19.

(28) Unit 1: ALE Fundamentals. BIT300. To ensure the consistency of the data across the system landscape and beyond, it is advisable to maintain the different views of a distribution model in one central system, and distribute them or transport them to the partner systems (see below).. RFC Destinations and Ports. Only. Use. Partner. Internal. In ALE scenarios, the systems involved exchange data via Remote Function Calls (RFC). From one SAP system, an RFC calls a function module in another SAP system. RFCs make it possible to exchange data between different SAP systems or between one SAP system and a non-SAP system. In non-SAP systems, specially-programmed functions are called instead of function modules; the interface of these functions simulates a function module.. SAP. SAP. For your ALE scenarios, you create RFC destinations for all the partner systems in each system involved. To do this, select in the ALE Customizing IDoc Interface / Application Link Enabling (ALE) → Communication → Create RFC Connections or use transaction SM59. In the RFC destinations, specify a target host, IP addresses, and. 20. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. Internal. Use. Partner. Figure 16: Defining RFC Destinations.

(29) BIT300. Lesson: Basic ALE Customizing. (if applicable) the system number and user and logon data for “remote login” in the target system. Thus the RFC destination contains all the technical information that the calling system needs to call the partner from within the network. Hint: If you give the RFC destination the same name as the logical target system, you can have the system carry out certain settings automatically later on.. Use. Only Partner. Note: There are different types of port in SAP systems. ALE always uses RFC ports. In EDI scenarios, you can also use file ports in addition to RFC ports (see lesson on “Intermediate Documents”).. Transferring IDocs Using tRFC. SAP. Only. Internal. Partner. In transactional RFC calls, the data that belongs to an RFC function must be saved temporarily in the SAP database in the RFC client system. Once the processing is complete, this must be confirmed to the calling ABAP program. The tRFC component in the SAP system handles everything else.. SAP. To ensure that RFC functions can be executed reliably, securely, and independently of RFC server or RFC server system availability, the transactional RFC (tRFC) was introduced in SAP R/3 3.0. This ensures that the function module called is only executed once in the RFC server system.. Use. Internal. In order to use ALE scenarios later on, the RFC must be assigned to a port. The sender uses the port to determine the communication channel to the recipient. You can create ports manually or – if the logical target system and the RFC destination have the same name – have the sender system create them.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 21.

(30) Unit 1: ALE Fundamentals. BIT300. Partner. Only. Internal. Figure 17: Transactional RFC. SAP Use Internal. • • •. 22. Suppress batch job in the event of communication errors (manual start with transaction SM58 required) Number of connection attempts Interval in minutes between repeated attempts to transfer data. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. In the SAP system, you can set tRFC parameters for the relevant connection in table RFCDES (for connection types T, 3, I) (SM59):. Partner. Note: An external tRFC client needs to repeat the calls itself at a later time.. SAP. If a connection error occurs during a synchronous RFC, the client repeats the call without knowing whether the processing has already taken place. The tRFC solves this problem as tRFC calls can be transferred even if the target system is not available. In these cases, the data is saved locally in the sender system and transmitted later. In SAP R/3 or SAP ECC, automatic job scheduling is used for this purpose. The job starts the corresponding function module(s) in the target system at a later time.. Use. As a database on an external system is not always available, the connection to the tRFC interface is implemented in such a way that the client or server programs must perform a number of administration functions on the RFC API basis to ensure that the function module is executed only once..

(31) BIT300. Lesson: Basic ALE Customizing. Partner Profiles In ALE scenarios, application programs check the system's distribution model when they are called, in order to identify the recipient of each message prepared in IDoc format. ALE scenarios require partner profiles for every combination of recipient system and message type. These profiles are also necessary for processing inbound IDocs. There is always an outbound and an inbound partner profile for each message type in an ALE scenario.. Use. Partner. Only. Internal. Internal. From the inbound partner profile, the recipient system reads how and when the data from the inbound IDoc is to be transferred to the relevant application. As a rule, what is known as a process code is used to find a function module for the inbound processing of the IDoc. For a model view to be distributed to all the partner systems, the sender system must contain outbound partner profiles for message type SYNCH for all the affected recipient systems. This message type is used only for determining the RFC destination for the target system. If the name of the logical target system and its RFC destination. 2005/Q4. © 2006 SAP AG. All rights reserved.. 23. Only. On the one hand, the sender system reads the basic type for the message type from the outbound partner profile, so that it can create an IDoc with the data that is to be distributed. On the other, the sender system uses the port assigned to the partner profile to find the RFC destination that enables it to call the recipient system. In addition to this, the partner profile determines whether the IDoc is sent immediately or not until later.. Partner. Use. SAP. SAP. Figure 18: Partner Profiles.

(32) Unit 1: ALE Fundamentals. BIT300. are the same, the sender system can automatically create a port with the appropriate RFC destination and generate the partner profiles for the message types of a model view. The authorization object for distributing model views is B_ALE_MODL. Note: The lesson on “Intermediate Documents” explains how to create and change ports and partner profiles.. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. 24. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(33) BIT300. Lesson: Basic ALE Customizing. Exercise 1: Basic ALE Customizing Exercise Objectives. Business Example. Task:. SAP Use. 2.. In one of the three clients for the mySAP ERP logistics and accounting system, check the assignment of the logical system names to the three clients. Make a note of the assignment: Logical system. Client. Only. Internal. Search in the IMG documentation for ALE scenarios for master data distribution. To do this, use the IMG section IDoc Interface / Application Link Enabling (ALE) (transaction SALE).. CORE SALES PRODUCTION. Continued on next page. 2005/Q4. © 2006 SAP AG. All rights reserved.. Partner. 1.. SAP. First, look in the IMG documentation to see if there are any ALE scenarios for master data distribution between SAP systems. Next, check the assignment of the logical system names CORE, SALES and PRODUCTION to the three training clients mentioned by your instructor. Then take a look at the distribution model for the CORE logical system.. Use. Partner. You want to use ALE to exchange data between two SAP systems. You therefore want to get an overview of the Customizing settings needed to set up ALE scenarios. You also want to check if there is a standard ALE scenario that would be suited to your purposes.. Internal. Only. After completing this exercise, you will be able to: • Find information about ALE scenarios supplied by SAP • Determine which logical system names are allocated to which clients • Check distribution model views and partner profiles. 25.

(34) Unit 1: ALE Fundamentals. 3.. BIT300. In the distribution model for the CORE system, select all the model views containing message type MATMAS.. 4.. From the distribution model, display the CORE system's partner profiles for the SALES and PRODUCTION systems. Check the detail settings for the MATMAS message type.. 5.. Check the corresponding inbound partner profiles in the SALES system.. Use. Partner. Internal. Only. Hint: Use the Filter model display button.. SAP. SAP Only. Internal. Use. Partner. 26. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(35) BIT300. Lesson: Basic ALE Customizing. Solution 1: Basic ALE Customizing Task:. a). Select IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Configure Predefined ALE Business Processes → Logistics → Master Data Distribution.. b). You will find IMG activities for setting up various master data distribution scenarios.. In one of the three clients for the mySAP ERP logistics and accounting system, check the assignment of the logical system names to the three clients. Make a note of the assignment: Logical system. Client. Use. SALES. a). Choose IDoc Interface Application Link Enabling (ALE) → Basic Settings → Logical Systems → Assign Logical System to Client.. b). One by one, select the table entries for the three training clients and click for each one: in the Logical system field, you will see the Details logical system name assigned to the client in question (CORE, SALES or PRODUCTION).. Continued on next page. 2005/Q4. © 2006 SAP AG. All rights reserved.. 27. Only. Internal. PRODUCTION. Partner. CORE. SAP. SAP. 2.. Search in the IMG documentation for ALE scenarios for master data distribution. To do this, use the IMG section IDoc Interface / Application Link Enabling (ALE) (transaction SALE).. Use. Partner. 1.. Internal. Only. First, look in the IMG documentation to see if there are any ALE scenarios for master data distribution between SAP systems. Next, check the assignment of the logical system names CORE, SALES and PRODUCTION to the three training clients mentioned by your instructor. Then take a look at the distribution model for the CORE logical system..

(36) Unit 1: ALE Fundamentals. 3.. BIT300. In the distribution model for the CORE system, select all the model views containing message type MATMAS.. SAP Use. From the distribution model, display the CORE system's partner profiles for the SALES and PRODUCTION systems. Check the detail settings for the MATMAS message type. a). In the distribution model's menu, select Environment → Change partner profile.. b). Open the folder for partner type LS (logical system) and select the entry for the SALES partner.. c). In the outbound parameters, select the entry for message type MATMAS and click on DetailScreenOutb.Parameter : the SALES port and the MATMAS05 basic type are assigned here. The IDocs should be sent immediately.. Check the corresponding inbound partner profiles in the SALES system. a). Call the distribution model as in step 3 a).. b). In the menu, select Environment → Change partner profile, open the folder for partner type LS and select the CORE partner.. c). Select the inbound parameters for the entry for message type MATMAS and click on DetailScreenInboundParameter : process code MATM is assigned here. The IDocs should be processed immediately.. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. Internal. Click on the Filter model displays button, enter MATMAS in the Message Type field and select Execute : the system will only display model views containing message type MATMAS.. Partner. 28. b). SAP. 5.. Select IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model and Distribute Views.. Use. Partner. 4.. a). Internal. Only. Hint: Use the Filter model display button..

(37) BIT300. Lesson: Basic ALE Customizing. Lesson Summary. Only. Use. Partner. Internal. 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. SAP. SAP Only. Internal. Use. Partner. 2005/Q4. © 2006 SAP AG. All rights reserved.. 29.

(38) Unit 1: ALE Fundamentals. BIT300. Lesson: Intermediate Documents Lesson Overview. Lesson Objectives After completing this lesson, you will be able to:. • •. Explain and differentiate between the terms “basic type”, “master IDoc” and “communications IDoc” Determine the details of basic types Describe the process from the creation of an IDoc in the sender system through to processing in the target system. SAP. You want to use ALE to exchange data between two SAP systems and, by doing so, find out more about the technical implementation of ALE scenarios.. Use Internal. Note: Message types specify the type of data that is to be distributed. They are included in distribution model views. In the outbound partner profiles for sender and recipient, the appropriate basic type is assigned to one message type (see the lesson on “Basic ALE Customizing”). The example illustrated below shows a section from the structure of the basic type MATMAS05.. 30. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. In ALE scenarios, data sent between two SAP systems or between SAP systems and non-SAP systems is transported in the form of Intermediate Documents (IDocs). The structure of an IDoc is specified by the basic type or IDoc type. Basic types are linked to message types. A basic type can be compatibly enhanced for a new release, in the same way as the interfaces of an ABAP function module. This means that there are often various basic types for one message type: each basic type represents a version of the same basic pattern.. Partner. Structure of an IDoc: The Basic Type. SAP. Business Example. Use. Partner. •. Internal. Only. In ALE scenarios, the systems involved exchange data in the form of intermediate documents (IDocs). This lesson deals with the structure of IDocs, presents various possible ways of generating IDocs and gives you an overview of the whole process, from IDoc creation in the sender system, through to the processing of the data in the recipient system..

(39) Lesson: Intermediate Documents. Internal. Only. BIT300. SAP Use. The structure of the basic types provided by SAP is documented in detail in SAP R/3 and mySAP ERM. To call this documentation, go to Tools → ALE → ALE Administration → Services → Documentation → IDoc Types and Segments or call transaction WE60.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 31. Only. Internal. Note: For an overview of the segment structure of a basic type, see transaction WE30 (IDoc Type Development).. Partner. An IDoc does not have to contain all the segments of its segment type, and a segment type can have more than one segment. Whether an IDoc must contain a particular segment, and how many segments are permitted for a segment type, is determined in the IDoc type.. SAP. The basic type structures the formatting of the application data that is to be sent. Among other things, it specifies which data is stored in which location (row and offset). It also determines the order in which application data belongs to a message. An IDoc's data is organized in rows. The rows make up the segments of an IDoc, which are, in turn, composed of segment fields. The row structure of an IDoc segment is determined by a segment type. For every segment field, the field name is stored along with the technical properties and semantics of the field. IDoc segments can be hierarchically related to one another.. Use. Partner. Figure 19: The Basic Type.

(40) Unit 1: ALE Fundamentals. BIT300. In addition to information about the IDoc segments and their hierarchical dependencies, this documentation includes the following attributes: • •. •. IDoc type attributes: information, such as the first release of the IDoc type. Segment type attributes: this includes the information about whether a segment is “required” or “optional” and the minimum or maximum number of segments allowed for a segment type. Segment field attributes: technical and semantic properties of a field.. Only. The Master IDoc. SAP. SAP. The application programs that you use in ALE scenarios always begin by generating an internal table based on the IDoc basic type and using an ABAP program; this table is called a master IDoc. The application data is formatted line by line according to the basic type and then inserted in this internal table. An internal table is a data object in an ABAP program that exists only during the runtime of the program. Internal tables are, therefore, not saved to the database.. Use. Partner. Note: The basic types provided by SAP can be enhanced to suit the customer's needs. The BIT350 training course deals with enhancing IDoc basic types (ALE enhancements).. Internal. In addition to this, the documentation generally contains information about earmarking a segment field for organizational or business needs.. Only. Internal. Use. Partner. Figure 20: Structure of a Master IDoc. 32. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(41) BIT300. Lesson: Intermediate Documents. Each line in the internal table consists of a control part, which contains the meta information for the line, and the actual data part. The most important information in the control part is the name of the segment type that describes the structure of the data part.. Client. DOCNUM. Number of the IDoc. Only. SEGNUM. Consecutive number (line number in internal table). SEGNAM. Name of the segment type. PSGNUM. Line number of the parent segment. HLEVEL. Hierarchy level. Internal. MANDT. Partner. The control section of every row consists of the following fields:. Overall length of data part. SDATA. Long field of type CHAR. Contains the data in the structure, which is described by the segment type.. Partner. Use. The line type of the internal table is determined by the ABAP Dictionary structure type EDIDD.. The Communications IDoc. © 2006 SAP AG. All rights reserved.. Internal. Only. Later in the application program run, the system uses the data from the master IDoc to generate a communications IDoc, an intermediate document that is saved to the database and then sent. When the system or documentation refers to an “IDoc”, they are generally referring to this communications IDoc. Every communications IDoc consists of exactly one control record and multiple data records and status records.. 2005/Q4. SAP. DTINT2. Use. SAP. The data part consists of the following fields:. 33.

(42) Unit 1: ALE Fundamentals. BIT300. Use. Partner. Only. Internal. Figure 21: Structure of a Communication IDoc. SAP Use. Creating IDocs Application programs create IDocs in different ways. The figure below covers the four basic forms of IDoc creation:. 34. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. Internal. The status records contain the processing steps of the IDoc. They log the stations that the IDoc has run through from when it was created to when it was sent; this helps you to monitor data distribution between systems.. Partner. The data records in the communications IDoc correspond to the lines in the master IDoc.. SAP. The important part of the control record is the IDoc number, which is assigned internally in the system. This number is unique within a logical system. You define the value range in each system using a number range interval. The control record also contains the key fields of the partner profiles, and the last processing status..

(43) Lesson: Intermediate Documents. Internal. Figure 22: How is an IDoc Created?. •. Use. •. Internal. Exchanging Data with IDocs: Overview of the Process Data exchange using IDocs begins in the sender system when an intermediate document is created in IDoc format and ends when the data transported by the IDoc is posted in an application in the target system. In the process, certain stations are processed, which the sender and target systems each mark with status values.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 35. Only. Note: In later units, you will become familiar with examples of IDoc generation using SMD, message control and BAPIs. In each lesson in this unit, you will also learn about how you can use these instruments for your ALE scenarios.. Partner. •. Dedicated transactions: the preconfigured ALE scenarios for centralized master data administration use application transactions that were specifically programmed for creating IDocs. These transactions are brought together in the umbrella term “Shared Master Data” (SMD). Message control: some logistical applications in SAP R/3 and mySAP ERM use message control to output the data from their documents. Formatting the document data in IDoc format is one of the message output options. Application programs: some application programs generate IDocs directly by filling an internal table in IDoc format and further processing it. Business Application Programming Interfaces (BAPIs): the application program uses a BAPI with an ALE interface.. SAP. SAP. •. Use. Partner. Only. BIT300.

(44) Unit 1: ALE Fundamentals. BIT300. Use. Partner. Only. Internal. SAP Use. •. Note: You will find out about other status values in the unit on “Monitoring Data Processing, Error Handling and Archiving”.. 36. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. • •. Partner. •. •. Regardless of how the IDoc was created, it is first saved to the sender system's database (status value 01). If all the information required for sending has been obtained from the recipient, then the IDoc receives the status “ready for dispatch” (status value 30). If the outbound partner profiles specify that the IDoc is to be transferred immediately to the port stored in the relevant message type, then the IDoc is sent and receives a corresponding status (status value 03). However, it is also possible to send multiple IDocs bundled together at a later time. The IDoc is saved to the target system's database (status value 50). If all information about further processing is known, the IDoc can be transferred to the application (status value 64). If the inbound partner profiles specify that the IDoc is to be transferred to the application immediately, the target system attempts to post the IDoc data (status value 62). If the inbound processing is successful, the IDoc receives status value 53.. SAP. •. Internal. Figure 23: The IDoc's Path and Status Values.

(45) BIT300. Lesson: Intermediate Documents. Exchanging Data with IDocs: Process Substeps First, the application program generates a master IDoc containing the application data.. Use. Only. Internal. The ALE layer checks the distribution model to determine the recipient(s) of the message.. Partner. The master IDoc is transferred to what is known as the ALE layer. The ALE layer is the ALE-specific part of the application program.. SAP. SAP. Use. Partner. Only. Internal. Figure 24: Generating a Master IDoc. 2005/Q4. © 2006 SAP AG. All rights reserved.. 37.

(46) Unit 1: ALE Fundamentals. BIT300. Use. Partner. Only. Internal. Figure 25: Recipient Determination in the ALE Layer. SAP Use. Only. Internal. Partner. In order to be able to send the communications IDoc to the recipient, the sender system uses the outbound partner profile to determine the port (in other words, the communication channel) via which the IDoc is to reach the target system. Then the IDoc is converted into the format suitable for the port. This part of the program is also known as the communication layer.. SAP. Next in the program's run, the sender system checks the outbound partner profiles for the message type used. For each recipient, a communication IDoc is created according to the basic type and is saved to the database.. 38. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(47) BIT300. Lesson: Intermediate Documents. Use. Partner. Only. Internal. SAP. The ALE layer can pass a communications IDoc directly to the communication layer. However, for performance reasons, it is often better to first save the IDocs to the database and then to process them collectively later. The partner profile determines whether a communications IDoc is sent to the port immediately or not until later.. SAP. Use. Figure 26: Further Processing in the Communication Layer. Metaphorically speaking, the communications IDoc is like a letter that is to be sent to one or more recipients. The letter is copied and a copy is placed in an envelope for each recipient. The sender and recipient are noted on the envelope. Then it is placed in an out-tray whose contents are later put in a mailbox.. Partner Only. Internal. Two types of port are used for sending IDocs: tRFC ports and file ports.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 39.

(48) Unit 1: ALE Fundamentals. BIT300. SAP Use Internal. The IDoc is initially saved to the database in the recipient system.. Partner. Not every partner system is able to interpret the RFC protocol. In EDI scenarios involving a converter, a file port is often used, for this reason. The IDoc is stored for this file port as a sequential file at the operating system level in such a way that the target system can access it. A corresponding path in the file system is entered in the port.. SAP. The port type tRFC is short for “transactional Remote Function Call”. The technology of the transactional RFC ensures that the recipient receives the document once and once only. If the recipient cannot be reached at the time of sending, the system attempts to establish the connection again at regular intervals. The document is only deleted from the tRFC queue when it has reached the target system. In ALE scenarios, data transfer is via tRFC.. Use. Partner. Only. Internal. Figure 27: Port Types. Only. 40. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(49) BIT300. Lesson: Intermediate Documents. Use. Partner. Only. Internal. Figure 28: Inbound Processing in the Recipient System. SAP Use. Only. Internal. Partner. The ALE layer uses the partner profile to determine a transaction code that controls how the IDoc is processed further. Generally speaking, the data is transferred to the application by a function module. However, a workflow could also be started instead.. SAP. Depending on the defaults in the partner profiles, the IDoc is either transferred to the ALE layer immediately or not until later by a program for background processing.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 41.

(50) Unit 1: ALE Fundamentals. BIT300. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. 42. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(51) BIT300. Lesson: Intermediate Documents. Exercise 2: Documentation for Basic Types Exercise Objectives After completing this exercise, you will be able to: • Display documentation about basic types in mySAP ERP. Only SAP. From the application menu, display the documentation for the basic type MATMAS05.. 2.. Find segment type E1MARMM (Material master units of measure) and display the structure. Which segment type is dependent on E1MARMM?. 3.. Change your user settings so that, in future, the link to the documentation for individual segment fields is displayed next to the link to the structure of the corresponding segment type.. SAP. 1.. Use. You want to learn about the structure of the MATMAS05 basic type, so that you can use the “Central Material Master Management” ALE scenario.. Task:. Internal. You want to use ALE to exchange data between two SAP systems and, by doing so, find out more about the technical implementation of ALE scenarios.. Partner. Business Example. Only. Internal. Use. Partner. 2005/Q4. © 2006 SAP AG. All rights reserved.. 43.

(52) Unit 1: ALE Fundamentals. BIT300. Solution 2: Documentation for Basic Types Task: You want to learn about the structure of the MATMAS05 basic type, so that you can use the “Central Material Master Management” ALE scenario.. SAP Use. In the Basic type field, enter MATMAS05 and select HTML Format. .. Find segment type E1MARMM (Material master units of measure) and display the structure. Which segment type is dependent on E1MARMM? a). Segment type E1MARMM is dependent on segment type E1MARAM (Material master general data). Click on the Structure link below the status information about segment type E1MARMM to call a list of segment fields.. b). Segment type E1MARMM (Material master EAN code) is dependent on segment type E1MARMM.. Change your user settings so that, in future, the link to the documentation for individual segment fields is displayed next to the link to the structure of the corresponding segment type. a). Choose Back. b). In the transaction's menu, select Goto → User Settings, click on Display <-> Change , set the Documentation Output indicator and save your changes.. c). Check the changed setting by displaying the HTML display again: you can now access a Documentation link which you can use to call information about the individual segment fields.. to exit the HTML display.. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. Internal. b). Partner. 44. Select Tools → ALE → ALE Administration → Services → Documentation → IDoc Types and Segments.. SAP. 3.. a). Use. Partner. 2.. From the application menu, display the documentation for the basic type MATMAS05.. Internal. Only. 1..

(53) BIT300. Lesson: Intermediate Documents. Lesson Summary You should now be able to: • Explain and differentiate between the terms “basic type”, “master IDoc” and “communications IDoc” • Determine the details of basic types • Describe the process from the creation of an IDoc in the sender system through to processing in the target system. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. 2005/Q4. © 2006 SAP AG. All rights reserved.. 45.

(54) Unit 1: ALE Fundamentals. BIT300. Lesson: Synchronizing Customizing Lesson Overview Data exchange across system boundaries requires the basic configurations of the applications involved in the sending and target systems to be aligned with each other. This lesson deals with synchronizing Customizing for the purposes of ALE.. Only. After completing this lesson, you will be able to:. Consequences of Distributing Applications Across Two Systems. Previously, you modeled your business processes in one particular system. In the future, you want to outsource a subprocess to a second system. You want to be able to assess the consequences and give yourself an overview of the different methods for aligning the system configuration.. Use. Only. Internal. Partner. If all applications are integrated in one system, the programs access the same database. In this type of system, the consistency of the data is guaranteed because every item of logical information is stored in only one database table, and all programs retrieve data directly from the database. As soon as one application is separated from the rest of the applications by being installed in another system, the applications need to communicate via interfaces. The Customizing settings and master data must be consistent in all the communicating systems.. SAP. Business Example. Use. Partner. Describe methods for adjusting Customizing settings in SAP system landscapes. SAP. •. Internal. Lesson Objectives. 46. © 2006 SAP AG. All rights reserved.. 2005/Q4.

(55) BIT300. Lesson: Synchronizing Customizing. SAP Use Internal. 2005/Q4. © 2006 SAP AG. All rights reserved.. 47. Only. A business process often consists of multiple single steps. Within a business process, an agent can be responsible for more than one step. However, process steps can also be carried out by different agents. Applications in SAP can be affected by more than one partial solution. Once a process step has been processed, the newly created or changed data is saved to the database. The agent for the next process step needs to be informed, and the data required for executing the next step needs to be transferred.. Partner. Business Process in One System. SAP. In ALE scenarios, IDocs are used to exchange application data between the systems involved in a process. This exchange can only work if an IDoc contains only field values that are also defined in the target system, unless these are fields for which unrestricted data entry is planned. However, in most of the fields in the master data and documents for SAP applications, only the field values pre-defined in Customizing are allowed. This means that, before you distribute the data, you need to make sure that these catalogs of values match in both the sending and target systems. If you cannot (or do not wish to) match the systems, deviating field values need to be replaced by values from the target system during further processing of either the outbound or the inbound IDoc.. Use. Partner. Only. Internal. Figure 29: Distributing Applications Across Two Systems.

(56) Unit 1: ALE Fundamentals. BIT300. Use. Partner. Only. Internal. Figure 30: Business Process in One System: Example. SAP Use Internal. 48. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. If a business process extends across not only various subsolutions but also across different systems, then specific data needs to be forwarded to the next agent. In ALE scenarios, an IDoc functions as a “container” for this data.. Partner. Business Processes in Multiple Systems. SAP. The example shown above illustrates a sales order being processed in an SAP R/3 or SAP ECC system. Agent 1, a sales employee, records the customer's order in the system. The system (agent 2) automatically creates the shipment for this sales order. A further employee (agent 3) creates a transfer order so that the product that is to be shipped is removed from storage. Once the product has been removed from storage, the system (agent 2) posts the goods issue so that the sales employee (agent 1) can end the process by creating the billing document, in other words, the invoice for the customer. This process therefore involves not only various agents but also various subsolutions (sales, delivery processing, warehouse management and inventory management)..

(57) BIT300. Lesson: Synchronizing Customizing. Use. Partner. Only. Internal. Figure 31: Business Processes in Two Systems: Example. SAP Use. In addition to distributing master data and transaction data, you can also use ALE to align the Customizing settings between systems (in preparation for distributing master and transaction data). Message type CONDA2 is available in the SAP R/3 and SAP ECC systems for this purpose (ALE: Synchronization of Customizing Data). The core of this function is an automatic alignment of selected Customizing objects in two SAP systems: this alignment generates transport requests for all the changes. Note: In systems released before SAP R/3 4.6A, use message type CONDAT instead.. 2005/Q4. © 2006 SAP AG. All rights reserved.. 49. Only. Internal. Synchronizing Customizing Settings with ALE. Partner. Note: This is a simplified representation of the “Decentralized Warehouse Management System” ALE scenario.. SAP. The figure illustrates the same process as the last one. The difference to the first example is that warehouse management is outsourced to a second SAP system. The shipment data from the first system is transferred to the second system in an IDoc. There, it is processed further in the stock removal step. After this procedure has been completed, the warehouse management system creates a second IDoc with all the data necessary for continuing the shipment process in the first system..

(58) Unit 1: ALE Fundamentals. BIT300. Note: You can distribute all client-dependent Customizing objects of category CUST. Each object can be assigned to one distribution group, and one only.. Partner SAP Use Internal. 50. © 2006 SAP AG. All rights reserved.. 2005/Q4. Only. As an alternative to distributing Customizing settings with ALE as described in the previous section, you can use the SAP Solution Manager: this is an extensive set of instruments for configuring and operating SAP solutions. The SAP Solution Manager includes two components for synchronizing Customizing settings between SAP systems: the Customizing Scout and Customizing distribution. The Customizing Scout compares the configurations of multiple SAP systems and displays the differences. The comparison can – as in ALE – be carried out interactively or in the background, and periodically, if required. After the settings have been matched,. Partner. Synchronizing Customizing Settings with the SAP Solution Manager. SAP. Note: The ALE transport request can be consolidated by a dedicated transaction (BDXL) with transport requests for exporting the changes to the quality assurance and production systems.. Use. All the Customizing settings you need for cross-system Customizing comparison and subsequent synchronization can be found with transaction SALE. In the menu, select IDoc Interface/Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Synchronization of Customizing Data. You can call the relevant application transactions in SAP Easy Access via Tools → ALE → ALE Administration → Services → Customizing Data. Here you will find a program for matching Customizing tables in the sending and target systems, known as the “Customizing Cross-System Viewer” (transaction SCU0), and transaction for generating and further processing ALE transport requests for Customizing synchronization. The sending system creates IDocs of message type CONDA2 for the transport requests: these IDocs contain the core information about each request. Inbound processing of these IDocs controls the importing of request data in the target system: either a workflow is sent to the responsible administrator requesting him or her to carry out the import, or the import is carried out automatically by a program executed in the background.. Internal. Only. To optimize the use of ALE for Customizing synchronization, one logical system in the system landscape is identified as the central Customizing system. Changes to certain Customizing tables are made in this system only. You can determine exactly which objects should only be changed in the context of ALE distribution. You group together these objects, known as ALE Customizing objects, into distribution groups, which are automatically assigned to the logical maintenance system. You then need to distribute these distribution groups to the target systems. It is now no longer possible (or only partly possible, depending on the particular configuration) to carry out any changes in the target system to the objects contained in the distribution groups..

(59) BIT300. Lesson: Synchronizing Customizing. the Customizing distribution instrument can create transport requests for each changed Customizing object in the maintenance system and distribute the requests automatically to the downstream systems. It is, however, also possible to distribute manually. Certain Customizing objects are predefined in the SAP Solution Manager as synchronization objects.. Converting Field Values: Cross-System Company Codes. © 2006 SAP AG. All rights reserved.. 51. Only Partner SAP Use Internal. Only. 2005/Q4. Partner. Note: The configuration of field conversion is one of the topics covered in the BIT350 training course (ALE Enhancements).. SAP. There are only a few cases where you can convert field values directly using Customizing tables before the IDoc is sent or before IDoc inbound processing. For all other field values that need to be replaced by other values, you can use the Field Conversion tool. This allows either the sending or the target system to change the content of IDoc segment fields during runtime of the application program in question. Field conversion is based on rules and allows for a more differentiated data changing procedure than that provided by exchanging values on the basis of Customizing table entries.. Use. Caution: You need to define and assign at least one cross-system company code in the sending and target systems, even if the company code keys are identical. If this setting is missing, IDoc processing fails. The outbound IDoc receives status 29 (Error in ALE Service) and the inbound IDoc receives the corresponding status 65.. Internal. It is not always either possible or desirable to standardize Customizing in a system landscape. If, for example, a logical system represents an enterprise's subsidiary, then the keys for the organizational units will normally differ, at least in part. The subsidiary will be assigned to a different company code than the parent company. For this reason, you use what are known as cross-system company codes in ALE scenarios. These are freely-definable keys that are each assigned to one “genuine” company code, in other words, a company code used in the application. When creating a communications IDoc containing the field Company Code in one of its segments, the sending system replaces the company code key from the application (such as a customer master that is to be distributed) with the key for the assigned cross-system company code. The target system carries out the same operation in reverse: it replaces the cross-system company code with the “genuine” company code, in order to create or change the customer master. You can find the tables for defining cross-system company codes and linking them to the company codes used in the applications under transaction SALE, via IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Global Organizational Units → Cross-System Company Codes. You need to carry out similar settings for the business areas..

(60) Unit 1: ALE Fundamentals. BIT300. Lesson Summary You should now be able to: • Describe methods for adjusting Customizing settings in SAP system landscapes. Use. Partner. Only. Internal. SAP. SAP Only. Internal. Use. Partner. 52. © 2006 SAP AG. All rights reserved.. 2005/Q4.

References

Related documents