TBIT40 Implementation & Operation 2004 Q4

(1)

©SAP AG 2004

TADMBO Implementation&Operation II

THE BEST-RUN BUSINESSES RUN SAP

TBIT40

Implementation & Operation II

2004/Q4

(2)

©SAP AG TBIT40 0 - 1

SAP Exchange Infrastructure 3.0

TBIT40 XI Foundations

(3)

©SAP AG 2003, PM Process Integration 2

Topics

Lecture topics

XI Overview

System Landscape Directory Integration Repository Integration Directory Runtime

Runtime Workbench Adapter Framework

Business Process Management Server Administration

Security

(4)

©SAP AG 2003, PM Process Integration 3

Topics

Exercise topics

Exercise 1: File to IDoc Exercise 2: File to JDBC Exercise 3: HTTP to (t)RFC Exercise 4: ABAP Proxy to RFC Exercise 5: BPM Async-Sync

(5)

SAP Exchange

Infrastructure – Process

Centric Integration

XI Overview

SAP NetWeaverTM Process Integration

(6)

©SAP AG 2004, TBIT40 01 XI Overview 2

Topics

Lecture topics

XI Overview

Security

(7)

After completing this unit, you will be able to: Explain need for and the benefits of the SAP Exchange Infrastructure.

Describe the components of the SAP Exchange Infrastructure.

Detail the key functionality of SAP XI.

(8)

Agenda

SAP Exchange Infrastructure

Positioning

Architecture Overview

Key Functionality

(9)

Mission

BUILDER SERVER

SAP XI is an integration technology and platform…

…for SAP and non-SAP applications.

…for A2A and B2B scenarios.

…for asynchronous and synchronous communication. …for cross-component Business Process Management.

A goal of the Exchange Infrastructure (XI) is to provide a single point of integration for all systems, SAP and non-SAP, inside and outside the corporate boundary.

The XI supports B2B as well as A2A exchanges; supports synchronous and asynchronous message exchange; and includes a built-in engine for designing and executing Integration Processes (Business Processes).

An important feature of the XI is that it provides openness and transparency to the integration process

(10)

SAP NetWeaver™

Unifies and aligns people, information and business processes

Integrates across technologies and organizational boundaries A safe choice with full .NET and J2EE interoperability

The business foundation for SAP and partners

Powers business-ready solutions that reduce custom integration

Its Enterprise Services

Architecture increases business process flexibility

SAP NetWeaver

™

SAP NetWeaver™ Compos ite A pplic a tion Fra m e w or k PEOPLE INTEGRATION

Multi channel access

Portal Collaboration INFORMATION INTEGRATION Bus. Intelligence Master Data Mgmt Knowledge Mgmt PROCESS INTEGRATION Integration Broker Business Process Mgmt APPLICATION PLATFORM J2EE DB and OS Abstraction ABAP L if e C y cle M g mt

SAP NetWeaver is the integration and application platform for mySAP

solutions; XI represents the Process Integration layer of the NetWeaver stack, and is a crucial element of the Enterprise Services Architecture (ESA).

(11)

One Customer’s Complex Integration Landscape

SAPMarkets Enterprise Buyer (Professional Edition) Collaborative Engineering SAP R/3: ~30 systems, versions 3.1I – 4.6B e-Procurement: in 10 units ERP legacy: ~15 systems e-Sales Technical Systems Trading ERP non-SAP: ~25 systems, different versions

Today, integration complexity abounds. Many components in customer system landscapes are directly connected 1:1, with all integration capabilities hardwired into the application components and individual mapping programs.

Imagine a common complex IT landscape at a customer site. This sort of ”spider web” is the epitome of today’s application integration challenge. What you see is a wildly grown integration landscape with different application systems and multiple individual connections between different interfaces. Connecting these applications does not only lead to a high complexity in managing and maintaining – there is also a lot of cost associated with it.

(12)

Exchange Infrastructure for Collaboration

Integration Engine & Bus Infrastructure Shared central knowledge, Small number of peer-to-peer connections Direct Connections Integration challenge Quadratically growing complexity Database Integration Integration by single centralized data model Enterprise Resource Planning Inter-/Intra-Enterprise Co-operation Collaborative Business

How integration has evolved at SAP:

At first a single database integration in a single centralized data model: in one system with several applications one database, (e.g. an R/3 system with MM, SD, CO, FI, HR,…) with the applications having access to the data structures across the components. Integration in this case is and was fairly easy.

Then SAP and 3rd party vendors provided other solutions as e.g. CRM, SRM, … These solutions and their respective systems needed to be integrated to the ERP environment (e.g. an R/3 backend system). This brought added complexity and the beginning of many individual point-to-point connections.

With the SAP Exchange Infrastructure and collaborative business, SAP

approaches the integration challenge from a different angle. The basic idea is to provide a runtime infrastructure which allows heterogeneous systems to be tied together with fewer connections and at the same time, in order to connect those applications and let messages flow from one application to the other, have a centralized storage of the integration knowledge.

(13)

The Solution – Shared Business Semantics

Shared Integration Knowledge

Integration scenarios, business processes, Web services, interfaces, mappings, routing rules, ...

For a common understanding how collaborative business processes work

Enabling distributed execution

Shared classification and discovery of businesses and services Support for UDDI (Universal Description, Discovery and Integration)

Loose coupling via XML messaging

Asynchronous communication as far as possible Synchronous communication where required Evolution

Allow easy and non-disruptive addition of new services and processes

Integration of existing and new SAP components

Integration of existing customer and 3rd party components

The complete integration knowledge of mySAP.com e-business platform is described in shared repositories and directories. Traditionally, interfaces were described within components in an implementation-dependent programming language. E.g. Interfaces in the Integration Repository introduce a new level of transparency and homogeneity in interface development. The integration knowledge is not distributed across individual applications, but is centrally configured.

