Bit400 en Col34 Fv Part a4

BIT400 SAP Exchange Infrastructure mySAP Technology

Date Training Center Instructors Education Website

Participant Handbook Course Version: 2003 Q4 Course Duration: 3 Day(s) Material Number: 50064223

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

Copyright Copyright © 2004 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. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Trademarks •

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

•

IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

•

ORACLE® is a registered trademark of ORACLE Corporation.

•

INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.

•

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

•

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

•

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

•

JAVA® is a registered trademark of Sun Microsystems, Inc.

•

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

•

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

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

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

Typographic Conventions American English is the standard used in this handbook. The following typographic conventions are also used. Type Style

Description

Example text

Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).

26-02-2004

Example text

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

EXAMPLE TEXT

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

Example text

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

Example text

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

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

© 2004 SAP AG. All rights reserved.

iii

About This Handbook

BIT400

Icons in Body Text The following icons are used in this handbook. Icon

Meaning For more information, tips, or background Note or further explanation of previous point Exception or caution Procedures

Indicates that the item is displayed in the instructor’s presentation.

iv


26-02-2004

Contents Course Overview ......................................................... vii Course Goals ...........................................................vii Course Objectives .....................................................vii

Unit 1: Introduction to Exchange Infrastructure.................... 1 Work Method of SAP Exchange Infrastructure......................2

Unit 2: System Landscape and System Landscape Directory 15 Analysis of the System Landscape ................................. 16 System Landscape Directory ........................................ 21

Unit 3: SAP XI Pipeline Example for an Asynchronous Scenario .................................................................... 35 Introducing the Scenario ............................................. 37 Processing Within SAP Exchange Infrastructure: The Pipeline 47 Logical and Technical Routing ...................................... 53 Mapping Between Different Interfaces ............................. 75

Unit 4: Adapters .......................................................... 95 Adapter Overview ..................................................... 98 The Adapter Engine .................................................101 Outbound File Adapter .............................................. 117 Inbound File Adapter ................................................148 IDoc Adapter..........................................................172 Inbound IDoc Adapter ...............................................187 Outbound IDoc Adapter .............................................201 RFC Adapter: Overview............................................. 211 Inbound RFC Adapter ...............................................228 Outbound RFC Adapter .............................................236

26-02-2004


v

Contents

vi

BIT400


26-02-2004

Course Overview This course demonstrates how to implement scenarios in a distributed system landscape by using SAP Exchange Infrastructure. It introduces the architecture and features of SAP Exchange Infrastructure. It gives a detailed introduction to scenario configuration and the connection of back-end systems by using adapters.

Target Audience This course is intended for the following audiences: •

Developers and consultants who want to configurate scenarios using SAP Exchange Infrastructure.

Course Prerequisites Required Knowledge • •

Basic knowledge of business processes in distributed system landscapes Basic knowledge of integration technologies

Recommended Knowledge •

Basic knowledge of IDoc processing (for IDoc adapters)

Course Goals This course will prepare you to: • •

Configuring scenarios in SAP Exchange Infrastructure Connecting systems to SAP Exchange Infrastructure unsing adapters

Course Objectives After completing this course, you will be able to: • • •

26-02-2004

Configure an asynchronous scenario with different outbound and inbound interfaces Connect sender or receiver SAP systems using the IDoc adapter or the RFC adapter Transfer files to SAP Exchange Infrastructure as a data source using the file adapter and write messages from SAP Exchange Infrastructure to a file using the file adapter


vii

Course Overview

BIT400

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

viii


26-02-2004

Unit 1 Introduction to Exchange Infrastructure Unit Overview This unit introduces the functions and architecture of SAP Exchange Infrastructure.

Unit Objectives After completing this unit, you will be able to: • •

Describe how SAP Exchange Infrastructure processes messages List the options available for connecting application systems to SAP Exchange Infrastructure

Unit Contents Lesson: Work Method of SAP Exchange Infrastructure ......................2

26-02-2004


1

Unit 1: Introduction to Exchange Infrastructure

BIT400

Lesson: Work Method of SAP Exchange Infrastructure Lesson Overview This lesson explains how SAP Exchange Infrastructure processes messages and how to connect application systems.

Lesson Objectives After completing this lesson, you will be able to: • •

Describe how SAP Exchange Infrastructure processes messages List the options available for connecting application systems to SAP Exchange Infrastructure

Business Example You want to implement business processes in a distributed system landscape. You want messages to be sent as uniformly as possible when data is transferred between systems. You want to use SAP Exchange Infrastructure to do this.

Complex System Landscapes Originally, you integrated different applications in an SAP system by saving all the data in a database, but system landscapes have since become much more complex.

Figure 1: Historical Development of System Landscapes

2


26-02-2004

BIT400

Lesson: Work Method of SAP Exchange Infrastructure

Business processes in a heterogeneous system landscape generally span several systems. Until now, you had to develop the external interfaces separately for each interface to exchange data between systems. The method you chose depended on the options available at the time of development.

External Interfaces Using Point-To-Point Connections In a point-to-point connection interfaces are developed between two systems in such a way that the sender system sends a document to the receiver system. If you look at the whole system landscape with all its interfaces, you will see that this often results in a complicated network of connections.

Figure 2: System Landscape with Point-To-Point Connections

Technical Implementation of a Point-To-Point Connection Sender and receiver software components are usually made by different vendors and function using different technologies. The software components often provide external outbound and inbound interfaces. However, they differ in their document structure and in the protocol that the systems support.

26-02-2004


3


BIT400

Figure 3: Technical View of a Point-To-Point Connection

To establish the connection, you use a connector that recognizes both protocols and can convert a message from one protocol to another. If the document structures are different, map the source document fields to the target document fields by using a mapping program. Some connectors provide graphical mapping tools for this purpose.

Implementing Business Processes Before you develop the interfaces you have to analyze the business process that you want to implement in a distributed system landscape. In this analysis you have to determine which process steps you are going to implement in which system in which software component.

Figure 4: Business Process in a Distributed System Landscape

4


26-02-2004

BIT400


Every time data is transferred between systems you have to check whether an external interface exists and how the sender outbound interface fits together with the receiver inbound interface.

Figure 5: External Interfaces in a Distributed System Landscape

Next you evaluate the various methods for developing the interface and then implement it. The relationship between the interface and the business process as a whole is often considered to be unimportant for the technical implementation. Usually, the documentation of the business process and the corresponding interfaces is not given high enough priority. The main consideration is usually that the interface works. However, if the business process changes at a later date or a software component is exchanged or updated, this can also effect communication between the interfaces. In this case it is good to know how the business process and the interface are related.

External Interfaces Using SAP Exchange Infrastructure The aim of SAP Exchange Infrastructure is to provide a platform which allows different interfaces to connect using a uniform technology. This improves the overview and also reduces maintenance costs.

26-02-2004


5


BIT400

Figure 6: System Landscape with SAP Exchange Infrastructure

Architecture of SAP Exchange Infrastructure SAP Exchange Infrastructure comprises various components:

6


26-02-2004

BIT400


Figure 7: Architecture of SAP Exchange Infrastructure

• •

• •

•

•

You implement your system landscape in the System Landscape Directory. You enter all the necessary interfaces of the various software components in the Integration Repository. You save mapping programs here. You configure the scenarios in the Integration Directory. The Integration Engine of the Integration Server ensures that the messages are processed in the Integration Directory according to the configuration. This involves determining who the receiver is and mapping the inbound message to the receiver interface structure. A local Integration Engine is provided for application systems that run on SAP Web AS (Release 6.20 or higher). This Integration Engine generates messages in XI format and sends them to the Integration Server. The Integration Engine receives messages in XI format for inbound interfaces and makes the data available to the application. All other application systems are connected using adapters.

Implementing the System Landscape in the System Landscape Directory You enter all the technical systems of the system landscape in the SLD. This includes host names and other technical attributes as well as information on the software component installed on a server. Assign a business system name to each technical system. This business system name is required for scenario configuration as the name for the sender and receiver systems.

26-02-2004


7


BIT400

Figure 8: Implementing the System Landscape in the System Landscape Directory

Interfaces and Mapping Programs in the Integration Repository The Integration Repository contains the interfaces of the software components you are using. In some cases you can import them to the Integration Repository, in some cases you have to create them manually. Save mapping rules for structure mapping and value mapping for each external interface. There is a graphical mapping tool for this purpose. Alternatively, you can create mapping programs in Java or XSLT.

Figure 9: Mapping Interfaces and Defining Mappings

8


26-02-2004

BIT400


You can create business scenarios to provide a clear overview of the relationship between the interfaces and business processes.

Figure 10: Implementing Scenarios and Assigning the Interfaces and Mappings Used

You can create process steps for a particular role in a system; these steps are referred to as actions. You assign outbound and inbound interfaces to each action. Connect the actions by using connection lines. You can represent synchronous and asynchronous connections. Select an outbound interface for the sender system action and an inbound interface for the receiver system action for each connection. You can specify a mapping program, if necessary, which maps the outbound interface to the inbound interface.

Configuring Scenarios in the Integration Directory The Integration Repository only stores information relating to the development objects of a software component. For these objects it is not important whether and on which server the software component is actually installed.

26-02-2004


9


BIT400

Figure 11: Configuring Scenarios in the System Landscape in the Integration Directory

To implement business processes in a distributed system landscape, you have to configure business scenarios containing exact information on the business systems you want to send a message between. The system saves this configuration in the Integration Directory. The rules define which business system and which inbound interface a document is sent to once it has been sent from a business system with a particular outbound interface to the Integration Server.

Mapping the Application Systems to SAP Exchange Infrastructure You can install a local Integration Engine on any application system that runs on SAP Web AS (Release 6.20 or higher). This means you can implement application scenarios from XI. You define the interface structure in the Integration Repository. An outbound proxy can then be generated and called in the application system; this proxy creates a message from the interface parameters in XI format and sends it to the Integration Server. An inbound proxy can be generated in the target system; this proxy receives a message in XI format from the Integration Server and processes the data. ABAP and Java proxy generation is supported.

10


26-02-2004

BIT400


Figure 12: Runtime Procedure: Conversion to XI Message Format

All other application systems are currently connected to XI by using adapters. The sender system provides data in a document format and sends it to the adapter by using a protocol. The adapter converts the document to XI format and send it to the Integration Server by HTTP(S). The adapter that will receive the message is specified during configuration. The Integration Server sends the message to the adapter. The adapter converts the message to the receiver protocol and sends it to the receiver.

Runtime Procedure of SAP Exchange Infrastructure

Figure 13: Runtime Procedure: Pipeline

26-02-2004


11


BIT400

The processing procedure begins in the Integration Server pipeline as soon as the message reaches the Integration Server in XI format. First of all, the receiver and the receiver inbound interface are determined using the configuration data. This step is called logical routing. Next the pipeline determines the technical method for contacting the receiver. This is called technical routing. If necessary, a mapping program is executed after configuration to map the outbound interface to the inbound interface. Finally, the message is sent to the target system or corresponding adapter.

12


26-02-2004

BIT400


Lesson Summary You should now be able to: • Describe how SAP Exchange Infrastructure processes messages • List the options available for connecting application systems to SAP Exchange Infrastructure

26-02-2004


13

Unit Summary

BIT400

Unit Summary You should now be able to: • Describe how SAP Exchange Infrastructure processes messages • List the options available for connecting application systems to SAP Exchange Infrastructure

14


26-02-2004

Unit 2 System Landscape and System Landscape Directory Unit Overview This unit explains how to implement a system landscape in the System Landscape Directory of the SAP Exchange Infrastructure.

Unit Objectives After completing this unit, you will be able to: • • •

Describe which aspects of a system landscape are relevant for the configuration of business processes in a distributed system landscape Check the component information in the SLD and complete it as required Check the settings for the system landscape in the SLD

Unit Contents Lesson: Analysis of the System Landscape.................................. 16 Lesson: System Landscape Directory ........................................ 21 Exercise 1: Checking the Configuration of the System Landscape Directory ...................................................................... 29

26-02-2004


15

Unit 2: System Landscape and System Landscape Directory

BIT400

Lesson: Analysis of the System Landscape Lesson Overview This unit describes the information about the system landscape that you can store in the System Landscape Directory.

Lesson Objectives After completing this lesson, you will be able to: •

Describe which aspects of a system landscape are relevant for the configuration of business processes in a distributed system landscape

Business Example You have a heterogeneous system landscape with various software components. To implement a business process in this system landscape, you need to analyze the technical properties of the various systems and the application components that are installed.

Analysis of the Technical System Landscape First of all you need to look at your technical system landscape: • • •

Which servers are available? Which basis software is installed on the servers? (SAP WebAS, J2EE Engine, ...) Which protocol types can the systems use to communicate with each other?

The technical system landscape determines the basic technical conditions for an integration solution. If two systems need to communicate with each other directly but they do not support the same protocol, then a connector is required. The connector supports both protocols and converts the sender protocol into the receiver protocol. If the systems communicate by means of SAP Exchange Infrastructure, then this task is performed by adaptors. The system landscape for the examples and exercises is depicted on the following slide.

16


26-02-2004

BIT400

Lesson: Analysis of the System Landscape

Figure 14: Technical System Landscape of the Example Scenario

The technical system landscape comprises two SAP clients and an Integration Server. In the training system, all three clients are set up on an SAP system. A file adapter is also installed, which is used to exchange data with an external airline. The systems will exchange data by using SAP Exchange Infrastructure. Various protocols will be used to exchange the data. Therefore, the network connections and communication channels must be configured at the same time as the system landscape.

Analysis of the Software Components You can improve the analysis by bringing together the software components that are to be used. Software components require specific technology to function. This may be an SAP Web Application Server, a J2EE Engine, or another kind of server technology. No application is able to run on just a C-Compiler or a Java Virtual Machine. Depending on the system landscape and the specific requirements, it may be possible to install a software component on multiple servers. Each software component provides programs for particular functions. Generally, software components have external interfaces to enable them to communicate with other software components. These can be both inbound and outbound interfaces.

26-02-2004


17


BIT400

Figure 15: Software Component with External Interfaces

Examples of SAP inbound interfaces are: • • • • •

Remote-enabled function modules/BAPIs IDoc inbound interfaces File interfaces XML interfaces (Web AS 6.20 or higher) Java or ABAP inbound proxies (Web AS 6.20 or higher and for integration scenarios that were implemented for SAP Exchange Infrastructure)

Outbound interfaces cannot all be described by one object, instead they often exist implicitly. This includes: • • • • •

IDoc outbound interfaces in the form of a program that creates an IDoc RFC outbound interfaces in the form of a program that calls a remote function call by using CALL FUNCTION...DESTINATION File interfaces in the form of a program that creates a file XML interfaces in the form of a program that sends an XML message by using HTTP Java or ABAP outbound proxies (Web AS 6.20 or higher and for integration scenarios that were implemented for SAP Exchange Infrastructure)

Assigning Business Systems and Analyzing Business Processes To implement the business processes in a distributed system landscape, you must assign a business system name to each of the technical systems. The business system describes the semantics of a system (or a client in an SAP system). To implement the business processes, you must know

18


26-02-2004

BIT400

Lesson: Analysis of the System Landscape

which software components are available on which business systems. Each business system must be assigned a technical system during configuration time at the latest.

Figure 16: Assigning Business Systems

When you implement a business process in a distributed system landscape, you determine the business system in which the particular process steps will run and the software component that will execute them. If the business system changes between two consecutive process steps, then the sender software component must provide all the data required for the subsequent process step by means of an outbound interface. This data is sent to the receiver business system and processed there using an inbound interface. Therefore, each time data is transferred between two systems you must identify the sender outbound interface and the receiver inbound interface. If the systems are integrated by means of SAP Exchange Infrastructure, the document is converted from the format that it is sent in to an XI-XML document. Within SAP Exchange Infrastructure, the document structure is mapped to the structure of the inbound interface (structure and value mapping) and is converted to the format of the target system.

26-02-2004


19


BIT400

Lesson Summary You should now be able to: • Describe which aspects of a system landscape are relevant for the configuration of business processes in a distributed system landscape

20


26-02-2004

BIT400

Lesson: System Landscape Directory

Lesson: System Landscape Directory Lesson Overview This lesson describes how to store information about products, software components, and the current system landscape in the System Landscape Directory (SLD).


Check the component information in the SLD and complete it as required Check the settings for the system landscape in the SLD

Business Example The system landscape has been entered in the System Landscape Directory. You want to check whether the System Landscape Directory contains all the relevant information and complete any missing information.

System Landscape Directory In the System Landscape Directory you store all the information that is relevant for a system landscape.

Aspects of a System Landscape Information about the system landscape is required at different levels.

26-02-2004


21


BIT400

Figure 17: Aspects of a System Landscape

•

•

•

To implement a business process, you need to know which business systems are available and which software components are installed on which business system. The system landscape usually comprises development systems, quality-assurance systems, and productive systems for quality assurance. Development objects and Customizing are created in the development or quality-assurance systems and following successful testing are then transported to the productive landscape. Intelligent tools used to organize these transports require information about the technical systems and the transport channels. It is not possible to monitor individual systems within a complicated system landscape. For each communication step, it must be possible to determine the cause of any errors that occur. Therefore, intelligent monitoring tools in a distributed system landscape also require information about the systems in a system landscape.

System Landscape Directory The aim of the System Landscape Directory is to make all the information about a system landscape available centrally. All the tools have access to the information that they require by means of System Landscape Directory interfaces. At present, a lot of information about the system landscape must be entered manually. Some systems can already register with the SLD and thus make the information available automatically. In future releases it will also be possible for SAP systems to register with the System Landscape Directory.

22


26-02-2004

BIT400


Figure 18: System Landscape Directory

Besides the information about the technical and business systems, information about the software components is also required. You can download SAP software components from the SAP Service Marketplace.

Component Information From a software vendor’s point of view, a software component is a modular entity that you are also able to implement in multiple products. It comprises a standalone software component as well as an add-on. Software components are subject to further developments that result in various software component versions. A product comprises software components, which are shipped to customers. A product is also subject to further developments. This might be due to further developments made to the software components that it contains, or due to further software components being added if the product has had functional enhancements made to it. Thus, each product usually has multiple product versions. For example, the product SAP APO has the product versions APO 1.1, 2.0A, 3.0A, 3.1.

26-02-2004


23


BIT400

Figure 19: Products and Software Components

In the SLD, the relationship between the product version and the software component versions is represented by an independent object known as a software feature. This enables you to represent very complicated products. To display the products and software components and their versions in the System Landscape Directory, choose Software Catalog from the SLD initial screen.

Figure 20: Example of a Product and a Software Component

SLD Interfaces for the Integration Repository The System Landscape Directory has an interface for the Integration Repository where you can import software components and their various versions. The inbound or outbound interfaces for a software component version are then implemented in the Integration Repository. You can only

24


26-02-2004

BIT400


create objects for software component versions that you have entered in the SLD and that were imported into the Integration Repository by using this interface.

Figure 21: SLD Interface for the Integration Repository

The System Landscape in the SLD Besides information about products and software components, you can also enter technical and business systems in the SLD. There are various different types of technical system. The type of technical system determines exactly which attributes you must enter. To check the technical systems in the SLD, choose Technical Landscape from the SLD initial screen. The system navigates to a screen where you can select a system type. It then displays a list of technical systems for the system type you selected.

26-02-2004


25


BIT400

Figure 22: SLD: Technical Systems

For an SAP system you need to enter the host name, the system ID, the release, and the clients. Each client is assigned a business system.

Figure 23: Example: SAP System (Technical View)

The products and software components are assigned at system level, because development objects in SAP systems are not client-specific. In the business system that is assigned to the client, you specifiy which of the products is relevant for the client and therefore for the business system as well.

26


26-02-2004

BIT400


To check the business systems in the SLD, choose XI Landscape from the SLD initial screen. Select a system type. The system displays a list of business systems for the system type you selected.

Figure 24: SLD: Business Systems

In the configuration in the Integration Builder, business systems are used to define the sender and receiver in a scenario. For this reason, the input help has an SLD interface in the Integration Directory, which lists all the business systems that are maintained in the SLD.

Figure 25: SLD Interface for the Integration Directory

26-02-2004


27


28


BIT400

26-02-2004

BIT400


Exercise 1: Checking the Configuration of the System Landscape Directory Exercise Objectives After completing this exercise, you will be able to: • Check the basic configuration of the System Landscape Directory in the Integration Server • Log on to the System Landscape Directory • Check which products and software components are configured in the SLD • Check which technical and business systems are configured in the SLD • Check which products are installed on a business system according to the configuration in the SLD

Business Example You want to implement business processes in an existing system landscape. An administrator has installed SAP Exchange Infrastructure and has configured the existing system landscape in the SLD. You want to check these settings to ensure that they are complete and to make alterations where applicable. The business processes involve SAP software components.

Task 1: SLD Configuration in the Integration Server Check the configuration of the System Landscape Directory (SLD) in the Integration Server. 1.

Log on to the Integration Server. Use transaction SLDCHECK to check whether the configurations for the SLD are correctly maintained.

2.

Log on to the System Landscape Directory.

Task 2: Component Information in the System Landscape Directory Check the component information in the System Landscape Directory. 1.

Is the the product SAP APO in the SLD? How many product versions are there? Which software components belong to the latest product version? Choose Software Catalog from the SLD initial screen.

Continued on next page

26-02-2004


29


BIT400

Task 3: Technical System and Business System in the System Landscape Directory Create a technical and a business system in the SLD for a software component of a small airline. 1.

Log on to the SLD. Use your user BIT400-## from the Integration Server and your password.

2. Create a new technical system of type Third Party with the name TS_BIT_TRAVELAGENCY_##. This technical system will be used later for an exercise involving the file adapter. Assign the product P_BIT_TravelSoft in the version 1.0 to the technical system. The host name should be localhost##. 3. Create a new business system of type Third Party with the name BS_BIT_TravelAgency_##. Leave the field ALE Name initial. This business system will be used in an exercise for the file adapter.

30


26-02-2004

BIT400


Solution 1: Checking the Configuration of the System Landscape Directory Task 1: SLD Configuration in the Integration Server Check the configuration of the System Landscape Directory (SLD) in the Integration Server. 1.

Log on to the Integration Server. Use transaction SLDCHECK to check whether the configurations for the SLD are correctly maintained. a)

2.

Call transaction SLDCHECK to check the configuration of the System Landscape Directory in the Integration Server. This transaction tests the RFC destination used to access the SLD and whether it is possible to access information about the business system and the installed products.

Log on to the System Landscape Directory. a)

Call transaction SXMB_IFR to navigate to a menu for the SAP Exchange Infrastructure J2EE Engine in the Web browser. It is possible to call the System Landscape Directory from here. The user name and password are the same as those required to log on to the Integration Server.

Task 2: Component Information in the System Landscape Directory Check the component information in the System Landscape Directory. 1.

Is the the product SAP APO in the SLD? How many product versions are there? Which software components belong to the latest product version? 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 APO. It has the product versions 2.0A, 3.0A, and 3.1. Choose 3.1. The system displays a list with the software component versions SAP ABA 4.6D, SAP APO 3.1, SAP BASIS 4.6, SAP BW 2.1C, and SAP GUI FOR WINDOWS 6.10.


26-02-2004


31


BIT400

Task 3: Technical System and Business System in the System Landscape Directory Create a technical and a business system in the SLD for a software component of a small airline. 1.

Log on to the SLD. Use your user BIT400-## from the Integration Server and your password. a)

Log on to the System Landscape Directory by calling transaction SXMB_IFR and then choosing the link to the SLD in the web browser.

2. Create a new technical system of type Third Party with the name TS_BIT_TRAVELAGENCY_##. This technical system will be used later for an exercise involving the file adapter. Assign the product P_BIT_TravelSoft in the version 1.0 to the technical system. The host name should be localhost##. a)

Choose Technical Landscape on the System Landscape Directory initial screen. Choose New Technical System to create a new technical system. Choose Third-Party Systems and then Next. Select the product P_BIT_TravelSoft from the list and then choose Add then Next. Enter the following: System Name: TS_BIT_TRAVELAGENCY_## Host Name: localhost##. Finally, choose Finish.

3. Create a new business system of type Third Party with the name BS_BIT_TravelAgency_##. Leave the field ALE Name initial. This business system will be used in an exercise for the file adapter. a)

32

Choose XI Landscape on the System Landscape Directory initial screen. Choose New Business System to create a new business system. Select the Third-Party Business System radio button and then choose Next. Select the technical system you just created and choose Next. Select the product P_BIT_TravelSoft and choose Next. Enter the name BS_BIT_TravelAgency_## for your business system. Select the Integration Server and exit by choosing Finish.


26-02-2004

BIT400


Lesson Summary You should now be able to: • Check the component information in the SLD and complete it as required • Check the settings for the system landscape in the SLD

26-02-2004


33

Unit Summary

BIT400

Unit Summary You should now be able to: • Describe which aspects of a system landscape are relevant for the configuration of business processes in a distributed system landscape • Check the component information in the SLD and complete it as required • Check the settings for the system landscape in the SLD

