sap netweaver process integration

BIT100Integration TechnologySAP NetWeaver Process Integration

Date Training Center Instructors Education Website

Participant HandbookCourse Version: 2005 Q4 Course Duration: 3 Day(s) Material Number: 50075532

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

CopyrightCopyright 2005 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. Additionally this publication and its contents are provided solely for your use, this publication and its contents may not be rented, transferred or sold without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Trademarks Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation. ORACLE is a registered trademark of ORACLE Corporation. INFORMIX-OnLine for SAP and INFORMIX Dynamic ServerTM are registered trademarks of Informix Software Incorporated. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

DisclaimerTHESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.

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

Typographic ConventionsAmerican English is the standard used in this handbook. The following typographic conventions are also used. Type Style Example text Description Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet). Example text EXAMPLE TEXT Emphasized words or phrases in body text, titles of graphics, and tables Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE. Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program. Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

Example text

Example text

2005/Q4

2005 SAP AG. All rights reserved.

iii

About This Handbook

BIT100

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

iv


2005/Q4

ContentsCourse Overview ......................................................... viiCourse Goals ...........................................................vii Course Objectives .....................................................vii

Unit 1: Analysis of Business Processes ............................. 1Introduction to Business Processes ..................................2 SAP Tools for Representing Business Processes ................ 15

Unit 2: Analysis of the System Landscape ........................ 27Structured Storage of System Landscape Data .................. 28

Unit 3: Integration Strategies ......................................... 41Integration Strategies................................................. 42

Unit 4: SAP Interface Technologies ................................. 51Integration Technology - RFC ....................................... 52 Communicating Using BAPIs........................................ 70 IDoc and ALE.......................................................... 80

Unit 5: Support of Standard Interface Technologies ............ 95HTTP Basics........................................................... 96 XML Basics ...........................................................104 Internet Communication Manager ................................. 119 Web Services.........................................................126 SOAP Basics .........................................................136

Unit 6: SAP Connectors ............................................... 149An Overview of Connectors ........................................150 SAP Business Connector ...........................................160 Connectors and Interface Programming ..........................168

Unit 7: SAP NetWeaver Exchange Infrastructure................ 181Components of SAP NetWeaver XI ...............................183 XI Connectivity .......................................................198 Business Process Management in SAP NetWeaver XI.........206

Unit 8: Application Example.......................................... 217Incoming Sales Orders ..............................................218

2005/Q4


v

Contents

BIT100

Glossary................................................................... 229 Index ....................................................................... 231

vi


2005/Q4

Course OverviewThis course introduces the topic of process integration for SAP systems. It provides an overview of SAP integration technologies, tools and solutions for system-to-system coupling based on SAP and standard technologies, protocols, and formats.

Target AudienceThis course is intended for the following audiences: Technical project managers Technology consultants System architecture managers who are responsible for integration issues

Course PrerequisitesRequired Knowledge Basic knowledge of SAP NetWeaver

Recommended Knowledge Basic knowledge of integration technologies

Course GoalsThis course will prepare you to: Describe the basics of integration technologies

Course ObjectivesAfter completing this course, you will be able to: Determine which integration technologies are most suitable for an integration scenario Describe which integration technology is used in a standard SAP integration scenario

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

2005/Q4


vii

Course Overview

BIT100

viii


2005/Q4

Unit 1Analysis of Business ProcessesUnit OverviewThis unit defines some of the basic terms relating to business processes. It also explains which aspects of business processes you need to clarify before you can begin with the technical integration.

Unit ObjectivesAfter completing this unit, you will be able to: Explain the terms business scenario, business process, and business process step List the important objects in cross-system processes Locate the scenario and process descriptions created by SAP Describe the options for cross-system control of scenarios and processes Describe the options for controlling scenarios and processes in a system component List the tools for describing and structuring scenarios and processes Define the term process modeling

Unit ContentsLesson: Introduction to Business Processes...................................2 Lesson: SAP Tools for Representing Business Processes................. 15

2005/Q4


1

Unit 1: Analysis of Business Processes

BIT100

Lesson: Introduction to Business ProcessesLesson OverviewThis lesson introduces you to the fundamental terminology of process and integration management. It also shows how the interaction of business and technical definitions is an important prerequisite for the successful realization of cross-system and integrated business processes. Furthermore, this lesson shows you how to map terminology used in the SAP world to the terminology used by SAP customers. This lesson provides you with a common understanding of the problems to be resolved.

Lesson ObjectivesAfter completing this lesson, you will be able to: Explain the terms business scenario, business process, and business process step List the important objects in cross-system processes Locate the scenario and process descriptions created by SAP Describe the options for cross-system control of scenarios and processes Describe the options for controlling scenarios and processes in a system component

Business ExampleNowadays, all businesses need to integrate scenarios and processes across multiple applications. One reason for doing this would be to consolidate data from the different accounting systems of subsidiaries of a multinational company for reporting at company level. It must be possible to adapt this integration scenario on a business level so that different reporting standards can be used as applicable (for example, US-GAAP = Generally Accepted Accounting Principles, IAS = International Accounting Standards, IFRS = International Financial Reporting Standards). At the same time, on a technical level, a central service or central integration product needs to be used to integrate the multinational company's applications.

Scenarios and Processes in GeneralScenarios and processes reflect how all types of company activities are organized and executed. These company activities are executed according to a defined sequence as process steps. Questions of responsibility, overall clarity, performance, and added value play an important role in modeling and structuring scenarios, processes, and process steps. Aspects related to the technical implementation and questions about the integration are as important as

2


2005/Q4

BIT100

Lesson: Introduction to Business Processes

the business aspects already mentioned. However, if you initially separate both perspectives, it is easier to transfer and realize the company process with different business applications and technologies.

Figure 1: Process Integration Requirements

To get some initial indicators of points of integration between business processes, it is helpful to define strategic, operative, and supporting processes.

Figure 2: Process Management Views

You generally need to address the following topics in a discussion about processes:

2005/Q4


3


BIT100

Process Architecture Design Actual analysis of the company landscape Value chains, organizational charts, function assignments Scenarios, processes, process steps Software components Inter-application customizing Process integration Cross-system processes Inter-application processes Inclusion of end user Transparency, documentation Standardization, optimization

Consultation Between IT and Other Departments

Process Automation

Process Control

Scenarios and Processes from a Business PerspectiveBefore the task of describing and representing scenarios and processes can begin, the actual meaning of these terms needs to be discussed. Many different criteria can be used to subdivide company activities. However, initially, a neutral system for naming scenarios and processes is required; this naming system should not just apply to specific company areas or other attributes. Only when the terminology is clearly defined can you create a unique and concise structure of all company activities. The definition of the terms can vary from company to company. The SAP definitions of the relevant terms are listed in the following text:

Business ScenarioDefinition: business scenario

4


2005/Q4

BIT100


A series of business processes that describe a business task at a high level in a comprehensive and enclosed way. A business scenario usually refers to a company entity or a central function and may involve business partners and other companies. One or more SAP components or non-SAP components are required to execute a business scenario. A business scenario can comprise any number of variants. Each variant describes one end-to-end business case. Each end-to-end business case is represented by an ordered sequence of business processes.

Figure 3: Business Scenario Comprising Three Processes