XML-messaging: Loosely coupled applications communicate by exchanging XML messages via the integration infrastructure. Communication is asynchronous in most cases to allow complete decoupling. Synchronous calls are supported and

(14)

Advantage: Pre-delivered Integration Content

Benefits

Out-of-the-box integration of SAP solutions Simplified upgrade of SAP Solutions

Versioning and modification management of integration meta-data

SAP solutions bring their integration meta-data (CRM, SRM, SCM, xApps like xRPM, etc.)

Delivered with the

Integration Repository of SAP XI SUS EBP 3rd Party Catalog Data

SAP provides content for mySAP solutions in files that are imported into the XI.

(15)

Advantage: Openness and Interoperability

Benefits

Leverage existing investments

Arrive at new integration landscape in an evolutionary manner

Allow easy and non-disruptive addition of new services and processes

3rd Party Application SAP Application 3rd Party Middleware Component 3rd Party Application

Connect to existing integration solutions

Through JMS messaging (e.g. MQSeries) Through SOAP

Use open, XML based standards for integration

Incorporate existing functionality into new processes

Adapters (JCA) Web Services (WSDL)

XI is open and flexible; it uses web standards such as Web Services

Description Language (WSDL), XML Schema Definition Language (XSD), and SOAP messaging for describing objects and communicating with other

(16)

Agenda

SAP Exchange Infrastructure

Positioning

(17)

SAP Applications Using XI

More and more SAP applications are making use of SAP Exchange Infrastructure and introducing XI to a customer landscape

The following applications now use XI:

xApps (such as xRPM, Resource and Program Management) MDM (SAP Master Data Management)

SRM (SAP Supplier Relationship Management)

ICH (SAP Inventory Collaboration Hub within SAP SCM)

BI (SAP Business Intelligence, for Global Spending Reporting) R/3 Enterprise (for Industry Standard Support)

CRM (SAP Customer Relationship Management, for Extended Order Management)

(18)

Execution of Collaborative Business Processes Shared Collaboration Knowledge

Component Overview

Integration Builder Integration Directory (ID) Integration Repository (IR) Integration Server (IS)

System Landscape Directory (SLD)

Central Monitoring SAP Systems 3rd_Party Systems 3rd_Party Middleware Component Marketplace/ Business Partner

The XI is not a single component, but rather a collection of components that work together flexibly to implement integration scenarios.

The architecture includes components to be used at design time, components to be used at configuration time, and components to be used at runtime. XI components include:

The System Landscape Directory: a central repository of information about software and systems in the data center.

The Integration Builder: A client-server framework for accessing and editing two stores of

Shared Collaboration Knowledge:

The Integration Repository: For the design and development of Interface, Process, and Mapping objects that are used to implement Integration Scenarios.

The Integration Directory: For configuring scenarios from the Integration Repository in the concrete customer landscape.

The Integration Server: The central processing engine of the XI. All messages, whether SAP or non-SAP, A2A or B2B, regardless of backend technology or vendor, are

processed in a consistent way.

Central Monitoring: To give a comprehensive and focused view of all components and processes at runtime.

The Adapter Engine: A Java Connector Architecture (JCA) compliant adapter engine for connecting backend systems to the XI.

(19)

Capturing Shared Knowledge at Design/Config Time

Integration Engine Integration Repository

Product to be used at design/development time

At SAP, partner, and customer site Shipped along with content

Integration Directory

Product to be used at configuration time

At customer site

Content partially derivable from Integration Repository by configuration tools

Integration Engine

Product to be used at runtime At customer site

Relies on content of Integration Directory

By separating design time activities from configuration time activities, SAP can ship content for the Integration Repository, which each customer can

implement for their specific landscape in the Integration Directory. As far as possible the goal is to reduce the problem of developing interfaces to the simpler task of configuring interfaces.

At runtime, the Integration Engine is based on the solid architecture of the SAP Web Application Server, leveraging the power, scalability, and

(20)

Exchange Infrastructure – Integration Landscape

SAP 3.x SAP 4.x Third Party System SAP Adapter 3rd Party Adapter mySAP Solution*

* based on SAP Web Application Server 6.20+

Firewall Business Partner Business Partner Business Partner Market-place Integration Repository Integration Directory Integration Server

connects to different SAP and Non-SAP Systems, to Business Partners and Public Marketplaces

The SAP Exchange Infrastructure connects to different SAP and Non-SAP systems. In this example of an integration landscape at a customer site, an SAP R/3 3x (e.g. R/3 3.1I), an SAP R/3 4.x (e.g. R/3 4.OB), a third party system and a new mySAP solution (e.g. mySAP SRM) are integrated via the SAP Exchange Infrastructure. The Integration Server also handles the connection to different Business Partners as well as to a Public Marketplace.

Certain adapters are needed in cases where the Integration Server is to exchange messages with an R/3 system based on a basis kernel lower than 6.20 (RFC adapter, IDoc adapter), or in order to connect to a specific marketplace (depending on the marketplace product). There are no additional adapters

needed, when the Integration Server connects to a new mySAP solution which is based on the SAP Web Application Server 6.20, as the components of these solutions carry themselves a “small” Integration Engine – those systems can directly interact and communicate with the Integration Server to exchange XML messages.

(21)

Agenda

SAP Exchange Infrastructure

Positioning

(22)

Integration Builder – Common tool framework

DB U I C lie nt Server Integration Directory Integration Repository

Integration Builder Server Framework

Query Service & Cross References Import/Export & CMS interface Internationalization

Change list Management Versioning

Locking

Authorization & Authentication

Integration Builder Client Framework

Layout Building Blocks Personalization

Navigation

Client-server framework

Consistent look and feel Based on Java Web Start

The Integration Builder is the common tool framework for design and configuration time activities.

The Integration Builder allows you to work with objects in both repositories in a consistent way, with a consistent interface and a common look-and-feel. The Integration Builder is a Java application. On the client side it provides the user interface for working with XI objects. On the server side it offers services for authentication, lock management, import and export of interface objects, internationalization, versioning, and change management.