34


26-02-2004

Unit 3 SAP XI Pipeline Example for an Asynchronous Scenario Unit Overview This unit explains message processing within the Integration Server. It is unimportant at this stage how the back-end systems are connected to SAP Exchange Infrastructure. Message processing within the runtime environment is the same for all messages, regardless of the connection method. This unit explains which configuration settings you must make for the receiver determination, and how to set up a mapping from the sender outbound interface to the receiver inbound interface.

Unit Objectives After completing this unit, you will be able to: • • • • • •

•

• • •

26-02-2004

Describe the example scenario Describe the design view of the scenario and use a business scenario to check it in the Integration Repository Describe the configuration view of the scenario Describe how an XI-XML message is processed within a pipeline (logical routing, technical routing, and mapping) Make settings for logical and technical routing in the Integration Directory Check the runtime procedure by using the SAP adapter monitor and understand the logical and technical routing steps in the XML document Make all the configuration settings in the Integration Directory that are required for an asynchronous scenario with one or more receivers provided no mapping is required Create an asynchronous inbound interface with a data type and message type in the Integration Repository Create a message mapping from an IDoc type to the asynchronous inbound interface Create an interface mapping in the Integration Repository


35

Unit 3: SAP XI Pipeline Example for an Asynchronous Scenario

•

BIT400

Configure an asynchronous scenario in which an IDoc is transferred to the pipeline by means of an IDoc adapter and sends a message to the file adapter in accordance with your inbound interface

Unit Contents Lesson: Introducing the Scenario.............................................. 37 Exercise 2: Checking the Business Scenario in the Integration Repository .................................................................... 43 Lesson: Processing Within SAP Exchange Infrastructure: The Pipeline. 47 Lesson: Logical and Technical Routing ....................................... 53 Exercise 3: Configuring an Asynchronous Scenario with One Receiver ...................................................................... 63 Exercise 4: Configuring an Asynchronous Scenario with a Second Receiver ...................................................................... 71 Lesson: Mapping Between Different Interfaces.............................. 75 Exercise 5: Configuring an Asynchronous Scenario with Two Different Interfaces and a Mapping .................................................. 83

36


26-02-2004

BIT400

Lesson: Introducing the Scenario

Lesson: Introducing the Scenario Lesson Overview This lesson introduces the example scenario.

Lesson Objectives After completing this lesson, you will be able to: • • •

Describe the example scenario Describe the design view of the scenario and use a business scenario to check it in the Integration Repository Describe the configuration view of the scenario

Business Example The business system Travel_Agency_Summer is an SAP system and has an outbound interface for flight master data. This interface is implemented technically by using an IDoc outbound channel. The master data must be distributed independently of the technology involved. In the first step, the target system (business system Training) is also an SAP system with an inbound IDoc interface. Further target systems with other interfaces will be added to the scenario at a later stage. This will be done by using SAP Exchange Infrastructure.

Asynchronous Scenario The work method of SAP Exchange Infrastructure is first explained by means of an asynchronous scenario. To begin with, the lesson focuses on the processing and configuration steps within XI. XI receives a document in a special XML format, identifies the receiver or receivers, and sends each receiver system one document in a special XML format. The data format that the sender system uses to transfer the document to SAP Exchange Infrastructure is irrelevant. There are various adapters available that can convert the document to the XML format that SAP Exchange Infrastructure expects. The same applies for the receiver system. If necessary, adapters can also convert the document to a format that the receiver expects. A document is always processed in the same way within SAP Exchange Infrastructure.

26-02-2004


37


BIT400

Figure 26: Asynchronous Scenario: Distribution of Flight Master Data

This will be illustrated by means of a flight master data distribution example with demonstrations and exercises. In the example, an SAP system sends flight master data in the form of an IDoc. This flight master data then has to be sent to various different target systems. One of the target systems is also an SAP system with an inbound IDoc interface.

Design View The term design view is often used in the context of SAP Exchange Infrastructure. Each process that is to be implemented in a system landscape must have particular functions in the form of programs. Various programs that cover functions that belong together are put together in an application component or software component. In the design phase the inbound and outbound interfaces of the software components used are analyzed and saved in the Integration Repository. If necessary, mapping rules from an outbound interface to an inbound interface are created as well. If, as part of a business process in a distributed system landscape, a software component of a business system is to communicate with a software component of another business system, then the following prerequisites must be satisfied: The sender software component must have an outbound interface The receiver software component must have an inbound interface

38


26-02-2004

BIT400


Figure 27: Design View

The following objects must be created in the XI Integration Repository during the design phase. All the software components used are saved in the SLD and imported into the Integration Repository. The inbound and outbound interfaces used for each software component are stored in the Integration Repository. A mapping rule from an outbound interface to an inbound interface is defined for each required interface. If the outbound interface has a different structure to the inbound interface, then a mapping program is created. To get a better overview of which outbound interface in which business process is assigned to which inbound interface, you have the option of creating a business scenario in the Integration Repository.

26-02-2004


39


BIT400

Figure 28: Business Scenario

In a business scenario in the Integration Repository you create system roles. For example, you want to maintain flight master data in a system. To do so, create a ’Maintain Flight Master Data’ role. At configuration time, you define the system that is to execute this role. Flight master data is to be replicated in multiple systems. To do so, create a ’Dependent System’ role. At configuration time, you define which systems correspond to this role. Initially, it is not important how many systems there actually are for a role in a system landscape. What is important is the software component that is installed in a system for this role. In the example there may be multiple systems where the flight master data is replicated. You can create actions for each role. You can also assign inbound and outbound interfaces to the actions. In a business scenario you can then show which outbound interface is assigned to which inbound interface and which mapping program should be used. All objects in the design view can be shipped by the vendor of a software component. You can complete the missing objects in your Integration Repository. To avoid naming conflicts for object names in later shipments, save your objects in a separate namespace. At runtime, it is the task of SAP Exchange Infrastructure to receive the data from the outbound interface, then to convert it to the data format that the inbound interface expects, and finally to transfer it to the inbound interface of the target system. Besides the information about the software components and their interfaces, you also require information about the actual system landscape for this process.

40


26-02-2004

BIT400


Configuration View Unlike the design view, the emphasis of the configuration view is on the implementation of the scenario in a real system landscape. The configuration view determines which system and outbound interface is to be used to send a message to a different system and inbound interface. You specify the sender and receiver as business systems. In the System Landscape Directory, a technical system is assigned to each business system.

Figure 29: Configuration View

For this reason, the configuration view slides not only contain the inbound or outbound interfaces, but also the systems from which a message is to be sent or in which a message is to be received. You make the settings for the configuration view in the Integration Directory. These settings cannot be shipped by SAP since they are specific to a customer’s system landscape.

26-02-2004


41


42


BIT400

26-02-2004

BIT400


Exercise 2: Checking the Business Scenario in the Integration Repository Exercise Objectives After completing this exercise, you will be able to: • Describe the design view of the scenario and check it in the Integration Repository by using a business scenario

Business Example Flight master data is maintained in a central system and replicated in dependent systems. This scenario is maintained in the Integration Repository. This business scenario gives you a quick overview of all the actions in a business process as well as the interfaces that are used.

Task: In the Integration Repository verify the business scenario BIT400_Scenario1 for distributing flight master data.

26-02-2004

1.

Log on to the Integration Server. From the menu, start the Integration Builder and log on to the Integration Repository.

2.

Examine the business scenario BIT400_Scenario1 for the software component XI Training XX. What actions does this scenario have? How many systems are involved? Is the scenario synchronous or asynchronous? What is the name of the outbound interface for the sender system? What is the name of the inbound interface for the receiver system? Is a mapping required?


43


BIT400

Solution 2: Checking the Business Scenario in the Integration Repository Task: In the Integration Repository verify the business scenario BIT400_Scenario1 for distributing flight master data. 1.

Log on to the Integration Server. From the menu, start the Integration Builder and log on to the Integration Repository. a) b)

2.

Log on to client 800 in the training system. Choose Exchange Infrastructure: Integration Builder → Start Integration Builder or transaction SXMB_IFR. Choose Repository (Design). The user name and password are the same as those required to log on to the Integration Server.

Examine the business scenario BIT400_Scenario1 for the software component XI Training XX. What actions does this scenario have? How many systems are involved? Is the scenario synchronous or


44


26-02-2004

BIT400


asynchronous? What is the name of the outbound interface for the sender system? What is the name of the inbound interface for the receiver system? Is a mapping required? a)

b) c)

d) e)

f)

g)

26-02-2004

To locate the business scenario BIT400_Scenario1, choose XI Training XX → BIT400 → Business Scenario Objects → Business Scenarios. Double click to navigate to the graphical view. The scenario contains the actions ’Replication of Flight Master Data’ and ’Updating the Flight Master Data’. The scenario has two system roles. One system contains the current flight master data, and another is a dependent system that is to receive the current flight master data. In a productive system landscape there may be multiple systems that each have the role of the dependent system. This is an asynchronous scenario. Double click the action before you send the message to display the possible outbound interfaces of the sender system. The action is called FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Double click this name to display the interfaces. It is an IDoc type that was imported from an SAP system. Double click the action after you have received a message to display the possible inbound interfaces of the receiver system. The action is called FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Double click this name to display the interfaces. It is an IDoc type that was imported from an SAP system. To display the outbound and inbound interfaces, double click the connection line that symbolizes the sending of the message in question. The Interfaces tab page contains a list of the interfaces used in this scenario. On the Mapping tab page you can enter a mapping. However, since the inbound and outbound interfaces are identical in this scenario, no mapping is required.


45


BIT400

Lesson Summary You should now be able to: • Describe the example scenario • Describe the design view of the scenario and use a business scenario to check it in the Integration Repository • Describe the configuration view of the scenario

46


26-02-2004

BIT400

Lesson: Processing Within SAP Exchange Infrastructure: The Pipeline

Lesson: Processing Within SAP Exchange Infrastructure: The Pipeline Lesson Overview This lesson explains how messages are processed within SAP Exchange Infrastructure.


Describe how an XI-XML message is processed within a pipeline (logical routing, technical routing, and mapping)

Business Example A message is sent to the SAP Exchange Infrastructure Integration Server by using the technology available. You want to understand how the message is processed within SAP Exchange Infrastructure and how it is then sent to the target system by using one of the available technologies.

The Pipeline Once a document has been transferred to the Integration Server in a special XML format, it is processed in the pipeline. The business system and the receiver inbound interface are determined during logical routing. Technical routing on the other hand determines how the receiver can be accessed. The structure of the sender document is converted to the structure of the receiver document by a mapping.

26-02-2004


47


BIT400

Figure 30: Pipeline

The Integration Engine is the runtime environment of SAP Exchange Infrastructure and is used to exchange messages in accordance with the business processes that you have configured. You configure your business processes by using the Integration Builder: Directory (Configuration). The receiver of an XML message is determined during inbound processing in logical and technical routing. The number of receivers found then determines how processing will continue.

Figure 31: Runtime Procedure: The Integration Server Pipeline

48


26-02-2004

BIT400


If the system cannot find a receiver, it displays an error and terminates processing. If only one receiver is found, the message is placed in the corresponding outbound queue for outbound processing. If more than one receiver is found, in the case of asynchronous quality of services, processing is branched. A new message with a new message ID is created from the original message for each interface/receiver pair in the receiver list that was determined during logical routing. To keep the message branch unambiguous, the message ID of the original message is saved with each new message. If the quality of service is synchronous, then an error occurs in these cases. During the mapping phase, you also have the option of modifying the content of the message by introducing an interface/message mapping, which you have already saved in the Integration Repository.

Format of the XI Messages SAP Exchange Infrastructure processes messages in a special XML format. This format is based on the SOAP standard.

Figure 32: Pipeline: Format of an XI Message

SOAP stands for Simple Object Access Protocol. It is used to define how XML messages are structured. SOAP-XML documents comprise a header that contains information as message attributes, but also information about errors, a hop list detailing the stations that the document has passed through, and runtime and performance information. The actual application data is contained in the payload attachments.

26-02-2004


49


BIT400

Figure 33: SOAP Messages

The following slide shows an example of a SOAP message.

Figure 34: Example of SOAP using HTTP

You can display the XI-XML messages on the Integration Server by using a monitor. In the monitor you have the option of navigating to a detail view of each element of the SOAP document.

50


26-02-2004

BIT400


Figure 35: XI SOAP Message

26-02-2004


51


BIT400

Lesson Summary You should now be able to: • Describe how an XI-XML message is processed within a pipeline (logical routing, technical routing, and mapping)

52


26-02-2004

BIT400

Lesson: Logical and Technical Routing

Lesson: Logical and Technical Routing Lesson Overview This lesson explains logical and technical routing


•

Make settings for logical and technical routing in the Integration Directory Check the runtime procedure by using the SAP adapter monitor and understand the logical and technical routing steps in the XML document Make all the configuration settings in the Integration Directory that are required for an asynchronous scenario with one or more receivers provided no mapping is required

Business Example You want to distribute flight master data from one SAP system to various different systems. The sender SAP system has an IDoc interface for distributing flight master data. One of the target systems is also an SAP system with an IDoc interface. A different target system expects an XML file.

Logical Routing: Receiver Determination The first step in the pipeline is logical routing. It comprises two sub-steps:

26-02-2004


53


BIT400

Figure 36: Pipeline: Logical Routing

The receiver determination determines from the configuration which are the valid receivers for a sender with a special outbound interface.

Figure 37: Configuration View: Receiver Determination

The receiver determination is located in the Integration Directory under Business Scenarios → Receiver Determination.. The trio of values comprising the sender business system, the outbound interface, and its namespace is assigned a business system as a receiver. Furthermore, you can use routing conditions to define the conditions under which a receiver should

54


26-02-2004

BIT400


receive a message. For instance, if a receiver is only to receive a message if a particular field contains a pre-defined value, choose Field Value as the condition type. You can then select a field and enter the relevant value.

Figure 38: XML Message: Receiver Determination

At runtime, you check in the pipeline whether a valid receiver is configured for the trio of values comprising the sender business system, the outbound interface, and its namespace and whether the routing condition has been satisfied. It may be that no valid receiver is configured. In this case the message would not be processed any further. Or it may be that multiple receivers are configured. In this case the following steps are performed for all receivers. You can display the list of receivers identified in the monitor by choosing Receiver Determination→ SOAP Header → Message Header. Each receiver is placed between a pair of XML tags .

Logical Routing: Interface Determination The second sub-step of logical routing is the interface determination. This checks for each identified receiver, whether a receiver business system inbound interface is assigned to the sender business system outbound interface.

26-02-2004


55


BIT400

Figure 39: Configuration View: Interface Determination

You find the interface determination in the Integration Directory under Interface Determination for Outbound Interface. Select an outbound interface. If the outbound interface is only configured for one sender business system and there is only one assigned inbound interface, then the system navigates directly to the detail view. If multiple configurations are configured that involve the outbound interface, then the system first navigates to a list of the configured combinations. From there you can navigate to a detail view for each combination.

56


26-02-2004

BIT400


Figure 40: XML Message: Interface Determination

At runtime, you check in the pipeline whether for an identified receiver a valid inbound interface is configured, which mapping should be used, and whether the routing condition has been satified for the trio of values comprising the sender business system, the outbound interface, and its namespace. It may be that no valid inbound interface is configured. In this case no message would be sent to this receiver. Or it may be that multiple receiver interfaces are configured. In this case the following steps are performed for all inbound interfaces of the receiver. You can display the list of receivers identified in the monitor by choosing Receiver Determination → SOAP Header → Message Header. Each receiver is placed between a pair of XML tags . The namespace of the inbound interface is specified as an XML attribute.

Technical Routing The next step to be executed in the pipeline is technical routing.

26-02-2004


57


BIT400

Figure 41: Pipeline: Technical Routing

Technical routing identifies the end point and the end point type to be used to access each receiver technically.

Figure 42: Configuration View: End Points

58


26-02-2004

BIT400


The end point configurations are located in the Integration Directory under Receiver System End Points. Depending on the inbound interface for a receiver business system, multiple end points may be configured here. This is necessary, since various techniques may be used to access the target system in different scenarios. Hint: To check that the configuration settings for a business scenario are complete, choose the update icon in configuration for the receiver determination. The system must find an inbound interface and an end point.

Scenario with Multiple Receivers The scenario will now be extended by adding a second receiver, which expects flight master data in the form of an XML file. It is connected to SAP Exchange Infrastructure by using an outbound file adapter.

Figure 43: Example Scenario with Two Receivers

To keep the example simple, it is assumed that the target system understands an IDoc type as a data structure. In this case no mapping needs to be executed in the pipeline. In a real scenario the data structure would differ. This is shown in the Mapping Between Different Interfaces lesson.

26-02-2004


59


BIT400

Figure 44: Design View: Scenario with Two Receivers

The target system software component has an inbound interface that expects an XML file in IDoc format.

Figure 45: Configuration View: Scenario with Two Receivers

Besides the receiver business system Training, a receiver business system BS_BIT_TravelAgency is to be configured for the transfer of flight master data.

60


26-02-2004

BIT400


Figure 46: XML Message: Message Split

If there are multiple receivers, then a message must be created from the inbound message for each receiver. In this case the messages are given new numbers following the message split. These numbers are located under Message Split According to Receiver List→ SOAP Header → HopList.

26-02-2004


61


62


BIT400

26-02-2004

BIT400


Exercise 3: Configuring an Asynchronous Scenario with One Receiver Exercise Objectives After completing this exercise, you will be able to: • Configure an asynchronous scenario in the Integration Directory with one receiver

Business Example The business system Travel Agency Summer is an SAP system and it has an outbound interface for flight master data. This interface is implemented technically by using an IDoc outbound channel. The master data must be distributed independently of the technology involved. In the first step, the target system (business system Training) is also an SAP system with an inbound IDoc interface. Further target systems with other interfaces will be added to the scenario at a later stage. This will be done by using SAP Exchange Infrastructure.

Task 1: Configuring in the Integration Directory You make settings for routing and mapping the messages in the Integration Directory. This is where the Integration Repository objects created at design time are configured. The following sub-tasks reiterate the individual steps that are required for the configuration of the asynchronous IDoc scenario. Configure the asynchronous scenario that is described in the business example. The data must only be distributed if the Partner Number Receiver field has the value LS_BIT_##. The field is located in the IDoc control record (segment EDI_DC40) and is called RCVPRN. 1.

Log on to the Integration Server. From the menu, start the Integration Builder and log on to the Integration Directory.

2.

In the Integration Directory create the business scenario BIT400_##.

3.

Create a receiver determination for business scenario BIT400_## that you just created for the sender business system Travel_Agency_Summer. The outbound interface is described by the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. The receiver of the message is the business system Training. Create a routing condition that ensures that the data is only distributed to the business system Training if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. Continued on next page

26-02-2004


63


BIT400

4.

Check the interface determination for the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Is there an interface determination for the sender business system Travel_Agency_Summer and for the receiver business system Training with the inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01? Is a mapping entered in this interface determination?

5.

Check the end point for the business system Training. What end point type is the end point for the inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01?

6.

Save your settings and activate your change list.

7.

Check the entire configuration by choosing the Refresh icon in the detail view for your business scenario. The system displays a configuration overview. Which entry must be in the configuration overview?

Task 2: Test your configuration by sending an IDoc from the Travel Agency Summer system. For this purpose, use the program Send Flight Master Data in the initial menu (program name BIT400_REPLICATE_FLIGHTS_IDOC). 1.

Log on in client 811 (Travel_Agency_Summer) and start the report BIT400_REPLICATE_FLIGHTS_IDOC. Select a valid flight by using the search help and enter the logical system LS_BIT_##. Start the report by choosing the Execute icon. On the next screen the system displays the IDoc number of the generated IDoc. Choose the IDoc number to display the IDoc. The most important technical information is displayed in the window on the right. What value does the Partner Number field contain? To select the segments in the window on the left, expand the Data Records node. To display detailed information about a segment in the window on the right, double click a segment name. What data is transferred in segment E1BPSFLREP?

2.

Once the IDoc has been sent you can display the message in the SAP Adapter Monitor (transaction IDX5) in the Integration Server (client 800). Choose IDoc Monitor and enter today’s date. Choose the Execute icon. Which column contains the IDoc numbers of the source system? Which column contains the number of the XI message that the IDoc adapter created for the IDoc received from the Integration Server? Navigate to the message by double clicking the number and check the receiver determination, interface determination, and technical routing. Continued on next page

64


26-02-2004

BIT400


3.

26-02-2004

How do you know that your message has been successfully processed in the pipeline? Choose the Legend icon.


65


BIT400

Solution 3: Configuring an Asynchronous Scenario with One Receiver Task 1: Configuring in the Integration Directory You make settings for routing and mapping the messages in the Integration Directory. This is where the Integration Repository objects created at design time are configured. The following sub-tasks reiterate the individual steps that are required for the configuration of the asynchronous IDoc scenario. Configure the asynchronous scenario that is described in the business example. The data must only be distributed if the Partner Number Receiver field has the value LS_BIT_##. The field is located in the IDoc control record (segment EDI_DC40) and is called RCVPRN. 1.

Log on to the Integration Server. From the menu, start the Integration Builder and log on to the Integration Directory. a)

2.

In the Integration Directory create the business scenario BIT400_##. a)

3.

Choose Exchange Infrastructure: Integration Builder → Start Integration Builder or call transaction SXMB_IFR. Choose Directory (Configuration). The user name and password are the same as those required to log on to the Integration Server.

To create a new business scenario, call the context menu for the Business Scenario node and choose New.... Enter the name of the business scenario and choose Create. You can enter a description on the next screen.

Create a receiver determination for business scenario BIT400_## that you just created for the sender business system Travel_Agency_Summer. The outbound interface is described by the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. The receiver of the message is the business system Training. Create


66


26-02-2004

BIT400


a routing condition that ensures that the data is only distributed to the business system Training if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. a)

b)

To create a new receiver determination, choose Business Scenario → BIT400_## → Receiver Determination and call the context menu. Next, choose New.... Select the sender business system Travel_Agency_Summer and the interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 from input help and choose Create. You can enter a description on the next screen. In the table for receivers and routing conditions, from the input help for the Receiver field, choose the business system Training. Hint: To display the input help icon, click on the Receiver field.

c)

In the table for receivers and routing conditions, navigate to the condition editor from the input help for the Condition field. Hint: To display the input help icon, click on the Condition field. To add a condition, choose the Insert Expression icon. Select the type Field Value and from the input help for segment EDI_DC40, select the field RCVPRN. Close the window with the IDoc structure by choosing OK. In the Value field enter LS_BIT_##. Close the conditions editor by choosing ’OK’.

4.

Check the interface determination for the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Is there an interface determination for the sender business system Travel_Agency_Summer and for the receiver


26-02-2004


67


BIT400

business system Training with the inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01? Is a mapping entered in this interface determination? a)

b)

5.

Check the end point for the business system Training. What end point type is the end point for the inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01? a)

6.

The interface determinations are located under Interface Determination for Outbound Interface → FLIGHT_SAVEREPLICA.FLIGHTSAVEREPLICA01. Double click to navigate to the detail view. The system displays a table with all the sender business systems for which this outbound interface is configured. One or more receiver interfaces may be assigned to each trio of values comprising the sender business system, outbound interface, and namespace. The receiver interfaces are also identified by a trio of values (receiver business system, inbound interface, and namespace). There is an interface determination for the sender business system Travel_Agency_Summer and for the receiver business system Training with the inbound interface FLIGHT_SAVEREPLICA.FLIGHTSAVEREPLICA01. Double click to navigate to the detail view. No mapping has been entered because the inbound and outbound interfaces are identical.

To find the end points, choose Receiver System End Points. The end point for the inbound interface FLIGHT_SAVEREPLICA.FLIGHTSAVEREPLICA01 is of type ’IDoc Adapter’.

Save your settings and activate your change list. a)

Check whether you have any windows open in change mode. Save your settings and close the window. Next, choose the Change Lists tab page. The Changed Objects node contains all objects that have been changed. You can activate these objects by calling the context menu and choosing Activate. If you want to activate all objects, call the context menu for the Changed Objects node. However, if you want to activate individual objects, call the context menu for the object in question.


68


26-02-2004

BIT400


7.

Check the entire configuration by choosing the Refresh icon in the detail view for your business scenario. The system displays a configuration overview. Which entry must be in the configuration overview? a)

The system must find the inbound interface FLIGHT_SAVEREPLICA.FLIGHTSAVEREPLICA01 from the sender business system Travel_Agency_Summer with the outbound interface FLIGHT_SAVEREPLICA.FLIGHTSAVEREPLICA01 and an end point of type IDoc adapter for the receiver business system Training.

Task 2: Test your configuration by sending an IDoc from the Travel Agency Summer system. For this purpose, use the program Send Flight Master Data in the initial menu (program name BIT400_REPLICATE_FLIGHTS_IDOC). 1.

