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.

Legacy
System

XML XML Order RDBMS

Vendor Confirmation System
data
File

JDBC XML Vendor

SAP IDoc
IDoc
R/3 4.6C

RFC
BAPI HTTP
Web
Purchasing
Application
XML/Proxy XML Order Data
Order
request
SAP
WebAS 6.40
Purchasing app
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
scenario, and specific challenges which are typically encountered in integration projects.

The exercises build on top of each other, and are designed to be implemented in the given
sequence. However, the intent is to be as modular as possible, so each exercise can be
attempted independently, provided that all the technical prerequisites are met.

In the section below, for each exercise we explain which part of the complete scenario it is
implementing, which XI features it is exercising and the technical prerequisites. In addition we
outline which typical customer requirement is addressed with the scenario.
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
 - 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.

XI Features exercised
- BPM: async/sync bridge
- Flat file adapter (receiver)
- Triggering alerts from BPM.

Technical prerequisites
- Exercise (3) completed
 Appendix: naming conventions and terminology

General

Area Obj. type Object name Description

SLD Vendor SAP Vendor used for all objects
Product TBIT40_WORKSHOP, 1.0 Product used for all objects
SWC TBIT40_WORKSHOPXX Master SWC for solution
SWC TBIT40_WORKSHOP[00..30] Individual SWC for exercises
SWC TBIT40_BASE_COMP Master SWC for usage dependency
Int. Rep. NS urn:xiworkshop:groupXX:legacy Namespace for basis objects
in base component
RFC Z_BAPI_PO_CREATE Custom BAPI (base comp)
Int. Dir. C.C. XIWS_RFC_receiver RFC receiver comm. channel
C.C. XIWS_IDoc_receiver IDoc receiver comm. channel