Because the client applications (Integration Repository and Integration Directory) are “fat” clients, Java Web Start is required. JWS is a caching application for Java clients (download once and store locally).

(23)

Design

System Landscape

Directory Software Component

Software Component Version SA P Web A S J2EE/ ABAP Proxies Integration Repository BPEL XSLT Java XPath WSDL Integration Builder

Data Type Editor

Message Interfaces Message Types Data Types (XSD) Business Processes Mappings Business Scenarios Context Objects Scenario Editor Process Editor Mapping Editor Condition Editor Pre-delivered Integration Content for mySAP solutions

Open for collaboration knowledge of non-SAP systems, using open standards (e.g. WSDL) Provision to enhance XI design time objects by customers / partners Java based graphical tools

SAP provides the design content for mySAP solutions; other SAP interfaces, such as Remote-enabled Function Modules or IDOCs, are imported into the Integration Repository. The customer can add the collaboration knowledge of the non-SAP systems that are participating in an integration scenario.

The Integration Builder provides the editors for each object type in the Integration Repository.

All XI objects are described using web standards: Web Services Description Language (WSDL) for interfaces, XML Schema Definition Language (XSD) for messages and data types, XPath for “slicing and dicing” data in XML

(24)

Configuration

Integration Builder Integration Directory Business Processes Routing Rules Business Scenarios

Receiver Determination Rules

Interface Determination Rules (including Mapping Assignment)

Configuration Editors Configuration

Wizards

Collaboration Profiles

Parties & Services Channels

Collaboration Agreements

Security

Adapt integration content to specific configuration

Derive integration content from Integration Repository

Open for Customer to add collaboration knowledge relevant to non-SAP components

Java based graphical tools

Central configuration for B2B processes and BPM

Centralized adapter configuration

Once Integration content has been created in the Integration Repository, scenarios are configured in the Integration Directory. In the directory we specify the actual systems that will be exchanging messages, and configure the details of the message exchange (security, transport protocol, etc.)

(25)

System Landscape Directory

Describes concrete system landscape

of customer installation

What component is actively available on which machine/instance/client, etc.

Information about domain contained, i.e. in which network environment (local / remote) are components accessible

Any number of different landscapes Any type of component (SAP, partner products, other packages, legacy systems ..)

Open architecture, based on CIM Base for structuring design objects in the repository, and for configuring routing rules in the directory

The System Landscape Directory (SLD) is a central repository of information about systems and software in the data center.

The SLD is a server application; the XI is technically a client of the SLD. The SLD adheres to the Common Information Model (CIM), a standard proposed by the Distributed Management Task Force (DMTF).

(26)

SAP Web AS ≥ 6.20 SAP System

Runtime

Integration Directory System Landscape Directory XI Protocol RosettaNet, … XI Protocol Central Monitoring

Business Process Engine

Integration Engine Adapter Engine IDocs RFCs Proxy 3rd Party Apps File DB JMS Apps of Business Partner Apps of (small) Business Partner Local Integration Engine Proxy Runtime Partner Connectivity Kit

At runtime, the Integration Scenarios that have been developed in the Integration Repository and configured in the Integration Directory are

executed by the Integration Server. The Integration Server includes engines for executing Integration Processes (Business Processes), processing messages, and connecting to backend systems.

Communication between mySAP systems based on the SAP Web Application Server version 6.40 or higher communicate natively with the XI; other

systems, including those using B2B standards such as RosettaNet, CIDX, and PIDX, communicate via adapters.

SAP also provides the Partner Connectivity Kit (PCK), which allows smaller partners and subsidiaries that may not have XML messaging or B2B

capabilities to communicate natively with the XI across firewalls and across the Internet.

(27)

Decoupling Of Integrated Applications

3rd Party Adapter Firewall Integration Directory Integration Server SAP R/3 3.1i SAP R/3 Enterprise 3rd_Party App Marketplace Business Partner Business Partner Business Partner SAP

Adapter DeterminationReceiver

Channel Determination Mapping Routing Rules Mappings Collaboration Profiles

A sample message flow from one application to another is depicted

Logical decoupling of senders and receivers

Decoupling of sender and receiver interface formats

SAP XI abandons the point-to-point integration approach, favoring instead a model that features loosely coupled applications communicating via

XML/SOAP/HTTP. A message is received at the Integration Server and is examined by the runtime environment; based on the configuration for the particular message type and content, the message is routed to the appropriate receiver(s), perhaps undergoing a mapping to the partner format along the way.

(28)

Functionality

Communication

Synchronous: always “best effort”

Asynchronous: exactly-once or exactly-once-in-order

Retry mechanism

Acknowledgment is supported

Including error handling

Synchronous: error messages sent back to sender Asynchronous: errors made persistent

Transport of (XML) messages based on HTTP or HTTPS “SOAP Messages with Attachments” as wire format

Messaging protocol based on SOAP envelope with header extensions

XI Runtime Environment

The XI supports Synchronous and Asynchronous delivery; in XI terms, these are described with a Quality of Service (QoS) descriptor. The XI supports QoS Best Effort (BE), Exactly-once (EO), and Exactly-once-in-order (EOIO). These are equivalent to RFC types Synchronous RFC (sRFC), Transactional RFC (tRFC), and Queued RFC (qRFC), respectively.

The XI is used to exchange XML messages in an implementation of the SOAP protocol. The SAP implementation of SOAP includes messages sent as attachments to the SOAP document.

(29)

Connectivity / Adapters

Execute Collaborative Business Processes

Central Monitoring – ensures collaboration reliability

SAP Systems Partner Connectivity Kit Marketplace/ Business Partner Business Process Engine

Integration Server

Integration Engine Central Adapter Engine Adapter Framework Messaging Queuing Security Handling R e s our c e A dap te r Application Techn. System File/DB/JMS