Log on in client 811 (Travel_Agency_Summer) and start the report BIT400_REPLICATE_FLIGHTS_IDOC. Select a valid flight by using the search help and enter the logical system LS_BIT_##. Start the report by choosing the Execute icon. On the next screen the system displays the IDoc number of the generated IDoc. Choose the IDoc number to display the IDoc. The most important technical information is displayed in the window on the right. What value does the Partner Number field contain? To select the segments in the window on the left, expand the Data Records node. To display detailed information about a segment in the window on the right, double click a segment name. What data is transferred in segment E1BPSFLREP? a)

b)

c)

To start the ABAP report BIT400_REPLICATE_FLIGHTS_IDOC, choose Send Flight Master Data on the initial screen. Enter the corresponding data and start the report by choosing the Execute icon. On the next screen the system displays the number of the generated IDoc. Choose the IDoc number to display the IDoc. The window on the right has a frame with the title Technical Quick Info. The Partner Number field should contain the entry LS_BIT_##. The segment E1BPSFLREP is located under Data Records→E1SFL_SAVE → E1BPSFLREP. Click the segment name. The system displays the values for the AIRLINEID, CONNECTID, FLIGHTDATE, PRICE, CURR, CURR_ISO, and PLANETYPE fields in the window on the right.


26-02-2004


69


2.

Once the IDoc has been sent you can display the message in the SAP Adapter Monitor (transaction IDX5) in the Integration Server (client 800). Choose IDoc Monitor and enter today’s date. Choose the Execute icon. Which column contains the IDoc numbers of the source system? Which column contains the number of the XI message that the IDoc adapter created for the IDoc received from the Integration Server? Navigate to the message by double clicking the number and check the receiver determination, interface determination, and technical routing. a)

b) c)

d) 3.

Choose Exchange Infrastructure: Monitoring → SAP Adapter - Monitoring or call transaction IDX5 to navigate to the SAP Adapter Monitor. The IDoc number is in the Reference Number column. Select the line that contains your IDoc number. The number of the XI message is in the Message ID column. Double click the number in the selected line to navigate to the detail view for your message. Look at the slides for receiver determination, interface determinaiton, and technical routing.

How do you know that your message has been successfully processed in the pipeline? Choose the Legend icon. a)

70

BIT400

The monitor uses a series of icons to indicate whether a message was processed sucessfully or not. The various kinds of errors are also represented by corresponding icons. To display a list of the icons and their descriptions, choose the Legend icon.


26-02-2004

BIT400


Exercise 4: Configuring an Asynchronous Scenario with a Second Receiver Exercise Objectives After completing this exercise, you will be able to: • Configure an asynchronous IDoc scenario in SAP Exchange Infrastructure with two receivers

Business Example An external dependent system expects flight master data in files. Therefore, you also want to create files for all distributed flight master data by using a file adapter and then write the files to a particular directory.

Task: Complete the settings in the Integration Directory. Create a further receiver (BS_BIT_TravelAgency) in your receiver determination under the business scenario BIT400_## in the Integration Directory. The data must only be distributed if the Partner Number Receiver field has the value LS_BIT_##.

26-02-2004

1.

To open the receiver determination for your scenario, double click it. Add the business system BS_BIT_TravelAgency as the second receiver. Enter a condition that ensures that a document will only be sent if the Partner Number Receiver field has the value LS_BIT_##. Save and activate the receiver determination.

2.

Check whether the system can assign a valid interface determination and can find an end point, by choosing the Refresh icon. To which end point type does the assigned end point belong?

3.

Test the routing relation by creating a new IDoc in client 811. Which XI messages are generated from the inbound IDoc?


71


BIT400

Solution 4: Configuring an Asynchronous Scenario with a Second Receiver Task: Complete the settings in the Integration Directory. Create a further receiver (BS_BIT_TravelAgency) in your receiver determination under the business scenario BIT400_## in the Integration Directory. The data must only be distributed if the Partner Number Receiver field has the value LS_BIT_##. 1.

To open the receiver determination for your scenario, double click it. Add the business system BS_BIT_TravelAgency as the second receiver. Enter a condition that ensures that a document will only be sent if the Partner Number Receiver field has the value LS_BIT_##. Save and activate the receiver determination. a)

b)

To open the receiver determination for your scenario, double click it. To add a further receiver, choose the icons with the green plus sign. Call the input help to select the receiver BS_BIT_TravelAgency. In the table for receivers and routing conditions, navigate to the condition editor from the input help for the Condition field. Hint: To display the input help icon, click on the Condition field. To add a condition, choose the Insert Expression icon. Select the type Field Value and from the input help for segment EDI_DC40, select the field RCVPRN. Close the window with the IDoc structure by choosing OK. In the Value field enter LS_BIT_##. Close the conditions editor by choosing OK.

c) 2.

Save and then activate.

Check whether the system can assign a valid interface determination and can find an end point, by choosing the Refresh icon. To which end point type does the assigned end point belong? a)

To check whether the configuration settings are complete, choose the refresh icon in the detail view for the receiver determination. The system displays all valid interface determinations. There should be at least one interface determination that is assigned an end point with the end point type XI-Connectivity.


72


26-02-2004

BIT400


3.

Test the routing relation by creating a new IDoc in client 811. Which XI messages are generated from the inbound IDoc? a)

26-02-2004

Proceed as described in the previous exercise. Use the slides for help.


73


BIT400

Lesson Summary You should now be able to: • Make settings for logical and technical routing in the Integration Directory • Check the runtime procedure by using the SAP adapter monitor and understand the logical and technical routing steps in the XML document • Make all the configuration settings in the Integration Directory that are required for an asynchronous scenario with one or more receivers provided no mapping is required

74


26-02-2004

BIT400

Lesson: Mapping Between Different Interfaces

Lesson: Mapping Between Different Interfaces Lesson Overview This lesson describes how to configure a mapping between different interfaces.

Lesson Objectives After completing this lesson, you will be able to: • • • •

Create an asynchronous inbound interface with a data type and message type in the Integration Repository Create a message mapping from an IDoc type to the asynchronous inbound interface Create an interface mapping in the Integration Repository Configure an asynchronous scenario in which an IDoc is transferred to the pipeline by means of an IDoc adapter and sends a message to the file adapter in accordance with your inbound interface

Business Example An external partner is to receive flight master data by means of XML files. The file format is pre-defined. The flight master data is maintained in an SAP system and there is an IDoc interface for distributing it. The scenario will use SAP Exchange Infrastructure.

Pipeline: Mapping Usually, the outbound interface of the sender software component and the inbound interface of the receiver software component are not identical. This means that you must define mapping rules to assign fields that are semantically identical (structure mapping) and conversion rules to convert to the target format (value mapping). In XI there is a graphical mapping tool for this purpose.

26-02-2004


75


BIT400

Figure 47: Pipeline: Mapping

Configuration in the Integration Repository The mapping rules are defined in the Integration Repository at design time.

Figure 48: Design View: Scenario with Mapping

76


26-02-2004

BIT400


The example is an inbound file interface for a non-SAP software component. A data type is created in the Integration Repository for each line type. A message type, which references the data type, is created for the entire message. The asynchronous inbound interface defines which message type is referenced.

Data Type, Message Type, and Message Interface The following objects are created in the Integration Repository: You create a data type for each line type. The data type contains fields. XI generates an XML document in which the field names appear as XML tags. The fields for file interfaces are usually string-like. If the file structure is too complicated to describe with just one line type, create multiple data types and nest them in a complex data type. The data type that represents the entire message structure is referenced in a message type. By using attributes, the message interface describes whether the interface is an inbound or outbound interface, and whether it is synchronous or asynchronous.

Figure 49: Repository: Data Type, Message Type, and Message Interface

Data Type and Message Type First, analyze the structure of the interface. In the example, an XML file with the following structure is expected:

26-02-2004


77


BIT400

Figure 50: Expected File Structure

To define this structure in the Integration Repository, create a data type that contains the following fields: AirlineId, ConnectId, FlightDate, Price, Currency and PlaneType. The field names in the data type determine the names of the XML tags in the generated XML message. Therefore, they must exactly match the XML tag names that the inbound interface of the receiver software component expects. Next, create a message type FlightReplicate. The name must also match the name of the XML tag that the inbound interface expects. This message type can be referenced as a source or target structure in a message mapping.

Figure 51: Data Type and Message Type

Message Interface Next, you create an inbound and asynchronous message interface that references the message type. This message interface can be referenced as an inbound interface in an interface mapping.

78


26-02-2004

BIT400


Interface Mapping

Figure 52: Design View: Interface Mapping

The connection between the outbound and inbound interface is established by the interface mapping. In the interface mapping you define which mapping program defines the mapping rules from a particular outbound interface to a particular inbound interface.

Figure 53: Repository: Interface Mapping

26-02-2004


79


BIT400

Usually, you can reference either a message interface of type Outbound, an IDoc type, or an RFC interface as the outbound interface in the interface mapping. You can reference either a message interface of type Inbound, an IDoc type, or an RFC interface as the inbound interface. You can create the mapping rule by using a message mapping, an XSLT mapping, or a Java mapping. In the interface mapping you reference the applicable mapping program.

Message Mapping

Figure 54: Repository: Message Mapping

If both the source structure and the target structure are defined in the Integration Repository, you can create a mapping program by using the graphical mapping tool. Mapping programs that you create using this tool are known as message mappings. In the example, the source structure is described by an IDoc type. This has been imported into the Integration Repository for the software component XI Training XX. Therefore, it is located under this software component under Imported Objects. The target structure is described by the message type that you created previously. You can reference RFC signatures, IDoc types, or message types as source and target structures.

80


26-02-2004

BIT400


Figure 55: The Mapping Editor

To select the source or target structure, either search for the structure in the Integration Repository navigation tree, select it with the mouse, and then drag it across to the hand icon by using drag&drop, or use the input help. Finally, to define the structure mapping, select a field in the source structure and use drag&drop to drag it to the corresponding field in the target structure. If you require conversions for fields in the target structure or need to assign constants, use the options available in the data-flow editor in the lower part of the graphical mapping tool.

Figure 56: Structure Mapping in the Mapping Editor

26-02-2004


81


82


BIT400

26-02-2004

BIT400


Exercise 5: Configuring an Asynchronous Scenario with Two Different Interfaces and a Mapping Exercise Objectives After completing this exercise, you will be able to: • Configure an asynchronous IDoc scenario in SAP Exchange Infrastructure with two different interfaces and a mapping

Business Example An external system expects flight master data in a particular file format. You want to create such a document by using SAP Exchange Infrastructure and the file adapter. The flight data is transferred from an SAP system to XI by using an IDoc.

Task 1: Create all the objects that are required for an inbound interface in the Integration Repository. The structure of the interface must correspond to the requirements of an external application. File Structure for the External Application Field Name

Meaning

Type Length; Detail

AirlineID

ID of airline

Char 3

ConnectionID

ID of flight connection

Char 4

FlightDate

Date of flight

Char 8; YYYYMMDD

FlightPrice

Price of the flight in the currency from the Currency field

Char 12; Decimal symbol= ’.’

Currency

Currency ISO code

Char 3

Create an interface mapping from the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 for this inbound interface and perform a structure mapping by using a message mapping. 1.

26-02-2004

Log on to the Integration Repository. Look at the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 that is used as the outbound interface. From the software component XI_Training_XX, choose Imported Continued on next page


83


BIT400

Objects → IDocs. Display the imported IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Which fields does the segment E1BPSFLREP contain? Which segment fields correspond to the fields required in the inbound interface? Field Name

Segment Field

AirlineID ConnectionID FlightDate FlightPrice Currency 2.

Navigate to the software component SC_BIT_TravelSoft. The namespace BIT400_## has been created for this exercise. Create a data type DT_BIT400_##, which contains the fields of the inbound interface. Save the data type.

3.

Create a message type msgT_BIT400_## in your namespace BIT400_## and reference your data type DT_BIT400_##. Save the message type.

4.

Create a message interface I_msgIF_BIT400_##. The interface is an asynchronous inbound interface and should reference the message type msgT_BIT400_## as the input message type. Save the message interface.

5.

Create a message mapping msgMap_BIT400_##. Reference the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the source structure and your message type msgT_BIT400_## as the target structure. Hint: To select the source or target structure, select the IDoc type or message type from the navigation tree and drag them to the relevant hand icon by using drag&drop. Define the structure mapping by selecting a field in the source structure and using drag&drop to drag it to the corresponding field in the target structure. Proceed as described for all remaining fields in the target structure. Also assign the segment E1SFL_SAVE to the node msgT_BIT400_##. Save the message mapping.


84


26-02-2004

BIT400


6.

Create an interface mapping IF_Map_BIT400_##. Select the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the outbound interface and your message interface I_msgIF_BIT400_## as the inbound interface. Enter your message mapping msgMap_BIT400_## as the mapping.

7.

Activate all objects you have created.

Task 2: Add the following scenario to your business scenario BIT400_## in the Integration Directory: If the field Partner Number Receiver contains the value LS_BIT_##, flight master data has to be sent from the business system Travel_Agency_Summer with the outbound IDoc interface to the business system BS_BIT_TravelAgency_## with the inbound interface I_msgIF_BIT400_## in the namespace BIT400_##. Update the required settings in the Integration Directory. Use the configuration assistant for this purpose. 1.

Log on to the Integration Directory and start the configuration assistant for your business scenario.

2.

On the first screen, enter the sender and outbound interface.

3.

On the second screen, enter the receiver and inbound interface.

4.

On the third screen, define the interface mapping. Call the input help and select your interface mapping IF_Map_BIT400_##.

5.

On the fourth screen, define the end point. Select the business system

6.

On the fifth screen, specify the information required for logging on.

7.

Close the configuration

8.

In the receiver determination for the business scenario BIT400_## for the receiver BS_BIT_TravelAgency, define a routing condition that ensures that the data is only distributed if the RCVPRN field has the value LS_BIT_##.

9.

Check the settings for the end point and amend them, if required.

10. Check the receiver determination. Check whether your interface determination exists.

26-02-2004


85


BIT400

Solution 5: Configuring an Asynchronous Scenario with Two Different Interfaces and a Mapping Task 1: Create all the objects that are required for an inbound interface in the Integration Repository. The structure of the interface must correspond to the requirements of an external application. File Structure for the External Application Field Name

Meaning

Type Length; Detail

AirlineID

ID of airline

Char 3

ConnectionID


Char 4

FlightDate

Date of flight

Char 8; YYYYMMDD

FlightPrice



Currency

Currency ISO code

Char 3


Log on to the Integration Repository. Look at the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 that is used as the outbound interface. From the software component XI_Training_XX, choose Imported Objects → IDocs. Display the imported IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Which fields does the segment E1BPSFLREP contain? Which segment fields correspond to the fields required in the inbound interface? Field Name

Segment Field

AirlineID ConnectionID


86


26-02-2004

BIT400


FlightDate FlightPrice Currency a)

2.

Segment Field

AirlineID

AIRLINEID

ConnectionID

CONNECTID

FlightDate

FLIGHTDATE

FlightPrice

PRICE

Currency

CURR_ISO

Navigate to the software component SC_BIT_TravelSoft. The namespace BIT400_## has been created for this exercise. Create a data type DT_BIT400_##, which contains the fields of the inbound interface. Save the data type. a)

3.

Field Name

Expand the node SC_BIT_TravelSoft → BIT400_## → Interface Objects → Data Types. Create a new data type by calling the context menu and choosing New.... Enter the name DT_BIT400_## and check that BIT400_## is entered for the namespace and SC_BIT_Travelsoft for the software component version. Choose Create. You can enter a description on the next screen. Position the cursor on the DT_BIT400_## field and create new fields by using the icons with the green plus sign. For each new field enter a field name, the technical type, and, if required, detailed information.

Create a message type msgT_BIT400_## in your namespace BIT400_## and reference your data type DT_BIT400_##. Save the message type. a)

Under your namespace BIT400_##, choose Interface Objects then Message Types. Create a new message type by calling the context menu. Enter the name msgT_BIT400_## and enter a description. From the input help, select your data type DT_BIT400_## in the namespace BIT400_##.


26-02-2004


87


4.

Create a message interface I_msgIF_BIT400_##. The interface is an asynchronous inbound interface and should reference the message type msgT_BIT400_## as the input message type. Save the message interface. a)

5.

BIT400

Under your namespace BIT400_##, choose Interface Objects then Message Interfaces. Create a new message interface by calling the context menu. Enter the name I_msgIF_BIT400_## and enter a description. Select the attributes Inbound and Asynchronous. In the Input Message Type field, call the input help and select your message type msgT_BIT400_##.

Create a message mapping msgMap_BIT400_##. Reference the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the source structure and your message type msgT_BIT400_## as the target structure. Hint: To select the source or target structure, select the IDoc type or message type from the navigation tree and drag them to the relevant hand icon by using drag&drop. Define the structure mapping by selecting a field in the source structure and using drag&drop to drag it to the corresponding field in the target structure. Proceed as described for all remaining fields in the target structure. Also assign the segment E1SFL_SAVE to the node msgT_BIT400_##. Save the message mapping. a)

Under your namespace BIT400_##, choose Mapping Objects then Message Mappings. Create a new message mapping by calling the context menu. Enter the name msgMap_BIT400_## and your namespace and choose Create. Enter a description. In the tree structure for the software component XI Training XX choose Imported Objects and select the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Drag the IDoc type to the hand icon in the source structure by using drag&drop. Next, drag your message type msgT_BIT400_## to the hand icon in the target structure by using drag&drop. For all remaining target structure fields, assign the appropriate source structure field to the corresponding target structure field by using drag&drop. Assign the segment E1SFL_SAVE to the root node of your target structure msgT_BIT400_## by using drag&drop.


88


26-02-2004

BIT400


6.

Create an interface mapping IF_Map_BIT400_##. Select the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the outbound interface and your message interface I_msgIF_BIT400_## as the inbound interface. Enter your message mapping msgMap_BIT400_## as the mapping. a)

7.

Under your namespace BIT400_##, choose Mapping Objects then Interface Mappings. Create a new interface mapping by calling the context menu. Enter the name IF_Map_BIT400_## and your namespace and choose Create. Create a short text and enter the outbound and inbound interface by using the input help. Alternatively, you can drag the interfaces to the hand icons by using drag&drop. Choose the Read Interfaces icon to display detailed information in the lower part of the screen. Use the input help for the Mapping Program field to select your message mapping, if you have already saved it.

Activate all objects you have created. a)

Navigate to the Change Lists tab page and activate your objects by calling the context menu and choosing Activate.

Task 2: Add the following scenario to your business scenario BIT400_## in the Integration Directory: If the field Partner Number Receiver contains the value LS_BIT_##, flight master data has to be sent from the business system Travel_Agency_Summer with the outbound IDoc interface to the business system BS_BIT_TravelAgency_## with the inbound interface I_msgIF_BIT400_## in the namespace BIT400_##. Update the required settings in the Integration Directory. Use the configuration assistant for this purpose. 1.

Log on to the Integration Directory and start the configuration assistant for your business scenario. a)

Double click to navigate to the detail view for your business scenario BIT400_##. Choose the Configuration Assistant icon to start the configuration assistant.


26-02-2004


89


2.

BIT400

On the first screen, enter the sender and outbound interface. a) Sender

3.

Business System

Travel_Agency_Summer

Interface Name

FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01

Namespace

urn:sap-com:document:sap:idoc:messages

On the second screen, enter the receiver and inbound interface. a) Receiver

4.

Namespace

BIT400_##

Select the radio button ’Yes, with Data Specified Below’. Next, call the input help and select your interface mapping. Once you have selected it, close the window by choosing the icon with the green tick.

BS_BIT_TravelAgency as the receiver and I_msgIF_BIT400_## as the inbound interface in the interface namespace BIT400_##.

Select the radio button ’Logon Data not Required’.

Close the configuration a) b)

8.

I_msgIF_BIT400_##

On the fifth screen, specify the information required for logging on. a)

7.

Interface Name

On the fourth screen, define the end point. Select the business system a) b)

6.

BS_BIT_TravelAgency_##

On the third screen, define the interface mapping. Call the input help and select your interface mapping IF_Map_BIT400_##. a)

5.

Business System

by choosing the Finish icon and check the log.

In the receiver determination for the business scenario BIT400_## for the receiver BS_BIT_TravelAgency, define a routing condition that ensures that the data is only distributed if the RCVPRN field has the value LS_BIT_##. a) Continued on next page

90


26-02-2004

BIT400


9.

Check the settings for the end point and amend them, if required. a)

Use the settings for the inbound interface I_msgIF_BIT400_00 for guidance.

10. Check the receiver determination. Check whether your interface determination exists. a)

26-02-2004

Choose the Update icon.


91


BIT400

Lesson Summary You should now be able to: • Create an asynchronous inbound interface with a data type and message type in the Integration Repository • Create a message mapping from an IDoc type to the asynchronous inbound interface • Create an interface mapping in the Integration Repository • Configure an asynchronous scenario in which an IDoc is transferred to the pipeline by means of an IDoc adapter and sends a message to the file adapter in accordance with your inbound interface

92


26-02-2004

BIT400

Unit Summary

Unit Summary You should now be able to: • Describe the example scenario • Describe the design view of the scenario and use a business scenario to check it in the Integration Repository • Describe the configuration view of the scenario • Describe how an XI-XML message is processed within a pipeline (logical routing, technical routing, and mapping) • Make settings for logical and technical routing in the Integration Directory • Check the runtime procedure by using the SAP adapter monitor and understand the logical and technical routing steps in the XML document • Make all the configuration settings in the Integration Directory that are required for an asynchronous scenario with one or more receivers provided no mapping is required • Create an asynchronous inbound interface with a data type and message type in the Integration Repository • Create a message mapping from an IDoc type to the asynchronous inbound interface • Create an interface mapping in the Integration Repository • Configure an asynchronous scenario in which an IDoc is transferred to the pipeline by means of an IDoc adapter and sends a message to the file adapter in accordance with your inbound interface

26-02-2004


93

Unit Summary

94

BIT400


26-02-2004

Unit 4 Adapters Unit Overview This unit describes various adapters in detail.

Unit Objectives After completing this unit, you will be able to: • • • • • • • • • • • • • • • •

26-02-2004

Describe the different types of adapters and their uses Describe the tasks of the Adapter Engine Configure an outbound file adapter and describe the runtime procedure Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as an XML file Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as a sequential file Configure an inbound file adapter and describe the runtime procedure Configure a scenario that reads an XML file from a directory and transfers it to the Integration Server pipeline as an XI-XML message Configure a scenario that reads a sequential file from a directory and transfers it to the Integration Server pipeline as an XI-XML message Import an IDoc type to the Integration Repository Check the IDoc-specific settings in the SLD Describe the structure of an IDoc as an XML message in the pipeline Configure an inbound IDoc adapter and describe the runtime procedure Configure an outbound IDoc adapter and describe the runtime procedure Describe the distinctive features of an XI-IDoc-XML message Understand the RFC adapter as one of the components of SAP Exchange Infrastructure Check RFC signatures in the Integration Repository


95

Unit 4: Adapters

BIT400

• • • •

Check the basic configuration of the RFC adapter Use the SAP Adapter Monitor Configure a scenario that is triggered from an SAP system by a remote function call (RFC). Configure a scenario in which an RFM (remote-enabled function module) is called by using RFC.

Unit Contents Lesson: Adapter Overview ..................................................... 98 Lesson: The Adapter Engine ..................................................101 Procedure: Configuring the SLD Connection ...........................109 Procedure: Configuring a Password Token ............................. 110 Procedure: Creating a New Adapter ..................................... 111 Exercise 6: Configuring the Adapter Engine ............................ 113 Lesson: Outbound File Adapter............................................... 117 Procedure: Configuring the Outbound File Adapter in the Integration Engine........................................................................123 Exercise 7: Configuring the File Adapter for an XML Target File ....129 Exercise 8: Configuring the File Adapter for a Sequential Target File............................................................................141 Lesson: Inbound File Adapter .................................................148 Procedure: Configuring the Inbound File Adapter in the Integration Engine........................................................................154 Exercise 9: Configuring the Inbound File Adapter for an XML Source File............................................................................159 Exercise 10: Configuring the Inbound File Adapter for a Sequential Source File ..................................................................167 Lesson: IDoc Adapter ..........................................................172 Procedure: Checking the Logical System Name .......................174 Procedure: Importing an IDoc Type......................................179 Exercise 11: IDoc Adapter.................................................183 Lesson: Inbound IDoc Adapter................................................187 Exercise 12: Checking the Configuration for the Inbound IDoc Adapter.......................................................................195 Lesson: Outbound IDoc Adapter..............................................201 Exercise 13: Checking the Configuration for the Outbound IDoc Adapter.......................................................................207 Lesson: RFC Adapter: Overview ............................................. 211 Exercise 14: Checking RFC Signatures in the Integration Repository ...................................................................223 Exercise 15: Checking the Configuration of the RFC Adapter .......225 Lesson: Inbound RFC Adapter................................................228 Exercise 16: Checking the RFC Destination for the Inbound RFC Adapter.......................................................................233 Lesson: Outbound RFC Adapter..............................................236

96


26-02-2004

BIT400

Unit 4: Adapters