The above figure shows a scenario that consists of three processes: sales order processing, production, and billing. The integrated flow of the process must be defined from a business perspective, and enabled by interfaces from a technical perspective.

Business ProcessDefinition: business process A set of logically related tasks performed to achieve a defined business outcome (Davenport & Short, 1990). A business process consists of multiple process steps. A business process can be executed across multiple SAP or non-SAP components. A business process can be used in one or more business scenarios.

2005/Q4


5


BIT100

Figure 4: Business Process with Process Steps

The process outlined in the figure includes three process steps. These process steps are executed in business applications. The figure does not specify whether the process steps are executed in one or more business applications, or whether these business applications are installed in one or more systems. However, when realizing an integrated business process, this information is crucial for the definition of the interfaces. Business applications usually consist of two kinds of software components: Software components with business functions, for example, SAP_APPL Software components with technical functions, for example, SAP_BASIS or SAP_ABA

The business software components are installed on technical software components. Technical software components have the task of establishing connections to the operating system and to the database, and enabling communication with other technical software components.

Business Process StepDefinition: business process step

6


2005/Q4

BIT100


An elementary activity that is executed to complete a business process. Process steps are executed by user interaction or by a system. Process steps are executed in only one software component. Process steps are relevant from an implementation or operations perspective, or both. Note that process steps represent transactions in many cases. Hint: Important definition criteria from a business perspective Representation of processes down to process-step level Process steps and required business functions Description of functional dependencies on other processes or process steps Definition of whether process steps are processed in parallel or sequentially Appointment of persons responsible for processes Description of the requirement with reference to availability and process throughput Description of content for process implementation and configuration Description of procedure for testing processes

Figure 5: Process Example: Sales Process

Scenarios and Processes from a Technical PerspectiveFrom a technical perspective, company activities, that is, process steps, need to be assigned to business applications. Business applications consist of software components. Usually, processes involve a series of such business applications,

2005/Q4


7


BIT100

which results in the need to create integrated system environments. This in turn requires integration management to guarantee a flexible, safe, and integrated system landscape that, where possible, is based on universally valid standards. The following figure illustrates the complexity of cross-system integrated processes.

Figure 6: Processes in Integrated Systems

The above figure highlights the need to define the interfaces at process-step level. The following figure shows external process interfaces. At these interfaces, information is transferred to the process, or taken from the process to be transferred to other processes. For processing the process steps, you need to define any dependencies regarding the processing sequence, that is, whether processing is to be executed in serial or in parallel. This is important because you need to be sure that the communication methods provided by the technical software components enable a corresponding flow of information.

8


2005/Q4

BIT100


Figure 7: Process Steps and Interfaces

Refer to the following figure, Process Steps in Software Components. The distribution of the business and technical software components also influences the structure of the interfaces. The functions for executing process step 1 and process step 3 are implemented in software component 1 (application with business functions). The interface between the functions is provided by the application. It does not need to be taken into account when creating an integrated process. The function for executing process step 2 is implemented in software component 2. There is an interface between process step 1 and process step 2. How this interface must be realized depends on how the business software components are installed on technical software components.

2005/Q4


9


BIT100

Figure 8: Process Steps in Software Components

It is also important to know on which technical software components the business software components will be installed. In the following figure, Software Components in a Technical System, both business software components are installed on one server (technical software component). There is one external inbound interface. There are also internal interfaces between the process steps. However, in this case because both business software components are installed on a single technical software component, these interfaces are not relevant for SAP customers when realizing an integrated process. The semantic description of the interface is provided by the business software component, that is, a document is provided in a particular format. Based on a communication protocol, this document can then be transferred in a communication layer by using the technical software component. The document can be transferred by remote function call (RFC), file, or HTTP in the communication layer.

10


2005/Q4

BIT100


Figure 9: Software Components in a Technical System

The following figure, Software Components in Multiple Technical Systems, shows another way that software components can be installed and how they can influence the interfaces. In this case, both business software components are installed on two servers (technical software components). There is one external inbound interface. There are also external interfaces for the internal interfaces between the process steps. In this example, how the interfaces can be realized and which communication options are available depend on whether the technical software components are identical or not. When, as in this case, business software components are installed on multiple technical software components, customers must design their interfaces specifically.

2005/Q4


11


BIT100

Figure 10: Software Components in Multiple Technical Systems

Hint: Important definition criteria from a technical perspective Assign process steps to business applications and software components Assign transactions and programs to process steps Define whether business applications are coupled synchronously or asynchronously Describe methods for exchanging messages, master data, and transaction data between business applications Rename and describe the data to be exchanged using the interfaces, as well as the structures and formats of the data Describe system-related process automation mechanisms (Workflow) Describe cross-system process control mechanisms (ccBPM) Describe requirements regarding traceability and monitoring of data flow across the interfaces

Detailed Analysis of Technical Objects in Cross-System ProcessesIn an integrated solution, usually multiple cross-system processes are implemented, each of which are handled separately. Certain objects must be defined to describe the details of semantic and technical integration. These objects include interfaces, mappings, and the software components that make up the business applications. They also include actions. Actions are functions of a software component that cannot be subdivided further; together they represent

12


2005/Q4

BIT100


the process flow of a cross-system process. Semantic integration is usually provided by APIs (Application Programming Interfaces) in the business software components. Technical integration is usually configured depending on the installed technical software components. (The remaining units in this course contain more details on this subject.) The platform for representing these objects at SAP is SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI).

Figure 11: Cross-System Processes in SAP NetWeaver XI

By using the interface description language WSCI (Web Service Choreography Interface) to describe cross-system processes, you can enable a standardized exchange of scenarios.

2005/Q4


13


BIT100

Lesson SummaryYou should now be able to: Explain the terms business scenario, business process, and business process step List the important objects in cross-system processes Locate the scenario and process descriptions created by SAP Describe the options for cross-system control of scenarios and processes Describe the options for controlling scenarios and processes in a system component

14


2005/Q4

BIT100

Lesson: SAP Tools for Representing Business Processes

Lesson: SAP Tools for Representing Business ProcessesLesson OverviewTo be able to represent scenarios and processes, you need to describe details at different levels. This lesson introduces the tools used by SAP to do so.

Lesson ObjectivesAfter completing this lesson, you will be able to: List the tools for describing and structuring scenarios and processes Define the term process modeling

Business ExampleYou are implementing a new company business process and need to describe the process from a business and a technical perspective. Furthermore, you need to define how the new process is to be integrated in the existing process landscape.

Scenario and Process Modeling LevelsSAP has developed a series of tools to help you visualize, describe in detail, and implement integrated scenarios and processes. These tools are designed for processing various tasks. The following figure shows all the different tasks. The three levels show how the amount of detail for the description and implementation of processes varies.

2005/Q4


15


BIT100

Figure 12: Levels of Process Modelling

Hint: The tools used by SAP for describing scenarios and processes are: SAP Solution Composer SAP Solution Manager SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) ARIS for NetWeaver (in cooperation with IDS Scheer)

SAP Solution ComposerSAP Solution Composer is a PC tool that enables SAP customers to easily document scenarios and processes at a high level. You use SAP Solution Composer to create SAP Business Maps, such as the following: Solution Maps Business Scenario Maps