Adapter framework based on Java Connector

Architecture (JCA)

Adapters work as plug-ins to the Adapter

Framework

Adapter Development Kit - customers and partners can develop adapters

SAP NetWeaver certification of 3rd_party

adapters based on JCA adapter framework

Reselling of JCA adapters from selected partners (iWay, Seeburger)

SAP XI includes the Adapter Framework for developing adapters to non-SAP systems that can be executed by the Adapter Engine. The Adapter

Framework is a JCA-compliant framework for developing connectors to the XI. The framework includes:

Technical Resource Adapters

Non-SAP backend integration adapters B2B Adapters

(30)

Integration Server J2SE Adapter Engine Partner Connectivity Kit Optional Decentral Adapter Engine Central Adapter Engine

Adapter Architecture

Integration Repository / Integration Directory / System Landscape Directory

Business Process Engine

Integration Engine Adapter Framework Messaging Queuing Security Handling R e s our c e A dap te r R e s our c e A dap te r R e s our c e A dap te r Adapter FW Messaging Queuing Security Handling Adapter FW Messaging Queuing Security Handling PCK Configuration and Monitoring RFC/ ID o c A dap te r Adapter 3rd Party Application 3rd Party Application Application Techn. System File/DB/JMS File DB JMS SAP System

The XI Adapter Engine is based on the integrated J2EE engine of the SAP Web AS; it allows for central configuration and monitoring of all adapters, even those that are installed de-centrally (close to the backend system). The Adapter Engine includes its own security, message processing, and message queuing functionality.

(31)

©SAP AG 2004, TBIT40 01 XI Overview 27 Business

System 4

Cross-Component Business Process Management

Business System 1 Integration Server Business System 3 Business System 2 1 2 3 Messages Message 4

Orchestrates message choreography based on stateful interactions

Design, execute and monitor automated processes across applications and systems Provides process control in the central technology layer

Contains a Graphical Modeler Integral part of XI

Modeling enables linkage to XI design objects: interfaces, mappings …

BPM runtime is embedded in the Integration Server runtime

Adheres to standards

Industry Standard support (BPEL4WS) Import/ export of process definitions

Integration Processes (Cross-Component Business Processes), are executable processes that allow for stateful interactions between loosely-coupled systems.

XI includes capabilities for designing, documenting, implementing, configuring, and executing Integration Processes.

Integration Processes are built using the web standard Business Process Execution Language for Web Services (BPEL4WS or just BPEL).

(32)

SAP XI and B2B enablement (1)

Industry B2B Protocols

System Landscape Directory (SLD) Integration Repository (IR) Integration Directory (ID) Integration Server (IS) Partner Connectivity Kit Apps of (small) Business Partner Apps of (small) Business Partner XI Protocol

Enable business partners to conduct B2B processes with XI

Security enrichments for B2B Digital Signature and Encryption Partner Connectivity Kit

Enable partners of XI customers to conduct XML document exchange with XI

In order to enable B2B scenarios, XI includes security features such as message encryption, digital signatures, and non-repudiation.

Additionally, the PCK allows smaller partners or subsidiaries with no native B2B messaging capabilities to communicate with XI.

(33)

Integration Directory

(ID)

SAP XI and B2B enablement (2)

Collaboration Profile

Collaboration Agreement Industry B2B Protocols

System Landscape Directory (SLD) Integration Repository (IR) Integration Server (IS) Partner Connectivity Kit Apps of (small) Business Partner Apps of (small) Business Partner XI Protocol Industry Standards Content

Industry Standards Content (e.g. RosettaNet PIPs, specific mappings)

Collaboration Profile and Collaboration Agreement in Integration Directory

Manages technical characteristics of partners to facilitate document exchange, such as

Party identification

Message formats and versions supported Security requirements

SAP provides Industry Standards content for the Integration Repository; for instance, implementations of RosettaNet Partner Interface Processes (PIP’s). The Integration Directory includes Collaboration Profiles and Collaboration Agreements for enabling B2B communication.

(34)

Value-added Web Services Through XI

Web Service Client (SAP/non-SAP) Proxy Local Integration Engine Proxy Runtime Web Services Framework SOAP

‘Basic’ Web Service

IDocs RFCs

Web Service Client (SAP/non-SAP)

‘Managed’ Web Service

Mapping Routing Business Processes Adapter SOAP XI Protocol or SOAP Adapter Integration Server 3rd Party App SAP Web AS ≥6.40 SAP System

The SAP Web Application Server includes native XML messaging capability, and the ability to provide web services based on the SOAP protocol.

Because of the enhancements to the basic SOAP protocol used by XI, it is possible to implement “value-added” web services through the XI. XI allows to include additional payloads to a message, and to implement additional

(35)

Runtime Workbench

Central monitoring tool for the complete XI landscape Component monitoring Message monitoring Graphical end-to-end monitoring Performance monitoring Smooth integration with CCMS

Easy Configuration

Exploiting System Landscape Directory

Web-based user interface

The Runtime Workbench is an XI component that offers a central monitoring view of all XI components and processes.

The Workbench includes graphical end-to-end monitoring of integration scenarios.

It provides smooth and easy integration with CCMS, and CCMS alerts can be viewed through the Runtime Workbench.

(36)

Summary

SAP XI addresses integration challenges Is a A2A and B2B integration solution Industry standard support

Supports the whole process integration lifecycle Comes with pre-delivered content

Is suited for heterogeneous integration landscapes Is interoperable based on open standards

SAP XI is SAP’s strategic process integration platform mySAP SRM, mySAP SCM, SAP for Retail, …

Synergetic use inside SAP NetWeaver with SAP MDM, BPM, CAF, … SAP XI is more than just an Integration Broker

Cross-Component BPM