Exercise 17: Executing an RFC Call and Checking the XML Message Format of the Pipeline......................................................241

26-02-2004


97

Unit 4: Adapters

BIT400

Lesson: Adapter Overview Lesson Overview This lesson gives an overview of different types of adapters.


Describe the different types of adapters and their uses

Business Example You have a heterogeneous system landscape containing various software components with inbound and outbound interfaces. You want to control the flow of messages using SAP Exchange Infrastructure and existing interfaces as far as possible.

Adapter Overview Adapters for SAP Exchange Infrastructure are designed to connect systems which do not themselves support the XI message format. This includes both SAP systems that are not yet based on SAP Web Application Server (6.20 or higher), for example, R/3 4.6C, and non-SAP systems that do not support HTTP protocol (for example, systems that only exchange data by using files). The available adapters can be split into various categories according to the protocols they support or the types of systems they connect. The following slide gives you an overview of these adapters. It also illustrates the connection of SAP systems based on SAP Web Application Server (6.20 or higher). This is done using proxies and proxy runtime, not adapters.

98


26-02-2004

BIT400

Lesson: Adapter Overview

Figure 57: Adapters: Overview

SAP systems support RFC protocol (Remote Function Call) and are connected using SAP adapters (RFC and IDoc adapters). Technical adapters allow you to connect using technical protocols or processes, for example, FTP, File I/O, JDBC, JMS. SAP’s partner companies provide third party adapters, which enable you to connect to non-SAP ERP systems with their own formats. There are also SOAP/plain HTTP adapters, which allow communication using HTTP based on XML or SOAP documents. The adapters differ in various ways, for example, where they are installed and which programming language they use. This will be addressed in detail in other lessons.

26-02-2004


99

Unit 4: Adapters

BIT400

Lesson Summary You should now be able to: • Describe the different types of adapters and their uses

100


26-02-2004

BIT400

Lesson: The Adapter Engine

Lesson: The Adapter Engine Lesson Overview This lesson introduces the Adapter Engine. File adapters, JDBC adapters, JMS adapters and SOAP adapters can be configured in the Adapter Engine.


Describe the tasks of the Adapter Engine

Business Example You have a local application that you want to connect to SAP Exchange Infrastructure by using an adapter of the Adapter Engine. You want to check and complete the configuration of the Adapter Engine on the computer running this application.

Adapter Engine: Overview Business systems that do not support XI-SOAP protocol themselves are connected to the Integration Service by using adapters. The Adapter Engine is installed near the business system, uses an appropriate protocol to exchange messages with the business system, and communicates with the Integration Server by using HTTP/XI-SOAP messages. This also enables business systems to communicate with the Integration Server through firewalls. The Adapter Engine is a standalone application, developed in Java (J2SE). It does not require a Java (J2EE) server or an SAP Web Application Server.

26-02-2004


101

Unit 4: Adapters

BIT400

Figure 58: Installation Near the Business System

The Adapter Engine supports the following: • • • •

SOAP: Plain SOAP messages File/FTP: Access to files JDBC: Access to databases JMS: Communication with Java messaging service providers Note: The term plain SOAP message is used when the message is contained in the SOAP body and not attached to the SOAP body as an attachment, as is the case with XI-SOAP messages. Hint: There is a difference between inbound and outbound adapters, although the names used here reflect the viewpoint of the Integration Server, that is to say, an outbound file adapter receives XML messages from the Integration Server and writes the messages in files (outbound). This is different to the interface view, which uses the business system viewpoint, where an outbound interface sends messages from the business system to the Integration Server.

The Adapter Engine can communicate with: • • • • •

102

An Internet browser (Adapter Engine administration) The Runtime Workbench (overview of installed Adapter Engines) The System Landscape Directory (overview) The Integration Server (sending messages) A non-SAP back end system (for example, by using SOAP)


26-02-2004

BIT400


Figure 59: Communication with the Adapter Engine

Installing and Starting the Adapter Engine You can install the Adapter Engine by using SDM (Software Delivery Manager) or by unpacking the TechnicalAdapters.sda archive (SDA: Software Delivery Archive). This archive is located on the Integration Server. To open it, use one of the standard unpacking programs, for example, WinZip. Use the folder information when unpacking. This creates a tech_adapters folder when the archive is unpacked, which contains the required Java classes, the configuration files, documentation and batch files for starting the Adapter Engine (run_adapter.bat). Hint: SDM is the Software Delivery Manager, which is used to deploy Java applications (standalone and J2EE) in SAP Web Application Server. Note: You need the Java Development Kit 1.3 (JDK 1.3) for Adapter Engine runtime. You also have to copy the archive and the servlet classes (servlet.jar) to the tech_adapters directory. You can find this archive under http://java.sun.com/product/servlet/index.html. Some adapters may require additional Java archives. Caution: You do not need to start any of the installation scripts (for example, install_fileadapter.bat) after installation. All adapter instances are present and active by default. However, if for

26-02-2004


103

Unit 4: Adapters

BIT400

example you start the install_fileadapter.bat script, only the two adapters file_inbound and file_outbound will be active, the remaining adapters are deactivated. The batch file run_adapter.bat starts the Adapter Engine (in Windows NT). A shell window opens, which displays configuration messages and then the message “Adapter Engine running..”, which tells you that the Adapter Engine has been started successfully. The default setting for the Adapter Engine is port 8200. Note: The port is stored in the BaseConfiguration/GuiBrowserEngine.properties configuration file. Hint: You can set up the Adapter Engine as an operating system service, so that it starts automatically when you restart the operating system. You do this in Windows by using the SAPAdapterService.exe program and in Unix by changing the start script run_adapter.sh (for detailed instructions, see the documentation).

Configuring the Integration Engine You need a browser to configure the Adapter Engine. The default logon procedure uses the IP address of the server where the Adapter Engine is installed with port 8200. The default user is: user sap and password init. The configuration interface is divided into two areas. The area on the left is a menu, the area on the right shows an overview of the available adapters once you have logged on. The menu item About Adapter Engine in the main menu contains general information about the Adapter Engine. Here, you can also set the standard view, that is, the design of the HTML interface (SAP GUI or SAP Web).

104


26-02-2004

BIT400


Figure 60: Adapter Engine: Configuring Using a Browser

Hint: Language: The Adapter Engine exports the language of the configuration interface from the browser settings. In Internet Explorer 5.50, for example, you can set the language by choosing Tools→ Internet Options → Languages. Hint: Documentation: The installation procedure also installs the complete documentation for the Adapter Engine. You can find it in the folder tech_adapter → Administration → Documentation in German and English. You can also call it by using the configuration interface by choosing Documentation in the main menu. First of all, you have to make basic settings in the Adapter Engine. You do this from the main menu, by choosing Services.

26-02-2004


105

Unit 4: Adapters

BIT400

Figure 61: Adapter Engine: Services

To configure a service (the procedure is the same for adapters, which are dealt with later), select Configure and then switch from Edit mode to View mode. You can then make entries in the text area on the HTML form. When you save, these entries are written to a corresponding configuration file in the directory tech_adapter/BaseConfiguration (for services) or tech_adapter/Configuration (for adapters).

Figure 62: Configuring Adapters

106


26-02-2004

BIT400


The GUIBrowserEngine is responsible for user access to the Adapter Engine (for configuration). In this area you configure the port used by users in the browser window to log on to the Adapter Engine; the default is 8200. You can also use the parameter HTTP.transmission to select HTTP (HTTP.transmission=plain) or HTTPS (HTTP.transmission=SSL). You are not permitted to change the other parameters. Hint: To make the installation HTTPS-enabled, you must install additional Java libraries, which are available from SAP Service Marketplace (service.sap.com). These IAIK libraries are located in the Java CLASSPATH. The HTTPServer is responsible for Integration Server access to the Adapter Engine. For the outbound adapters you have to configure: • •

Whether or not user authentication will take place (http.authentication=none|basic) Whether communication will be by HTTP or HTTPS (HTTP.transmission=plain|SSL)

The PWtokens service replaces the password token in the adapter configurations. If you do not want to write passwords to the configuration files in plain text, you can use a PWtoken, a type of placeholder. A PWtoken uses characters to define the beginning and end of the PWtoken content. If required, you can change the beginning and end characters of the tokens (but not the PWtoken itself) centrally here. Hint: The default values are listed in the configuration but are deactivated with the hash symbol “#” since the default values themselves are also used automatically without configuration. The SLDaccessor service is responsible for communication with the SLD. Registering the Adapter Engine in the SLD means that the Runtime Workbench (RWB) recognizes the Adapter Engine (since the RWB also accesses the SLD to determine which Adapter Engines are available). Furthermore, for inbound adapters the Adapter Engine can export the URL of the assigned Integration Engine from the SLD. Passwords for communication between the Adapter Engine and other systems (not for logging on to the Adapter Engine): the PWtokens service only defines the characters that start and end a password. The passwords themselves are defined in the Password Management area. First of all you have to define a password placeholder (token) here. The token comprises the name and the content (that is, the password itself) that is stored when a token is created. When configuring a service or an adapter you can then enter the token instead of the password

26-02-2004


107

Unit 4: Adapters

BIT400

itself. For example, a defined token called mytoken would appear in SLDaccessor as SLD.password= (if the default PWtoken characters are kept). However, you first have to specify in the corresponding configuration that a token will be used: insert the parameter PWD.tokenHandler=PWtokens. To access User Management for logging on to the Adapter Engine, choose Main Menu → User Management. There are four user roles: Adapter Engine Administrator This role allows you to view and change all configurations. Adapter Configurator You are permitted to configure adapters, but you are not permitted to administer the Adapter Engine itself. Adapter User You are permitted to configure the adapters, but not change them. HTTP Server User This role can be used for authentication when using outbound adapters.

108


26-02-2004

BIT400


Configuring the SLD Connection Prerequisites The Adapter Engine is installed and started on the local computer.

Procedure 1.

Determine the host and the port of the SLD of your Integration Server. Log on to the Integration Server and call the transaction SLDCHECK.

2.

Log on to the Adapter Engine by using a browser window, navigate to Services in the main menu and select the SLDaccessor service.

3.

Select Configuration in the detailed view of the SLDaccessor service. To do this, choose Configure and switch to Edit mode.

4.

Enter the connection data for access to the SLD: • • • • •

5.

SLD.host= (for example, SLD.host=iwdf5070.wdf.sap.corp) SLD.port= (for example, SLD.port=50000) SLD.user= SLD.password= SLD.adapterEngineName=

Save the configuration, restart the service and check the log.

Result You have stored the logon data for the SLD of the Integration Server in the Adapter Engine, thus registering the Adapter Engine in the SLD. Moreover, at runtime the Adapter Engine can identify the URL to the Integration Server dynamically from the SLD.

26-02-2004


109

Unit 4: Adapters

BIT400

Configuring a Password Token 1.

Check the settings in the PWtoken service. To do this, log on to the Adapter Engine by using a browser window, navigate to Services in the main menu and select the PWtokens service.

2.

Select Configuration in the detailed view of the PWtokens service. Choose Configure. Note the values set for the parameters PWD.beginSeparator and PWD.endSeparator. Note: If the parameters have a # symbol at the beginning of the line, then the default values PWD.beginSeparator= apply.

3.

Define a PWtoken as a placeholder for a password. In the main menu, navigate to Password Management. Then select Create/Change Tokens. Enter a name for your PWtoken and the password. Save the token. (Example of a PWtoken name: mytoken.) Caution: Only use lower case characters for the PWtoken name.

4.

Navigate to the configuration of the service or adapter where you want to replace the password with a PWtoken. For example, for the SLDaccessor service, choose Main Menu → Services → SLDaccessor→ Configure →Edit/View.)

5.

Specify that you want to use PWtokens at the start of configuration. To do this, enter the following line: PWD.tokenHandler=PWtokens. Caution: This entry is case sensitive. Don’t forget the period.

6.

Replace the password with the previously defined PWtoken (for example, my token) using the separators you noted beforehand. (For example, for the SLDaccessor: SLD.password=.)

7.

Save the configuration, restart the service or adapter and check the log.

Result You have defined a type of placeholder for a password and used it in the configuration of a service or adapter instead of the actual password itself. As a result, the password itself is not visible in the configuration (or in the corresponding configuration file). You can of course use the defined PWtoken more than once, if the corresponding password can be used elsewhere.

110


26-02-2004

BIT400


Creating a New Adapter Prerequisites The Adapter Engine is running and all the adapters that were created during installation are active.

Procedure 1.

Navigate to the area Adapters. To do this choose Main Menu → Adapters.

2.

Select the function Add New Adapter from the list of adapters.

3.

Select a suitable template for your adapter from the list of active adapters (for example, file_outbound for writing a message to a file). Enter a name for your new adapter (for example, BIT400_File_Outbound) and check the option Automatic Startup so that when the Adapter Engine is restarted the adapter is automatically started as well. Create the new adapter by selecting Create and return to the adapter overview by choosing Main Menu → Adapters.

Result You have created a new adapter, using an existing adapter as a template. You have given the new adapter a name, which should refer to the scenario in which it is used. Deactivate the adapter you used as a template so that it can be reused as a template at a later date (as long as it is reactivated beforehand). Hint: Configure a new adapter for each scenario. For example, if you want a business system to contain some files in XML format and other files in flat file format, you have to create and configure two outbound file adapters in the Adapter Engine.

Monitoring The Runtime Workbench lists all registered Adapter Engines and their configured adapters. Furthermore, you can call the configuration of the Adapter Engine from the RWB. The Adapter Engines are located in the SLD under Administration/Content Management, then under Subset Landscape Description Class XI Adapter Engine (or Class XI Adapter Service).

26-02-2004


111

Unit 4: Adapters

BIT400

Figure 63: Adapter Engine: Integration in the Runtime Workbench

You can also view the trace files by choosing Main Menu/Traces, or by looking in the respective adapter section.

Figure 64: Adapter Engine: Monitoring

112


26-02-2004

BIT400


Exercise 6: Configuring the Adapter Engine Exercise Objectives After completing this exercise, you will be able to: • Complete the settings in the SLD that relate to the local Adapter Engine

Business Example You have an external application that can process data in a particular format. You want to connect it to SAP Exchange Infrastructure by using a local Adapter Engine. Your first step is to install and configure the Adapter Engine.

Task: Start the Adapter Engine on your PC and configure the service for SLD access. Check whether your Adapter Engine is registered in the SLD. 1.

Start the Adapter Engine.

2.

Log on to the Adapter Engine.

3.

Determine the host and port of the SLD.

4. Configure the SLDaccessor for the System Landscape Directory. Follow the procedure set out in “Configuring the SLD Connection” in this lesson. The SLD user BIT400SLD-## with password SLD is available for you to use for this connection. 5. Define a PWtoken named token## to enable you to write the password for your user BIT400SLD-## to the configuration file of the SLDaccessor without it being directly visible. Check your Adapter Engine access to the SLD. Follow the procedure set out in “Configuring a Password Token” in this lesson. 6.

26-02-2004

Log on to the SLD and check whether your Adapter Engine is registered under the name you assigned it.


113

Unit 4: Adapters

BIT400

Solution 6: Configuring the Adapter Engine Task: Start the Adapter Engine on your PC and configure the service for SLD access. Check whether your Adapter Engine is registered in the SLD. 1.

Start the Adapter Engine. a)

Start run_adapter.bat, for example by navigating to C:\XI_Training\Local_Adapter_Engine\tech_adapter\run_adapter.bat. The DOS box should remain visible at all times. Hint: Do not close the DOS box, as this closes the Adapter Engine.

2.

Log on to the Adapter Engine. a)

3.

Log on to the Adapter Engine: http://localhost:8200 Initial user: sap, password init

Determine the host and port of the SLD. a)

To find the parameters in the Integration Server, call transaction SLDCHECK, for example.

4. Configure the SLDaccessor for the System Landscape Directory. Follow the procedure set out in “Configuring the SLD Connection” in this lesson. The SLD user BIT400SLD-## with password SLD is available for you to use for this connection. a)

Choose Main Menu→ Services and select the SLDaccessor service. Select Configuration and switch to Edit mode. Use the following values: • • • • •

SLD.host= (for example, SLD.host=iwdf5070.wdf.sap.corp) SLD.port= (for example, SLD.port=50000) SLD.user=BIT400SLD-## SLD.password=SLD SLD.adapterEngineName=AdapterEngine##

Save the configuration, restart the service and check the log. 5. Continued on next page

114


26-02-2004

BIT400


Define a PWtoken named token## to enable you to write the password for your user BIT400SLD-## to the configuration file of the SLDaccessor without it being directly visible. Check your Adapter Engine access to the SLD. Follow the procedure set out in “Configuring a Password Token” in this lesson. a)

b)

c)

d) 6.

Log on to the SLD and check whether your Adapter Engine is registered under the name you assigned it. a)

b)

26-02-2004

In the main menu, choose Password Management, then Create/Change Tokens. Create a token token## and enter the password SLD as the token content. Save the token and return to the main menu. Check whether the default value is valid for the token separators. To do this, choose Services in the main menu, then PWtokens. Go to Configuration and check the lines with the parameters PWD.beginSeparator and PWD.endSeparator. Choose Services in the main menu, then SLDaccessor. Go to Configuration and in Edit mode replace the password SLD with your token token##: SLD.password=. Save the configuration and restart the service. In Logging select View Log and check whether you receive the message “SLD accessor started” without error messages.

For example, use the link to the SLD on the initial page of the Integration Builder: http://:/sld/index.html) to log on to the SLD. The Adapter Engines are located in the SLD under System Landscape → XI Adapters.


115

Unit 4: Adapters

BIT400

Lesson Summary You should now be able to: • Describe the tasks of the Adapter Engine

116


26-02-2004

BIT400

Lesson: Outbound File Adapter

Lesson: Outbound File Adapter Lesson Overview This lesson explains how to configure an outbound file adapter in the Adapter Engine. This can be done using XML files or sequential files as the target file and this lesson addresses both possibilities.


Configure an outbound file adapter and describe the runtime procedure Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as an XML file Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as a sequential file

Business Example You want to use SAP Exchange Infrastructure to send a message to a target system that processes a file of a particular file structure. To do this, you must save a file with the specified structure in a particular directory by using the file adapter. You want to set up this scenario by using the file adapter.

Defining Inbound File Interfaces in the Integration Repository You define the data structure of the inbound interface in the Integration Repository by using data types.

26-02-2004


117

Unit 4: Adapters

BIT400

Figure 65: Repository: Data Type, Message Type, and Message

The exact structure of the objects in the Integration Repository is dependent on the interface and on the file type. Sequential files have a special naming convention for field names. In the case of XML files, the inbound interface not only determines the message structure, but also the field names (by using XML tags). Therefore the interface analysis and the creation of objects in the Integration Repository are addressed in separate sections Configuration for a Target File in XML Format and Configuration for a Sequential Target File.

Outbound File Adapter Tasks

Figure 66: Configuration of the Outbound File Adapter

118


26-02-2004

BIT400


The outbound file adapter is installed in the external business system as part of the Adapter Engine. The Integration Server communicates with the outbound file adapter by HTTP or HTTPS. The configuration in the Adapter Engine determines whether the transfer is encrypted and how authentication is executed. 1.

2. 3.

4.

5.

The Integration Server sends an XML document to the outbound file adapter, whose structure corresponds to that of the inbound interface in the Integration Repository. The Integration Engine gets the target address from the configuration of the corresponding end point in the Integration Directory. The outbound file adapter receives the XML document by HTTP or HTTPS. Optional: If you want to save the file as a sequential file rather than in XML format, the outbound file adapter executes the necessary conversion. In this case you must save exact rules for the conversion when you configure the outbound file adapter. The file adapter saves the document as a file under a file name in a directory. The file name and directory are defined in the configuration of the outbound file adapter. Optional: The file adapter triggers the software component by using a batch file.

Basic Configuration of an Outbound File Adapter Since the data structure and possibly the names you want to use for the file and the directory can differ for each inbound interface, you have to configure a separate outbound adapter for each interface. A multitude of configuration parameters are available. The following sections show you how to structure these parameters. However, it is not possible to look at all the parameters. For detailed information, see the documentation.

26-02-2004


119

Unit 4: Adapters

BIT400

Port and Service of the Integration Server

Figure 67: Port and Service of the Integration Server

Specify in the configuration file which port the Integration Server can use to reach the outbound adapter. You must also maintain the configuration parameters XMB.httpPort and XMB.httpService. Then save this port number and service in the corresponding end point of the Integration Directory. Hint: If you want the transfer from the Integration Server to the Adapter Engine to be encrypted, configure this as a service in the Adapter Engine.

File Name and Directory Specifications The parameters relating to the file name, target directory and edit mode of the files begin with file..

120


26-02-2004

BIT400


Figure 68: Target File Specifications

Hint: The file adapter expects directories in the configuration parameters to be in a format usual in Java programs. Therefore, enter paths in the form C:/path, even if you are using a Windows operating system. Enter the following parameters for the target file: Which directory do you want to save the file in? (Parameter file.targetDir) What name do you want to give the file? (Parameter file.targetFilename)

26-02-2004


121

Unit 4: Adapters

BIT400

Configuration in the Integration Directory: End Point

Figure 69: Directory: End Point

Create an end point for the receiver business system and the inbound interface in the Integration Directory under Receiver System End Points. The end point must be of the XI Connectivity type. Specify http://: as the URL. The values and must match the values XMB.httpPort= and XMB.httpService= from the configuration of the outbound file adapter. You can choose between the options Anonymous Logon and Apply Logon Data. Hint: If you want to select the option Apply Logon Data in the end point, there must be a user and a password saved in the local Adapter Engine. Save the user, password, and the logon language for the receiver business system and the inbound interface in the Integration Directory by choosing Receiver System Logon Data.

122


26-02-2004

BIT400