Business maps help you to visualize the value chain of a company, define scenario and process requirements, and describe the potential of integrated processes. In this way, you can document the integration between people, data, and processes, regardless of whether the processes are company-internal or whether they extend beyond company boundaries. For more information about SAP Solution Composer and to download the software, see http://service.sap.com/s-composer.

16


2005/Q4

BIT100


Figure 13: SAP Solution Composer Business Maps Overview

Solution MapsAn SAP solution map is a software tool used to analyze and visualize scenarios and processes from SAP solutions. Solution maps help you to document the essential scenarios, processes, and functions, which in turn help to increase competitiveness and market orientation. Customers can create their own solutions maps with SAP Solution Composer. SAP Solution Composer contains two different types of solution maps: Cross-industry and industry-specific solution maps Generic solution maps

2005/Q4


17


BIT100

Figure 14: Industry Solution Map Automotive OEM Part 1 of 2

Figure 15: Industry Solution Map Automotive OEM Part 2 of 2

For more information about solution maps, see http://service.sap.com/solutionmaps or http://service.sap.com/businessmaps.

Business Scenario MapsBusiness scenario maps provide a detailed graphical representation of the end-to-end processes of companies that are active in just one specific industry or across multiple industries. These maps are used to represent collaborative processes and to simplify their implementation, and to describe the potential of collaborative scenarios. To be more precise, business scenario maps provide

18


2005/Q4

BIT100


different views on activities, roles, interfaces, and even business documents of scenarios. By providing different views of a business scenario, it is easier to discuss the details of the scenario.

Figure 16: Business Scenario Map Invoicing (Electronic)

SAP Solution ManagerSAP Solution Manager supports you throughout the lifecycle of your solutions, from the definition of your integrated business processes during the business blueprint phase to configuration and productive operation. One of the main reasons for using SAP Solution Manager is to be able to document the know-how for implementing and configuring integrated business processes. SAP Solution Manager provides central access to tools, methods, and preconfigured content, which you can use during evaluation and implementation, as well as the productive operation of your systems. The Business Process Repository contains scenarios and processes that can be represented with SAP solutions. SAP Solution Manager is usually installed at the customer site and connected with their business applications. This creates an integrated infrastructure that has significant advantages when designing, implementing, and operating integrated business processes. SAP Solution Manager must be used to implement SAP ERP 2004.

2005/Q4


19


BIT100

Figure 17: SAP Solution Manager - Overview of Functions

For more information about SAP Solution Manager, see http://service.sap.com/solutionmanager.

Business Process Repository in SAP Solution ManagerThe Business Process Repository is part of SAP Solution Manager. It contains the implementation content for SAP solutions, which is continually updated by SAP. This content forms the basis for the definition of customer-specific scenarios and processes. You install the implementation content by using the ST-ICO Add-On in your SAP Solution Manager. You can download ST-ICO from SAP Service Marketplace at service.sap.com/swdc Downloads Installations and Upgrades Entry by Application Group SAP Technology Components SAP SOLUTION MANAGER Content ST-ICO. Select the number for the current content.

20


2005/Q4

BIT100


Figure 18: Business Process Repository in SAP Solution Manager

Component View in SAP Solution ManagerBy describing the system landscape components in SAP Solution Manager, it is possible to assign process steps to system components. The resulting view is known as the component view. In the component view, processes are displayed graphically for a specific component and for multiple components. This provides a clear overview of the points of integration between components and processes. You must describe the exact definition of the points of integration in the project documentation in SAP Solution Manager.

2005/Q4


21


BIT100

Figure 19: Component View in SAP Solution Manager

Processes and Important AssignmentsSAP Solution Manager enables you to assign all kinds of information directly at process and process-step level. The person responsible for the process must define at which level this should take place. The following are examples of important pieces of information: Detailed process descriptions Transaction assignments Assignment of configuration tables (IMG structures) Interface descriptions Test procedure descriptions ...

22


2005/Q4

BIT100


Figure 20: Process Details and Assignments

2005/Q4


23


BIT100

Lesson SummaryYou should now be able to: List the tools for describing and structuring scenarios and processes Define the term process modeling

24


2005/Q4

BIT100

Unit Summary

Unit SummaryYou should now be able to: Explain the terms business scenario, business process, and business process step List the important objects in cross-system processes Locate the scenario and process descriptions created by SAP Describe the options for cross-system control of scenarios and processes Describe the options for controlling scenarios and processes in a system component List the tools for describing and structuring scenarios and processes Define the term process modeling

2005/Q4


25

Unit Summary

BIT100

26


2005/Q4

Unit 2Analysis of the System LandscapeUnit OverviewThis unit outlines which aspects of your system landscape you need to analyze to develop a successful integration strategy.

Unit ObjectivesAfter completing this unit, you will be able to: Explain the need for a central directory for storing system landscape data List the central objects of the System Landscape Directory from a hardware and software perspective Describe the fundamental communication mechanisms between technical software components

Unit ContentsLesson: Structured Storage of System Landscape Data ................... 28 Exercise 1: System Landscape Directory ................................ 35

2005/Q4


27

Unit 2: Analysis of the System Landscape

BIT100

Lesson: Structured Storage of System Landscape DataLesson OverviewThis lesson explains how you can store and query system landscape data in a structured way. SAP developed the System Landscape Directory (SLD) for storing system and software component information centrally. This information is important for realizing cross-system processes.

Lesson ObjectivesAfter completing this lesson, you will be able to: Explain the need for a central directory for storing system landscape data List the central objects of the System Landscape Directory from a hardware and software perspective Describe the fundamental communication mechanisms between technical software components

Business ExampleWhen designing integration scenarios, it is essential that you have access to information about company applications and their product versions, operating systems, and databases. Companies often request that such information be structured and made available in a central location.

Hardware and Software ComponentsSAP has developed a central directory for storing application component information and system landscape data. This directory is installed as an SAP software component (SAP_JTECHST) on an SAP NetWeaver Application Server (SAP NetWeaver AS). The System Landscape Directory (SLD) is a J2EE application. It uses the Common Information Model (CIM) of the Distributed Management Task Force, Inc. (www.dmtf.org) and implements its standard Web-Based Enterprise Management (WBEM) for client server communication. As the central data storage for system landscape information, the SLD server enables

28


2005/Q4

BIT100

Lesson: Structured Storage of System Landscape Data

system management applications to access the data they require. Usually, only one SLD is required per system landscape. The data in the SLD can be divided into two categories, component information and system landscape description: Component information includes information about all the available SAP software modules (for example, products, software components, releases, support packages) and about all the possible combinations of software modules and their interdependencies (operating system versions, databases, and so on). Component information is provided by SAP and can be updated by customers as required by downloading the relevant files from SAP Service Marketplace at service.sap.com (see SAP Note 669669). Customers can also enter components from external providers in their SLD. Example: SAP Basis 6.20 is a software component. It is registered in the component information as a CIM instance of the class SAP_SoftwareComponent. This entry contains important information about the component (for example, date of implementation, date when support ends). In addition, all existing support packages are registered for the component and associated with the component. System landscape description describes the individual system landscape (for example, network addresses) that is installed at a customer site. Together with the component information, the description of the components actually installed provides reliable and up-to-date data for the system management applications. A data supplier, which is configured in the relevant system, is available for SAP systems and SAP NetWeaver AS. Data suppliers provide the SLD with up-to-date system data at regular intervals. Example: An application system runs on an SAP Web Application Server (SAP Web AS) 6.20. This installed software component has an entry in the system landscape description as an instance of the CIM class SAP_InstalledSoftwareComponent. Using a relationship of type SAP_SoftwareComponentType, the instance establishes a connection to the counterpart in the component information, namely, the instance for the CIM class SAP_SoftwareComponent. In this way, the instance has access to all the relevant information from the component information.