SAP XI is a serious approach to the integration challenge, and represents the Process Integration layer of the NetWeaver stack. It leverages the flexibility of web standards such as Java and WSDL, as well as the power and scalability of ABAP. It is a crucial element in implementing the Enterprise Services Architecture.

XI supports both A2A and B2B scenarios. It includes content provided by SAP, reducing the amount of work the customer must do to implement an integration scenario. It provides for the rapid development of new interfaces in an intuitive, non-disruptive way. It includes shared collaboration knowledge for transparency in integration scenarios.

XI offers one platform for implementing messaging and Integration Processes (Business Processes).

(37)

You should now be able to:

Explain need for and the benefits of the SAP Exchange Infrastructure.

Describe the components of the SAP Exchange Infrastructure.

Detail the key functionality of SAP XI.

(38)

01 - XI OverviewEx.doc 1

TBIT40 – XI 3.0 Foundations workshop exercises Overview

This set of exercises will cover a realistic business scenario involving heterogeneous systems. The goal is to make the different applications communicate with each other using SAP Exchange Infrastructure 3.0.

The scenario is based on a typical procurement process and is inspired by real-life customer requirements. Therefore the workshop is intended for technical consultants who are likely to be faced with similar scenarios at customer sites.

The scenario

This is a simple procurement process involving the following applications: - A legacy (mainframe) system

- A Microsoft SQL Server RDBMS sales system - A third-party web-based purchasing application - An SAP R/3 4.6C system

- An SAP Web AS 6.40-based purchasing application

The diagram below outlines the different components involved and the message flow within the scenario. XML Order Data IDoc BAPI XML Vendor SAP R/3 4.6C File XML Order Confirmation SAP WebAS 6.40 Purchasing app Legacy System RDBMS System Web Purchasing Application HTTP JDBC IDoc RFC XML Vendor data XML/Proxy Order request

(39)

The scenario consists of two logical parts: 1. Creation of Vendor master data

A vendor is created in the legacy system. It will be replicated in the R/3 environment via an IDoc (CREMAS03). It will also be replicated in the RDBMS environment.

2. Posting of Purchase Order transactional data.

Purchase orders will be posted into the R/3 system for the vendor created above. The PO requests could come from the third-party web application, or the SAP WebAS 6.40 application. With the use of BPM, an order confirmation will be sent back to the legacy system.

This is a variation of an existing prototype scenario commonly referred to as “XI Starter Pack”. It is possible to combine this workshop with the existing starter pack and have an enhanced scenario.

Please note, the focus of the scenario is to display XI-specific features including the touch points into the respective applications. The functional application logic is not in scope; neither are the technical configuration aspects for the respective application systems. In other words this is not a workshop about Microsoft SQL Server or IBM MQSeries, neither is it about ALE or the SD module in R/3. The table below explains the touch points into the different applications, i.e. the boundaries of this scenario. It also outlines the extent to which the application is implemented in our landscape.

Component Touch point(s) Application functionality SAP R/3 4.6C RFC, IDoc Purchase order creation, vendor creation.

Transactions will physically take place in the system Legacy system File system This emulates a mainframe application. Files are

physically read/written in an OS folder. Web purchasing app. HTTP client The HTTP client is used manually.

This emulates requests coming from the application RDBMS sales system JDBC This is a SQL Server database. Rows are physically

written to a table

Web AS 6.40 app ABAP proxy This is a simple proxy client in ABAP. No application logic.

The exercises

The scenario is designed to exercise as many XI 3.0 features as possible, with a clear focus on the more practical, implementation-related aspects. Each exercise covers a specific part of the

(40)

01 - XI OverviewEx.doc 3

1. Vendor creation in R/3 – File sender to IDoc (asynchronous)

In this exercise the legacy system is producing a file containing Vendor data. For the purpose of this exercise we assume the file to be in XML format. The file is picked up by the file adapter, and mapped to IDoc-XML format, using the graphical mapping tool. A CREMAS03 IDoc will then be posted into the R/3 system, in order to create a new vendor there. Note that the vendor number is supplied externally be the legacy application. The exercise addresses a simple customer

requirement: integrate an external application with a traditional SAP system, using IDoc technology.

XI Features exercised:

- Basic design/configuration tasks - File adapter (sender)

- IDoc adapter - Message mapping Technical prerequisites:

- the R/3 application must be configured to be able to create vendors - ALE logical systems and partner profiles must be configured

2. Vendor master data distribution – File sender to RDBMS (asynchronous).

In this exercise, the same vendor data from exercise 1 needs to be replicated from the legacy system to the RDBMS system. The JDBC adapter will be used for this purpose. This is an example of XI being utilized to integrate non-SAP systems with each other.

XI Features exercised

- Routing to multiple receivers - File adapter (sender) - JDBC adapter (receiver) Technical prerequisites:

- A Microsoft SQL Server database is available

3. Purchase Order creation – HTTP client to BAPI (synchronous, then asynchronous)

In this exercise, a third-party web-based purchasing application will be posting XML data to the XI plain HTTP adapter. The XML structure definition is available externally as an XML Schema. Within XI, the data is routed (according to the Vendor number) and mapped to RFC-XML. A custom BAPI is called into the R/3 system to create the purchase order. This custom BAPI is in fact a wrapper for the standard BAPI_PO_CREATE and will return the PO number upon successful completion.

First we will implement the scenario synchronously (via standard RFC), then asynchronously (via tRFC).

This exercise addresses the requirement of posting transactions from an external web client into a traditional SAP application, using RFC technology. This can also be viewed as an entry point into the domain of web services. This will also open some discussion points regarding the pros and cons of synchronous vs. asynchronous communication.

XI Features exercised:

- Basic design/configuration tasks - Content-based routing

(41)

- Reuse of external objects based on open XML standards (XSLT, XSD, XPath). - Plain HTTP adapter

- (t)RFC adapter

- Synchronous vs. asynchronous communication Technical prerequisites:

- the R/3 application must be configured to be able to create purchase orders. A material number is available in the system, with sufficient inventory level. Also a vendor number is available (for example via successful completion of exercise 1).

4. Purchase Order creation – Proxy to BAPI (synchronous)

As a follow-up to exercise 3, we will generate an ABAP proxy for the PO XML data. The proxy will be deployed in a SAP WebAS 6.40 client and called synchronously. This will show the out-of-the-box and adapter-less communication between XI and any WebAS-based application system. Also, this will further demonstrate the reusability of existing objects with XI.

XI Features exercised

- ABAP proxy: development and runtime. - Outside-in development approach with XI Technical prerequisites

- WebAS 6.40 client available - Same as exercise (3).

5. BPM Introduction – simple pattern

This exercise falls outside the context of the business scenario. Because BPM in general is such a complex area, the goal of the exercise is to familiarize the student with the basic features of the modeling tool. The implementation of the business scenario will continue in the next exercise. 6. PO creation + confirmation – BPM asynchronous-synchronous bridge

This is an extension of exercise (3). We introduce the use of Business Process Modeling (BPM) and the Business Process Engine (BPE). This will be a simple BPM use case, and a common customer requirement called asynchronous to synchronous bridge. The HTTP client posts the XML PO request asynchronously to XI (using quality of service “Exactly Once”). BPM takes control of the process and posts the BAPI synchronously into the R/3 system. Upon receiving the BAPI response containing the PO number, BPM will send a message asynchronously to the legacy system, as a flat file. This addresses a common customer requirement, to be able to mix asynchronous and synchronous processing within the same transaction. In the more advanced variation of this exercise, an alert will be triggered in case of negative response from the BAPI.

(42)

SAP Exchange

Infrastructure

(43)

©SAP AG 2004, TBIT40 02 SLD 2

Topics

Lecture topics

XI Overview

Security

(44)

After completing this unit, you will be able to: z Explain the purpose of the System Landscape

Directory and its role as an information provider. z Describe the content types in the System

Landscape Directory.

z Create Software Component descriptions in the System Landscape Directory.

z Define Technical Systems in the System Landscape Directory.

z Define Business Systems in the System Landscape Directory.

(45)

System Landscape Directory Overview

Central information provider for NetWeaver system landscapes Manage software components and platform dependencies Facilitate Installations, upgrades and transports

Based on Common Information Model (CIM) of the Distributed Management Task Force (DMTF)

Basis for SAP Solution Manager Information provider for SAP XI

The System Landscape Directory is a central repository of information about software and systems in the data center, expressed in a standard schema called the Common Information Model, or CIM.

CIM was developed by the Distributed Management Task Force, or DMTF, an industry consortium whose goal is to enable management of IT systems in distributed environments using web standards.

(46)

Aspects of system landscapes

System Landscapes have 3 dimensions: the solution dimension (i.e., what software processes are installed), the transport dimension (DEV, QAS, and PRD, for instance), and the technical dimension (what products are installed on which hosts on particular networks).

(47)

SLD content type

Component Information

Describes building blocks of solutions

Describes possible combinations and dependencies

Delivered by SAP, extensible by customer Landscape Description

Information on installed landscape elements

Customer-specific

SAP XI utilizes both types of content:

Integration Repository: Component Information Integration Directory: Landscape Description

There are two main areas of content in the SLD: the software catalog, and the systems catalog.

The Software catalog describes the installed products and their constituent components. The software catalog is delivered with content about all SAP products. Customers and Partners can extend this catalog with information about software from other vendors.

The Systems catalog describes the systems in the data center from two

perspectives: a logical view (business systems) and a physical view (technical systems). In other words, the Systems catalog describes the concrete

(48)

System Landscape Directory

Synchronize, XML PPMS Master Component Repository SAP Component Types Landscape Patterns Possible Combinations Customer Update System Landscape Directory Component information CIM 3rd_{-Party / Customer} Component Types Landscape description CIM Any Landscape Element Customer Landscape

Applications and Tools

Graphical Design Tool .. .. .. Software Logistics .. .. .. 1 1 2 Technical Configuration .. Validation .. .. Registration WBEM, XML WBEM, XML

Importing / synchronizing PPMS-data as XML-file into the Master Component Repository at the SAP-site. Therefore the Master Component Repository contains up-to-date information about all available SAP products.

The content of the Master Component Repository will be published on the Service Marketplace so that customers can update their individual component information.

Customers can insert additional information about 3rd_{-party products which are in}

operation by them into their individual component information.

The landscape description contains information about all installed products / components at customer‘s site.

Applications and tools (installation, administration etc.) can use information from the System Landscape Directory as a central information provider.

(49)

SLD: Products and Software Components

Software Component Product

Product Version Software Component Version

Software Feature 1 * * * * * 0..1 0..1