Configuring the Outbound File Adapter in the Integration Engine Prerequisites You have installed and started an Adapter Engine. You have logged on to the Adapter Engine by using a browser (http://:8200).

Procedure 1.

Reactivate a template for the outbound file adapter. Use this template to create a new file adapter.

2.

Check the Java class name for the outbound file adapter. Specify the class name as follows: classname=com.sap.aii.messaging.adapter.ModuleXMB2FILE.

3.

Configure a port number and a service in the file adapter to enable the Integration Server to reach this outbound file adapter. XMB.httpPort= XMB.httpService= specifies the HTTP server port that receives the messages from the Integration Engine. describes the service part of the address to which the Integration Engine has to send its messages. Example: XMB.httpPort=8210 XMB.httpService=/file/receiver

4.

Configure the specifications for file processing. The statements begin with file. and specify the file path and the file name. You can number the file names consecutively. If you want to save files on an FTP server and not in the file system, you need to make additional specifications. The statements begin with ftp. and contain specifications on the FTP server, the FTP port, authentication, and connection. For detailed information, see the documentation.

5.

The following sections deal with the specifications for converting an XML document to a sequential file.

6.

Save an XI Connectivity end point in the Integration Directory. Specify http://: as the URL. Example: http://p55555:8210/file/receiver

Configuration for a Target File in XML Format The Integration Server sends an XML document to the Adapter Engine. The XML document structure matches the corresponding inbound interface saved in the Integration Repository. The first step is to keep this structure and write it unchanged to an XML file. For this purpose, set the

26-02-2004


123

Unit 4: Adapters

BIT400

mode of the outbound file adapter to ’unchanged XML file’ by using the parameter mode=XMB2FILE. In this case you do not have to set parameters for the file structure in the file adapter.

Inbound Interface Analysis The target system software component expects an XML file in a particular format. The first step is to analyze the expected structure of the XML document. Ideally, get a DTD or an XML schema from the target system. To enable the outbound file adapter to save the XML file exactly as is expected, save the corresponding data types in the Integration Repository. The data types must define the structure of the XML document and contain identical fields. The central Integration Engine then sends an XML document with this structure to the file adapter. The file adapter generates one single file from this document and saves it in a directory.

Figure 70: Example: Target File in XML Format

Configuration in the Integration Repository Create data types, a message type, and an inbound message interface in the Integration Repository.

124


26-02-2004

BIT400


Figure 71: Repository: Data Type, Message Type, and Message

The following slide illustrates the structure of the objects.

Figure 72: Repository: Example

Create a data type for the line type. The fields should be character fields, since character strings are expected in the files. The field names determine the XML tags of the field names in the XML document at runtime. If the XML file contains multiple lines of the same line type, create another data type containing a field that is typed with the actual line type. Choose 0..unbounded for the Occurrence attribute. Create a message type that references this data type. The message type name determines the name of the corresponding XML tag in the XML document.

26-02-2004


125

Unit 4: Adapters

BIT400

Configuration for a Sequential Target File If you want to save the file in a directory as a sequential file, then it is the outbound file adapter that converts it. You have to specify the conversion rules by using configuration parameters that begin with xml.. Choose mode=XMBWITHCONVERSION for the mode.

Figure 73: Example: Sequential Target File

Configuration in the Integration Repository The outbound file adapter expects an XML file for the conversion, where the lines in an XML tag are placed between row tags. For this reason, you have to create an additional data type in addition to the data type for the actual line type, and reference it in the message type. This data type must contain a row element that is typed with the data type that describes the line type.

126


26-02-2004

BIT400


Figure 74: Data Type Structure

Configuration for Conversion in the Outbound File Adapter You can choose between four file types:

26-02-2004


127

Unit 4: Adapters

BIT400

Figure 75: Structure of the Sequential Target File

• • • •

Files with fields that are divided by separators and a heading containing the column names. Files with fields that are divided by separators and no heading. Files with fields that are written one after another without separators and a heading containing the column names. Files with fields that are written one after another without separators and no heading.

For information on configuration parameters, see the documentation.

128


26-02-2004

BIT400


Exercise 7: Configuring the File Adapter for an XML Target File Exercise Objectives After completing this exercise, you will be able to: • Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as an XML file

Business Example Your local PC has a local application with the software component SC_BIT_Travelsoft. This software component has an inbound interface for flight master data and expects the data as an XML file. The application has been assigned the name BS_BIT_TravelAgency_## as a business system. You want to transfer flight master data from an outbound IDoc interface to the XML structure that is expecting the software component by using SAP Exchange Infrastructure. You want to put an XML file in a directory by using the outbound file adapter.

26-02-2004


129

Unit 4: Adapters

BIT400

Task 1: Create all the objects that are required for an inbound interface in the Integration Repository. The structure of the interface must correspond to the requirements of an external application. Hint: This task is the same as task 1 in the exercise ’Configuring an Asynchronous Scenario with Two Different Interfaces and Mapping’. If you have already completed this exercise, check your objects and complete them if necessary. File Structure for the External Application Field Name

Meaning

Type Length; Detail

AirlineID

ID of airline

Char 3

ConnectionID


Char 4

FlightDate

Date of flight

Char 8; YYYYMMDD

FlightPrice



Currency

Currency ISO code

Char 3


Log on to the Integration Repository. Look at the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 that is used as the outbound interface. From the software component XI_Training_XX, choose Imported Objects → IDocs. Display the imported IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Which fields does the segment E1BPSFLREP contain? Which segment fields correspond to the fields required in the inbound interface? Field Name

Segment Field

AirlineID ConnectionID


130


26-02-2004

BIT400


FlightDate FlightPrice Currency 2.

Navigate to the software component SC_BIT400_TravelSoft. The namespace BIT400_## has been created for this exercise. Create a data type DT_BIT400_##, which contains the fields of the inbound interface. Save the data type.

3.

Create a message type msgT_BIT400_## in your namespace BIT400_## and reference your data type DT_BIT400_##. Save the message type.

4.

Create a message interface I_msgIF_BIT400_##. The interface is an asynchronous inbound interface and should reference the message type msgT_BIT400_## as the input message type. Save the message interface.

5.

Create a message mapping msgMap_BIT400_##. Reference the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the source structure and your message type msgT_BIT400_## as the target structure. Hint: To select the source or target structure, select the IDoc type or message type from the navigation tree and drag them to the relevant hand icon by using drag&drop. Define the structure mapping by selecting a field in the source structure and using drag&drop to drag it to the corresponding field in the target structure. Proceed as described for all remaining fields in the target structure. Also assign the segment E1SFL_SAVE to the node msgT_BIT400_##. Save the message mapping.

6.

Create an interface mapping IF_Map_BIT400_##. Select the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the outbound interface and your message interface I_msgIF_BIT400_## as the inbound interface. Enter your message mapping msgMap_BIT400_## as the mapping.

7.

Activate all objects you have created.


26-02-2004


131

Unit 4: Adapters

BIT400

Task 2: Write flight master data to an XML file by using your local Adapter Engine. Configure a new outbound file adapter and define a corresponding end point in the Integration Directory. 1.

Create a new outbound file adapter called Training##_file_outbound in your Adapter Engine. Use the template file_outbound.

2.

Create a subdirectory FilesXml. Place files in this directory with the name Training##_nnnn.xml. nnnn signifies a consecutive number. Which configuration parameters of the outbound file adapter are responsible for these settings? For information on the parameters, see the documentation.

3.

Configure the file adapter. Follow the procedure in ’Configuring the Outbound File Adapter in the Integration Engine’ and get the necessary configuration parameters from the documentation. Place the files in the directory that you created in 2. under Training##_nnnnn.xml. nnnnn signifies a consecutive number. Enter 8210 as the port that XI uses to reach the file adapter and /file/receiver## as the service. The mode for the file to be generated should be XML file. Save the configuration and start the adapter.

4.

Create an XI connectivity end point for your business system BS_BIT_TravelAgency_## and your inbound interface I_msgIF_BIT400_## in the Integration Directory, in the namespace BIT400_##. Make sure that the URL corresponds to your configurations for port and service. Select Anonymous Logon.

Task 3: Configure a scenario in the Integration Directory that sends flight master data from the outbound IDoc interface of the Travel_Agency_Summer business system to the BS_BIT_TravelAgency_## business system with the inbound interface I_msgIF_BIT400_## in the namespace BIT400_## by using your local file adapter. This receiver takes over from the receiver BS_BIT_TravelAgency. The data must only be distributed if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. 1.

Create an interface determination from the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 to the inbound interface I_msgIF_BIT400_## in the namespace BIT400_## in the Integration Directory. Enter your mapping IF_Map_BIT400_##.


132


26-02-2004

BIT400


2.

26-02-2004

Change your receiver determination. Delete the receiver BS_BIT_TravelAgency and add BS_BIT_TravelAgency_##. Create a routing condition that ensures that the data is only distributed if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. Save the settings and check whether the system finds your end point in the configurations by using the ’Refresh’ icon.


133

Unit 4: Adapters

BIT400

Solution 7: Configuring the File Adapter for an XML Target File Task 1: Create all the objects that are required for an inbound interface in the Integration Repository. The structure of the interface must correspond to the requirements of an external application. Hint: This task is the same as task 1 in the exercise ’Configuring an Asynchronous Scenario with Two Different Interfaces and Mapping’. If you have already completed this exercise, check your objects and complete them if necessary. File Structure for the External Application Field Name

Meaning

Type Length; Detail

AirlineID

ID of airline

Char 3

ConnectionID


Char 4

FlightDate

Date of flight

Char 8; YYYYMMDD

FlightPrice



Currency

Currency ISO code

Char 3


Log on to the Integration Repository. Look at the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 that is used as the outbound interface. From the software component XI_Training_XX, choose Imported Objects → IDocs. Display the imported IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Which fields does the segment E1BPSFLREP contain? Which segment fields correspond to the fields required in the inbound interface?


134


26-02-2004

BIT400


Field Name

Segment Field

AirlineID ConnectionID FlightDate FlightPrice Currency a)

2.

Segment Field

AirlineID

AIRLINEID

ConnectionID

CONNECTID

FlightDate

FLIGHTDATE

FlightPrice

PRICE

Currency

CURR_ISO

Navigate to the software component SC_BIT400_TravelSoft. The namespace BIT400_## has been created for this exercise. Create a data type DT_BIT400_##, which contains the fields of the inbound interface. Save the data type. a)

3.

Field Name

Expand the node SC_BIT400_TravelSoft → BIT400_## → Interface Objects → Data Types. Create a new data type by calling the context menu and choosing New.... Enter the name DT_BIT400_## and check that BIT400_## is entered for the namespace and SC_BIT400_TravelSoft for the software component version. Choose Create. You can enter a description on the next screen. Position the cursor on the DT_BIT400_## field and create new fields by using the icons with the green plus sign. For each new field enter a field name, the technical type, and, if required, detailed information.

Create a message type msgT_BIT400_## in your namespace BIT400_## and reference your data type DT_BIT400_##. Save the message type. a)

Under your namespace BIT400_##, choose Interface Objects then Message Types. Create a new message type by calling the context menu. Enter the name msgT_BIT400_## and enter a description. From the input help, select your data type DT_BIT400_## in the namespace BIT400_##. Continued on next page

26-02-2004


135

Unit 4: Adapters

BIT400

4.

Create a message interface I_msgIF_BIT400_##. The interface is an asynchronous inbound interface and should reference the message type msgT_BIT400_## as the input message type. Save the message interface. a)

5.

Under your namespace BIT400_##, choose Interface Objects then Message Interfaces. Create a new message interface by calling the context menu. Enter the name I_msgIF_BIT400_## and enter a description. Select the attributes Inbound and Asynchronous. In the Input Message Type field, call the input help and select your message type msgT_BIT400_##.

Create a message mapping msgMap_BIT400_##. Reference the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the source structure and your message type msgT_BIT400_## as the target structure. Hint: To select the source or target structure, select the IDoc type or message type from the navigation tree and drag them to the relevant hand icon by using drag&drop. Define the structure mapping by selecting a field in the source structure and using drag&drop to drag it to the corresponding field in the target structure. Proceed as described for all remaining fields in the target structure. Also assign the segment E1SFL_SAVE to the node msgT_BIT400_##. Save the message mapping. a)

Under your namespace BIT400_##, choose Mapping Objects then Message Mappings. Create a new message mapping by calling the context menu. Enter the name msgMap_BIT400_## and your namespace and choose Create. Enter a description. In the tree structure for the software component XI Training XX choose Imported Objects and select the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Drag the IDoc type to the hand icon in the source structure by using drag&drop. Next, drag your message type msgT_BIT400_## to the hand icon in the target structure by using drag&drop. For all remaining target structure fields, assign the appropriate source structure field to the corresponding target structure field by using drag&drop. Assign the segment E1SFL_SAVE to the root node of your target structure msgT_BIT400_## by using drag&drop.


136


26-02-2004

BIT400


6.

Create an interface mapping IF_Map_BIT400_##. Select the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 as the outbound interface and your message interface I_msgIF_BIT400_## as the inbound interface. Enter your message mapping msgMap_BIT400_## as the mapping. a)

7.

Under your namespace BIT400_##, choose Mapping Objects then Interface Mappings. Create a new interface mapping by calling the context menu. Enter the name IF_Map_BIT400_## and your namespace and choose Create. Create a short text and enter the outbound and inbound interface by using the input help. Alternatively, you can drag the interfaces to the hand icons by using drag&drop. Choose the Read Interfaces icon to display detailed information in the lower part of the screen. Use the input help for the Mapping Program field to select your message mapping, if you have already saved it.

Activate all objects you have created. a)

Navigate to the Change Lists tab page and activate your objects by calling the context menu and choosing Activate.

Task 2: Write flight master data to an XML file by using your local Adapter Engine. Configure a new outbound file adapter and define a corresponding end point in the Integration Directory. 1.

Create a new outbound file adapter called Training##_file_outbound in your Adapter Engine. Use the template file_outbound. a) b)

c)

Reactivate the template file_outbound for the outbound file adapter. Create a new file adapter by choosing Add New Adapter. Enter file_outbound as the template and select Training##_file_outbound as the name. Deactivate the template.


26-02-2004


137

Unit 4: Adapters

BIT400

2.

Create a subdirectory FilesXml. Place files in this directory with the name Training##_nnnn.xml. nnnn signifies a consecutive number. Which configuration parameters of the outbound file adapter are responsible for these settings? For information on the parameters, see the documentation. a) b)

c)

3.

Create the directory. In our solution example it is called c:/XI_Training/FilesXml. The configuration parameter file.targetDir=c:/XI_Training/FilesXml is responsible for the file name. If necessary, replace the directory with your directory name. The configuration parameter file.targetFilename=Training##.txt is responsible for the file name. You can number the files consecutively, separated from the file name by an underscore (_), by using the configuration parameter file.writeMode=addCounter file.counterSeparator=_ file.counterFormat=0000 file.counterStep=1 .

Configure the file adapter. Follow the procedure in ’Configuring the Outbound File Adapter in the Integration Engine’ and get the necessary configuration parameters from the documentation. Place the files in the directory that you created in 2. under Training##_nnnnn.xml. nnnnn signifies a consecutive number. Enter 8210 as the port that XI uses to reach the file adapter and


138


26-02-2004

BIT400


/file/receiver## as the service. The mode for the file to be generated should be XML file. Save the configuration and start the adapter. a)

Replace ## with your group number.

## File adapter java class classname=com.sap.aii.messaging.adapter.ModuleXMB2File

mode=XMB2FILE #Adress for XMB endpoint XMB.httpPort=8210 XMB.httpService=/file/receiver##

#File Adapter specific parameters file.createDir=1 # Replace ’c:/XI_Training/FilesXml’ by the complete path of the folder file.targetDir=c:/XI_Training/FilesXml file.targetFilename=Training##.txt file.writeMode=addCounter file.counterMode=immediately file.counterSeparator=_ file.counterFormat=0000 file.counterStep=1

4.

Create an XI connectivity end point for your business system BS_BIT_TravelAgency_## and your inbound interface I_msgIF_BIT400_## in the Integration Directory, in the namespace BIT400_##. Make sure that the URL corresponds to your configurations for port and service. Select Anonymous Logon. a)

Expand the Receiver System End Points node in the Integration Directory. Your business system should not be in the list yet. To create a new end point, choose New.. in the context menu for the Receiver System End Points node. From the input help, select your inbound interface I_msgIF_BIT400_## in the namespace BIT400_##. Choose Create to navigate to the detail view of the new end point. Enter a description. Select the addressing mode URL. Enter the URL that accesses your outbound file adapter. Select Anonymous Logon. Save and activate the end point.


26-02-2004


139

Unit 4: Adapters

BIT400

Task 3: Configure a scenario in the Integration Directory that sends flight master data from the outbound IDoc interface of the Travel_Agency_Summer business system to the BS_BIT_TravelAgency_## business system with the inbound interface I_msgIF_BIT400_## in the namespace BIT400_## by using your local file adapter. This receiver takes over from the receiver BS_BIT_TravelAgency. The data must only be distributed if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. 1.

Create an interface determination from the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 to the inbound interface I_msgIF_BIT400_## in the namespace BIT400_## in the Integration Directory. Enter your mapping IF_Map_BIT400_##. a)

b) 2.

Change your receiver determination. Delete the receiver BS_BIT_TravelAgency and add BS_BIT_TravelAgency_##. Create a routing condition that ensures that the data is only distributed if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. Save the settings and check whether the system finds your end point in the configurations by using the ’Refresh’ icon. a)

b)

140

Expand the Interface Determination for Outbound Interface node in the Integration Directory. Open the detail view for the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. To create a new interface determination, use the Create icon. Enter the business system Travel_Agency_Summer as the sender and the business system BS_BIT_TravelAgency_## as the receiver by using the input help, and select Create. Enter a description. From the input help, select your inbound interface I_msgIF_BIT400_## in the namespace BIT400_## and your interface mapping IF_Map_BIT400_##. Save and then activate.

To open the receiver determination for your scenario, double click it. Select the receiver BS_BIT_TravelAgency. To delete the receiver, select the icon with the red minus sign. To add a further receiver, select the icon with the green plus sign in the detail view for your receiver determination. Call the input help to select the receiver BS_BIT_TravelAgency_##. Using the input help for Condition takes you to the Condition Editor. To add a condition, choose the Insert Expression icon. Select the type Field Value and from the input help for segment EDI_DC40, select the field RCVPRN. Close the window with the IDoc structure by choosing OK. In the Value field enter LS_BIT_##. Close the conditions editor by choosing OK. Save and then activate.


26-02-2004

BIT400


Exercise 8: Configuring the File Adapter for a Sequential Target File Exercise Objectives After completing this exercise, you will be able to: • Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as a sequential file

Business Example Your local PC has a local application with the software component SC_BIT_TravelSoft. This software component has an inbound interface for flight master data and expects the data as a sequential file. The application has been assigned the name BS_BIT_TravelAgency_## as a business system. You want to use SAP Exchange Infrastructure to transfer flight master data from an outbound IDoc interface to an XML structure that is expecting all fields of the required file structure. You want the outbound file adapter to convert the XML data to a sequential file of the line structure expected by the software component. You want the outbound file adapter to place this sequential file in a directory.

Task 1: Write flight master data to a sequential file by using your local Adapter Engine. Configure a new outbound file adapter and define an end point in the Integration Directory. 1.

Check and complete the settings in the Integration Repository. Create a data type DT_BIT400_##_flat that contains a line row, which is typed with the data type DT_BIT400_##. Create a message type msgT_BIT400_##_flat that references this data type DT_BIT400_##_flat. Create an inbound interface I_msgIF_BIT400_##_flat that references this message type. Create a message mapping msgMap_BIT400_##_flat with the source structure FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 and the target structure msgT_BIT400_##_flat. Create an interface mapping IF_Map_BIT400_##_flat with the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01, the inbound interface I_msgIF_BIT400_##_flat, and the message mapping msgMap_BIT400_##_flat. Activate your objects.

2.

Create a new outbound file adapter called Training##_flatfile_outbound in your Adapter Engine. Use the template Training##_file_outbound. Continued on next page

26-02-2004


141

Unit 4: Adapters

BIT400

3.

Create a subdirectory Files. Place files in this directory with the name Training##_nnnnn.txt. nnnnn signifies a consecutive number. Which configuration parameters of the outbound file adapter are responsible for these settings? For information on the parameters, see the documentation.

4.

Configure the file adapter. Follow the procedure set out in ’Configuring the Outbound File Adapter in the Integration Engine’. Place the files in the directory that you created in 2. and name them Training##_nnnn.txt. Enter 8212 as the port that XI uses to reach the file adapter and /file/receiver## as the service. Save the configuration and start the adapter.

5.

Create an XI connectivity end point for your business system BS_BIT_TravelAgency_## and your inbound interface I_msgIF_BIT400_##_flat in the Integration Directory, in the namespace BIT400_##. Make sure that the URL corresponds to your configurations for port and service. Select Anonymous Logon.

Task 2: Configure a scenario in the Integration Directory that sends flight master data from the outbound IDoc interface of the Travel_Agency_Summer business system to the BS_BIT_TravelAgency_## business system with the inbound interface I_msgIF_BIT400_##_flat in the namespace BIT400_## by using your local file adapter. The data must only be distributed if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##.

142

1.

Create an interface determination from the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 to the inbound interface I_msgIF_BIT400_##_flat in the namespace BIT400_## in the Integration Directory. Enter your mapping msgMap_BIT400_##_flat.

2.

Check whether the system finds your interface determination and your end point in the configurations by using the Refresh icon in your receiver determination.


26-02-2004

BIT400


Solution 8: Configuring the File Adapter for a Sequential Target File Task 1: Write flight master data to a sequential file by using your local Adapter Engine. Configure a new outbound file adapter and define an end point in the Integration Directory. 1.

Check and complete the settings in the Integration Repository. Create a data type DT_BIT400_##_flat that contains a line row, which is typed with the data type DT_BIT400_##. Create a message type msgT_BIT400_##_flat that references this data type DT_BIT400_##_flat. Create an inbound interface I_msgIF_BIT400_##_flat that references this message type. Create a message mapping msgMap_BIT400_##_flat with the source structure FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 and the target structure msgT_BIT400_##_flat. Create an interface mapping IF_Map_BIT400_##_flat with the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01, the inbound interface I_msgIF_BIT400_##_flat, and the message mapping msgMap_BIT400_##_flat. Activate your objects. a)

2.

Use the solution example for task 1 of the exercise Configuring the Outbound File Adapter for an XML Target File.

Create a new outbound file adapter called Training##_flatfile_outbound in your Adapter Engine. Use the template Training##_file_outbound. a)

Follow the procedure set out in Configuring the Outbound File Adapter in the Integration Engine.


26-02-2004


143

Unit 4: Adapters

BIT400

3.

Create a subdirectory Files. Place files in this directory with the name Training##_nnnnn.txt. nnnnn signifies a consecutive number. Which configuration parameters of the outbound file adapter are responsible for these settings? For information on the parameters, see the documentation. a) b)

c)

4.

Create the directory. In the solution example it is called c:/XI_Training/Files. The configuration parameter file.targetDir=c:/XI_Training/Files is responsible for the directory name. If necessary, replace the directory with your directory name. The configuration parameter file.targetFilename=Training##.txt is responsible for the file name. You can number the files consecutively, separated from the file name by an underscore (_), by using the configuration parameter file.writeMode=addCounter file.counterSeparator=_ file.counterFormat=0000 file.counterStep=1.

Configure the file adapter. Follow the procedure set out in ’Configuring the Outbound File Adapter in the Integration Engine’. Place the files in the directory that you created in 2. and name them


144


26-02-2004

BIT400


Training##_nnnn.txt. Enter 8212 as the port that XI uses to reach the file adapter and /file/receiver## as the service. Save the configuration and start the adapter. a)

The configuration file should contain the following parameters:

# File adapter java class classname=com.sap.aii.messaging.adapter.ModuleXMB2File mode=XMB2FILEWITHCONVERSION #Adress for XMB endpoint XMB.httpPort=8212 XMB.httpService=/file/receiver##

#File Adapter specific parameters file.createDir=1 file.targetDir=c:/XI_Training Files file.targetFilename=Training##.txt #file.writeMode=append #file.writeMode=overwrite file.writeMode=addCounter file.counterMode=immediately #file.counterMode=afterFirst file.counterSeparator=_ file.counterFormat=0000 file.counterStep=1

##xml conversion properties if mode XMB2FILEWITHCONVERSION is specified xml.addHeaderLine=0 xml.fieldSeparator=; xml.endSeparator=:

5.

Create an XI connectivity end point for your business system BS_BIT_TravelAgency_## and your inbound interface I_msgIF_BIT400_##_flat in the Integration Directory, in the namespace BIT400_##. Make sure that the URL corresponds to your configurations for port and service. Select Anonymous Logon. a) b)

c)

d) e)

Log on to the Integration Directory. Navigate to the end point for your business system by choosing Receiver System End Points→ BS_BIT_TravelAgency_##. Double click to navigate to the detail view. Select Create and select the inbound interface I_msgIF_BIT400_##_flat from the input help in the namespace BIT400_##. Select the end point type XI-Connectivity. Enter the URL of your file adapter and select Anonymous Logon. Save and activate the end point.


26-02-2004


145

Unit 4: Adapters

BIT400

Task 2: Configure a scenario in the Integration Directory that sends flight master data from the outbound IDoc interface of the Travel_Agency_Summer business system to the BS_BIT_TravelAgency_## business system with the inbound interface I_msgIF_BIT400_##_flat in the namespace BIT400_## by using your local file adapter. The data must only be distributed if the RCVPRN field of the segment EDI_DC40 has the value LS_BIT_##. 1.

Create an interface determination from the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 to the inbound interface I_msgIF_BIT400_##_flat in the namespace BIT400_## in the Integration Directory. Enter your mapping msgMap_BIT400_##_flat. a) b)

c)

d)

e) 2.

Check whether the system finds your interface determination and your end point in the configurations by using the Refresh icon in your receiver determination. a)

b)

146

Log on to the Integration Directory. To navigate to the interface determination for the outbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01, choose Interface Determination for Outbound Interface→ FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01BIT400_## → . Double click on the node to navigate to the detail view. Choose Create. Enter Travel_Agency_Summer as the sender business system and BS_BIT_TravelAgency_## as the receiver business system. Choose Create. Enter a description and select your inbound interface I_msgIF_BIT400_##_flat from the input help in the namespace BIT400_##. Save and activate the interface determination.

Navigate to the receiver determination for the sender business system Travel_Agency_Summer by choosing Business Scenarios → BIT400_## → Receiver Determination → Travel_Agency_Summer. Double click to navigate to the detail view. Select the receiver BS_BIT_TravelAgency_## and use the Refresh icon to check whether the system finds your inbound interface I_msgIF_BIT400_##_flat in the namespace BIT400_##.


26-02-2004

BIT400


Lesson Summary You should now be able to: • Configure an outbound file adapter and describe the runtime procedure • Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as an XML file • Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as a sequential file

26-02-2004


147

Unit 4: Adapters

BIT400

Lesson: Inbound File Adapter Lesson Overview This lesson explains how to configure an inbound file adapter in the Adapter Engine. This can be done using XML files or sequential files as the source file and this lesson addresses both possibilities.


Configure an inbound file adapter and describe the runtime procedure Configure a scenario that reads an XML file from a directory and transfers it to the Integration Server pipeline as an XI-XML message Configure a scenario that reads a sequential file from a directory and transfers it to the Integration Server pipeline as an XI-XML message

Business Example You have a file as a data source and want to transfer the data to SAP Exchange Infrastructure by using the file adapter, so that the data can be sent to a target system as a message.

Inbound File Adapter Tasks

Figure 76: Configuration of the Inbound File Adapter

The inbound file adapter is installed in the external business system as part of the Adapter Engine. The inbound file adapter enables you to convert files to an XI-XML document and send them to the

148


26-02-2004

BIT400

Lesson: Inbound File Adapter

Integration Server (inbound adapter). To do this, the file adapter needs information about the structure, the name, and the directory of the file to be processed, as well as information for processing in the Integration Server. Therefore, you have to configure a file adapter for each scenario. The inbound file adapter has the following tasks: 1. 2. 3.