2005/Q4


29


BIT100

Figure 21: System Landscape Directory

Furthermore, the SLD server is used as the name server for the SAP Java development infrastructure. The name server guarantees that local and global names of development objects are unique. Customers can either run the name server together with the SLD server in one software instance, or run both servers separately on different hardware servers.

Communication and Transport ProtocolsFor two systems to be able to communicate you require a transport protocol. The idea is that communication with another system is encapsulated in an interface and the parameters of this interface are transferred in a message. This means that SAP NetWeaver XI always requires two interfaces for communication: one at the sender and one at the receiver. The advantage of this over point-to-point connections is that the sender and receiver interfaces do not have to be identical (loose coupling).

30


2005/Q4

BIT100


Figure 22: Communication Protocols

Up to SAP Web AS 6.20, SAP server technology supported, in addition to file protocols, its own protocol, Remote Function Call (RFC), which was based on TCP/IP. As the name suggests, this communication method enabled an ABAP function module to be called remotely. Data exchange using IDocs and BAPIs, and in application link enabling (ALE) scenarios is based on the RFC protocol, and is not required if you use SAP NetWeaver XI. Outside the SAP world, HTTP is the most popular communication protocol. For this reason, direct connections using HTTP are supported in SAP Web AS 6.20 and higher. Which communication protocols can be used? CPI-C (Common Programming Interface-Communication). Standardized interface for cross-system communication between programs. TCP/IP (Transmission Control Protocol/Internet Protocol). Software protocol that enables computers to communicate. Remote Function Call (RFC) is the SAP standard interface used for communication and is based on CPI-C or TCP/IP. CPI-C services in the SAP world that are based on TCP/IP are realized by using SAP Gateway. This enables connections to SAP systems and external programs to be established. Multiple versions of this protocol exist. Synchronous RFC (sRFC) executes the function call on the basis of synchronous communication, that is, both involved systems must be accessible at the time of the call. Transactional RFC (tRFC) is an asynchronous means of communication that executes the called program exactly once in the target system (the RFC server). The remote system in which the RFC client program executes a tRFC does not need to be available in this case. The tRFC component saves the called RFC function together with the corresponding data in the SAP database in a unique transaction ID. If a call is made while the target system is not available, the call remains in a local queue. The caller dialog program can continue without having to wait for confirmation of whether the program was executed successfully or not. If the receiver system is not activated within a specified period, the call is scheduled as a background job. To guarantee

2005/Q4


31


BIT100

a sequence of multiple integration steps specified by the application, you can serialize the tRFC by using (inbound or outbound) queues. This RFC type is known as queued RFC (qRFC) and is an enhancement of tRFC. Another RFC version is fast RFC (fRFC). The difference here is that fRFC uses a shared memory pipeline instead of SAP Gateway for communication. fRFC is usually only used by SAP for internal communication between ABAP and Java in SAP NetWeaver AS. SOAP (Simple Object Access Protocol) is the standard protocol used for exchanging XML-based data. SOAP is used, among other things, to execute Web services. For an up-to-date definition of the standard, visit www.W3org. HTTP (Hypertext Transfer Protocol) is the application protocol for the World Wide Web. It controls communication between the Web browser and the Web server. You can encrypt communication between the client and the server by using HTTP(S).

Data ContainersData is always transferred in a data container. At least one document format is available for each communication technology. Therefore, you use HTTP protocol to transfer XML documents, and RFC protocol to transfer IDocs. Which communication protocols and which document formats are supported in each case depends on the server. The exact definition is then implemented in the application. The exact structure of the contents is defined in the application. This is usually done using a tree structure in which you define precisely which fields are transferred at which points in the document. You also define the exact semantics of each field and the cardinality. The target system can execute inbound processing only if it recognizes this metadata. Certain communication technologies transfer only pure data and do not include this metadata. For XML documents, only a subset of the metadata is transferred.

32


2005/Q4

BIT100


Figure 23: Metadata for the Document

2005/Q4


33


BIT100

34


2005/Q4

BIT100


Exercise 1: System Landscape DirectoryExercise ObjectivesAfter completing this exercise, you will be able to: Find information about SAP products and software components in the SLD

Business ExampleAs part of a discussion about cross-system processes, you want to find out which products, software components, and software component versions are installed in your system landscape. You are particularly interested in information about the recently installed product, SAP ECC (Enterprise Central Component).

Task 1: Component Information in the System Landscape DirectoryCheck the component information in the System Landscape Directory (SLD). 1. 2. Log on to the SLD. Use your user BIT100-## and your password. Is the product SAP ECC in the SLD? Which product versions are listed? How many are there in total? Which software components belong to product version 5.0? Choose Software Catalog from the SLD initial screen. What is the name of the system and the host on which the product SAP ECC 5.0 is installed? Compare the names from the SLD with the information in the SAP ECC system under System Status.

3.

Task 2: Information About Technical SystemsWhat is the name of the technical system on which the product SAP ECC 5.0 is installed? 1. 2. 3. Click the relevant system name in the overview of the software catalog to display an overview of the technical systems. What is the installation number of the SAP Web AS? How many clients does the SAP Web AS have? Which products are installed on the SAP Web AS? Which software component versions and which support packages are installed on the technical system?

2005/Q4


35


BIT100

Solution 1: System Landscape DirectoryTask 1: Component Information in the System Landscape DirectoryCheck the component information in the System Landscape Directory (SLD). 1. Log on to the SLD. Use your user BIT100-## and your password. a) Log on to the Integration Server (ABAP). Choose Exchange Infrastructure Start Integration Builder or call transaction SXMB_IFR. Choose System Landscape Directory from the Integration Builder initial screen, and log on to the SLD using your user and password.

2.

Is the product SAP ECC in the SLD? Which product versions are listed? How many are there in total? Which software components belong to product version 5.0? Choose Software Catalog from the SLD initial screen. a) Navigate to the initial screen of the System Landscape Directory. Choose Software Catalog. Search for the product SAP ECC. There is only one product version, namely, 5.0. Choose 5.0. A list of the software component versions that product SAP ECC 5.0 contains is displayed.

3.

What is the name of the system and the host on which the product SAP ECC 5.0 is installed? Compare the names from the SLD with the information in the SAP ECC system under System Status. Answer: Switch to the Installed Systems tab page where the system and host names for the installed product SAP ECC 5.0 are displayed.

Task 2: Information About Technical SystemsWhat is the name of the technical system on which the product SAP ECC 5.0 is installed? 1. Click the relevant system name in the overview of the software catalog to display an overview of the technical systems. a) 2. Click the relevant system name to navigate to an overview of the technical systems. SAP Web AS is entered as the technical system.