A Software Product (such as SAP R/3) may exist in multiple versions (such as 4.6c, 4.6d, 4.7 .

A Software Component is a unit of software delivery that has its own support package track. Example of Software Components are SAP_APPL, SAP_ABA, SAP_HR, etc.

A Software Product is composed of one or more software components. For instance, the product R/3 version 4.6C has components:

zSAP BASIS zSAP APPL

(50)

Example: SAP APO

An example of the relationship between software product version and its components: SAP APO v. 3.1.

(51)

Example: workshop exercise

Product Product Version Software Component Software Component Version 1 1 n n Software Feature: Associations TBIT40_WORKSHOP ##, 1.0 of SAP TBIT40_WORKSHOP, 1.0 of SAP TBIT40_WORKSHOP of SAP TBIT40_WORKSHOP ## of SAP

This workshop uses the above Software Product and Component for organizing development work.

(52)

Defining the Software Component

Select the Product from the drop-down

Enter the software vendor

Enter the Software Component Name

Enter the Software Component version (SWCV)

Choose “Create” To define a Software Component:

From the main screen of the SLD, choose “Software Catalog.”

Use the drop-down to select the Software Components type, and then select “New Component” to start the wizard.

Defining third-party Products and Software Components is easy in the SLD, because there are wizards to guide you through the process.

(53)

SLD: Technical System

Technical System WebAS ABAP Standalone JAVA Third Party

Name; host name; system number; Release Installed clients Message Server Installed Products Installed Products Business System Business Systems Business Systems Technical System ID WebAS Java

Name; host name; SID; System Home

In the Systems Catalog we define each Technical System in the landscape. The Technical System correlates the software to the physical host on which it is installed. The exact settings for each System depend on the system type.

Technical systems are the basis for defining Business Systems. The association between the Technical system and the Business Ssytem is dependent on the TS type; for instance, in a system based on SAP Web AS (ABAP), each client in the system is a separate Business System (this corresponds to the notion of a client as a Logical System in ALE

(54)

Defining the Technical System

From the Technical System browser choose “New Technical System…”

… select (and add) the products and components that are installed on the technical system...

… click “Finish.” … specify the Technical System Type…

To create a Technical System definition there is a wizard interface in the SLD. You can launch the wizard from the Technical System browser (from the main screen of the SLD, choose “Technical Landscape” under “System Landscape”). In the Technical System browser there is a button labeled “New Technical System” that starts the wizard.

The exact data to define the technical system depends on the Technical System type (see previous slide). For the workshop exercises you will create a Third-Party system type. Choose the appropriate system type and click “Next.”

In the subsequent screen(s), you will enter the specific details of the Technical System

(dependent on type); for the workshop exercises, we are using a third-party type and therefore need only detail the installed products. Of course, a technical system may have multiple products installed on it.

A product may be installed on a system without all of its possible components. For instance, the SWCV Internet Transaction Server (ITS) version 4.6C is a component of the product SAP R/3 version 4.6C; but it is possible to have a 4.6C system that is not using ITS. The wizard allows you choose the specific components associated with a system as follows:

For each selected product, the associated SWCV’s will be listed with checkboxes; you can deselect any components that are not part of the installation.

(55)

SLD: Business System

Business System

WebAS ABAP

WebAS Java

Third Party Systems

Related Integration Server client Installed Products Installed Products Technical System Technical System Technical System Name Standalone Java

Related Integration Server

Name Technical System

The Business System definition points to the appropriate Technical System. The SLD makes the appropriate association.

(56)

Defining the Business System

Give the system a unique name…

… specify the associated Technical System (and Logical System, if necesary)…

… select the installed products (from the technical system definition)…

… and the Related Integration Server

… click “Finish.”

For defining Business Systems, the four important pieces of data are:

Business System Name (must be unique in the landscape).

Associated Technical System, and if the Business System will be used with IDOC interfaces, a Logical System Name. Note that multiple Business Systems can be defined off of a single technical system (for instance, each numbered client of an SAP system is a unique Business System). The logical system name is mandatory in case the Business system will act as a sender or receiver of IDocs. In this case it should match exactly the logical system name as defined in the SAP client (if the Business system is of type WebAS-ABAP). The IDoc adapter will make use of this entry to resolve a Business system name into an ALE logical system name and vice-versa.

The Software Products (and associated SWCV’s) that are used by the Business System. The products are brought through from the Technical System definition; but for a particular Technical System, not all products will necessarily be associated with a particular

Business System. For instance, you may install mySAP SRM and mySAP CRM solutions as separate clients on a single (technical) system; but the Business System definition for each would only include the appropriate product (SAP SRM or SAP CRM).

The Related Integration Server. Application systems are associated with particular Integration Servers, which makes change management in the XI landscape easier.

(57)

SLD and XI Integration Repository

System Landscape Directory

Product Version Product

Software Component

Software Component Version Integration Repository (Design)

Application Component Role Product Version Software Component Version Business Scenario Interface Objects Mapping Objects

All design work in the Integration Repository is organized by Software Component Version. This makes sense, as interfaces logically belong to a software component and to a particular version. For instance, a BOMMAT03 IDOC is used by SAP systems from version 4.0 on, but a BOMMAT05 IDOC is used by SAP systems from 4.7 on. And, more specifically, the IDOC specifically belongs to the software component SAP APPL (which is why a BOMMAT IDOC does not exist in a Web AS with no application layer).

Before development can begin, the Software Component Versions (SWCV’s) ust be imported from the SLD to the Integration Repository.

(58)

SLD and Repository: usage dependencies

System Landscape Directory

Software Component Version A SAP Integration Builder

Repository (Design) Software Component Version A

Basis objects ...

Software Component Version B Usage Dependency

Software Component Version B

X X

A dependency can be defined in the SLD This dependency will be automatically detected in the Integration Repository

(59)

SLD and Directory

SAP Integration Directory (Configuration)

Routing Relations Sender Service: Receiver Service: Business System Business System Business System Technical System

System Landscape Directory A service object in the Integration

Directory can be derived from the SLD.

Routing Relations in the Integration Directory point to the Business Systems that are maintained in the System Catalog of the SLD, and through the appropriate association, to the technical systems.

(60)

Summary: object structure in SLD

To summarize: Products are collections of Software Components; both Software Products and Components exist in versions.

Products are installed on Technical Systems, which describe the concrete structure of Systems in the Data Center.

Applications communicate with Business Systems, which provide a logical view of the system that participate in a particular Integration Scenario.

(61)

You should now be able to:

z Explain the purpose of the System Landscape Directory and its role as an information provider. z Describe the content types in the System Landscape

Directory.

z Create Software Component descriptions in the System Landscape Directory.

z Define Technical Systems in the System Landscape Directory.

z Define Business Systems in the System Landscape Directory.

(62)

02 - SLDEx - File to IDoc1.doc 1

Exercise 1: File sender to IDoc Part 1: System Landscape Directory Overview

The purpose of this exercise is to implement a simple one-way, asynchronous link between a file sender and the R/3 system, using XI. As a result of this exercise, you will become familiar with the basic sequence of steps to implement a simple interface with XI. You will be able to

understand the structure of objects in the SLD, Integration Repository and Integration Directory. This exercise will also introduce the graphical mapping environment, the central J2EE adapter engine, the file adapter for sender systems and the IDoc adapter.

Prerequisites

Basic knowledge of XI architecture Description

A custom XML document containing vendor information is picked up from the file system by the file adapter. The message is mapped to IDoc-XML format and then routed to the IDoc adapter. The CREMAS IDoc (vendor master data) is posted into the backend R/3 system. A vendor will be created by the R/3 application.

Exercise steps

Step 1 – System Landscape Directory Step 2 – Integration Repository

Step 3 – Integration Directory Step 4 – Testing

*Please note, as a general rule, all development and configuration objects in XI are CASE-SENSITIVE.

Step 1 – SLD

Since this is the first exercise, we have to define a software component which will house all our development objects. This is done in the system landscape directory (SLD). We will also define a technical system and business system for the third party application which is sending the file. 1.1 Create software component.

1.1.1 Log in to the Integration Server client via SAPGUI and change your password.

1.1.2 From the main menu select “Start Integration Builder” (transaction SXMB_IFR). This will launch the Integration Builder homepage in a separate browser window.

XML Vendor Data CREMAS03 SAP R/3 4.6C Legacy System File IDoc

(63)

1.1.3 In the Integration Builder home page, select “System Landscape Directory”. This will bring up the SLD in a separate window (note the URL shortcut /sld).

1.1.4 Select “software catalog”. The list of all products appears. Browse around the list and inspect specific product versions by clicking on them. The details page will show you which software components are exposed for a given product.

You can go back to the main page by clicking “Back to Software Catalog”. 1.1.5 When you are finished browsing, from the software catalog screen select “Software

(64)

green box at the top of the screen. The fields of the wizard will be reset in order to allow you to create another SWC if necessary. Click “Cancel” to get out of the wizard.

Vendor: SAP

Name: TBIT40_WORKSHOP## (replace ## with your group number). Version: 1.0

1.2 Create technical system

1.2.1 Go to the SLD homepage (click “Home” in the upper left corner.) 1.2.2 Choose “Technical Landscape”.

(In the Technical System Browser, select technical system type: “Third-Party” to view the existing entries, but you don’t have to; this just preselects the type in the next step.) 1.2.3 Click “New Technical System…”. This will take you to the wizard.

1.2.4 For the type of technical system, select “Third-Party”. Click “Next>”

1.2.5 System Name: TBIT40_LEGACY_TS_## (replace ## with your group number). Host Name: localhost## (on the WTS server, we do not have different hosts). Click “Next>”.

1.2.6 Select “TBIT40_WORKSHOP, 1.0 of SAP” from the list of available products, then click “Add”. The product will appear in the “Selected Products” list. Verify that the software

(65)

component you created in the previous step is present and is checked. Uncheck all software components other than your own. Click “Finish”.

1.2.7 Verify in the technical system browser that the newly created object appears in the list under TS type: “third-party”.

1.3 Create Business System

1.3.1 In the SLD homepage, select “Business Landscape”.

1.3.2 Select “New business system”. This will take you to the wizard.

1.3.3 For the business system name, enter “TBIT40_LEGACY_BS_## (replace ## with your group number). Click “Next>”.

(66)

1.3.7 Finally, make sure that this business system is identified as an application system (as opposed to an integration server). Choose the appropriate related integration server (Integration_Server) from the drop-down list. Click “Finish”.

1.4 Software Components

For this exercise, there is an additional requirement to reuse some objects which are maintained centrally, in a separate software component called “TBIT40_BASE_COMP”, which we will refer to as the base component.

In the SLD you will now define a usage dependency between software components, and specify that your SWC “TBIT40_WORKSHOP##” will be based on SWC “TBIT40_BASE_COMP”. 1.4.1 From the SLD homepage, select “Software Catalog”.

1.4.2 As software type, select “Software Components”

1.4.3 Locate your own software component “TBIT40_WORKSHOP## of SAP” and click on the SWC version (1.0).

1.4.4 Click on “Usage Dependencies” and select “Define Dependencies”.

1.4.5 Important: in the screen “Define Dependencies”, select “Installation Time” from the drop down box.

1.4.6 Enter a filter “TBIT40*” to restrict the amount of components displayed.

1.4.7 Now select the SWC “TBIT40_BASE_COMP” from the list, and click “create”. You have now created a usage dependency.

(67)

Appendix: naming conventions and terminology Exercise 1 (replace ## with your group number)

Area Obj. type Object name Description

SLD Technical System TBIT40_LEGACY_TS_## Technical system for legacy app Business System TBIT40_LEGACY_BS_## Business system for legacy app Logical System WS## Logical system name for BS Software Component TBIT40_WORKSHOP## Individual SWC for exercises

(68)

SAP Exchange

Infrastructure

(69)

Topics

Lecture topics

XI Overview

Security

(70)

After completing this unit, you will be able to:

z Describe the Integration Repository and the objects that are created in it.

z Understand various Interface Objects and their roles in integration scenarios.

z Detail the use of web standards in the descriptions of interface objects in the Integration Repository.

z Explain the Proxy functionality in XI.

z Describe message mappings and list the different types of mappings available in XI.

z Explain Business Processes and their role in integration scenarios.

z Describe how to import various objects into the Integration Repository.

(71)

z You need to implement and Integration Scenario. z You must first create the appropriate objects and

processes in the Integration Repository.

Integration Repository: Business Scenario

(72)

Agenda

Integration Repository

XI 3.0 Integration Repository Overview and concepts

Software components and namespaces Interface objects

Proxy generation Mapping objects

Business Process objects Miscellaneous