It searches at intervals (to be configured) in a directory for files with a particular naming convention. It reads the file and uses structure information about the file to generate an XML message that the Integration Server can process. The file adapter sends the XML file to the SAP Exchange Infrastructure Integration Server by HTTP(S) and transfers data about the outbound interface to be used and about the sender business system to the pipeline.

Defining Outbound File Interfaces in the Integration Repository A third-party software component gets data and writes it to a file. The data structure in the file is determined by the outbound interface of the software component. Ideally, you want to evaluate this file directly and transfer it to SAP Exchange Infrastructure without having to convert it into another data format. Therefore, you can define the data structure as an outbound interface in the Integration Repository.

Figure 77: Repository: Data Type, Message Type, and Message Interface

26-02-2004


149

Unit 4: Adapters

BIT400

Create a data type in the Integration Repository for each line type in the file. You can nest data types, if necessary. Then, reference the whole structure in a message type. Create an outbound message interface for each outbound interface. This outbound message interface references a message type and contains information on whether the interface is synchronous or asynchronous. The exact structure of the objects depends on the exact file structure and also on whether the file is a sequential file or an XML file. Therefore, the objects to be created are looked at in more detail in separate sections: ’Configurations for a Source File in XML Format’ and ’Configurations for a Sequential Source File’. The inbound file adapter sends the name of the message interface and the namespace where the message interface was created to the Integration Server pipeline. To configure an inbound file adapter, you therefore have to find out the name of this repository object.

Basic Configuration of the Inbound File Adapter Integration Server Specifications

Figure 78: Integration Server Specifications

Specify in the configuration file how the Adapter Engine reaches the Integration Server. URL of the Integration Server: You can find out the target URL in the Integration Server by calling transaction SXMB_ADM and choosing Configuration →Configuration Data (Integration Engine). Choose the Check icon. Assign the URL that you find in the System Landscape

150


26-02-2004

BIT400


to the parameter XMB.TargetURL. You can also determine the Integration Server dynamically from the SLD. For the parameters in this case, see the documentation. Logon data for the Integration Server: To log on to the Integration Server, enter a user and a password. The role SAP_XI_APPL_SERV_USER must be assigned to the user in the Integration Server. Assign the Integration Server client, the user, the password, and the logon language to the configuration parameters

26-02-2004


151

Unit 4: Adapters

BIT400

XMB.Client, XMB.User, XMB.Password, and XMB.Language. Information for the pipeline: For the Integration Engine pipeline, give the parameter XMB.SenderInterfaceName the name of the outbound message interface from the Integration Repository and the parameter XMB.SenderInterfaceNamespace the corresponding namespace. Also specify the name of the sender business system by using the configuration parameter XMB.SenderBusinessSystem. This must match a business system in the System Landscape Directory. You also have the option of entering the receiver business system by using the parameter XMB.ReceiverBusinessSystem. To determine how the message will be transferred, use the parameter XMB.QualityOfService.

Source File Specifications

Figure 79: Source File Specifications

Specify the following parameters for the source file: Source directory: Where is the file located? Specify the file path (file.sourceDir) and the file name (file.sourceFilename). The file name can also include wildcards. Processing mode: What happens to the file after it has been processed successfully? To determine this, use the parameter file.processingMode. You can either set the attribute to ’read only’ by using =setAttribute, delete the file by using =delete

152


26-02-2004

BIT400


, or copy the file to an archiving directory by using =archive. In this case, you also have to specify the archiving directory by using the parameter file.archiveDir. Poll interval: Use the parameter file.pollInterval to determine how often the file adapter attempts to read new files. Specify the interval in seconds. The file adapter can also get files from another server by using FTP. For these parameters, see the documentation.

Figure 80: File Structure

You can convert the sender document to an XML document if required. If the source file is a sequential file, you have to configure structure information.

26-02-2004


153

Unit 4: Adapters

BIT400

Configuring the Inbound File Adapter in the Integration Engine Prerequisites You have installed and started an Adapter Engine. You have logged on to the Adapter Engine by using a browser (http://:8200) and initialized a template for the inbound file adapter.

Procedure 1.

Reactivate a template for the inbound file adapter. Use this template to create a new file adapter.

2.

Check the Java class name for the inbound file adapter. Specify the class name as follows: classname=com.sap.aii.messaging.adapter.ModuleFILE2XMB.

3.

Configure the specifications for the Integration Server: XMB.TargetURL= XMB.Client= XMB.User= XMB.Password= XMB.Language= XMB.SenderInterfaceName= XMB.SenderInterfaceNamespace= XMB.SenderBusinessSystem= XMB.QualityOfService=EO . Check the user authorizations in the Integration Server. The user should be assigned the role SAP_XI_APPL_SERV_USER. You can use an Adapter Engine token for the password.

154

4.

Configure the specifications for file processing. The statements begin with file. and specify the file path, the file name, and the read access interval. If you want to save files on an FTP server and not in the file system, you need to make additional specifications. The statements begin with ftp. and contain specifications on the FTP server, the FTP port, authentication, and connection. For detailed information, see the documentation.

5.

The following sections deal with the specifications for converting an XML document.


26-02-2004

BIT400


Configurations for an XML Source File

Figure 81: Structure of an XML Source File

If the source file is in XML format, you do not need to configure any data on the file structure in the inbound file adapter. In this case, choose the mode Mode=FILE2XMB.

Figure 82: Structure of the Corresponding Data Type in the Repository

Create corresponding message types and data types in the Integration Repository. There must be a data type for each line type, with the same field names as the XML tags of the XML file fields. You can choose the name of this data type yourself. Create a message type that references this data type as well. The message type name determines the name of the corresponding XML tag.

26-02-2004


155

Unit 4: Adapters

BIT400

Configurations for a Sequential Source File

Figure 83: Structures of Sequential Source Files

The file adapter can read various formats from sequential files. Configure the file structure in the inbound file adapter. For details on the configuration parameters, see the documentation. You have to convert the sequential file to an XML file in each case. Choose the mode mode=FILE2XMBWITHROWCONVERSION. The file adapter uses the file data to generate an XML message. The structure of the data part of this message is depicted in the slide. - - LH 0400 20020525 666.0000 EUR A310-300

In this case, the tag for the message type is resultset and the fields are labeled with fieldn. You can rename the field names and the message type by using configuration parameters. Use the configuration parameter xml.structureTitle for the message type and xml.fieldNames for the field names. The result of using the following configuration file:

156


26-02-2004

BIT400


# file adapter java class classname=com.sap.aii.messaging.adapter.ModuleFile2XMB mode=FILE2XMBWITHROWCONVERSION XMB.TargetURL=http://:/sap/xi/engine?type=entry XMB.SenderBusinessSystem=BS_BIT_TravelAgency_## XMB.SenderInterfaceNamespace=BIT400_## XMB.SenderInterfaceName=O_msgIF_BIT400_##_flat

XMB.ContentKind=T XMB.ContentType=text/plain XMB.QualityOfService=EO XMB.User=XIAPPLUSER XMB.Password=xipass XMB.Client=800 XMB.Language=EN ##File Adapter specific parameters (example, see docu)

file.sourceDir=C:/ file.sourceFilename=*.txt

file.processingMode=archive file.archiveDir=C:/ file.pollInterval=20 xml.fieldSeparator=; xml.endSeparator=: xml.processHeaderLine=0 xml.processFieldNames=fromConfiguration xml.fieldNames=AirlineId;ConnectId;FlightDate;Price;Curr_ISO;Planetype:

is that an XML file in the following form is sent to the Integration Server: - - LH 0400 20020525 666.0000 EUR A310-300

26-02-2004


157

Unit 4: Adapters

BIT400

. To define this interface structure in the Integration Repository, create the following objects:

Figure 84: Data Type Structure

There must be a data type for each line type. The field names of the data type must be the same as the XML tags of the fields of the XML document that is transferred to the pipeline. You can choose the name of this data type yourself. Create another data type corresponding to the document structure. This data type should contain a line row, which is typed with the above line type. Create a message type that references this document data type as well. If you have not renamed the name in the file adapter, the name of the message type should be resultset.

158


26-02-2004

BIT400


Exercise 9: Configuring the Inbound File Adapter for an XML Source File Exercise Objectives After completing this exercise, you will be able to: • Configure a scenario that reads an XML file from a directory and transfers it to the Integration Server pipeline as an XI-XML message

Business Example Your local PC has a local application with the software component SC_BIT_TravelSoft. This software component has an outbound interface for flight master data and gets the data as an XML file. The application has been assigned the name BS_BIT_TravelAgency_## as a business system. You want to use SAP Exchange Infrastructure to transfer the flight master data to another system by using the inbound file adapter.

Task 1: Create all objects that are required for an outbound interface for the software component SC_BIT_TravelSoft in the Integration Repository. The interface structure should correspond to the following XML file: (Replace # with your group number). - LH 0400 20020525 666.0000 EUR

1.

Log on to the Integration Repository. Navigate to the software component SC_BIT_TravelSoft. The namespace BIT400_## has been created for this exercise. Check which objects you can use for the inbound interface and, if necessary, create the missing objects.


26-02-2004


159

Unit 4: Adapters

BIT400

2.

Is there a data type that has the same field name as the file?

3.

Is there a message type whose name matches the corresponding XML tag of the XML file? Does this message type reference the data type appropriate for the file?

4.

Is there an outbound interface that references this message type? If necessary, create a message interface O_msgIF_BIT400_## that references the data type in 3.

5.

Create any missing objects and activate all the objects you have created.

Task 2: Create an inbound file adapter in your local Adapter Engine that transfers an XML file containing flight master data to the Integration Server pipeline. 1.

Create an inbound file adapter Training##_xmlFile_inbound in your Adapter Engine. Use the file_inbound template. Navigate to the Edit mode in the configuration.

2.

Check the Java class name.

3.

Configure the access data for the Integration Server pipeline:


160


26-02-2004

BIT400


4.

Which URL takes you to the Integration Server? Which configuration parameter do you have to assign this information to?

5.

Which client do you have to log on to? Enter xiappluser as the user and xipass as the password and select the logon language. Which configuration parameters do you have to assign this information to?

6.

What is the sender business system called? What is the outbound interface called in the Integration Repository? Which namespace does it belong to? Which configuration parameters do you have to assign this information to?

7.

Create a XMLFiles subdirectory and an Archive subdirectory. You want the file adapter to look in the XMLFiles subdirectory every 60 seconds to check whether it contains any new files and transfer these files to XI. You want files that have been processed successfully to be written to the Archive directory. Which configuration parameters are responsible for this setting? Refer to the documentation.

8.

You do not have to configure any file structure data since the file is in XML format.

Task 3: Configure a scenario and test your inbound file adapter. If necessary, create a message mapping in the Integration Repository. 1.

Start the file adapter and check the log.

2.

If the log does not return any errors, copy a valid XML file to the source directory. Check the log again. Continued on next page

26-02-2004


161

Unit 4: Adapters

162

BIT400

3.

Check the inbound message in the monitor in the Integration Server.

4.

Optional: Configure a scenario to send your message to a business system and an outbound interface. Define a message mapping in the Integration Repository, if necessary.


26-02-2004

BIT400


Solution 9: Configuring the Inbound File Adapter for an XML Source File Task 1: Create all objects that are required for an outbound interface for the software component SC_BIT_TravelSoft in the Integration Repository. The interface structure should correspond to the following XML file: (Replace # with your group number). - LH 0400 20020525 666.0000 EUR

1.

Log on to the Integration Repository. Navigate to the software component SC_BIT_TravelSoft. The namespace BIT400_## has been created for this exercise. Check which objects you can use for the inbound interface and, if necessary, create the missing objects. a)

2.

Use the following questions:

Is there a data type that has the same field name as the file? Answer: The data type DT_BIT400_## should contain the same field names as the file. If this is not the case, then look at the XML file that you generated in the exercise for the outbound file adapter. The data type field names should be identical to the names in your file.

3.

Is there a message type whose name matches the corresponding XML tag of the XML file? Does this message type reference the data type appropriate for the file? Answer: There should be a message type msgT_BIT400_## that references the data type DT_BIT400_##.

4.

Is there an outbound interface that references this message type? If necessary, create a message interface O_msgIF_BIT400_## that references the data type in 3. Answer: There should not be any outbound asynchronous message interfaces in your namespace.


26-02-2004


163

Unit 4: Adapters

BIT400

5.

Create any missing objects and activate all the objects you have created. a)

b)

Create a message interface with ’outbound’ and asynchronous’ attributes. From the input help, select the message type msgT_BIT400_## in the namespace BIT400_##. Navigate to the Change Lists tab page and activate your objects by calling the context menu and choosing Activate.

Task 2: Create an inbound file adapter in your local Adapter Engine that transfers an XML file containing flight master data to the Integration Server pipeline. 1.

Create an inbound file adapter Training##_xmlFile_inbound in your Adapter Engine. Use the file_inbound template. Navigate to the Edit mode in the configuration. a) b)

c) 2.

Reactivate the template file_inbound for the inbound file adapter. Create a new file adapter by choosing Add New Adapter. Enter file_inbound as the template and select Training##_xmlFile_inbound as the name. Deactivate the template.

Check the Java class name. a) classname = com.sap.aii.messging.adapter. ModuleFile2XMB

3.

Configure the access data for the Integration Server pipeline: a) XMB.TargetURL= XMB.User=xiappluser XMB.Password=xipass XMB.Client=800 XMB.Language=EN XMB.SenderBusinessSystem=BS_BIT_TravelAgency_## XMB.SenderInterfaceNamespace=BIT400_## XMB.SenderInterfaceName=O_msgIF_BIT400_##


164


26-02-2004

BIT400


4.

Which URL takes you to the Integration Server? Which configuration parameter do you have to assign this information to? Answer: To find out the target URL, call transaction SXMB_ADM in the Integration Server and choose Configuration→ Configuration Data (Integration Engine). Choose the Check icon. Assign the URL that you find in the System Landscape to the parameter XMB.TargetURL.

5.

Which client do you have to log on to? Enter xiappluser as the user and xipass as the password and select the logon language. Which configuration parameters do you have to assign this information to? Answer: Assign this information to the configuration parameters XMB.User=xiappluser XMBPassword XMB.Client and XMB.Language.

6.

What is the sender business system called? What is the outbound interface called in the Integration Repository? Which namespace does it belong to? Which configuration parameters do you have to assign this information to? Answer: The sender business system is called BS_BIT_TravelAgency_##. The outbound interface is called O_msgIF_BIT400_## and belongs to the namespace BIT400_##.

7.

Create a XMLFiles subdirectory and an Archive subdirectory. You want the file adapter to look in the XMLFiles subdirectory every 60 seconds to check whether it contains any new files and transfer these files to XI. You want files that have been processed successfully to be written to the Archive directory. Which configuration parameters are responsible for this setting? Refer to the documentation. a)

8.

file.sourceDir=/xmlFiles file.sourceFilename=*.* file.processingMode=archive file.archiveDir=/Archive file.pollInterval=20

You do not have to configure any file structure data since the file is in XML format. a)

If no code page conversions are required, select the parameter XMB.ContentKind=B XMB.ContentType=application/xml .


26-02-2004


165

Unit 4: Adapters

BIT400

Task 3: Configure a scenario and test your inbound file adapter. If necessary, create a message mapping in the Integration Repository. 1.

Start the file adapter and check the log. a)

2.

If the log does not return any errors, copy a valid XML file to the source directory. Check the log again. a)

3.

b)

Log on to the Integration Server. Call transaction SXMB_MONI and start the monitor for processed XML messages. On the selection screen, enter BS_BIT_TravelAgency_## in the Sender Business System field and choose Execute to start the monitor. Navigate to the detail view of your message and check the message structure by choosing Inbound Message → Payloads → Main Document.

Optional: Configure a scenario to send your message to a business system and an outbound interface. Define a message mapping in the Integration Repository, if necessary. a)

166

To refresh the log, choose View Log again. If the file adapter has transferred the message to the pipeline successfully, the log displays the number of the XI message.

Check the inbound message in the monitor in the Integration Server. a)

4.

Choose Restart in the detail view of your file adapter. Next, check the log by choosing View Log.

Use the exercises on configuring a scenario for help.


26-02-2004

BIT400


Exercise 10: Configuring the Inbound File Adapter for a Sequential Source File Exercise Objectives After completing this exercise, you will be able to: • Configure a scenario that reads a sequential file from a directory and transfers it to the Integration Server pipeline as an XI-XML message

Business Example An external system delivers flight master data as a sequential file. You want to import this data to a system by using SAP Exchange Infrastructure.

Task 1: Create all objects that are required for an outbound interface for the software component SC_BIT400_TravelSoft in the Integration Repository. The interface structure should correspond to the following sequential file: File Structure for the External Application Field Name

Meaning

Type Length; Detail

AirlineID

ID of airline

Char 3

ConnectionID


Char 4

FlightDate

Date of flight

Char 8; YYYYMMDD

FlightPrice



Currency

Currency ISO code

Char 3

Transfer an XML document with the following structure to the Integration Server pipeline: - - LH 0400 20020525 666.0000 EUR

1.

26-02-2004

Log on to the Integration Repository. Navigate to the software component SC_BIT400_TravelSoft. The namespace BIT400_## has been created for this exercise. Check which objects you can use for the inbound interface and, if necessary, create the missing objects. Continued on next page


167

Unit 4: Adapters

BIT400

2.

Is there a data type that has the same fields as the file? Do the field lengths match the specifications for the sequential file?

3.

Is there a message type whose name matches the corresponding XML tag of the XML file? Does this message type reference the data type appropriate for the file?

4.

Is there an outbound interface that references this message type? If necessary, create a message interface O_msgIF_BIT400_## that references the data type in 3.

5.

Create any missing objects and activate all the objects you have created.

Task 2: Use either the sequential file containing flight master data that you created on your computer in the outbound file adapter exercise, or a sequential file provided by the instructor. Transfer this file to the Integration Server pipeline by using your inbound file adapter. Check the structure of the XI message. As an extra exercise you can set up a scenario that processes this XML message further and transfers it to a receiver business system by using an outbound adapter.

168


26-02-2004

BIT400


Solution 10: Configuring the Inbound File Adapter for a Sequential Source File Task 1: Create all objects that are required for an outbound interface for the software component SC_BIT400_TravelSoft in the Integration Repository. The interface structure should correspond to the following sequential file: File Structure for the External Application Field Name

Meaning

Type Length; Detail

AirlineID

ID of airline

Char 3

ConnectionID


Char 4

FlightDate

Date of flight

Char 8; YYYYMMDD

FlightPrice



Currency

Currency ISO code

Char 3

Transfer an XML document with the following structure to the Integration Server pipeline: - - LH 0400 20020525 666.0000 EUR

1.

Log on to the Integration Repository. Navigate to the software component SC_BIT400_TravelSoft. The namespace BIT400_## has been created for this exercise. Check which objects you can use for the inbound interface and, if necessary, create the missing objects. a)

2.

Use the following questions:

Is there a data type that has the same fields as the file? Do the field lengths match the specifications for the sequential file? Answer: The data type DT_BIT400_## should contain the same fields as the file, but with different field names. If this is not the case, then look at the XML file that you generated in the exercise for the outbound file adapter. The data type field names should be identical to the names in your file. Copy the data type to DT_BIT400_##_flat and change the field names. Continued on next page

26-02-2004


169

Unit 4: Adapters

BIT400

3.

Is there a message type whose name matches the corresponding XML tag of the XML file? Does this message type reference the data type appropriate for the file? Answer: There should be a message type msgT_BIT400_## that references the data type DT_BIT400_##. Create a message type msgT_BIT400_##_flat that references the data type DT_BIT400_##_flat.

4.

Is there an outbound interface that references this message type? If necessary, create a message interface O_msgIF_BIT400_## that references the data type in 3. Answer: There should not be any outbound asynchronous message interfaces in your namespace.

5.

Create any missing objects and activate all the objects you have created. a)

b)

Create a message interface with ’outbound’ and asynchronous’ attributes. From the input help, select the message type msgT_BIT400_##_flat in the namespace BIT400_##. Navigate to the Change Lists tab page and activate your objects by calling the context menu and choosing Activate.

Task 2: Use either the sequential file containing flight master data that you created on your computer in the outbound file adapter exercise, or a sequential file provided by the instructor. Transfer this file to the Integration Server pipeline by using your inbound file adapter. Check the structure of the XI message. As an extra exercise you can set up a scenario that processes this XML message further and transfers it to a receiver business system by using an outbound adapter.

170


26-02-2004

BIT400


Lesson Summary You should now be able to: • Configure an inbound file adapter and describe the runtime procedure • Configure a scenario that reads an XML file from a directory and transfers it to the Integration Server pipeline as an XI-XML message • Configure a scenario that reads a sequential file from a directory and transfers it to the Integration Server pipeline as an XI-XML message

26-02-2004


171

Unit 4: Adapters

BIT400

Lesson: IDoc Adapter Lesson Overview This lesson introduces the basic configuration of the IDoc adapter.


Import an IDoc type to the Integration Repository Check the IDoc-specific settings in the SLD Describe the structure of an IDoc as an XML message in the pipeline

Business Example You want to implement scenarios containing an IDoc interface of an SAP system by using SAP Exchange Infrastructure.

The IDoc Adapter The IDoc adapter is installed on the Integration Server. It consists of an inbound adapter and an outbound adapter. An SAP system with an IDoc outbound interface can send an IDoc to the inbound IDoc adapter by using tRFC. The inbound IDoc adapter generates an IDoc-XML from the IDoc and transfers it to the pipeline of the Integration Server. If you want to transfer an XML document to an inbound IDoc interface of an SAP system by using the IDoc adapter, the outbound IDoc adapter generates an IDoc from the XML document and sends it to the target system by using tRFC.

Figure 85: IDoc Adapter

172


26-02-2004

BIT400

Lesson: IDoc Adapter

System Landscape In addition to the business system, you also have to save a logical system name for all technical systems involved in an IDoc scenario. For SAP systems, this logical system name must be identical to the entry in the client table.

Figure 86: Logical System Name and Business System

26-02-2004


173

Unit 4: Adapters

BIT400

Checking the Logical System Name 1.

Access the following data for an SAP application system: SystemID and client. Log on to the system and client.

2.

To determine the logical system name of the client, call transaction SALE. Choose Application Link Enabling (ALE) → Sending and Receiving Systems → Logical Systems → Assign Client to Logical System. This takes you to the screen showing the clients installed in the system. Select your client and choose Details. The assigned logical system name appears in the Logical System field. Hint: You are not permitted to change the logical system name later on during client maintenance, as inconsistencies could arise. If, however, you need to make a change, consult the notes in the documentation under Application Link Enabling (ALE) → Sending and Receiving Systems → Logical Systems → Convert Logical System Names in Application Tables in transaction SALE.

3.

Log on to the System Landscape Directory. To check the settings of the technical systems, see Technical Landscape. Choose SAP Systems and select the link with the SystemID you have determined. Select the link with the client number. This takes you to the detailed view for clients. Enter the name that you determined in 2. in the Logical System Name field.

Design Time: IDoc Types An IDoc type contains information on how the IDoc is structured. This includes the definition of segment types as line types and information on where a line of a particular line type can or must be present in the IDoc. Each segment type consists of fields, which are typed with a data element from the ABAP Dictionary.

174


26-02-2004

BIT400


Figure 87: IDoc Type: Basic Structure

For detailed information on an IDoc type, call transaction WE60 or look in the Interface Repository http://ifr.sap.com.

Figure 88: Segment Type

To configure a scenario with an IDoc interface of an SAP software component in SAP Exchange Infrastructure, you have to import the software component and the IDoc type for the software component to the Integration Repository. Name the XML-IDoc type by using the naming convention (MessageType).(IDocType).(Enhancement). For SAP standard IDoc types, the last element .(Enhancement) is omitted. The IDoc type is saved as an XML schema in this case.

26-02-2004


175

Unit 4: Adapters

BIT400

Figure 89: IDoc Type in the Integration Repository

If an IDoc type is not yet in the Integration Repository, you can import it from an SAP system. It is a prerequisite that the software component version to which the IDoc belongs is imported to the Integration Repository.

Figure 90: Importing an IDoc Type to the Integration Repository

In interface mapping you can reference the IDoc types both as an outbound interface (as an alternative to an outbound message interface) and as an inbound interface (as an alternative to an inbound message interface).

176


26-02-2004

BIT400


Figure 91: Using IDoc Types in Interface Mapping

In message mapping you can reference the IDoc type as a source structure and as a target structure as an alternative to a message type.

Figure 92: Using IDoc Types in Message Mapping

26-02-2004


177

Unit 4: Adapters

BIT400

If you want to define a message mapping from a message type to an IDoc type, note the following: • • •

178

An optional segment is only constructed if a mapping exists from a source field to the segment. Each segment has an attribute Segment=, which should have a value of 1. You can do this by assigning a constant. You are only permitted to use character fields in an IDoc type, that is string type fields. If the source structure contains other types, you must make sure they are converted correctly.


26-02-2004

BIT400