What is the installation number of the SAP Web AS? How many clients does the SAP Web AS have? Which products are installed on the SAP Web AS? a) You find all the details about the technical system in the technical system browser. If not all the required information is available, scroll down further. Continued on next page

36


2005/Q4

BIT100


3.

Which software component versions and which support packages are installed on the technical system? a) The technical system browser has a screen area named Installed Products. Choose Installed Software Components to display an overview of the software components and support packages installed on the technical system.

2005/Q4


37


BIT100

Lesson SummaryYou should now be able to: Explain the need for a central directory for storing system landscape data List the central objects of the System Landscape Directory from a hardware and software perspective Describe the fundamental communication mechanisms between technical software components

38


2005/Q4

BIT100

Unit Summary

Unit SummaryYou should now be able to: Explain the need for a central directory for storing system landscape data List the central objects of the System Landscape Directory from a hardware and software perspective Describe the fundamental communication mechanisms between technical software components

2005/Q4


39

Unit Summary

BIT100

40


2005/Q4

Unit 3Integration StrategiesUnit OverviewThis unit outlines how you can analyze the interface technologies used.

Unit ObjectivesAfter completing this unit, you will be able to: Describe which aspects you need to take into account when developing an integration strategy

Unit ContentsLesson: Integration Strategies ................................................. 42

2005/Q4


41

Unit 3: Integration Strategies

BIT100

Lesson: Integration StrategiesLesson Overview Lesson ObjectivesAfter completing this lesson, you will be able to: Describe which aspects you need to take into account when developing an integration strategy

Business Example Analyzing the System Prerequisites: Master Data and CustomizingYou must clarify the following points before you can begin developing an integration strategy: Which business processes are to be represented in the system landscape and how exactly are they defined? Ideally, all your business processes will have been modeled down to process-step level. What does the system landscape look like? Which software components are installed or deployed on which systems? Are the customizing settings in the various different systems intercompatible? In which systems is which master data maintained? Which master data needs to be replicated in other systems? Between which process steps does a system switch occur? Which external interfaces are required? Which inbound or outbound interfaces do the software components contain?

To determine whether the signatures for an interface are sufficient or not, you must find out which master data is available in which system and what information about customizing settings is available. For an external interface in a business process, all the data that is required for the subsequent process steps and all data that is not known in the subsequent systems must be transferred.

42


2005/Q4

BIT100

Lesson: Integration Strategies

Interface Properties: Asynchronous or Synchronous?

Figure 24: Communication Technologies - Schematic Display

The simplest business process is a sequence of process steps. If a system switch occurs, data is usually transferred to the subsequent system as a message. Ideally, the sender system has an outbound interface that can be used to make the data available in a particular structure. This data is then transferred to the subsequent system by using a transaction-secure transfer method. An inbound interface in this system receives the data and triggers the next process step. In asynchronous communication, the receiver system does not have to be available when a function call is made from the sender system. The receiver system can still receive and process the call at a later stage. If the receiver system cannot be contacted, the function call is placed in the outbound queue of the sender system. The call is repeated at regular intervals until it can be processed by the receiver system. If you want the first system to control the process, you can implement synchronous interfaces. In this case, the first system calls a service in another system and waits for a response. Sometimes it is difficult to distinguish between synchronous and asynchronous interfaces. When analyzing the process, you might need to decide whether three sequential process steps should be implemented with multiple external asynchronous interfaces or as just one synchronous external interface.

Analyzing Asynchronous Interfaces in DetailYou must perform a detailed analysis of each external interface you want to implement.

2005/Q4


43


BIT100

Analyzing Outbound Interfaces:An outbound interface is a program that provides data in a well-defined structure. The following outbound interfaces are used in SAP software: Some applications have IDoc interfaces. A program that creates an IDoc (Intermediate Document) is made available. The structure of the IDoc is described in detail by an IDoc type. These are stored in the Interface Repository. For more information, see http://ifr.sap.com. In the IDoc type, you define the structure and the semantics for each field. Various communication methods can be used to send an IDoc (file, tRFC, HTTP). XML interfaces: The structure of the XML document is defined by an XML schema or DTD. XML documents are usually sent by using HTTP or HTTPS. Some applications have outbound interfaces that can be processed by SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) directly. These are actually SOAP documents that are sent by using HTTP or HTTPS. Some applications create files. A printout or fax can also be an outbound interface. Depending on what formats the receiver supports, most SAP applications give you the option of configuring whether a printout, fax, or IDoc is created. A generated e-mail is also a form of outbound interface. However, e-mails cannot always be evaluated by machine.

You must check whether the data that is provided using the outbound interface is sufficient for the subsequent process steps.

44


2005/Q4

BIT100


Analyzing Inbound Interfaces:An inbound interface is a program that can receive external data with a particular structure. Business application programming interfaces or BAPIs: These are stored in the Interface Repository. For more information, see http://ifr.sap.com. To find a BAPI within an SAP system, use the BAPI Explorer (transaction BAPI). Some applications have IDoc interfaces. A program is made available that evaluates an IDoc (Intermediate Document) and triggers a process step. The structure of the IDoc is described in detail by an IDoc type. These are stored in the Interface Repository. For more information, see http://ifr.sap.com. In the IDoc type, you define the structure and the semantics for each field. There are various different communication methods that can be used to receive an IDoc (file, tRFC, HTTP). XML interfaces: The structure of the XML document is defined by an XML schema or DTD. XML documents are usually sent by using HTTP or HTTPS. Therefore, the receiver system provides an HTTP service that receives the XML document and triggers the next process step. SAP NetWeaver XI inbound interfaces: In this case, a SOAP message is usually sent from the Integration Server to the target system by using HTTP(S). SAP NetWeaver XI interfaces are defined in the Integration Repository. The inbound interface must be implemented in the target system. Files are used by some applications to support inbound interfaces. In this case, files from a particular structure must be placed in a directory. How the file structures are documented depends on the application.

Structure and Value MappingIf the outbound and inbound interfaces have identical structures and use the same methods of communication, you can configure a direct connection. If this is not the case, you have to perform a structure mapping. Refer to the following figure.

2005/Q4


45


BIT100

Figure 25: Transfer from Outbound to Inbound Interface

Parallel and Serial Processing in Process StepsWhen you define an integration process, you have to decide whether the process steps and the messages they use are to be processed in parallel or in serial. This is explained with two examples.

Serial ProcessingThe following figure shows a receiver process step. The process starts when the first receive step receives the message. When the message is received, the receive step activates a correlation. This correlation is used by the two subsequent receive steps; in each case the messages are correlated using an ID. As soon as all three messages have been received, the process sends the messages in reverse order. As soon as it has sent a message, the process waits for confirmation from the receiver to arrive before sending the next message.

46


2005/Q4

BIT100


Figure 26: Serial Processing in a Process Step

Parallel ProcessingIf, for example, multiple inbound messages are to start a process, the method of communication used must enable you to configure the process correspondingly within a fork. Consequently, multiple inbound messages can then be processed in independent branches, for example, to enable communication with two independent systems. The various branches of the fork are merged at the end of parallel processing by using an operator.

Figure 27: Parallel Processing in a Process Step

2005/Q4


47


BIT100

Lesson SummaryYou should now be able to: Describe which aspects you need to take into account when developing an integration strategy

48


2005/Q4

BIT100

Unit Summary

