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.
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. 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
6. Multiple vendor creation – BPM collect pattern (asynchronous)
This is another common BPM use case. We will revisit exercise 1 such that XI collects incoming vendor data and posts an IDoc package into the R/3 system, creating multiple vendors at a time. This addresses the customer requirement to be able to collect individual IDocs and post them as a package into the R/3 system, mainly for performance reasons.
XI Features exercised
- BPM building blocks: correlation, container objects
- BPM collect pattern
- Use of N:M mapping (multi-mapping) in the context of BPM
Technical prerequisites
- Same as exercise (1).
Appendix: naming conventions and terminology
General
| Area | Obj. type | Object name | Description |
| SLD | Vendor | SAP XI RIG US | Vendor used for all objects |
| Product | XI RIG US Workshop 1.0 | Product used for all objects | |
| SWC | XI RIG US workshop XX | Master SWC for solution | |
| SWC | XI RIG US workshop [00..30] | Individual SWC for exercises | |
| SWC | XI RIG US workshop base comp | Master SWC for usage dependency | |
| Int. Rep. | NS | urn:xiworkshop:xirig | Namespace for basis objects |
| 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 |