Importing an IDoc Type Prerequisites The software component and the version containing the IDoc type must be maintained in the SLD and assigned to a product version. This product must be assigned to the technical system and the software component version must be selected as the installed software component. This product must be selected as the installed product in the corresponding business system. Finally, the software component version must be imported from the SLD to the Integration Repository.

Procedure 1.

Select the software component that you want to import an IDoc type to. Check the settings for the software component version. Make sure the attribute Import of RFC and IDoc Interfaces from SAP Systems Permitted is selected and that the connection data for importing from the SAP system is maintained.

2.

Under the Imported Objects node choose Import RFC/IDoc from the context menu.

3.

Enter a valid user and password and choose Continue.

4.

Expand the node External IDoc and select one or more IDocs. Choose Continue.

5.

Check your selection and import the IDoc types by using the Start icon.

Runtime: IDocs and IDoc-XML Messages The monitor for XI messages has a few distinctive features for IDocs. The SOAP header contains an additional entry IDocInbound (or IDocOutbound), where you can find values from the IDoc control record. The data itself is located in the MainDocument of the payload. The payload contains an additional attachment Context, which lists some important fields of the control record. This information can be used for context type routing conditions.

26-02-2004


179

Unit 4: Adapters

BIT400

Figure 93: IDoc-XML Document in the Monitor

The payload contains information about the control record as well as data records. An attribute segment with value 1 is assigned to each segment tag.

Figure 94: IDoc-XML: Payload Main Document

You can display the XI messages that have been received or sent using the IDoc adapter by using the SAP adapter monitor (transaction IDX5). You can use this monitor to navigate to the XI monitor for a special message.

180


26-02-2004

BIT400


Figure 95: SAP Adapter Monitor

26-02-2004


181

Unit 4: Adapters

182

BIT400


26-02-2004

BIT400


Exercise 11: IDoc Adapter Exercise Objectives After completing this exercise, you will be able to: • Check the IDoc-specific settings in the SLD • View an IDoc in the back-end system by using the IDoc monitor

Business Example You want to connect SAP systems with IDoc interfaces to SAP Exchange Infrastructure. You also want to ensure that the configurations in the SLD and in the Integration Repository are complete.

Task 1: Determine the logical system names of the clients 811 and 821 and compare these with the settings in the SLD. 1.

Log on to client 811. In transaction SALE you can find detailed information on a client by choosing Application Link Enabling (ALE) → Sending and Receiving Systems → Logical Systems → Assign Client to Logical System. In the detail view, navigate to clients 811 and 821. What are the logical system names?

2.

Log on to the SLD. Which technical system belongs to the SAP system from step 1? Which logical system name is entered for clients 811 and 821?

Task 2: In the sender system (client 811), navigate to the IDoc monitor (transaction BD87) and view the IDocs that you have generated. On the selection screen, filter according to the partner number LS_BIT_##.

26-02-2004

1.

Log on to client 811 and call transaction BD87. On the selection screen, enter the value LS_BIT_## in the Partner System field and correct the time period for IDoc creation, if necessary. Start the monitor by choosing Execute. How many IDocs are generated?

2.

Navigate to the list of IDocs with status Data Passed to Port OK by double clicking on it. Double click on an IDoc number to navigate to the detail view of an IDoc. Which segments does the IDoc have?


183

Unit 4: Adapters

BIT400

Solution 11: IDoc Adapter Task 1: Determine the logical system names of the clients 811 and 821 and compare these with the settings in the SLD. 1.

Log on to client 811. In transaction SALE you can find detailed information on a client by choosing Application Link Enabling (ALE) → Sending and Receiving Systems → Logical Systems → Assign Client to Logical System. In the detail view, navigate to clients 811 and 821. What are the logical system names? a)

2.

The logical system name for client 811 is TRAVSUMMER and for client 821 is TRAINING.

Log on to the SLD. Which technical system belongs to the SAP system from step 1? Which logical system name is entered for clients 811 and 821? a) b)

c)

The technical system corresponds to the system ID of the training system. Navigate to the detail view by using the link with the name of the technical system. Select client 811. The logical system name TRAVSUMMER is entered here. It must be the same as the logical system name that you determined in 1. Next select client 821. The logical system name TRAINING is entered here. It must be the same as the logical system name that you determined in 1.

Task 2: In the sender system (client 811), navigate to the IDoc monitor (transaction BD87) and view the IDocs that you have generated. On the selection screen, filter according to the partner number LS_BIT_##. 1.

Log on to client 811 and call transaction BD87. On the selection screen, enter the value LS_BIT_## in the Partner System field and correct the time period for IDoc creation, if necessary. Start the monitor by choosing Execute. How many IDocs are generated? a)

The IDocs that have been successfully transferred to the tRFC port have the status Data Passed to Port OK.


184


26-02-2004

BIT400


2.

Navigate to the list of IDocs with status Data Passed to Port OK by double clicking on it. Double click on an IDoc number to navigate to the detail view of an IDoc. Which segments does the IDoc have? a)

26-02-2004

Double click on the name of the message type FLIGHT_SAVEREPLICA to navigate to the IDoc list. Double click on an IDoc number to get to the IDoc display. Expand the node Data Records. You will find the IDoc segments here.


185

Unit 4: Adapters

BIT400

Lesson Summary You should now be able to: • Import an IDoc type to the Integration Repository • Check the IDoc-specific settings in the SLD • Describe the structure of an IDoc as an XML message in the pipeline

186


26-02-2004

BIT400

Lesson: Inbound IDoc Adapter

Lesson: Inbound IDoc Adapter Lesson Overview This lesson explains which configurations are necessary to send a message as an IDoc from an SAP system to SAP Exchange Infrastructure and transfer it to the pipeline by using the inbound IDoc adapter.


Configure an inbound IDoc adapter and describe the runtime procedure

Business Example You want to transfer a message from an SAP system to the SAP Exchange Infrastructure pipeline by using an IDoc interface.

Inbound IDoc Adapter: Overview The inbound IDoc adapter is installed on the Integration Server, receives an IDoc from an application system, converts it into an XI-XML document and transfers it to the pipeline.

Figure 96: Inbound IDoc Adapter

Correct maintenance of the technical system and the business system in the System Landscape Directory is a prerequisite for communication between an application system and the Integration Server by using the inbound IDoc adapter. In SAP systems each client is assigned a logical system name. This must be identical to the entry in the System Landscape Directory. The IDoc Adapter lesson describes the settings for the SLD in more detail.

26-02-2004


187

Unit 4: Adapters

BIT400

Figure 97: Logical System and Business System

Configuration in the Sender System

Figure 98: Distribution Model

During ALE processing, information on which logical systems will receive IDocs for a particular message type is saved in the distribution model. Call transaction BD64 to check which distribution models are installed.

188


26-02-2004

BIT400


Figure 99: Outbound Partner Profile

You have to maintain an outbound partner profile for each outbound IDoc interface. This controls when an IDoc is sent and which port it uses. In the case of the tRFC port this determines which RFC destination is used to send the document. To check the partner profile in the sender system, call transaction WE20. Expand the node LS → for the logical system that is entered in the distribution model as the target system. Choose Outbound Parameters and select the line containing the message type that is entered in the distribution model, and select Detail. The Basis Type field contains the name of the IDoc type that describes the IDoc structure. You have the option to enter an enhancement of the standard IDoc type in the Enhancements field. The name of the IDoc type that is imported to the Integration Repository follows the naming convention (MessageType).(BasisType).(Enhancement). The Receiver Port field contains the name of the port. Double click on this name to navigate to the detail view of the port. In the case of tRFC ports the RFC Destination field contains the RFC destination that is used to send the document. Double click on the name to navigate to the detail view of the RFC destination. The Target Host field must contain the server and the client of the Integration Server as well as a valid name and password.

26-02-2004


189

Unit 4: Adapters

BIT400

Figure 100: Runtime Procedure: ALE Outbound Processing

If you start a program that generates IDocs, first of all an internal table is constructed (the master IDoc), which is then transferred to the ALE level. The ALE level determines the valid receiver or receivers and saves an IDoc for each of them in the database. The IDoc is either transferred to the tRFC layer immediately or gathered in the database, depending on the setting in the partner profile. The next step is to start sending the IDocs by using a background program.

Figure 101: IDoc Monitor (BD87): Display IDoc

190


26-02-2004

BIT400


You can check the sent IDocs by using the IDoc monitor (transaction BD87).

Configuration in the Integration Server The current metadata of the IDoc type must be available to the Integration Server (this metadata also contains information that is irrelevant for the Integration Repository). For example, the names of the data elements and the segment types are required. For this reason there is a special cache on the Integration Server, which saves the IDoc metadata. To view these values, call transaction IDX2.

Figure 102: Configuration in the Integration Server

You can save a port with an RFC destination for each SAP application system by calling transaction IDX1. If the metadata is not in the cache, the Integration Server reads it automatically from this port.

26-02-2004


191

Unit 4: Adapters

BIT400

Figure 103: Runtime Procedure in the IDoc Adapter

If the Integration Server receives an IDoc, it is transferred automatically to the inbound IDoc adapter if the system is configured as the Integration Server. To check this customizing setting, call transaction SXMB_ADM, choose Integration Engine→ Configuration → Configuration Data (Integration Engine) and check the Role of Business System field. The IDoc data is then used to generate an IDoc-XML document. The current metadata of the IDoc type is required for this purpose. If the metadata for the sender system contained in the control record and for the IDoc type is not present, it is determined once more using the RFC destination that is maintained in transaction IDX1. To construct the XI-SOAP document, the logical system names must be converted to business systems. The information you need to do this is cached in the table SAILCRBSC and determined from the SLD, if necessary. To check which business systems are assigned to which logical systems in the cache, call transaction SXI_CACHE and choose Goto → Business Systems. The inbound IDoc adapter saves the XI-SOAP document in the database and transfers it to the Integration Server pipeline.

192


26-02-2004

BIT400


Figure 104: SAP Adapter Monitor (IDX5)

The following IDoc-specific information is located in the SAP adapter monitor (transaction IDX5) for inbound IDocs: • • •

The IDoc number from the source system, in the Reference Number field. The transaction ID of the transactional RFCs from the sender system, in the Transaction ID field. The ID of the generated XI message, in the Message ID field.

Double click the message ID to navigate to the monitor for processed XML messages.

26-02-2004


193

Unit 4: Adapters

194

BIT400


26-02-2004

BIT400


Exercise 12: Checking the Configuration for the Inbound IDoc Adapter Exercise Objectives After completing this exercise, you will be able to: • Check the settings that are required to connect a sender SAP system to XI by using an IDoc Adapter

Business Example You want to process an IDoc from an SAP system by using SAP XI. This requires configurations on the sender SAP system and on the Integration Server.

Task 1: Check the settings in the sender system (TA8, Client 811). 1.

Log on to the sender system. Determine the logical system name for the sender system.

2.

Check whether a distribution model has been created, which distributes data on the business object Flight and the BAPI SaveReplica to the logical system LS_BIT_##. To determine the corresponding message type, double click on Flight.SaveReplica.

3.

Check which RFC destination is used to send the IDocs for your partner LS_BIT_## and for the message type FLIGHT_SAVEREPLICA. Navigate forward from the partner profile to the transaction WE20 by double clicking. Expand the tree by choosing Partner Profiles→ Partner Type LS → LS_ BIT## and select your logical target system LS_BIT_##. Click on the message type FLIGHT_SAVEREPLICA in the Outbound Parameters table to navigate to the detail view. Double click on the name of the port to navigate to the detail view of the port. The RFC destination is referenced here. Double click to navigate to the detail view of the RFC destination. Which system and which client does the RFC destination show? What is the RFC destination type? Test the RFC destination.

Task 2: Check the configurations in the Integration Server (client 800). 1.

Log on to the Integration Server. Check in transaction SXMB_ADM whether the client is configured as the Integration Server. Continued on next page

26-02-2004


195

Unit 4: Adapters

BIT400

2.

Check whether the metadata for the training system and the IDoc type FLIGHT_SAVEREPLICA01 are available.

3.

Check whether a business system is entered in the cache (transaction SXI_CACHE) for the SAP system of the training system and for client 811.

Task 3: Check the settings in the Integration Repository. 1.

196

Check whether the IDoc type FLIGHT_SAVEREPLICA01 for the message type FLIGHT_SAVEREPLICA has been imported to the Integration Repository for the software component XI Training XX. View the structure of the IDocs. What is the corresponding namespace?


26-02-2004

BIT400


Solution 12: Checking the Configuration for the Inbound IDoc Adapter Task 1: Check the settings in the sender system (TA8, Client 811). 1.

Log on to the sender system. Determine the logical system name for the sender system. a)

2.

Check whether a distribution model has been created, which distributes data on the business object Flight and the BAPI SaveReplica to the logical system LS_BIT_##. To determine the corresponding message type, double click on Flight.SaveReplica. a)

3.

To determine the logical system name of the client, call transaction SALE. Choose Application Link Enabling (ALE) → Sending and Receiving Systems → Logical Systems → Assign Client to Logical System. This takes you to the screen showing the clients installed in the system. Select your client and choose Details. The assigned logical system name TRAVSUMMER appears in the Logical System field.

Transaction BD64 takes you to the maintenance screen for distribution models. Here you should find a view of the distribution model with the technical name TRAINING##, which transfers data on the business object Flight and the BAPI SaveReplica from the logical system TRAVSUMMER to the logical system LS_BIT_##. Double click on Flight.SaveReplica to display the message type FLIGHT_SAVEREPLICA corresponding to this BAPI.

Check which RFC destination is used to send the IDocs for your partner LS_BIT_## and for the message type FLIGHT_SAVEREPLICA. Navigate forward from the partner profile to the transaction WE20 by double clicking. Expand the tree by choosing Partner Profiles→ Partner Type LS → LS_ BIT## and select your logical target system LS_BIT_##. Click on the message type FLIGHT_SAVEREPLICA in the Outbound Parameters table to navigate to the detail view. Double click on the name of the port to navigate to the detail view of the port. The RFC destination is referenced here.


26-02-2004


197

Unit 4: Adapters

BIT400

Double click to navigate to the detail view of the RFC destination. Which system and which client does the RFC destination show? What is the RFC destination type? Test the RFC destination. a)

The receiver port BIT400 is entered in the detail view of the outbound partner profile for the message type FLIGHT_SAVEREPLICA. Double click on the name of the port to navigate to the detail view of the port. The RFC destination IntegrationServer is entered here. Double click on the name of the RFC destination to navigate to the detail view of the RFC destination. The destination is of „R/3 Connection type. On the tab page Technical Settings you will find the name of the target host, and on the tab page Logon/Security you will find the target client as well as the user and password. You can check the functional efficiency of the destination in the detail view of the RFC destination by choosing Test Connection and Remote Login.

Task 2: Check the configurations in the Integration Server (client 800). 1.

Log on to the Integration Server. Check in transaction SXMB_ADM whether the client is configured as the Integration Server. a)

2.

Check whether the metadata for the training system and the IDoc type FLIGHT_SAVEREPLICA01 are available. a)

3.

Client 800 is configured as the Integration Server. Call transaction SXMB_ADM and choose Integration Engine → Configuration → Configuration Data (Integration Engine). The entry for the Role of the Business System field is Integration Server.

Check the metadata in the IDoc adapter by calling transaction IDX2. To find the IDoc types that are already in the cache, look under the node SAP.

Check whether a business system is entered in the cache (transaction SXI_CACHE) for the SAP system of the training system and for client 811. a)

Call transaction SXI_CACHE. Choose Goto → Business Systems to view the data for converting to a business system. The business system name is Travel_Agency_Summer and the logical system name is TRAVSUMMER for client 811.


198


26-02-2004

BIT400


Task 3: Check the settings in the Integration Repository. 1.

Check whether the IDoc type FLIGHT_SAVEREPLICA01 for the message type FLIGHT_SAVEREPLICA has been imported to the Integration Repository for the software component XI Training XX. View the structure of the IDocs. What is the corresponding namespace? a)

26-02-2004

Log on to the Integration Repository. In the software component XI Training XX with component version 2.0, if you choose Imported Objects → IDocs you will find the entry FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Double click on this entry to open the detail view. The corresponding namespace is „urn:sap-com:document:sap:idoc:messages.


199

Unit 4: Adapters

BIT400

Lesson Summary You should now be able to: • Configure an inbound IDoc adapter and describe the runtime procedure

200


26-02-2004

BIT400

Lesson: Outbound IDoc Adapter

Lesson: Outbound IDoc Adapter Lesson Overview This lesson describes which configurations are required to send a message to an SAP System as an IDoc by using the outbound IDoc adapter.


Configure an outbound IDoc adapter and describe the runtime procedure Describe the distinctive features of an XI-IDoc-XML message

Business Example You want to transfer a message to an IDoc interface of an SAP system by using SAP Exchange Infrastructure. You want to use the IDoc adapter to implement this scenario.

Outbound IDoc Adapter: Overview The outbound IDoc adapter is installed on the Integration Server. It can convert an XI-XML document to an IDoc and send it by tRFC to an application system.

Figure 105: Outbound IDoc Adapter: Overview

Configuration in the SLD Correct maintenance of the technical system and the business system in the System Landscape Directory is a prerequisite for communication between the Integration Server and an application system by using the outbound IDoc adapter. In SAP systems each client is assigned a logical system name. This must be identical to the entry in the System Landscape Directory. The IDoc processing lesson describes the settings for the SLD in more detail.

26-02-2004


201

Unit 4: Adapters

BIT400

Figure 106: Configuration in the SLD

Hint: You have to assign a logical system name to the sender system in the SLD in any case. This also applies to systems that do not send IDocs. The outbound IDoc adapter uses this configuration to convert the name of the sender business system to a logical sender system name. This information is required for the ALE processing of the receiver system.

Configuration in the Integration Server

202


26-02-2004

BIT400


Configuration in the Integration Directory You have to create an IDoc adapter end point in the Integration Directory. Maintain the following fields: • •

•

•

•

RFC Destination: Enter the RFC destination which will be used to send the IDoc to the target system. Segment Version: In the case of third-party systems, enter the release for which the IDoc type has been released, so that the relevant segment version can be used. Interface Version: Enter the IDoc record types. The namespace for development object names was enhanced for Release 4.0. If the target system is a lower release than 4.0, choose SAP Release 3.0/3.1. If the release is 4.0 or higher, select SAP Release 4.0 or higher. Port: Enter the IDX1 port that is used to read the metadata from the target system. The port is named according to the naming convention SAP. SAP Release: Enter the release of the target system. This information is necessary to ensure that the correct function modules are used for reading the metadata.

IDoc Adapter Configuration in the Integration Server The current metadata of the IDoc type must be available to the Integration Server (this metadata also contains information that is irrelevant for the Integration Repository). For example, the names of the data elements and the segment types are required. For this reason there is a special cache on the Integration Server, which saves the IDoc metadata. You can view these values by calling transaction IDX2.

26-02-2004


203

Unit 4: Adapters

BIT400

Figure 107: Configuration in the Integration Server

You can save a port with an RFC destination for each SAP application system by calling transaction IDX1. If the metadata is not in the cache, the Integration Server reads it automatically from this port. Hint: If an IDoc is sent from the Integration Server to an application system, you have to save the port that you want to use to compare the metadata in the Integration Directory in the corresponding end point. You also have to enter the release of the target system in the SAP Release field.

204


26-02-2004

BIT400


Runtime Procedure

Figure 108: Runtime Procedure in the Outbound IDoc Adapter

If the pipeline determines an end point of IDoc adapter type during technical routing, the XI message is transferred to the outbound IDoc adapter after mapping. The logical system name corresponding to the business system is determined in the IDoc adapter. If there is no entry in the cache, the IDoc adapter reads this information from the SLD. For this reason you have to maintain the logical system name in the SLD for the target system. The XI message is converted to an IDoc by using the IDoc metadata. A new IDoc number is assigned in the Integration Server. This IDoc number is in the SAP Adapter Monitor in the Reference Number field. If the metadata for the IDoc type are not in the cache, the IDoc adapter reads them using RFC with the RFC destination that is saved to the IDX1 port. The IDoc is then sent to the target system by tRFC.

Configuration in the Target System You have to maintain the inbound partner profile for the message type that is sent with the IDoc in the control record in the target system. You can check the settings by calling transaction WE20.

26-02-2004


205

Unit 4: Adapters

BIT400

Figure 109: Configuration in the Target System

Figure 110: Runtime Procedure: ALE Inbound Processing in the Target System

Expand the navigation tree by choosing Partner Profiles → Partner Type LS → and select the logical system of the sender. Double click on the message type in the inbound parameter table to navigate to the detail view for inbound processing configuration. The process code determines which function module or workflow task processes the IDoc.

206


26-02-2004

BIT400


Exercise 13: Checking the Configuration for the Outbound IDoc Adapter Exercise Objectives After completing this exercise, you will be able to: • Check the settings that are required to send a message as an IDoc from SAP Exchange Infrastructure to a receiver SAP system

Business Example You want to generate an IDoc from a message from SAP Exchange Infrastructure by using the outbound IDoc adapter and send it to an SAP system. To do this you have to make configuration settings in the Integration Server and in the receiver SAP system.

Task 1: Check the settings in the Integration Directory. 1.

Open the configuration object End Point for the receiver system Training. Which inbound interface has an IDoc adapter end point?

2.

Look at the end point for the inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Which RFC destination does the outbound IDoc adapter use to send the IDoc to the target system? Note the name of the RFC destination. Which RFC destination is used to read the IDoc metadata from the outbound IDoc adapter?

Task 2: Check the settings in the Integration Server. 1.

Check which SAP system and which client the RFC destination that you determined in task 1, step 2b, takes you to, by calling transaction SM59.

2.

Check whether the metadata for the training system and for the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 are entered, by calling transaction IDX2. vorhanden sind.

26-02-2004


207

Unit 4: Adapters

BIT400

Solution 13: Checking the Configuration for the Outbound IDoc Adapter Task 1: Check the settings in the Integration Directory. 1.

Open the configuration object End Point for the receiver system Training. Which inbound interface has an IDoc adapter end point? a)

2.

Log on to the Integration Directory and choose Receiver System End Points. Double click on the business system Training to display a list with an overview of the end points for this receiver system, if more than one end point has been created. The inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 has an end point of IDoc adapter type.

Look at the end point for the inbound interface FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01. Which RFC destination does the outbound IDoc adapter use to send the IDoc to the target system? Note the name of the RFC destination. Which RFC destination is used to read the IDoc metadata from the outbound IDoc adapter? a) b) c)

Double click to navigate to the detail view of an end point. The IDoc is sent using the RFC destination that is entered in the RFC Destination field. The metadata is read using the RFC destination that is saved in the port that is entered in the Port field. For detailed information, call transaction IDX1 in client 800. Here you will find this port, which references a RFC destination.

Task 2: Check the settings in the Integration Server. 1.

Check which SAP system and which client the RFC destination that you determined in task 1, step 2b, takes you to, by calling transaction SM59. a)

Call transaction SM59 to navigate to the maintenance screen for RFC destinations. The destination you are looking for is of „R/3 Connection type. To find the client, navigate to the detail view for the RFC destination, choose the Logon/Security tab page and look in the Client field. To find the target system, choose the Technical Settings tab page and look in the Target Host field. If this field is empty, the RFC destination in the specified client leads to the same SAP system. Continued on next page

208


26-02-2004

BIT400


2.

Check whether the metadata for the training system and for the IDoc type FLIGHT_SAVEREPLICA.FLIGHT_SAVEREPLICA01 are entered, by calling transaction IDX2. vorhanden sind. a)

26-02-2004

To check the metadata in the IDoc adapter, call transaction IDX2. To find the IDoc types that are already in the cache, expand the node SAP.


209

Unit 4: Adapters

BIT400

Lesson Summary You should now be able to: • Configure an outbound IDoc adapter and describe the runtime procedure • Describe the distinctive features of an XI-IDoc-XML message

210


26-02-2004

BIT400

Lesson: RFC Adapter: Overview

Lesson: RFC Adapter: Overview Lesson Overview Overview of the architecture of the RFC adapter, design time, configuration time, and runtime.

Lesson Objectives After completing this lesson, you will be able to: • • • •

Understand the RFC adapter as one of the components of SAP Exchange Infrastructure Check RFC signatures in the Integration Repository Check the basic configuration of the RFC adapter Use the SAP Adapter Monitor

Business Example Your system landscape contains SAP systems that have RFC interfaces. You want to assess to what extent RFC interfaces can be used in a scenario and at the same time check the basic configuration of the RFC adapter.

RFC Adapter: Overview

Figure 111: RFC Adapter: Overview

The RFC adapter is required to connect SAP components to the Integration Server by means of RFC protocol for use in scenarios in which IDocs are not used. SAP systems with a release version lower than 4.6 cannot communicate (natively) using XML messages and HTTP. For this reason, the RFC adapter is used to connect such systems to the central SAP Exchange Infrastructure Integration Server. The RFC adapter is part of the Integration Server. It essentially comprises two parts, an inbound adapter and an outbound adapter, though both parts in turn comprise an ABAP

26-02-2004