Unit SummaryYou should now be able to: Describe which aspects you need to take into account when developing an integration strategy

2005/Q4


49

Unit Summary

BIT100

50


2005/Q4

Unit 4SAP Interface TechnologiesUnit OverviewThis unit introduces the SAP interface technologies Remote Function Call (RFC), Business Application Programming Interface (BAPI), and Intermediate Document (IDoc).

Unit ObjectivesAfter completing this unit, you will be able to: Describe how RFC and its variations (synchronous, transactional, and queued) work Describe the prerequisites for an RFC connection to an SAP system from an SAP system and from other RFC-enabled systems Explain when to use the different types of RFC calls Create an RFC destination in an SAP system Describe the distinctive features of BAPIs Explain how the Business Object Repository is used as the central repository for SAP objects, and explain how to use its methods Describe when to use BAPIs Find out information about BAPIs Identify typical IDoc scenarios Find information about the structure of IDocs Describe the procedure and characteristics of inbound and outbound IDoc processing Explain the ALE concept

Unit ContentsLesson: Integration Technology - RFC........................................ 52 Exercise 2: Executing an RFC in Another System...................... 67 Lesson: Communicating Using BAPIs ........................................ 70 Exercise 3: Searching for, Analyzing, and Testing BAPIs.............. 77 Lesson: IDoc and ALE .......................................................... 80

2005/Q4


51

Unit 4: SAP Interface Technologies

BIT100

Lesson: Integration Technology - RFCLesson OverviewThis lesson introduces the interface technology, Remote Function Call (RFC).

Lesson ObjectivesAfter completing this lesson, you will be able to: Describe how RFC and its variations (synchronous, transactional, and queued) work Describe the prerequisites for an RFC connection to an SAP system from an SAP system and from other RFC-enabled systems Explain when to use the different types of RFC calls Create an RFC destination in an SAP system

Business ExampleIn the business world today, a company's systems must be able to communicate with other systems, some systems within the same company, or systems belonging to business partners. You work in your company's IT department and want to find out more about RFC as one of the technology options shipped by SAP for establishing this kind of communication.

RFC Communication Between Two SAP SystemsIn a remote function call, a task is transferred from one system to another. This other system provides the function required by the caller. The system that provides the function is known as the server; the system that uses the function is known as the client. If this system is an SAP system, the server makes the function available as an RFC-enabled function module. This is also where RFC gets its name. Both the client and the server can be either SAP or non-SAP systems. This section starts with a communication scenario between two SAP systems. Communication between an SAP system and a non-SAP system is covered later in the lesson. Hint: SAP uses synchronous RFC in BAPIs. Asynchronous RFC is used by IDocs. Both BAPIs and IDocs are covered in other lessons.

52


2005/Q4

BIT100

Lesson: Integration Technology - RFC

Figure 28: RFC Between Two SAP Systems

When an RFC call is executed between two SAP systems, the client calls a function module within the normal ABAP logic. This function module must be available in the server under the same name so it can be called remotely. In the call, the client specifies that this function module is to be processed and by which system. This is done by using an RFC destination. What an RFC destination looks like and what information is required is covered in another lesson. The following figure illustrates the properties of remote-enabled function modules (RFM).

Figure 29: Properties of Remote-Enabled Function Modules

2005/Q4


53


BIT100

Realizing an RFC Call Between Two SAP SystemsAll SAP systems are shipped with an RFC layer. This layer enables data in RFC protocol format to be exchanged between two SAP Gateways. The sender system requires an RFC destination of type 3. The corresponding request is executed using the user entered in the RFC destination.

Figure 30: RFC Between Two SAP Systems

RFC destinations provide the system with all the information that is required to access a function in another system. The previous examples have already shown that you do not need to manually enter any information about the user, target address, or similar data when the RFC is called because this information is taken from the RFC destination. To be able to access an SAP system, you need to specify only the host address of the SAP system, the client, and the logon data. The user that is used here must have all the authorizations that are necessary to execute the required RFC calls. For reasons of security, SAP recommends that you choose a system user so that it is not possible to log on to the system by using the SAP GUI. Some RFC destinations are case sensitive. SALES and Sales might therefore correspond to two different destinations.

54


2005/Q4

BIT100


Figure 31: RFC Destination of Type 3 for an SAP System

Types of RFCsThe Analysis of Business Processes unit looks at the differences between synchronous and asynchronous interfaces, and where each type is used. RFC provides appropriate tools for both variants: those used for interfaces, synchronous RFC for synchronous processing, and transactional and queued RFC for asynchronous processing. This section covers these interfaces in more detail. Synchronous RFC In a synchronous RFC call, the user starts the query that is to be forwarded to the remote system. The user waits for a response and cannot do anything in this session until the response has arrived. As soon as the response has arrived, it is displayed and the user can now continue working. The user decides how often the same call is executed. The user also decides what procedure to follow when an error occurs. On a technical level, the entire process flow takes place in one work process at the client, which communicates with exactly one work process at the server. If the server system is not available when the query is sent, the user cannot continue working. The user must resend the query manually at a later stage.

2005/Q4


55


BIT100

Figure 32: Flow Diagram for Synchronous RFC

Transactional RFC In transactional RFC (tRFC), a whole transaction (hence the name) at the client is filled with data, which the server is then to execute. The information about what is to be done is not transferred directly to the server but written to the database by the caller program instead. The process is then available again for the original program. A different process then applies the saved information and executes the actual call in another system. A response confirming whether the call was successful or not can no longer be sent to the original user. Consequently, the original user also cannot be the controlling instance. Instead, the system guarantees that each transaction is executed exactly once. This is also known as transaction security, which is guaranteed by transactional RFC. For this purpose, each call has a unique TRANSACTION-ID, which is known by both the sender and the receiver. The two systems use this unique key to exchange information about what has already been executed, what is still to be executed, and the statuses used. If a query cannot be processed because the other system is currently not available, it is repeated automatically. If an application error occurs, the system switches to automatic repetition and the error message sent by the server is made available in the client system.

56


2005/Q4

BIT100


Figure 33: Flow Diagram for Transactional RFC

In transactional RFC, each query is processed by a separate work process. As a result, if numerous queries arrive simultaneously or if application errors occur, queries to the same remote system can overtake each other. In most cases, for example, when 1000 independent materials are to be created, this does not cause any problems. However, certain applications require the processing sequence at the sender and receiver to be identical to avoid errors. You can achieve this by forcing all queries in a process to be processed sequentially, and stopping subsequent steps if an error occurs in a call. This function is available in queued RFC (qRFC). Queued RFC In qRFC, all queries that belong together sequentially are placed in a queue in the correct order. This ensures that they are processed in the correct order. The name of the queue is defined by the caller program. As far as the actual processing is concerned, there are four different cases. In two cases, only the client works with a queue; in the other two cases, the server also works with a queue. In the first scenario, the client not only places the data in the queue but also decides when the server starts processing and ensures that the processing order is maintained. The following figure shows this procedure.

2005/Q4


57


BIT100

Figure 34: qRFC with Sender Queue Controlled by Client

However, it is also possible that the client places all queries in the queue, but does not influence how the queue is processed. Instead, the client collects the tasks at a time specified by the server, and executes them one after the other.

Figure 35: qRFC with Sender Queue Controlled by Server

58


2005/Q4

BIT100


When both the client and the server work with queues, the server can decide when processing of the queue begins.

Figure 36: qRFC with Sender and Receiver Queue Controlled by Server

When there are two queues, as shown in the following figure, the client controls when processing of the queue begins.

2005/Q4


59


BIT100

Figure 37: qRFC with Sender and Receiver Queue Controlled by Client

Any errors that occur when calling an RFC are returned to the caller system. Hint: Additional information for ABAP developers: The special exceptions, communication_failure and system_failure, are automatically available for each RFC-enabled function module in addition to the exceptions defined by the developer. In a synchronous call, these exceptions must be caught and processed in the caller program. The person who started the program is automatically made aware of this error and can then react appropriately, either by correcting the input data or by repeating the process when the partner system can be accessed again. When a tRFC or qRFC call is executed, the person who originally used the program may not be made aware of any errors that occur. For this reason, there is an additional administration layer in qRFC and tRFC. Depending on what settings have been made, when a communication error occurs, this layer can repeat the call until it is successfully processed. If an error is reported from the caller module, processing is terminated and the system waits for an administrator to intervene. You can display and, if applicable, restart transactional calls with errors in transaction SM58. You manage queues in transactions SMQ1 and SMQ2. Exactly-once processing of each call in the target system is guaranteed by a unique RFC TRANSACTION ID, which defines each call uniquely at the sender and receiver.

60


2005/Q4

BIT100


Figure 38: Processing Errors in RFC

Communicating with Non-SAP SystemsYou can execute an RFC call not only between two SAP systems, but also between an SAP and a non-SAP system. The non-SAP system can be either the server or the client. tRFC and qRFC can be used only if the non-SAP system also supports them. Furthermore, since RFC is a proprietary SAP technology, the SAP RFC Software Development Kit (RFC-SDK) needs to be installed on the non-SAP system. You can download RFC-SDK from SAP Service Marketplace at service.sap.com. RFC-SDK can be run on all established operating systems. RFC-SDK contains an example program for an RFC client, an example program for an RFC server, and an example for the saprfc.ini file. This file contains information about how to reach an SAP system when it is the server in an RFC call. The content of the file is approximately the same as the data that is saved in the RFC destination in SAP systems. The call is then made using a C-routine within a C-program.

Let us assume initially that SAP is the client in a communication scenario. You have two options for establishing communication. In the first option, SAP starts the server program by calling the RFC. This type of communication is illustrated in the following figure.

2005/Q4


61


BIT100

Figure 39: SAP as the Client Starting the Server

In the second option, the server system determines the time at which communication is established. At this point, the non-SAP system registers with the SAP Gateway. Communication is then established and the SAP system can now access this system.

Figure 40: SAP as Client when Server Registers with the SAP System

In both cases you need to enter the relevant access data for the non-SAP system in an RFC destination of type TCP/IP in the SAP system. For starting the server program, the RFC destination is defined as shown in the following figure:

62


2005/Q4

BIT100


Figure 41: RFC Destination for an External System Including Starting a Program

The following figure shows an RFC destination for a non-SAP system with prior registration.

Figure 42: RFC Destination for a Non-SAP System with Prior Registration

The SAP system can also take the role of the server. The non-SAP system client can then use every RFC-enabled function module.

2005/Q4


63


BIT100

Figure 43: SAP as Server for Communication with Non-SAP Systems

To be able to use RFC function modules, the non-SAP system needs to know the relevant system and logon data for the SAP system. This information is provided for all relevant systems in the ini file. The RFC-SDK is shipped with an example ini file, which needs to be completed with the relevant SAP data.

Figure 44: Example of an saprfc.ini File

When should you use which type of RFC? In synchronous RFC, the user is responsible for transaction security, therefore it cannot be guaranteed. Consequently, synchronous RFC is always used when a response is imperative,

64


2005/Q4

BIT100


that is, when the response contains business information and can be displayed only. In all other cases in which the response merely contains confirmation of success or failure, which are usually posting functions, either tRFC or qRFC are used. However, qRFC must be used only when a particular sequence is required to ensure the function is maintained (for example, material postings in a warehouse) because a posting with errors will delay all subsequent postings.

2005/Q4


65


BIT100

66


2005/Q4

BIT100


Exercise 2: Executing an RFC in Another SystemExercise ObjectivesAfter completing this exercise, you will be able to: Execute an RFC call and see what it looks like for the user

Business ExampleYou want to get information about Customizing content in your current system, as well as in one or more other SAP systems.

Task:The function module BAPI_COMPANYCODE_GETLIST displays the company code of a client. 1. 2. Ensure that this function module exists and is remote-enabled. The function module must be remote-enabled so that the required information can be accessed from other clients. Since there is no report to implement this function, use the test tool for this purpose.

2005/Q4


67


BIT100

Solution 2: Executing an RFC in Another SystemTask:The function module BAPI_COMPANYCODE_GETLIST displays the company code of a client. 1. Ensure that this function module exists and is remote-enabled. a) Call transaction SE37. Enter the function module name and choose Display. Choose the Attributes tab page. The Processing Type frame displays whether the function module is remote-enabled or not.

2.

The function module must be remote-enabled so that the required information can be accessed from other clients. Since there is no report to implement this function, use the test tool for this purpose. a) Choose the test tool icon. Enter an RFC destination in the subsequent screen. You do not need to make any other entries. Test three RFC destinations: enter SALES, PRODUCTION, and leave one RFC destination empty (the function module is executed locally in this case). The three RFC destinations will return a list with different company codes. This illustrates that the calls are definitely executed in different systems.

68


2005/Q4

BIT100


Lesson SummaryYou should now be able to: Describe how RFC and its variations (synchronous, transactional, and queued) work Describe the prerequisites for an RFC connection to an SAP system from an SAP system and from other RFC-enabled systems Explain when to use the different types of RFC calls Create an RFC destination in an SAP system

2005/Q4


69


BIT100

Lesson: Communicating Using BAPIsLesson OverviewThis lesson discusses the particular characteristics of BAPIs. This includes details about their technical implementation and business importance.

Lesson ObjectivesAfter completing this lesson, you will be able to: Describe the distinctive features of BAPIs Explain how the Business Object Repository is used as the central repository for SAP objects, and explain how to use its methods Describe when to use BAPIs Find out information about BAPIs

Business ExampleThe SAP system at your company contains data that is to be made available to third parties. You cannot assume that these third parties can use a graphical user interface (GUI) to access your system. You want to find out whether you can use BAPI technology to enable your data to be accessed.

BAPIs as Methods for Business Object TypesBAPI stands for Business Application Programming Interface. BAPIs enable business information either to be made accessible or to be changed. BAPIs can be used both within SAP (for example, for business processes that SAP ships for distributed systems) and externally. The latter in particular has consequences that are covered in this lesson. Since BAPIs are so closely linked to business events (unlike the remote-enabled function modules discussed in another lesson), they do not reside as individual functions in an SAP system; instead they are assigned as methods to business objects types. For this reason, this section briefly looks at business object types. A business object type is an abstraction of a real object. Only real objects that are also of interest at SAP are represented by business object types in an SAP system. Furthermore, the abstraction means that only those characteristics are taken into account that are of interest in a business process involving these objects. All business object types can be accessed in the Business Object Repository (BOR).