211

Unit 4: Adapters

BIT400

and a Java part. The lessons in this unit will show you the most important configuration settings that you need to make and provide you with a detailed description of the procedure for realizing the scenario above. The RFC adapter has the following properties/limitations: • • • • •

IDoc processing is not supported Only sRFC and tRFC are supported No external RFC programs are supported Dialog and callback calls in function modules are not possible All calls are stateless

This means that only the IDoc adapter is available for processing IDocs, however this must not be seen as a limitation. RFC usually supports various different technologies, however, the RFC adapter only supports synchronous calls (sRFC) and transactional calls (tRFC). Queue RFC (qRFC) is not possible. Since external programs that were, for example, created with the RFC Software Development Kit (RFC-SDK) do not provide any meta information about the interface parameters, they are not supported. Stateless means that multiple calls in the target system cannot be executed bundled in a single context. This means that write-to BAPIs cannot be used synchronously: write-to BAPIs work with asynchronous updates and do not execute the commit work themselves. However, the necessary commit work cannot be bundled in the same call in the case of a synchronous stateless call. Therefore, write-to BAPIs must be called by tRFC, which is recommended anyway for reasons of call security. The RFC adapter is configured in the Adapter Engine, although the Adapter Engine is installed on the Integration Server, which is not near the business system as is the case for the file adapter, for example. The Java part of the RFC adapter runs on the Java VM of the server (as a standalone application) and is based on the SAP Java connector (SAP JCo). In other words, configuring the RFC adapter essentially means configuring the JCo server and client functions, as is described below.

212


26-02-2004

BIT400


Figure 112: RFC Adapter Architecture

The protocol used for communication is RFC. A message is sent from a business system in RFC data format to the Java part of the inbound RFC adapter (for example, an RFC call is executed in a report). The Java part of the RFC inbound adapter creates a message in XML data format from this message and transfers it to the ABAP part of the RFC inbound adapter by means of RFC. The latter then transfers the data to the pipeline. The same applies for outbound messages: a message from the pipeline in XML format is sent to the outbound RFC adapter, which in turn sends the message in RFC data format to the target system by means of RFC protocol. An RFC-enabled function module (RFM - Remote-Enabled Function Module) is then called in the target system. Before describing the configuration of the RFC adapter, this lesson will first explain the message formats that you can use with the RFC adapter, namely RFM interfaces (known as RFC signatures).

Design: RFC Signatures in the Integration Repository At design time, you must import the interface of an RFM from the business system in the Integration Repository for the corresponding software component version. Just like when you import IDoc types, you must ensure that the connection data of the SAP back-end system is assigned to the software component version so that you can log on to this system and access the meta data. To import the RFC signature, expand the Imported Objects node and call the context menu.

26-02-2004


213

Unit 4: Adapters

BIT400

Figure 113: Repository: Importing RFC Signatures

The RFC signature is not assigned to a namespace of the software component version, but is automatically given the namespace urn:sap-com:document:sap:rfc:functions. Unlike IDoc types, the RFC signature comprises three message types, which each list the interface parameters during the call (request), reply (response), and in the case of errors (fault). This view of the interface parameters of an RFM can also be seen at runtime in the XML messages, as is described below. This is explained below by means of the example for the RFM BIT400_CUSTOMER_GET. •

Request:

•

Response:

•

Fault:

The request is the RFM call and it corresponds to the import interface and table interface of the RFM, while the response corresponds to the export interface and table interface. If the RFM triggers an exception, it is handled as a fault message type.

214


26-02-2004

BIT400


Figure 114: RFC Signature and Message Types

Note: Table interface parameters that are not required for the call are nevertheless listed in the request message type. For example, in the RFC Signature and Message Types graphic, the RETURN table only returns information about the success or failure of the call. It is not used to transfer data to the RFM. All RFMs that belong to a BAPI work with this table and do not have any exception interface parameters, and therefore also do not have any parameters in fault message types. Note: To be precise, when you import an RFM interface, an RFC signature as a message interface and three message types are created. However, the RFC signature itself as a message interface is not specified as synchronous or asynchronous, or outbound or inbound. When you use an RFC signature as a message interface in the configuration, the system automatically uses the appropriate message type (request for outbound or response for inbound).

Configuration: Internal Configuration of the RFC Adapter Internal configuration here refers to the part of the configuration that enables the Java and ABAP parts of the RFC adapter to communicate with each other, in other words to convert data from RFC to XML format and the other way around. These configuration steps only need to be performed once and are part of the Integration Server installation procedure.

26-02-2004


215

Unit 4: Adapters

BIT400

Figure 115: RFC Adapter Configuration: JCo -> ABAP

The RFC adapter is essentially configured like the Adapter Engine, although the Adapter Engine runs on the Integration Server. To start the browser administration screen, either enter the corresponding URL in the browser window (http://:8200) or choose SAP Adapter on the Integration Server/Adapter Engine (RFC Adapter) on the initial screen of the Integration Builder . The RFC adapter is configured by using a single configuration file, which is divided into multiple sections with annotations. Section 3 of the configuration lists the parameters Rfc.Adapter.toXmb.*, which must contain the logon data and technical parameters. This data is used to transfer an inbound RFC message in XML data format to the ABAP part of the RFC adapter by using RFC protocol.

216


26-02-2004

BIT400


Figure 116: RFC Adapter Configuration: JCo -> ABAP

Section 4 lists the parameters that the RFC adapter uses to log on to the gateway to be able to receive XML messages by means of RFC calls. This includes the configuration of an RFC destination with the pre-defined name AI_RFCADAPTER_JCOSERVER on the ABAP side.

Figure 117: Gateway Registration

26-02-2004


217

Unit 4: Adapters

BIT400

Registration is generally used for RFC communication with external programs. In this case, the RFC adapter registers itself with an Integration Server gateway under the (recommended) ID Rfc2XmbService, which corresponds to the parameter RfcAdapter.fromXmb.progid in the configuration. Since every instance of the server has its own gateway, it is very important that you specify which gateway the RFC adapter is registered with. Hint: Usually, you register the RFC adapter with the gateway of the instance on which the message server is running. The gateway information comprises the host (for example, iwdf1708) and the service (combination of sapgw and the instance number, for example sapgw00) and it must also be used for the RFC destination (see below). Hint: You can monitor communication by using the gateway monitor (transaction SMGW). To display the registered programs there, choose Goto → Logged on clients.

Figure 118: RFC Destination to Registered RFC Adapter

The only part of the ABAP part of the adapter that you need to configure is the creation of an RFC destination. Call transaction SM59 to create an RFC destination of type T (with type registration), which references the entry in the gateway. You need to specify the gateway (menu Destination → Gateway Options) that the RFC adapter has registered with. Furthermore, once you have selected the option Registered Server Program you must

218


26-02-2004

BIT400


specify the program ID used by the RFC adapter to log on to the gateway. Finally, do not forget to set the UNICODE indicator since the Integration Server is a unicode system.

Runtime: XML Message Format Note the following about the XML format processed by the RFC adapter: the SOAP header has the entry RfcAdapterProperty, which contains information about the connections used (RFC destination/end point) for inbound and outbound messages, for example. The actual content of the message is stored in the payload as a soap-rfc message (in place of the main document).

Figure 119: RFC-XI-XML Message

As already mentioned in the section about RFC signatures, the name of the called RFM appears as a root element in the XML message.

Example of Request Message 00000023

The outbound message contains the addition Response.

Example of Response Message 821 00000023 SAP America Inc.

26-02-2004


219

Unit 4: Adapters

BIT400

701 Lee Road PA 19113 Philadelphia US ...

SAP tables are listed in an XML file under your name, however, each table entry has the tag item. If the called RFM triggers an exception, it will be visible as an application error in the monitor.

Example of Fault Message NO_ENTRY_FOUND com.sap.mw.jco.JCO$AbapException: (126) NO_ENTRY_FOUND: Kein Eintrag in SCUSTOM gefunden

Monitoring RFC-XML Messages

Figure 120: SAP Adapter Monitor

220


26-02-2004

BIT400


It is recommended that you use the SAP Adapter Monitor (transaction IDX5) to monitor RFC-XML messages since it has several useful selection functions. For example, once you have selected the RFC Monitor option you can specify the direction of the message as well as the RFC destination used or the name of the called function module. To navigate to the the XML message list, choose a message ID from the list that the system produces. All successfully processed synchronous and transactional calls are represented in the XML message list by an inbound and outbound message with the same message ID. In the case of tRFC, they also have the same transaction ID. If the RFM triggers an exception, the monitor only displays an outbound message. To display the application error, navigate to the detail view for the outbound message.

26-02-2004


221

Unit 4: Adapters

222

BIT400


26-02-2004

BIT400


Exercise 14: Checking RFC Signatures in the Integration Repository Exercise Objectives After completing this exercise, you will be able to: • Check RFC signatures in the Integration Repository

Business Example Before using the RFC adapter in a scenario you first want to familiarize yourself with the message interfaces to be used.

Task: Log on to the Integration Repository and call up detailed information about the RFC signature imported by the instructor. 1.

26-02-2004

Log on to the Integration Repository and call up detailed information about the RFC signature BIT400_CUSTOMER_GET that was imported into the software component version XI Training xx and give a name to the parameters for the request and response message types.


223

Unit 4: Adapters

BIT400

Solution 14: Checking RFC Signatures in the Integration Repository Task: Log on to the Integration Repository and call up detailed information about the RFC signature imported by the instructor. 1.

Log on to the Integration Repository and call up detailed information about the RFC signature BIT400_CUSTOMER_GET that was imported into the software component version XI Training xx and give a name to the parameters for the request and response message types. a) b)

c)

d)

224

Log on to client 800 in the training system. Choose Exchange Infrastructure: Integration Builder → Start Integration Builder or call transaction SXMB_IFR. Choose Repository (Design). The user name and password are the same as those required to log on to the Integration Server. Navigate to the software component version XI Training xx, expand the Imported Objects node, and navigate to the detail view of the RFC signature BIT400_CUSTOMER_GET by double clicking it. In the detail view of the RFC signature, choose Display Message Type to select one of the three message types. The request message type has the parameter IM_ID, while the response message type has the parameter EX_SCUSTOM.


26-02-2004

BIT400


Exercise 15: Checking the Configuration of the RFC Adapter Exercise Objectives After completing this exercise, you will be able to: • Check the internal configuration of the RFC adapter

Business Example Before you implement an RFC scenario, you want to ensure that the RFC adapter you want to use is configured correctly.

Task: Log on to the central Adapter Engine, call up the RFC adapter configuration and check the internal configuration parameters.

26-02-2004

1.

Log on to the central Adapter Engine and check the internal configuration parameters of the RFC adapter.

2.

Log on to the Integration Server and check the RFC destination on the RFC adapter.


225

Unit 4: Adapters

BIT400

Solution 15: Checking the Configuration of the RFC Adapter Task: Log on to the central Adapter Engine, call up the RFC adapter configuration and check the internal configuration parameters. 1.

Log on to the central Adapter Engine and check the internal configuration parameters of the RFC adapter. a) b)

c) d) e) 2.

Log on to the Integration Server and check the RFC destination on the RFC adapter. a) b)

c) d)

226

Log on to client 800 in the training system. Choose Exchange Infrastructure: Integration Builder → Start Integration Builder or call transaction SXMB_IFR. Under SAP Adapter on the Integration Server, choose Adapter Engine (RFC Adapter) . Log on using user BIT400 (without a password). Select the adapter rfc_adapter from the list and choose Configure to display the configuration. In section 3, check whether the parameter RfcAdapter.toXmb.host is set to localhost. In section 4, check whether the parameter RfcAdapter.fromXmb.progid is set to Xmb2RfcService.

Log on to client 800 in the training system. Call the RFC destination maintenance screen (transaction SM59) and choose Search to search for the RFC destination AI_RFCADAPTER_JCOSERVER. Check that the program ID is Xmb2RfcService. Start the gateway monitor by calling transaction SMGW and navigate to the screen for registered programs by choosing Goto/Logged on systems. Look for the entry Xmb2RfcService as type REGISTER_TP.


26-02-2004

BIT400


Lesson Summary You should now be able to: • Understand the RFC adapter as one of the components of SAP Exchange Infrastructure • Check RFC signatures in the Integration Repository • Check the basic configuration of the RFC adapter • Use the SAP Adapter Monitor

26-02-2004


227

Unit 4: Adapters

BIT400

Lesson: Inbound RFC Adapter Lesson Overview Overview of the configuration for the RFC inbound adapter as well as technical implementation of RFC calls.


Configure a scenario that is triggered from an SAP system by a remote function call (RFC).

Business Example An SAP system requires information from another system for a scenario. The program states that this information is to be retrieved from another SAP system by using RFC. The target system has a synchronous interface but it does not have an RFC-enabled program. You want to realize the scenario by using SAP Exchange Infrastructure and the RFC adapter.

Inbound RFC Adapter Configuration

Figure 121: Inbound RFC Adapter Overview

228


26-02-2004

BIT400

Lesson: Inbound RFC Adapter

You need to configure the RFC adapter for each SAP system from which an RFC call is to be transferred to the inbound RFC adapter. You configure the inbound RFC adapter in sections 1.2 and 2 of the RFC adapter configuration file, which is stored on the central Adapter Engine.

Figure 122: Inbound RFC Adapter Configuration

In section 1.2, you first need to give the SAP back-end system a parameter name, for example sourceBackend2. All system names are separated by a space and listed in the configuration parameter RfcAdapter.registerInbound. They can then be used in section 2. Section 2 contains the detailed information concerning registration with the gateway of the SAP back-end system. Furthermore, it contains logon parameters with which the inbound RFC adapter can call the metadata from the SAP back-end system.

Creating an RFC Destination in the SAP Back-End System Once you have registered the inbound RFC adapter with a gateway in the SAP back-end system, you can create an RFC destination of type T (registered third-party program), which references the inbound RFC adapter (transaction SM59). To do so, you must use the same parameters as those used in the inbound RFC adapter: gateway host, gateway service, and program ID.

26-02-2004


229

Unit 4: Adapters

BIT400

Figure 123: RFC Destination to Inbound RFC Adapter

Synchronous RFC Call to the Inbound RFC Adapter Once you have created the RFC destination, it can be used for a synchronous RFC (sRFC) call, for example, in a report with the ABAP statement call function ... destination. After call function you must enter (in uppercase letters and quotation marks) the function module (RFM) that you want to call. Furthermore, you must replace destination with the RFC destination that addresses the Integration Server. For purposes of exception handling of RFM exceptions, you should also handle the system exceptions system_failure for system errors and communication_failure for communication problems. Note: An sRFC call is handled as a quality of service BE (Best Effort).

Example Program: Synchronous RFC REPORT

BIT400_sRFC.

Parameters: l_id type scustom-id default ’1’, dest type rfcdes-rfcdest default ’XI_SERVER’. DATA:

l_scust type scustom, mess_text(200).

CALL FUNCTION ’BIT400_CUSTOMER_GET’ destination dest EXPORTING i_id

230

= l_id


26-02-2004

BIT400


IMPORTING e_SCUSTOM

= l_scust

EXCEPTIONS NO_ENTRY_FOUND

= 1

system_failure

= 2 message mess_text

communication_failure = 3 message mess_text OTHERS

= 4 .

case sy-subrc. ... endcase.

Hint: Both system exceptions enable you to get further system information by using the addition message (and a subsequent program variable). Of course, technical routing, logical routing, and mappings must have been configured on the Integration Server before a request can be processed. Hint: The business system determines the ABAP part of the RFC adapter by using the system ID and the client from which the call was sent.

Transactional RFC Call to the Inbound RFC Adapter When making changes to a database (write-to RFM) you must work with transactional RFC (tRFC) for reasons of downtime security. This is particularly the case for RFMs that work with asynchronous updates and that are unable to execute the commit work required to trigger the update, because the RFC adapter only works statelessly. In other words, it is not possible to execute the commit work synchronously in the context of the RFM called previously. Note: An tRFC call is handled as a quality of service EO (Exactly Once). Note the following three points about tRFC calls: • • •

26-02-2004

call function with the addition in background task It is not possible to import data or handle errors End the call with a Commit Work


231

Unit 4: Adapters

BIT400

Example Program: Transactional RFC REPORT

BIT400_tRFC.

... CALL FUNCTION ’BAPI_FLBOOKING_CREATEFROMDATA’ in background task destination dest EXPORTING BOOKING_DATA

= bookdat

* IMPORTING *

AIRLINEID

*

BOOKINGNUMBER

= id = nr

*

TICKET_PRICE

= price

* TABLES *

RETURN

= ret

. commit work.

232


26-02-2004

BIT400


Exercise 16: Checking the RFC Destination for the Inbound RFC Adapter Exercise Objectives After completing this exercise, you will be able to: • Understand how to execute an RFC call to the inbound RFC adapter

Business Example You want to forward a synchronous call to the target system by using the Integration Server. To do so, you need an RFC destination to be able to send the call to the Integration Server. Furthermore, you need to implement the actual RFC call.

Task: Check the RFC destination and study the example program.

26-02-2004

1.

Log on to the business system Travel_Agency_Summer and check the RFC destination to the inbound RFC adapter.

2.

Study the demo program BIT400_sRFC.


233

Unit 4: Adapters

BIT400

Solution 16: Checking the RFC Destination for the Inbound RFC Adapter Task: Check the RFC destination and study the example program. 1.

Log on to the business system Travel_Agency_Summer and check the RFC destination to the inbound RFC adapter. a) b)

c) 2.

Study the demo program BIT400_sRFC. a)

234

Log on to client 811 in the training system. Call the RFC destination maintenance screen (transaction SM59) and choose Search to search for the RFC destination BIT400DEST##. Check which program ID is saved in the RFC destination.

Start the ABAP Editor by calling transaction SE38. Enter BIT400_sRFC as the program name and display the source text.


26-02-2004

BIT400


Lesson Summary You should now be able to: • Configure a scenario that is triggered from an SAP system by a remote function call (RFC).

26-02-2004


235

Unit 4: Adapters

BIT400

Lesson: Outbound RFC Adapter Lesson Overview This lesson explains how to set up an SAP target system in the RFC adapter that is to receive RFC calls. Furthermore, the lesson will also illustrate the configuration steps you need to make in the Integration Builder (Configuration) to realize an RFC-to-RFC scenario.


Configure a scenario in which an RFM (remote-enabled function module) is called by using RFC.

Business Example In a scenario you require information from a target system. This information is made available by using an RFC interface.

Outbound RFC Adapter Configuration You must create an end point of type RFC in the Integration Directory for the business system that corresponds to the SAP back-end system before you configure the outbound RFC adapter. This end point contains the technical information about the SAP back-end system which contains the RFM that you want to call. Furthermore, the logon data for this end point is maintained separately as logon data. You must specify the SAP back-end system as a business system when you create the end point. You also need to assign an RFC signature (and therefore the namespace urn:sap-com:document:sap:rfc:functions) to the end point, otherwise you cannot set it as type RFC Adapter. Once you have made these entries on the initial screen, navigate to the detail view and select the end point type RFC Adapter. The end point contains the technical information about how to log on to the SAP back-end system. However, it is possible to specify an application server (an instance) directly and to maintain the message server and logon group by using load balancing. Hint: When you create an end point, most of the data will already have been entered since it is taken from the business system that you defined in the System Landscape Directory.

236


26-02-2004

BIT400

Lesson: Outbound RFC Adapter

Figure 124: Outbound RFC Adapter: End Point

Once you have defined the end point you then need to maintain the logon data separately. This is mandatory for an end point of type RFC Adapter. Logon data comprises four parameters: • • • •

SAP Client User Password Logon Language

As is the usual procedure in RFC communication, the user must be of type Communication. This user does not have dialog authorization and so cannot be abused and used to log on normally. Furthermore, these users are exempt from having to periodically change their password in the system, if this is the system default. Hint: Depending on the trace setting on the Integration Server, the password may be displayed in the XML monitor for a corresponding message.

26-02-2004


237

Unit 4: Adapters

BIT400

Figure 125: Outbound RFC Adapter: Logon Data

You also have the option of entering the logon data in section 5 of the RFC adapter configuration file with the parameters RfcAdapter.targetBackend.*. This enables the outbound RFC adapter to logon to the target system, thus avoiding unnecessary logon time.

Figure 126: Outbound RFC Adapter: Configuration

238


26-02-2004

BIT400


Configuration in the Integration Builder Ultimately, you must configure the Integration Server so that the inbound RFC call is forwarded to the correct target system. The configuration assistant is particularly useful for this purpose, especially when the inbound and outbound interfaces are the same. This is the case in the demo scenario, where the RFC call is executed with exactly the same interface as the RFM. In the Integration Builder (Configuration) you can call the configuration assistant for a business scenario. First of all, you specify the sender business system, including the name of the called RFM (as the interface name) and the namespace urn:sap-com:document.sap.rfc:functions. You can also select the entries from the input help for these fields. Secondly, specify the receiver business system with the RFM name. Since the two interfaces match, you do not need to enter an interface mapping in the third step. Finally, to complete the configuration, you assign the end point of type RFC you created previously and the existing logon data by using the RFM name.

26-02-2004


239

Unit 4: Adapters

240

BIT400


26-02-2004

BIT400


Exercise 17: Executing an RFC Call and Checking the XML Message Format of the Pipeline Exercise Objectives After completing this exercise, you will be able to: • Understand the XML message formats used in the RFC adapter

Business Example To monitor an RFC scenario, you need to be able to check the inbound and outbound messages on the Integration Server.

Task: Start the program that executes the RFC call and then look at the messages that have been converted on the Integration Server.

26-02-2004

1.

Log on to business system Travel_Agency_Summer and start the demo program BIT400_sRFC with a query for customer##.

2.

Log on to the Integration Server and start the SAP Adapter Monitor (transaction IDX5). Search for the messages generated by your call.


241

Unit 4: Adapters

BIT400

Solution 17: Executing an RFC Call and Checking the XML Message Format of the Pipeline Task: Start the program that executes the RFC call and then look at the messages that have been converted on the Integration Server. 1.

Log on to business system Travel_Agency_Summer and start the demo program BIT400_sRFC with a query for customer##. a) b) c)

d) 2.

Log on to client 811 in the training system. Start the ABAP Editor by calling transaction SE38. Enter BIT400_sRFC as the program name and start the program. On the selection screen for the program, enter BIT400DEST## as the RFC destination and your group number ## as the customer number. Start the program by choosing Execute or F8. Check whether the customer data for customer number ## is listed correctly.

Log on to the Integration Server and start the SAP Adapter Monitor (transaction IDX5). Search for the messages generated by your call. a) b)

c)

d) e)

Log on to client 800 in the training system. Start the SAP Adapter Monitor by calling transaction IDX5. Select the radio button RFC Monitor and enter your RFC destination BIT400DEST##. Start the monitor by choosing Execute or F8. Navigate to the detail view for each message by double clicking the message ID in each case. To display the inbound message, in the detail view, choose Inbound Message → Payload → soap-rfc. To display the outbound message, in the detail view, choose Response → Payload → soap-rfc. Hint: Since the inbound and outbound messages both have the same message ID, it is irrelevant which you display in the detail view.

242


26-02-2004

BIT400


Lesson Summary You should now be able to: • Configure a scenario in which an RFM (remote-enabled function module) is called by using RFC.

26-02-2004


243

Unit Summary

BIT400

Unit Summary You should now be able to: • Describe the different types of adapters and their uses • Describe the tasks of the Adapter Engine • Configure an outbound file adapter and describe the runtime procedure • Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as an XML file • Configure a scenario that transfers an XI-XML message to the file adapter and writes it to a directory as a sequential file • Configure an inbound file adapter and describe the runtime procedure • Configure a scenario that reads an XML file from a directory and transfers it to the Integration Server pipeline as an XI-XML message • Configure a scenario that reads a sequential file from a directory and transfers it to the Integration Server pipeline as an XI-XML message • Import an IDoc type to the Integration Repository • Check the IDoc-specific settings in the SLD • Describe the structure of an IDoc as an XML message in the pipeline • Configure an inbound IDoc adapter and describe the runtime procedure • Configure an outbound IDoc adapter and describe the runtime procedure • Describe the distinctive features of an XI-IDoc-XML message • Understand the RFC adapter as one of the components of SAP Exchange Infrastructure • Check RFC signatures in the Integration Repository • Check the basic configuration of the RFC adapter • Use the SAP Adapter Monitor • Configure a scenario that is triggered from an SAP system by a remote function call (RFC). • Configure a scenario in which an RFM (remote-enabled function module) is called by using RFC.

244


26-02-2004

BIT400

Course Summary

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

26-02-2004

Configure an asynchronous scenario with different outbound and inbound interfaces Connect sender or receiver SAP systems using the IDoc adapter or the RFC adapter Transfer files to SAP Exchange Infrastructure as a data source using the file adapter and write messages from SAP Exchange Infrastructure to a file using the file adapter


245

Course Summary

246

BIT400


26-02-2004

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

26-02-2004


247

Bit400 en Col34 Fv Part a4

Recommend Documents