70


2005/Q4

BIT100

Lesson: Communicating Using BAPIs

Figure 45: Business Object Types and the Business Object Repository

The business object types have key fields, which make them, as well as all other relevant data, unique. This data is accessed by using methods. Some of these methods are now implemented as BAPIs and represent the business object types that are relevant at this point.

Figure 46: Characteristics of Business Object Types

You can use methods to access these business object types. This involves implementing particular methods - the BAPIs - so that external access is possible, that is, by using the Internet, Java classes, connectors, or directly from a Microsoft application. As a result, they constitute a significant opening up of the SAP systems to the outside world.

2005/Q4


71


BIT100

Figure 47: Business Object Types at SAP

Almost all business objects in SAP have a counterpart in the Business Object Repository (BOR). The following figure shows a selection of well-known and frequently used objects.

Figure 48: Examples of Business Object Types

72


2005/Q4

BIT100


Figure 49: Examples of Uses of BAPIs

On a technical level, BAPIs are realized as remote-enabled function modules. This means that they can be called from an RFC-enabled system outside the SAP system. They also comply with specific naming conventions. They always start with BAPI, followed by an underscore, the name of the business object type that they reference, another underscore, and the name of the method that they implement. This makes BAPIs easy to distinguish from other function modules. See the example in the following figure.

Figure 50: BAPIs as Remote-Enabled Function Modules

2005/Q4


73


BIT100

BAPI must fulfill additional requirements. BAPIs can be used by non-SAP systems. All variables used must be in ASCII format and not in an SAP format. Furthermore, nothing must be altered in the signature of BAPIs that have already been shipped by SAP; doing so could invalidate applications that customers have already implemented. BAPIs must also always send a response to confirm whether their task was successfully executed or not. The name and type of these return values are defined. Object-oriented Implemented as an object method in BOR Stable interface BAPI interface is frozen Parameter in external format BAPIs can be used within the SAP system and can be accessed externally BAPIs usually do not have a presentation layer Visualization of results by callers themselves Confirmation of errors or success by using export parameter RETURN Structure or table (depending on the BAPI) BAPIs represent a self-contained process step within a business process You must also comply with certain rules when using BAPIs to change objects. These rules are included here for completeness, but are really only of interest for developers who call or create BAPIs themselves. The aim of the rules is to let the caller of the BAPI control whether something is posted or not, and if so, when.

Figure 51: Change Access Using BAPIs

74


2005/Q4

BIT100


A separate transaction for BAPIs displays only those business objects that have BAPIs and that display only the BAPIs and no other methods. Transaction code BAPI starts the BAPI Explorer; the initial screen is shown in the following figure.

Figure 52: BAPI Explorer

In transaction BAPI, you can see whether SAP ships an IDoc for a particular BAPI or not. BAPIs can be used transactionally; the content of the transfer parameters is converted to an IDoc and then sent to a receiver by using tRFC. The lesson on IDocs explains in more detail how this asynchronous processing works. If SAP does not ship an IDoc for a particular BAPI, you can always create a customer-specific IDoc automatically in transaction BDBG. Since the main idea behind BAPIs is to make it possible to access functions remotely, all BAPIs are summarized and their characteristics are documented on the Internet. This enables companies that do not have their own SAP system to develop functions that access SAP systems.

2005/Q4


75


BIT100

Figure 53: Interface Repository as Central Repository for SAP Interfaces

76


2005/Q4

BIT100


Exercise 3: Searching for, Analyzing, and Testing BAPIsExercise ObjectivesAfter completing this exercise, you will be able to: Use BAPIs more effectively

Business ExampleYour company wants to make an application available that works closely with SAP systems and that provides data directly from an SAP system.

Task:Use BAPI BAPI_COMPANYCODE_GETLIST to get data. 1. Answer the following question without using the SAP system initially: Which business methods for which objects does SAP provide together with company codes? Using this information, find out more about the GetList method in the SAP system. Which function module is it implemented by? Is the function module remote-enabled? Test the method from the business object environment.

2.

3.

2005/Q4


77


BIT100

Solution 3: Searching for, Analyzing, and Testing BAPIsTask:Use BAPI BAPI_COMPANYCODE_GETLIST to get data. 1. Answer the following question without using the SAP system initially: Which business methods for which objects does SAP provide together with company codes? a) Navigate to http://ifr.sap.com or use the address provided by the instructor. Choose Interface Repository Content, followed by SAP FI 500. CompanyCode is shown under the top node Financial Accounting in the hierarchy, or in the overall list for FI. By clicking the business object, you will see that the key for this object type is the company code; the methods GetList, ExistenceCheck, GetDetail, GetPeriod, and possibly others are also displayed.

2.

Using this information, find out more about the GetList method in the SAP system. Which function module is it implemented by? Is the function module remote-enabled? a) Call transaction BAPI in the SAP system. In the alphabetical overview, navigate to the business object CompanyCode. To display all methods implemented as BAPIs, choose the business object. To display the properties of these methods, choose the method GetList. The implementing function module is BAPI_COMPANYCODE_GETLIST. Double-click the function module to display it. On the Properties tab page you can see that this is a remote-enabled function module. Call transaction BAPI. Search for the business object CompanyCode (for example, in the alphabetical overview). Display the properties by choosing the different object types. The technical name of this business object is BUS0002. Double-click the business object to navigate to the technical view of the business object types. Navigate to the test environment by choosing the test tool icon. Select the GetList method. On the subsequent screen, choose Execute to display a results list. Unlike the test environment for function modules, you cannot test other RFC destinations here.

3.

Test the method from the business object environment. a)

78


2005/Q4

BIT100


Lesson SummaryYou should now be able to: Describe the distinctive features of BAPIs Explain how the Business Object Repository is used as the central repository for SAP objects, and explain how to use its methods Describe when to use BAPIs Find out information about BAPIs

2005/Q4


79


BIT100

Lesson: IDoc and ALELesson OverviewThis lesson looks at IDoc (Intermediate Document) and ALE (Application Link Enabling) technology.

Lesson ObjectivesAfter completing this lesson, you will be able to: Identify typical IDoc scenarios Find information about the structure of IDocs Describe the procedure and characteristics of inbound and outbound IDoc processing Explain the ALE concept

Business ExampleYou want to exchange information between different SAP systems in your company. You want to exchange the data by using IDocs.

IDoc InterfaceMany business processes have standard IDoc scenarios that support the distribution of documents beyond system boundaries. In this case, you can send the information by using an IDoc (Intermediate Document).

80


2005/Q4

BIT100

Lesson: IDoc and ALE

Figure 54: IDoc Processing

The process of sending an IDoc starts with the creation of a message in IDoc format in the sender system. There the IDoc is written to the database. If all the required data about the receiver of the message is known, the IDoc can be sent. When it arrives in the target system, the IDoc is first saved to the database. If all the information required to process the IDoc further is available, the IDoc can then be transferred to the application and posted. You can configure and control each of these steps individually. IDocs are always sent as part of asynchronous communication and have a high level of transaction security.

Figure 55: Intermediate Document

2005/Q4


81


BIT100

The structure of an IDoc is defined by a

sap netweaver process integration

Documents