SG 247220

Front cover
Connect WebSphere
Service-Oriented
Middleware to SAP
Business connectivity using WebSphere Enterprise
Service Bus, Process Server, and Message Broker
Integration scenarios using open
standards and WebSphere Adapters
Common broker-to-broker and
direct communication patterns
Saida Davies
Khirallah Birkler, Reinhard Heite
Uwe Klein, Mikko J. Mkel
Clara Akiko Matsuki
Pavel Parizek, Abdelkader Sall
Sascha Schefenacker
Robert Sulzmann
Torsten Wilms
ibm.com/redbooks
International Technical Support Organization

Connect WebSphere Service-Oriented Middleware
to SAP
May 2007
SG24-7220-00
Note: Before using this information and the product it supports, read the information in
Notices on page xix.
Version
Release
Modification
fix pack
Product Name
Product
Number
WebSphere Application Server
D5ATLL
IBM WebSphere Enterprise

Service Bus
D56UCLL
IBM WebSphere Enterprise

Service Bus
D56UCLL
IBM WebSphere Process Server
D558JLL
IBM WebSphere Process Server
D558JLL
IBM WebSphere MQ
5724-B41
IBMWebSphere MQ
5724-H72
IBM WebSphere Message Broker
D5245LL
IBM WebSphere Business

Integration Adapter for SAP
D555XLL
IBM WebSphere Adapter for SAP

software
D555XLL
Version
Release
Modification
Service
Pack
Product Name
18
SAP ERP 2004
IDES
3
SAP XI
First Edition (May 2007)
Copyright International Business Machines Corporation 2007. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Information about this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Part 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Introduction and objective of the book. . . . . . . . . . . . . . . . . . . . 3
1.1 Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 The scope of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Overview of the topics that this book covers . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 What is not covered in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2. Key technologies and concepts . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Enterprise requirements for connecting systems . . . . . . . . . . . . . . . . . . . 12
2.1.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Copyright IBM Corp. 2007. All rights reserved.
iii
2.1.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Integration logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 Consumability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.6 Infrastructure intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 From peer-to-peer to business process management . . . . . . . . . . . . . . . 14
2.2.1 Direct connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Common messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Central integration broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Enterprise service bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5 Business process management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Standards and technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Service component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Service Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.4 Java technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.5 Messaging and queuing technology . . . . . . . . . . . . . . . . . . . . . . . . . 29
Chapter 3. Product overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Introduction to the IBM SOA reference architecture . . . . . . . . . . . . . . . . . 34
3.1.1 IBM SOA reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Simple, rapid development and deployment . . . . . . . . . . . . . . . . . . . 39
3.2.2 Secure, scalable, highly available SOA runtime environment. . . . . . 40
3.2.3 Extensive communication services . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.4 Effective application management . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 IBM WebSphere Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 IBM WebSphere Process Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.1 SOA core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 IBM WebSphere Message Broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1 Choosing between WebSphere Message Broker or WebSphere
Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6 IBM WebSphere Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.1 IBM WebSphere Adapter for SAP Software . . . . . . . . . . . . . . . . . . . 51
3.6.2 IBM WebSphere Business Integration Adapter for mySAP.com. . . . 53
3.7 WebSphere Integration Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.7.1 Supports SOA development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7.2 Easy to build, test, and deploy J2EE applications. . . . . . . . . . . . . . . 56
3.7.3 Automated deployment tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.8 Reference documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9 Introduction to SAP Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.9.1 A short overview of SAP NetWeaver . . . . . . . . . . . . . . . . . . . . . . . . 58
3.9.2 SAP WebApplication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
iv
Connect WebSphere Service-Oriented Middleware to SAP
3.9.3 SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.9.4 Reference documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Part 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 4. Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1 Integration scenario tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.1 Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.2 Table synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Feasible integration scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.1 WebSphere Application Server invoking SAP XI using
Web Services (i) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.2 WebSphere Application Server invoking SAP J2EE using
Web Services (ii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.3 WebSphere Application Server invoking SAP WebAS (ABAP) using
Web Services (iii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.4 SAP XI invoking WebSphere Application Server using
Web Services (iv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.5 SAP J2EE invoking WebSphere Application Server using
Web Services (v) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2.6 SAP WebAS (ABAP) invoking WebSphere Application Server using
Web Services (vi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.7 WebSphere Process Server and WebSphere Enterprise Service Bus
invoking SAP XI using Web Services (vii). . . . . . . . . . . . . . . . . . . . . 86
invoking SAP J2EE using Web Services (viii). . . . . . . . . . . . . . . . . . 87
invoking ABAP using Web Services (ix) . . . . . . . . . . . . . . . . . . . . . . 88
4.2.10 SAP XI invoking WebSphere Process Server and WebSphere
Enterprise Service Bus using Web Services (x) . . . . . . . . . . . . . . . . 89
4.2.11 SAP J2EE invoking WebSphere Process Server/WebSphere
Enterprise Service Bus using Web Services (xi). . . . . . . . . . . . . . . . 90
4.2.12 SAP WebAS (ABAP) invoking WebSphere Process Server and
WebSphere Enterprise Service Bus using Web Services (xii) . . . . . 91
4.2.13 WebSphere Message Broker invoking SAP XI using
Web Services (xiii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.2.14 WebSphere Message Broker invoking SAP J2EE using Web Services
(xiv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2.15 WebSphere Message Broker invoking SAP WebAS (ABAP) using Web
Services (xv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2.16 SAP XI invoking WebSphere Message Broker using
Web Services (xvi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.17 SAP J2EE invoking WebSphere Message Broker using
Contents
Web Services (xvii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.2.18 SAP WebAS (ABAP) invoking WebSphere Message Broker using Web
Services (xviii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.19 WebSphere Application Server invoking SAP XI using JMS (xix). . 98
4.2.20 SAP XI invoking WebSphere Application Server using JMS (xx) . . 99
invoking SAP XI using JMS (xxi) . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Enterprise Service Bus using JMS (xxii) . . . . . . . . . . . . . . . . . . . . . 101
4.2.23 WebSphere Message Broker invoking SAP XI using JMS (xxiii) . 102
4.2.24 SAP XI invoking WebSphere Message Broker using JMS (xxiv) . 103
4.2.25 WebSphere MQ connecting to SAP XI using JMS (xxv) . . . . . . . . 104
4.2.26 WebSphere MQ connecting to SAP J2EE using JMS (xxvi) . . . . . 105
4.2.27 SAP XI connecting to WebSphere MQ using JMS (xxvii) . . . . . . . 106
4.2.28 SAP J2EE connecting to WebSphere MQ using JMS (xxviii) . . . . 107
4.2.29 WebSphere Application Server invoking SAP ERP using SAP JCo
(xxix) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.30 WebSphere Application Server invoking SAP ERP using SAP JCo and
ALE (xxx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.2.31 SAP ERP invoking WebSphere Application Server using SAP JCo
(xxxi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.32 SAP ERP invoking WebSphere Application Server using SAP JCo and
ALE (xxxii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
invoking SAP ERP using JCA Adapter (xxxiii) . . . . . . . . . . . . . . . . 112
invoking SAP ERP using JCA Adapter and ALE (xxxiv) . . . . . . . . . 113
4.2.35 SAP ERP invoking WebSphere Process Server/WebSphere Enterprise
Service Bus using JCA Adapter and ALE (xxxv) . . . . . . . . . . . . . . 114
invoking SAP ERP using WebSphere Business Integration Adapter for
SAP (xxxvi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
SAP and ALE (xxxvii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
SAP and the ABAP Extension Module (xxxviii) . . . . . . . . . . . . . . . 117
4.2.39 SAP ERP invoking WebSphere Process Server and WebSphere
Enterprise Service Bus using WebSphere Business Integration Adapter
for SAP (xxxix) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
vi
for SAP and ALE (xl). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

for SAP and the ABAP Extension Module (xli) . . . . . . . . . . . . . . . . 120
4.2.42 WebSphere MQ sending IDOC into SAP ERP using MQ link for SAP
R/3 (xlii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.2.43 SAP ERP sending IDOC to WebSphere MQ using MQ link for SAP R/3
(xliii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.3 Implemented integration scenarios in this book . . . . . . . . . . . . . . . . . . . 124
4.3.1 Scenario graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.3.2 WebSphere Enterprise Service Bus invoking SAP Exchange
Infrastructure using Web Service (6A) . . . . . . . . . . . . . . . . . . . . . . 127
4.3.3 WebSphere Application Server invoking SAP Exchange Infrastructure
using Web Service (6B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.3.4 SAP Exchange Infrastructure invoking WebSphere Enterprise Service
Bus using Web Service (6C). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Infrastructure using JMS (7A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.3.6 SAP Exchange Infrastructure invoking WebSphere Enterprise Service
Bus using JMS (7B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.3.7 WebSphere Message Broker invoking SAP Exchange Infrastructure
using JMS (8A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3.8 SAP Exchange Infrastructure invoking WebSphere Message Broker
using JMS (8B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3.9 WebSphere Enterprise Service Bus invoking SAP Web Application
Server (ABAP) using Web Service (9A) . . . . . . . . . . . . . . . . . . . . . 133
4.3.10 WebSphere Application Server invoking SAP Web Application Server
using Web Service (9B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.3.11 SAP ERP invoking WebSphere Application Server using XML over
HTTP (10A). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.3.12 WebSphere MQ invoking SAP ERP using Web Service (10B) . . . 135
4.3.13 WebSphere Enterprise Service Bus executing a single BAPI using
WebSphere Adapter for SAP (11A) . . . . . . . . . . . . . . . . . . . . . . . . 136
4.3.14 WebSphere Enterprise Service Bus executing a multiple BAPIs using
WebSphere Adapter for SAP (11B) . . . . . . . . . . . . . . . . . . . . . . . . 136
4.3.15 WebSphere Enterprise Service Bus executing a BAPI transaction
using WebSphere Adapter for SAP (11C) . . . . . . . . . . . . . . . . . . . 137
4.3.16 WebSphere Enterprise Service Bus executing the RFC_READ_TABLE
BAPI using WebSphere Adapter for SAP (11D) . . . . . . . . . . . . . . . 138
4.3.17 SAP ERP sending single IDOC to WebSphere Enterprise Service Bus
using WebSphere Adapter for SAP (12A) . . . . . . . . . . . . . . . . . . . 138
4.3.18 WebSphere Enterprise Service Bus sending single IDOC to SAP ERP
using WebSphere Adapter for SAP (12B) . . . . . . . . . . . . . . . . . . . 139
Contents
vii
4.3.19 WebSphere Enterprise Service Bus sending multiple IDOCs to SAP

ERP using WebSphere Adapter for SAP(12C) . . . . . . . . . . . . . . . . 140
4.3.20 SAP ERP sending business event to WebSphere Enterprise Service
Bus using WebSphere Business Integration Adapter for SAP and SIBus
(13A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.3.21 SAP ERP sending business event to WebSphere Enterprise Service
Bus using WebSphere Business Integration Adapter for SAP and MQ
link (13B). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Chapter 5. Configuring SAP XI for the SOAP and JMS-based scenarios143
5.1 Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.2 Overview of SAP XI configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.3 Common preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.4 Configuring the SAP System Landscape Directory. . . . . . . . . . . . . . . . . 149
5.4.1 Defining software products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.4.2 Defining the business system for WebSphere Message Broker . . . 155
5.4.3 Defining the business system for WebSphere ESB . . . . . . . . . . . . 158
5.4.4 Defining the business system for SAP ECC . . . . . . . . . . . . . . . . . . 160
5.4.5 Defining the software component in the integration repository . . . . 163
5.5 Configuring the SOAP outbound scenario in
SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.5.1 Overview of the SOAP outbound scenario . . . . . . . . . . . . . . . . . . . 165
5.5.2 Preparing the integration repository for the SOAP
outbound scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.5.3 Configuring the Integration Directory . . . . . . . . . . . . . . . . . . . . . . . 179
5.5.4 Exporting the WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5.6 Configuring the SOAP inbound scenario in SAP Exchange Infrastructure190
5.6.1 Overview of the SOAP inbound scenario . . . . . . . . . . . . . . . . . . . . 191
5.6.2 Preparing the Integration Repository for the SOAP
inbound scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.6.3 Configuring the Integration Directory . . . . . . . . . . . . . . . . . . . . . . . 201
5.7 Configuring the JMS outbound scenarios in
5.7.1 Overview of the JMS outbound scenario . . . . . . . . . . . . . . . . . . . . 212
5.7.2 Preparing the Integration Repository for the JMS
outbound scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5.7.3 Exporting the XML schema files . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
5.7.4 Configuring ItsoEsbJmsOutboundScenario in the
Integration Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
5.7.5 Configuring ItsoWmbJmsOutboundScenario in the
5.8 Configuring the JMS inbound scenarios in SAP XI . . . . . . . . . . . . . . . . . 264
5.8.1 Overview of the JMS inbound scenarios . . . . . . . . . . . . . . . . . . . . . 265
viii
5.8.2 Preparing the Integration Repository for JMS inbound scenario. . . 271
5.8.3 Configuring ItsoEsbJmsInboundScenario in the
5.8.4 Configuring ItsoWmbJmsInboundScenario in the
5.9 Preparing the SAP Exchange Infrastructure runtime . . . . . . . . . . . . . . . 323
Chapter 6. Web Services based integration to SAP Exchange Infrastructure
scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
6.1 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
6.2.1 Scenario A: WebSphere Enterprise Service Bus consuming Web
Service from SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . 330
6.2.2 Scenario B: WebSphere Application Server consuming Web Service
from SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 330
6.2.3 Scenario C: SAP Exchange Infrastructure consuming Web Service from
WebSphere Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . 330
6.2.4 Extension A: WebSphere Process Server consuming Web Service from
SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
6.2.5 Extension B: SAP Exchange Infrastructure consuming Web Service
from WebSphere Process Server . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.3.1 WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.3.2 SAP XI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.4 Scenario A: WebSphere Enterprise Service Bus consuming Web Service
from SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
6.4.1 Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
6.4.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
6.4.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
6.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
6.5 Scenario B: WebSphere Application Server consuming Web Service from
6.5.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
6.5.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
6.5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
6.6 Scenario C: SAP Exchange Infrastructure consuming Web Service from
WebSphere Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
6.6.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
6.6.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
6.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
6.8 Extension A: WebSphere Process Server consuming Web Service from SAP
Contents
ix
Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

6.8.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
6.8.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
6.8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
6.9 Extension B: SAP Exchange Infrastructure consuming Web Service from
WebSphere Process Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
6.9.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
6.9.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
6.9.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Chapter 7. JMS-based integration scenarios between WebSphere
Enterprise Service Bus and SAP Exchange Infrastructure . 495
7.2.1 Scenario A: WebSphere Enterprise Service Bus
as a JMS consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
7.2.2 Scenario B: WebSphere Enterprise Service Bus as a
JMS provider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
7.2.3 Extension A: WebSphere Process Server as a JMS consumer . . . 498
7.2.4 Extension B: WebSphere Process Server as a JMS provider . . . . 498
7.3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
7.3.1 Configuring SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . 498
7.3.2 Configuring WebSphere Enterprise Service Bus V6 . . . . . . . . . . . . 499
7.4 Scenario A: WebSphere Enterprise Service Bus
as a JMS consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
7.4.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
7.4.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
7.4.4 Deployment to WebSphere Enterprise Service Bus . . . . . . . . . . . . 553
7.4.5 Execution and test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
7.4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
7.5 Scenario B: WebSphere Enterprise Service Bus as a JMS provider . . . 558
7.5.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
7.5.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
7.5.4 Deployment to WebSphere Enterprise Service Bus . . . . . . . . . . . . 616
7.5.6 Verifying messages using Cloudview . . . . . . . . . . . . . . . . . . . . . . . 623
7.5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
7.6 Extension A: WebSphere Process Server as a JMS consumer . . . . . . . 625
7.6.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

7.6.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
7.6.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
7.6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
7.7 Extension B: WebSphere Process Server as a JMS provider. . . . . . . . . 649
7.7.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
7.7.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
7.7.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
7.7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Chapter 8. JMS-based integration scenarios between WebSphere Message
Broker and SAP Exchange Infrastructure . . . . . . . . . . . . . . . 671
8.2 An overview of how to configure scenarios
in WebSphere Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
8.3 Preparing the Message Broker Environment . . . . . . . . . . . . . . . . . . . . . 677
8.3.1 Setting up the queue manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
8.3.2 Configuring the broker and configuration manager . . . . . . . . . . . . . 681
8.3.3 Configuring the domain connection. . . . . . . . . . . . . . . . . . . . . . . . . 682
8.4 Scenario A: Configure the JMS outbound scenario in WebSphere Message
Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
8.4.1 Overview of the configured scenario . . . . . . . . . . . . . . . . . . . . . . . . 686
8.4.2 Configuring the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
8.4.3 Testing the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
8.5 Scenario B: Configure the JMS inbound scenario in WebSphere Message
Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
8.5.1 Overview of configured scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
8.6 Configuring the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
8.6.1 Building message set and message definition files. . . . . . . . . . . . . 741
8.6.2 Building the message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
8.6.3 Deploying message set and message flow . . . . . . . . . . . . . . . . . . . 763
8.6.4 Testing the JMS inbound scenario . . . . . . . . . . . . . . . . . . . . . . . . . 768
8.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Chapter 9. Web Services based integration to SAP WebApplication Server
scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
9.2.1 Scenario A: Web Service based access to SAP
WebApplication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Contents
xi
9.2.2 Scenario B: Send an IDoc using a Web Service into SAP . . . . . . . 777
9.2.3 Extension A: WebSphere Process Server deployment
and test process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
9.3 Scenario A: Web Service based access to
SAP WebApplication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
9.3.2 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
9.3.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
9.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
9.4 Scenario B: Send an IDoc using a Web Service into SAP . . . . . . . . . . . 824
9.4.2 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
9.4.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
9.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
9.5 Extension A: WebSphere Process Server deployment and test process 851
9.5.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
9.5.3 Deploying to WebSphere Process Server. . . . . . . . . . . . . . . . . . . . 872
9.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Chapter 10. XML-based exchange of IDocs between WebSphere Application
Server and SAP WebAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
10.1 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
10.2 Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
10.2.1 Scenario A: Sending an IDoc from SAP to WebSphere Application
Server using XML/HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
10.2.2 Scenario B: Build a WebSphere MQ to SAP bridge . . . . . . . . . . . 879
10.3 Scenario A: Sending an IDoc from SAP to WebSphere Application Server
using XML/HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
10.3.1 Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
10.3.2 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
10.3.3 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
10.3.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
10.3.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
10.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
10.4 Scenario B: Build a WebSphere MQ to SAP bridge . . . . . . . . . . . . . . . 903
10.4.2 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
10.4.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
10.4.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
10.4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
xii
Chapter 11. Adapter-based integration to SAP: JCA Adapter

BAPI scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
11.1 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
11.2 Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
11.3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
11.3.1 Installing SAP JCo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
11.3.2 Installing WebSphere Adapter for SAP Software . . . . . . . . . . . . . 955
11.3.3 Deploying WebSphere Adapter for SAP Software . . . . . . . . . . . . 960
11.3.4 Configuring J2C authentication data . . . . . . . . . . . . . . . . . . . . . . . 963
executes a single BAPI call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
11.4.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
11.4.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
11.4.4 Execution and test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
11.4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
11.5 Scenario B: WebSphere Enterprise Service Bus executes a multiple BAPI
call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
11.5.1 Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
11.5.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
11.5.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
11.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
11.6 Scenario C: WebSphere Enterprise Service Bus executes a transactional
BAPI call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
11.6.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
11.6.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
11.6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
11.7 Scenario D: WebSphere Enterprise Service Bus
uses Read Table RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
11.7.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
11.7.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
11.7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
11.8 Extension A: Dynamic authentication . . . . . . . . . . . . . . . . . . . . . . . . . 1117
11.8.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
11.8.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
11.8.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
Contents
xiii
11.9 Extension B: WebSphere Process Server

deployment and test process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
11.9.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140
11.9.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
11.9.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Chapter 12. Adapter-based integration to SAP: WebSphere Adapter for SAP
Software ALE scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
12.1 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160
12.2 Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
receives SAP IDOCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
12.2.2 Scenario B: WebSphere Enterprise Service Bus sends a single SAP
IDOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
12.2.3 Scenario C: WebSphere Enterprise Service Bus sends batch SAP
IDocs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
inbound ALE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
12.2.5 Extension B: WebSphere Process Server deployment
outbound ALE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
12.3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
12.3.1 SAP RFC destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
12.3.2 SAP tRFC port in IDoc processing . . . . . . . . . . . . . . . . . . . . . . . 1165
12.3.3 SAP Logical System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
12.3.4 SAP Distribution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
12.3.5 SAP Partner profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
12.3.6 Installing SAP JCo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
12.3.7 Installing WebSphere Adapter for SAP Software . . . . . . . . . . . . 1178
12.3.8 Deploying WebSphere Adapter for SAP Software . . . . . . . . . . . 1182
12.3.9 Configuring J2C authentication data . . . . . . . . . . . . . . . . . . . . . . 1185
12.4 Scenario A: WebSphere Enterprise Service Bus receives SAP IDOCs1190
12.4.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
12.4.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
12.4.4 Execution and Test: ALE Inbound - Single IDoc . . . . . . . . . . . . . 1221
12.4.5 Execution and test: ALE inbound with acknowledgement. . . . . . 1225
12.4.6 Execution and test: ALE inbound - batch IDocs . . . . . . . . . . . . . 1229
12.4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235
12.5 Scenario B: WebSphere Enterprise Service Bus
sends a single SAP IDOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
xiv
12.5.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238

12.5.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
12.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257
12.6 Scenario C: WebSphere Enterprise Service Bus
sends batch SAP IDocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
12.6.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
12.6.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
12.6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
12.7 Extension A: WebSphere Process Server deployment inbound ALE . 1283
12.7.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
12.7.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
12.7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
12.8 Extension B: WebSphere Process Server deployment outbound ALE 1302
12.8.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
12.8.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312
12.8.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
Chapter 13. Adapter-based integration to SAP: WebSphere Business
Integration Adapter scenarios . . . . . . . . . . . . . . . . . . . . . . . . 1323
13.1 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
13.2 Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
13.2.1 Scenario A: Advanced Event notification with SI Bus . . . . . . . . . 1326
13.2.2 Scenario B: Advanced Event notification with WebSphere MQ . 1326
13.3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327
13.3.1 Installing the WebSphere Business Integration Adapter
or mySAP.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327
13.3.2 Installing WebSphere MQ V5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
13.3.3 Installing WebSphere Business Integration Adapter Framework 1341
13.3.4 Installing WebSphere Business Integration Adapter
or mySAP.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
13.3.5 Verifying the WebSphere Business Integration Adapter
installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352
13.3.6 Installing the SAP Java API (SAP JCo) . . . . . . . . . . . . . . . . . . . 1352
13.3.7 Installing other required software . . . . . . . . . . . . . . . . . . . . . . . . 1353
13.3.8 Preparing the SAP environment . . . . . . . . . . . . . . . . . . . . . . . . . 1353
13.4 Development steps common to both scenarios . . . . . . . . . . . . . . . . . 1363
Contents
xv
13.4.1 Creating an integration component library . . . . . . . . . . . . . . . . . 1363

13.4.2 Developing an event business object . . . . . . . . . . . . . . . . . . . . . 1364
13.4.3 Starting the target server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370
13.5 Scenario A: WebSphere Business Integration Adapter Advanced Event
notification - SIBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371
13.5.2 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1372
13.5.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
13.5.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
13.5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
13.6 Scenario B: WebSphere Business Integration Adapter Advanced Event
notification - WebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
13.6.2 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
13.6.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
13.6.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
13.6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453
xvi
Examples
2-1 SDO programming example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5-1 The location of soap:address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6-1 Invoke the UserExistenceIF interface from JSP page. . . . . . . . . . . . . . . 381
6-2 Example JSP code for index.jsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
6-3 Implement the getUserList method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
6-4 Process validation error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
6-5 Include directives with relative paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
6-6 Include directives without a path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
7-1 getUserList method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
7-2 Method generateEISFunctionName . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
8-1 The itsousdb.sql file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
8-2 insertTestdata.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
10-1 The doPost method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
10-2 The doGet method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
10-3 The MQSAP_Bridge Java class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
11-1 Code to fill dynamic authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
13-1 Values to create a new entry for a workflow event . . . . . . . . . . . . . . . 1358
13-2 Values to create a configuration object . . . . . . . . . . . . . . . . . . . . . . . . 1360
13-3 Create new BI Object parameter configuration . . . . . . . . . . . . . . . . . . 1361
13-4 Create new BI Object parameter configuration . . . . . . . . . . . . . . . . . . 1362
13-5 startAdapter.bat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381
13-6 Configuring WebSphere MQ to be used with the scenario . . . . . . . . . 1403
13-7 MQ_SAP_Setup.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403
xvii
13-8 startAdapter2.bat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
xviii
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
xix
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
iSeries
z/OS
AIX
CICS
DB2 Universal Database
DB2
Encina
IBM
Lotus
MQSeries
Parallel Sysplex
PowerPC
Rational
Redbooks
SupportPac
Tivoli
WebSphere
The following terms are trademarks of other companies:
BAPI, ABAP, SAP xApps, SAP NetWeaver, mySAP.com, mySAP, SAP R/3, SAP, and SAP logos are
trademarks or registered trademarks of SAP AG in Germany and in several other countries.
Enterprise JavaBeans, EJB, Java, JavaBeans, JavaServer, JavaServer Pages, JDBC, JDK, JRE, JSP,
JVM, J2EE, J2ME, J2SE, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
xx
Microsoft, Visual Basic, Windows, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
Notices
xxi
xxii
Preface
This book demonstrates the use of IBM Service-Oriented Middleware products
to integrate data and processes located in SAP back-end systems. IBM
provides different Integration Brokers with a wide range of application and
technology adapters that can be used to build robust, flexible and extensible
integration scenarios in very fast implementation cycles.
The first part of this book introduces general concepts and challenges that a
service-oriented business integration architecture has to fulfill and to overcome.
It describes prevalent terminologies in more detail to get an overall view of all
involved components. It also introduces the various IBM WebSphere
Service-Oriented Middleware products and the relevant SAP products to provide
a common understanding of all the participating components. In addition, it
discusses how IBM service-oriented architecture relates to the SAP Enterprise
Service Architecture.
The second part highlights common integration scenarios and communication
patterns in more technical detail. Each scenario includes technical configuration
and step-by-step guidance.
In this book, we use the following WebSphere middleware products to implement
the chosen scenarios:
IBM WebSphere Application Server 6.0.2.9
IBM WebSphere Enterprise Service Bus 6.0.1 and 6.0.1.2
IBM WebSphere Process Server 6.0.1 and 6.0.1.2
xxiii
IBM WebSphere MQ 5.3.0.12

IBM WebSphere MQ 6.0
IBM WebSphere Message Broker 6.0
IBM WebSphere Business Integration Adapter for SAP 6.0.5
IBM WebSphere Adapter for SAP software 6.0.0.1
SAP ERP 2004 IDES-Version
SAP XI 3.0 SP 18
The standards-based integration scenarios use the Web Services and Java
Messaging Service capabilities that are built in to the WebSphere middleware
products and SAP.
Finally, the appendixes provide the source code and scripts that we use to
implement the scenarios.
The team that wrote this book

This book was produced by a team of specialists from around the world working
for the International Technical Support Organization (ITSO), Raleigh Center, at
IBM Deutschland Entwicklung GmbH, Boeblingen, Germany.
Saida Davies is a Project Leader for the ITSO and has extensive experience in
IT. She has published several IBM Redbooks publications on WebSphere
Business Integration topics for multiple platforms. Saida has experience in the
architecture and design of WebSphere MQ solutions, extensive knowledge of
z/OS operating system, and a detailed working knowledge of both IBM and
Independent Software Vendors operating system software. In a customer facing
role as a senior IT specialist with IBM Global Services, her responsibilities
included the development of services for WebSphere MQ within the z/OS and
Windows platform. This covered the architecture, scope, design, project
management, and implementation of the software on stand-alone systems or on
systems in a Parallel Sysplex environment. She has received Bravo Awards for
her project contributions. Saida has a degree in Computer Studies and her
background includes z/OS systems programming. Saida supports Women in
Technology activities and contributes and participates in the their meetings.
Khirallah Birkler is an IT Architect for IBM Software Group Germany. He joined
IBM eight years ago and started at the central site of IBM that installs, tests, and
assesses all new SAP products, releases, and tools. In the last four years, he
has been working in the Boeblingen laboratories and is responsible for building
WebSphere SAP related architectures. His main responsibility is to evaluate,
design, and architect areas where IBM and SAP software can be used in
conjunction. Khirallah helps worldwide key customers assess scenarios where
IBM software can be placed to complement SAP infrastructures. He is an IBM
xxiv
Certified Solution Designer for service-oriented architectures, specialized to

combine SAP NetWeaver and the WebSphere middleware process platform.
He has 10 years of experience in the J2EE and software development area as
well as eight years of experience with SAP Basis, from 4.0 to the latest
NetWeaver release. He holds a Bachelor of Science degree in Information
Technology Management from the University of Cooperative Education,
Stuttgart.
Reinhard Heite is an IT Architect with IBM Global Business Services. He has 17
years of experience working for IBM. His areas of expertise include distributed
computing, IT security, and designing and implementing e-business solutions.
For the last three years, he has worked for the IBM/SAP Collaboration
Technology Support Center (CTSC) in Walldorf, focussing on supporting
customers and partners on interoperability scenarios between IBM WebSphere
and SAP NetWeaver. He holds a degree in Computer Science from the
University of Bonn and received a Ph.D. in Computer Science from the University
of Erlangen.
Uwe Klein is an IT Specialist at IBM Global Services. He is a member of the IBM
AMS SAP World Wide Beta Test Site in Germany, which is the SAP Customer
Competence Center within IBM that installs, tests, and assesses all new SAP
products, releases, and tools. He has worked and continues to contribute in
many SAP integration projects for the last seven years. His main responsibility is
to evaluate, design, and implement customer specific SAP software
enhancements and his areas of expertise includes SAP-ABAP/4, SAP
ALE/BAPI/RFC, SAP XI. Uwe joined IBM in1984 and is a certified automation
engineer.
Mikko J. Mkel is an IT Architect with IBM Global Business Services in Finland.
He joined IBM in 2005 and has 10 years of experience in the IT industry. His
areas of expertise include system integration, J2EE, SOA and software
development processes. In his current position, Mikko performs a customer
facing role and his responsibility includes architect, design, and implement
complex system integrations, as well as portal and content management
solutions. During his career, he has successfully delivered several solutions to
Nordic telecommunications, governmental, and retail organizations that are now
running in a production environment. He has extensive experience in
implementing solutions on various middleware platforms, including IBM
WebSphere and BEA WebLogic/AquaLogic. Mikko holds a Master of Science
degree in Technology from the Helsinki University of Technology.
Clara Akiko Matsuki is an ERP Systems Support analyst for IBM Integrated
Technology Delivery, Server Systems Operations in Brazil. She joined IBM
seven years ago and started as an SAP Basis support analyst for IBM Brazil
outsourcing customers. In the last three years, she has continued in the same
Preface
xxv
role and now, additionally, supports international customers and projects. Her
main responsibilities are to support and administer customer's SAP systems,
which include installations, upgrades, and migrations. She has extensive
experience in systems support whereby, she has worked as an output
management system instructor and a college professor in computer introduction
and scientific methodology. Clara is certified in the Hewlett Packard Output
Server (Dazel) and has supported this product for two years for an international
customer. Clara holds a Master degree in Information Systems Management and
Bachelor in Systems Analysis from PUC (Pontificia Universidade Catolica), in
Campinas, Sao Paulo, Brazil and speaks four languages.
Pavel Parizek is an IT Consultant for IBM Software Group, Application
Integration Middleware Group. He joined IBM in 1989. His experience includes
WebSphere Application server, WebSphere Portal server, WebSphere Process
server, and Encina / DCE. Currently, he works for the IBM Business Partner
Technical Enablement team, where his main responsibility is to assist in
development of proof of concept, evaluate and validate scenarios in the area of
WebSphere and SAP integration. Before joining IBM, he was software developer
in the medical, Wall Street, and banking industries.
Abdelkader Sall is a senior Consultant working for Lader Systems Ltd based in
Oxford, UK. He has Over seven years of IT experience in the areas of SAP and
IBM WebSphere products. His main responsibility is to provide consulting
services to global customers and his assignments include designing and
implementing integration solutions using SAP, WebSphere interchange Server
and WebSphere Process Server. He is an SAP Certified Development
Consultant, an IBM Certified System Administrator for WebSphere Application
Server Network Deployment V6.0, and also an IBM Certified Deployment
Professional for WebSphere Process Server v6.0. He holds a Master degree in
Applied Mathematics from the University of Paris-Sud XI, France.
Sascha Schefenacker is an IT Architect for IBM Software Group Germany. He
joined IBM six years ago. In the last four years, his work has been strongly SAP
specific. He is currently part of the WebSphere SAP Technology Team (WSTT)
in the Boeblingen laboratories. The team is responsible for building WebSphere
SAP related architecture, including customer assignments and proof of concepts.
His main responsibility is to evaluate, design, and architect areas where IBM can
be used in conjunction with SAP software. His additional focus are WebSphere
Portlet Factory, Rational Application Developer and Portal based Projects.
Sascha helps worldwide key customers assess scenarios where IBM software
can be placed to complement SAP infrastructures. He is an IBM Certified
Solution Designer for service-oriented architectures, specialized to combine SAP
NetWeaver and the WebSphere middleware process platform. He holds a
Bachelor of Science degree in Information Technology; Project management,
and e-business from the University of Cooperative Education, Stuttgart.
xxvi
Robert Sulzmann is a Senior IT Consultant for IBM Software Group Germany.

After graduation in computer science, he joined IBM 1989 and started at IBM
Development Lab in Boeblingen, Germany. He worked in software development
of security solutions, smart card software and WebSphere Portal Server. In the
last four years, he has been working for the Software Group Business Partner
Technical Enablement Team in the Boeblingen lab. His main responsibility is to
evaluate, design, and architect areas where IBM can be used in conjunction with
SAP software. Robert helps worldwide key customers assess scenarios where
IBM software can be placed to complement SAP infrastructures. He has several
years experience in the J2EE software development area and has a master
certification as a project manager at Washington University.
Torsten Wilms Torsten Wilms is an IT Specialist for IBM Software Group
Germany. Since 2005, he has worked within the Lab based Service Team of the
WebSphere Solution Center in the development laboratory in Boeblingen,
Germany. In his current role, he provides expert knowledge about the newest
versions of WebSphere Process Server and assists customers to design and
implement IBM WebSphere and SAP business integration scenarios. After
obtaining his degree in Business Information Systems, Torsten joined IBM in
2001 and started at the AMS World Wide Beta Test Site, which is part of the IBM
SAP Customer Competence Center. His responsibilities were SAP integration
proof of concepts.
Figure 1
From left: Mikko, Reinhard, Uwe, Clara, Robert, Sascha, Saida, Pavel, Torsten, Khirallah, and
Abdelkader
The photo was taken by Ms. Mareike Lattermann.
Preface
xxvii
The ITSO would like to express its special thanks to the IBM Deutschland
Entwicklung GmbH, Boeblingen, Germany for hosting this project, providing the
human resources, hardware, software, and access to SAP systems. Also to IBM
SAP International Competence Center (ISICC), Walldorf, Germany for providing
access to SAP systems.
Sincere thanks
Mark Giles, Manager
iSV Enablement, IBM Software Group, Application and Integration
Middleware Software, IBM Austin, USA for his total support to this project.
Marks support throughout the project was invaluable and the majority of the
resource was also assigned from his department.
Daniel Moellenbeck
IT Consultant, IT-Services, SAP Consulting, EAI, SAP Germany for his
valuable consulting time towards the configuration and of SAP XI and reviews
of the scenarios.
The team would also like to thank the following people for their guidance,
assistance, and contributions to this project:
Colin Hofmann
Senior Consultant SAP NetWeaver XI, IBM Germany
Christian Holsing
IBM SAP International Competence Center, Lotus Software, IBM Sales and
Distribution, Software Sales, IBM Germany
Alasdair Paton
WebSphere MQ Brokers, System Test team lead, IBM Software Group,
Application and Integration Middleware Software, IBM Hursley, U. K.
Mark Phillips
WebSphere MQ Technical Strategy, XMS, Web Services and Client APIs,
IBM Software Group, Application and Integration Middleware Software, IBM
Hursley, U. K.
Ariel G Polanco
Account Manager, Business Development EMEA, IBM Sales and Distribution,
Software Sales, IBM Mnchen, Germany
Zafrulla Khan
Software Engineer, WebSphere Business Integration Adapters, IBM Software
Group, Application and Integration Middleware Software, IBM CA, U. S.
Heiko Scholtes
IBM WebSphere Process Integration Level 2 Customer Support Engineer,
IBM Software Group, Application and Integration Middleware Software, IBM
Germany
xxviii
Elise Sivilay
Global Partner Manager IBM, SAP AG for support and assistance with legal
requirements
Stephen Todd, STSM
Messaging systems (especially message and database interactions), IBM
Software Group, Application and Integration Middleware Software, IBM
Hursley, U. K.
Become a published author

Join us for a two- to six-week residency program! Help write a book dealing with
specific products or solutions, while getting hands-on experience with
leading-edge technologies. You'll have the opportunity to team with IBM
technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about
this book or other IBM Redbooks in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface
xxix
xxx
Information about this book

This book extends WebSphere Business Integration for SAP, SG24-6354, which
demonstrated the use of WebSphere Business Integration products to integrate
data and processes located in SAP back-end systems.
In this book, IBM Service-Oriented Middleware products, such as WebSphere
Enterprise Service Bus, WebSphere Process Server, WebSphere MQ,
WebSphere Adapter for SAP Software, and WebSphere Business Integration
Adapter, are used to establish communication between WebSphere and SAP
back-end systems.
xxxi
xxxii
Part 1
Part
Overview
This part provides a general overview of the topics and concepts that we discuss
in this book. It includes the following chapters:
Chapter 1, Introduction and objective of the book on page 3
Provides an overview of the scope of this book and includes:
The objective of the book

The intended audience
Topics that the book covers and does not cover
Assumptions that we made when writing the content of this book
Chapter 2, Key technologies and concepts on page 11

Introduces the high-level concepts and terminology that we use in this book.
Chapter 3, Product overview on page 33
Includes general descriptions of products that are related to the sample
scenario solution illustrated in the later chapters.
Chapter 1.
Introduction and objective of

the book
This chapter includes an executive summary as well as an overview of the scope
of this book. It also provides a brief introduction to the contents of the book.
It discusses the following topics:
Executive summary on page 4

The scope of this book on page 5
Intended audience on page 6
Overview of the topics that this book covers on page 6
What is not covered in this book on page 8
Assumptions on page 9
1.1 Executive summary

Typical enterprises that use IT resources to support and execute their daily
businesses are facing the issue that the IT infrastructure has grown in the last
decades to a complex and heterogeneous environment. Steadily new upcoming
business requirements were the major drivers to introduce new components
continuously into the IT infrastructure regardless of the underlying technology,
platform, or operating system of these components. The introduction of a
middleware layer guarantees that all these different systems can communicate
with each other in a flexible and efficient manner.
The WebSphere product family from IBM provides one of the most powerful
middleware solutions in the marketplace. This superior technology is also
reflected by the huge market share that IBM WebSphere middleware products
hold in the small, medium, and large enterprise integration market.
IBM is the major driver of service-oriented architectures (SOA) and has shown its
commitment in these new architectural approaches by releasing a complete
ready-to-use SOA infrastructure. This SOA Foundation is an integrated, open set
of software, best practices, and patterns that provides what you need to get
started with SOA. The software that makes up the SOA Foundation has been
carefully selected from the broader IBM software portfolio to support each stage
of the SOA life cycle. Special attention within this new SOA reference
architecture is given to capabilities that enable you to incorporate your existing
components smoothly into the SOA. Dedicated Access Services facilitate
interactions with existing information and application assets. This provides a high
degree of reuse of existing components as well as the capability to transform
these components into the new architectural service and component-based
integration approach efficiently.
Because SAP software modules are widespread in customer environments, the
integration capabilities of WebSphere Service-Oriented Middleware makes these
components a key success factor for the entire IBM SOA Foundation. IBM
addresses this requirement as a high priority by launching a dedicated adapter to
integrate SAP business applications with their full functionality into the IBM SOA
Foundation. In addition, the IBM SOA Foundation supports all relevant open
standards and communication protocols that are necessary to communicate with
the SAP software modules as well as with SAP broker components. Finally, IBM
Service-Oriented Middleware can connect all SAP components in any fashion
into an enterprise-wide SOA.
1.2 The scope of this book

This book provides basic information that is designed to enable users to
configure the connections of WebSphere middware products to SAP applications
and SAP middware. It discusses the basic concepts of service-oriented business
integration and discusses the general requirements in this domain. The book
explains the common terminologies, disciplines, and abstract concepts areas
such as:
Integration brokers
Enterprise Service Bus
Business process execution
Standard based communications
Adapter based communications
Messaging patterns
Communication patterns
It also provides an overview of WebSphere middleware products and SAP

products and discusses various integration options between WebSphere
middleware products and SAP products.
This book further discusses some of the common integration solution designs
and demonstrates sample business scenarios. It shows the capabilities of the
different WebSphere middleware products in application connectivity and
illustrates these capabilities in scenarios. In particular, we investigate the various
connectivity approaches of WebSphere Message Broker, WebSphere Enterprise
Service Bus, and WebSphere Process Server using the WebSphere Adapters for
SAP Software or open standards to SAP back-end systems and SAP
middleware. We also explore various combinations of usage scenarios.
This book gives an architectural overview of what can be achieved and provides
a step-by-step guide to achieve the connection of certain WebSphere
middleware products and SAP products.
It focuses on the following main scenarios:
Web Services based integration of WebSphere middleware to SAP
JMS-based integration of WebSphere middleware to SAP Exchange
Infrastructure
WebSphere Adapter based integration to SAP
The scenarios include detailed information in the form of operational models,
preparation tasks, configuration tasks, testing, and conclusions.
Chapter 1. Introduction and objective of the book
1.3 Intended audience

The content of this book is oriented towards a broad audience, beginning with
managers, IT architects and consultants, and technicians. The book can give
guidance when requiring assistance in planning, designing, and implementing
integration scenarios between WebSphere middleware and SAP products.
This book is divided into two parts and each part is aimed at a specific audience.
Part 1, Overview on page 1 provides a general overview of the technologies
and concepts that we discuss in this book. This part of the book is best for
non-technical persons who need to understand the architectural challenges
that have to be overcome.
Chapter 3, Product overview on page 33 is aimed at management,
architects, and solution designers. It is also useful for users who are
interested in the enhanced features of the WebSphere products or require an
understanding of how to plan the integration of these WebSphere products to
SAP.
Part 2, Scenarios on page 71 provides information for technicians and
consultants who connect certain WebSphere middleware products to SAP
Exchange Infrastructure, SAP Enterprise Resource Planning, or SAP
WebApplication Server. This part provides detailed technical instructions and
guidance for the required steps.
This book is not targeted at new users. It does not provide information about how
to use the product. Thus, information about how to set up a WebSphere or SAP
environment and how to use all of the functions is beyond the scope of this book.
1.4 Overview of the topics that this book covers

This book is divided in two parts:
Part 1, Overview on page 1 includes the following chapters:
Chapter 1, Introduction and objective of the book on page 3 is the chapter
that you are reading now. It describes the objectives of this book project and a
high-level overview of what it covers such as the scope of this book, its
intended audience, the assumptions made by the team, and the aspects of
connecting WebSphere to SAP.
Chapter 2, Key technologies and concepts on page 11 describes the basic
concepts and terminology of requirements, disciplines and abstract concepts
such as Integration Broker, Enterprise Service Bus, Adapters Messaging,
Standards and others.
Chapter 3, Product overview on page 33 gives a introduction of WebSphere

and SAP products in a high-level overview, as well as the tools related to the
sample business scenario solutions illustrated in part 2.
Part 2, Scenarios on page 71 is comprised of chapters 4 to 13.
Chapter 4, Scenarios overview on page 73 describes the possible
integration scenarios and the chosen ones with overall and functional
graphical illustration and tables synopsis.
Chapter 5, Configuring SAP XI for the SOAP and JMS-based scenarios on
page 143 includes all the configurations of SAP XI which are required for the
configurations of all scenarios with SAP XI.
Chapter 6, Web Services based integration to SAP Exchange Infrastructure
scenarios on page 327 describes three scenarios and two extensions of
integration WebSphere Web Services based to SAP Exchange Infrastructure.
Chapter 7, JMS-based integration scenarios between WebSphere Enterprise
Service Bus and SAP Exchange Infrastructure on page 495 describes two
scenarios and two extensions of integration WebSphere JMS-based to Sap
Exchange Infrastructure.
Chapter 8 JMS-based integration scenarios between WebSphere Message
Broker and SAP Exchange Infrastructure on page 671 describes two
scenarios where WebSphere Message Broker connect to SAP Exchange
Infrastructure as a Service Provider and a Service Consumer.
Chapter 9, Web Services based integration to SAP WebApplication Server
scenario on page 775 describes two scenarios and one extension of
integration WebSphere Web Services based to SAP WebApplication Server.
Chapter 10, XML-based exchange of IDocs between WebSphere Application
Server and SAP WebAS on page 877 describes two scenarios of exchange
IDocs in XML format from SAP WebApplication Server to WebSphere Web
Services.
Chapter 11, Adapter-based integration to SAP: JCA Adapter BAPI
scenarios on page 951 describes four scenarios and two extensions of J2EE
Connector Architecture (JCA) Adapters Business Application Programming
Interface (BAPI) based to SAP, with a single, multiple or transactional calls
to access SAP Data by function modules or even tables.
Chapter 12, Adapter-based integration to SAP: WebSphere Adapter for SAP
Software ALE scenarios on page 1159 describes two scenarios of
integration WebSphere adapter for SAP Software and SAP Application Link
Enabling (ALE) interface. This is performed with single inbound with or
without acknowledgment, batch inbound, single outbound, batch outbound
interaction.
Chapter 13, Adapter-based integration to SAP: WebSphere Business

Integration Adapter scenarios on page 1323 describes three scenarios of
Advanced Event notification possibilities of WebSphere Business Integration
Adapters to SAP with two deployment options. Deployment on the Service
Integration Bus (SIB) which is included in the WebSphere Enterprise Service
Bus and WebSphere Process Server as well as the deployment in a
WebSphere MQ landscape.
You can find further details about the specific scenarios and environment setups
used in the connections in each scenarios chapters.
1.5 What is not covered in this book

This book does not cover:
Information about installation of any WebSphere middleware product or SAP
product. This book does not include step-by-step installation instructions.
Installation of prerequisite and corequisite software, such as WebSphere
Enterprise Service Bus and operating system updates.
Advanced information about the products architectures or about the
development, maintenance, and deployment of production systems.
The code examples that we use demonstrate the capability of the product and
how to perform basic tasks. The code examples that we include are not
designed to be high performance code. Thus, you should not use these
examples in test and evaluation environments only. They do not demonstrate
best practices with the product for production environments. Platform-specific
information is restricted to Windows and AIX, although much of the
information can be applied to other platforms.
You can find the broader description of the individual products and their features
from the reference material. See 3.8, Reference documentation on page 57.
1.6 Assumptions
This book makes a number of assumptions to simplify the information that we
present here and to make this information as useful and as relevant to as many
users as possible. We make the following assumptions:
Users have the appropriate security privileges on all the components that are
involved in the scenarios, including access to the operating system,
WebSphere middleware components, and SAP components.
Users are familiar with the usage, navigation, and administration of the
discussed WebSphere middleware products as well as the SAP products.
Users are familiar with the basic administrative activities on the Windows
operating system because all scenarios are implemented on Windows nodes.
Users have basic network skills that are required to set up and reproduce the
scenarios that we describe in this book.
We have tested the practical scenarios that we describe in this book with those
product versions that are listed in the Connect WebSphere Service-Oriented
Middleware to SAP and Preface. If you want to apply the scenarios that we
describe to other product versions, the implementation might differ.
10
Chapter 2.
Key technologies and

concepts
This chapter provides high-level concepts that you need to know regarding
integration. It gives a short introduction on historical integration approaches and
how these approaches have developed to the current days service-based
integration paradigm.
This chapter discusses the following topics:
Enterprise requirements for connecting systems on page 12
From peer-to-peer to business process management on page 14
Standards and technologies on page 21
11
2.1 Enterprise requirements for connecting systems

This chapter discusses how to connect the data and the processes of existing
enterprise information systems (EIS) into an overall business infrastructure. EIS
that are used in different business areas commonly run on different platforms,
and each EIS provides a typical interface and access mechanism. Given the
heterogeneity, a broad range of different requirements arise that must be
addressed to ensure that these systems are connected with each other in a
flexible and efficient manner. These requirements include:
Communication
Maintainability
Integration logic
Consumability
Quality of Service
Infrastructure intelligence
2.1.1 Communication
Typically most EIS have specific access mechanisms and might support only
proprietary protocols. The data formats used to exchange information is also
different from system to system as well as the communication styles such as
request and response, fire and forget, publish/subscribe, and event driven
patterns. Communication styles can also be categorized as synchronous or
asynchronous. Finally, the addressing schema between systems is also a
challenging topic. Discussing the communication requirements between
enterprise systems security is always a multi-fold issue with its whole broad
range from authorization, authentication, non-repudiation, and encryption to
confidentiality. This security discussion can be enriched by dealing with different
encoding and validation approaches of the different data formats.
2.1.2 Maintainability
Whenever several systems have to be managed, the desire to have a common
administration arises. The requirement to have a unified view across all
connected systems is also true for other essential topics such as logging,
auditing, and monitoring.
2.1.3 Integration logic

Depending on the integration scenario that you choose, you need a dedicated
integration logic to manage the routing of the data to the correct receiver and to
manipulate the data to fit the receivers needs. Therefore, it is an advantage to
12
have a common business object model across all connected systems and to be
able to build relationships between exchanged data entities. This also justifies
the requirement to have a common business data repository to store common
object definitions in one central place.
2.1.4 Consumability
It is no longer sufficient to open back-end applications for external access. How
the data and the back-end access is given to the outside world is the key
difference. The business functionary must be available as a fine granular service
that can be consumed by any permitted consumer. The overall setup has to be
flexible to be able to react ad-hoc changes. Such late binding requirements are
most times dressed by introducing service registry and discovery concepts. In
such a scenario, a service provider can register an available service at a central
service registry. The component that is looking for a specific service can do this
using standardized discovery mechanisms of the service registry.
2.1.5 Quality of Service

Although service enablement is the key buzzword in todays business integration
terminologies, it does not change the importance of traditional requirements such
as processing of business tasks within a defined transaction, the ability to do a
rollback, or a compensating action when required. These typical quality of
service requirements are all still within service-based integration environments.
2.1.6 Infrastructure intelligence

Within integration infrastructures it becomes more and more essential that the
infrastructure itself includes a specific amount of intelligence to coordinate the
business execution efficiently. Insufficient plumbing from different data formats is
not acceptable anymore. Integrators want to have a business perspective on
what is transferred between the interconnected systems. This intelligence is not
limited to IT specific values but should also include business policies that have to
be fulfilled to ensure a successful execution of the overall business process. In
an ideal environment, some dedicated autonomous adjustments can also be
initiated by an intelligent infrastructure to avoid critical situations whenever they
are foreseeable. Typical features that belong in this area are the capability to
define business rules which enable a policy driven execution of business
processes. These policies can span various quality of service levels such as
security and delivery options.
Chapter 2. Key technologies and concepts
13
2.2 From peer-to-peer to business process

management
This section debates the evolution from simple peer-to-peer connectivity to the
latest state-of-the-art enterprise service bus (ESB) concept, which is the
infrastructure enabler for flexible service-oriented architectures (SOA) that can
execute adaptive business processes.
2.2.1 Direct connectivity

Using direct interconnections between different EIS without an intermediate
instance would require extending the existing EIS with connection functionality,
as shown in Figure 2-1. This type of connectivity would result in the development
of dedicated connection solutions for converting data and process logic from one
EIS to the other. Each of these bilateral connections requires that you extend at
least one of the EIS involved. In addition, it requires a huge effort to maintain and
manage connections from many different places.
EIS 1
EIS 5
EIS 2
EIS 6
EIS 3
EIS 7
EIS 4
Figure 2-1 Business integration with direct connections
With direct connectivity, the complete infrastructure is very static because

changes in one component require the adjustment of a multitude of affected
connections.
14
2.2.2 Common messaging

The originating idea behind common messaging was to substitute the custom
connections between EIS by one common messaging infrastructure. The
concept of message queuing is very powerful one that de-couples applications
by abstracting connections through the use for queues. Instead of the application
talking directly to another application, it talks to an intermediate queue which can
then be directed to any application as shown in Figure 2-2.
EIS 1
Messaging
provider
EIS 5
EIS 2
EIS 6
EIS 3
EIS 7
EIS 4
Figure 2-2 Business integration with a common messaging provider
Message-queuing also eliminates the need for the application to deal with the
intricacies of different platforms or worry whether the other application is busy or
even online. It also takes care to ensure that message delivery is assured and
not duplicated. All of this capability strips out interface code from your
application.
2.2.3 Central integration broker

Message-queuing does nothing in itself to help deliver information in the right
format, nor does it help to direct information to different targets based on the
message content. The integrator still has to build all this kind of interface logic
directly into the application interfaces.
15
A more manageable and efficient architecture for business integration is to

introduce a central integration broker and EIS specific adapters (Figure 2-3). The
integration broker is responsible for routing data between participating EIS with
transformations of received data before forwarding them, like parsing, mapping
or aggregation. In addition, the integration broker can process business logic
between connected EIS, for example synchronization of data from various
resources and building relationships between sent data entities.
EIS 1
EIS 5
EIS specific
Adapter
EIS 2
EIS 6
Integration
Broker
EIS 3
EIS 7
EIS 4
Figure 2-3 Business integration with a central integration broker
The central integration broker enables the integrator to remove the

transformation and routing logic from the application interfaces. It can also
augment content and reroute based on message content. Additionally, it can also
translate between different protocols and programming models.
2.2.4 Enterprise service bus

What makes a common integration broker topology an ESB? This is a widely
discussed topic than can be difficult to answer. The key inhibitor to IT flexibility,
as mentioned previously, is the complexity of application interfaces. The major
task of an ESB is to reduce the number, size, and complexity of interfaces, which
in turn leads to the reduction of time, cost, and risk within an integration project
because a single interface for each application is introduced that increases the
responsiveness of the business.
16
Figure 2-4 illustrates how the ESB can connect different systems with different
data types and protocols to one common service-enabled platform.
Color = Data type

Shape = Protocol
Figure 2-4 Business integration with an ESB
The ESB is responsible to integrate across any back-end application regardless

if the application offers a standards based interface or a proprietary one.
Especially in the second option it is essential to be able to offer standards based
interfaces around those assets in the current environment that have business
value and reuse them in many places within an enterprise. A typical industry
example is the introduction of a single, service-based access to the application
that hosts the customer base. Regardless of where the customer related data is
required, it can be consumed by any other application through a consistent,
reliable, and standard-based interface that is provided by an ESB. For the
consuming party, the complexity of the original, proprietary interface is hidden,
and consumer and providers are de-coupled.
17
Lines of maintainable code
Figure 2-5 highlights how an ESB can simplify business integration architectures
by reusing common integration tasks within one product. This diagram puts the
value proposition into the context with other traditional integration approaches
which we discussed previously.
Direct Connectivity
(No middleware)
Message Queuing
Connectivity logic
Connectivity,
mediation &
custom
adaptation
logic
Enterprise
Application
Integration
Enterprise
Service Bus
Connectivity and
mediation logic
Connectivity,
mediation &
custom
adaptation logic
Mediation &
custom
adaptation
logic
Custom
adaptation
logic
Application
Application
Application
Application as
a service
All connectivity,
mediation and
custom logic
buried within the
application
Removes the
connectivity
logic from the
application
Removes the
connectivity +
mediation logic
from the
application
Reduces
application to its
core business
functions
(that is, a service)
Reduced development and maintenance; increased flexibility and reuse
Figure 2-5 Reuse of common integration patterns
A key success factor in building such easy-to-consume business services is to

find the right level of granularity. This discipline is a new and essential discipline
that has to be fulfilled by special SOA architects. By determining the correct level
of granularity for the provided services now, you can later build new applications
efficiently and easily and reassemble the existing applications with great
flexibility. Even on this ESB level it is possible to include specific integration logic
within the ESB to control the flow of information between connected systems.
The following points about an ESB scenario can be made:
Many EIS systems expose fine-grained transactions that should be wrapped
into higher-grained services rather than being exposed directly as enterprise
services.
An ESB provides a good solution for connecting the integration logic of the
wrapping software component to the underlying EIS transaction, and is one
option for hosting the integration logic itself (for example, as mediations).
An ESB provides a good solution for exposing the service that wraps the EIS
transaction to clients, in a managed way.
18
2.2.5 Business process management

Understanding that an ESB provides a new level of flexibility with the IT
infrastructure, it is now time to use this flexibility, for example, to create new
business processes in a fast and flexible manner. As mentioned previously, the
correct level of granularity of the business services provided by the ESB gives
the opportunity to rearrange certain building blocks of the business process and
rearrange the overall execution. Interfaces that are provided through an ESB by
specific key enterprise applications, such as material master or customer base,
are so generic that they can be consumed by anyone within the enterprise and
beyond.
While the ESB itself can be understood as one logical unit, to do efficient
business process management (BPM) a complete SOA life cycle has to be
supported. Figure 2-6 highlights a typical SOA life cycle together with the key
topics.
Discover
Construct & Test
Compose
Integrate people
Integrate processes
Manage and integrate
information
Gather requirements
Model & Simulate
Design
Financial transparency
Business/IT alignment
Process control
Manage applications &

services
Manage identiry &
compliance
Monitor business metrics
Figure 2-6 The SOA life cycle
The typical SOA life cycle includes the following phases:

Model
In the model phase, business requirements are gathered. Then, the desired
business process is designed, simulated, and optimized in the desired
business processes.
Assemble
After the business process is optimized in the Model phase, the organization
can implement the process in the assemble phase by combining newly
19
created and reused existing services that are the creation of a composite
application.
Deploy
After assembly, the assets are then deployed into a secure and integrated
environment that takes advantage of specialized services that provide
support for integrating people, processes, and information. This level of
integration helps ensure that all the key elements of the organization are
connected and working together.
Manage
When deployed, customers manage and monitor the composite applications
and underlying resources from both an IT and a business perspective.
Information gathered during the manage phase is used to gain real-time
insight into business processes that enable better business decisions and
that feed information into the life cycle for continuous process improvement.
Underpinning all of these life cycle stages is governance, which provides
guidance and oversight for the SOA project.
At this point, it is clear that a comparison of an ESB driven integration approach
with a BPM driven integration approach is not appropriate. Typically, an ESB
integration is the first stage, which is followed by the introduction of a flexible
SOA-based BPM integration that in fact uses the granular services that are
provided by the ESB.
In both stages the integration is using additional logic to make it more efficient. In
the ESB, it is in integration logic that enables it to route, transform, convert, and
handle messages between systems. This is all on the technical message or data
layer that enables the ESB, for example, to convert from one format to another.
By contrast, the BPM layer includes additional application logic because the data
used here is typically of business nature. On the BPM layer, the decision is taken
if a customer for example can use a premium service based on the information
that is fetched from the customer base system.
Finally, it can be summarized that the introduction of powerful ESB-based
integration foundation combined with a flexible BPM layer on top can enable
enterprises to execute real event-driven computing and to react quickly and
efficiently to changes within their business environment.
20
2.3 Standards and technologies

This section describes the core standards and technologies that we reference
later in this book. Many of these standards use more low-level standards or
specifications that we do not describe in more detail.
2.3.1 Web Services

Web Services are self-contained, modular applications that can be described,
published, located, and invoked over networks. Web Services encapsulate
business functions that range from a simple request-reply to full business
process interactions. Figure 2-7 shows the core elements of Web Services.
UDDI
WSIL
Publish
Discover
Discover
WSDL
Provider
Requester
Web
service
SOAP
Client
HTTP
Legend
References to service descriptors
Pointers to WSDL documents
Originates from
Figure 2-7 Web Services core elements
The following core technologies implement Web Services:

Extensible Markup Language (XML) is the markup language that underlies
most of the specifications that are used for Web Services. XML is a generic
language that can describe any kind of content in a structured way, separated
from its presentation to a specific device.
21
SOAP is a network, transport, and programming language and

platform-neutral protocol that allows a client to call a remote service. The
message format for SOAP is XML.
Web Services Description Language (WSDL) is an XML-based interface and
implementation description language. The service provider uses a WSDL
document in order to specify the operations that a Web Service provides and
the parameters and data types of these operations. A WSDL document also
includes the service access information.
Web Services Inspection Language (WSIL) is an XML-based specification that
locates Web Services without using UDDI. However, WSIL can also be used
with UDDI, that is, it is orthogonal to UDDI and does not replace it.
Universal Description, Discovery, and Integration (UDDI) is both a
client-side API and a SOAP-based server implementation that can be used to
store and retrieve information about service providers and Web Services.
Typical Web Services characteristics can be described as follows:
Web Services are self-contained.
On the client side, no additional software is required. A programming
language with XML and HTTP client support is enough to get you started. On
the server side, merely a HTTP server and a SOAP server are required. It is
possible to enable an existing application for Web Services without writing a
single line of code.
Web Services are self-describing.
The definition of the message format travels with the message. No external
metadata repositories or code generation tools are required. Web Services
can be published, located, and invoked across the Web. This technology
uses established lightweight Internet standards such as HTTP. It uses the
existing infrastructure. Some additional standards that are required to do so
include SOAP, WSDL, and UDDI.
Web Services are modular.
Simple Web Services can be aggregated to more complex ones, either using
workflow techniques or by calling lower-layer Web Services from a Web
Service implementation. Web Services can be chained together to perform
higher-level business functions. This shortens development time and enables
best-of-breed implementations.
Web Services are language-independent and interoperable.
The client and server can be implemented in different environments. Existing
code does not have to be changed to be Web Service enabled. Basically, you
can use any language to implement Web Service clients and servers. In this
book, we discuss only the use of Java for Web Services.
22
2.3.2 Service component architecture

Service component architecture (SCA) is a set of specifications that describe a
model for building applications and systems using a service-oriented
architecture. SCA extends and complements prior approaches to implementing
services, and SCA builds on open standards such as Web Services.
SCA encourages an SOA organization of business application code based on
components that implement business logic, which offer their capabilities through
service-oriented interfaces and which consume functions offered by other
components through service-oriented interfaces, called service references. SCA
divides up the steps in building a service-oriented application into two major
parts:
The implementation of service components which provide services and
consume other services.
The assembly of sets of components to build business applications, through
the wiring of service references to services.
SCA emphasizes the de-coupling of service implementation and of service
assembly from the details of infrastructure capabilities and from the details of the
access methods used to invoke services. SCA components operate at a
business level and use a minimum of middleware APIs while for example J2EE
remains the programming model and technology used for developing new atomic
service components. Service Data Objects (SDO) provide the universal model
for business data. Figure 2-8 shows an overview of SCA.
Component
Java
Java
WSDL
Port Type
Interface
Reference
WSDL
Port Type
Implementation
Java
BPEL
State
Machine
Business
Rule
Human
Task
Selector
Implementation Types
Figure 2-8 SCA overview
23
A service interface is defined by a Java interface or WSDL Port type. The

arguments and return values which are passed through this interface are
described with Java classes, simple Java types, or XML schema. SDO
generated Java classes are the preferred form of Java class because of their
integration with XML technologies. Arguments described in XML schema are
exposed to programmers as SDOs.
A component exposes business-level interfaces to its application business logic
so that the service can be used or invoked. The interface of a component defines
the operations that can be called and the data that is passed, such as input
arguments, returned values, and exceptions. An import and export also has
interfaces so that the published service can be invoked. All components have
interfaces of the WSDL type. Only Java components support Java-type
interfaces. If a component, import, or export has more than one interface, all
interfaces must be the same type. A component can be called synchronously or
asynchronously. This call is independent of whether the implementation is
synchronous or asynchronous.
The component interfaces are defined in the synchronous form and
asynchronous support is also generated for them. You can specify a preferred
interaction style as synchronous or asynchronous. The asynchronous type
advertises to users of the interface that it includes at least one operation that can
take a significant amount of time to complete. As a consequence, the calling
service must avoid keeping a transaction open while waiting for the operation to
complete and send its response. The interaction style applies to all the
operations in the interface.
You can also apply a role-based permission qualifier to an interface so that only
authorized applications can invoke the service with that interface. If the
operations require different levels of permission for their use, you must define
separate interfaces to control their access. A service can be implemented in a
range of languages (for example Java, WS-BPEL, state-machine definitions, and
so on). When implementing a service, the focus is on the business purpose and
less on infrastructure technology. SCA and non-SCA services can use other
24
service components in their implementations. They do not hard code the other
services they use. They declare soft links called service references. Service
wires resolve service references. You can use SCA wiring to create SCA
applications by component assembly, as shown in Figure 2-9.
Service Module
Service
Component
Export
Service
Component
Implementation
Java
Implementation
Standalone
Reference
Java
Import
Wire
Figure 2-9 SCA service module
Applications that are not defined as SCA components, for example,

JavaServer Pages (JSPs), can still invoke SCA components. They do so
through the use of stand-alone references. Stand-alone references include
partner references that identify the components to call. Stand-alone references
do not have any implementation or interface.
2.3.3 Service Data Objects

Business data that is exchanged in an integrated application or Enterprise
Service Bus is represented by business objects. The objects are based on
Service Data Objects (SDOs), which is a new data access technology.
The fundamental concept in the SDO architecture is the data object. In fact, the
term SDO is often used interchangeably with the term data object. A data object
is a data structure that holds primitive data, multi-valued fields (other data
objects), or both. The data object also has references to metadata that provide
information about the data found in the data object. In the SDO programming
model, data objects are represented by the commonj.sdo.DataObject Java
interface definition. This interface includes method definitions that allow clients to
obtain and set the properties associated with DataObject.
25
As an example, consider modeling customer data with a SDO data object. The
properties associated with the customer might be firstName (String), lastName
(String), and customerID (long). The code in Example 2-1 shows how to use the
DataObject API to obtain and set properties for the customer data object.
Example 2-1 SDO programming example
DataObject customer =
customer.setString("firstName","John");
customer.setString("lastName","Doe");
customer.setInt("customerID", 123);
int id = customer.getInt(customerID);
Another important concept in the SDO architecture is the data graph. A data
graph is a structure that encapsulates a set of data objects. From the top level
data object in the graph, all other data objects can be reached by traversing the
references from the root data object. In the SDO programming model, data
graphs are represented by the commonj.sdo.DataGraph Java interface
definition.
2.3.4 Java technology

This section provides a brief introduction to several key definitions that are
related to the word Java.
Java language
First of all, Java is language. Java is one of the most popular programming
languages today. It has been around for many years since Sun Microsystems
introduced it in early 1990s.
Any programming language is based on a well-defined syntax and semantic. Any
high-level language program, including Java, is a text file with a unique file
extension (.java for the Java programs). A program, as a text file, cannot be
executed on a computer. There is a need for another component, called a
compiler, that converts a human readable text file into machine instructions.
Typically, these instructions are unique for a specific hardware platform, such as
Intel or PowerPC. To avoid duplication, the occurrence of common
programming segments in different applications, the most frequently used
functions (segments of programs) are pre-written and grouped in special
libraries. These libraries are called differently for different platforms and
languages. For Java they are called Java class libraries. These packages are
downloaded to a computer and can be included (or referenced) to any program.
Thus we achieve code reuse.
26
As a language (meaning syntax and semantic), Java has not changed a lot.
However, the runtime support and the number of available packages have grown
tremendously. As the result, Java programming language is one of the most
popular languages for enterprise applications.
The main characteristic of the Java language include:
Java is a high-level programming language.
Java is object-oriented language.
This concept is supported by many programming languages. It is based on
the idea that the program is seen as the collection of objects. Each object
represents an entity within the business task that this program has to solve.
For example, many applications have Customer or Address objects. The
objects communicate through well-defined interfaces, called methods, by
exchanging messages.The object-oriented programming claims to achieve a
better flexibility, reusability of the code, and maintainability. It is a popular
choice for the large-scale solutions.
Java is platform independent.
A Java program written according to the best practices can be moved to any
supported platform without any change or need to recompile.
27
Java platform
To support the development and deployment of the Java applications, you need
to have a special environment on your system. This environment is called Java
platform. Figure 2-10 shows the architecture of the Java platform.
Figure 2-10 Java platform architecture
There are several editions of the Java platform in existence today to meet the
various requirements:
Java Platform Micro Edition (Java ME, formerly J2ME)
This edition targets development and deployment of the Java applications for
small, mobile devices, such as PDAs and cell phones.
Java Platform Standard Edition (Java SE, formerly J2SE)
This edition targets development and deployment for most of the Java
applications running on the servers.
Java Platform Enterprise Edition (Java EE, formerly J2EE)
This edition has additional support API for enterprise-level applications. The
examples of additional API include Web Services, distributed deployment of
the applications, and communication API.
28
Java platform is a set of specifications that defines the services and APIs for the
Java environment. Java platform is the document. The product, that implements
this document, is called Java Software Development Kit (Java SDK). It includes
the following major components (Figure 2-10):
Java Virtual Machine (JVM)
Java Runtime Environment (JRE)
Development tools
2.3.5 Messaging and queuing technology

IBM WebSphere MQ is an established and reliable message queuing
middleware platform. During more than 10 years of development, WebSphere
MQ has grown to provide flexible and reliable solutions that address the breadth
of considerations introduced in the previous chapter. A message queuing
infrastructure built on WebSphere MQ technology helps provide an available,
reliable, scalable, secure, and maintainable transport for messages with exactly
one delivery assurance.
WebSphere MQ message queuing infrastructure

The nodes within a WebSphere MQ message queuing infrastructure are called
queue managers. Multiple queue managers can run on a single physical server,
and queue managers can run on a large variety of different hardware and
operating system combinations.
Each queue manager provides facilities for reliable message queuing. Queue
managers on all platforms provide facilities for message queuing using a
point-to-point model, including request/reply and send and forget messaging, as
described in Chapter 3, Product overview on page 33. WebSphere MQ Version
6.0 queue managers, with the exception of WebSphere MQ for z/OS, also
provide a publish/subscribe broker for message queuing using a
publish/subscribe model.
The queue managers maintain the queues of the message queuing infrastructure
and all of the messages that reside on those queues waiting to be processed or
routed. Queue managers are tolerant to failures, maintaining the integrity of the
business-critical data flowing through the message queuing infrastructure.
The queue managers within the infrastructure are connected with channels.
Messages automatically flow across these channels, from the initial producer of
a message to the eventual consumer of that message, based on the
configuration of the queue managers in the infrastructure. Many changes can be
made to this configuration transparently to the applications, which provide and
access the services in the system.
29
Facilities for building a WebSphere MQ infrastructure

WebSphere MQ V6.0 provides the WebSphere MQ Explorer, which is a
graphical user interface (GUI) that is used to configure and monitor the queue
managers within a WebSphere MQ infrastructure from a desktop workstation.
This includes the administration of queue managers hosted on the z/OS
platform.
WebSphere MQ provides a scripting interface called MQSC to perform
administration on all platforms. Panel driven administration interfaces are also
provided on iSeries and z/OS.
WebSphere MQ objects are defined on each queue manager. These configure
the queues hosted on that queue manager and the interaction between that
queue manager, applications, and other queue managers within the WebSphere
MQ infrastructure. These objects can be used to configure specific routes
between the individual queue managers within the infrastructure. They can also
be used to join a queue manager to a queue manager cluster, in which the
channels between queue managers are automatically created when required.
Queue manager clusters reduce the amount of administration required when
building or modifying a WebSphere MQ infrastructure. Queue managers can join
and leave a queue manager cluster without additional configuration of the
existing queue managers within the infrastructure.
Queue manager clusters also provide significant extra functionality over
manually defined intercommunication between queue managers. This
functionality can be used to increase the scalability and availability of the
services provided by a system.
SupportPacs
Some additional functionality and documentation, which is not supplied in the
base WebSphere MQ product, is provided within a WebSphere MQ
SupportPac.
The areas of functionality that SupportPacs provide are varied and include the
following features:
Reports about the performance of WebSphere MQ

Documentation and guides regarding particular areas of function
Sample applications that interact with WebSphere MQ
Scripts that simplify the administration of WebSphere MQ
Interfaces into WebSphere MQ from additional programming languages
Each SupportPac has a unique reference and an associated category. The

category specifies the origin of that SupportPac and the level of support that is
provided by IBM for that SupportPac.
30
For a list of all available SupportPacs and for more details about the SupportPac
system and the categories of SupportPacs, see the following Web page:
http://www.ibm.com/software/integration/support/supportpacs
31
32
Chapter 3.
Product overview
This chapter gives an introduction to the IBM service-oriented architecture (SOA)
reference architecture and the SAP NetWeaver architecture. It also provides an
overview of the business integration products that are outlined in the IBM SOA
reference architecture and the SAP NetWeaver architecture. This chapter
describes in more detail the products that we use in the scenarios of this book.
This chapter discusses the following topics:
Introduction to the IBM SOA reference architecture on page 34

IBM WebSphere Application Server on page 39
IBM WebSphere Enterprise Service Bus on page 41
IBM WebSphere Process Server on page 43
IBM WebSphere Message Broker on page 46
IBM WebSphere Adapter on page 49
WebSphere Integration Developer on page 54
Reference documentation on page 57
Introduction to SAP Components on page 58
33
3.1 Introduction to the IBM SOA reference architecture

SOA is a business centric IT architectural approach that supports integrating
your business as linked, repeatable business tasks or services. SOA helps users
build composite applications, which are applications that draw upon functionality
from multiple sources within and beyond the enterprise to support horizontal
business processes.
SOA takes everyday business applications and breaks them down into individual
business functions and processes. An SOA lets you build, deploy, and integrate
these functions and processes, independently of the applications and computing
platforms on which they run.
Getting started with SOA is easier with the IBM SOA Foundation, an integrated,
open-standards-based set of software, best practices, and patterns for SOA. IBM
SOA Foundation helps to extend the value of the applications and business
processes that currently run your business, not replace them.
IBM SOA Foundation is interoperable and fully modular, allowing you to select
components on a build-as-you-go basis by adding components as new
requirements need to be addressed. Because IBM SOA Foundation is scalable,
you can start small and grow as fast as the business requires. IBM SOA
Foundation also provides extensive support for business and IT standards to
facilitate greater interoperability and portability between applications.
Figure 3-1 shows the SOA life cycle.
WebSphere Integration Developer
Rational Application Developer
WebSphere Business Modeler

Rational Software Architect
Process:
WebSphere Process Server
WebSphere ESB and Message Broker
WebSphere Partner Gateway & Adapters
People:
WebSphere Portal
WebSphere Everyplace Deployment
Workplace Collaboration Services
Information:
WebSphere Information Integrator
Application Infrastructure:
WebSphere Application Server & XD
WebSphere Business Monitor

Tivoli Composite Application Manager
Tivoli Federated Identity Manager
Tivoli Access Manager for e-business
Figure 3-1 SOA life cycle
34
The software that comprises IBM SOA Foundation has been carefully selected
from the leading-edge IBM software portfolio to support each stage of the SOA
life cycle. That life cycle includes four stages. Underpinning these stages are
governance and processes that provide guidance and oversight for the SOA
project. The stages of the SOA life cycle are:
Model
You begin the Model phase by gathering and analyzing business
requirements that you use to model, simulate and optimize your business
processes. The resulting business processes are used to design associated
software services and service levels to support these processes. During this
phase, you use a model to establish a common understanding between
business and IT of your business processes, objectives and outcomes, as
well as to help ensure that the resulting application meets your defined
business requirements. This model also provides a base line to measure
business performance.
IBM products that support the Model phase are IBM WebSphere Business
Modeler and IBM Rational Software Architect.
Assemble
During the Assemble phase, you create services out of existing assets, such
as enterprise resource planning (ERP) and financial systems, IBM CICS
applications and other solutions that run your business. In many cases, a
library of existing services can be used to find services that already exist in
your organization. If no functionality exists, you can create and test a service
to deliver the functionality required for a particular business process. After the
required services are available, the services are orchestrated to implement a
business process.
IBM products that support the Assemble phase are IBM Rational Application
Developer, IBM WebSphere Integration Developer, and IBM WebSphere
Portlet Factory.
Deploy
During the Deploy phase, you configure and scale the run-time environment
to meet the service levels required by your business processes. After a
business process is configured, you can deploy it into a robust, scalable,
highly secure services environment. This services environment is optimized
to reliably run mission-critical business processes while providing the
flexibility to make updates dynamically in response to the changing business
requirements. This service-oriented approach also reduces the cost and
complexity associated with maintaining numerous point-to-point integrations.
IBM products that support the Deploy phase are IBM WebSphere Application
Server, IBM WebSphere MQ, IBM WebSphere Message Broker, IBM
Chapter 3. Product overview
35
WebSphere Enterprise Service Bus, IBM WebSphere Process Server, and

IBM WebSphere Portal.
Manage
The Manage phase involves establishing and maintaining service availability
and response times, as well as managing underlying services assets. You
can monitor key performance indicators (KPIs) in real time to get the
information you need to prevent, isolate, diagnose and fix problems.
Understanding the real-time performance of your business processes
enables you to provide vital feedback to the business-process model to
enable continuous improvement. This phase also involves managing and
maintaining version control over the services that make up your business
processes. The management phase ultimately enables you to make better
business decisions sooner than earlier possible.
IBM products that support the Manage phase are IBM WebSphere Business
Monitor and the products of IBM Tivoli.
Governance and processes
Governance and processes are critical to the success of any SOA initiative.
To help ensure success, you might choose to create a center of excellence
within your business to implement governance policies and to follow proven
international governance standards of control objectives for information and
related technology. Implementing strong governance policies can result in
successful SOA implementations and also has the potential to result in higher
profits and increased shareholder value.
3.1.1 IBM SOA reference architecture

IBM has developed an SOA reference architecture that shows the kinds of
services and other capabilities that can be part of an SOA and how they fit
together. Any given SOA application need not use all of the capabilities; different
applications use different capabilities. The architecture is a vendor-neutral way of
looking at and planning the set of services that go into building an SOA. It does
not necessarily require any IBM products, although the IBM SOA Foundation
provides everything that is needed to build this architecture. A single architecture
can include products from multiple vendors which are able to integrate
successfully because they adhere to industry standards.
36
Integrated
environment
for design
and creation
of solution
assets
Business Innovation & Optimization Services

Facilitates better decision-making
with real-time business information
Interaction Services
Enables collaboration
between people,
processes & information
Process Services
Orchestrate and
automate business
processes
Information Services
Manages diverse
data and content in a
unified manner
Facilitates communication ESB between services

Partner Services
Connect with trading
partners
Business App Services

Build on a robust,
scaleable, and secure
services environment
Access Services
Facilitates interactions
with existing information
and application assets
IT Service
Management
Development Services
Figure 3-2 illustrates the IBM SOA reference architecture.
Manage
and secure
services,
applications
&
resources
Infrastructure Services
Optimizes throughput,
availability and performance
Figure 3-2 IBM SOA reference architecture
The components of the IBM SOA reference architecture are:

Interaction services: Enables people to work with services through user
interfaces.
Process services: Enables the execution of business processes.
Information services: Enables access to enterprise sources of data.
Partner services: Enables connections to outside partners and suppliers.
Business application services: Enables the execution of new application
components.
Access services: Enables connections to existing enterprise applications.
Enterprise Service Bus: Enables inter-connectivity between services.
Infrastructure services: Enables the execution of services with defined
qualities of service.
IT service management: Provides quality-of-service enhancements like
scalability and security.
Business innovation and optimization services: Monitoring capabilities to
ensure proper functioning and measure execution.
Development services: Programming tools for implementing and integrating
services.
The IBM SOA reference architecture shows the components that are needed to
fully realize the promise of SOA. The IBM SOA Foundation provides a complete
and compatible set of products for achieving this architecture.
37
WebSphere Process Server V6 is the natural evolution of the WebSphere

Business Integration Server Foundation product. Figure 3-3 highlights the
relationship of the former V5 products to the new V6 releases.
Prior
Today (V6)
Message
Broker
WebSphere
Business
Integration
Server
v4.3
MQ
Workflow
WebSphere Enterprise Service Bus

WebSphere Message Broker
(Advanced Enterprise Service Bus)
InterChange
Server
WebSphere Business
Integration Tools
WebSphere Business
Integration Server
Foundation v5.1.1

WebSphere ESB
WebSphere Studio Application

Developer Integration Edition
(WSAD-IE)
Figure 3-3 Evolution of WebSphere Business Integration products
IBM started building a business integration server that exploits SOA and Web
Services concepts in WebSphere Business Integration Server Foundation V5.1
(note the terminology Foundation in the product name). WebSphere Process
Server V6 now achieves the goal of being a robust and highly functional product
for business integration that exploits SOA.
The concepts from WebSphere MQ Workflow and WebSphere Interchange
Server are carried forward in WebSphere Message Broker V6. For example, all
the robust staff capabilities that customers appreciated with WebSphere MQ
Workflow are in WebSphere Process Server V6, including a robust set of client
components. WebSphere Message Broker also includes the concepts of
WebSphere InterChange Server, such as business objects, canonical business
processes, and cross-referencing capabilitiesthe features that made
WebSphere InterChange Server the ideal solution for data synchronization
scenarios.
The sections that follow outline the WebSphere products that we use in the
scenarios of this book.
38
3.2 IBM WebSphere Application Server

IBM WebSphere Application Server V6.1 is the foundation of the IBM
WebSphere software platform and a key building block for SOA. As the premier
Java 2 Enterprise Edition (J2EE) and Web Services application platform,
WebSphere Application Server V6.1 delivers a high performance transaction
engine that can help you build, run, integrate, and manage dynamic On Demand
Business applications.
As the core configuration of the WebSphere Application Server family,
WebSphere Application Server is optimized to ease administration in a scalable,
single server deployment environment.
An additional configuration IBM WebSphere Application Server Network
Deployment V6.1 is delivering a highly available transaction engine with
advanced performance and management capabilities. In addition to all of the
features and functions within the core WebSphere Application Server
configuration, WebSphere Application Server Network Deployment delivers
exceptional deployment services that include near-continuous availability,
clustering, edge-of-network services and Web Services that can operate across
disparate application frameworks.
WebSphere Application Server supports an unparalleled range of platforms and
can be deployed on servers of any size. New and enhanced features deliver the
flexible, open, resilient application infrastructure that you need for an SOA.
3.2.1 Simple, rapid development and deployment

WebSphere Application Server V6.1 helps you improve time to value and make
the most of existing technology skills with easy-to-use features that are designed
to get you to production quickly. With WebSphere Application Server V6.1, you
can:
Minimize development cycle time
WebSphere Application Server V6.1 offers features to help you maximize
skills, assets, and time, including pre-built functions for use within Web user
interfaces and an improved Application Server Toolkit with new automation
tools, basic assembly tools for creating new Web applications, Web Services,
and portlets, and a comprehensive unit test environment.
Easy to use and deploy
WebSphere Application Server V6.1 helps simplify the deployment
experience through the rapid deployment feature and enhancements such as
installation by non-root/non-administrator users. Significant improvements in
39
developer productivity can be gained from IBM implementation of J2SE 5 and

tight integration with IBM Rational tools.
3.2.2 Secure, scalable, highly available SOA runtime environment

WebSphere Application Server V6.1 provides a secure, scalable, and reliable
environment on which your applications and services can execute. Using the
scaling abilities and resilient security features of WebSphere Application Server
can help businesses do more work with less resources. With WebSphere
Application Server V6.1, you can:
Rest assured, applications and data are secure from attack
WebSphere Application Server V6.1 delivers an open standards-based
security infrastructure that removes vulnerable threats while maximizing
developer productivity. Security configurations and user registry, compliance
with government standards, and stringent Web Services securityavailable
with little configuration on your partgive ultimate peace of mind.
Run your applications where it makes sense for you
WebSphere Application Server V6.1 supports the broadest range of platforms
in the industry thereby assuring that your applications can be built to run on
the platform that most makes sense for your business.
Keep pace with a constantly changing environment
WebSphere Application Server V6.1 delivers unbeatable performance that
drives high throughput and scalability with JDK 5 enhancements and
improved cache off-loading.
Expand in response to the evolving business needs
WebSphere Application Server V6.1 provides a flexible deployment
environment that enables your business to grow at the required pace and cost
structure.
3.2.3 Extensive communication services

WebSphere Application Server V6.1 helps you improve the flexibility of your
business and increases the return on investment by making your application
services more reusable and accessible to new users, in new ways. With
WebSphere Application Server V6.1, you can:
Compelling new ways to interact
WebSphere Application Server V6.1 supports Session Initiation Protocol
(SIP) servlets to offer standardized support for interactive user sessions that
involve real-time multimedia elements such as voice, video, instant
messaging, and online games.
40
Re-use existing assets and extend their reach

WebSphere Application Server V6.1 delivers extensive Web Services support
and a powerful Java Message Service (JMS) engine to help you extend the
reach of your existing applications and maximize asset utilization. New Web
Services standards, including WS-Business Activity, WS-Notification, and
WS-I Basic Security Profile, help you extend your reach more securely and
give better application portability and control.
Extend services to the most heterogeneous environments
WebSphere Application Server Version 6.1 interoperates seamless with
WebSphere MQ and is tightly integrated with WebSphere Enterprise Service
Bus. As a result, you can combine these products to form a powerful
Enterprise Service Bus that can integrate the most diverse applications and
environments.
3.2.4 Effective application management

WebSphere Application Server V6.1 empowers you to direct your IT budget at
beating competitors to market and not at maintaining existing infrastructure.
Reduce the costs of managing your environment, with effective, easy-to-use
management tools. With WebSphere Application Server V6.1, you can:
Simple Administration and Maintenance
WebSphere Application Server V6.1 provides features to maximize the
efficiency of managing the deployment environment with a new console
command assistant, easier security configuration and database connectivity,
wizards and a stand-alone thin administration client.
Effective ecosystem for self-help and guidance
WebSphere Application Server V6.1 offers extensive documentation,
education and self-help tools such as the IBM Support Assistant, as well as a
skilled and accessible partner and user community to help you.
3.3 IBM WebSphere Enterprise Service Bus

WebSphere Enterprise Service Bus (WebSphere ESB) is designed to provide an
ESB for IT environments that is built around open standards and SOA. It delivers
easy to use functionality that is built on the messaging and Web Services
technologies of WebSphere Application Server.
WebSphere ESB provides the runtime environment that allows for a loose
coupling of service requestors and service providers. Using mediation flows,
WebSphere ESB provides for protocol transformations, message payload
41
transformations, and dynamic routing decisions. The runtime infrastructure is

founded on the WebSphere Application Server Network Deployment.
WebSphere Application Server is the foundation for WebSphere ESB, providing
not only the required quality of service, the J2EE runtime environment, and the
messaging engine but also providing broad support regarding open standards
and Web Services. WebSphere ESB is built on the Network Deployment
package and provides a wide range of capabilities for large enterprise networks,
including clustering, failover, and scalability features.
The development tool for WebSphere ESB is WebSphere Integration Developer.
WebSphere ESB provides uniform invocation and data representation
programming models and monitoring capabilities for the following components
that run on WebSphere ESB:
Service component architecture
On top of the infrastructure that is provided by WebSphere Application
Server, WebSphere ESB implements a mediation layer that consists of a
mediation base and mediation functions. The newly provided mediation
framework is based on the service component architecture (SCA). This
mediation framework allows enhanced flexibility, encapsulation, and reuse.
Service Data Objects
Mediation components are typically concerned with the flow of messages
through the infrastructure and not just with the business content of the
message. The information that governs their behavior is often held in headers
flowing with the business message. Therefore, the Service Message Object
(SMO) pattern for Service Data Objects (SDO) is introduced to support this
pattern. Service Message Objects are enhanced Service Data Objects,
providing an abstraction layer for processing and manipulating messages
exchanged between services.
Common Event Infrastructure
WebSphere ESB uses the Common Event Infrastructure (CEI) to provide
event management services, such as event generation, transmission,
persistence, and consumption. The format of those events is defined by the
Common Base Event (CBE) specification.
Mediations
Mediations are provided by SCA and Service Message Objects (SMO). SCA
supports the description of every mediation module through a
technology-neutral interface. SMO is based on SDO and supports the
representation of a binding-specific data format in a common, neutral way.
The application of this SCA/SMO based programming model allows for the
42
configurable assembly of different mediation modules including the mediation

flow, thus enabling a very flexible and encapsulated solution.
Mediation functions are built upon the mediation base and consist of one or
more mediation modules. A SCA/SMO based mediation module is composed
of different parts such as imports representing providers, exports
representing service consumers and mediation flow components
representing integration and mediation functionality.
WebSphere ESB provides prebuilt components called mediation primitives that
can be used in mediation flows to perform XSLT message transformation,
logging, routing, and database lookup. It also supports the implementation of
custom mediation primitives.
WebSphere ESB supports different binding types for imports and exports, thus
allowing the connection of different kinds of service consumers and providers.
Supported binding types are JMS binding, Web Services binding, WebSphere
adapter binding, EJB binding, as well as SCA binding used for module to
module communication.
The mediation framework and its mediation modules separate the processing of
requests from the processing of replies. They allow the mediation flow
components to pass a potentially modified request from a service consumer to a
service provider and to pass a potentially modified reply from a service provider
to a service consumer. The request processing within a mediation flow
component can send a reply back to the consumer without necessarily needing
to contact a service provider.
3.4 IBM WebSphere Process Server

IBM WebSphere Process Server combines integration capabilities with a
composite application platform to deliver a integration platform with a fully
converged, standards based business process engine, using the full power of
WebSphere Application Server.
IBM WebSphere Process Server is an SOA integration platform built on a
uniform invocation programming model and a uniform data representation
model.
43
WebSphere Process Server provides the run time to execute business

integration processes (Figure 3-4). The run time infrastructure is built on top of
the WebSphere ESB and, therefore, provides all of the capabilities of mediation
flows as well as possessing all of the qualities of service that are provided by the
WebSphere Application Server Network Deployment mentioned previously.
Choreography
WebSphere ESB
Mediation
WebSphere
Application Server ND
Clustering
WebSphere
Application
Server
App Server
Figure 3-4 WebSphere Process Server - inherited products
The combination of a powerful foundation (WebSphere Application Server and

the SOA core) and service components in WebSphere Process Server allows
quick development and deployment of sophisticated composite applications that
run on WebSphere Process Server (Figure 3-5).
One component-based framework addresses all styles of integration.
Service
Components
Business
Business
Processes
Processes
Supporting
Services
Mediation
Mediation
Flows
Flows
SOA Core
Human
Human
Tasks
Tasks
Interface
Maps
Service Component
Architecture
Business
Object Maps
Business
Objects
Business
Business
State
State
Machines
Machines
Business
Business
Rules
Rules
Relationships
Selectors
Selectors
Common Event
Infrastructure
WebSphere Application Server (J2EE runtime environment)
Figure 3-5 WebSphere Process Server
44
3.4.1 SOA core

The SOA core of WebSphere Process Server provides both uniform invocation
and data representation programming models and monitoring and management
capabilities for applications running on WebSphere Process Server.
SOA is a conceptual description of the structure of a software system in terms of
its components and the services they provide, without regard for the underlying
implementation of these components, services and connections between
components. The service component architecture and business objects that are
part of the SOA core provide uniform invocation and data representation
programming models for applications deployed on IBM WebSphere Process
Server. The SOA core also includes the Common Event Infrastructure for
generating events for the monitoring and management of applications on
WebSphere Process Server.
Supporting services
Supporting services in IBM WebSphere Process Server address a number of
transformation challenges for connecting components and external artifacts (as
illustrated in Figure 3-5 on page 44). Those supporting services include:
Mediation flows
Mediation flows intercept and modify messages that are passed between
existing services (providers) and clients (requesters) that want to use those
services.
Interface maps
Interface maps reconcile the differences between components that have
different interfaces.
Business object maps
Business object maps support mappings between the source and target
business objects.
Relationships
Relationships are supporting services in WebSphere Process Server
applications that establish an association between data from two or more data
types.
Selectors
Selectors provide flexibility at points in the processing of components in an
application running on IBM WebSphere Process Server.
45
Service components
All integration artifacts running on IBM WebSphere Process Server (for example,
business processes, business rules, and human tasks) are represented as
components with well defined interfaces. Within the SCA, a service component
defines a service implementation (see Figure 3-5 on page 44). Service
components include:
Business processes
Business processes are service components that provide the primary means
through which enterprise services are integrated.
Human tasks
Human tasks are stand-alone service components that can be used to either
assign work to employees or to invoke other services.
Business state machines
Business state machines are service components that specify the sequences
of states, responses, and actions that an object or an interaction goes through
during its life in response to events.
Business rules
Business rules are service components that declare policy or conditions that
must be satisfied within your business.
3.5 IBM WebSphere Message Broker

WebSphere Message Broker enhances the flow and distribution of information
by enabling the transformation and intelligent routing of messages without the
need to change either the applications that are generating the messages or the
applications that are consuming them.
The broker is a set of application processes that host and run message flows
consisting of a graph of nodes that represent the processing needed for
integrating applications. The broker also hosts message sets, including message
models for predefined message formats.
When a message from a business application arrives at the broker, the broker
processes the message before passing it on to one or more other business
applications. The broker routes, transforms, and manipulates messages
according to the logic that is defined in message flow applications. A broker uses
WebSphere MQ as the transport mechanism both to communicate with the
Configuration Manager, from which it receives configuration information, and to
communicate with any other brokers to which it is associated. Each broker has a
46
database in which it stores the information that it needs to process messages at

run time. Figure 3-6 illustrates the Message Broker Overview.

Message Brokers Toolkit
Repository
Broker
Domain
Configuration
Manager
Optional User
Name Server
Application
Message
Flow
Broker
Application
Message
Sets
Application
Application
Figure 3-6 IBM Message Broker -overview
Execution groups enable message flows within the broker to be grouped

together. Each broker includes a default execution group. You can create
additional execution groups as long as they have unique names within the
broker. Each execution group is a separate operating system process and,
therefore, the contents of an execution group remain separate from the contents
of other execution groups within the same broker. This design can be useful for
isolating pieces of information for security because the message flows execute in
separate address spaces or as unique processes. Message flow applications are
deployed to a specific execution group. To enhance performance, the same
message flows and message sets can be running in different execution groups.
WebSphere Message Broker includes the WebSphere Message Broker toolkit
that is based on the Rational Software Development Platform, which itself is built
on Eclipse. The toolkit runs on either Windows or Linux on Intel and enables
the customer to configure the system, develop the message flows, and manage
deployed environments.
47
The Configuration Manager is the interface between the Message Brokers

Toolkit and the brokers in the broker domain. The Configuration Manager stores
configuration details for the broker domain in an internal repository, providing a
central store for resources in the broker domain. The Configuration Manager is
responsible for deploying message flow applications to the brokers and
delivering reports on the progress of the deployment and on the status of the
broker. When the Message Brokers Toolkit connects to the Configuration
Manager, the status of the brokers in the domain is derived from the
configuration information stored in the Configuration Manager's internal
repository.
WebSphere Message Broker together with WebSphere MQ provide high
availability features. This is quite important because WebSphere Message
Broker acts as a hub and therefore needs to be eliminated as a single point of
failure.
Load balancing and high availability can be achieved by providing multiple broker
instances serving the same logical hub with each instance is mapped to its own
WebSphere MQ queue manager. The different broker instances could reside on
different machines.
WebSphere Message Broker provides the Message Broker Toolkit, a graphical
environment for developing and deploying message flow applications.
3.5.1 Choosing between WebSphere Message Broker or WebSphere

WebSphere ESB and WebSphere Message Broker are complementary
products. WebSphere ESB provides an embedded, standards-based ESB
designed to provide the functionality of an ESB for a predominantly Web
Services based environment. It provides Web Services based connectivity and
service-oriented integration.
WebSphere Message Broker provides an advanced ESB, extending the value of
an ESB to include capabilities such as universal connectivity any-to-any
transformation and complex event processing. Depending on their requirements,
customers can deploy WebSphere ESB, WebSphere Message Broker, or both,
and IBM is uniquely able to provide this flexibility in implementing an ESB.
Customers can integrate WebSphere ESB and WebSphere Message Broker
seamlessly using IBM WebSphere MQ Link, JMS, and Web Services (SOAP
over HTTP protocols or JMS over either WebSphere MQ or JMS). New features
in WebSphere ESB V6.0.2, including native WebSphere MQ integration and
support for WebSphere MQ JMS, provide faster performance and easier
48
integration with existing WebSphere MQ and WebSphere Message Broker

assets.
3.6 IBM WebSphere Adapter

An IBM WebSphere Adapter implements the Java 2 Enterprise Edition (J2EE)
Connector Architecture (JCA), Version 1.5. Also known as resource adapters or
JCA adapters, WebSphere Adapters enable managed, bidirectional connectivity
between enterprise information systems (EIS) and J2EE components supported
by WebSphere Process Server or WebSphere ESB.
The IBM WebSphere Adapter portfolio is a new generation of adapters based on
the J2EE) standard. JCA is a standard architecture for integrating J2EE
applications with enterprise information systems. Each of these systems
provides native APIs for identifying a function to call, specifying its input data,
and processing its output data. The goal of the JCA is to provide an independent
API for coding these functions, to facilitate data sharing, and to integrate J2EE
applications with existing and other EIS. The JCA standard accomplishes this by
defining a series of contracts that govern interactions between an EIS and J2EE
components within an application server.
Fully compliant with the JCA standard, WebSphere Adapters have been
developed to run on WebSphere Process Server or WebSphere ESB, as shown
in Figure 3-7.

J2EE
Component
WebSphere
Adapter
EIS
Figure 3-7 WebSphere Adapter - JCA
A WebSphere Adapter:
Integrates with WebSphere Process Server.
Connects an application running on WebSphere Process Server with an EIS.
Enables data exchange between the application and the EIS.
49
Each WebSphere Adapter is made up of the following:

An implementation of the J2EE Connector Architecture (JCA), Version 1.5
that supports WebSphere Process Server.
An enterprise metadata discovery component, you use this component with
the enterprise service discovery wizard to introspect the EIS, to generate
business objects and other SCA artifacts that are compiled in a standard
enterprise application archive (EAR) file.
WebSphere Adapters use SDO for representing data objects.
WebSphere Business Integration Adapters

WebSphere Business Integration Adapters plug into a custom WebSphere
Adapter Framework that encapsulates and delivers common services and
functions which are required by all adapters, such as to design business objects,
configure connector configurations or to introspect a particular back-end system
to generate business objects efficiently.
As shown in Figure 3-8, WebSphere Business Integration Adapters are
distributed. They reside outside of the application server. The server or
integration broker communicates with this type of adapter through a JMS
transport layer.
WebSphere
Integration
Broker
WebSphere
Business
Integration
Adapter
EIS
Figure 3-8 WebSphere Business Integration Adapter
Other differences between WebSphere Adapters and WebSphere Business

Integration Adapters include the following:
Connection management
WebSphere Adapters rely on standard JCA contracts to manage life cycle
tasks such as stopping, starting. WebSphere Business Integration Adapters
rely on the WebSphere Adapter Framework to manage connectivity.
Event notification
Known as inbound event notification for WebSphere Adapters.
50
Request processing
Known as outbound support in WebSphere Adapters.
Object definition
With WebSphere Adapters, you use an enterprise metadata discovery
component to probe an EIS and develop business objects and other useful
artifacts. This enterprise metadata discovery component is part of the
WebSphere Adapter. WebSphere Business Integration Adapters use a
separate Object Discovery Agent (ODA) to probe an EIS and generate
business object definition schemes.
WebSphere Business Integration Adapter for mySAP.com is shipped with the
WebSphere Adapter for SAP Software package.
3.6.1 IBM WebSphere Adapter for SAP Software

The WebSphere Adapter for SAP Software complies to the J2EE JCA standard.
The WebSphere Adapter for SAP Software connects to SAP systems running on
SAP WebApplication Servers, using the SAP Java interface known as SAP Java
Connector (SAP JCo). It does so by making calls, modeled as business objects,
to the SAP native interfaces and passing data to and from the SAP system. The
adapter supports SAP integration interfaces such as Business Application
Programming Interface (BAPI) and Application Link Enabling (ALE), as well as
SAP Remote Function Call (RFC) enabled function modules.
51
The adapter supports outbound processing (from the adapter to the SAP system)
and inbound processing (from the SAP system to the adapter) of events, as
shown in Figure 3-9.
WebSphere
Adapter for
SAP Software
SCA
component
BAPI
outbound
interface
SCA
component
ALE
outbound
interface
SAP
application
Endpoint
Event
recovery
ALE
inbound
interface
Figure 3-9 WebSphere Adapter for SAP Software
Outbound event processing

Outbound support allows a client to make calls to the adapter to perform a
specific operation in the SAP system. The client requests a connection, which in
turn is passed from the adapter to SAP. Outbound event processing, which the
adapter supports for the BAPI and ALE interfaces, consists of the following
steps:
1. An SCA component invokes an interaction with SAP.
2. As a result of the invoked interaction, a business object representing the SAP
function call is passed from the component application to the adapter.
3. The adapter extracts the elements from the business object and, using the
metadata information from the business object, recognizes the SAP interface
to use (BAPI or ALE).
4. Using the SAP Java interface (SAP JCo), the adapter converts the business
object data to the appropriate SAP function call.
52
5. The adapter then executes the function on the destination SAP software
system, sending the event data to SAP.
Inbound event processing

Inbound event processing, which the adapter supports for the ALE interface,
consists of the following steps:
1. The adapter spawns listener threads to the SAP system.
2. Whenever an event occurs in SAP, the event is pushed to the adapter
through the event listeners.
3. The adapter then forwards the event to the endpoint (a message driven
bean).
4. The endpoint registers the incoming event.
5. The adapter can track and recover events in case of abrupt termination using
the data source for persisting the event state in an event recovery table.
The adapter supports container managed sign-on and basic authentication.
Because the SAP back-end systems do not provide a re-authentication
capability, the adapter cannot provide this feature either. Finally, the adapter is
able to use all SAP features which are available using the native RFC libraries
and ALE processing like enhanced connection handling, pooling and expiration.
3.6.2 IBM WebSphere Business Integration Adapter for mySAP.com

As mentioned previously, the WebSphere Business Integration Adapter use on
IBM specific WebSphere Adapter Framework for enhanced provision of common
services. The WebSphere Business Integration adapters consist of a collection
of software programs, application programming interfaces (APIs), and tools you
can use to enable applications to exchange business data through an integration
broker. Each business application requires its own application specific adapter to
participate in the business integration system.
Each adapter in WebSphere Business Integration adapters portfolio includes:
A connector that links the application to the integration broker.
Tools with graphical user interfaces to help you configure a connector and
create the business object definitions needed for the application.
An Object Discovery Agent (ODA) that runs against an application's data
store to create business object definitions, which you can then refine. Note
that WebSphere Business Integration adapters for some applications do not
include an ODA.
53
An Object Discovery Agent Development Kit (ODK), which consists of a set of

APIs you can use to develop an ODA.
In the WebSphere Business Integration system implemented with WebSphere
Application Server, connectivity for moving data between applications and
WebSphere Application Server is supplied by connectors using WebSphere MQ
as the JMS provider. A connector can reside on any machine from which it can
access the necessary queues and communicate with the application.
Each connector consists of two parts. The connector framework and the
application specific component.
The connector framework interacts with the integration broker using
WebSphere MQ queues.
The application specific component interacts directly with an application.
3.7 WebSphere Integration Developer

WebSphere Integration Developer provides the development environment to
create the business integration solutions. WebSphere Integration Developer
provides a layer of abstraction that separates the visually presented components
you work with from the underlying implementation. This helps simplify and
accelerate the development of integrated applications.
WebSphere Integration Developer tools are based on an SOA. Components
represent services, and an integrated business application can involve many
components. The services comply with the leading, industry wide standards such
as Business Process Execution Language (BPEL). Business process
applications are created by connecting the service components using graphical
tools in the WebSphere Integration Developer tool.
IBM WebSphere Integration Developer Version 6.0 software is Eclipse
technology based tooling designed to enable you to rapidly assemble business
solutions based on a composite application development framework, and using
minimal programming skills.
With WebSphere Integration Developer, you can author SOA based services and
choreograph them into business processes that you can deploy on IBM
WebSphere Process Server. WebSphere Integration Developer offers a role
based development experience that specifically targets the integration developer
on a single and integrated Eclipse platform.
WebSphere Integration Developer is the only tool you need for all your
integration needs within SOA. SOA allows you to render existing IT architecture
54
as reusable service components. The framework is comprehensive and

extensive, which helps you transform your enterprise to SOA by using your
existing IT architecture. Because WebSphere Integration Developer is based on
open standards based technologies, such as Web Services Description
Language (WSDL), XML Schema Definition (XSD), and Business Process
Execution Language (WS-BPEL), you can model, implement, and deploy
complex composite applications without extensive knowledge of the underlying
implementation.
WebSphere Integration Developer is a fully integrated development environment
based on the Eclipse 3 platform. Its graphically rich interface allows developers
to create composite business applications by wiring service components with
minimal skills and agnostic of underlying programming and architectural
implementations. It has fully integrated testing, debug and deployment
environment allows you to easily deploy to WebSphere Process Server. When
deployed, you can change and adapt to changes dynamically with its rich
features like business rules, selectors, and state machines.
WebSphere Integration Developer complements IBM WebSphere Business
Modeler Version 6 and can be used in conjunction with IBM Rational Software
Architect Version 6 and IBM Rational Application Developer Version 6. When
combined into a single integrated development environment (IDE), these
products provide a complete suite of tools to model, simulate, author, and deploy
composite SOA applications.
IBM WebSphere Integration Developer delivers a rich set of features to
assemble, deploy and manage business processes:
Import business models from WebSphere Business Modeler and transform to
BPEL flows.
Drag-and-drop features to create business processes.
Widgets to wire service components including:
Business processes
Human tasks
Business state machines
Business rules
Supporting services
Interface maps
Business object maps
Relationships
Selectors
Java objects
Online library to browse and reuse service components.
55
3.7.1 Supports SOA development

Includes visual construction tools for developing the services needed in SOA
applications and provides the tools you need to discover, create, build, test,
deploy and publish the services that comprise SOA applications. You can build
new applications from scratch or enable existing applications for the SOA
architecture. A set of highly visual construction tools and wizards help you
automate the development process as you create these applications.
3.7.2 Easy to build, test, and deploy J2EE applications

Includes full support for the J2EE programming model, including Web, Java,
Web Services and EJB development to help you speed development and better
understand and manage complex code. A visual editor enables drag-and-drop
creation of interfaces, as well as binding data to interface components. This
helps to use existing skills and helps shorten the Java learning curve. You can
visualize and graphically edit the code through a UML-based visual editor. You
can also automate many functions including:
The creation of components and code needed to describe and discover Web
Services applications
Assembly of JAR, WAR, and EAR files
Code reviews that apply coding standards and best practices to your code
Component and Web Service unit testing
Multi-tier runtime analysis
3.7.3 Automated deployment tools

Automated deployment tools in WebSphere Integration Developer include
support for testing and debugging of local and server side code on IBM
WebSphere Application Server, WebSphere Process Server, WebSphere
Enterprise Service Bus. You can create and configure many elements of your
unit test, including server instances and breakpoints. In addition, you have the
ability to step through the code and even modify it without restarting the unit test
server. All of these features together help you to shorten unit test cycles as you
ensure the release of higher quality applications.
In summary, WebSphere Integration Developer allows:
Composite application development
WebSphere Integration Developer allows you to render existing applications
as standards based services. Services can be assembled together without
the associated complexities of the underlying IT to realize complex business
56
applications. Now, you start building a solution from the services available to
you; and build only the services you do not have, enabling true incremental
solution.
Flexible in managing deployed processes
WebSphere Integration Developer allows you to test, debug business
processes and deploy them on WebSphere Process Server with a few mouse
clicks.
When deployed, you can change and manage the processes with minimal
disruption. WebSphere Integration Developers rich GUI intensive features allow
management of deployed processes with minimal skills and disruption.
3.8 Reference documentation

Detailed information about IBM WebSphere products is available at:
http://www.ibm.com/software/websphere
You can find a collection of material on IBM Developer Works at:
http://www.ibm.com/developerworks/websphere
WebSphere Application Server V6.1: Technical Overview, REDP-4191
http://www.redbooks.ibm.com/redpieces/abstracts/redp4191.html?Open
Getting Started with WebSphere Enterprise Service Bus V6, SG24-7212
http://www.redbooks.ibm.com/abstracts/sg247212.html?Open
Technical Overview of WebSphere Process Server and WebSphere Integration
Developer, REDP-4041
http://www.redbooks.ibm.com/abstracts/redp4041.html?Open
Patterns: Building Serial and Parallel Processes for IBM WebSphere Process
Server V6, SG24-7205
WebSphere Business Integration for SAP, SG24-6354
57
3.9 Introduction to SAP Components

Whereas the previous section introduced the WebSphere products, this section
sheds some light on the SAP system components, SAP WebApplication Server,
and SAP Exchange Infrastructure. These components act as a provider for SAP
business applications and, thus, are applied within the technical scenarios
described within this book. They belong to the SAP NetWeaver technology
platform, an overview of which is given in the next paragraph. After that, the
components are introduced in more detail.
3.9.1 A short overview of SAP NetWeaver

SAP NetWeaver, which was announced by SAP in 2003, is a Web based, open
integration and application platform that serves as the foundation for enterprise
SOA and allows the integration and alignment of people, information, and
business processes across business and technology boundaries. It utilizes open
standards to enable integration with information and applications from different
sources or technologies. SAP NetWeaver is the foundation of SAP xApps and
mySAP Business Suite solutions.
As shown in Figure 3-10, the SAP technology stack can be divided into six core
building blocks:
58
People Integration
Information Integration
Process Integration
Application platform
Solution life cycle Management
Composite Application Framework
SAP NetWeaver
People Integration
Portal
Collaboration
Business
Intelligence
Knowledge
Management
Master Data Management
Process Integration
Integration
Broker
Business Process
Management
Life Cycle Management
Multi-Channel Access
Application Platform
J2EE
ABAP
DB and OS Abstraction
.NET
WebSphere
Figure 3-10 SAP NetWeaver overview
This division supports the delivery of business integration capabilities of different

levels. The fact that both WebSphere and .Net are mentioned in the official SAP
NetWeaver overview chart emphasizes that NetWeaver is designed to
interoperate with these primary market technologies.
People Integration
People Integration within SAP NetWeaver provides the user with the requested
functionality with the correct information. SAP Enterprise Portal is the core
component of the People Integration area.
The Information Integration section includes products that are responsible for
making structured and unstructured information available in the enterprise in a
consistent and accessible manner. The products are SAP Business Intelligence
(BI), Knowledge Management (KM), and Master Data Management (MDM).
Process Integration
Process Integration enables business processes to spread across system
boundaries and execute seamlessly across heterogeneous IT landscapes. The
59
products located in this SAP NetWeaver area are addressed as middleware in

IBM terminology. In the past, SAP focused on creating business applications with
defined system interfaces for integration and the integration itself was achieved
by dedicated system integrators. SAP is now offering its own process and
system integration suite.
The technical core component of the process integration layer is the SAP
Exchange Infrastructure (SAP XI), as shown in Figure 3-11. SAP XI is the
technical infrastructure for XML based message exchange between SAP and
non-SAP systems. In addition, it includes a business process execution engine,
enabling business processes to be executed in heterogeneous system
landscapes exceeding SAP applications.
3rd
Party
3rd
Party
Mainframe
Other
Integration
Solution
3rd
Party
Figure 3-11 SAP XI
Application platform
The application platform of SAP NetWeaver is the SAP WebApplication Server
(Web AS). It provides a platform independent, maintainable basis for business
Web applications and Web Services that encompass Java 2 Enterprise Edition
(J2EE) and ABAP and supports open standards for development.
The major key capability of SAP WebAS is the full support for both the SAP
proprietary and proven ABAP technology and the open source J2EE technology.
SAP WebAS integrates the ABAP and Java personalities in one application
server. This is not performed by providing one hybrid interpreter or virtual
60
machine, but by coupling the ABAP and the Java interpreter through well defined
interfaces and communication channels.
Solution life cycle management

Solution life cycle management services provide technology for all stages of the
software life cycle like design of information technology landscapes, operation, or
change management.

SAP Composite Application Framework (CAF) includes the methodology, tools,
and runtime environment to develop and run composite applications, called SAP
xApps. The application design process is model driven to build applications with
less programming effort.
3.9.2 SAP WebApplication Server

The SAP WebApplication Server is the central foundation for the entire SAP
software stack. All of the mySAP Business Suite solutions (SRM, CRM, SCM,
PLM, ERP) run on SAP WebAS.
Figure 3-12 shows that the architecture of SAP WebApplication Server can be
separated into the following five areas:
Presentation layer
In the presentation layer, the user interface can be developed with Java
Server Pages (JSP), Business Server Pages (BSP), or with Web Dynpro
technology. The underlying business layer provides the business content in
Java or ABAP.
Business layer
The business layer consists of a J2EE certified run-time environment that
processes the requests passed from the ICM and generates the responses
dynamically. The business logic can be written either in ABAP or in Java
based on the J2EE standard. Developers can implement business logic and
persistence with Enterprise JavaBeans (EJB) using the J2EE environment.
Developers can also access the business objects of applications running in
the ABAP environment to benefit from their business logic and persistence.
Integration layer
The local integration engine is an integral part of SAP WebAS and allows
instant connection to SAP XI. The local integration engine provides
messaging services that exchange messages between the components that
are connected in SAP XI.
61
Connectivity layer
The Internet Communication Manager (ICM) dispatches user interface
requests to the presentation layer and provides a single framework for
connectivity using various communication protocols. Currently, modules are
available for Hypertext Transfer Protocol (HTTP), HTTPS (extension of HTTP
running under the Secure Socket Layer (SSL)), Simple Mail Transport
Protocol (SMTP), SOAP, and Fast Common Gateway Interface (FastCGI).
Persistence layer
The persistence layer supports database independence and scalable
transaction handling. Business logic can be developed completely
independent of the underlying database and operating system. Database
independence is also made possible by support for open standards. The
database interface ensures optimized data access from within the ABAP
environment through Open SQL. SAP propagates the outstanding capabilities
of Open SQL for ABAP to Open SQL for Java and offers a variety of standard
APIs to application programmers, such as SQLJ. Other technologies, such as
Java Data Objects (JDO) and container managed persistence (CMP) for EJB
or the direct use of the Java Database Connectivity (JDBC) API are also
supported.
3rdParty
PartyApps/
Apps/
3rd
Exchange
Exchange
Browser/
Portal
SAP Web Application Server

Connectivity
Internet Communication Manager
Presentation Layer
Integration Layer
Web Dynpro
Business Layer
J2EE/ABAP
Persistence
Database Interface
Figure 3-12 SAP WebApplication Server Architecture
62
Integration
Engine
Having described the internal structure of SAP WebApplication Server, let us

now illustrate the most important external interface it offers:
IDocs
Intermediate Documents (IDocs) are containers for exchanging data across
system boundaries.The IDoc type indicates the SAP format that is to be used
to transfer the data for a business transaction between SAP Systems and
partner systems. An IDoc type can transfer several message types, these are
the logical messages that correspond to different business processes.
An IDoc type is described using the following components:
A control record
The format of the control record is identical for all IDoc types.
One or more data records
A data record consists of a fixed administration part and a data part
(segment). The number and format of the segments can vary for each
IDoc type.
Status records
The status records describe the processing stages which an IDoc can
pass through and have an identical format for each IDoc type. IDocs can
be used for outbound and inbound processing.
RFCs/BAPIs
A Remote Function Call (RFC) is a procedure for data interchange between a
client and server. Typically the client calls a server program and the server
returns the results via a TCP/IP connection. RFC function modules in an SAP
system must be proper function modules and must be registered in the SAP
system as remote.
Business APIs (BAPIs) are specific methods for SAP business objects, like
an order, which are stored in the Business Object Repository (BOR) of the
SAP system and are used for carrying out particular business tasks.
In the SAP system, BAPIs are stored as RFC enabled function modules in the
ABAP Workbench Function Builder.
BAPIs have standard business interfaces, which enable external applications
(with the help of SAP business objects) to access SAP processes, functions
and data.
Client programs that use BAPIs to access SAP business objects can be part
of the same SAP system or part of an external system (for example, a
WebSphere application), or part of another SAP system.
63
Web Services
The SAP WebApplication Server implements the following basic Web
Services standards: XML, SOAP, WSDL, UDDI client.
SAP provides a range of components that translate the ABAP standards
(RFC, BAPI) into the communication formats of the Internet.
You create a Web Service so that users can access the available functions,
such as a RFC enabled function module, function group, or BAPI.
To create a Web Service for a function module or a BAPI with a predefined
feature profile, use the Web Service Creation Wizard. The ABAP
Workbench offers an environment where you can publish, search for, and call
Web Services. It enables the SAP WebApplication Server to act both as a
server and client for Web Services.
Note: The context in the called system is not kept open over multiple calls
(calls are stateless; there is no session). Some updating BAPIs require an
additional external commit call to actually cause any change on the SAP
database to happen.
3.9.3 SAP Exchange Infrastructure

SAP Exchange Infrastructure (SAP XI) is the enterprise application integration
(EAI) software from SAP, a component of the NetWeaver product group that is
used to facilitate the exchange of information among a company's internal
software and systems and those of external parties.
SAP calls SAP XI an integration broker because it mediates between entities
with different requirements in terms of connectivity, format and protocols. The
central component of SAP XI is the SAP Integration Server, which facilitates
interaction between diverse operating systems and applications across internal
and external networked computer systems.
64
The implementation of a collaborative process is split into three phases, as

Central Monitoring
Integration Builder (IB)
Integration
Repository
(IR)
Integration
Directory
(ID)
SAP
Systems
3rd Party
Systems
Integration
Server
(IS)
3rd Party
Middleware
Component
Marketplace/
Business
Partner
System Landscape Directory (SLD)

Design
Configuration
Runtime
Figure 3-13 General components of SAP XI
Design time and configuration time each have a central data storage point
providing an overview of all data that is relevant to the cross-component process:
the Integration Repository and the Integration Directory respectively. To edit
this data the Integration Builder is used. The content of the Integration
Repository and Integration Directory is known as collaboration knowledge.
The Integration Server is the central distribution engine for messages in SAP
Exchange Infrastructure at runtime. All systems that use SAP Exchange
Infrastructure to communicate use this server to exchange messages. These
systems are referred to as business systems at a logical level; within a specific
system landscape they are called technical systems or communication parties.
Using the configuration data from the Integration Directory, the Integration Server
decides to which receiver or receivers it must send the message and whether a
mapping needs to be executed beforehand.
The next paragraphs offer a more detailed overview of the architectural
components.
65
Design (integration repository)

During the design phase, you document the entire collaborative process and
determine which interfaces are required. You can either define new system
independent interfaces to implement at a later point in time (outside-in
development) or work with functions that already exist in the systems (inside-out
development). In this phase you design the logical collaborative process by
describing in a specific role the message exchange between the application
components. This description is still not specific to any particular installed
system.
The entire content of the Integration Repository can be shipped. Together, these
objects are referred to as Process Integration Content, abbreviated to XI content.
Configuration (integration directory)

During the configuration phase, you configure your collaborative process for a
specific system landscape. The configuration describes how the Integration
Server is to process inbound messages and to which receiver or receivers
messages must be sent.
For example, you define conditions for the message flow and select design
objects that meet your requirements.
Runtime
The configuration data is evaluated at runtime and controls communication.
SAP XI runtime consists of a series of components:
The Integration Engine is the central runtime component. It receives
messages using XI message protocol and performs central services such as
routing and mapping for received messages.
The proxy runtime uses proxies to exchange messages with the Integration
Server. This section addresses the programming model for ABAP and Java
proxies.
The Adapter Engine is the runtime component for adapter communication.
Adapters are used to connect other systems to the Integration server. Each
adapter converts calls or messages from a sender into the XI message format
for the Integration Engine and conversely, the adapter receives messages
from the Integration Engine and converts them for the receiver.
The respective adapters are either connected using the Adapter Engine or
run independently (for instance, the IDoc adapter and the plain HTTP
adapter).
Central monitoring monitors XI runtime components, the message flow, and
the performance.
66
The Business Process Engine is the runtime component for the execution of
integration processes on the Integration Server. It extends the Integration
Server function to include stateful message processing.
Figure 3-14 provides an overview of all the components that can communicate
with the Integration Server.
Central Monitoring
Integration Server
Integration
Directory
Business Process Engine
Integration Engine
System
Landscape
Directory
Adapter Engine
XI
Protocol
Non-Central
Integration Engine
RosettaNet, ... XI
Protocol
IDocs
RFCs
File
DB
JMS
Proxy Runtime
Proxy
SAP Web AS > 6.40
SAP
System
3rd Party
Systems
Apps of
Business
Partner
Partner
Connectivity
Kit
Apps of
(small)
Business
Partner
Figure 3-14 SAP XI Integration Server
All the systems either send messages to, or receive messages from the
Integration Server. It is the task of the Integration Server to distribute the
messages received according to the rules that are configured in the Integration
Directory. In this way, messages can be exchanged between all systems in a
heterogeneous system landscape, regardless of whether a message was sent to
the Integration Server using an adapter or the proxy runtime.
SAP System Landscape Directory

The System Landscape Directory (SLD) is an SAP product that enables you to
describe products, software components, logical systems, and technical
systems.
SAP XI accesses this information at design time, configuration time, and runtime.
Before a customer who uses SAP XI can begin configuration, he must first enter
all the business systems and assigned technical systems in the SLD.
67
A system landscape comprises the following different types of system:

Technical systems with which the hardware of the system is specified in more
detail. Examples of a technical system are an SAP WebAS (ABAP) or an SAP
WebAS (Java).
Business systems, which name the logical receiver independently of technical
properties. For example, a business system might be a client of an SAP
system.
Third-party systems
SAP Integration Builder Toolset

SAP Integration Builder is the central tool for the design and configuration of SAP
XI. The Integration Builder creates design objects in the Integration Repository
and configuration objects in the Integration Directory.
Depending for which of these tasks you call the Integration Builder, you choose
one of the following links on the SAP Exchange Infrastructure initial panel:
Integration Builder: Design - Integration Repository
Integration Builder: Configuration - Integration Directory
Both Java applications use the same GUI framework and are started using Java
Web Start. The Integration Builder: Design offers functions to:
Define message types

Map from one message type to another
Define business processes
Define scenarios consisting of business systems, business processes and
message types
The design objects are based on XML standards. SAP Exchange Infrastructure
supports various XML standards, like XSD, WSDL or BPEL. The advantage of
this is that you can reuse external programs and schema definitions.
Using the tool Integration Builder: Configuration an integration scenario is
defined, which consists of:
The business systems or business processes, which are involved in the
scenario as a receiver or sender of message.
Communication channels defining the protocol of the connection between a
business system and the Integration Server.
The message types and their mapping rules that are associated with the
communication channels.
The routing rules defining how the Integration Server forwards received
message to receiving business systems.
68
The configuration data is structured, organized, and saved in the Integration

Directory in the form of configuration objects. Configuration objects are identified
uniquely by an object key.
SAP Integration Monitoring: Runtime Workbench

The Runtime Workbench is the central tool in SAP Exchange Infrastructure for
monitoring and testing the individual components and for monitoring message
processing and performance.
The Runtime Workbench gives you the option of navigating to the monitoring
functions of the Integration Engine, as well as integration with the Computing
Center Management System (CCMS), and the Process Monitoring Infrastructure
(PMI) of SAP.
3.9.4 Reference documentation

You can find detailed information about SAP products at:
http://help.sap.com
When looking for SAP XI help, select SAP Netweaver 2004s Select
language Key Capability Process integration Integration Broker.
69
70
Part 2
Part
Scenarios
This part provides an overview of the integration solutions that we use as sample
business scenarios in this book. We begin this part with a chapter that provides
an overview of the scenarios. Then, in the chapters that follow, we talk about
each scenario in detail and discuss the following topics:
Operational models
Preparation
Installation
Configuration
Testing
Conclusion
71
72
Chapter 4.
Scenarios overview
This chapter gives an overview of the wide range of feasible integration
scenarios between IBM and SAP components. The first section uses tables to
make the different integration options visible and gives you the opportunity to
select between various decision criteria. The second section discusses briefly
the most popular feasible integration options. The last section includes more
details about the scenarios that we implement in this book.
This chapter includes the following topics:
Integration scenario tables on page 74
Feasible integration scenarios on page 80
Implemented integration scenarios in this book on page 124
73
4.1 Integration scenario tables

The set of tables that we discuss in this section makes it easier to find a suitable
integration scenario. The fact is that there are multiple components on the SAP
side that have to be integrated into various components on the IBM side. This
complexity is increased by the availability of various standards and products to
do a particular integration. The availability of many standards makes it a fairly
complex task to find an ideal solution.
4.1.1 Architectural overview

Typical IT environments today host multiple business applications that belong to
different business units. These environments are implemented using different
technologies and mostly follow different architectural paradigms. Todays IT
environments are heterogeneous. Even when dealing with only two vendors
such as SAP and IBM, there are many options of how to integrate the multiple
components that these vendors offer in a meaningful way, as illustrated in
Figure 4-1.
IBM
domain
J2EE
HTML
gifs
MVS
IMS
3270
CGI
Network
iSeries
Queues
JNDI
IIOP
DOS
EJBs
VM
JCA
APIs
CICS
MDBs
JMS
DB2
RMI
DASD
RPCs
Servlets
Java
XML
EIS
JSPs
SOAP
COBOL
Web Services
Linux
ERP
SQL
CORBA
WSIF
URLs
jpgs
HTTP
SAP
domain
WSDL
JDBC
Figure 4-1 Heterogeneous system landscape
Besides proprietary and open standards, there are various access mechanisms
and policies in place which have to be taken into consideration when choosing
an appropriate integration approach.
74
4.1.2 Table synopsis

The tables in this section display in a efficient way the large number of
connectivity options between SAP components and the various IBM middleware
products.
Key to reading the tables
The top headings in a table lists SAP systems. The side headings list IBM
middleware systems together with the communication direction. The inbound
and outbound label is used from the viewing perspective of the IBM
component. Inbound means SAP is calling the IBM component, while
outbound means that the IBM component is calling the SAP component.
List of abbreviations used in tables:

WAS
WPS
WebSphere Process Server V6
WESB
WebSphere Enterprise Service Bus V6
WMB
WebSphere Message Broker, also Advanced ESB
WMQ
WebSphere MQ
XI
SAP Exchange Infrastructure
SAP WebAS
SAP Web Application Server
J2EE
Java 2 Enterprise Edition
ABAP
ABAP
BAPI
Business Application Programming Interface
ALE/IDoc
ALE/IDoc
AXM
ABAP Extension Module
WS
Web Services
JMS
Java Message Service
SCA
Service component architecture
RFC
Remote Function Call
R/3 link
WebSphere MQ link for SAP R/3
Adapter
Adapter available to achieve connectivity (see detail table)
Chapter 4. Scenarios overview
75
Table 4-1 provides an overview of all feasible integration scenarios. It highlights

the approaches and protocols used to integrate the various IBM and SAP
components. Which option you choose depends on the specific requirements of
your integration project.
Table 4-1 All feasible integration scenarios by protocol and binding
SAP
Exchange
Infrastructure
WAS
WPS /
WESB
(SCA)
WMB
WMQ
SAP WebSphere Application Server

ABAP
J2EE
WS
BAPI
ALE/IDoc
AXM
Outbound
WS / JMS
WS
WS
RFC
RFC
n/a
Inbound
WS / JMS
WS
WS
RFC
RFC
n/a
Outbound
WS / JMS
WS
WS
Inbound
WS / JMS
WS
WS
Outbound
WS / JMS
WS
WS
Inbound
WS / JMS
WS
WS
Outbound
JMS
JMS
n/a
n/a
R/3 link
n/a
Inbound
JMS
JMS
n/a
n/a
R/3 link
n/a
T1a - Adapter
N3b
a. These are adapter based integration scenarios. Refer to Table 4-2 for more details.
b. These scenarios are described in WebSphere Business Integration for SAP, SG24-6354. Because
the setup and configuration has not changed, we do not describe these scenarios again in our book.
Table 4-2 highlights in more detail the adapter-based integration scenarios and
differentiates between the use of the WebSphere Adapter for SAP and the
WebSphere Business Integration Adapter for SAP.
Table 4-2 T1 - Adapter based integration scenarios
WPS /
WESB
(SCA)
76
JCA Adapter
WebSphere Business
Integration Adapter
BAPI
ALE
/IDoc
BAPI
ALE /IDoc
AXM
Outbound
BA
A1
BA
A1
DT
Inbound
n/a
A1,A2
RF
A1,A2
AEN
BAPI
BA
Single BAPI
Multiple BAPI
Transactional BAPI
Read Table BAPI
ALE
RF
RFC Server
A1
Single ALE
Batch ALE
ABAP
Extension
Module
A2
ALE with acknowledgement
AEN
Advanced Event Notification
DT
Dynamic Transactions
Dynamic retrieve
Advanced iDoc Handling
Important: The WebSphere Business Integration Adapter for SAP requires

Java Message Service (JMS) connectivity to the corresponding integration
broker. There are various options to setup this connectivity.
Option 1: Use the internal SIBus only. The WebSphere Business
Integration Adapter connects directly to the SIBus and the queues created
within the SIBus. The adapter is handled here like a native MQ Client Link
communication partner.
Option 2: Use the internal SIBus together with an external WebSphere MQ.
The WebSphere Business Integration Adapter connects to the external
WebSphere MQ. The integration logic in WebSphere Enterprise Service
Bus connects to the internal SIBus. A dedicated MQ Link is established
between the SIBus and WebSphere MQ to enable the server-to-server
communication.
Option 3: Use external WebSphere MQ as default JMS provider. The
WebSphere Business Integration Adapter connects to the external
WebSphere MQ as well as the WebSphere Enterprise Service Bus. This
means that the internal SIBus is completely bypassed and also the
developed integration artefact within WebSphere Enterprise Service Bus
use the external JMS provider.
77
Table 4-3 lists all integration scenarios that are technically feasible and that could
be set up between the various IBM and SAP components. Which option you
choose depends on the specific requirements of your integration project.
Table 4-3 Enumeration of all feasible integration scenarios
SAP Exchange
Infrastructure
SAP WebAS
ABAP
J2EE
WAS
WPS /
WESB
(SCA)
WMB
WMQ
WS
BAPI
ALE/IDoc
AEN
Outbound
i,xix
ii
iii
xxix
xxx
n/a
Inbound
iv,xx
vi
xxxi
xxxii
n/a
Outbound
vii,xxi
viii
ix
Inbound
x,xxii
xi
xii
Outbound
xiii,xxiii
xiv
xv
Inbound
xvi,xxiv
xvii
xviii
Outbound
xxv
xxvi
n/a
n/a
xlii
n/a
Inbound
xxvii
xxviii
n/a
n/a
xliii
n/a
T3
N3
Table 4-4 highlights in more detail the feasible adapter-based integration

scenarios and differentiates between the use of the WebSphere Adapter for SAP
or the WebSphere Business Integration Adapter for SAP.
Table 4-4 T3 - Enumeration of all feasible adapter based integration scenarios
WPS /
WESB
(SCA)
78
JCA Adapter
WebSphere Business
Integration Adapter
BAPI
ALE
/IDoc
BAPI
ALE
/IDoc
AEN
Outbound
xxxiii
xxxiv
xxxvi
xxxvii
xxxviii
Inbound
n/a
xxxv
xxxix
xl
xli
Table 4-5 provides an overview of integration scenarios implemented in this book

with chapter, scenario reference. It lists the implemented integration scenarios in
this book and references the chapters that include the implmentation.
Table 4-5 Integration scenarios implemented in this book
SAP
Exchange
Infrastructure
Outbound
WAS
WPS /
WESB
(SCA)
WMB
Inbound
ABAP
J2EE
WS
BAPI
ALE/IDoc
11A,11B,
11C,11D
12B,12C
AEN
9B
10A
Outbound
6A,7A
Inbound
6C,7B
Outbound
8A
Inbound
8B
Outbound
WMQ
6B
SAP WebAS
9A
12A
13A,13B
10B
Inbound
79
4.2 Feasible integration scenarios

In this section we discuss the feasible integration scenarios. To best use the
information that we present here, you will not read this section from beginning to
end. Instead, you can use the tables that we list in 4.1.2, Table synopsis on
page 75 to find a suitable scenario. Then, you can read just the scenario that
applies to your situation.
Note: The sections that describe the scenarios include a certain amount of
repetition because many of them share similar integration approaches or the
same transport and standards.
Here are some general observations that apply to the 1 through 30 (4.2.1,
WebSphere Application Server invoking SAP XI using Web Services (i) through
4.2.30, WebSphere Application Server invoking SAP ERP using SAP JCo and
ALE (xxx)):
Web Services invocation
Both IBM WebSphere Application Server and SAP XI support the Web
Services standard, including the Web Services Basic profile that is defined by
the Web Services Interoperability organization. It uses HTTP protocol, which
is widely supported across different systems. It is easy to use and requires no
additional components to support it. However, it lacks QoS features such as
assured message delivery and once only message delivery. HTTP is not
sufficient when enterprise-like requirements are defined for a communication
path such as no duplicate calls or no lost messages.
JMS invocation
The JMS standard is included in the J2EE 1.4 specification, which is
supported by both IBM WebSphere Application Server and SAP XI. The JMS
protocol provides a much higher QoS than HTTP does. It provides QoS
features such as assured message delivery and once only message delivery.
Additionally using JMS enables the setup of much complex scenarios as the
request and response messages can be persisted, mediated, and routed
during the delivery from the sender to the receiver. The major drawback is
that a dedicated system is needed which acts a JMS provider, and this
system has to be supported by all attached systems that want to participate in
a integration scenario. IBM WebSphere MQ is such a JMS provider that can
be used to connect IBM WebSphere components and SAP components such
as SAP Exchange Infrastructure or SAP Web Application Server.
80
4.2.1 WebSphere Application Server invoking SAP XI using

Web Services (i)
This scenario uses the SOAP adapter of the SAP Exchange Infrastructure to
expose a business function as a Web Service to the external environment. The
Web Services Description Language based interface can be exported and used
to generate a Web Services client on the WebSphere Application Server side.
The supported transport mechanism between the Web Service client and the
Web Service provider is HTTP (Figure 4-2).
System B
WAS
J2EE Application
WS Client
SOAP/HTTP
Synchronous invocation
SOAP Adapter
System A
SAP XI
Figure 4-2 Functional model scenario 4.2.1
In this scenario SAP Exchange Infrastructure acts as a Web Service provider

while IBM WebSphere Application Server is the Web Service consumer.
You can find a list of other feasible integration scenarios in Table 4-3 on page 78.
You can find a further description of this integration scenario in 4.3.3,
WebSphere Application Server invoking SAP Exchange Infrastructure using
Web Service (6B) on page 128.
4.2.2 WebSphere Application Server invoking SAP J2EE using

Web Services (ii)
This scenario uses the built-in Web Services capabilities of the SAP J2EE engine
to expose a standard Java-based business function as a Web Service to the
external environment. The Web Services Description Language based interface
81
can be exported and used to generate a Web Services client on the WebSphere
Application Server side. The supported transport mechanism between the Web
Service client and the Web Service provider is HTTP (Figure 4-3).
System A
System B
WAS
SAP J2EE
J2EE Application
WS Client
J2EE Application
SOAP/HTTP
WS Provider
In this scenario the SAP J2EE engine acts as a Web Service provider while IBM
WebSphere Application Server is the Web Service consumer.
4.2.3 WebSphere Application Server invoking SAP WebAS (ABAP)

using Web Services (iii)
This scenario uses the built-in Web Services capabilities of the ABAP part of the
SAP Web Application Server. Since release 6.40 of the SAP Web Application
Server, SAP provides an ABAP based Web Service Framework that can be used
to expose BAPIs and Remote Function Modules as a Web Service to the
can be exported and used to generate a Web Services client on the WebSphere
Application Server side. The supported transport mechanism between the Web
System A
System B
WAS
SAP WebAS
J2EE Application
WS Client
ABAP Application
SOAP/HTTP
82
WS Provider
In this scenario the ABAP part of the SAP Web Application Server acts as a Web
Service provider while IBM WebSphere Application Server is the Web Service
consumer.
You can find a further description of this integration scenario in WebSphere
Application Server invoking SAP Web Application Server using Web Service
(9B) on page 133.
4.2.4 SAP XI invoking WebSphere Application Server using

Web Services (iv)
This scenario uses the built-in Web Services capabilities of the IBM WebSphere
Application Server to expose a standard Java based business function as a Web
Service to the external environment. The Web Services Description Language
based interface can be exported and used to generate the relevant artifacts
within the SAP Exchange Infrastructure. Finally the SOAP adapter of the SAP
Exchange Infrastructure is configured to make the respective Web Service call.
System B
WAS
J2EE Application
WS Provider
SOAP/HTTP
SOAP Adapter
System A
SAP XI
In this scenario the IBM WebSphere Application Server acts as the Web Service
provider while SAP Exchange Infrastructure is the Web Service consumer.
83
4.2.5 SAP J2EE invoking WebSphere Application Server using

Web Services (v)
based interface can be exported and used to generate a Web Services client on
the SAP J2EE engine. The supported transport mechanism between the Web
System A
System B
WAS
SAP J2EE
J2EE Application
WS Provider
J2EE Application
SOAP/HTTP
WS Client
In this scenario, the IBM WebSphere Application Server acts as the Web Service
provider while the SAP J2EE engine is the Web Service consumer.
84
4.2.6 SAP WebAS (ABAP) invoking WebSphere Application Server

using Web Services (vi)
based interface can be exported and used to generate the relevant ABAP
artifacts within the SAP Web Application Server together with an ABAP based
Web Service client. The supported transport mechanism between the Web
System A
System B
WAS
SAP WebAS
J2EE Application
WS Provider
ABAP Application
SOAP/HTTP
WS Client
In this scenario the IBM WebSphere Application Server acts as the Web Service
provider while the SAP Web Application Server is the Web Service consumer.
You can find a further description of this integration scenario in 4.3.11, SAP ERP
invoking WebSphere Application Server using XML over HTTP (10A) on
page 134.
85
4.2.7 WebSphere Process Server and WebSphere Enterprise Service

Bus invoking SAP XI using Web Services (vii)
to generate an Import node with a Web Services binding in the respective
Service Component Architecture Module. The supported transport mechanism
between the Web Service client and the Web Service provider is HTTP
(Figure 4-8).
System B
WPS/WESB
SCA Module
WS Import
SOAP/HTTP
SOAP Adapter
System A
SAP XI

while IBM WebSphere Process Server and WebSphere Enterprise Service Bus
is the Web Service consumer.
WebSphere Enterprise Service Bus invoking SAP Exchange Infrastructure
using Web Service (6A) on page 127.
86

Bus invoking SAP J2EE using Web Services (viii)
to expose a standard Java based business function as a Web Service to the
can be exported and used to generate an Import node with a Web Services
binding in the respective Service Component Architecture Module. The
supported transport mechanism between the Web Service client and the Web
Service provider is HTTP (Figure 4-9).
System A
System B
WPS/WESB
SAP J2EE
SCA Module
WS Import
J2EE Application
SOAP/HTTP
WS Provider
In this scenario, the SAP J2EE engine acts as a Web Service provider while IBM
WebSphere Process Server/WebSphere Enterprise Service Bus is the Web
Service consumer.
87

Bus invoking ABAP using Web Services (ix)
Server SAP is providing an ABAP based Web Service Framework which can be
used to expose BAPIs and Remote Function Modules as a Web Service to the
can be exported and used to generate an Import node with a Web Services
binding in the respective Service Component Architecture Module. The
System A
System B
WPS/WESB
SAP WebAS
SCA Module
WS Import
ABAP Application
SOAP/HTTP
WS Provider
In this scenario, the SAP Web Application Server acts as a Web Service provider
while IBM WebSphere Process Server/WebSphere Enterprise Service Bus is the
Web Service consumer.
WebSphere Enterprise Service Bus invoking SAP Web Application Server
(ABAP) using Web Service (9A) on page 133.
88

Enterprise Service Bus using Web Services (x)
This scenario uses the Service Component Architecture capabilities of the IBM
WebSphere Process Server and WebSphere Enterprise Service Bus. It exposes
an operation of an integration module as a Web Service to the external
environment by defining an Export node with Web Service binding. The
WSDL-based interface of the Export node can be exported and used to generate
the relevant artifacts within the SAP Exchange Infrastructure. Finally, the SOAP
adapter of the SAP Exchange Infrastructure is configured to make the respective
Web Service call. The supported transport mechanism between the Web Service
client and the Web Service provider is HTTP (Figure 4-11).
System B
WPS/WESB
SCA Module
WS Export
SOAP/HTTP
SOAP Adapter
System A
SAP XI
In this scenario the IBM WebSphere Process Server and WebSphere Enterprise
Service Bus acts as a Web Service provider while the SAP Exchange
Infrastructure is the Web Service consumer.
You can find a further description of this integration scenario in 4.3.4, SAP
Exchange Infrastructure invoking WebSphere Enterprise Service Bus using Web
Service (6C) on page 129.
89
4.2.11 SAP J2EE invoking WebSphere Process Server/WebSphere

Enterprise Service Bus using Web Services (xi)
environment by defining an Export node with Web Service binding. The Web
Services Description Language based interface of the Export node can be
exported and used to generate a Web Services client on the SAP J2EE engine.
System A
System B
WPS/WESB
SAP J2EE
SCA Module
WS Export
J2EE Application
SOAP/HTTP
WS Client
Service Bus acts as a Web Service provider while the SAP J2EE engine is the
90
4.2.12 SAP WebAS (ABAP) invoking WebSphere Process Server and

WebSphere Enterprise Service Bus using Web Services (xii)
environment by defining an Export node with Web Service binding. The Web
Services Description Language based interface of the Export node can be
exported and used to generate the relevant ABAP artifacts within the SAP Web
Application Server together with an ABAP-based Web Service client. The
System A
System B
WPS/WESB
SAP WebAS
SCA Module
WS Export
ABAP Application
SOAP/HTTP
WS Client
In this scenario the IBM WebSphere Process Server/WebSphere Enterprise

Service Bus acts as a Web Service provider while the SAP Web Application
Server is the Web Service consumer.
91
4.2.13 WebSphere Message Broker invoking SAP XI using

Web Services (xiii)
to generate a message set within a WebSphere Message Broker project. The
standard HTTP Request Node can be utilized to execute the respective Web
Service call within the message flow. The supported transport mechanism
between the Web Service client and the Web Service provider is HTTP
(Figure 4-14).
System B
WMB
Message Flow
HTTP
Request Node
SOAP/HTTP
SOAP Adapter
System A
SAP XI

while IBM WebSphere Message Broker is the Web Service consumer.
92
4.2.14 WebSphere Message Broker invoking SAP J2EE using Web

Services (xiv)
to expose a standard Java based business function as a Web Service to the
can be exported and used to generate a message set within a WebSphere
Message Broker project. The standard HTTP Request Node can be utilized to
execute the respective Web Service call within the message flow. The supported
transport mechanism between the Web Service client and the Web Service
provider is HTTP (Figure 4-15).
System A
System B
WMB
SAP J2EE
Message Flow
HTTP
Request Node
J2EE Application
SOAP/HTTP
WS Provider
In this scenario SAP J2EE engine acts as a Web Service provider while IBM
WebSphere Message Broker is the Web Service consumer.
93
4.2.15 WebSphere Message Broker invoking SAP WebAS (ABAP)

using Web Services (xv)
Server SAP is providing an ABAP based Web Service Framework which can be
used to expose BAPIs and Remote Function Modules as a Web Service to the
can be exported and used to generate a message set within a WebSphere
Message Broker project. The standard HTTP Request Node can be utilized to
execute the respective Web Service call within the message flow. The supported
System A
System B
WMB
SAP WebAS
Message Flow
HTTP
Request Node
ABAP Application
SOAP/HTTP
WS Provider
In this scenario SAP Web Application Server acts as a Web Service provider
while IBM WebSphere Message Broker is the Web Service consumer.
94
4.2.16 SAP XI invoking WebSphere Message Broker using

Web Services (xvi)
This scenario uses the capability of IBM WebSphere Message Broker to expose
message flows as Web Services by using the built-in HTTP Input Node.
WebSphere Message Broker is able to create a Web Services Description
Language based representation of the expected Message. The Web Services
Description Language based interface of the HTTP Input Node can be exported
and used to generate the relevant artifacts within the SAP Exchange
Infrastructure. Finally, the SOAP adapter of the SAP Exchange Infrastructure is
configured to make the respective Web Service call. The supported transport
mechanism between the Web Service client and the Web Service provider is
HTTP (Figure 4-17).
System B
WMB
Message Flow
HTTP
Input Node
SOAP/HTTP
SOAP Adapter
System A
SAP XI
In this scenario IBM WebSphere Message Broker acts as a Web Service

provider while SAP Exchange Infrastructure is the Web Service consumer.
95
4.2.17 SAP J2EE invoking WebSphere Message Broker using

Web Services (xvii)
and used to generate a Web Services client on the SAP J2EE engine. The
System A
System B
WMB
SAP J2EE
Message Flow
HTTP
Input Node
J2EE Application
SOAP/HTTP
WS Client

provider while the SAP J2EE engine is the Web Service consumer.
96
4.2.18 SAP WebAS (ABAP) invoking WebSphere Message Broker

using Web Services (xviii)
and used to generate the relevant ABAP artifacts within the SAP Web Application
Server together with an ABAP based Web Service client. The supported
System A
System B
WMB
SAP WebAS
Message Flow
HTTP
Input Node
ABAP Application
SOAP/HTTP
WS Client

provider while the SAP Web Application Server is the Web Service consumer.
97
4.2.19 WebSphere Application Server invoking SAP XI using JMS

(xix)
This scenario describes how to benefit from the fact that IBM WebSphere
Application Server as well as SAP Exchange Infrastructure support the JMS
standard. Assumed a JMS provider is put in between which is supported by both
vendors, like WebSphere MQ, messages can be exchanged using the standard
JMS API. In this particular scenario a J2EE application deployed on IBM
WebSphere Application Server emits a message to a dedicated message queue.
The SAP Exchange Infrastructure system uses the built-in JMS adapter to
receive the message from this queue and to execute a certain function
(Figure 4-20).
System B
WAS
J2EE Application
JMS Provider
Message
Producer (EJB)
JMS Adapter
System A
SAP XI
Asynchronous invocation
Assured delivery
In this scenario SAP Exchange Infrastructure acts as the message consumer

while the IBM WebSphere Application Server is the message producer.
98
4.2.20 SAP XI invoking WebSphere Application Server using JMS

(xx)
Application Server as well as SAP Exchange Infrastructure support the JMS
standard. Assumed a JMS provider is put in between which is supported by both
vendors, such as WebSphere MQ, messages can be exchanged using the
standard JMS API. In this particular scenario the SAP Exchange Infrastructure
system uses the built-in JMS adapter to emit a message to a dedicated message
queue. The IBM WebSphere Application Server runs a J2EE application which
receives the message from this queue and executes a certain function
(Figure 4-21).
System A
System B
J2EE Application
JMS Adapter
WAS
JMS Provider
Message
Listener (MDB)
SAP XI
Assured delivery
In this scenario IBM WebSphere Application Server acts as the message

consumer while the SAP Exchange Infrastructure is the message producer.
99
4.2.21 WebSphere Process Server and WebSphere Enterprise

Service Bus invoking SAP XI using JMS (xxi)
Process Server and WebSphere Enterprise Service Bus as well as SAP
Exchange Infrastructure support the JMS standard. Assumed a JMS provider is
put in between which is supported by both vendors, like WebSphere MQ,
messages can be exchanged using the standard JMS API. In this particular
scenario a Service Component Architecture Module can use an Import node with
JMS binding to emit a message to a dedicated message queue. The SAP
Exchange Infrastructure system uses the built-in JMS adapter to receive the
message from this queue and to execute a certain function (Figure 4-22).
System B
WPS/WESB
SCA Module
JMS Provider
JMS Import
JMS Adapter
System A
SAP XI
Assured delivery
In this scenario SAP Exchange Infrastructure acts as the message consumer

while the IBM WebSphere Process Server/WebSphere Enterprise Service Bus is
the message producer.
WebSphere Enterprise Service Bus invoking SAP Exchange Infrastructure
using JMS (7A) on page 130.
100

Enterprise Service Bus using JMS (xxii)
Process Server and WebSphere Enterprise Service Bus as well as SAP
Exchange Infrastructure support the JMS standard. Assumed a JMS provider is
put in between which is supported by both vendors, like WebSphere MQ,
messages can be exchanged using the standard JMS API. In this particular
scenario the SAP Exchange Infrastructure system uses the built-in JMS adapter
to emit a message to a dedicated message queue. The Service Component
Architecture Module can use an Export node with JMS binding to receive the
message from this queue and executes a certain function (Figure 4-23).
System B
WPS/WESB
SCA Module
JMS Provider
JMS Export
JMS Adapter
System A
SAP XI
Assured delivery
In this scenario IBM WebSphere Process Server/WebSphere Enterprise Service

Bus acts as the message consumer while the SAP Exchange Infrastructure is the
message producer.
Exchange Infrastructure invoking WebSphere Enterprise Service Bus using JMS
(7B) on page 131.
101
4.2.23 WebSphere Message Broker invoking SAP XI using JMS (xxiii)

This scenario describes how to benefit from IBM WebSphere Message Broker
and SAP Exchange Infrastructure supporting the JMS standard. If a JMS
provider, such as WebSphere MQ, is between the two products, messages can
be exchanged using the standard JMS API.
In this particular scenario a message flow uses a MQOutputNode to emit a
message to a dedicated message queue. The SAP Exchange Infrastructure
system uses the built-in JMS adapter to receive the message from this queue
and to execute a certain function. Because the built-in JMS adapter of SAP
Exchange Infrastructure supports natively only one-way communication, a
Correlation Bridge is needed to generate a response message and put it to the
correct ReplyTo Queue which is observed by a MQInputNode. For one-way
communication types the reply path and the Correlation Bridge are not required
(Figure 4-24).
System B
WMB
Message Flow
JMS Provider
MQOutputNode
MQInputNode
JMS Adapter
System A
SAP XI
Correlation
Bridge
Assured delivery
In this scenario SAP Exchange Infrastructure acts as the Service provider while
the IBM WebSphere Message Broker is the Service consumer.
WebSphere Message Broker invoking SAP Exchange Infrastructure using JMS
(8A) on page 132.
102
4.2.24 SAP XI invoking WebSphere Message Broker using JMS (xxiv)

This scenario describes how to benefit from IBM WebSphere Message Broker
and SAP Exchange Infrastructure supporting the JMS standard. If a JMS
provider, such as WebSphere MQ, is between the two products, messages can
be exchanged using the standard JMS API.
In this particular scenario the SAP Exchange Infrastructure system uses the
built-in JMS adapter to emit a message to a dedicated message queue. A
message flow running on WebSphere Message Broker can use a MQInputNode
to pick up this message and to execute a certain function. The response is put to
the ReplyTo Queue using a MQOutputNode. The Service Component
Architecture Module can use an Export node with JMS binding to receive the
message from this queue and to execute a certain function. Because the built-in
JMS adapter of SAP Exchange Infrastructure supports native only one-way
communication, a Correlation Bridge is needed to recognize and correlate the
response to the corresponding request. For one-way communication types, the
reply path and the Correlation Bridge are not required (Figure 4-25).
System A
System B
Message Flow
JMS Adapter
WMB
JMS Provider
MQInputNode
MQOutputNode
SAP XI
Correlation
Bridge
Assured delivery
In this scenario IBM WebSphere Message Broker acts as the Service provider
while the SAP Exchange Infrastructure is the Service consumer.
Exchange Infrastructure invoking WebSphere Message Broker using JMS (8B)
on page 132.
103
4.2.25 WebSphere MQ connecting to SAP XI using JMS (xxv)

This integration scenario highlights the fact that SAP Exchange Infrastructure
supports WebSphere MQ as a standard JMS provider. The built-in JMS adapter
of the SAP Exchange Infrastructure can be configured to connect to a
WebSphere MQ queue manager and to consume messages from a dedicated
message queue (Figure 4-26). Considering that nearly any platform can connect
to WebSphere MQ and use it as messaging backbone, this scenario is the
baseline for many more complex setups.
System B
WebSphere MQ
Queue Manager
JMS Provider
Assured delivery
JMS Adapter
System A
SAP XI
In this scenario IBM WebSphere MQ acts as a JMS provider and messaging

backbone while the SAP Exchange Infrastructure is the message consumer.
104
4.2.26 WebSphere MQ connecting to SAP J2EE using JMS (xxvi)

This integration scenario highlights the fact that the SAP J2EE engine supports
the JMS standard and can therefore connect to WebSphere MQ as a standard
JMS provider. A J2EE application deployed on the SAP J2EE engine can use the
JMS API to connect to a WebSphere MQ queue manager and to consume
messages from a dedicated message queue (Figure 4-27). Considering that
nearly any platform can connect to WebSphere MQ and use it as messaging
backbone, this scenario is the baseline for many more complex setups.
System A
System B
WebSphere MQ
SAP J2EE
Queue Manager
J2EE Application
JMS
Message
Listener (MDB)

backbone while the SAP J2EE engine is the message consumer.
105
4.2.27 SAP XI connecting to WebSphere MQ using JMS (xxvii)

This integration scenario highlights the fact that SAP Exchange Infrastructure
supports WebSphere MQ as a standard JMS provider. The built-in JMS adapter
of the SAP Exchange Infrastructure can be configured to connect to a
WebSphere MQ queue manager and to emit messages to a dedicated message
queue (Figure 4-28). Considering that nearly any platform can connect to
WebSphere MQ and use it as messaging backbone, this scenario is the baseline
for many more complex setups.
System B
WebSphere MQ
Queue Manager
JMS Provider
Assured delivery
JMS Adapter
System A
SAP XI

backbone while the SAP Exchange Infrastructure is the message emitter.
106
4.2.28 SAP J2EE connecting to WebSphere MQ using JMS (xxviii)

This integration scenario highlights the fact that the SAP J2EE engine supports
the JMS standard and can therefore connect to WebSphere MQ as a standard
JMS provider. A J2EE application deployed on the SAP J2EE engine can use the
JMS API to connect to a WebSphere MQ queue manager and to emit messages
to a dedicated message queue (Figure 4-29). Considering that nearly any
platform can connect to WebSphere MQ and use it as messaging backbone, this
scenario is the baseline for many more complex setups.
System A
System B
WebSphere MQ
SAP J2EE
Queue Manager
J2EE Application
JMS
Message
Producer (EJB)

backbone while the SAP J2EE engine is the message emitter.
107
4.2.29 WebSphere Application Server invoking SAP ERP using SAP

JCo (xxix)
This scenario describes how to use the SAP Java Connector (JCo) to build a
communication channel between IBM WebSphere Application Server and any
ABAP-based SAP ERP system. J2EE applications that are developed and
deployed on IBM WebSphere Application Server can use the JCo API to call any
remote enabled function module within an ABAP-based SAP ERP system. The
SAP Java Connector enables Java developers to communicate with ABAP based
back-end systems seamlessly by using a familiar Java based API. The
connectivity to the target SAP ERP system is performed by using the SAP RFC
protocol (Figure 4-30).
WAS
J2EE Application
System B
SAP Java
Connector (JCO)
System A
SAP ERP
TCP / RFC
JCO as RFC Client
BAPI/RFM
BAPI/RFM
BAPI/RFM
In this scenario the SAP ERP systems acts as a service provider while IBM
WebSphere Application Server is the service requestor.
108
4.2.30 WebSphere Application Server invoking SAP ERP using SAP

JCo and ALE (xxx)
deployed on IBM WebSphere Application Server can use the JCo API to send an
Intermediate Document (IDoc) into an ABAP-based SAP ERP system. Within the
SAP ALE distribution model, the external J2EE application is handled as a
standard message sender, and the received IDOC is processed as though it is
defined in the ALE distribution model.
The SAP Java Connector enables Java developers to communicate with
ABAP-based back-end systems seamlessly by using a familiar Java based API.
The connectivity to the target SAP ERP system is performed by using the SAP
RFC protocol (Figure 4-31).
J2EE Application
J2EE Application
Send
IDOC
System B
SAP Java
Connector (JCO)
System A
SAP ERP
TCP / RFC
Asynchronous IDOC delivery
Receive
IDOC
ALE
Distribution
Model
In this scenario the SAP ERP systems acts as the IDOC receiver while IBM
WebSphere Application Server is the IDOC sender.
109
4.2.31 SAP ERP invoking WebSphere Application Server using SAP

JCo (xxxi)
deployed on IBM WebSphere Application Server can use the JCo API to register
a RFC Server at the SAP gateway of a dedicated SAP ERP system.
Using this RFC Server capability, ABAP-based applications can call through the
SAP Gateway a remote destination in a transparent manner and execute
business logic that is implemented in Java rather than ABAP. The SAP Java
Connector enables Java developers to communicate with ABAP based back-end
systems seamlessly by using a familiar Java based API. The connectivity to the
target SAP ERP system is performed by using the SAP RFC protocol
(Figure 4-32).
J2EE Application
RFC Server
TCP / RFC
JCO as RFC Server
SAP Gateway
WAS
System B
SAP Java
Connector (JCO)
System A
SAP ERP
ABAP Application
In this scenario the J2EE application deployed on the IBM WebSphere

Application Server acts as a RFC Server providing business functions to the SAP
ERP system which is here acting as a RFC Client.
110
4.2.32 SAP ERP invoking WebSphere Application Server using SAP

JCo and ALE (xxxii)
ABAP based SAP ERP system. J2EE applications that are developed and
deployed on IBM WebSphere Application Server can use the JCo API to receive
an Intermediate Document (IDoc) from an ABAP-based SAP ERP system.
Within the SAP ALE distribution model, the external J2EE application is handled
as a standard message receiver, and the send IDoc is processed as though it is
defined in the ALE distribution model (Figure 4-33).
The SAP Java Connector enables Java developers to communicate with ABAP
based back-end systems seamlessly by using a familiar Java based API. The
connectivity to the target SAP ERP system is performed by using the SAP RFC
protocol.
J2EE Application
Receive
IDOC
TCP / RFC
SAP Gateway
WAS
System B
SAP Java
Connector (JCO)
System A
SAP ERP
ALE Distribution
Model
Send
IDOC
In this scenario the SAP ERP systems acts as the IDOC sender while IBM
WebSphere Application Server is the IDoc receiver.
111

Service Bus invoking SAP ERP using JCA Adapter (xxxiii)
This scenario describes how to use the WebSphere Adapter for SAP to build a
communication channel between IBM WebSphere Process Server and
WebSphere Enterprise Service Bus and any ABAP-based SAP ERP system.
The WebSphere Adapter for SAP complies to the JCA 1.5 standard and can be
used to develop the respective Service Component Architecture components
within the WebSphere Integration Developer. It enables the integration developer
to place an Import node with an EIS binding which is calling a dedicated BAPI or
remote enabled function module in the target SAP ERP back-end system. The
WebSphere Adapter for SAP uses the SAP Java Connector underneath to
establish the connection to the SAP ERP back-end system (Figure 4-34).
WPS/WESB
SCA Module
EIS Import
System B
JCA Adapter
System A
SAP ERP
TCP / RFC
BAPI/RFM
Service Bus acts as a service consumer while the SAP ERP systems is the
service provider.
You can find a further description of this scenario in 4.3.13, WebSphere
Enterprise Service Bus executing a single BAPI using WebSphere Adapter for
SAP (11A) on page 136. Also read 4.3.14, WebSphere Enterprise Service Bus
executing a multiple BAPIs using WebSphere Adapter for SAP (11B) on
page 136 through 4.3.16, WebSphere Enterprise Service Bus executing the
RFC_READ_TABLE BAPI using WebSphere Adapter for SAP (11D) on
page 138 for more complex integration options.
112

Service Bus invoking SAP ERP using JCA Adapter and ALE
(xxxiv)
WebSphere Enterprise Service Bus and any ABAP based SAP ERP system. The
WebSphere Adapter for SAP complies to the JCA 1.5 standard and can be used
to develop the respective Service Component Architecture components within
the WebSphere Integration Developer. It enables the integration developer to
place a Import node with an EIS binding which is sending a specific Intermediate
Document (IDOC) the target SAP ERP back-end system. Within the SAP ALE
distribution model, the external application is handled as a standard message
sender, and the received IDOC is processed as though it is defined in the ALE
distribution model. The WebSphere Adapter for SAP uses the SAP Java
Connector underneath to establish the connection to the SAP ERP back-end
(Figure 4-35).
WPS/WESB
SCA Module
EIS Import
System B
JCA Adapter
System A
SAP ERP
TCP / RFC
Receive
IDOC
ALE
Distribution
Model
In this scenario the SAP ERP systems acts as the IDOC receiver while IBM
WebSphere Process Server and WebSphere Enterprise Service Bus is the IDOC
sender.
WebSphere Enterprise Service Bus sending single IDOC to SAP ERP using
WebSphere Adapter for SAP (12B) on page 139. Also read 4.3.19, WebSphere
Enterprise Service Bus sending multiple IDOCs to SAP ERP using WebSphere
Adapter for SAP(12C) on page 140 for batch transfer of IDocs.
113
4.2.35 SAP ERP invoking WebSphere Process Server/WebSphere

Enterprise Service Bus using JCA Adapter and ALE (xxxv)
WebSphere Enterprise Service Bus and any ABAP-based SAP ERP system.
The WebSphere Adapter for SAP complies to the JCA 1.5 standard and can be
used to develop the respective Service Component Architecture components
within the WebSphere Integration Developer. It enables the integration developer
to place a Export node with an EIS binding which is receiving a specific
Intermediate Document (IDOC) from the sending SAP ERP back-end system.
Within the SAP ALE distribution model the external J2EE application is handled
as a standard message receiver. The WebSphere Adapter for SAP uses the SAP
Java Connector underneath to establish the connection to the SAP ERP
back-end (Figure 4-36).
WPS/WESB
SCA Module
EIS Export
TCP / RFC
SAP Gateway
System B
JCA Adapter
System A
SAP ERP
ALE Distribution
Model
Send
IDOC
WebSphere Process Server/WebSphere Enterprise Service Bus is the IDOC
receiver.
sending single IDOC to WebSphere Enterprise Service Bus using WebSphere
Adapter for SAP (12A) on page 138.
114

Service Bus invoking SAP ERP using WebSphere Business
Integration Adapter for SAP (xxxvi)
This scenario describes how to use the WebSphere Business Integration
Adapter for SAP to build a communication channel between IBM WebSphere
Process Server and WebSphere Enterprise Service Bus and any ABAP-based
SAP ERP system. The adapter includes development tools which are able to
introspect the back-end system to create business object representations and
interaction specifications. These artifacts can be imported into the WebSphere
Integration Developer to create the respective Service Component Architecture
nodes within the integration module. In this specific scenario, an Import node
with a JMS binding is generated that calls a dedicated BAPI or remote enabled
function module in the target SAP ERP back-end system. The WebSphere
Business Integration Adapter for SAP has a JMS-based interface towards the
integration server. Therefore, a supported JMS provider, such as the default
message provider of the underlying WebSphere Application Server the Service
Integration Bus, can be used to connect the WebSphere Business Integration
Adapter for SAP to the IBM WebSphere Process Server and WebSphere
Enterprise Service Bus. The connection to the SAP ERP back-end system is
established by using the SAP Java Connector (Figure 4-37).
System A
System B
WPS/WESB
SCA Module
JMS Import
SAP ERP
BAPI/RFM
SI
Bus
JMS
WBI Adapter
for SAP
TCP / RFC
In this scenario the SAP ERP systems acts as the service provider while IBM
WebSphere Process Server and WebSphere Enterprise Service Bus is the
service consumer.
115

Integration Adapter for SAP and ALE (xxxvii)
SAP ERP system. The adapter includes development tools that are able to
introspect the back-end system to create business object representations and
interaction specifications. These artifacts can be imported into the WebSphere
Integration Developer to create the respective Service Component Architecture
nodes within the integration module. In this specific scenario an Import node with
a JMS binding is generated which is sending a dedicated Intermediate Document
(IDoc) to the target SAP ERP back-end system.
Within the SAP ALE distribution model the external application is handled as a
standard message sender and the received IDOC is processed like it is defined
in the ALE distribution model. The WebSphere Business Integration Adapter for
SAP has a JMS-based interface towards the integration server. Therefore, a
supported JMS provider, such as the default message provider of the underlying
WebSphere Application Server the Service Integration Bus, can be used to
connect the WebSphere Business Integration Adapter for SAP to the IBM
WebSphere Process Server and WebSphere Enterprise Service Bus. The
connection to the SAP ERP back-end system is established by using the SAP
Java Connector (Figure 4-38).
System A
System B
SAP ERP
WPS/WESB
SCA Module
JMS Import
Receive
IDOC
SI
Bus
JMS
WBI Adapter
for SAP
ALE
Distribution
Model
TCP / RFC
In this scenario, the SAP ERP systems acts as the IDOC sender while IBM
receiver. You can find a list of other feasible integration scenarios in Table 4-3 on
page 78.
116

Integration Adapter for SAP and the ABAP Extension Module
(xxxviii)
Process Server/WebSphere Enterprise Service Bus and any ABAP based SAP
ERP system. The ABAP Extension Module is a set of ABAP transports which can
be installed into the target SAP ERP system. These transports enrich the level of
integration significantly by delivering outbound capabilities like Dynamic
Transactions, Dynamic Retrieve and Enhanced IDOC handling. The adapter
includes development tools that can introspect the back-end system to create
business object representations and interaction specifications. These artifacts
can be imported into the WebSphere Integration Developer to create the
respective Service Component Architecture nodes within the integration module.
In this specific scenario an Import node with a JMS binding is generated which is
triggering the regarding function within the ABAP Extension Module in the target
SAP ERP back-end system.
The WebSphere Business Integration Adapter for SAP has a JMS-based
interface towards the integration server. Therefore, a supported JMS provider,
such as the default message provider of the underlying WebSphere Application
Server the Service Integration Bus, can be used to connect the WebSphere
Business Integration Adapter for SAP to the IBM WebSphere Process Server
and WebSphere Enterprise Service Bus. The connection to the SAP ERP
back-end is established using the SAP Java Connector (Figure 4-39).
System B
System A
SAP ERP
WPS/WESB
SCA Module
JMS Import
ABAP
ABAP
Handlers
ABAP
Handlers
Handlers
SI
Bus
JMS
WBI Adapter
for SAP
ABAP
Extension
Module
TCP / RFC
Dynamic Transactions
Dynamic Retrieve
Enhanced IDOC handling
In this scenario the SAP ERP systems acts as the service provider while IBM
WebSphere Process Server/WebSphere Enterprise Service Bus is the service
117
consumer. You can find a list of other feasible integration scenarios in Table 4-3
on page 78.
4.2.39 SAP ERP invoking WebSphere Process Server and

WebSphere Enterprise Service Bus using WebSphere
Business Integration Adapter for SAP (xxxix)
SAP ERP system. The adapter includes development tools that can introspect
the back-end system to create business object representations and interaction
specifications. These artifacts can be imported into the WebSphere Integration
Developer to create the respective Service Component Architecture nodes within
the integration module. The WebSphere Business Integration Adapter for SAP
registers a RFC Server at the SAP gateway of a dedicated SAP ERP system.
Using this RFC Server capability ABAP based applications can call through the
SAP Gateway a remote destination in a transparent manner and execute
business logic which is implemented in Java rather than ABAP. In this specific
scenario, an Export node with a JMS binding is generated in the Service
Component Architecture module, which can receive the RFC Server call from the
connected SAP ERP back-end system.
interface towards the integration server. Therefore, a supported JMS provider
Server the Service Integration Bus can be used to connect the WebSphere
Business Integration Adapter for SAP to the IBM WebSphere Process Server
and WebSphere Enterprise Service Bus. The connection to the SAP ERP
back-end is established using the SAP Java Connector.
System A
System B
SCA Module
JMS Export
SAP Gateway
WPS/WESB
SI
Bus
JMS
WBI Adapter
for SAP
118
SAP ERP
ABAP Application
TCP / RFC
Service Bus acts as the service provider while the SAP ERP systems is the
service consumer. You can find a list of other feasible integration scenarios in
Table 4-3 on page 78.

Business Integration Adapter for SAP and ALE (xl)
SAP ERP system. The adapter includes development tools that can introspect
the back-end system to create business object representations and interaction
specifications. These artifacts can be imported into WebSphere Integration
Developer to create the respective Service Component Architecture nodes within
the integration module.
In this specific scenario an Export node with a JMS binding is generated to
receive an Intermediate Document (IDoc) from an ABAP based SAP ERP
system. Within the SAP ALE distribution model the external J2EE application is
handled as a standard message receiver and the send IDOC is processed as
though it is defined in the ALE distribution model. The WebSphere Business
Integration Adapter for SAP has a JMS-based interface towards the integration
server. Therefore, a supported JMS provider such as the default message
provider of the underlying WebSphere Application Server the Service Integration
Bus can be used to connect the WebSphere Business Integration Adapter for
SAP to the IBM WebSphere Process Server and WebSphere Enterprise Service
Bus. The connection to the SAP ERP back-end system is established by using
the SAP Java Connector.
System A
System B
SCA Module
JMS Export
SAP Gateway
WPS/WESB
SI
Bus
JMS
WBI Adapter
for SAP
SAP ERP
ALE Distribution
Model
Send
IDOC
TCP / RFC
119
receiver.

Business Integration Adapter for SAP and the ABAP
Extension Module (xli)
SAP ERP system. The ABAP Extension Module is a set of ABAP transports that
can be installed into the target SAP ERP system. These transports enrich the
level of integration significantly by delivering inbound capabilities such as
Enhanced Event notification.
The adapter includes development tools that can introspect the back-end system
to create business object representations and interaction specifications. These
artifacts can be imported into the WebSphere Integration Developer to create the
respective Service Component Architecture nodes within the integration module.
In this specific scenario, an Export node with a JMS binding is generated that is
triggered when the WebSphere Business Integration Adapter for SAP receives a
relevant business event. Which business events are relevant can be configured
in a fine granular manner within the ABAP Extension Module. The WebSphere
Business Integration Adapter for SAP polls the target SAP ERP system
frequently for relevant business events.
120

interface towards the integration server. Therefore, a supported JMS provider
Server the Service Integration Bus can be used to connect the WebSphere
Business Integration Adapter for SAP to the IBM WebSphere Process
Server/WebSphere Enterprise Service Bus. The connection to the SAP ERP
back-end system is established by using the SAP Java Connector (Figure 4-42).
System A
System B
SAP ERP
WPS/WESB
SCA Module
JMS Export
SI
Bus
Event
Infrastructure
JMS
WBI Adapter
for SAP
ABAP
Extension
Module
TCP / RFC
Enhanced Event notification
Event polling
In this scenario, the SAP ERP systems acts as a business event producer while
the IBM WebSphere Process Server and WebSphere Enterprise Service Bus is
the business event receiver.
sending business event to WebSphere Enterprise Service Bus using WebSphere
Business Integration Adapter for SAP and SIBus (13A) on page 141. Also read
4.3.21, SAP ERP sending business event to WebSphere Enterprise Service Bus
using WebSphere Business Integration Adapter for SAP and MQ link (13B) on
page 141 for information about the usage of an external WebSphere MQ.
4.2.42 WebSphere MQ sending IDOC into SAP ERP using MQ link for
SAP R/3 (xlii)
This scenario describes the integration capabilities of the product MQ link for
SAP R/3. You can configure this component to pick up messages that arrive on a
certain WebSphere MQ message queue and to post them as an IDOC into the
SAP ERP target system. The messages that arrive in the observed queue have
to have a certain format to ensure that the transformation to the IDOC format is
successful. The connectivity to WebSphere MQ is performed using a standard
121
WebSphere MQ client connection. The connectivity to the target SAP ERP

system is performed using the SAP RFC protocol (Figure 4-43).
System A
System B
SAP ERP
WebSphere MQ
Queue Manager
Receive
IDOC
Native MQ
MQSeries link
for SAP R/3
Inbound
Server
ALE
Distribution
Model
TCP / RFC
In this scenario, IBM WebSphere MQ is the messaging backbone. The

MQSeries link for SAP R/3 component is the message transformer while the
SAP ERP system is the IDOC receiver.
WebSphere MQ invoking SAP ERP using Web Service (10B) on page 135.
122
4.2.43 SAP ERP sending IDOC to WebSphere MQ using MQ link for

SAP R/3 (xliii)
This scenario describes the integration capabilities of the product MQ link for
SAP R/3. You can configure this component to receive specific IDOCs from an
SAP ERP system and to put them on a certain WebSphere MQ message queue.
The connectivity to WebSphere MQ is performed using a standard WebSphere
MQ client connection. The connectivity to the source SAP ERP system is
performed using the SAP RFC protocol (Figure 4-44).
System A
System B
SAP Gateway
WebSphere MQ
Queue Manager
Native MQ
MQSeries link
for SAP R/3
Outbound
Server
SAP ERP
ALE Distribution
Model
Send
IDOC
TCP / RFC
In this scenario, IBM WebSphere MQ is the messaging backbone. The MQSeries

link for SAP R/3 component is the message transformer while the SAP ERP
system is the IDOC sender.
123
4.3 Implemented integration scenarios in this book

This section lists all integration scenarios that we implement within this book.
First, it includes some graphics that give an overview of the selected scenarios
that we implement in this book. Then, it gives a brief introduction of each
scenario with a short summary of the characteristics of the particular scenario
and why we selected the particular scenario. Each section also includes a
cross-reference to the chapter where you can find complete implementation
information about that scenario.
4.3.1 Scenario graphics

Figure 4-45 highlights the scenarios that integrate WebSphere Enterprise
Service Bus with particular SAP components.
WebSphere
Adapter
for
SAP
WebSphere
ESB
WebSphere
ESB
WBI
Adapter
for
SAP
IDoc
RFC
RFC
SOAP/HTTP
WebSphere
ESB
WebSphere
ESB
XML/JMS
Figure 4-45 Selected scenarios for WebSphere Enterprise Service Bus
124
SAP
ABAP
Web AS
SAP
ABAP
Web AS
SAP
ABAP
Web AS
SAP
Exchange
Infrastructure
(XI)
SAP
Exchange
Infrastructure
(XI)
Figure 4-46 highlights the outbound scenario that integrates WebSphere

Message Broker with the SAP Exchange Infrastructure.
WESB
WAS
WPS
Web Services
Consumer
SOAP
WESB
WPS
JMS Services
Consumer
JMS
WMB
SAP Exchange
Infrastructure
as
Web Services
Provider
SAP Exchange
Infrastructure
as
JMS Services
Provider
RFC
SAP ECC
RFC
SAP ECC
Figure 4-46 Outbound scenario for WebSphere Message Broker
Figure 4-47 highlights the inbound scenario that integrates WebSphere Message
Broker with the SAP Exchange Infrastructure.
RFC
SAP ECC
RFC
SAP ECC
SAP Exchange
Infrastructure
as
Web Services
Consumer
SAP Exchange
Infrastructure
as
JMS Services
Consumer
SOAP
Web Services
Provider
WESB
WAS
WPS
WESB
WPS
JMS
JMS Services
Provider
WMB
Figure 4-47 Inbound scenario for WebSphere Message Broker
125
Figure 4-48 highlights the scenarios that integrate WebSphere Application

Server with particular SAP components.
SOAP/HTTP
WebSphere
Application
Server
XML/HTTP
SAP
Exchange
Infrastructure
(XI)
SAP
ABAP
Web AS
Figure 4-48 Selected scenarios for WebSphere Application Server
Figure 4-49 highlights the scenarios that integrate WebSphere MQ with

particular SAP components.
Stand-alone
Java Client
WebSphere MQ 6.0
SAP WebAS 6.40

SOAP/HTTP request
requestqueue
SOAP/MQ
sender
SOAP/HTTP response
SOAP/MQ
listener
MQ/SAP
Bridge.java
requestqueue
Figure 4-49 Selected scenarios for WebSphere MQ
126
WebServiceenabled RFC
ALE
IDOC_INBOUND_ASYNCHRONOUS

Infrastructure using Web Service (6A)
This scenario uses SAP Exchange Infrastructure (XI) as the Service Provider
and WebSphere Enterprise Service Bus as the Service Consumer. The XI
system is configured to access an SAP back-end system through the built-in
RFC adapter and to expose this functionality as a Web Service to the external
world. To realize the Web Service provider, a built-in SOAP adapter is used which
supports the HTTP protocol as the only transport mechanism.
The WebSphere Enterprise Service Bus component is configured to execute a
mediation module that mediates requests from external client to exactly this Web
Service that is provided by SAP XI. The setup is tested using the built-in test
client of WebSphere Integration Developer.
The communication style is Web Service calls using SOAP through HTTP. This
style is the most popular access mechanism within service based scenarios
because HTTP is flexible and SOAP can be understood by any Web Service
runtime. The SOAP/HTTP mechanism is also included within the WS-I Basic
profile and, therefore, gives a good level of interoperability when calls are made
between Web Service runtimes of different vendors. While this method of
connectivity to systems is flexible, it does lack certain QoS requirements such as
assured delivery and once only delivery, caused by the underlying transport
protocol which does not provide these capabilities.
You can find the detailed description of this implementation in 6.4, Scenario A:
WebSphere Enterprise Service Bus consuming Web Service from SAP
Exchange Infrastructure on page 332.
127
4.3.3 WebSphere Application Server invoking SAP Exchange

Infrastructure using Web Service (6B)
RFC adapter and expose this functionality as a Web Service to the external
world. To realize the Web Service provider, the built-in SOAP adapter is used,
which supports the HTTP protocol as the only transport mechanism.
On the WebSphere side the Rational Application Developer (RAD) is used to
develop a standard J2EE application which consumes the Web Service from
SAP XI. In the development steps the Web Service Client generation features of
the RAD are used to generate a client from the WSDL file provided by XI. After
this, a simple JSP page is created which utilizes the generated client to invoke
the SAP-based Web Service. Finally, this application is deployed into
style is the most popular access mechanism within service based scenarios as
HTTP is pretty flexible and SOAP can be understood by any Web Service
profile and therefore gives a good level of interoperability when calls are made
between Web Service runtimes of different vendors. While this way to connect to
systems is flexible it lacks certain QoS requirements like assured delivery and
once only delivery but this is caused by the underlying transport protocol which
does not provide these capabilities.
You can find the detailed description of this implementation in 6.5, Scenario B:
WebSphere Application Server consuming Web Service from SAP Exchange
Infrastructure on page 383.
128
4.3.4 SAP Exchange Infrastructure invoking WebSphere Enterprise

Service Bus using Web Service (6C)
This scenario uses the WebSphere Enterprise Service Bus to expose a business
functionality as a Web Service. The functionality is given by a Java Component
which is included in the Mediation Module. The Java component is supposed to
do a user lookup in an imaginary system and return a list of available users to the
caller. The WebSphere Enterprise Service Bus uses the built-in service
component architecture (SCA) Export node together with the standard HTTP
transport to expose the Web Service to the external world.
The SAP Exchange Infrastructure (XI) implements the Web Service consumer
and uses the built-in SOAP adapter to execute the Web Service call on the HTTP
transport protocol. To test this scenario, the SAPGUI executes a specific BAPI.
This request is sent to the built-in RFC adapter of SAP XI and routed to the Web
Service client which invokes the Web Service on the WebSphere Enterprise
Service Bus.
profile and, therefore, gives a good level of interoperability when calls are made
between Web Service runtimes of different vendors. While this method of
connectivity is flexible, it does lack certain QoS requirements such as assured
delivery and once only delivery which are caused by the underlying transport
protocol that does not provide these capabilities.
You can find the detailed description of the implementation in 6.6, Scenario C:
SAP Exchange Infrastructure consuming Web Service from WebSphere
Enterprise Service Bus on page 404.
129

Infrastructure using JMS (7A)
RFC adapter and to expose this functionality as a service to the external world.
The connectivity to the external world is performed using the built-in JMS
Adapter which enables SAP XI to connect to a supported JMS provider and listen
there at dedicated message queues for arriving messages.
mediation module that mediates requests from external client to exactly this
Service provided by SAP XI. Therefore, WebSphere Enterprise Service Bus uses
the built-in service component architecture capabilities to create a service import
within the mediation module which supports a JMS binding. The setup is tested
using the built-in test client of WebSphere Integration Developer.
The setup in this scenario is more complex than in a SOAP through HTTP
scenario. This scenario requires a JMS provider which is supported by both
communication parties. Both parties communicate with the JMS provider through
the JMS API that is provided by the vendor specific JMS libraries. One party acts
as the message provider which is a defacto consumer service speaking in
service terms, while the other party is the message consumer which is a service
provider speaking in service terms. The exchanged messages follow the XML
annotation but are not SOAP messages. While this method of connectivity is
more complex in terms of required infrastructure, it delivers a much better QoS.
Using the capabilities of the JMS protocol and the JMS provider makes it
possible to implement scenarios that deliver QoS levels such as assured delivery,
once only delivery, or delivery in order.
You can find the detailed description of the implementation in 7.4, Scenario A:
WebSphere Enterprise Service Bus as a JMS consumer on page 518.
130
4.3.6 SAP Exchange Infrastructure invoking WebSphere Enterprise

Service Bus using JMS (7B)
This scenario uses the WebSphere Enterprise Service Bus to expose a business
functionality as a service. The functionality is given by a Java Component which
is included in the Mediation Module. The Java component is supposed to do a
user lookup in an imaginary system and return a list of available user to the
caller. The WebSphere Enterprise Service Bus uses the build in service
component architecture (SCA) Export node together with the standard JMS
transport to expose the service to the external world.
The SAP Exchange Infrastructure (XI) implements the service consumer and
uses the build in JMS adapter to put messages to a dedicated message queue
on the connected JMS provider and to received the corresponding answer on the
reply queue. To test this scenario the SAPGUI is used to execute a specific BAPI.
This request is send to the built-in RFC adapter of SAP XI and routed to the JMS
adapter kicks off the message based service invocation through the JMS
provider to the WebSphere Enterprise Service Bus.
The setup in this scenario is more complex than in a SOAP through HTTP
scenario. This scenario requires a JMS provider which is supported by both
communication parties. Both parties communicate with the JMS provider through
the JMS API which is provided by the vendor specific JMS libraries. One party
acts as the message provider which is a defacto consumer service speaking in
service terms, while the other party is the message consumer which is a service
provider speaking in service terms. The exchanged messages follow the XML
annotation but are not SOAP messages. While this way to connect systems is
more complex in terms of required infrastructure it delivers a much better Quality
of Service (QoS). Leveraging the capabilities of the JMS protocol and the JMS
provider makes it possible to implement scenarios which deliver QoS levels such
as assured delivery, once only delivery or delivery in order. This is a typical
scenario in customer environments whenever a high QoS is required. The
message queuing capabilities of the used JMS provider can also be used to build
a batch processing like integration pattern whenever am immediate reply is not
required and a asynchronous connectivity is sufficient.
You can find the detailed description of the implementation in 7.5, Scenario B:
WebSphere Enterprise Service Bus as a JMS provider on page 558.
131
4.3.7 WebSphere Message Broker invoking SAP Exchange

Infrastructure using JMS (8A)
This outbound scenario describes how WebSphere Message Broker consumes a
service which is provided by SAP Exchange Infrastructure. The exchanged
request and response messages of this service are defined by a XML schema
representation. The scenario describes in detail all necessary configuration
steps in all involved components. The transport protocol used between
WebSphere Message Broker and SAP Exchange Infrastructure is JMS.
WebSphere MQ is the common JMS provider which is supported by both the
sender and the receiver. For providing an adequate end-to-end test environment,
the example is extended by a Web Service Interface that triggers the generation
of the JMS request messages and visualizes its respective response. This
outbound scenario was chosen because it is a very likely setup found within
mixed customer environments. It illustrates in detail how to use a reliable
communication mechanism JMS to establish enterprise like connectivity between
the two brokers WebSphere Message Broker and SAP Exchange Infrastructure.
The detailed description of the implementation can be found in 8.4, Scenario A:
Configure the JMS outbound scenario in WebSphere Message Broker on
page 685.
4.3.8 SAP Exchange Infrastructure invoking WebSphere Message

Broker using JMS (8B)
This inbound scenario describes how WebSphere Message Broker acts as a
JMS Service Provider to SAP Exchange Infrastructure. The exchanged request
and response messages of this service are defined by a XML schema
representation. The scenario describes in detail all necessary configuration steps
in all involved components. The transport protocol used between WebSphere
Message Broker and SAP Exchange Infrastructure is JMS. WebSphere MQ is
the common JMS provider which is supported by both the sender and the
receiver. For testing purposes, the scenario retrieves test data from a DB2
based database. This inbound scenario was chosen because it is a very likely
setup found within mixed customer environments. It illustrates in detail how to
use a reliable communication mechanism JMS to establish enterprise like
connectivity between the two brokers WebSphere Message Broker and SAP
Configure the JMS inbound scenario in WebSphere Message Broker on
page 739.
132
4.3.9 WebSphere Enterprise Service Bus invoking SAP Web

Application Server (ABAP) using Web Service (9A)
This scenario uses ABAP portion of the SAP WebApplication Server (WebAS) as
the Service Provider and WebSphere Enterprise Service Bus as the Service
Consumer. Since the SAP WebAS release 6.20 SAP ERP systems are able to
support natively SOAP through HTTP Web Services. Therefore it is possible to
expose traditional ABAP based remote callable function modules (RFM) as Web
Service to the external world. The fact that the most parts of the SAP business
logic still resides within the ABAP technology stack makes this access
mechanism using native Web Service more and more popular.
mediation module which mediates requests from external client to exactly this
Web Service provided by SAP WebAS. The setup is tested using the built-in test
client of WebSphere Integration Developer.
The used communication style is Web Service calls using SOAP through HTTP.
This style is the most popular access mechanism within service based scenarios
as HTTP is pretty flexible and SOAP can be understood by any Web Service
does not provide these capabilities.
Web Service based access to SAP WebApplication Server on page 778.
4.3.10 WebSphere Application Server invoking SAP Web Application

Server using Web Service (9B)
the Service Provider and WebSphere Application Server as the Service
Consumer. Since the SAP WebAS release 6.20 SAP ERP systems are able to
support natively SOAP through HTTP Web Services. Therefore it is possible to
expose traditional ABAP based remote callable function modules (RFM) as Web
Service to the external world. The fact that the most parts of the SAP business
logic still resides within the ABAP technology stack makes this access
mechanism using native Web Service more and more popular.
On the WebSphere side, the Rational Application Developer (RAD) is used to
develop a standard J2EE application which calls the Web Service from SAP
133
WebAS. In the development steps the Web Service Client generation features of
the RAD are used to generate a client from the WSDL file provided by the SAP
WebAS. After this the build in Web Services Explorer is used to invoke the Web
Service provided by SAP WebAS.
The used communication style is Web Service calls using SOAP through HTTP.
This style is the most popular access mechanism within service based scenarios
as HTTP is pretty flexible and SOAP can be understood by any Web Service
does not provide these capabilities. Especially in this scenario where the enabled
RFC is creating an IDOC in the SAP ERP system, additional efforts have to be
spend to ensure that the HTTP call to the SAP back-end system does not
failthe HTTP protocol does not provide this reliability out of the box. In
productive environments such a setup is very unlikely as typical IDOC delivery
scenarios mandate the usage of more reliable transport protocols like
transactional RFC or JMS. The advantage of the scenario is that the IDOC
structure is sent unparsed - this means there is no additional time spend to
validate or transform the payload.
The detailed description of the implementation can be found in 9.4, Scenario B:
Send an IDoc using a Web Service into SAP on page 824.
4.3.11 SAP ERP invoking WebSphere Application Server using XML

over HTTP (10A)
the Service Provider and WebSphere Application Server as the Service
Consumer.
Since SAP WebAS release 6.20, SAP ERP systems support native XML through
HTTP ports. Therefore, the SAP WebAS is able to send any XML payload to a
defined HTTP endpoint. The receiving system in this scenario is a servlet which
is deployed on the WebSphere Application Server. The XML payload sent in this
scenario is a XML representation of a standard SAP IDOC. The servlet which
catches the XML payload in this scenario is sending an appropriate status
message back to the SAP ERP system to report the correct retrieval.
The used communication style is not a native Web Service call as the payload is
not a SOAP compliant XML message. This kind of communication uses only the
flexibility of the underlying HTTP protocol to deliver a XML message to a
134
receiver. While this way to connect to systems is flexible it lacks certain QoS
requirements like assured delivery and once only delivery but this is caused by
the underlying transport protocol which does not provide these capabilities. This
scenario delivers an IDOC structure through the HTTP transport, in productive
environments such a setup is very unlikely as typical IDOC delivery scenarios
mandate the usage of more reliable transport protocols like transactional RFC or
JMS. The advantage of the scenario is that the IDOC structure is sent unparsed this means there is no additional time spend to validate or transform the payload.
Sending an IDoc from SAP to WebSphere Application Server using XML/HTTP
on page 879.
4.3.12 WebSphere MQ invoking SAP ERP using Web Service (10B)

the Service Provider and WebSphere MQ as the Service Consumer. Since SAP
WebAS release 6.20, SAP ERP systems are able to support natively SOAP
through HTTP Web Services. Therefore, it is possible to expose traditional ABAP
based remote callable function modules (RFM) as Web Service to the external
world. The fact that the most parts of the SAP business logic still resides within
the ABAP technology stack makes this access mechanism using native Web
Service more and more popular.
On the WebSphere MQ side, the built-in capability to execute Java Code within
WebSphere MQ is used to implement a Web Service client. The client itself uses
the AXIS Web Services framework to invoke the Web Service provides by the
SAP WebAS system. A stand-alone Java based WebSphere MQ client is used to
test the complete scenario.
does not provide these capabilities. Especially in this scenario where the enabled
RFC is creating an IDOC in the SAP ERP system, additional efforts have to be
spent to ensure that the HTTP call to the SAP back-end system does not
failthe HTTP protocol does not provide this reliability without configuration. In
productive environments such a setup is very unlikely as typical IDOC delivery
scenarios mandate the usage of more reliable transport protocols like
transactional RFC or JMS. The advantage of the scenario is that the IDOC
135
structure is sent unparsed - this means there is no additional time spent to

validate or transform the payload.
Build a WebSphere MQ to SAP bridge on page 903.
4.3.13 WebSphere Enterprise Service Bus executing a single BAPI

using WebSphere Adapter for SAP (11A)
This scenario describes the usage of the WebSphere Adapter for SAP to connect
to the SAP WebApplication server. The scenario describes the generation of the
integration artefacts during the development time as well as the packaging and
the subsequent execution on the WebSphere Enterprise Service Bus runtime.
The WebSphere Adapter for SAP uses the SAP Java Connector API to connect
to the SAP back-end system on the RFC layer. On top of this SAP standard API,
it builds a service facade to execute the SAP proprietary functionality in a generic
service manner. In addition to the execution, the adapter supports also the
development life cycle to introspect the target SAP back-end system and to
generate the required business object representation as back-end neutral XML
Schema files.
Within this scenario a single BAPI is accessed and executed. For test purposes
the built-in Test client is used to trigger the generated service operation
manually.
WebSphere Enterprise Service Bus executes a single BAPI call on page 970.
4.3.14 WebSphere Enterprise Service Bus executing a multiple BAPIs

using WebSphere Adapter for SAP (11B)
to the SAP back-end system on the RFC layer. On top of this SAP standard API,
service manner. Beside the execution the adapter supports also the
Schema files.
136
Within this scenario multiple BAPI representations are accessed and executed.
The different BAPIs are assigned to dedicated business object operations like
Create, Update, Retrieve or Delete. This enables the developer to create a
high-level business object which encapsulates and hides the back-end system
specifics from the calling components. For test purposes, the build in Test client
is used to trigger the generated service operation manually.
WebSphere Enterprise Service Bus executes a multiple BAPI call on
page 1005.
4.3.15 WebSphere Enterprise Service Bus executing a BAPI

transaction using WebSphere Adapter for SAP (11C)
This scenario describes the use of the WebSphere Adapter for SAP to connect to
the SAP WebApplication server. The scenario describes the generation of the
to the SAP back-end system on the RFC layer. On top of this SAP standard API
it built a service facade to execute the SAP proprietary functionality in a generic
service manner. Besides the execution the adapter supports also the
Schema files.
Within this scenario multiple BAPI representations are accessed and executed in
a defined sequence. This is the counterpart to the SAP specific transactional
behavior to implement a Logical Unit of Work (LUW). Typically the first call
blocks or locks an entity within the SAP back-end system and the last call
commits the completed changes. However, there are also different actions
feasible within the back-end system, this depends on the specific implementation
within the SAP back-end system. Finally, the important part is that all calls are
recognized by the SAP back-end system as on LUW. For test purposes, the
built-in Test client is used to trigger the generated service operation manually.
WebSphere Enterprise Service Bus executes a transactional BAPI call on
page 1047.
137
4.3.16 WebSphere Enterprise Service Bus executing the

RFC_READ_TABLE BAPI using WebSphere Adapter for SAP
(11D)
it build a service facade to execute the SAP proprietary functionality in a generic
Schema files.
Within this scenario a dedicated BAPI called RFC_READ_TABLE is accessed
and executed. The reason why this is discussed in a dedicated use case is, that
within the WebSphere Business Integration Adapter for SAP a module called
Hierarchical Dynamic Retrieve (HDR) is available which is doing the same thing,
accessing SAP database tables through a remote function module. For
customers who are looking for this functionality within the WebSphere Adapter
for SAP this use case might be interesting. For test purposes the build in Test
client is used to trigger the generated service operation manually.
You can find the detailed description of the implementation in 11.7, Scenario D:
WebSphere Enterprise Service Bus uses Read Table RFC on page 1082.
4.3.17 SAP ERP sending single IDOC to WebSphere Enterprise

Service Bus using WebSphere Adapter for SAP (12A)
Schema files.
138
For ALE inbound event processing, the adapter acts as a Remote Function Call
(RFC) Server by listening for ALE events from an SAP system. The adapter
spawns listener threads to the SAP system. Whenever an event occurs in SAP,
the event is pushed to the adapter through the event listeners. An inbound event
can include multiple IDocs, with each IDoc corresponding to a single business
object. The multiple IDocs are pushed out by the SAP system to the adapter in
the form of an IDoc packet.
You can configure the adapter to update the IDoc status for the purpose of
monitoring your IDoc processing. If the adapter configuration property
ALEUpdateStatus is set to true (indicating that an audit trail is required for all
message types), then the adapter updates the IDoc status of ALE business
objects that are retrieved from the SAP system. The update is accomplished by
updating a status IDoc called ALEAUD that the adapter sends to the SAP system
as an inbound IDoc event. After the event is sent to the message endpoint, the
adapter updates the status of the IDoc in SAP to indicate a failure or success in
processing.
WebSphere Enterprise Service Bus receives SAP IDOCs on page 1190.
4.3.18 WebSphere Enterprise Service Bus sending single IDOC to

SAP ERP using WebSphere Adapter for SAP (12B)
to the SAP back-end system on the RFC layer. On top of this SAP standard AP,
Schema files.
For ALE outbound processing, the adapter acts as a Remote Function Call
(RFC) Client that pushes the IDoc through a dedicated remote callable function
module into the SAP ERP system. The adapter supports ALE outbound
processing by working with business objects that represent outbound IDocs.
Because the ALE interface is asynchronous, SAP returns a return code only and
a null object to the caller. When no exceptions are raised, the outbound
transaction is considered successful. The success of the data being incorporated
139
into the SAP application can be verified by inspecting the IDocs that have been
generated in SAP. This scenario describes the various steps which have to be
performed in order to send one single IDoc to an SAP ERP system.
WebSphere Enterprise Service Bus sends a single SAP IDOC on page 1236.
4.3.19 WebSphere Enterprise Service Bus sending multiple IDOCs to

SAP ERP using WebSphere Adapter for SAP(12C)
service manner. Besides the execution the adapter supports also the
Schema files.
For ALE outbound processing, the adapter acts as a Remote Function Call
(RFC) Client that pushes the IDoc through a dedicated remote callable function
module into the SAP ERP system. The adapter supports ALE outbound
processing by working with business objects that represent outbound IDocs.
generated in SAP. This scenario describes the various steps which have to be
performed in order to send one multiple IDocs with a single invocation to an SAP
ERP system.
WebSphere Enterprise Service Bus sends batch SAP IDocs on page 1258.
140
4.3.20 SAP ERP sending business event to WebSphere Enterprise

Service Bus using WebSphere Business Integration Adapter
for SAP and SIBus (13A)
This scenario describes how the WebSphere Business Integration Adapter for
SAP can be used within WebSphere Integration Developer and WebSphere
Enterprise Service Bus to connect to an SAP ERP system. The adapter is used
to receive business events from an SAP ERP system and trigger a specific
functionality within WebSphere Enterprise Service Bus. To which business event
the adapter is listening can be configured using the IBM Business Integration
Station which is integrated in the SAP ERP system within a separate ABAP
namespace.
The connectivity of the adapter to the integration broker, in this scenario the
WebSphere Enterprise Service Bus, is performed by using a supported JMS
provider. This scenario uses the SIBus as the JMS provider to enable the
communication between the WebSphere Enterprise Service Bus and the
WebSphere Business Integration Adapter for SAP. One prerequisite to make the
internal SIBus available to external parties like the WebSphere Business
Integration adapter for SAP is to setup the MQ Client Link. The adapter is
handled like a native MQ Client Link in this scenario.
WebSphere Business Integration Adapter Advanced Event notification - SIBus
on page 1371.
4.3.21 SAP ERP sending business event to WebSphere Enterprise

Service Bus using WebSphere Business Integration Adapter
for SAP and MQ link (13B)
This scenario describes how the WebSphere Business Integration Adapter for
SAP can be used within WebSphere Integration Developer and WebSphere
Enterprise Service Bus to connect to an SAP ERP system. The adapter is used
to receive business events from an SAP ERP system and trigger a specific
functionality within WebSphere Enterprise Service Bus. To which business event
the adapter is listening can be configured using the IBM Business Integration
Station which is integrated in the SAP ERP system within a separate ABAP
namespace.
The connectivity of the adapter to the integration broker, in this scenario the
WebSphere Enterprise Service Bus, is performed by using a supported JMS
provider. This scenario uses beside the SIBus an additional WebSphere MQ
instance. The adapter is connected to the WebSphere MQ server, the integration
141
logic running on the WebSphere Enterprise Service Bus is connected to the

internal SIBus. The communication between the external WebSphere MQ and
the internal SIBus is established using the MQ Link capabilities of the
WebSphere Enterprise Service Bus. This build in MQ Link component enables
the SIBus to talk to other external WebSphere MQ server instances in a server to
server fashion.
WebSphere Business Integration Adapter Advanced Event notification WebSphereMQ on page 1401.
142
Chapter 5.
Configuring SAP XI for the

SOAP and JMS-based
scenarios
This chapter explains the configurations of SAP Exchange Infrastructure to
support the Web Services and JMS-based scenarios introduced in 4.3,
Implemented integration scenarios in this book on page 124.
All the SAP Exchange Infrastructure related configurations are summarized
within one chapter to provide a common presentation of design and configuration
elements that are shared between the different scenarios and to offer a
comprehensive overview. Nevertheless, the chapter consists of different
self-contained sections to allow you to configure the different scenarios
independently but to run them simultaneously.
The configurations are presented at a high level of detail and should be
reproducible if the requirements of the operational model introduced in
Figure 5-4 are fulfilled. Their implementation requires administrative privileges on
SAP Exchange Infrastructure and the respective skills.
143
The chapter starts with an overview of the scenarios from an SAP Exchange
Infrastructure perspective as well as an illustration of the major configurations
steps.
First, we discuss the following introductory topics:
Scenarios overview on page 145
Overview of SAP XI configuration steps on page 147
Common preparation on page 149
After that, we introduce the system landscape followed by detailed descriptions
on how to perform the following tasks in SAP Exchange Infrastructure:
Configuring the SOAP outbound scenario in SAP Exchange Infrastructure
on page 165
Configuring the SOAP inbound scenario in SAP Exchange Infrastructure on
page 190
Configuring the JMS outbound scenarios in SAP Exchange Infrastructure on
page 210
Configuring the JMS inbound scenarios in SAP XI on page 264
Preparing the SAP Exchange Infrastructure runtime on page 323
144
5.1 Scenarios overview

In 4.3, Implemented integration scenarios in this book on page 124, we identify
various scenarios in which SAP Exchange Infrastructure is involved. From a
perspective of SAP Exchange Infrastructure, these scenarios can be divided into
outbound and inbound scenarios, as illustrated in Figure 5-1. The outbound
scenarios determine SAP Exchange Infrastructure to act as a services provider
using either SOAP or JMS as a transport to its services consumers. In contrast,
the inbound scenarios define SAP Exchange Infrastructure as a services
consumer using either SOAP or JMS as a transport to its services providers.
WESB
WAS
WPS
Web Services
Consumer
SOAP
WESB
WPS
SAP Exchange
Infrastructure
as
Web Services
Provider
RFC
SAP ECC
Outbound Scenarios
JMS Services
Consumer
JMS
WMB
RFC
SAP ECC
RFC
SAP ECC
SAP Exchange
Infrastructure
as
Web Services
Consumer
SAP Exchange
Infrastructure
as
JMS Services
Consumer
SAP Exchange
Infrastructure
as
JMS Services
Provider
SOAP
RFC
Web Services
Provider
SAP ECC
WESB
WAS
WPS
WESB
WPS
JMS
JMS Services
Provider
Inbound Scenarios
WMB
Figure 5-1 Scenario overview from an SAP Exchange Infrastructure perspective
As shown in Figure 5-1, SAP Exchange Infrastructure is configured to mediate

the access between the WebSphere systems and a downstream SAP ECC
instance for demonstration purposes. Thereby, all members of the outbound
respectively inbound scenarios share the same integration setup of the SAP
ECC instance. However, they differ with respect to whether a SOAP or
JMS-based access is deployed.
Chapter 5. Configuring SAP XI for the SOAP and JMS-based scenarios
145
For the SOAP-based scenarios, the interface between SAP Exchange

Infrastructure and its services provider or consumer is always a WSDL that
defines the service address and the structure of request and response
messages.
For the JMS-based scenarios, the interfaces between SAP Exchange
Infrastructure and its services provider or consumer are defined by the XML
schemas for the request and the response messages. WebSphere MQ queues
for the request and response messages are required as services addresses in
addition.
Because the scenarios are configured independently but should be able to run
simultaneously, different service addresses are required when different
WebSphere systems act as a JMS producer, JMS consumer or Web Services
provider. These different service addresses in turn require their own
configuration entities within SAP Exchange Infrastructure. In order to clearly
arrange the discussion, WebSphere ESB is chosen as a representative for
WebSphere Process Server as well as WebSphere Application Server, which
leads to the following grouping of the configuration scenarios:
5.5, Configuring the SOAP outbound scenario in SAP Exchange
Infrastructure on page 165 describes how to configure SAP Exchange
Infrastructure to publish a given RFC as a Web Service, which can be
consumed by a WebSphere ESB subsequently.
5.6, Configuring the SOAP inbound scenario in SAP Exchange
Infrastructure on page 190 illustrates how to configure SAP Exchange
Infrastructure to consume a given Web Service that is provided by a
WebSphere ESB.
5.7, Configuring the JMS outbound scenarios in SAP Exchange
Infrastructure on page 210 documents how to configure SAP Exchange
Infrastructure to offer a given RFC as a JMS that is either to be consumed by
WebSphere ESB or Message Broker subsequently.
5.8, Configuring the JMS inbound scenarios in SAP XI on page 264
introduces two scenarios in which SAP Exchange Infrastructure consumes a
given JMS that is provided either by WebSphere ESB or Message Broker.
Before starting with the implementation of one of the listed scenarios, ensure to
have worked through 5.3, Common preparation on page 149. For the
JMS-based scenarios, the configurations in 5.9, Preparing the SAP Exchange
Infrastructure runtime on page 323 are required.
146
5.2 Overview of SAP XI configuration steps

If two or more enterprise information systems are to be connected using SAP
Exchange Infrastructure a scenario has to be configured, as illustrated in
Figure 5-2. Such a scenario usually consists of:
Business systems which are representations of the enterprise information
systems.
Communication channels that connect the business systems to the
Integration Server.
Message interfaces that define the structure of the messages which are
transmitted across the communication channels.
Interface mappings which define how different interfaces are mapped to each
other.
Logical routing rules that define how messages are distributed between the
business systems.
Integration processes for defining additional business logic to be executed
within the Integration Server.
Sender Agreement
Receiver Determination
Interface Determination
Business System
Communication Channel
Receiver Agreement
Communication Channel
Business System
Integration
Processes
Message Interface
Interface Mapping
Message Interface
Figure 5-2 Basic elements of a scenario configured in SAP Exchange Infrastructure
147
The elements of a scenario are configured in different SAP Exchange

Infrastructure components (Figure 5-3):
Business systems, their underlying technical systems as well as their installed
products are registered within the System Landscape Directory.
Message interfaces, their mappings, imported metadata from SAP systems
and integration processes are defined within the Integration Repository.
Configuration scenarios, which consist of the involved business systems, the
communication channels, references to used message interfaces, their
respective mappings, receiver and interface determinations as well as sender
and receiver agreements are configured in the Integration Directory.
System Landscape Directory
Integration Repository
Integration Directory
Products
Interface Objects
Configuration Scenarios
Software Components
Mapping Objects
Business Systems
Technical Systems
Integration Processes
Communication Channels
Business Systems
Imported Objects
Sender Agreements
Receiver Determinations
Interface Determinations
Receiver Agreements
Figure 5-3 Artefacts to be configured in SAP Exchange Infrastructure
The following sections explain the meaning of the various artefacts in more detail
by showing how to apply them to concrete integration scenarios.
Before starting with the scenarios in detail, the registrations in the SAP System
Landscape Directory, which are common to all scenarios, are introduced.
148
5.3 Common preparation

This section documents common preparation steps which are shared by all the
scenarios described within this chapter. It starts with configuring the SAP System
Landscape. After that, the software component for all definitions in the Integration
Repository is created.
5.4 Configuring the SAP System Landscape Directory

The environment on which all SAP Exchange Infrastructure related scenarios are
configured is depicted in Figure 5-4. It consists of the following nodes:
ITSO_IBM_1 with WebSphere ESB as a major system.

ITSO_IBM_2 with WebSphere Message broker as a major system.
ITSO_SAP_2 with SAPXI as a major system.
ITSO_SAP_3 with SAP ECC as a major system.
ITSO_IBM_2
ITSO_SAP_2
WebSphere Message Broker Toolkit

V 6.0.0.1

3.0 SP 18

V 6.0.0.2
WebSphere MQ Client
V 6.0
WebSphere MQ
V 6.0
Java 2 Runtime Environment

SE 1.4.2_11
DB2 Enterprise Server Edition

V 8.1.7
Oracle Database Server

V 9.2.0.1
Microsoft Windows Server 2003 SP1
Microsoft Windows 2000 SP4
ITSO_IBM_1
ITSO_SAP_3

V 6.0.1.2
SAP ERP Central Component

5.0
WebSphere Enterprise Service

Bus V 6.0.1.0

V 8.2

V 6.0.1.0
Linux Suse 9.2 Server Edition
Microsoft Windows XP Professional SP2
Figure 5-4 Environment for the configuration of SAPXI related scenarios
149
From the perspective of SAP Exchange Infrastructure the major systems

WebSphere ESB, WebSphere Message Broker and SAP ECC act as enterprise
information systems that must be registered as business systems within the
System Landscape Directory before they can be referenced within a
configuration scenario. On entering a business system it has to be associated
with software products as well as a technical system, which have to be registered
as well.
Table 5-1 depicts the registrations that are necessary for the scenarios described
within this chapter.
Note: As mentioned in the previous section, WebSphere ESB is used as a
representative for WebSphere Process Server and WebSphere Application
Server during the course of configuring SAP Exchange Infrastructure.
Therefore these systems are not registered within the System Landscape
Directory. Nevertheless, they can be used as a replacement for WebSphere
ESB in configured scenarios, as long as they share the same service address.
In addition to the two business systems, Table 5-1 lists the software product
ITSO_SG247220. The product registration refers internally to a software
component with the same name. All interfaces, mappings and integrations
processes that are developed for the SAP Exchange Infrastructure scenarios
within this book are stored under this component name within the Integration
Repository.
Table 5-1 Registrations within System Landscape Directory
Software Products
Technical Systems
Business Systems
WebSphere Message
Broker, 6.0
WEBSPHERE MESSAGE
BROKER on ITSO_IBM_2
ITSO_ADVANCED_ESB
WebSphere ESB, 6.0
WEBSPHERE ESB on
ITSO_IBM_1
ITSO_ESB
SAP ECC, 5.0
SDC on ITSO_SAP_3
ITSO_SAP_ECC
ITSO_SG247220, 1.0
The next section starts with a detailed descriptions of the registrations within the
System Landscape Directory. Thereby, all entries in Table 5-1 must be registered
except the product SAP ECC, which is expected to be pre-configured.
150
5.4.1 Defining software products

To define the software products, follow these steps:
1. Open System Landscape Directory from the SAP Exchange Infrastructure
Tools page as shown in Figure 5-5.
Figure 5-5 SAP Exchange Infrastructure Tools page
2. Open the Software Catalog on the System Landscape Directory homepage

as shown in Figure 5-6.
Figure 5-6 System Landscape Directory home page
151
3. Select Products as Software Type and click New Product as shown in

Figure 5-7.
Figure 5-7 New Product in Software Catalog
4. Enter ibm.com as the vendor, ITSO_SG247220 as the product name, and 1.0 as
the version, as shown in Figure 5-8. Click Create.
Figure 5-8 Add the product ITSO_SG247220
5. Each product registered in the System Landscape Directory needs to have at

least one software component specified. Therefore, specify ITSO_SG247220 as
the name of a software component and 1.0 as a version of the new
component, as shown in Figure 5-9. Click Create and Cancel subsequently
which returns you to the Software Catalog (as shown in Figure 5-7).
Figure 5-9 Add a software component to ITSO_SG247220
152
6. In the Software Catalog, click New Product. Enter ibm.com as the vendor,
WebSphere Message Broker as the product name, and 6.0 as the version, as
shown in Figure 5-10. Click Create.
Figure 5-10 Add WebSphere Message Broker as a product to SLD
7. Enter WMB as the name of the software component and 6.0 as its version, as
shown in Figure 5-11. Then, click Create and Cancel subsequently.
Figure 5-11 Add software component WMB
153
8. In the Software Catalog, click New Product. Enter ibm.com as the vendor,
WebSphere ESB as the product name, and 6.0 as the version, as shown in
Figure 5-12. Click Create.
Figure 5-12 Add a product for WebSphere ESB
9. Enter WESB as the name of the software component and 6.0 as its version, as
shown in Figure 5-13. Then, click Create and Cancel subsequently.
Figure 5-13 Add a software component to WebSphere ESB
154
5.4.2 Defining the business system for WebSphere Message Broker

To define the business system for WebSphere Message Broker, follow these
steps:
1. Go to the Home page of the System Landscape Directory and click Technical
Landscape, as shown in Figure 5-6 on page 151, which opens the Technical
System Browser. Select Third-Party as the technical system type and click
New Technical System. In the next window that opens, click Next
(Figure 5-14).
Figure 5-14 New Technical System Third-Party
2. Specify WEBSPHERE MESSAGE BROKER as the System Name and ITSO_IBM_2 as

the Host Name for the new technical system, and click Next, as shown in
Figure 5-15.
Figure 5-15 Specify Details of technical system WEBSPHERE MESSAGE BROKER
155
3. Select WebSphere Message Broker from the list of available products and
click Add as shown in Figure 5-16.
Figure 5-16 Select WebSphere Message Broker from the list of available products
4. The chosen product displays in the Selected Products list (Figure 5-17). Click
Finish.
Figure 5-17 Finish creating a technical system
5. Choose the Home link and open Business Landscape from the System
Landscape Directory Home page in Figure 5-6 on page 151. In the Business
Landscape panel, click New Business System as shown in Figure 5-18.
Figure 5-18 New Business System
156
6. Enter ITSO_Advanced_ESB as the name for the new business system as shown
in Figure 5-19.
Figure 5-19 Choose ITSO_Advanced_ESB as name of new business system
7. Select Third-Party as the type of the new business system and click Next as
Figure 5-20 Select type of new business system
8. Select the technical system WEBSPHERE MESSAGE BROKER that is

associated with the new business system and click Next as shown in
Figure 5-21. Leave the following two screens unchanged. Click Next and then
Finish.
Figure 5-21 Select associated Technical System
157
5.4.3 Defining the business system for WebSphere ESB

To define the business system for WebSphere ESB, follow these steps:
1. Go to the Home page of the System Landscape Directory and click Technical
Landscape as shown in Figure 5-6 on page 151, which opens the Technical
System Browser. Click New Technical System, select Third-Party, and
click Next as shown in Figure 5-14 on page 155. Enter WEBSPHERE ESB as the
System Name and ITSO_IBM_1 as the Host Name, and click Next as shown in
Figure 5-22.
Figure 5-22 New Technical system WebSphere ESB
2. Select WebSphere ESB from the list of available products, and click Add
(Figure 5-23). Then, click Finish.
Figure 5-23 Select WebSphere ESB from list of available products
158
3. Define the business system for the WebSphere ESB instance. Again open
Business Landscape from the SLD homepage and click New Business
System on the Business Landscape panel as shown in Figure 5-6 on
page 151. Enter the Name ITSO_ESB for the new business system and click
Next as shown in Figure 5-24.
Figure 5-24 Name the new business system
4. Select Third-Party as the type of the new business system and click Next as
shown in Figure 5-20 on page 157. Select the technical system
WEBSPHERE ESB that is associated with the new business system and click
Next as shown in Figure 5-25. Leave the followings two screens unchanged.
Click Next and then Finish.
Figure 5-25 Select associated Technical System
159
5.4.4 Defining the business system for SAP ECC

To define the business system for SAP ECC, follow these steps:
1. In the Technical System Browser panel, click New Technical System. Then
select Web AS ABAP as technical system type and click Next as shown in
Figure 5-26.
Figure 5-26 New Technical system for SAP ECC
2. Complete the details of the SAP ECC instance, such as its name, installation
number, and host name on the next panel and click Next.
Note: You can get the details from your SAP system administrator if the
SAP system administrator is not doing registration within the System
Landscape Directory for you in any way.
Figure 5-27 Details of technical system for SAP ECC system SDC
160
3. In the same way, add additional information about the message server and
central application server of SAP ECC on the next panel and click Next as
Figure 5-28 Add additional information about the technical system for SDC
4. Complete your client information in the next panel and click Next as shown in
Figure 5-29.
Figure 5-29 Specify client number of the technical system for SDC
5. Finally, select SAP ECC from the list of available products and click Add (as
shown in Figure 5-30). Then, click Finish.
Figure 5-30 Add SAP ECC to the list of available products
161
6. Next define the business system for the SAP ECC back-end system. Again
open Business Landscape from the SLD homepage and click New
Business System on the Business Landscape panel as shown in
Figure 5-18 on page 156. Enter ITSO_SAP_ECC as the name of the new
business system and click Next as shown in Figure 5-31.
Figure 5-31 New business system for SAP ECC
7. Select Web AS ABAP the type of the associated technical system and click
Figure 5-32 Select Web AS ABAP as type of the associated technical system
8. Select SDC as the associated technical system and click Next as shown in
Figure 5-33.
Figure 5-33 Select SDC as he associated technical system
162
9. Leave the product selection panel unchanged and click Next. On the last
panel , leave Application System as the Business System Role, and click
Finish as shown in Figure 5-34.
Figure 5-34 End the business landscape dialog box
This finishes the configuration the System Landscape Directory part.
5.4.5 Defining the software component in the integration repository

This section introduces the software component version ITSO_SG247220, which
includes all the definitions introduced within this chapter. To define the software
component in the integration repository, follow these steps:
1. Start the Design:Integration Builder tool by opening Integration Repository
from the SAP Exchange Infrastructure tools page as shown in Figure 5-5 on
page 151. Within the opened application, click Tools Transfer from
System Landscape Directory Import Software Component Version
from the menu as shown in Figure 5-35.
Figure 5-35 Import Software Component ITSO_SG247220 from SLD
163
2. Within the Import of Software Component Versions window, select

ITSO_SG247220 and click Import (Figure 5-36).
Figure 5-36 Select the software component ITSO_SG247220
3. The software component is created within the Integration Repository and

appears within the Design:Integration Builder tool. Select Import of RFC and
IDoc interfaces from SAP Systems Permitted, as shown in Figure 5-37.
Specify the SAP ECC instance SDC as the target system for imports. In
addition, create the namespace http://ibm.com/itso/sg247220 for objects
that are to be defined during the course of this configuration.
Figure 5-37 Create Namespaces within the imported software component
164
5.5 Configuring the SOAP outbound scenario in

This section describes how to configure SAP Exchange Infrastructure to publish
a given RFC BAPI_USER_EXISTENCE_CHECK as a Web Service that can be
consumed by WebSphere ESB subsequently. The section illustrates the different
configurations steps and includes detailed descriptions of how to set up the
different components of SAP Exchange Infrastructure for this scenario.
5.5.1 Overview of the SOAP outbound scenario

The overall goal of this section is to deliver the ItsoSoapOutboundScenario within
the SAP Exchange Infrastructure Integration Directory, as illustrated in
Figure 5-38.
ItsoSoapOutboundScenario
Sender Agreement
ItsoSoapSenderChannel
ITSO_ESB
BapiUserExistenceCheck
Receiver Agreement
BapiUserExistenceCheck_IM
ItsoRfcReceiverChannel
ITSO_SAP_ECC
BAPI_USER_EXISTENCE_CHECK
Figure 5-38 Configuration scenario ItsoSoapOutboundScenario
The configuration scenario includes two business systems. ITSO_ESB

represents the WebSphere ESB instance on ITSO_IBM_1, and ITSO_SAP_ECC
represents the SAP_ECC instance on ITSO_SAP_3. ITSO_SAP_ECC hosts the
BAPI_USER_EXISTENCE_CHECK, which will be published as a Web Service in
the end.
Within this scenario, the business system ITSO_ESB is connected to the
Integration Server with a communication channel ItsoSoapSenderChannel,
which serves incoming SOAP requests. The Integration Server forwards these
requests to ITSO_SAP_ECC using the communication channel
ItsoRfcReceiverChannel, which transmits RFC calls to a downstream SAP
back-end system or any other RFC Server.
165
The communication channels are associated with message interfaces

BapiUserExistenceCheck and BAPI_USER_EXISTENCE_CHECK respectively.
Because the message interfaces are different, an interface mapping
BapiUserExistenceCheck_IM must be configured.
The two message interfaces as well as the interface mapping are specified in the
Integration Repository as shown in Figure 5-39. The BapiUserExistenceCheck
interface is hierarchical structured consisting of two message types representing
inbound and outbound processing. The message types themselves are derived
from data types as the lowest building blocks.
Message Interfaces
Interface Mappings
BapiUserExistenceCheck
Message Types
BapiUserExistenceCheck_IM
Message Mappings
BapiUserExistenceCheckQuery_MT
BapiUserExistenceCheckResponse _MT
Imported Objects
BAP_USER_EXISTENCE_CHECK
Request / Response Message Types
BapiUserExistenceCheckQuery_MM
BapiUserExistenceCheckResponse_MM
BAP_USER_EXISTENCE_CHECK.Response
Data Types
BapiUserExistenceCheckQuery_DT
BapiUserExistenceCheckResponse_DT
Figure 5-39 Definitions in the Integration Repository for the ItsoSoapOutboundScenario
Whereas the BapiUserExistenceCheck interface is built from scratch in the

Integration Repository, the BAPI_USER_EXISTENCE_CHECK interface is
imported from a directory, which is managed by the SAP ECC system and
includes all the metadata of the RFCs on that system.
Mapping definitions follow the hierarchical structure as well. The
BapiUserExistenceCheck_IM interface mapping consists of two message
mappings that map the respective input and output message interface.
166
Before you implement the definitions in the Integration Repository and the
configuration scenario in the Integration Directory, ensure that all entities in
Table 5-2 are registered in the system Landscape Directory.
Table 5-2 Registrations in System Landscape Directory for ItsSoapOutboundScenario
Software Products
Technical Systems
Business Systems
WebSphere ESB, 6.0
WebSphere ESB on
ITSO_IBM_1
ITSO_ESB
SAP ECC, 5.0
SDC on ITSO_SAP_3
ITSO_SAP_ECC
ITSO_SG247220, 1.0
5.5.2 Preparing the integration repository for the SOAP

outbound scenario
This section describes the definition of the entities shown in Figure 5-39. First,
the metadata of BAPI_USER_EXISTENCE_CHECK are imported. After that, the
respective interfaces for the sender and their respective mappings are defined.
Note: In this section, the BapiUserExistenceCheck interface that defines the
message structure sent by ITSO_ESB is defined from scratch. This is done for
the sake of flexibility and reuse in other scenarios. Technically, this interface
could have been derived directly from the imported
BAPI_USER_EXISTENCE_CHECK.
To prepare the integration repository for the SOAP outbound scenario, follow
these steps:
1. Start the Design:Integration Builder tool by opening the Integration Repository
from the SAP Exchange Infrastructure tools page as shown in Figure 5-5 on
page 151.
The folder ITSO_SG24720, which is displayed in the left pane of the tool,
includes two folders. One folder, with the name of the created namespace,
includes all the design objects that belong to the configurations that we
develop in this book. The other folder, Imported Objects, is the place to store
metadata that is imported from the specified system SDC.
167
2. Select Imported Objects RFCs Import of SAP Objects (Figure 5-40).
Figure 5-40 Import of SAP Objects
3. Within the Import from SAP System SDC dialog box, specify the logon data to
open a connection to SDC and click Continue as shown in Figure 5-41.
Figure 5-41 Logon to SAP System from where to import the metadata
4. From the list of Objects that can be imported, select

BAPI_USER_EXISTENCE_CHECK (Figure 5-42) and click Continue.
Figure 5-42 Select BAPI_USER_EXISTENCE_CHECK from the list of objects
168
5. When the message Ready for Import displays (Figure 5-43), click Finish.
Close the dialog box after a successful import.
Figure 5-43 Execute the Import
As a result, the folder RFCs include the metadata of the imported

BAPI_USER_EXISTENCE_CHECK, as shown in Figure 5-44.
Figure 5-44 Result of RFC Import
6. In the following steps, you create a data type that models the request
message of BAPI_USER_EXISTENCE_CHECK. Select the Data Types
folder within the defined namespace and select New as shown in Figure 5-45.
Figure 5-45 New Data Type
169
7. Choose BapiUserExistenceCheckQuery_DT as the name of the new data

type (Figure 5-46) and click Create.
Figure 5-46 Choose a name for the new Data Type
8. Using the input help facilities of the type definition editor, define the structure
of BapiUserExistenceCheckQuery_DT as shown in Figure 5-47.
Figure 5-47 Define the structure of BapiUserExistenceCheckQuery_DT
170
9. Create an additional data type, choose

BapiUserExistenceCheckResponse_DT as its name and define its
structure as shown in Figure 5-48.
Figure 5-48 Define the structure of BapiUserExistenceResponse_DT
10.To derive message types from the defined data types:

a. Navigate to the Message Types folder within the defined namespace, and
select New as shown in Figure 5-49.
b. Choose BapiUserExistenceCheckQuery_MT as the name of the new
message type and click Create.
Figure 5-49 Start defining a new message type
171
11.In the Edit Message Type panel (Figure 5-50), click the blue icon that includes
a question mark on the right-hand side of the panel to open the input help.
Select the BapiUserExistenceCheckQuery_DT data type. The editor
imports the respective definitions.
Figure 5-50 Definition of message type BapiUserExistenceCheckQuery_MT
12.In same way, create a new message type

BapiUserExistenceCheckResponse_MT based on the existing data type
BapiUserExistenceCheckResponse_DT (Figure 5-51).
Figure 5-51 Definition of message type BapiUserExistenceCheckResponse_MT
172
13.Derive a message interface from the defined message types. Navigate to the
Message Interfaces folder and select New from its context menu as shown in
Figure 5-52.
Figure 5-52 New Message Interface
14.On the next panel choose BapiUserExistentCheck as the interface name

(Figure 5-53) and click Create.
Figure 5-53 Select a name for the new message interface
173
15.In the Edit Message Interface dialog box (Figure 5-54), select Outbound and
Synchronous as attributes of the message interface. Choose
BapiUserExistenceCheckQuery_MT as the Output Message and
BapiUserExistenceCheckResponse_MT as Input Message using the input
help. Save the configuration.
Note: Remember that message directions within the SAP Exchange
Infrastructure are named from the perspective of the involved business
systems.
Figure 5-54 Definition of message interface BapiUserExistentCheck
16.In the left pane of the Design:Integration Builder application, navigate to the
Message Mappings folder within the defined namespace and select New from
its context menu as shown in Figure 5-55.
Figure 5-55 Create a new message mapping
174
17.Choose BapiUserExistenceCheckQuery_MM as the name of the new

mapping and click Create (Figure 5-56).
Figure 5-56 Choose a name for the new mapping
18.In the Edit Message Mapping dialog box, use the input help of the mapping
editor to select BapiUserExistenceCheckQuery_MT as the source and
BAPI_USER_EXISTENCE_CHECK as the target interface of mapping. Map
the respective USERNAME attribute of the source to the target (Figure 5-57).
Figure 5-57 Definition of message map BapiUserExistenceCheckQuery_MM
175
19.Repeat steps 16 through 18 and create a new message mapping u2 and

select the imported RFC Message
BAPI_USER_EXISTENCE_CHECK.Response as the source and the
message type BapiUserExistenceCheckResponse as the target of the
mapping. Using the graphical mapping editor, map the respective attributes of
the source to those of the target interface as shown in Figure 5-58.
Figure 5-58 Define mapping BapiUserExistenceCheckResponse_MM
20.Based on the two message mappings, define an interface mapping. Start by

navigating to the Interface Mappings folder in the left pane and select New
from its context menu as shown in Figure 5-59.
Figure 5-59 Define a new interface mapping
176
21.Enter BapiUserExistenceCheck_IM as the name of the new mapping

Figure 5-60 Choose a name of the interface mapping
22.In the Edit Interface Mapping dialog box, select BapiUserExistenceCheck

as the source and the imported interface BAPI_USER_EXISTENCE_CHECK
as the target. Click Read Interfaces to fill the source and target message
interfaces by the editor. Go to the Request tab and use the input help to select
the Mapping Program BapiUserExistenceCheck_MM, as shown in
Figure 5-61.
Figure 5-61 Define the mapping BapiUserExistenceCheck_IM
177
23.Go to the Response tab, click Read Interfaces and select

BapiUserExistenceCheckResponse_MM as the message mapping for the
response message, as shown in Figure 5-62.
Figure 5-62 Select mapping for the response messages
This step finishes the configuration of the design objects in the integration
respository. All configurations are stored temporarily in a change list. The
configurations become active on the Integration Server as soon as the
change list is activated.
24.Select the Change Lists tab in the right pane of the Design: Integration
Builder, open the Standard Change List of the software component that you
just configured, and select Activate from its context menu, as shown in
Figure 5-63.
Figure 5-63 Activate the Change List
178
5.5.3 Configuring the Integration Directory

This section documents the configuration scenario ItsoSoapOutboundScenario
as depicted in Figure 5-38 on page 165.
Note: The steps in this section first define the scenario and then add the
business systems and communication channels. Then, the steps define the
determinations and agreements. Alternatively, you can define an integration
scenario within the Integration Repository and then import it into the
Integration Directory. We take the approach documented here for the sake of
flexibility.
To configure the Integration Directory for this scenario, follow these steps:
1. Select the Integration Directory from the SAP Exchange Infrastructure tools
page as shown in Figure 5-5. As a result, the Configuration: Integration
Builder application opens after a login. Create a new configuration scenario
by selecting Open from the menu, as shown in Figure 5-64.
Figure 5-64 Create a new configuration scenario
2. Select Configuration Scenario in the left pane of the Create Object dialog
box, enter ItsoSoapOutboundScenario as the name of the new scenario
(Figure 5-65), and click Create.
Figure 5-65 Choose a name for the Configuration Scenario
179
3. Select the Scenarios tab, open the ItsoSoapOutboundScenario folder,

navigate to the Business System sub-folder, and select Assign Business
System from its context menu as shown in Figure 5-66.
Figure 5-66 Assign Business System
4. Within the window Assign Business System, click Continue twice until
3. Select Business Systems is selected in the left pane as shown in
Figure 5-67. Select ITSO_ESB from the list of business systems in the right
pane, deactivate the automatic creation of a communication channel and click
Finish.
Figure 5-67 Select ITSO_ESB as the business system to be assigned
5. Open the new folder ITSO_ESB, which is created for the assigned business
system within the configuration scenario, select Communication Channel,
and select New from its context menu as in Figure 5-68.
Figure 5-68 Create a new communication channel
180
6. Enter ItsoSoapSenderChannel as a name for the communication channel

Figure 5-69 Name the new communication channel
7. Edit the communication channel as shown in Figure 5-70. Choose SOAP as

the adapter type and select Sender. Enter BapiUserExistenceCheck as the
default interface name and enter http://ibm.com/itso/sg247220 as its
corresponding namespace. Except these entries, keep all the other defaults.
Figure 5-70 Edit communication channel ItsoSoapSenderChannel
181
8. Navigate to the Business System sub-folder and select Assign Business

System from its context menu. Within the Assign Business System window,
click continue until 3. Select Business Systems is selected in the left pane.
Choose ITSO_SAP_ECC from the list of business systems (Figure 5-71),
deselect generating communication channels automatically, and click Finish.
Figure 5-71 Assign ITSO_SAP_ECC to the configuration scenario
9. Open the new folder ITSO_SAP_ECC, which is created for the assigned
business system within the configuration scenario, select Communication
Channel and select New from its context menu as shown in Figure 5-72.
Figure 5-72 New communication channel for ITSO_SAP_ECC
182
10.Within the next window, enter ItsoRfcReceiverChannel as the channel name

and click Create. Edit the communication as shown in Figure 5-73. Select
RFC as the Adapter Type and click Receiver. For the section RFC Client
Parameter, complete the logon data to the SAP_ECC instance on host
ITSO_SAP_3.
Figure 5-73 Edit communication channel ItsoRfcReceiverChannel
11.Navigate to Receiver Determination within the ItsoSoapOutboundScenario

folder and select New from its context menu as shown in Figure 5-74.
Figure 5-74 New Receiver Determination
183
12.Within the Create Object dialog box, enter ITSO_ESB as the service entry,
BapiUserExistenceCheck as the interface and
http://ibm.com/itso/sg247220 (Figure 5-75) as its namespace and click
Create.
Figure 5-75 Specify Sender of Receiver Determination
13.In the Edit Receiver Determination window, enter ITSO_SAP_ECC as the

Configured Receiver (Figure 5-76). This configuration establishes the routing
rule that any message from ITSO_ESB of type BapiUserExistenceCheck is
routed to ITSO_SAP_ECC by the Integration Server.
Figure 5-76 Edit Receiver Determination
184
14.Within the ItsoSoapOutboundScenario configuration scenario, navigate to the

Interface Determination entry and select New from its context menu as shown
in Figure 5-77.
Figure 5-77 New Interface Determination
15.In the Create Object dialog box, specify ITSO_ESB as the sender,
BapiUserExistenceCheck as the interface together with its namespace, and
ITSO_SAP_ECC as the receiver (Figure 5-78), and click Create.
Figure 5-78 Specify sender and receiver to which Interface Determination applies
16.The Display Interface Determination dialog box opens. Within the Configured
Inbound Interfaces section of this dialog box, choose
BAPI_USER_EXISTENCE _CHECK as the inbound interface of the receiver
185
together with the mapping BapiUserExistenceCheck_IM (Figure 5-79),

which maps the outbound interface of the sender to inbound interface of the
receiver.
Figure 5-79 Edit Interface Determination

Sender Agreement entry and select New from its context menu as shown in
Figure 5-80.
Figure 5-80 New Sender Agreement
18.Select the sender and interface to which this sender agreement applies
(Figure 5-81).
Figure 5-81 Select the sender
186
19.Specify ItsoSoapSenderChannel as the communication channel of the Sender

ITSO_ESB as shown in Figure 5-82.
Figure 5-82 Edit Sender Agreement

Receiver Agreement entry and select New from its context menu as shown in
Figure 5-83.
Figure 5-83 New Receiver Agreement
21.Specify ITSO_ESB as sender and ITSO_SAP_ECC as receiver to which the

receiver agreement applies (Figure 5-84). Add the interface and namespace
of the receiver and click Create.
Figure 5-84 Sender and receiver to which Receiver Agreement applies
187
22.Within the Edit Receiver Agreement dialog box, select

ItsoRfcReceiverChannel as the communication channel of the receiver as
Figure 5-85 Edit Receiver Agreement
23.All the definitions within the Integration Directory that you have configured are
stored temporarily within a change list. Switch to the Change Lists tab within
the left pane, open the Standards Change List folder, and select Activate
from its context menu as shown in Figure 5-86. After this step, the
configurations are operational.
Figure 5-86 Activate Change List of Integration Directory
188
5.5.4 Exporting the WSDL

The communication channel that ItsoSoapSenderChannel offers to the
BapiUserExistenceCheck message interface is a Web Service. For a Web
Service client to be able to consume this service, you must export the
corresponding WSDL from the Integration Directory. Follow these steps to export
the WSDL:
1. Click Tools Define Web Service from the menu of the Configuration:
Integration Builder tool as shown in Figure 5-87.
Figure 5-87 Define Web Service
2. In the Define Web Service dialog box, click Continue. You need to specify the
Web address of the Web Service. Although it does not generate the correct
Web address, click Propose URL (Figure 5-88). Then, click Continue for the
next step.
Figure 5-88 Specify the URL of the Web Service
3. Specify BapiUserExistenceCheck as the message interface for which the tool

generates a WSDL (Figure 5-89). Click Continue.
Figure 5-89 Specify the interface as a source for WSDL generation
189
4. You need to specify the business system that is defined as the sender within
the Integration Scenario as well as the respective message interface, as
shown in Figure 5-90. Click Continue.
Figure 5-90 Specify the Sender of the Web Service
5. An overview of the generated WSDL displays. Click Save to store the WSDL.
Then, open the WSDL within your favorite editor and ensure that
soap:address refers to a location as depicted in Example 5-1. After you edit
the WSDL, 51100 is the port of the J2EE engine that hosts the adapter
framework for the SAP Exchange Infrastructure.
Example 5-1 The location of soap:address
<soap:address
location="http://ITSO_SAP_2:51100/XISOAPAdapter/MessageServlet?channel=
:ITSO_ESB:ItsoSoapSenderChannel"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" />
You can now use the WSDL to generate the Web Service Client on the ESB.
5.6 Configuring the SOAP inbound scenario in SAP

Exchange Infrastructure
This section describes how to configure SAP Exchange Infrastructure to
consume a given Web Service that is provided by WebSphere ESB. The section
starts with an overview of the different configurations steps. It then provides
details about the configurations within the different components of SAP
190
5.6.1 Overview of the SOAP inbound scenario

The configurations are delivered as the scenario ItsoSoapInboundScenario
within the SAP Exchange Infrastructure Integration Directory, as illustrated in
Figure 5-91.
ItsoSoapInboundScenario
Sender Agreement
ITSO_SAP_ECC
ItsoRfcSenderChannel
BAPI_USER_GETLIST
Receiver Agreement
ItsoSoapReceiverChannel
BapiUserGetlist_To_UserListInterface_IM
ITSO_ESB
UserListInterface_MI
Figure 5-91 Integration Scenario ItsoSoapInboundScenario
The configuration scenario includes two business systems. ITSO_ESB

represents the WebSphere ESB instance on ITSO_IBM_1, and ITSO_SAP_ECC
represents the SAP_ECC instance on ITSO_SAP_3.
Within this scenario, the business system ITSO_SAP_ECC is connected to the
Integration Server with a communication channel ItsoRfcSenderChannel, which
serves incoming RFC requests.
The Integration Server forwards these requests to ITSO_ESB using the
communication channel ItsoSoapReceiverChannel, which transmits SOAP calls
to the Web Service Provider ITSO_ESB.
The communication channels are associated with message interfaces
BAPI_USER_GETLIST describing a RFC that is called on ITSO_SAP_ECC and
UserListInterface_MI, which is a representation of the Web Service that is
provided by ITSO_ESB. Because the message interfaces are different, you must
configure an interface mapping BapiUserGetlist_To_UserListInterface_IM.
191
The two message interfaces as well as the interface mapping are specified in the
Integration Repository, as shown in Figure 5-92. The BAPI_USER_GETLIST
interface is imported from a directory that is managed by the SAP ECC instance
and includes all the metadata of the RFCs that is hosted by that system.
The UserListInterface_MI interface is derived from a WSDL
UserListInterface.wsdl that is provided by WebSphere ESB. The WSDL
references its request and response message types as external XML schema
UserListRequestBO.xsd and UserListResponseBO.xsd. The response message
type consists of a list of data types that are described by the XML schema
UserInfoBO.xsd.
The WSDL as well as its referenced XML schemas are imported as external
definitions into the Integration Repository.
The BapiUserGetlist_To_UserListInterface_IM interface mapping consists of two
message mappings that map the respective input and output message interface.
Imported Objects
Interface Mappings
BAP_USER_GETLIST
Request / Response Message Types

BAP_USER_GETLIST
BAP_USER_GETLIST.Response
BapiUserGetlist_To_UserListInterface_IM
Message Mappings
BapiUserGetlist_To_UserListRequest_MM
UserListResponse_To_BapiUserGetlist_MM
Message Interfaces
UserListInterface_MI
External Definitions
getUserListRequestMsg
getUserListResponseMsg
UserListInterface
External Definitions
UserListRequestBO
UserListResponseBO
UserInfoBO
Figure 5-92 Definitions in Integration Repository that are required by ItsoSoapInboundScenario
The configuration of ItsoSoapInboundScenario requires the same registrations

within the System Landscape Directory as ItsoSoapOutboundScenario, as listed
in Table 5-2 on page 167. Therefore, you need to ensure that you perform all the
configurations described in 5.4, Configuring the SAP System Landscape
Directory on page 149 h before you proceed.
192
5.6.2 Preparing the Integration Repository for the SOAP

inbound scenario
The following steps assume that the WSDL and the XML schemas that it
references, which are provided by WebSphere ESB, are available to the
Design:Integration Builder application. To prepare the Integration Repository
for the SOAP inbound scenario, follow these steps:
1. Open the Design:Integration Builder by selecting Integration Repository
from the SAP Exchange Infrastructure tools page (Figure 5-5 on page 151).
Open the ITSO_SG247220 folder in the left pane, navigate to External
Definition and select New from its context menu, as shown in Figure 5-93.
Figure 5-93 Create an External Definition
2. Enter UserInfoBO as the name of the new external definition (Figure 5-94) and
click Create.
Figure 5-94 Create External Definition dialog box
193
3. In the Edit External Definition dialog box, select xsd as the Category, and
click the button beside the File field, which opens a file dialog box. Browse to
the file location where the external definition files resides and select the
UserInfoBO.xsd file. The XML schema is loaded and displays in this definition
dialog box. For cross-referencing this schema within other external
definitions, input the file name into the Source field as well (Figure 5-95).
Figure 5-95 Edit External Definition for UserInfoBO
194
4. Create an external definition UserListResponseBO and import the XML

schema UserListResponseBO.xsd. For cross-referencing this schema within
other external definitions, input the file name into the Source input field as
well. After the import, click the External References tab to ensure that the
external definition UserInfoBD is referenced (Figure 5-96).
Figure 5-96 External Definition UserListResponseBO
5. Create an external definition UserListRequestBO and import the XML schema

UserListRequestBO.xsd. For cross-referencing this schema within other
external definitions, input the file name into the Source input field as well
(Figure 5-97).
Figure 5-97 External Definition UserListRequestBO
195
6. Create an external definition UserListInterface, select wsdl as the category,

and import the WSDL file, including the description of the Web Services
provided by WebSphere ESB. Go to the Messages tab after the import to
ensure that the external definition includes a request as well as a response
message (Figure 5-98). In the next step, a message interface is derived from
the external definition configured herein.
Figure 5-98 External Definition UserListInterface
196
7. Create a new message interface and name it UserListInterface_IM. Refer to

Figure 5-52 on page 173. Within the Edit Message Interface panel, select the
Inbound category and Synchronous mode. Using the input help facility of
the editor, select the external definition UserListInterface and choose
getUserListRequestMsg as the input and getUserListResponseMsg as
the output message (Figure 5-99).
Figure 5-99 Message Interface UserListInterface_MI
8. Import the metadata of BAPI_USER_GETLIST by navigating to the Imported

Objects folder of the namespace http://ibm.com/itso/sg247220 and select
Import of SAP Objects from the context menu of RFCs. Specify the logon
data to the SAP system SDC and click Continue. From the list of Objects
choose BAPI_USER_GETLIST (Figure 5-100) and click Continue.
Figure 5-100 Select BAPI_USER_GETLIST for import
9. Finally click Finish to execute the import.
197
10.Configure the mappings by following these steps:

a. Create a new message mapping by navigating to the Message Objects
folder and selecting New from the context menu of Message Mappings.
b. Enter BapiUserGetlist_To_UserListRequest_MM as the mapping name.
c. Using the input help of the editor, select the imported RFC Message
BAPI_USER_GETLIST as the source and the external message and
getUserListRequestMsg as the target of the mapping (Figure 5-101).
Figure 5-101 Message mapping BapiUserGetlist_To_UserListRequest_MM
d. Specify the mapping using either the graphical facilities of the mapping
editor as shown in Figure 5-101 or using the Text Preview facility as shown
in Figure 5-102. Thereby map includeName to true if the attribute
WITH_USERNAME equals to X.
Figure 5-102 Text preview of message mapping
198
11.Define the mappings by following these steps:

a. Create a new message mapping by navigating to the Message Objects
folder and selecting New from the context menu of Message Mappings.
b. Enter UserListResponse_To_BapiUserGetlistResponse_MM as the mapping
name.
c. Using the input help of the message mapping editor, select the external
message getUserListResponseMsg as the source and imported RFC
message BAPI_USER_GETLIST.Response as the target of the mapping.
Figure 5-103 shows the graphical mapping of the respective attributes as well
as its equivalent text preview at the bottom of the figure.
Figure 5-103 Define mapping UserListResponse_To_BapiUserGetlistResponse_MM
199
12.To create a new interface mapping, navigate to the Interface Mappings folder
within the software component ITSO_SG247220 and select New from its
context menu. Then, follow these steps:
a. Enter the name BapiUserGetlist_To_UserListInterface_IM. Within the
Edit Interface Mapping dialog box, select BAPI_USER_GETLIST as the
source and UserListInterface_MI as the target interface.
b. Click Read Interfaces to load the respective request and response
message type interfaces into the editor. Go to the Request tab and specify
the BapiUserGetlist_To_UserListRequest_MM mapping program
(Figure 5-104).
Figure 5-104 Edit interface mapping BapiUserGetlist_To_UserListInterface_IM
13.In the same dialog box, go to the Response tab and choose
UserListResponse_To_BapiUserGetlistResponse_MM as the mapping
program for response processing.
Figure 5-105 Select mapping program for response
14.Make the documented configurations of this section available by activating the

change list of the Software Component ITSO_SG247220 (refer to Figure 5-63
on page 178).
200
5.6.3 Configuring the Integration Directory

This section documents the configuration of the entities that comprise the
ItsoSoapInboundScenario as illustrated in Figure 5-91 on page 191. To configure
the Integration Directory, follow these steps:
1. Click the Integration Directory from the SAP Exchange Infrastructure tools
page. After logging in, the Configuration: Integration Builder application
opens. Create a new configuration scenario by selecting Open New from
its menu.
2. Select Configuration Scenario in the left pane and enter
ItsoSoapInboundScenario as the name of the new scenario (Figure 5-106).
Click Create.
Figure 5-106 Create scenario ItsoSoapInboundScenario
3. If you have not assigned the ITSO_ESB and ITSO_SAP_ECC business

systems within the Configuration: Integration Builder application previously,
then assign them as shown in Figure 5-67 on page 180 and Figure 5-71 on
page 182. If these business systems are assigned, then skip to the next step.
4. Go to the Objects tab in the application click Business System
ITSO_ESB Add to Scenario (Figure 5-107).
Figure 5-107 Add ITSO_ESB to Scenario
201
5. Choose ItsoSoapInboundScenario from the list of scenarios (Figure 5-108)

and click Add.
Figure 5-108 Select ItsoSoapInboundScenario as the target scenario
6. Business System ITSO_SAP_ECC Add to Scenario (Figure 5-109),

choose ItsoSoapInboundScenario from the list of scenarios (Figure 5-109),
and click Add.
Figure 5-109 Add ITSO_SAP_ECC to scenario
7. Go to ITSO_SAP_ECC within the ItsoSoapInboundScenario scenario and

select New from the context menu of Communication Channel
(Figure 5-110).
Figure 5-110 Create communication channel for ITSO_SAP_ECC
202
8. Enter ItsoRfcSenderChannel as the name of the channel and click Create.

Configure the new channel by following these steps (Figure 5-111):
a. Select RFC as the Adapter Type and click Sender.
b. The entries in the editor section RFC Server Parameter enable the
channel to register itself at the system ITSO_SAP_3 using the registration
name itsorfcsender.
c. The editor section RFC Metadata Repository Parameter includes the
logon data to the SAP system on ITSO_SAP_3.
d. Turn on the options in the editor section Adapter-Specific Message
Attributes. These options specify routing instructions during the receiver
determination.
Figure 5-111 Edit communication channel ItsoRfcSenderChannel
203
9. Go to ITSO_ESB within the ItsoSoapInboundScenario scenario and select

New from the context menu of Communication Channel. Then, follow these
steps:
a. Enter ItsoSoapReceiverChannel as the name of the channel and click
Create.
b. Within the Edit Communication Channel dialog box, select SOAP as the
adapter type, click Receiver, and specify the target Web address
(Figure 5-112). The exact Web address refers to the Web Service that is
provided by WebSphere ESB on ITSO_IBM_1:
http://ITSO_IBM_1:9081/ITSOSAPXI2ESB_WSWeb/sca/UserList_Mediation
FlowExport
Figure 5-112 Edit communication channel ItsoSoapReceiverChannel
10.Select the Receiver Determination folder within the ItsoSoapInboundScenario

and select New from its context menu (Figure 5-113).
Figure 5-113 Create receiver determination within ItsoSoapInboundScenario
204
11.Enter ITSO_SAP_ECC as the sender service and BAPI_USER_GETLIST as the

interface (Figure 5-114) and click Create.
Figure 5-114 Select sender of receiver determination
12.In the Edit Receiver Determination dialog box, specify ITSO_ESB as a

configured receiver (Figure 5-115). You can also add the condition
(RfcDestination=ITSO_XI_TO_ESB) using the Condition Editor that opens if
you use the input help of this field (as shown in Figure 5-116). This definition
establishes the routing rule that every request of type BAPI_USER_GETLIST
from system ITSO_SAP_ECC is forwarded to ITSO_ESB if the incoming SAP
Exchange Infrastructure messages fulfills the specified condition.
Figure 5-115 Edit receiver determination for sender ITSO_SAP_ECC
205
The left operand RfcDestination of the condition refers to a context object that
can be selected using the Condition Editor. The right operand
ITSO_XI_TO_ESB is given as a literal.
Figure 5-116 Using the condition editor
13.Select Interface Determination within ItsoSoapInboundScenario and select

New from its context menu (Figure 5-117).
Figure 5-117 New interface determination
206
14.Select ITSO_SAP_ECC as the sender service, BAPI_USER_GETLIST as

the interface, and ITSO_ESB as the receiver service and click Create. Within
the Edit Interface Determination dialog box, enter UserListInterface_MI as
the inbound interface of the receiver and
BapiUserGetlist_To_UserListInterface_IM as the corresponding interface
mapping. Refer to Figure 5-118.
Figure 5-118 Edit Interface Determination
15.Select the entry Sender Agreement within the ItsoSoapInboundScenario and

select New from its context menu (Figure 5-119).
Figure 5-119 New sender agreement
207
16.Enter ITSO_SAP_ECC as the sender service and BAPI_USER_GETLIST as the

interface and click Create. Within the Edit Sender Agreement dialog box,
select ItsoRfcSenderChannel as the sender communication channel
(Figure 5-120).
Figure 5-120 Edit sender agreement
17.Select Receiver Agreement in ItsoSoapInboundScenario and select New

from its context menu (Figure 5-121).
Figure 5-121 New receiver agreement
208
18.Enter ITSO_SAP_ECC as the sender service, ITSO_ESB as the receiver service,

UserListInterface_MI as the receiver interface, and click Create. In the Edit
Receiver Agreement dialog box, select ItsoSoapReceiverChannel as the
receiver communication channel (Figure 5-122).
Figure 5-122 Edit receiver agreement
19.Activate the configured artifacts within the Integration Directory by activating

its change list. (Refer to Figure 5-86 on page 188.)
To test the scenario, define a RFC destination in the SAP ECC on
ITSO_SAP_3.
20.Log on to the SAP_ECC on ITSO_SAP_3. Within the SAPGUI, open the
transaction SM59 (Figure 5-123).
Figure 5-123 Start transaction SM59
21.When the transaction opens, click Create.
209
22.Enter ITSO_XI_TO_ESB as the RFC destination and choose T as the

connection type. Save your configuration. Activate Registered Server
Program and enter itsorfcsender as the Program ID of the registered server
program. Specify ITSO_SAP_3 as the gateway host and sapgw00 as the
gateway service. Refer to Figure 5-124.
23.If you have activated the communication channel ItsoRfcSenderChannel
(refer to Figure 5-111 on page 203) previously, you can test the RFC
destination ITSO_XI_TO_ESB by selecting Test connection. Refer to
Figure 5-124.
Figure 5-124 RFC Destination ITSO_XI_TO_ESB
5.7 Configuring the JMS outbound scenarios in

This section describes the configuration steps within SAP Exchange
Infrastructure for the JMS outbound scenarios. It documents how to configure
SAP Exchange Infrastructure to offer a given RFC
BAPI_USER_EXISTENCE_CHECK as a JMS that is to consumed by either
WebSphere ESB or WebSphere Message Broker subsequently.
210
Although WebSphere ESB and Message Broker both consume the same JMS,
they have varying communication endpoints that consist of different queues
hosted by different queue managers. These different endpoints are reflected by
different communication channels within the scenarios configured in SAP
The different communication channels lead to different SAP Exchange
Infrastructure scenarios in the description that we provide here. Although the
presentation includes some redundant configuration steps, it offers the choice to
configure WebSphere ESB and Message Broker as enterprise information
systems independently.
Regardless of the fact that these two scenarios are two different SAP Exchange
Infrastructure scenarios, we present them both in one section because they
share definitions within the Integration Repository and have similar
configurations in the Integration Directory that distinguish themselves only by
using different names.
The section starts with an overview of the configurations steps. It then
documents the common preparation of the Integration Repository, followed by
information about configuration of the Integration Directory for WebSphere ESB
and WebSphere Message Broker.
211
5.7.1 Overview of the JMS outbound scenario

The configurations for WebSphere ESB as a JMS consumer are delivered as the
scenario ItsoEsbJmsOutboundScenario within the SAP Exchange Infrastructure
Integration Directory, as illustrated in Figure 5-125.The configuration scenario
includes two business systems. ITSO_ESB represents the WebSphere ESB
instance on ITSO_IBM_1, and ITSO_SAP_ECC represents the SAP_ECC
instance on ITSO_SAP_3.
ItsoEsbJmsOutboundScenario
Sender Agreement
Esb2XiJmsSenderChannel
ESB2XI_Request
Receiver Agreement
MyAsynchJmsToSynchRfcBridge
ITSO_ESB
ITSO_SAP_ECC
Esb2XiJmsReceiverChannel
XI2ESB_Response
Figure 5-125 Configuration scenario ItsoEsbJmsOutboundScenario
The business system ITSO_ESB is connected to the Integration Server with a

communication channel Esb2XiJmsSenderChannel, which reads a JMS request
from the queue ESB2XI_Request and sends it to the Integration Server. The
Integration Server forwards the request as a synchronous RFC call to the
business system ITSO_SAP_ECC. The result of the synchronous call is put into
the queue XI2ESB_Response by means of the communication channel
Esb2XiJmsReceiverChannel, which again connects ITSO_ESB to the Integration
Server.
212
The configurations for WebSphere Message Broker as a JMS consumer are

delivered as the scenario ItsoWmbJmsOutboundScenario within the SAP
Exchange Infrastructure Integration Directory, as illustrated Figure 5-126. The
configuration scenario includes two business systems. ITSO_Advanced_ESB
represents the WebSphere Message Broker instance on ITSO_IBM_2, and
ITSO_SAP_ECC represents the SAP_ECC instance on ITSO_SAP_3.
ItsoWmbJmsOutboundScenario
Sender Agreement
Wmb2XiJmsSenderChannel
WMB2XI_Request
ITSO_Advanced_ESB
Receiver Agreement
ITSO_SAP_ECC
Wmb2XiJmsReceiverChannel
XI2WMB_Response
Figure 5-126 Configuration scenario ItsoWmbJmsOutboundScenario
The business system ITSO_Advanced_ESB is connected to the Integration

Server with a communication channel Wmb2XiJmsSenderChannel which reads
a JMS request from the queue WMB2XI_Request and sends it to the Integration
Server.
The Integration Server forwards the request as a synchronous RFC call to the
business system ITSO_SAP_ECC. The result of the synchronous call is put into
the queue XI2WMB_Response by means of the communication channel
Wmb2XiJmsReceiverChannel, which again connects ITSO_Advanced_ESB to
the Integration Server.
In addition to the common routing and mapping configuration steps, both
scenarios include an integration process MyAsynchJmsToSynchRfcBridge,
which is responsible for setting the correct value of the JMS header field
JMSCorrelationID. By means of this header field, a sender of a JMS request is
able to identify the respective JMS response message. Then, it checks that the
value of the JMSCorrelationID of the response message equals to the value of
the header field JMSMessageID within the request message.
213
As shown in Figure 5-127, the integration process stores the value of the field
JMSMessageID of the request message within a process internal container
SynchRequest. In addition, it assigns this value to the field ConversationID of an
internal XI message before it forwards this message. When an internal XI
message comes in as a response to the prior request, the stored value within the
container SynchRequest is assigned to the JMSCorrelationID field of the JMS
response message.
Note: The approach is documented according to the guide How to Correlate
JMS published by SAP. You can download the document from the SAP
Developer Network at the following Web site:
http://sdn.sap.com
On this page, navigate to Exchange Infrastructure XI How-to Guides.
XI Message
...
JMS Request Message

...
ConversationID
JMSMessageID
...
...
JMS Response Message
...
ConversationID
SynchRequest
XI Message
...
JMSCorrelationID
ConversationID
...
...
Figure 5-127 Setting JMSCorrelationID within MyAsynchJmsToSynchRfcBridge
214
The message interfaces and their respective mappings, which are involved in
both scenarios, are depicted in Figure 5-128. JMS request messages, which are
sent across either Esb2XiJmsSenderChannel or Wmb2XiJmsSenderChannel,
have the interface BapiUserExistenceCheckQuery_MI. The structure of the JMS
response messages is determined by the message interface
BapiUserExistenceCheckResponse_MI. The communication channel
ItsoRfcReceiverChannel is associated with the interface
BAPI_USER_EXISTENCE_CHECK.
BapiUserExistenceCheckQuery_MI
BapiUserExistenceCheckQuery_MI_2_ABS
BapiUserExistenceCheckQuery_ABS
MyEsbAsnychJmsToSynchRfcBridge
BapiUserExistenceCheck_ABS
BapiUserExistenceCheckResponse_ABS
BapiUserExistenceCheckResponse_ABS_2_MI
BapiUserExistenceCheckResponse_MI
Message interface
Interface mapping
Figure 5-128 Message Interfaces and mappings for ItsoEsbJmsOutboundScenario
Before a message is sent to or received from an integration process it needs to

be transformed into an abstract message interface, which in terms of SAP
Exchange Infrastructure does not have an inbound or outbound direction. Thus
for all the message interfaces, which are associated with a communication
channel, an abstract counterpart has to be specified. In addition, interface
mappings must be introduced in those cases in which the structure of the
abstract message interfaces differ considerably.
215
All the message interfaces, their mappings as well as the integration process are
specified within the Integration Repository. Figure 5-129 gives an overview of the
entities and their relationships in the Integration Repository specific to both
scenarios.
BapiUserExistenceCheckQuery_MI
BapiUserExistenceCheckQuery_MI_2_ABS
BapiUserExistenceCheckQuery_MM
BapiUserExistenceCheckQuery_ABS
BapiUserExistenceCheckQuery_DT
BapiUserExistenceCheck_ABS
BAPI_USER_EXISTENCE_CHECK.Response
BapiUserExistenceCheckResponse_MI
BapiUserExistenceCheckResponse_MT
BapiUserExistenceCheckResponse_ABS_2_MI
BapiUserExistenceCheckResponse_ABS
BapiUserExistenceCheckResponse_MM
map to
refer to
BapiUserExistenceCheckResponse_DT
Interface or type
Mapping
AsynchJmsToSynchRfcBridge
Integration process
Figure 5-129 Definitions in the Integration Repository for the ItsoEsbJmsOutboundScenario
The message interfaces BapiUserExistenceCheckQuery_MI and

BapiUserExistenceCheckResponse_MI are each structured hierarchically. Both
are derived from a respective message type (ending _MT) whose definition is
based on a data type (ending _DT) as the lowest building block.
Whereas the interface mentioned previously are built from scratch in the
Integration Repository, the interface BAPI_USER_EXISTENCE_CHECK is
imported from a directory within an SAP back system, including all the metadata
of the RFCs hosted by that SAP system.
Mapping definitions follow the hierarchical structure as well. For example, the
interface mapping BapiUserExistenceCheckQuery_MI_2_ABS is built from the
message mapping BapiUserExistenceCheckQuery_MM, which maps the
respective message types.
216
Business systems must be registered within the System Landscape Directory

before they can be referenced within a configuration scenario. A registered
business system must be associated with software products as well as a
technical system, which must be registered as well.
Table 5-3 depicts the registrations that are necessary for
ItsoEsbJmsOutboundScenario.
Table 5-3 Registrations in System Landscape Directory ItsoEsbJmsOutboundScenario
Software Products
Technical Systems
Business Systems
WebSphere ESB 6.0
WEBSPHERE ESB on ITSO_IBM_1
ITSO_ESB
SAP ECC 5.0
SDC on ITSO_SAP_3
ITSO_SAP_ECC
ITSO_SG247220 1.0
Table 5-4 shows the registrations that are necessary for

ItsoWmbJmsOutboundScenario. Before you proceed with the definitions in the
Integration Repository, ensure that these entries are registered as described in
5.4, Configuring the SAP System Landscape Directory on page 149.
Table 5-4 Registrations in System Landscape Directory ItsoWmbJmsOutboundScenario.
Software Products
Technical Systems
Business Systems
WebSphere Message
Broker 6.0
WEBSPHERE MESSAGE
ITSO_ADVANCED_ESB
SAP ECC 5.0
SDC on ITSO_SAP_3
ITSO_SAP_ECC
ITSO_SG247220 1.0
5.7.2 Preparing the Integration Repository for the JMS

outbound scenario
This section describes the configuration of the entities shown in Figure 5-129 on
page 216. First, you import the metadata of the
BAPI_USER_EXISTENCE_CHECK. After that, you define the interfaces for the
sender and their mappings.
217
Note: In this section, the BapiUserExistenceCheckQuery_MI and

BapiUserExistenceCheckResponse_MI interfaces, which determine the
message structure that are sent and received by ITSO_ESB or
ITSO_Advanced_ESB, are defined from scratch for the sake of flexibility.
Technically, the interfaces could be derived from the imported
BAPI_USER_EXISTENCE_CHECK directly.
To prepare the Integration Repository for the JMS outbound scenario, follow
these steps:
1. Start the Design:Integration Builder tool by opening Integration Repository
from the SAP Exchange Infrastructure tools page (refer to Figure 5-5 on
page 151).
The software component ITSO_SG24720 includes two folders. One folder
with the name of the created namespace includes all the design objects that
belong to the configurations that we developed in this book. The other folder,
Imported Objects, is the place to store metadata that you import from the
specified system, SDC. Go to the RFCs entry and select Import of SAP
Objects from its context menu (Figure 5-130).
Figure 5-130 Import of SAP Objects
218
2. Within the Import from SAP System SDC dialog box, specify the logon data to
open a connection to SDC and click Continue (Figure 5-131).
Figure 5-131 Logon to SAP System to import the metadata
3. From the list of Objects that you can import, select

BAPI_USER_EXISTENCE_CHECK and click Continue (Figure 5-132).
When the Ready for Import message displays, click Finish. Close the dialog
box after a successful import.
Figure 5-132 Select BAPI_USER_EXISTENCE_CHECK from the list of Objects
4. As a result, the folder RFCs includes the metadata of the imported

BAPI_USER_GETLIST (Figure 5-133).
Figure 5-133 Result of RFC Import BAPI_USER_EXISTENCE_CHECK
219
5. The following steps created a data type that models the request message of
BAPI_USER_EXISTENCE_CHECK. Navigate to the Data Types folder within
the defined namespace and select New from its context menu.
6. Enter BapiUserExistenceCheckQuery_DT as the name of the new data type
Figure 5-134 Choose a name for the new Data Type
7. Using the input help facilities of the type definition editor, define the structure
of BapiUserExistenceCheckQuery_DT as shown in Figure 5-135.
Figure 5-135 Define the structure of BapiUserExistenceCheckQuery_DT
220
8. Create an additional data type, enter BapiUserExistenceCheckResponse_DT as

its name, and define its structure as shown in Figure 5-136.
Figure 5-136 Define the structure of BapiUserExistenceCheck_DT
9. Navigate to the Message Types folder within the defined namespace, and
select New from its context menu. Enter BapiUserExistenceCheckQuery_MT as
the name of the new message type and click Create.
221
10.By means of the input help, enter BapiUserExistenceCheckQuery_DT as input

to Data Types Used (refer to Figure 5-137). The editor imports the respective
definitions.
Figure 5-137 Definition of message type BapiUserExistenceCheckQuery_MT
11.Following the approach of the previous steps, create a new message type
BapiUserExistenceCheckResponse_MT based on the existing data type
BapiUserExistenceCheckResponse_DT. Refer to Figure 5-138.
Figure 5-138 Definition of message type BapiUserExistenceCheckResponse_MT
222
12.Derive a message interface from the defined message types by navigating to

the Message Interfaces folder and select New from its context menu.
13.On the next panel, enter BapiUserExistentCheckQuery_MI as the interface
name (Figure 5-139) and click Create.
Figure 5-139 Select a name for the new message interface
14.Select Outbound category and Asynchronous mode as attributes of the

message interface. Select BapiUserExistenceCheckQuery_MT as the
Output Message using the input help (Figure 5-140).
Note: Remember that message directions within the SAP Exchange
Infrastructure are named from the perspective of the involved business
systems.
Figure 5-140 Edit Message Interface BapiUserExistenceCheckQuery_MI
223
15.Browse to the Message Interfaces folder and select New from its context
menu. Then, follow these steps:
a. On the next panel, enter BapiUserExistenceCheckResponse_MI as the
name and click Create.
b. In the Edit Message Interface dialog box, select Inbound category and
Asynchronous mode as attributes of the message interface. Select
BapiUserExistenceCheckResponse_MT as the Input Message
(Figure 5-141).
Figure 5-141 Edit Message Interface BapiUserExistenceCheckResponse_MI
a. On the next panel, enter BapiUserExistenceCheck_ABS as the name and
click Create.
b. In the Edit Message Interface dialog box, select Abstract category and
Synchronous mode as attributes of the message interface. Choose the
imported RFC message BAPI_USER_EXISTENCE_CHECK as the
224
Output Message and the imported RFC message

BAPI_USER_EXISTENCE_CHECK .Response as the Input Message
(Figure 5-142).
Figure 5-142 Edit Message Interface BapiUserExistenceCheck_ABS
a. On the next panel, enter BapiUserExistenceCheckQuery_ABS as the name
and click Create.
Asynchronous mode as attributes of the message interface. Choose the
imported RFC message BAPI_USER_EXISTENCE_CHECK as Message
(Figure 5-143).
Figure 5-143 Edit Message Interface BapiUserExistenceCheckQuery_ABS
225
a. On the next panel, enter BapiUserExistenceCheckResponse_ABS as the
name and click Create.
Synchronous mode as attributes of the message interface. Choose the
imported RFC message BAPI_USER_EXISTENCE_CHECK.Response
as Message (Figure 5-144).
Figure 5-144 Edit Message Interface BapiUserExistenceCheckResponse_ABS
19.You next define the mappings between the provided types and interfaces.
Navigate to the Message Mappings folder within the defined namespace and
select New from its context menu as shown in Figure 5-145.
Figure 5-145 Create a new message mapping
226
20.Enter BapiUserExistenceCheckQuery_MM as the name of the new mapping

Figure 5-146 Choose a name for the new mapping
21.Using the input help of the mapping editor, select

BapiUserExistenceCheckQuery_MT as the source and
BAPI_USER_EXISTENCE_CHECK as the target interface of mapping. Map
the respective USERNAME attribute of the source to the target
(Figure 5-147).
Figure 5-147 Definition of message map BapiUserExistenceCheckQuery_MM
227
22.Create a new message mapping BapiUserExistenceCheckResponse_MM, and

select the BAPI_USER_EXISTENCE_CHECK.Response that was imported
RFC Message as the source and the BapiUserExistenceCheckResponse
message type as the target of the mapping. Using the graphical mapping
editor, map the respective attributes of the source to those of the target
interface as shown in Figure 5-148.
Figure 5-148 Define mapping BapiUserExistenceCheckResponse_MM
23.Based on the two message mappings define an interface mapping. Create

this interface mapping by navigating to the Interface Mappings folder and
select New from its context menu.
24.Enter BapiUserExistenceCheckQuery_MI_2_ABS as the name of the new
mapping (Figure 5-149) and click Create.
Figure 5-149 Choose a name of the interface mapping
228
25.Select BapiUserExistenceCheckQuery_MI as the source and the abstract

interface BapiUserExistenceCheckQuery_ABS as the target. Click Read
Interfaces to fill the source and target message interfaces by the editor. Use
the input help to select the Mapping Program
BapiUserExistenceCheckQuery_MM (Figure 5-150).
Figure 5-150 Define the mapping BapiUserExistenceCheckQuery_IM_2_ABS
229
26.Navigate to the Interface Mappings folder and select New from its context
a. Enter BapiUserExistenceCheckResponse_ABS_2_MI as the name of the new
mapping and click Create.
b. In the Edit Interface Mapping dialog box, select
BapiUserExistenceCheckResponse_ABS as the source and
BapiUserExistenceCheckResponse_MI as the target (Figure 5-151).
c. Click Read Interfaces to fill the source and target message interfaces by
the editor. Use the input help to select the Mapping Program
BapiUserExistenceCheckResponse_MM.
Figure 5-151 Define the mapping BapiUserExistenceCheckResponse_ABS_2_MI
27.You next define the integration process AsynchJmsToSynchRfcBridge. Select

the entry Integration Processes in the component ITSO_SG247220 and
select New from its context menu, which creates new integration process.
28.Enter AsynchJmsToSynchRfcBridge as the name of the integration process
Figure 5-152 Name the process
230
29.Within the Edit Integration Process dialog box, define a process skeleton
using the graphical definition editor as shown in Figure 5-153. The skeleton
consists of one receive step followed by two send steps.
Figure 5-153 Define the process skeleton
30.Within the Container panel, add two elements (Figure 5-154):

SynchRequest of type BapiUserExistenceCheckQuery_ABS
SynchResponse of type BapiUserExistenceCheckResponse_ABS
Figure 5-154 Define the container elements
31.Annotate the processing steps by selecting the receive step and defining its
properties as shown in Figure 5-155. Because this step represents the
receiving of a JMS message, its mode is defined as asynchronous.
Figure 5-155 ReceiveFromJMS node
231
32.Select the second process step and specify its properties as depicted in
Figure 5-156. This step defines the synchronous RFC call to
ITSO_SAP_ECC. Therefore, both a request as well as a response message
are determined.
Figure 5-156 SendToBackend Node
33.Select the third processing step that defines the sending of the JMS response
message and define its properties as shown in Figure 5-157. Assign the value
of the container SynchRequest.ConversationId to the field Conversation ID to
prepare the setting of the JMSCorrelationID as shown Figure 5-127 on
page 214. The values of the fields Receiver From and Response to Message
determine this step to be a response to the processing step specified in
Figure 5-155 on page 231.
Figure 5-157 SendResponseToJms
This step ends the configuration of the design objects in the integration
respository. All configurations are stored temporarily in a change list. The
configurations become active on the Integration Server as soon as you
activate the change list.
232
34.Go to the Change Lists tab in the right pane of the Design: Integration Builder,
open the Standard Change List of the software component that you just
configured and select Activate from its context menu (Figure 5-158).
Figure 5-158 Activate the Change List
5.7.3 Exporting the XML schema files

To provide correct request messages and to process the response messages,
WebSphere ESB requires the respective XML schema files from SAP Exchange
Infrastructure. You export these files by executing the following steps:
1. Open the Message Types folder of the component ITSO_SG247220 within
the left pane of the Design:Integration Builder tool, as shown in Figure 5-159.
Then, follow these steps:
a. Open BapiUserExistenceCheckQuery_MT in the Message Type editor.
b. Go to the XSD tab and click Export XSD to File.
c. A file dialog box opens. Specify the location where you want to store the
XML schema file.
Figure 5-159 Export XML schema files
233
2. Repeat these steps for the BapiUserExistenceCheckResponse_MT message

type.
5.7.4 Configuring ItsoEsbJmsOutboundScenario in the

This section documents the ItsoEsbJmsOutboundScenario configuration
scenario as illustrated in Figure 5-125 on page 212.
Note: The steps in this section first define the scenario and then add the
business systems and communication channels. Then, the steps define the
collaboration profiles and agreements. Alternatively, you can define an
integration scenario within the Integration Repository and then import it into
the Integration Directory. We take the approach documented here for the sake
of flexibility.
To configure the ItsoEsbJmsOutboundScenario in the Integration Directory,
follow these steps:
page (Figure 5-5 on page 151). As a result, the Configuration: Integration
Builder application opens after you log in. Create a new configuration
scenario by selecting Open New from the menu, as shown in
Figure 5-160.
box, enter ItsoEsbJmsOutboundScenario as the name of the new scenario
(Figure 5-161), and click Create.
Figure 5-161 Choose a name for the Configuration Scenario
234
3. Go to the Scenarios tab, select ItsoEsbJmsOutboundScenario

Business System, and select Assign Business System from its context
menu (Figure 5-162).
4. Within the window Assign Business System, click Continue twice until 3.
Select Business Systems is selected in the left pane, as shown in Figure 5-163.
Select ITSO_ESB from the list of business systems in the right pane,
deactivate the automatic creation of a communication channel, and click
Finish.
Figure 5-163 Select ITSO_ESB as the business system to be assigned
5. Open the new folder ITSO_ESB, which is created for the assigned business
system within the configuration scenario, select Communication Channel
and select New from its context menu (Figure 5-164).
235
6. Enter Esb2XiJmsReceiverChannel as a name for the communication channel

7. Edit the communication channel as shown in Figure 5-166. Choose JMS as

the adapter type and select Receiver. Select WebSphere MQ (MQSeries)
JMS Provider as the Transport Protocol. Enter XI2ESB_Response as the JMS
Queue and specify the attributes that describe additional connection
parameter, as shown in Table 5-5.
Table 5-5 Connection parameter to ItsoQmgr2
Server
Port
Queue Manager Name
Channel Name
ITSO_IBM_1
3414
ItsoQmgr2
all.clients
Ensure that WebSphere MQ (non-JMS) is selected for JMS-Compliant and

assign XI Conversation ID (ConversationID) to the Set JMSCorrelationID To
entry. Except for these entries, leave all the other defaults.
236
Figure 5-166 Edit communication channel Esb2XiJmsReceiverChannel
8. Create a second communication channel for ITSO_ESB, enter

Esb2XIJmsSenderChannel as the name, and edit its attributes as shown in
Figure 5-167. Choose JMS as the adapter type and select Sender. Select
WebSphere MQ (MQSeries) JMS Provider as the Transport Protocol. Enter
ESB2XI_Request as the JMS Queue and specify the attributes that describe
additional connection parameter, as shown in Table 5-5 on page 236.
assign JMSMessageID to the Set XI Conversation ID (ConversationID) To
entry. Except for these entries, keep all the other defaults.
237
Figure 5-167 Edit communication channel Esb2XiJmsSenderChannel
238
9. Navigate to the Business System folder and select Assign Business System
from its context menu. Within the window Assign Business System click
Continue until 3. Select Business Systems is selected in the left pane
(Figure 5-168). Choose ITSO_SAP_ECC from the list of business systems,
deselect generating communication channels automatically and click Finish.
10.Open the new folder ITSO_SAP_ECC that is created for the assigned
Channel, and select New from its context menu.
239
11.In the next window, specify ItsoRfcReceiverChannel as the channel name

and click Create. Edit the communication as depicted in Figure 5-169. Select
RFC as the Adapter Type and click Receiver. For the section RFC Client
Parameter, fill in the logon data to the SAP_ECC instance on host
ITSO_SAP_3.
12.Browse to the entry Integration Process within the

ItsoEsbJmsOutboundScenario and select New from its context menu
(Figure 5-170).
Figure 5-170 New integration process
240
13.Within the Install Integration Process dialog box, click Continue on the first
panel, then select the AsynchJmsToSynchRfcBridge process from the list
of Repository Processes (Figure 5-171), and click Continue.
Figure 5-171 Select from Repository Processes
14.Specify the name MyAsynchJmsToSynchRfcBridge for the integration process

to be installed (Figure 5-172) and click Finish.
Figure 5-172 Select name for integration process to be installed
15.Navigate to Receiver Determination within the ItsoEsbJmsOutboundScenario

folder and select New from its context menu (Figure 5-173).
16.Within the Create Object dialog box, enter ITSO_ESB as the Service entry,
BapiUserExistenceCheckQuery_MI as the Interface, and
http://ibm.com/itso/sg247220 as its namespace and click Create. Refer to
Figure 5-174.
241
17.In the Edit Receiver Determination window, select

MyAsynchJmsToSynchRfcBridge as the Configured Receiver. This
configuration establishes the routing rule that any message from ITSO_ESB
of type BapiUserExistenceCheckQuery_MI is routed to
MyAsynchJmsToRfcBridge by the Integration Server. Refer to Figure 5-175.
Figure 5-175 Edit Receiver Determination to MyAsynchJmsToSynchRfcBridge
18.Create an additional receiver determination within the folder

ItsoEsbJmsOutboundScenario. Enter MyAsynchJmsToSynchRfcBridge as the
Service entry, BapiUserExistenceCheck_ABS as the Interface, and
http://ibm.com/itso/sg247220 as its namespace and click Create.
242
In the Edit Receiver Determination window, select ITSO_SAP_ECC as the

Configured Receiver. Refer to Figure 5-176.
Figure 5-176 Edit receiver determination to ITSO_SAP_ECC
19.Within the configuration scenario ItsoEsbJmsOutboundScenario navigate to

the entry Interface Determination and select New from its context menu.
Refer to Figure 5-177.
243
20.In the Create Object dialog box, specify ITSO_ESB as the sender,
BapiUserExistenceCheckQuery_MI as the interface together with its
namespace, and MyAsynchJmsToSynchRfcBridge as the receiver and click
Create. Refer to Figure 5-178.
Figure 5-178 Specify Sender and Receiver to which Interface Determination applies
Inbound Interfaces section, choose BapiUserExistenceCheckQuery_ABS
as the inbound interface of the receiver together with the mapping
BapiUserExistenceCheckQuery_MI_2_ABS, which maps the outbound
interface of the sender to inbound interface of the receiver. Refer to
Figure 5-179.
Figure 5-179 Edit Interface Determination to MyAsnychJmsToSynchRfcBridge
244
22.Create an additional interface determination for the sender

MyAsynchJmsToSynchRfcBridge with interface
BapiUserExistenceCheck_ABS to the receiver ITSO_SAP_ECC. Refer to
Figure 5-180. Specify BAPI_USER_EXISTENCE_CHECK as the Inbound Interface.
Note that no additional mapping step is to be referenced because both
interfaces are derived from identical message types.
Figure 5-180 Edit interface determination to ITSO_SAP_ECC
245
23.Finally create an interface determination for sending the response of type

BapiUserExistenceCheckResponse_ABS from the process
MyAsynchJmsToSynchRfcBridge to the business system ITSO_ESB. Refer
to Figure 5-181. Specify BapiUserExistenceCheckResponse_MI as the Inbound
Interface and BapiUserExistenceCheckResponse_ABS_2_MI as the Interface
Mapping.
Figure 5-181 Edit interface determination to ITSO_ESB
24.Within the configuration scenario ItsoEsbJmsOutboundScenario navigate to

the entry Sender Agreement and select New from its context menu. Refer to
Figure 5-182.
246
25.Select the sender ITSO_ESB and the interface

BapiUserExistenceCheckQuery_MI as the interface and click Create. Within
the Edit Sender Agreement dialog box, select the channel
Esb2XiJmsSenderChannel. Refer to Figure 5-183.
26.Navigate to the entry Receiver Agreement within the folder

ItsoEsbJmsOutboundScenario and select New from its context menu. Refer
to Figure 5-184.
27.Specify MyAsynchJmsToSynchRfcBridge as sender and ITSO_SAP_ECC as

receiver to which the receiver agreement applies. Add the interface and
namespace of the receiver and click Create. Refer to Figure 5-185.
Figure 5-185 Sender and Receiver to which Receiver Agreement applies
247

ItsoRfcReceiverChannel as the communication channel of the receiver.
Figure 5-186 Edit Receiver Agreement to ITSO_SAP_ECC
29.Create an additional receiver agreement for the sender

MyAsynchJmsToSynchRfcBridge and receiver ITSO_ESB with interface
BapiUserExistenceCheckResponse_MI. Select
Esb2XiJmsReceiverChannel as the receiver communication channel. Refer
to Figure 5-187.
Figure 5-187 Edit receiver agreement to ITSO_ESB
248
30.All the definitions within the Integration Directory that have been configured
during the previous steps are temporarily stored within a change list. Switch
to the Change Lists tab within the left pane, open the Standards Change List
folder and select Activate from its context menu. Refer to Figure 5-188. After
this step, the configurations are operational.
5.7.5 Configuring ItsoWmbJmsOutboundScenario in the

This section documents the configuration scenario
ItsoWmbJmsOutboundScenario as depicted in Figure 5-126.
Note: In this section, first the scenario is defined, then the business systems
and communication channels are added. This is followed by the definition of
collaboration profiles and agreements. Alternatively an integration scenario
could have been defined within the Integration Repository and then imported
into the Integration Directory. Again the approach here is taken for the sake of
flexibility.
249
Follow these steps:

page (Figure 5-5). As a result, the Configuration: Integration Builder
application opens after you log in. Start creating a new configuration scenario
by selecting Open New from the menu. Refer to Figure 5-189.
box, enter ItsoWmbJmsOutboundScenario as the name of the new scenario and
click Create. Refer to Figure 5-190.
Figure 5-190 Choose name ItsoWmbJmsOutboundScenario
3. Select the Scenarios tab, open the ItsoWmbJmsOutboundScenario folder,

navigate to the Business System folder and select Assign Business System
from its context menu. Refer to Figure 5-191.
250
4. Within the Assign Business System window, click Continue twice until 3.
Select Business Systems is selected in the left pane. Refer to Figure 5-192.
Select ITSO_Advanced_ESB from the list of business systems in the right
Finish.
Figure 5-192 Select ITSO_Advanced_ESB as the business system to be assigned
5. Open the new folder ITSO_Advanced_ESB, which is created for the assigned
Channel and select New from its context menu. Refer to Figure 5-193.
6. Specify Wmb2XiJmsReceiverChannel as a name for the communication

channel and click Create. Refer to Figure 5-194.
251
7. Edit the communication channel as shown in Figure 5-195. Choose JMS as

the adapter type and select Receiver. Select WebSphere MQ (MQSeries)
JMS Provider as the Transport Protocol. Insert XI2WMB_Response as the JMS
Queue and specify the attributes that describe additional connection
parameter, as shown in Table 5-6.
Server
Port
Queue Manager Name
Channel Name
ITSO_IBM_2
3414
ItsoQmgr1
all.clients

assign XI Conversation ID (ConversationID) to the Set JMSCorrelationID To
entry. Except for these entries, leave all the other defaults.
Figure 5-195 Edit communication channel Wmb2XiJmsReceiverChannel
252
8. Create a second communication channel for ITSO_Advanced_ESB, specify

Wmb2XIJmsSenderChannel as the name and edit its attributes as depicted in
Figure 5-196. Choose JMS as the adapter type and select Sender. Select
WebSphere MQ (MQSeries) JMS Provider as the Transport Protocol. Insert
WMB2XI_Request as the JMS Queue and specify the attributes that describe
additional connection parameter, as shown in Table 5-6.
assign JMSMessageID to the Set XI Conversation ID (ConversationID) To
entry. Except for these entries, keep all the other defaults.
Figure 5-196 Edit communication channel Wmb2XiJmsSenderChannel
253
9. Navigate to the Business System folder and select Assign Business

System from its context menu. Within the Assign Business System window,
click Continue until 3. Select Business Systems is selected in the left pane.
Choose ITSO_SAP_ECC from the list of business systems, deselect
generating communication channels automatically and click Finish. Refer to
Figure 5-197.
10.Open the new folder ITSO_SAP_ECC, which is created for the assigned
Channel and select New from its context menu. Refer to Figure 5-198.
Figure 5-198 New communication channel for ITSO_SAP_ECC
254
11.Within the next window, choose ItsoRfcReceiverChannel as the channel

name and click Create. Edit the communication as depicted in Figure 5-199.
Select RFC as the Adapter Type and click Receiver. For the RFC Client
Parameter section, complete the logon data to the SAP_ECC instance on
host ITSO_SAP_3.
255
12.Browse to the Integration Process entry within the

ItsoWmbJmsOutboundScenario and select New from its context menu. Refer
to Figure 5-200.
Figure 5-200 New integration process
13.Within the Install Integration Process dialog box, click Continue on the first
panel, then select the AsynchJmsToSynchRfcBridge process from the list
of Repository Processes and click Continue. Refer to Figure 5-201.
Figure 5-201 Select from Repository Processes
14.Specify the name MyAsynchJmsToSynchRfcBridge for the integration process

to be installed and click Finish. Refer to Figure 5-202.
Figure 5-202 Select name for integration process to be installed
15.Navigate to Receiver Determination within the

ItsoWmbJmsOutboundScenario folder and select New from its context menu.
256
16.Within the Create Object dialog box, specify ITSO_Advanced_ESB as the

Service entry, BapiUserExistenceCheckQuery_MI as the Interface, and
http://ibm.com/itso/sg247220 as its namespace and click Create. Refer to
Figure 5-204.
17.In the Edit Receiver Determination window, select

MyAsynchJmsToSynchRfcBridge as the Configured Receiver. This
configuration establishes the routing rule that any message from
ITSO_Advanced_ESB of type BapiUserExistenceCheckQuery_MI is routed
to MyAsynchJmsToRfcBridge by the Integration Server. Refer to
Figure 5-205.
Figure 5-205 Edit Receiver Determination to MyAsynchJmsToSynchRfcBridge
257
18.Create an additional receiver determination within the folder

ItsoWmbJmsOutboundScenario. Specify MyAsynchJmsToSynchRfcBridge as
the Service entry, BapiUserExistenceCheck_ABS as the Interface, and
http://ibm.com/itso/sg247220 as its namespace and click Create.
In the Edit Receiver Determination window, select ITSO_SAP_ECC as the
Configured Receiver. Refer to Figure 5-206.
Figure 5-206 Edit receiver determination to ITSO_SAP_ECC
19.Within the configuration scenario ItsoWmbJmsOutboundScenario, navigate

to the entry Interface Determination and select New from its context menu.
258
20.In Create Object dialog box, specify ITSO_Advanced_ESB as the sender,

BapiUserExistenceCheckQuery_MI as the interface together with its
namespace, and MyAsynchJmsToSynchRfcBridge as the receiver and click
Create. Refer to Figure 5-208.
Figure 5-208 Specify Sender and Receiver for new Interface Determination
Inbound Interfaces section, choose BapiUserExistenceCheckQuery_ABS
as the inbound interface of the receiver together with the mapping
BapiUserExistenceCheckQuery_MI_2_ABS, which maps the outbound
interface of the sender to inbound interface of the receiver. Refer to
Figure 5-209.
Figure 5-209 Edit Interface Determination to MyAsnychJmsToSynchRfcBridge
259
22.Create an additional interface determination for the sender

MyAsynchJmsToSynchRfcBridge with interface
BapiUserExistenceCheck_ABS to the receiver ITSO_SAP_ECC. Refer to
Figure 5-210. Specify BAPI_USER_EXISTENCE_CHECK as the Inbound Interface.
Note that no additional mapping step is to be referenced because both
interfaces are derived from identical message types.
Figure 5-210 Edit interface determination to ITSO_SAP_ECC
260
23.Finally create an interface determination for sending the response of type

BapiUserExistenceCheckResponse_ABS from the process
MyAsynchJmsToSynchRfcBridge to the business system
ITSO_Advanced_ESB. Refer to Figure 5-211. Specify
BapiUserExistenceCheckResponse_MI as the Inbound Interface and
BapiUserExistenceCheckResponse_ABS_2_MI as the Interface Mapping.
Figure 5-211 Edit interface determination to ITSO_Advanced_ESB
24.Within the ItsoWmbJmsOutboundScenario configuration scenario, navigate

to the Sender Agreement entry and select New from its context menu. Refer
to Figure 5-212.
261
25.Select the sender ITSO_Advanced_ESB and the interface

BapiUserExistenceCheckQuery_MI as the interface and click Create.
Within the Edit Sender Agreement dialog box, select the channel
Wmb2XiJmsSenderChannel. Refer to Figure 5-213.
26.Navigate to the Receiver Agreement entry in the

ItsoWmbJmsOutboundScenario folder and select New from its context menu.
27.Specify MyAsynchJmsToSynchRfcBridge as sender and ITSO_SAP_ECC as

receiver to which the receiver agreement applies. Add the interface and
namespace of the receiver and click Create. Refer to Figure 5-215.
Figure 5-215 Sender and Receiver to which Receiver Agreement applies
262

ItsoRfcReceiverChannel as the communication channel of the receiver.
Figure 5-216 Edit Receiver Agreement to ITSO_SAP_ECC
29.Create an additional receiver agreement for the sender

MyAsynchJmsToSynchRfcBridge and receiver ITSO_dvanced_ESB with
interface BapiUserExistenceCheckResponse_MI. Select
Wmb2XiJmsReceiverChannel as the receiver communication channel.
Figure 5-217 Edit receiver agreement to ITSO_Advanced_ESB
263
30.All the definitions within the Integration Directory that have been configured
during the previous steps are temporarily stored within a change list. Switch
to the Change Lists tab within the left pane, open the Standards Change List
folder and select Activate from its context menu (Figure 5-218). After this
step, the configurations are operational.
5.8 Configuring the JMS inbound scenarios in SAP XI

This section describes how to configure SAP Exchange Infrastructure to
consume a given JMS Service, that is provided either by WebSphere ESB or
Message Broker. Even though WebSphere ESB and Message Broker both
provide JMS services with the same interface, they have nevertheless varying
communication endpoints consisting of different queues hosted by different
queue managers. These different endpoints are reflected by different
communication channels within the scenarios configured in SAP Exchange
Infrastructure.
The different communication channels lead to different SAP Exchange
Infrastructure scenarios in the description provided here. The presentation
includes some redundant configuration steps in order to provide the choice to
configure WebSphere ESB and Message Broker as enterprise information
systems independently.
Regardless of being two different SAP Exchange Infrastructure scenarios, they
are both presented in one section, because they share definitions within the
Integration Repository and have similar configurations in the Integration
Directory that only distinguish themselves by using different names.
We begin this section with an overview of the configurations steps. Then, we
provide the common preparation of the Integration Repository and a detailed
264
description of how to configure SAP Exchange Infrastructure, the Integration

Directory for integrating WebSphere ESB and WebSphere Message Broker.
5.8.1 Overview of the JMS inbound scenarios

The configurations for WebSphere ESB being a JMS provider are delivered as
ItsoEsbJmsInboundScenario within the SAP Exchange Infrastructure Integration
Directory (Figure 5-219). The configuration scenario includes two business
systems ITSO_ESB representing the WebSphere ESB instance on
ITSO_IBM_1, and ITSO_SAP_ECC representing the SAP_ECC instance on
ITSO_SAP_3. The business system ITSO_SAP_ECC is connected with
communication channel ItsoRfcSenderChannel for sending RFC calls to the
Integration Server.
The Integration Server forwards the request as an asynchronous JMS message
to the queue XI2ESB_Request using the communication channel
Xi2EsbJsmReceiverChannel. The resulting JMS response message is delivered
from the queue ESB2XI_Response to the Integration Server using the channel
Xi2EsbJmsSenderChannel.
ItsoEsbJmsInboundScenario
Sender Agreement
Receiver Agreement
ITSO_SAP_ECC
MyEsbSynchRfcToAsynchJmsBridge
Xi2EsbJmsReceiverChannel
XI2ESB_Request
ITSO_ESB
Xi2EsbJmsSenderChannel
ESB2XI_Response
Figure 5-219 Integration Scenario ItsoEsbJmsInboundScenario
265
The configurations for WebSphere Message Broker being a JMS provider are
delivered as the scenario ItsoWmbJmsInboundScenario within the SAP
Exchange Infrastructure Integration Directory, as shown in Figure 5-220. The
configuration scenario includes two business systems ITSO_Adavanced_ESB
representing the WebSphere Message Broker instance on ITSO_IBM_2, and
ITSO_SAP_ECC representing the SAP_ECC instance on ITSO_SAP_3.
The business system ITSO_SAP_ECC is connected with communication
channel ItsoRfcSenderChannel for sending RFC calls to the Integration Server.
The Integration Server forwards the request as an asynchronous JMS message
to the queue XI2WMB_Request using the communication channel
Xi2WmbJsmReceiverChannel. The resulting JMS response message is
delivered from the queue WMB2XI_Response to the Integration Server using the
channel Xi2WmbJmsSenderChannel.
ItsoWmbJmsInboundScenario
Sender Agreement
Receiver Agreement
ITSO_SAP_ECC
Xi2WmbJmsReceiverChannel
XI2WMB_Request
MyWmbSynchRfcToAsynchJmsBridge
ITSO_Advanced_ESB
Xi2WmbJmsSenderChannel
WMB2XI_Response
Figure 5-220 Integration Scenario ItsoWmbJmsInboundScenario
266
In addition to the common routing and mapping configuration steps, these

scenarios include an integration process instance
MyEsbSynchRfcToAsynchJmsBridge respectively
MyWmbSynchRfcToAsynchJmsBridge. These instances are incarnations of an
integration process definition SynchRfcToAsynchJmsBridge, which specifies how
to correlate the JMS response to its initiating JMS request message
(Figure 5-221).
Note: The approach is documented according to the guide How to Correlate
JMS published by SAP. You can download the document from the SAP
Developer Network:
http://sdn.sap.com
On this page, navigate to Exchange Infrastructure XI How-to Guides.
SynchRfcToAsynchJmsBridge
JMS Request Message
XI Message
...
XI Message
...
MessageID
ConversationID
JMSCorrelationID
...
...
...
XI Message
...
...
JMS Response Message

...
ConversationID
JMSCorrelationID
...
...
CorrId
Correlation Container
assign
check
Figure 5-221 Correlation of JMS messages as defined by SynchRfcToAsynchJmsBridge
The Integration Server routes an incoming RFC call as a SAP Exchange

Infrastructure internal message to the process SynchRfcToAsynchJmsBridge.
The process retrieves the MessageId of the internal message, stores it in a
correlation container and assigns it to the field ConversationID of the outgoing
internal message. When the internal message is transformed into a JMS
message, the value of the field ConversationID is assigned to the JMS header
field JMSCorrelationID.
The service to be called using JMS has to ensure that the value of the
JMSCorrelationID within the JMS response message is identical to the one
within its corresponding request message.
267
An incoming JMS response message is transformed into a SAP Exchange

Infrastructure internal message before it is further processed by
SynchRfcToAsynchJmsBridge. The internal message includes a field
ConversationID which is assigned the value of the field JMSCorrelationID of the
JMS response message.
The process checks that the value of ConversatioID is identical to the one stored
within the correlation container. If it is, the message is sent as a response of the
original synchronous call.
Figure 5-222 shows the message interfaces and their respective mappings,
which are involved in the two JMS inbound scenarios. The communication
channel ItsoRfcSenderChannel is associated with the message interface
BAPI_USER_GETLIST describing a RFC that is called from ITSO_SAP_ECC .
UserListRequestBO
UserListRequestBO_ABS_To_UserListRequestBO
UserListRequestBO_ABS
BAPI_USER_GETLIST
BAPI_USER_GETLIST_ABS
MyEsbSynchRfcToAsnychJmsBridge
UserListResponseBO_ABS
UserListResponseBO_To_UserListResponseBO_ABS
UserListResponseBO
Figure 5-222 Overview of message interfaces and mappings for the JMS inbound scenarios
A JMS request message, which is sent across Xi2EsbJmsReceiverChannel or

Xi2WmbJmsReceiverChannel, has the interface UserListRequestBO, while the
type of its corresponding response message is defined as UserListResponseBO.
Before a message is sent to or received from an integration process it needs to
be transformed into an abstract message interface, which in terms of SAP
Exchange Infrastructure does not have an inbound or outbound direction.
Thus, for all the message interfaces, which are associated with a communication
channel, an abstract counterpart has to be specified. In addition, interface
268
mappings must be introduced in those cases in which the structure of the

abstract message interfaces differ considerably.
All the message interfaces, their mappings as well as the integration process are
specified within the Integration Repository. Figure 5-223 gives an overview of the
entities and their relationships in the Integration Repository specific to the JMS
inbound scenarios.
UserListRequestBO
UserListRequestBO_ABS_To_UserListRequestBO
Message Type
UserListRequestBO
UserListRequestBO_ABS
BapiUserGetlist_To_UserListRequestBO_MM
http://itso.ibm.com/sg247220/UserListRequestBO
Data Type
UserListRequestBO
http://itso.ibm.com/sg247220/UserListRequestBO
BAPI_USER_GETLIST
BAPI_USER_GETLIST
Request Message Type
BAPI_USER_GETLIST_ABS
BAPI_USER_GETLIST.Response
Responset Message Type
UserListResponseBO_TO_UserListResponseBO_ABS
UserListResponseBO
UserListResponseBO
Message Type
UserListResponseBO_ABS
UserListResponseBO_To_BapiUserGetlistResponse_MM
http://itso.ibm.com/sg247220/UserListResponseBO
map to
Data Type
UserListResponseBO
refer to
Interface or type
Mapping
Data Type
UserInfoBO
http://itso.ibm.com/sg247220/UserInfoBO
SynchRfcToAsynchJmsBridge
Integration process
Figure 5-223 Definitions in the Integration Repository for the JMS inbound scenarios
The message interface BAPI_USER_GETLIST is imported from a directory,

which is managed by the SAP ECC instance and includes all the metadata of the
RFCs hosted by that SAP system. The imported interface consists of a request
and a response message type. These message are used as building blocks for
the definition of the abstract message interfaces.
The structure of the message interfaces UserListResponseBO and
UserListRequestBO are derived from XML schema files provided by WebSphere
ESB. The derivation consists of multiple steps. First, data types are defined from
269
the provided XML schema files. Because the external XML schema files are
defined in different namespaces, these namespaces have to be reflected within
the data types as well. Then a message type is derived from the data type.
Finally, the message type is used as an input for building a message interface.
The mapping definitions follow the hierarchical structure as well. For instance,
the interface mapping UserListRequestBO_ABS_To_UserListRequestBO is built
from the message mapping BapiUserGetlist_To_UserListRequestBO_MM which
maps the respective message types.
Business systems and their associated software products have to be registered
within the System Landscape Directory before they can be referenced within a
configuration scenario. Table 5-7 depicts the registrations that are necessary for
ItsoEsbJmsInboundScenario.
Table 5-7 Registrations in System Landscape Directory ItsoEsbJmsInboundScenario
Software Products
Technical Systems
Business Systems
WebSphere ESB, 6.0
WEBSPHERE ESB on
ITSO_IBM_1
ITSO_ESB
SAP ECC, 5.0
SDC on ITSO_SAP_3
ITSO_SAP_ECC
ITSO_SG247220, 1.0
Table 5-8 shows the registrations that are necessary for

ItsoWmbJmsInboundScenario. Ensure that these entries are registered as
described in 5.4, Configuring the SAP System Landscape Directory on
page 149 before you proceed with the definitions in the Integration Repository.
Table 5-8 Registrations in System Landscape Directory ItsoWmbJmsInboundScenario.
Software Products
Technical Systems
Business Systems
WebSphere Message
Broker, 6.0
WEBSPHERE MESSAGE
ITSO_ADVANCED_ESB
SAP ECC, 5.0
SDC on ITSO_SAP_3
ITSO_SAP_ECC
ITSO_SG247220, 1.0
270
5.8.2 Preparing the Integration Repository for JMS inbound scenario

Before starting with the executing the documented steps, ensure that the
external XML schema files are available to the Design:Integration Builder
application. To prepare the Integration Repository for the JMS inbound scenario,
follow these steps:
1. Open the Design:Integration Builder by selecting Integration Repository
from the SAP Exchange Infrastructure tools page. Refer to Figure 5-5.
Double-click the ITSO_SG247220 folder in the left pane. Within the dialog box
Edit Software Component add the namespaces
http://itso.ibm.com/sg247220/UserInfoBO,
http://itso.ibm.com/sg247220/UserListRequestBO and
http://itso.ibm.com/sg247220/UserListResponseBO (Figure 5-224).
Figure 5-224 Add namespaces to ITSO_SG247220
271
2. Open the folder of the namespace http://itso.ibm.com/sg247220/UserInfoBO,

select Data Types and select New from its context menu. Refer to
Figure 5-225.
Figure 5-225 Create new data type
3. Specify UserInfoBO as the name of the new data type and click Create. In the
Edit Data Type dialog box, select the XSD tab and click the button to import
the file including the XML schema UserInfoBO. Refer to Figure 5-226.
Figure 5-226 Import Data Type Definition from File for UserInfoBO
4. Go to the Type Definition tab and ensure that the result of the import looks
like that shown in Figure 5-227.
Figure 5-227 Result of import UserInfoBO
272
5. Open the folder of the namespace,

http://itso.ibm.com/sg247220/UserListResponseBO and follow these steps:
a. Select Data Types and select New from its context menu.
b. Choose UserListResponseBO as the name of the new data type and
click Create.
c. In the Edit Data Type dialog box, go to the XSD tab and click the button to
import the file UserListResponseBO.xsd that includes the XML schema
UserListResponseBO.
d. Go to the TypeDefinition tab and ensure that the result looks like that
Figure 5-228 Result of importing UserListResponseBO.xsd
6. Select the Message Types entry in folder

http://itso.ibm.com/sg247220/UserListRespondBO and select New from its
context menu. Refer to Figure 5-229.
Figure 5-229 New message type in http://itso.ibm.com/sg247220/UserListResponseBO
7. Specify UserListResponseBO as the name of the new message type and click
Create.
273
8. Within the Edit Message Type dialog box, select UserListResponseBO as

input to Data Type Used and specify http://ibm.com/itso/sg247220 as the
XML Namespace. When you select the Structure tab, ensure that the result
looks like shown in Figure 5-230.
Figure 5-230 New message type UserListResponseBO
274
9. Open the folder of the namespace,

http://itso.ibm.com/sg247220/UserListRequestBO, and follow these steps:
a. Select Data Types and select New from its context menu.
b. Choose UserListRequestBO as the name of the new data type and click
Create.
c. In the Edit Data Type dialog box, go to the XSD tab and click the button to
import the file UserListRequestBO.xsd that includes the XML schema
UserListRequestBO.
d. Go to the TypeDefinition tab and ensure that the result looks like that
Figure 5-231 EditData Type UserListRequestBO
10.Select the Message Types entry in the

http://itso.ibm.com/sg247220/UserListRequestBO folder and select New from
its context menu.
a. Specify UserListRequestBO as the name of the message type and click
Create.
275
b. Within the Edit Message Type dialog box, select the type
UserListRequestBO that you defined in the previous step into the entry of
Data Type Used. Note again that you do not have to insert the names
manually, but you can do it by means of the input help. Specify
http://ibm.com/itso/sg247220 as the XML Namespace. Refer to
Figure 5-232.
Figure 5-232 Edit Message Type UserListRequestBO
11.Having specified the basic message types, open the folder

http://ibm.com/itso/sg247220 in the left pane in order to define the message
interfaces, which are part of this scenario. Refer to Figure 5-233.
Figure 5-233 Start defining a new message interface
12.Specify UserListRequestBO as the interface name and click Create.
276
13.Select Inbound and Asynchronous and the message type

UserListrequestBO with its respective namespace as the Input Message
(Figure 5-234).
Figure 5-234 Edit message interface UserListRequestBO
14.Create message interface UserListRequestBO in folder

http://ibm.com/itso/sg247220. Within the Edit Message Interface dialog box,
select Outbound and Asynchronous. Choose UserListResponseBO with
its respective namespace as the underlying message type (Figure 5-235).
Figure 5-235 Edit message interface UserListResponseBO
277
Having defined the message interfaces that are derived from the external
XML schema files, the next steps describe the import of the
BAPI_USER_GETLIST and how to derive the abstract message types.
15.Start importing the metadata of BAPI_USER_GETLIST by navigating to the
Imported Objects folder of the namespace http://ibm.com/itso/sg247220 and
selecting Import of SAP Objects from the context menu of RFCs (refer to
Figure 5-130 on page 218). Then follow these steps:
a. Specify the logon data to the SAP system SDC and click Continue.
b. From the list of Objects, choose BAPI_USER_GETLIST and click
Continue (Figure 5-236).
c. Click Finish to execute the import.
Figure 5-236 Select BAPI_USER_GETLIST for import
16.As a result the metadata of BAPI_USER_GETLIST are added to the Imported

Objects folder. Refer to Figure 5-237. Note that the imported RFC consists of
a message type BAPI_USER_GETLIST for the request and of
BAPI_USER_GETLIST.Response for the response.
Figure 5-237 Result of import BAPI_USER_GETLIST
278
The following steps illustrate the specification of the abstract message

interfaces as required by the MyEsbSynchRfcToAsynchJmsBridge
integration process (refer to Figure 5-222 on page 268).
17.Create message interface BAPI_USER_GETLIST_ABS in folder
select Abstract and Synchronous. Choose BAPI_USER_GETLIST as the
Output Message and BAPI_USER_GETLIST.Response as the Input
Message (Figure 5-238).
Figure 5-238 Edit message interface BAPI_USER_GETLIST_ABS
18.Create message interface UserListRequestBO_ABS in folder

select Abstract and Asynchronous. Choose BAPI_USER_GETLIST as the
Message (Figure 5-239).
Figure 5-239 Edit message interface UserListRequestBO_ABS
279
19.Create message interface UserListResponseBO_ABS in folder

select Abstract and Asynchronous. Choose
BAPI_USER_GETLIST.Response as the Message (Figure 5-240).
Figure 5-240 Edit message interface UserListResponseBO_ABS
The next steps describes the mappings, an overview of which is given in

280
20.Create a new message mapping by navigating to the Message Objects folder

and select New from the context menu of Message Mappings. Refer to
21.Specify BapiUserGetlist_To_UserListRequestBO_MM as the mapping name.
Using the input help of the editor, select the imported RFC Message
BAPI_USER_GETLIST as the source and UserListRequestBO from
namespace http:/itso.ibm.com/sg247220/UserListRequestBO as the target of
the mapping (Figure 5-241).
Figure 5-241 Message mapping BapiUserGetlist_To_UserListRequestBO_MM
For the specification of the mapping use either the graphical facilities of the
mapping editor as shown in Figure 5-241 or define it using the Text Preview
facility as shown in Figure 5-242. Thereby map includeName to true if the
attribute WITH_USERNAME equals X.
Figure 5-242 Text preview of message mapping
281
22.Create a new message mapping by navigating to the Message Objects folder

and select New from the context menu of Message Mappings. Refer to
Figure 5-145 on page 226. Then, follow these steps:
a. Specify UserListResponseBO_To_BapiUserGetlistResponse_MM as the
mapping name.
b. Using the input help of the Edit Message Mapping editor, select the
external message UserListResponseBO from the namespace
http://itso.ibm.com/sg247220/UserListResponseBO as the source and
imported RFC message BAPI_USER_GETLIST.Response as the target
of the mapping.
c. Define the mapping as depicted in Figure 5-243, which shows the
graphical mapping of the respective attributes as well as its equivalent text
preview at the bottom of the figure.
Figure 5-243 Define mapping UserListResponseBO_To_BapiUserGetlistResponse_MM
282
23.To create a new interface mapping navigate to the Interface Mappings folder
within the software component ITSO_SG247220 and select New from its
context menu.
a. Specify the name UserListRequestBO_ABS_To_UserListRequestBO.
b. Within the Edit Interface Mapping dialog box, select
UserListRequestBO_ABS as the source and UserListRequestBO as
the target interface, both from namespace http://ibm.com/itso/sg247220.
c. Click Read Interfaces to load the respective request and response
message type interfaces into the editor.
d. Click the Request tab and specify the
BapiUserGetlist_To_UserListRequestBO_MM mapping program.
Figure 5-244 Edit interface mapping UserListRequestBO_ABS_To_UserListRequestBO
283
24.Create an additional interface mapping with name

UserListResponseBO_TO_UserListResponseBO_ABS.
a. Within the Edit Interface Mapping dialog box, select
UserListResponseBO as the source and UserListResponseBO_ABS as
the target interface, both from namespace http://ibm.com/itso/sg247220
(Figure 5-245).
b. Click Read Interfaces to load the respective request and response
message type interfaces into the editor.
c. Click the Request tab and specify the
UserListResponseBO_To_BapiUserGetlistResponse_MM mapping program.
Figure 5-245 Edit UserListResponseBO_TO_UserListResponseBO_ABS
As a final major configuration step define the integration process. The main task
of this process is to correlate the response with request message as depicted in
Figure 5-221 on page 267. In addition, the process has to bridge the
synchronous RFC call to the asynchronous JMS request/response calls. For this
task a communication pattern from the XI Integration Repository is used.
25.Create a new integration process. Specify SynchRfcToAsynchJmsBridge for
the process name. Refer to Figure 5-246.
Figure 5-246 Name the new integration process
284
26.Using the graphical editor create an integration skeleton consisting of two

consecutive receive/send steps. Refer to Figure 5-247.
Figure 5-247 Create the integration process skeleton
27.Within the Container pane, define an entry Request with type

UserListRequestBO_ABS and an entry Response with type
UserListResponseBO_ABS, both of category Abstract Interface. Refer to
Figure 5-248.
Figure 5-248 Define container for the integration process
28.Define the message that to be correlated to the value in the correlation

container by starting View Correlation Editor from the menu of the
integration process editor.
a. Add the entry CorrHeader into the Correlation List pane.
b. Add CorrId as a new Correlation Container.
c. Select UserListResponseBO_ABS under Involved Messages. Refer to
Figure 5-249.
Figure 5-249 Define correlation CorrHeader
285
29.Still in Figure 5-249, define the Value entry under Properties using the
express editor which opens if you double-click the field (see Figure 5-250).
Select Interface Variable with entry Interface and Context Object with
entry ConversationId. This configuration determines the correlation rule that
the value of CorrId is checked against the value of the ConversationId within
a message of type UserListResponseBO_ABS.
Figure 5-250 Define the correlation expression
Note: During the description of the different processing steps keep in mind
that the actual sender and receiver of messages with their respective
communication channels are only defined within the Integration Directory.
30.Next define the properties of the different process steps. Start by selecting the
first receive step and specify the properties as shown in Figure 5-251. The
mode Opens S/A Bridge defines this step to be the receiver of a synchronous
call that handles internally an asynchronous request/reply pattern. The entry
to Message refers to the container element defined in Figure 5-248.
Figure 5-251 Define properties of first receive step
286
31.Establish the properties of the second process step as shown in

Figure 5-252. This step sends the message that was received in the process
step before. Thereby, the MessageId of the incoming request message is
assigned to the field Conversation ID of the outgoing message. In addition,
the MessageId is assigned to the correlation container CorrId as well. See
Figure 5-221 on page 267 for an overview of the correlation procedure.
Figure 5-252 Define the properties of the second process step
32.The third process step is meant to receive the response to the request
message that was sent by the previous step. Refer to Figure 5-253. The
received message, which is put into the Response container, gets correlated
to its respective request by means of the correlation CorrHeader.
Figure 5-253 Define the properties of the third process step
287
33.The final process step as shown in Figure 5-254 closes the

synchronous/asynchronous bridge, which has been opened by the process
step shown in Figure 5-251. Thus, the message in the Response container is
sent as a response to the synchronous request that has triggered this
integration process.
Figure 5-254 Define the properties of the final process step
34.The previous configuration step completes the definitions within the

Integration Repository as shown in Figure 5-223 on page 269. Make the
documented configurations of this section available by activating the change
list of the Software Component ITSO_SG247220. Refer to Figure 5-158 on
page 233.
5.8.3 Configuring ItsoEsbJmsInboundScenario in the

The previous section provided all the interfaces, mappings and integration
processes that are required to define the actual ItsoEsbJmsInboundScenario as
depicted in Figure 5-219 on page 265 together with the interfaces and mappings
involved that are shown in Figure 5-222 on page 268.
This section illustrates how to assemble the definitions from the Integration
Repository into the overall scenario. Follow these steps:
1. Open the Integration Directory from the SAP Exchange Infrastructure tools
page. Refer to Figure 5-5. After a login, the Configuration: Integration Builder
application is opened. Create a new configuration scenario by selecting
Open New from its menu as shown in Figure 5-160 on page 234.
288
2. Select Configuration Scenario in the left pane, specify

ItsoEsbJmsInboundScenario as the name of the new scenario, and click
Create as shown in Figure 5-255.
Figure 5-255 Create ItsoEsbJmsInboundScenario
3. If you have not assigned the ITSO_ESB and ITSO_SAP_ECC Business

Systems within the application Configuration: Integration Builder previously,
then assign them as shown in Figure 5-163 on page 235 and Figure 5-168 on
page 239.
4. Otherwise go to the Objects tab in the application, browse to ITSO_ESB
within the Business System folder and select Add to Scenario from its
context menu as shown in Figure 5-256.
Figure 5-256 Add ITSO_ESB to Scenario
5. Choose ItsoEsbJmsInboundScenario from the list of scenarios

(Figure 5-257) and click Add.
Figure 5-257 Select ItsoEsbJmsInboundScenario as target
6. Select the business system ITSO_SAP_ECC, select Add to Scenario from

its context menu, choose ItsoEsbJmsInboundScenario from the list of
scenarios and click Add.
289
7. Browse to ITSO_SAP_ECC within the scenario ItsoEsbJmsInboundScenario

and select New from the context menu of Communication Channel. Refer to
Figure 5-258.
8. Specify ItsoRfcSenderChannel as the name of the channel and click Create.

Configure the new channel as shown in Figure 5-259. Follow these steps:
a. Select RFC as the Adapter Type and click Sender.
b. The entries in the editor section RFC Server Parameter establish the
registration of the communication channel on ITSO_SAP_3 under the
name itsorfcsender.
c. Within the editor section RFC Metadata Repository Parameter, specify the
d. Finally turn on the options in the Adapter-Specific Message Attributes
editor section. These options are important to specify routing instructions
as part of the receiver determination definition.
290
291
9. Browse to ITSO_ESB within the scenario ItsoEsbJmsInboundScenario and

select New from the context menu of Communication Channel. Then, follow
these steps:
a. Specify Xi2EsbJmsReceiverChannel as the name of the channel and click
Create. Edit the communication channel as shown in Figure 5-260.
b. Choose JMS as the adapter type and select Receiver.
c. Select WebSphere MQ (MQSeries) JMS Provider as the Transport
Protocol.
d. Insert XI2ESB_Request as the JMS Queue and specify the attributes that
describe additional connection parameter, as shown in Table 5-9.
Server
Port
Queue Manager
Name
Channel Name
ITSO_IBM_1
3414
ItsoQmgr2
all.clients
e. Ensure that JMS-Compliant is selected for JMS-Compliant.

f. Finally assign XI Conversation ID (ConversationID) to the Set
JMSCorrelationID To entry. Except for these entries, leave all the other
defaults.
292
Figure 5-260 Edit communication channel Xi2EsbJmsReceiverChannel
293
Note: If you have configured ItsoEsbJmsOutboundScenario before, you might

have noticed that here a different value is chosen for the JMS-Compliant field.
In this scenario, the structure of the value that is assigned to
JMSCorrelationID is determined by SAP Exchange Infrastructure and
includes a string with 24 literals. In this case, the mapping rules of JMS
messages to WebSphere MQ state that the JMSCorrelationID must be copied
into the MQRFH2 header. During the test of this scenario, we noticed that a
JMS message that is produced or consumed by a SAP Exchange
Infrastructure JMS adapter only handles MQRFH2 headers when the value
JMS Compliant is specified.
10.Browse to ITSO_ESB within the scenario ItsoEsbJmsInboundScenario and
select New from the context menu of Communication Channel. Then, follow
these steps:
a. Specify Xi2EsbJmsSenderChannel as the name of the channel and click
Create.
b. Within the Edit Communication Channel dialog box (Figure 5-261), choose
JMS as the adapter type and select Sender.
Protocol.
d. Insert ESB2XI_Response as the JMS Queue and specify the attributes that
describe additional connection parameters, as shown in Table 5-9 on
page 292.
f. Assign JMSCorrelationID to the Set XI Conversation ID (ConversationID)
To entry. Except for these entries, keep all the other defaults.
294
Figure 5-261 Edit Xi2EsbJmsSenderChannel
295
11.Browse to the entry Integration Process within the

ItsoEsbJmsInboundScenario and select New from its context menu. In the
Install Integration Process dialog box, click Continue once, then select
SynchRfcToAsynchJmsBridge from the Repository Processes
(Figure 5-262) and click Continue again.
Figure 5-262 Select Process from Repository Processes
12.Specify MyEsbSynchRfcToAsynchJmsBridge as the name of the integration

process instance (Figure 5-263) and click Finish.
Figure 5-263 Select name for integration process
13.Add the receiver determinations to the scenario. Select the Receiver

Determination folder within the ItsoEsbJmsInboundScenario and select New
Figure 5-264 Create receiver determination within ItsoEsbJmsInboundScenario
14.Choose ITSO_SAP_ECC as the sender service and BAPI_USER_GETLIST

as the interface and click Create (Figure 5-265).
Figure 5-265 Select Sender of receiver determination
296
15.In the Edit Receiver Determination dialog box, specify ITSO_ESB as a

configured receiver. Supplementary, add the condition
(RfcDestination=ITSO_XI_TO_PROCESS_ESB) using the Condition Editor that
opens if you use the input help of this field. Refer to Figure 5-267.
This definition establishes the routing rule that every request of type
BAPI_USER_GETLIST from system ITSO_SAP_ECC is to be forwarded to
MyEsbSynchRfcToAsynchJmsBridge if the incoming SAP Exchange
Infrastructure messages fulfills the specified condition.
Figure 5-266 Edit receiver determination from sender ITSO_SAP_ECC
The left operand RfcDestination of the condition refers to a context object

which can be selected using the Condition Editor. The right operand
ITSO_XI_TO_PROCESS_ESB is given as a literal.
297
Note: If you plan to run the different SOAP or JMS inbound scenarios
simultaneously, this receiver determination might already exist. In this
case, just add the existing receiver determination to the scenario and
extend it by the row including the condition and service as shown in
Figure 5-266.
16.Likewise, create a receiver determination in the scenario for messages of
type UserListRequestBO_ABS sent from Service
MyEsbSynchRfcToAsynchJmsBridge. In the Edit Receiver Determination
dialog box, refer to ITSO_ESB as the receiver of the message of the stated
type. Refer to Figure 5-268.
Figure 5-268 Edit receiver determination from MyEsbSynchRfcToAsynchJmsBridge
298
17.Finally, create a receiver determination which establishes the rule that every
message from service ITSO_ESB and of type UserListResponseBO is
forwarded to MyEsbSynchRfcToAsynchJmsBridge. Refer to Figure 5-269.
Figure 5-269 Edit receiver determination from sender ITSO_ESB
18.Select Interface Determination within ItsoEsbJmsInboundScenario and

select New from its context menu. Refer to Figure 5-270.
299

the interface, MyEsbSynchRfcToAsynchJmsBridge as the receiver
service, and click Create. Within the Edit Interface Determination dialog box,
specify BAPI_USER_GETLIST_ABS as the Inbound Interface of the receiver.
Figure 5-271 Edit Interface Determination from sender ITSO_SAP_ECC
300
20.Create an additional interface determination with

MyEsbSynchRfcToAsynchJmsBridge as the sender,
UserListRequestBO_ABS as the interface and ITSO_ESB as the receiver
(Figure 5-272). Define UserListRequestBO as the Inbound Interface together
with UserListRequestBO_ABS_To_UserListRequestBO as its associated
Interface Mapping.
Figure 5-272 Edit interface determination from MyEsbSynchRfcToAsynchBridge
301
21.Finally create an interface determination from sender ITSO_ESB with

interface UserListResponseBO_ABS to receiver
MyEsbSynchRfcToAsynchJmsBridge, which specifies
UserListResponseBO_ABS as the Inbound Interface and
UserListResponseBO_TO_UserListResponseBO_ABS as the Interface Mapping.
Figure 5-273 Edit interface determination from sender ITSO_ESB
22.Select the entry Sender Agreement within the ItsoEsbJmsInboundScenario

and select New from its context menu. Refer to Figure 5-274.
302

as the interface and click Create. Within the Edit Sender Agreement dialog
box, select ItsoRfcSenderChannel as the sender communication channel.
Figure 5-275 Edit sender agreement for sender ITSO_SAP_ECC
24.In the same way create a sender agreement for sender ITSO_ESB with
interface UserListResponseBO, selecting Xi2EsbJmsSenderChannel as the
Sender Communication Channel. Refer to Figure 5-276.
Figure 5-276 Edit sender agreement for sender ITSO_ESB
25.Select Receiver Agreement in ItsoEsbJmsInboundScenario and select New

from its context menu as shown in Figure 5-277.
303
26.Specify MyEsbSynchRfcToAsynchJmsBridge as the sender service, ITSO_ESB

as the receiver service, UserListRequestBO as the receiver interface and click
Create. In the Edit Receiver Agreement dialog box, select
Xi2EsbJmsReceiverChannel as the receiver communication channel. Refer
to Figure 5-278.
27.Activate the configurations in the Integration Directory by activating its change

list. Refer to Figure 5-188 on page 249.
Finally for testing the scenario, define a RFC destination in the SAP ECC
instance on ITSO_SAP_3.
28.Logon to the SAP_ECC on ITSO_SAP_3. Within the SAPGUI open the
transaction SM59. Refer to Figure 5-123 on page 209 and click Create. Refer
to Figure 5-279.
Figure 5-279 Transaction Display and Maintain RFC Destinations in SAPGUI
304
29.Specify ITSO_XI_TO_PROCESS_ ESB as the RFC destination and choose T as a

connection type. Save your configuration. Select Registered Server
Program and specify itsorfcsender as the Program ID of the registered
server program. Finally, specify ITSO_SAP_3 as the gateway host and sapgw00
as the gateway service. Refer to Figure 5-280.
Figure 5-280 RFC Destination ITSO_XI_TO_PROCESS_ESB
30.If the communication channel ItsoRfcSenderChannel (Figure 5-259 on

page 291) has been activated before, the RFC destination
ITSO_XI_TO_PROCESS_ESB can be tested by selecting Test connection.
Note: The RFC destination is used only for routing the request within SAP
5.8.4 Configuring ItsoWmbJmsInboundScenario in the

In 5.8.2, Preparing the Integration Repository for JMS inbound scenario on
page 271, we provide all the interfaces, mappings and integration processes that
are required to define the actual ItsoWmbJmsInboundScenario as depicted in
305
Figure 5-220 together with the interfaces and mappings involved that are shown
in Figure 5-222 on page 268.
This section illustrates how to assemble the definitions from the Integration
Repository into the overall scenario.
1. Open the Integration Directory from the SAP Exchange Infrastructure tools
page (Figure 5-5 on page 151). After a login, the Configuration: Integration
Builder application opens. Create a new configuration scenario by selecting
Open New from its menu. Refer to Figure 5-160 on page 234.
2. Select Configuration Scenario in the left pane, specify
ItsoWmbJmsInboundScenario as the name of the new scenario, and click
Create (Figure 5-281).
Figure 5-281 Create ItsoWmbJmsInboundScenario
3. Select the Scenarios tab, open the ItsoWmbJmsInboundScenario folder,

navigate to the Business System folder and select Assign Business System
4. Within the window Assign Business System, click Continue twice until 3.
Select Business Systems is selected in the left pane. Refer to Figure 5-283.
Select ITSO_Advanced_ESB from the list of business systems in the right
Finish.
Figure 5-283 Select ITSO_Advanced_ESB as the business system to be assigned
5. Likewise, select Assign Business System from the context menu of

Business System again and this time add ITSO_SAP_ECC to
ItsoWmbJmsInboundScenario.
306
6. Browse to ITSO_SAP_ECC within the scenario

ItsoWmbJmsInboundScenario and select New from the context menu of
Communication Channel. Refer to Figure 5-284.
7. Specify ItsoRfcSenderChannel as the name of the channel and click Create.

Then, follow these steps:
a. Configure the new channel as shown in Figure 5-285.
b. Select RFC as the Adapter Type and click Sender.
c. Based on the entries in the editor section RFC Server Parameter, the
communication channels get registered in the SAP system on
ITSO_SAP_3 as itsorfcsender.
d. Within the RFC Metadata Repository Parameter editor section, specify the
e. Turn on the options in the Adapter-Specific Message Attributes editor
section. These options are important for specifying routing instructions as
part of the receiver determination definition.
307
308
8. Browse to ITSO_Advanced_ESB within the scenario

ItsoWmbJmsInboundScenario and select New from the context menu of
Communication Channel. Then, follow these steps:
a. Specify Xi2WmbJmsReceiverChannel as the name of the channel and click
Create.
b. Edit the communication channel as shown in Figure 5-286. Choose JMS
as the adapter type and select Receiver.
Protocol.
d. Insert XI2WMB_Request as the JMS Queue and specify the attributes,
which describe additional connection parameter, as shown in Table 5-10.
Server
Port
Queue Manager Name
Channel Name
ITSO_IBM_2
3414
ItsoQmgr1
all.clients

f. Assign XI Conversation ID (ConversationID) to the Set
JMSCorrelationID To entry. Except for these entries, leave all the other
defaults.
309
Figure 5-286 Edit communication channel Xi2WmbJmsReceiverChannel
310
Note: If you have configured ItsoWmbJmsOutboundScenario before, you

might have noticed that here a different value is chosen for the
JMS-Compliant field. In this scenario, the structure of the value that is
assigned to JMSCorrelationID is determined by SAP Exchange Infrastructure
and includes a string with 24 literals. In this case, the mapping rules of JMS
messages to WebSphere MQ state that the JMSCorrelationID must be copied
into the MQRFH2 header. During the test of this scenario, we noticed that a
JMS message that is produced or consumed by a SAP Exchange
Infrastructure JMS adapter only handles MQRFH2 headers when the value
JMS Compliant is specified.
9. Browse to ITSO_Advanced_ESB within the scenario
ItsoWmbJmsInboundScenario again and select New from the context menu
of Communication Channel. Then, follow these steps:
a. Specify Xi2WmbJmsSenderChannel as the name of the channel and click
Create.
b. Within the Edit Communication Channel dialog box, choose JMS as the
adapter type and select Sender. Refer to Figure 5-287
Protocol.
d. Insert WMB2XI_Response as the JMS Queue and specify the attributes that
describe additional connection parameter, as shown in Table 5-10 on
page 309.
f. Assign JMSCorrelationD to the Set XI Conversation ID (ConversationID)
To entry. Except for these entries, keep all the other defaults.
311
Figure 5-287 Edit communication channel Xi2EsbJmsSenderChannel
312
10.Browse to the Integration Process entry within the

ItsoWmbJmsInboundScenario and select New from its context menu. In the
Install Integration Process dialog box, click Continue once, then select
SynchRfcToAsynchJmsBridge from the Repository Processes, and click
Continue again. Refer to Figure 5-288.
Figure 5-288 Select Process from Repository Processes
11.Specify MyWmbSynchRfcToAsynchJmsBridge as the name of the integration

process instance and click Finish. Refer to Figure 5-289.
Figure 5-289 Select name for integration process
12.Next add the receiver determinations to the scenario. Select the Receiver
Determination folder within the ItsoWmbJmsInboundScenario and select New
Figure 5-290 Create receiver determination within ItsoWmbJmsInboundScenario

as the interface and click Create. Refer to Figure 5-291.
Figure 5-291 Select Sender of receiver determination
313
14.In the Edit Receiver Determination dialog box, specify ITSO_Advanced_ESB as

a configured receiver. Supplementary, add the condition
(RfcDestination=ITSO_XI_TO_PROCESS_WMB) using the Condition Editor that
opens if you use the input help of this field. Refer to Figure 5-292.
This definition establishes the routing rule that every request of type
BAPI_USER_GETLIST from system ITSO_SAP_ECC is to be forwarded to
MyWmbSynchRfcToAsynchJmsBridge if the incoming SAP Exchange
Infrastructure messages fulfills the specified condition.
Figure 5-292 Edit receiver determination from sender ITSO_SAP_ECC
The left operand RfcDestination of the condition refers to a context object

which can be selected using the Condition Editor. The right operand
ITSO_XI_TO_PROCESS_WMB is given as a literal.
314
Note: If you plan to run the different SOAP or JMS inbound scenarios
simultaneously, this receiver determination might already exist. In this
case, just add the existing receiver determination to the scenario and
extend it by the row including the condition and service as shown in
Figure 5-292.
15.Create a receiver determination in the scenario for messages of type
UserListRequestBO_ABS sent from Service
MyWmbSynchRfcToAsynchJmsBridge. In the Edit Receiver Determination
dialog box, refer to ITSO_Advanced_ESB as the receiver of the message of
the stated type. Refer to Figure 5-294.
Figure 5-294 Edit receiver determination from MyWmbSynchRfcToAsynchJmsBridge
315
16.Finally, create a receiver determination which establishes the rule that every
message from service ITSO_Advanced_ESB and of type
UserListResponseBO is forwarded to MyWmbSynchRfcToAsynchJmsBridge.
Figure 5-295 Edit receiver determination from sender ITSO_Advanced_ESB
17.Select Interface Determination within ItsoWmbJmsInboundScenario and

select New from its context menu. Refer to Figure 5-296.
316

the interface, and MyWmbSynchRfcToAsynchJmsBridge as the receiver
service and click Create. Within the Edit Interface Determination dialog box,
specify BAPI_USER_GETLIST_ABS as the Inbound Interface of the receiver.
Figure 5-297 Edit Interface Determination from sender ITSO_SAP_ECC
317
19.Create an additional interface determination with

MyWmbSynchRfcToAsynchJmsBridge as the sender,
UserListRequestBO_ABS as the interface and ITSO_Advanced_ESB as the
receiver. Refer to Figure 5-298. Define UserListRequestBO as the Inbound
Interface together with UserListRequestBO_ABS_To_UserListRequestBO as its
associated Interface Mapping.
Figure 5-298 Edit interface determination from MyWmbSynchRfcToAsynchBridge
318
20.Create an interface determination from sender ITSO_Advanced_ESB with

interface UserListResponseBO_ABS to receiver
MyWmbSynchRfcToAsynchJmsBridge, which specifies
UserListResponseBO_ABS as the Inbound Interface and
UserListResponseBO_TO_UserListResponseBO_ABS as the Interface Mapping.
Figure 5-299 Edit interface determination from sender ITSO_Advanced_ESB
21.Select the entry Sender Agreement within the ItsoWmbJmsInboundScenario

and select New from its context menu. Refer to Figure 5-300.
319

as the interface and click Create. Within the Edit Sender Agreement dialog
box, select ItsoRfcSenderChannel as the sender communication channel.
Figure 5-301 Edit sender agreement for sender ITSO_SAP_ECC
23.In the same way create a sender agreement for sender

ITSO_Advanced_ESB with interface UserListResponseBO, selecting
Xi2WmbJmsSenderChannel as the Sender Communication Channel. Refer
to Figure 5-302.
Figure 5-302 Edit sender agreement for sender ITSO_Advanced_ESB
320
24.Select Receiver Agreement in ItsoEsbJmsInboundScenario and select New

25.Specify MyWmbSynchRfcToAsynchJmsBridge as the sender service,

ITSO_Advanced_ESB as the receiver service, UserListRequestBO as the
receiver interface, and click Create. In the Edit Receiver Agreement dialog
box, select Xi2WmbJmsReceiverChannel as the receiver communication
channel. Refer to Figure 5-304.
26.Activate the configured artefacts within the Integration Directory by activating

its change list. Refer to Figure 5-188.
Finally for testing the scenario, define a RFC destination in the SAP ECC on
ITSO_SAP_3.
27.Logon to the SAP_ECC on ITSO_SAP_3. Within the SAPGUI open the
transaction SM59 and click Create. Refer to Figure 5-305.
Figure 5-305 Transaction Display and Maintain RFC Destinations in SAPGUI
321
28.Specify ITSO_XI_TO_PROCESS_WMB as the RFC destination and choose T as a

connection type. Save your configuration. Then, follow these steps:
a. Select Registered Server Program and specify itsorfcsender as
Program ID of the registered server program.
b. Specify ITSO_SAP_3 as the gateway host and sapgw00 as the gateway
service. Refer to Figure 5-306.
Figure 5-306 RFC Destination ITSO_XI_TO_PROCESS_WMB
29.If the communication channel ItsoRfcSenderChannel (Figure 5-285) has been

activated before, then the RFC destination ITSO_XI_TO_PROCES_WMB can
be tested by selecting Test connection. Refer to Figure 5-306.
322
5.9 Preparing the SAP Exchange Infrastructure runtime

The previous sections illustrated how to configure SAP Exchange Infrastructure
for the SOAP and JMS based scenarios described within this book. From a SAP
Exchange Infrastructure perspective, the SOAP based scenarios can be tested
as soon as their respective change is activated (Figure 5-86 on page 188).
In contrast to this an external driver for WebSphere MQ as a JMS provider has to
be installed before the JMS based scenarios are ready for testing. A detailed
description of how to install external drivers is provided by SAP on:
http://service.sap.com/nw04
To open this page you need to be registered with SAP. In the left pane of this
page select How-to Guides Exchange Infrastructure. Then download the
package How to Install and Configure External Drivers. The package includes a
document and a small Java based tool, drivertool, which simplifies the building
of the library including the external driver considerably.
Although the approach is very well documented, this paragraph shows the
building of the library because the JMS based scenarios are tested in an
environment in which the queues accessed by the JMS communication channels
are hosted by a queue manager running on WebSphere MQ V 6.0. In contrast to
this, the approach described in the document How to Install and Configure
External Drivers for building the JMS driver assumes WebSphere MQ 5.3.
Restriction: The configuration described herein is only the documentation of
a well defined ITSO environment. It describes how to configure an external
driver for WebSphere MQ V6 to be used for the SAP Exchange Infrastructure
JMS Adapter installed on ITSO_SAP_2. In particular, this documentation
assumes that a WebSphere MQ Client is installed on ITSO_SAP_2
(Figure 5-4).
Follow these steps:
1. Create a directory C:\WUtemp\jmsproviderlib on ITSO_SAP_2. Install the
drivertool that is provided in the package that was downloaded before.
Figure 5-307 Copy the drivertool
323
2. Copy the libraries listed in Table 5-11 from the installation directory of the
WebSphere MQ V6.0 Client to the directory C:\WUtemp\jmsproviderlib.
Table 5-11 Java Libraries from C:\Program Files\IBM\WebSphere MQ\Java\lib
CL3Export.jar
CL3Nonexport.jar
com.ibm.mq.jar
com.ibm.mqjms.jar
connector.jar
dhbcore.jar
rmm.jar
3. Within the command prompt set the environment variable JAVA_HOME to

reference the directory where you have installed the Java runtime
environment on ITSO_SAP_2. Use the drivertool to add the libraries listed
in Table 5-11. Having completed this, check that all the libraries are included.
Figure 5-308 Contents of aii_af_jmsproviderlib.sda
324
4. Deploy the created library using the Software Deployment Manager GUI for
SAP J2EE engine as described in the document How to Install and Configure
External Drivers. Refer to Figure 5-309.
Figure 5-309 Deploy aii_aj_jmsproviderlib.sda
325
326
Chapter 6.
Web Services based

integration to SAP Exchange
Infrastructure scenarios
This chapter describes in detail how to integrate different WebSphere products
with SAP using SAP Exchange Infrastructure and standard Web Services
technologies, such as SOAP, HTTP, and WSDL. It covers different integration
scenarios using SAP Exchange Infrastructure both as a service provider and as
a service consumer, combining these to different WebSphere products. Each
scenario is discussed in detail by describing the architecture, the required
configuration, development steps, and testing.
The chapter includes the following topics:
System landscape on page 328
Preparation on page 331
Scenario A: WebSphere Enterprise Service Bus consuming Web Service
from SAP Exchange Infrastructure on page 332
Development on page 332
Scenario B: WebSphere Application Server consuming Web Service from
SAP Exchange Infrastructure on page 383
327
Scenario C: SAP Exchange Infrastructure consuming Web Service from

WebSphere Enterprise Service Bus on page 404
Conclusion on page 438
Extension A: WebSphere Process Server consuming Web Service from SAP
Exchange Infrastructure on page 438
Extension B: SAP Exchange Infrastructure consuming Web Service from
WebSphere Process Server on page 461
6.1 System landscape

Figure 6-1 depicts the system landscape of the environment that we used to build
and test all the different scenarios in this chapter.
ITSO_IBM_1
ITSO_SAP_2
WebSphere Integration Developer V

6.0.1.2
SAP Exchange Infrastructure 3.0 SP

18

V 6.0.1.0
Java 2 Runtime Environment SE

1.4.2_11
WebSphere Process Server V

6.0.1.0

V 9.2.0.1
ITSO_SAP_3
ITSO_IBM_3
SAP ERP Central Component 5.0
WebSphere Application Server V 6

Test Environment Update 6.0.2.5

V 8.2
Rational Application Developer V

6.0.1.1
Figure 6-1 System landscape of the environment
328
The environment includes two nodes for WebSphere software (ITSO_IBM_1 and
ITSO_IBM_3) and two nodes for SAP software (ITSO_SAP_2 and
ITSO_SAP_3).
ITSO_IBM_1 node includes the WebSphere Business Integration products,
including the WebSphere Enterprise Service Bus and WebSphere Process
Server runtimes and the WebSphere Integration Developer toolkit.
ITSO_IBM_3 node includes the WebSphere Application Server runtime for
running standard J2EE applications as well as the Rational Application
Developer tool for developing them.
ITSO_SAP_2 node includes SAP Exchange Infrastructure and the related
tools and databases.
ITSO_SAP_3 node includes the SAP ERP back-end and databases of
business applications.
Note: This environment setup and these specific product versions were used
to build the examples in this chapter. Always use the latest fix packs and other
patches while installing your environment.
Note: The scenarios that we demonstrate in this chapter require

authentication. The examples use itsouser user ID and itso01 password. You
must replace these as appropriate to suit your environment.

This chapter discusses several different sub-scenarios between IBM WebSphere
and SAP Exchange Infrastructure using Web Services based integration. In the
different sub-scenarios the actual WebSphere side runtime product is varied
between:
The roles of the service producer and service consumer are changed between
SAP Exchange Infrastructure and WebSphere.
Chapter 6. Web Services based integration to SAP Exchange Infrastructure scenarios
329
6.2.1 Scenario A: WebSphere Enterprise Service Bus consuming

Web Service from SAP Exchange Infrastructure
In this sub-scenario the SAP Exchange Infrastructure is configured to expose the
functionality of simple BAPI component as a Web Service. In the WebSphere
side the WebSphere Enterprise Service Bus is configured to mediate
request-response messages from external clients to the SAP XI using a
Mediation Module.
6.2.2 Scenario B: WebSphere Application Server consuming Web

Service from SAP Exchange Infrastructure
In this sub-scenario the Web Service provided by SAP XI from scenario A is
re-used without changes. The scenario describes how to use the Rational
Application Developer to develop a standard J2EE application which consumes
the Web Service from SAP XI. This application is deployed into WebSphere
Application Server.
6.2.3 Scenario C: SAP Exchange Infrastructure consuming Web

Service from WebSphere Enterprise Service Bus
In this sub-scenario the WebSphere Enterprise Service Bus is configured to
expose the functionality of a simple Java component as a Web Service using a
Mediation Module. In the SAP side the SAP XI is configured to act as a Web
Service client and mediate the requests originated from the SAP ERP back-end
system to WebSphere Enterprise Service Bus.
6.2.4 Extension A: WebSphere Process Server consuming Web

Service from SAP Exchange Infrastructure
In this extension the solution from sub-scenario A is extended by using the
WebSphere Process Server. The SAP Exchange Infrastructure configuration is
kept unchanged as in the original implementation. In the WebSphere side, the
Mediation Module built in to the original implementation is reused by building a
simple business process on top of it.
330
6.2.5 Extension B: SAP Exchange Infrastructure consuming Web

Service from WebSphere Process Server
In this extension the solution from sub-scenario C is extended by using the
Mediation Module built in to the original implementation is reused by building a
6.3 Preparation
This section describes the required preparation steps for creating the example
scenarios and their extensions.
6.3.1 WebSphere installation

Install the required WebSphere products into the test environment:
WebSphere Integration Developer version 6 with following options:
WebSphere Enterprise Service Bus version 6 Test Environment
WebSphere Process Server version 6 Test Environment
Rational Application Developer version 6 with following options:
WebSphere Application Server version 6 Test Environment
The installation instructions of the individual products can be found from the
product infocenters and in the related books.
6.3.2 SAP XI configuration

The configuration of SAP Exchange Infrastructure for the scenarios in this
chapter has been described in Chapter 5., Configuring SAP XI for the SOAP and
JMS-based scenarios on page 143.
331

consuming Web Service from SAP Exchange
Infrastructure
In this scenario the SAP Exchange Infrastructure is configured to expose the
functionality of simple BAPI component as a Web Service. The BAPI, named as
BAPI_USER_EXISTENCE_CHECK, provides a functionality for checking
whether a username, given as an input parameter, exists in the SAP system or
not. In the WebSphere side the WebSphere Enterprise Service Bus is configured
to mediate request-response messages from external clients to the SAP XI using
a Mediation Module. Finally, the configuration is tested by invoking the Mediation
Module using different clients, including the built-in Test Client and a simple
JavaServer Page.
6.4.1 Operational model

Figure 6-2 depicts the operational model of the scenario.
WebSphere ESB 6.0.1.0
SAP Exchange
Infrastructure 3.0 SP18
SAP ERP 5.0
JSP Page
Mediation Module
SOAP/
ITSOESB2SAPXI_WS
HTTP
RFC
Figure 6-2 Operational model of the scenario
6.4.2 Development
This section describes the required development steps for building the Mediation
Module for the WebSphere Enterprise Service Bus.
Common preparation procedures

Common preparation procedure include the following tasks:
1. Start the WebSphere Integration Developer.
2. Change to Business Integration Perspective if you currently have some other
perspective open.
332
3. If automatic building is currently enabled, disable it. You can check this from
the drop-down menu Project Build Automatically as shown in Figure 6-3.
The disabling of the automatic build improves the performance of the
WebSphere Integration Developer because it will not needlessly build the
workspace after each save operation.
Figure 6-3 Disable automatic building
333
Creating a library for shared resources

In the first phase of the development, you create a library for storing shared
resources. You use the same library later in the other scenarios. To create a
library for shared resources, follow these steps:
1. Create a new project by selecting File New Project as shown in
Figure 6-4.
Figure 6-4 Create a new project
334
2. Select Library as the project type and click Next as shown in Figure 6-5.
Figure 6-5 Select Library as project type
335
3. Type ITSOSAPXI_WS_Lib as the library name and use the default location for
library as in Figure 6-6.
4. Click Finish to create the library.
Figure 6-6 Set name for the library
336
Importing the WSDL generated by SAP Exchange

Infrastructure
To invoke the Web Service from SAP Exchange Infrastructure, you need to
import the corresponding WSDL file BapiUserExistence.wsdl to the workspace.
Follow these steps:
1. Right-click the library that you just created in the Business Integration View
and select Import as shown in Figure 6-7.
Figure 6-7 Import resources to library
337
2. Select Interface/WSDL File as an import source and click Next as shown in

Figure 6-8.
Figure 6-8 Select import source type
338
3. Set the import settings as follows (Figure 6-9):

a. Use the Browse button to select the directory where the WSDL file that is
generated by SAP Exchange Infrastructure is stored.
b. Select the BapiUserExistence.wsdl file.
c. Keep the Into folder field set as ITSOSAPXI_WS_Lib.
d. Make sure that the Create selected folders only option is selected from
import options.
4. Click Finish to import the WSDL file to the Library.
Figure 6-9 Set import settings for the WSDL file
339
5. Expand the tree in the Business Integration View to verify that the import
created new data types, an interface, and a Web service port definition as
depicted in Figure 6-10.
Figure 6-10 Verify the results of the WSDL import
340
Creating the mediation module

The next phase of the development is to create a mediation module, which is the
main application module for all WebSphere Enterprise Service Bus projects and
includes the mediation flows and the import from SAP Exchange Infrastructure.
Follow these steps:
1. Right-click in empty area in the Business Integration View and select New
Mediation Module as shown in Figure 6-11.
Figure 6-11 Create a new Mediation Module
341
2. Set the module properties as follows (Figure 6-12):

a. Type ITSOESB2SAPXI_WS as Module name.
b. Make sure that Use default is selected for module location.
c. Select WebSphere ESB Server v6.0 as target runtime.
d. Make sure that the Create mediation flow component option is selected.
e. Click Next.
Figure 6-12 Set module name and settings
342
3. Select ITSOSAPXI_WS_Lib in the libraries list to use resources in the library

within the mediation module as shown in Figure 6-13.
4. Click Finish to create the mediation module.
Figure 6-13 Select required libraries for the Mediation Module
343
Creating Business Objects and interfaces

This phase of the development includes the creation of the request and response
Business Objects (BO) and a the new interface that use the BOs as input and
output types of a request-response operation. To create the BOs and interfaces,
follow these steps:
1. In the Business Integration View, right-click Data Types node in the
ITSOESB2SAPXI_WS module and select New Business Object as
Figure 6-14 Create a new Business Object
344
2. In the window that opens set Business Object properties as follows

(Figure 6-15):
a. Clear the Default box in the namespace field and enter
http://itso.ibm.com/sg247220.
b. Leave the Folder field empty.
c. Enter UserExistenceRequestBO in the name field.
d. Leave the Inherit from field set as <none>.
e. Click Finish to create the Business Object.
Figure 6-15 Set properties for the request Business Object
345
3. Right-click in a empty area in the Business Object editor that opens and
select Add attribute as shown in Figure 6-16.
Figure 6-16 Add a new attribute to the request Business Object
346
4. In the Properties view, set the following properties for the new attribute
(Figure 6-17):
a. Enter username in the name field and make sure that the type field is set to
string.
b. Select Required.
Figure 6-17 Set properties for the username attribute
5. Save the Business Object by pressing Ctrl+S and then close the editor.
6. Repeat steps 1 through 5 and create an additional Business Object with the
properties that are specified in Table 6-1.
Table 6-1 Properties for the response Business Object
Namespace
http://itso.ibm.com/sg247220
Folder
Leave as empty
Name
UserExistenceResponseBO
Inherit from
<none>
7. Repeat steps 1 through 5 and add an attribute to the response Business

Object with properties described in Table 6-2.
Table 6-2 Attribute properties for the response Business Object
Name
message
Type
string
Required
No
347
8. Save the response Business Object by pressing Ctrl+S and then close the
editor.
9. Right-click the Interfaces node of the ITSOESB2SAPXI_WS module in the
Business Integration View and select New Interface as shown in
Figure 6-18.
Figure 6-18 Create a new interface
348
10.In the window that opens, set the properties of the interface as follows
(Figure 6-19):
a. Clear the default box and enter http://itso.ibm.com/sg247220 in the
namespace field.
b. Leave the folder field as empty.
c. Enter UserExistenceIF in the name field.
Figure 6-19 Set the properties for the new interface
349
11.In the interface editor of the UserExistenceIF, right-click in the empty area
and select Add Request Response Operation as shown in Figure 6-20.
Figure 6-20 Add new operation to the UserExistenceIF interface
12.Enter checkUserExistence as the operation name.
350
13.Right-click in the checkUserExistence row and select Add Input as in

Figure 6-21.
Figure 6-21 Add input parameters to the checkUserExistence operation
14.In the properties view of the input parameter, enter request in the Name field
and select UserExistenceRequestBO in the Type field.
15.In the Interface editor, right-click in the checkUserExistence row again and
select Add Output.
16.In the properties view of the output parameter, enter response in the name
field and select UserExistenceResponseBO in the type field as shown in
Figure 6-22.
Figure 6-22 The UserExistenceIF interface after adding the operation in its input and output parameter
17.Press Ctrl+S to save the interface and close the interface editor.
351
Assembling the mediation module

After importing and creating the required resources (BOs and interfaces) for
components, you assemble the mediation module by creating the required import
from SAP Exchange Infrastructure and wiring it with the Mediation Flow
component. To assemble the mediation module, follow these steps:
1. Double-click the ITSOESB2SAPXI_WS Assemble diagram in the Business
Integration View to open it in the Assembly Editor.
2. Select the Mediation1 component in the Assembly editor by clicking it, and in
the Properties view, enter UserExistence_MediationFlow in the Name field as
Figure 6-23 Rename the Mediation Flow component
352
3. Right-click UserExistence_MediationFlow and select Add Interface as

Figure 6-24 Add an interface to the Mediation Flow component
353
4. Select UserExistenceIF from the list and click OK as shown in Figure 6-25.
Figure 6-25 Select the interface to add
354
5. From the Business Integration View in the library module, select the
BapiUserExistenceCheck interface and drag it to the Assembly Editor. Select
Import with Web Service Binding and click OK as shown in Figure 6-26.
Figure 6-26 Select type for SAP Exchange Infrastructure import
6. Select Import1 that you just created and rename it to SAP_XI as shown in
Figure 6-27.
Figure 6-27 Rename the Web Service import
7. Select the Wiring tool from the palette, select

UserExistence_MediationFlow and create a wire to SAP_XI import. If
prompted, select OK to create a matching reference on the source node as in
Figure 6-28.
Figure 6-28 Create a wire from Mediation Flow to the import
355
Implementing the Mediation Flow

After you have wired the Mediation Flow component, you need to implement it. In
the implementation, you define the mediations and data mappings between the
mediation interface (UserExistenceIF) and the SAP Exchange Infrastructure
interface (BapiUserExistence). To implement the Mediation Flow, follow these
steps:
1. Double-click the UserExistence_MediationFlow component and select Yes
to generate the implementation as shown in Figure 6-29.
Figure 6-29 Generate the implementation to the Mediation Flow component
356
2. Select the ITSOESB2SAPXI_WS folder and click OK as shown in Figure 6-30

to open the Mediation Flow Editor.
Figure 6-30 Select the folder for the Mediation Flow implementation
3. In the Operation connections section (upper section) of the editor, create a

connection from the checkUserExistence operation to the
BapiUserExistenceCheck operation by dragging a line from the source to the
target as shown in Figure 6-31.
Figure 6-31 Create a connection from checkUserExistence to BapiUserExistenceCheck
357
4. In the flow section of the editor, select XSL Transformation primitive from
the palette and place it in the middle as shown in Figure 6-32.
Figure 6-32 Create a new XSL Transformation primitive in the request flow
5. Rename the XSLTransformation1 primitive to RequestTF.

6. Create a connection from the out terminal of the Request node to the in
terminal of the transformation primitive by dragging a line from source
terminal to target terminal as shown in Figure 6-33.
Figure 6-33 Connect the request node to the transformation primitive
358
7. In the same way as in the previous step, create a connection from the out
terminal of the transformation primitive to the in terminal of the Invoke node
Figure 6-34 Connect the transformation primitive to the Invoke node
8. In the flow section, select the RequestTF primitive and switch to the Details
tab of the Properties view. Then, click New to create a new mapping as
Figure 6-35 Create a new mapping for the RequestTF primitive
359
9. Leave the Message Type settings with the default values and click Finish to
create the mapping as shown in Figure 6-36. This action opens the Mapping
editor.
Figure 6-36 Specify the message types for the XSLT mapping
10.In the Mapping editor, expand all the child nodes of both the source tree and
the target tree. Select the smo/body/checkUserExistence/request/username
node in the source tree and then select
smo/body/BapiUserExistenceCheckQuery_MT/USERNAME in the target
tree.
360
11.Right-click, and select Create Mapping to create a mapping for the

username field as shown in Figure 6-37.
Figure 6-37 Create a mapping for the username field
12.Save the mapping by pressing Ctrl+S and closing the Mapping editor.
13.In the Details tab of the Properties view, click Regenerate XSL to generate
the corresponding XSL file as shown in Figure 6-38.
Figure 6-38 Generate the XSL file for the request transformation
14.Click OK to close the message box.
361
15.In the Flow section of the editor, click the Response tab to switch to the
response flow as shown in Figure 6-39.
Figure 6-39 Switch the editor to the response flow
16.Create a XSL transformation primitive to the response flow and rename it to

ResponseTF as shown in Figure 6-40.
Figure 6-40 Create the XSL Transformation primitive to the response flow
17.Using the same technique as in the request flow, create following connections
between the different nodes and primitives as shown in Table 6-3.
Table 6-3 List of connections for the response flow
362
Source
node/primitive
Source terminal
Target
node/primitive
Target terminal
Response BapiUserExistence
Check
out
ResponseTF
in
ResponseTF
out
Response checkUserExistence
in
After creating the connections, the response flow looks as illustrated in the
Figure 6-41.
Figure 6-41 Create connections for the response flow
18.Select ResponseTF primitive on the Flow section and click New on the
Details tab of the Properties view.
19.Leave the message types of the mapping to default values and click Finish to
create the mapping.
363
20.In the mapping editor, expand all the child nodes of both source and target
trees and create a mapping from
smo/body/BapiUserExistenceCheckResponse_MT/RETURN/MESSAGE to
smo/body/checkUserExistenceResponse/response/message as shown in
Figure 6-42.
Figure 6-42 Create a mapping for the message field
21.Save the mapping by pressing Ctrl+S and closing the Mapping editor.
22.Click Regenerate XSL to generate the corresponding XSL file.
23.In the Mediation Flow Editor, press Ctrl+S to save the Mediation Flow and
close the Mediation Flow Editor.
364
Creating a stand-alone reference

To test the Mediation Flow component from a non-SCA component (JavaServer
Page in this scenario), you need a stand-alone reference. To create a
stand-alone reference, follow these steps:
1. In the Assembly Editor, select Stand-alone References from palette and place
it on the diagram as shown in Figure 6-43.
Figure 6-43 Select Stand-alone References tool from the palette
2. Select the just created Stand-alone References and click Add Reference as
Figure 6-44 Add reference to the Stand-Alone Reference
365
3. Select UserExistenceIF from the list and click OK as shown in Figure 6-45.
Figure 6-45 Select the interface for the reference
366
4. Select Yes to create utility Java interface as shown in Figure 6-46.
Figure 6-46 Create a utility Java interface
5. From the Assembly Editor, select the wiring tool and create a wire from the
Stand-alone Reference to the UserExistence_MediationFlow component as
Figure 6-47 Wire the Stand-alone Reference
6. Press Ctrl+S to save the Assembly Diagram.
367
7. Verify that the utility Java interface was generated to the module. You can
verify this from the Business Integration View, as shown in Figure 6-48.
Figure 6-48 Verify the generation of the Java interface
Building the application

Because the automatic building of the application was disabled in the beginning,
you need to build it manually. To build the application manually, follow these
steps:
1. From the drop-down menus, select Project Clean as shown in
Figure 6-49.
Figure 6-49 Clean the application build
368
2. From the cleaning options select Clean all projects and make sure that Start
a build immediately is selected. Click OK to start the cleaning and building
process as shown in Figure 6-50.
Figure 6-50 Select cleaning options
Configuring SAP Exchange Infrastructure authentication

As mentioned previously, the SAP Exchange Infrastructure is configured to
require authentication for the BapiUserExistenceCheck Web Service by HTTP
basic authentication. To invoke the service, you need to configure the mediation
module to provide the user credentials to SAP Exchange Infrastructure. To
configure SAP Exchange Infrastructure authentication, follow these steps:
1. Switch to the J2EE perspective (Figure 6-51).
Figure 6-51 Switch to J2EE perspective
369
2. Open the Project Explorer view, expand the ITSOESB2SAPXI_WSEJB EJB

project and double-click its deployment descriptor as shown in Figure 6-52.
Figure 6-52 Open the deployment descriptor of the EJB project
3. From the EJB Deployment Descriptor editor, switch to the WS Binding sheet
Figure 6-53 Switch to the WS Binding sheet
4. In the Port Qualified Name Binding Details section, enter itsouser in the User
ID field and itso01 in the Password field as shown in Figure 6-54.
Figure 6-54 Configure the HTTP basic authentication for the Web Service client
5. Save the changes by pressing Ctrl+S and closing the EJB Deployment
Descriptor editor.
Attention: If the application is cleaned and rebuilt after you configure the
HTTP basic authentication in the EJB deployment descriptor, you will lose
these configurations and will have to configured them again.
370
6.4.3 Testing
This section demonstrates how to test the implementation of the scenario A
using two different approaches.
Note: Before starting the testing, make sure that the required SAP
configurations have been completed and the SAP environment is running.
Testing with the built-in test client

This section demonstrates how to test the implemented mediation module using
the built-in test client of the WebSphere Integration Developer. To test with the
built-in test client, follow these steps:
1. Switch to the Business Integration Perspective.
2. In the Servers view, select WebSphere ESB Server v6.0 and click the Start
icon as shown in Figure 6-55.
Figure 6-55 Start the WebSphere ESB Server
3. After the server has started, verify from the Console view that the server is up
and running. There is a log entry with a message Server server1 open for
e-business as shown in Figure 6-56.
Figure 6-56 Verify a successful server start up
371
4. In the Servers view, right-click WebSphere ESB Server v6.0 and select Add
and remove projects as shown in Figure 6-57.
Figure 6-57 Add a project to the server
5. From the available projects, select ITSOESB2SAPXI_WSApp and click Add

(Figure 6-58). Click Finish. This publishes the application to the server.
Figure 6-58 Select the project to publish
372
6. From the Business Integration View, double-click the ITSOESB2SAPXI_WS

module and select Test Test Module as shown in Figure 6-59.
Figure 6-59 Start the test client
373
7. From the test client, select UserExistence_MediationFlow in the component

field and enter itsouser in the value column of the username parameter.
Then select Continue as shown in Figure 6-60.
Figure 6-60 Configure the test client
374
8. If prompted, select WebSphere ESB Server v6.0 as a deployment location

for the Test Client and select Use this as the default and do not ask again.
Click Finish as shown in Figure 6-61.
Figure 6-61 Select deployment location for the Test Client
9. After invoking the mediation module, there is a return parameter, named

message, which includes the text User ITSOUSER exists as shown in
Figure 6-62.
Figure 6-62 Return parameters of a successful test
10.In the Test Client, click the Invoke icon to create a new Invoke node as
Figure 6-63 Create a new Invoke node
375
11.Enter unknown in the value field of the username input parameter and click
Continue.
12.Because there is no such user as unknown in the SAP system, the response
message includes the text User UNKNOWN does not exist as shown in
Figure 6-64.
Figure 6-64 Return parameter for a non-existing user
Testing with a JavaServer Page

As an alternative testing method, this section demonstrates how to test the
Mediation Module with a simple JavaServer Page (JSP). Follow these steps:
1. Switch to the Web perspective as shown in Figure 6-65.
Figure 6-65 Switch to the Web perspective
2. From the Project Explorer view right-click the Dynamic Web Projects node
and select New Dynamic Web Project as shown in Figure 6-66.
Figure 6-66 Create a new Dynamic Web Project
376
3. In the window that opens, set the project properties as follows (Figure 6-67):
a. Type ITSOESB2SAPXI_WSClient in the name field.
b. Select WebSphere ESB Server v6.0 as target server.
c. Make sure that the Add module to an EAR project option is selected.
d. Select ITSOESB2SAPXI_WSApp as the EAR project.
e. Make sure that the Context Root field includes the value
TSOESB2SAPXI_WSClient.
f. Click Next.
Figure 6-67 Set basic properties for the Web project
377
4. On the Module dependencies page, select ITSOESB2SAPXI_WS and click

Finish to create the Web project (Figure 6-68).
Figure 6-68 Select module dependencies
378
5. In the Project Explorer view, expand the ITSOESB2SAPXI_WSClient project

and right-click the WebContent node. Select New JSP File as shown in
Figure 6-69.
Figure 6-69 Create a new JSP page
379
6. In the window that opens, type index.jsp to the File name field and leave
other fields at their default values. Click Finish to create the JSP page
(Figure 6-70).
Figure 6-70 Set properties for the JSP page
380
7. In the JSP editor, replace the source code of the page with a code that uses
the Java interface that was created by the Stand-Alone Reference. The
fragment of JSP code in Example 6-1 demonstrates the invoking of the
Mediation Module using the existing Java interface.
Example 6-1 Invoke the UserExistenceIF interface from JSP page
<%
ServiceManager manager = new ServiceManager();
BOFactory factory = (BOFactory)
manager.locateService("com/ibm/websphere/bo/BOFactory");
UserExistenceIF service = (UserExistenceIF)
manager.locateService("UserExistenceIFPartner");
String message = new String();
if (request.getParameter("userName") != null) {
DataObject reqObj =
factory.create("http://itso.ibm.com/sg247220",
"UserExistenceRequestBO");
reqObj.setString("username", request.getParameter("userName"));
DataObject respObj = service.checkUserExistence(reqObj);
message = respObj.getString("message");
}
%>
You can find the full source code of the JSP page in Appendix A, Additional
material on page 1441.
8. Save the JSP page by pressing Ctrl+S and then close the editor.
9. Select Project Build All from the menu to rebuild the workspace as shown
in Figure 6-71.
Figure 6-71 Rebuild the workspace
381
10.From the Servers view, right-click WebSphere ESB Server v6.0 and select
Publish to redeploy the application with the new Web module as shown in
Figure 6-72. Click OK to close the message window.
Figure 6-72 Redeploy the application to the server
11.Open a Web browser and open the JSP page that you created previously. If
the WebSphere ESB Test Environment is configured to default settings, the
Web address of the JSP page is:
http://localhost:9081/ITSOESB2SAPXI_WSClient/index.jsp
12.Enter itsouser in the username field and click Submit. After processing the
request, the result field is populated with the message User ITSOUSER exists
(Figure 6-73).
Figure 6-73 Test the application with the JSP page
382
6.4.4 Conclusion
This scenario demonstrated how you can use the WebSphere Enterprise Service
Bus to consume a Web Service from the SAP Exchange Infrastructure. From the
WebSphere Enterprise Service Bus perspective, SAP Exchange Infrastructure
as the provider of the Web Service is transparent for the client and building so
that the mediation module can be performed by following generic guidelines.
However, enabling HTTP basic authentication, which is typical to SAP Exchange
Infrastructure configurations, requires some advanced configuration efforts in the
WebSphere Enterprise Service Bus.
6.5 Scenario B: WebSphere Application Server

Infrastructure
This scenario reuses the Web Service that is provided by SAP Exchange
Infrastructure from scenario A without changes. Thus, the SAP Exchange
Infrastructure has been configured to expose the functionality of BAPI
USER_EXISTENCE_CHECK as a Web Service.
The scenario describes how to use the Rational Application Developer (RAD) to
develop a standard J2EE application which consumes the Web Service from
SAP Exchange Infrastructure. In the development steps, the Web Service Client
generation features of the RAD are used generate a client from the WSDL file
provided by SAP Exchange Infrastructure. Then, a simple JSP page is created
that uses the generated client to invoke the SAP-based Web Service. Finally, this
application is deployed into WebSphere Application Server.
383

Figure 6-74 depicts the operational model that we use in this scenario.
WebSphere Application
Server 6.0.2.5
SAP Exchange
SAP ERP 5.0
Web Module
ITSOWAS2SAPXI_WS
JSP Page
Web Service Client
SOAP/
HTTP
RFC
Figure 6-74 Operational model of the scenario
6.5.2 Development
This section describes how to build the Web Module for the WebSphere
Application Server. Common preparation procedures include the following steps:
1. Start the Rational Application Developer.
2. Open the preferences by selecting Window Preferences as shown in
Figure 6-75.
Figure 6-75 Open Workbench preferences
384
3. Expand the Workbench Capabilities node and make sure that all the
sub-nodes of the Web Services Developer node are checked. When
complete, click OK as shown in Figure 6-76.
Figure 6-76 Enable Web Services development capabilities
385
4. If the automatic building of the workspace is enabled, disable it by selecting

Project Build Automatically as shown in Figure 6-77.
Figure 6-77 Disable automatic build
5. Switch to the Web perspective as shown in Figure 6-78.
Figure 6-78 Switch to Web perspective
386
Creating the Web project

To create the Web project, follow these steps:
1. Right-click the Dynamic Web Projects node in the Project Explorer view and
select New Dynamic Web Project as shown in Figure 6-79.
Figure 6-79 Create a new Dynamic Web project
2. In the properties window, set the project properties as follows (Figure 6-80):
a. Type ITSOWAS2SAPXI_WS to the Name field.
b. Leave the Project location field to default value.
c. Make sure that Servlet version field is set to 2.4.
d. Make sure that WebSphere Application Server v6.0 is selected as
Target server.
e. Make sure that the Add module to an EAR project option is selected.
f. Make sure that EAR project field is set to ITSOWAS2SAPXI_WSEAR.
g. Make sure that Context root field is set to ITSOWAS2SAPXI_WS.
h. Leave the Add support for annotated Java classes option clear.
i. Click Finish.
387
Figure 6-80 Set Web project properties
388
Importing the WSDL file from SAP Exchange Infrastructure

To import the WSDL file from SAP Exchange Infrastructure, follow these steps:
1. Right-click the ITSOWAS2SAPXI_WS project in the Project Explorer view
and select Import Import as shown in Figure 6-81.
Figure 6-81 Import files to the project
389
2. Select Filesystem as the import source and click Next as shown in

Figure 6-82.
Figure 6-82 Select the import source
390
3. In the Import window, set the import properties as follows (Figure 6-83):
a. Use the Browse button to select the source directory where the WSDL file
generated by SAP Exchange Infrastructure has been stored.
b. Select the BapiUserExistenceCheck.wsdl file.
c. Make sure that Into folder field includes value ITSOWAS2SAPXI_WS.
d. From the options, select Create selected folders only.
e. Click Finish to import the WSDL file.
Figure 6-83 Set import properties
391
Generic Web Service client

In this phase of development, you use the Web Services development features
of the Rational Application Developer to generate a standard Java client for the
Web Service automatically. Follow these steps:
1. Right-click the BapiUserExistenceCheck.wsdl file and select Web
Services Generate Client as shown in Figure 6-84.
Figure 6-84 Generate the Web Service client
392
2. In the window that opens, set the client properties as follows and click Next.
a. Select Java Proxy as Client Proxy type.
b. Make sure that option Create folders, when necessary, is selected and the
other options are not selected as shown in Figure 6-85.
Figure 6-85 Set the Web Service client properties
393
3. In the next window, make sure that BapiUserExistenceCheck.wsdl is selected

Figure 6-86 Select the WSDL file
4. Click Finish to generate the client. If prompted, select Yes to allow the
Rational Application Developer to overwrite the existing web.xml file.
394
5. To verify the successful creation of the Web Service client, expand the Java
Resources node on the Project Explorer view. It includes a set of Java
classes packaged in the com.ibm package as shown in Figure 6-87.
Figure 6-87 Verify the results of the client generation
395
Creating the JavaServer Page

To create the JavaServer Page, follow these steps:
1. Right-click the WebContent node on the Project Explorer view and select
New JSP File as shown in Figure 6-88.
Figure 6-88 Create a new JSP page
396
2. In the JSP properties window, set the properties as follows (Figure 6-89):
a. Make sure that Folder field includes value /ITSOWAS2SAPXI_WS/WebContent.
b. Type index.jsp in the File Name field.
c. Make sure that Markup language is set to HTML.
d. Make sure that all of the option fields are clear.
e. Set the Model field to None.
f. Clear the Configure advanced options field.
g. Click Finish.
Figure 6-89 Set the properties of the JSP page
397
3. In the JSP editor, switch to the Source view of the editor as shown in
Figure 6-90.
Figure 6-90 Switch to the source view
4. Replace the source code of the JSP page with an implementation that uses
the previously generated Web Service client to invoke the Web Service
provided by SAP Exchange Infrastructure. Example 6-2 is a code fragment
that demonstrates the key parts of such implementation.
Example 6-2 Example JSP code for index.jsp
<%@ page import="com.ibm.*" %>

<%
BapiUserExistenceCheckProxy proxy = new
BapiUserExistenceCheckProxy();
String message = new String();
if (request.getParameter("userName") != null) {
BapiUserExistenceCheckQuery_DT reqObj =
new BapiUserExistenceCheckQuery_DT();
reqObj.setUSERNAME(request.getParameter("userName"));
BapiUserExistenceCheckResponse_DT respObj =
proxy.bapiUserExistenceCheck(reqObj);
message = respObj.getRETURN().getMESSAGE();
}
%>
You can find the full source code of the JSP page in Appendix A, Additional
material on page 1441.
5. Save the changes to JSP page by pressing Ctrl+S and then close the editor.
398
Configuring SAP Exchange Infrastructure authentication

Because the SAP Exchange Infrastructure configuration is the same as it was in
scenario A, you must also configure the Web Service client to pass credential
information to SAP Exchange Infrastructure to invoke the Web Service here. To
configure SAP Exchange Infrastructure authentication, follow these steps:
1. In the Project Explorer view, double-click the Deployment Descriptor of the
ITSOWAS2SAPXI_WS project to open it in the editor as shown in
Figure 6-91.
Figure 6-91 Open the deployment descriptor
2. In the editor, switch to the WS Binding tab as shown in Figure 6-92.
Figure 6-92 Switch to the WS Binding tab
399
3. In the Port Qualified Name Binding Details section, enter itsouser in the User
ID field and itso01 in the Password field as shown in Figure 6-93.
Figure 6-93 Set the HTTP Basic authentication credentials
4. Save the changes to the deployment descriptor by pressing Ctrl+S and then
close the editor.
400
Building the application

To build the application, follow these steps:
1. From the drop-down menus, select Project Clean as shown in
Figure 6-94.
Figure 6-94 Clean the workspace
2. From the clean options windows, make sure that Clean all projects and
Start a build immediately are selected. Click OK to start the cleaning and
building process as shown in Figure 6-95.
Figure 6-95 Set cleaning properties
401
6.5.3 Testing
This section illustrates the execution and test of the created project in a
WebSphere Application Server environment.
1. In the Servers view, select WebSphere Application Server v6.0 and click
Start on the toolbar as shown in Figure 6-96.
Figure 6-96 Start the WebSphere Application Server test environment
2. Verify the successful start-up of the server by switching to the Console view
and making sure that it includes following log entry.
WSVR0001I: Server server1 open for e-business
3. In the Servers view, right-click WebSphere Application Server v6.0 and
select Add and remove projects as shown in Figure 6-97.
Figure 6-97 Add the project to the server
402
4. From the project selection window, select the ITSOWAS2SAPXI_WSEAR

application from the available projects and click Add to move the application
to the right side (Figure 6-98). Then, click Finish.
Figure 6-98 Select the projects to add
5. Open a Web browser and navigate to the following Web address:

http://localhost:9080/ITSOWAS2SAPXI_WS/index.jsp
Note: The Web address that you use might be different if the WebSphere
Application Server 6 Test Environment has been configured to use some
other port than the assumed default port (9080).
403
6. In the browser, type itsouser to the Username field and click Submit. The
application returns with a response message User ITSOUSER exists as
Figure 6-99 Test the application
6.5.4 Conclusion
This scenario demonstrates how you can use the WebSphere Application Server
to consume a Web Service from the SAP Exchange Infrastructure. From the
WebSphere side, the implementation of the integration follows the standard
steps of generating a Web Service client from an externally-provided WSDL
interface. As in scenario A, enabling HTTP basic authentication requires some
extra configuration work. From the SAP perspective, using WebSphere
Application Server as a client is transparent to the service provider.
6.6 Scenario C: SAP Exchange Infrastructure

consuming Web Service from WebSphere
In this scenario the WebSphere Enterprise Service Bus is configured to expose
the functionality of a simple Java component as a Web Service using a mediation
module. This Java component provides a functionality to retrieve a list of the
users of an imaginary system. In the SAP side, SAP Exchange Infrastructure is
configured to act as a Web Service client and mediate the requests that
originated from the SAP ERP back-end system to WebSphere Enterprise
Service Bus.
404

Figure 6-100 illustrates the operational model of this scenario.
SAP ERP 5.0
SAP Exchange

Java Component
UserListService_JavaImpl
BAPI_USER_GETLIST
RFC
SOAP/
Mediation Module
HTTP
ITSOSAPXI2ESB_WS
Figure 6-100 The operational model of the scenario
6.6.2 Development
This section describes the required development steps for building the mediation
module and the Java component for the WebSphere Enterprise Service Bus.
Common preparation procedures include:
1. Starting the WebSphere Integration Developer.
2. Changing to Business Integration Perspective if you currently have some
other perspective open.
3. If automatic building is currently enabled, disabling it. We describe this
procedure in detail in Common preparation procedures on page 332.
405
Creating the mediation module

To create the mediation module, follow these steps:
1. In the Business Integration View, right-click in the empty area and select
New Mediation Module as shown in Figure 6-101.
Figure 6-101 Create the Mediation Module
406
2. In the windows that opens, set the properties of the Mediation Module as
follows (Figure 6-102):
a. Enter ITSOSAPXI2ESB_WS in the Module name field.
b. Use the default location for the module.
c. Make sure that WebSphere ESB Server v6.0 is selected as target
runtime.
d. Select Create mediation flow component.
e. Click Finish to create the Mediation Module.
Figure 6-102 Set properties for the Mediation Module
407
Creating the required Business Objects and interfaces

To create the required Business Objects and interfaces, follow these steps:
1. In the Business Integration View, right-click the Data Types node and select
New Business Object as shown in Figure 6-103.
Figure 6-103 Create a new Business Object
408
2. In the Business Object properties window, set the properties as follows (Refer
to Figure 6-104):
a. Leave the Module field set at ITSOSAPXI2ESB_WS.
b. Clear the default option in the Namespace field and enter
http://itso.ibm.com/sg247220 as value.
c. Leave the Folder field to empty.
d. Enter UserListRequestBO in the Name field.
e. Leave the Inherit from field set to <none>.
f. Click Finish to create the Business Object.
Figure 6-104 Set properties for the request Business Object
409
3. In the Business Object editor that opens, right-click the empty area and select
Add attribute as shown in Figure 6-105.
Figure 6-105 Add an attribute to the request Business Object
4. In the Properties View, set the attribute properties as follows (Figure 6-106):
a. Enter amount in the Name field.
b. Select int in the Type field.
c. Select Required.
Figure 6-106 Set properties for the amount attribute
410
5. Create an additional attribute in the UserListRequestBO Business Object and

set the properties as follows (Figure 6-107):
a. Enter includeNames in the Name field.
b. Set the Type field to boolean.
c. Select Required.
Figure 6-107 Set properties for the includeNames attribute
6. After adding the two attributes, the request Business Object looks as
illustrated in Figure 6-108.
Figure 6-108 The UserListRequestBO Business Object after adding the attributes
7. Save the changes by pressing Ctrl+S and then close the Business Object
editor.
411
8. Create a second business object and set the properties as listed in Table 6-4.
Table 6-4 Properties for the UserInfoBO Business Object
Module
ITSOSAPXI2ESB_WS
Namespace
Folder
Leave as empty
Name
UserInfoBO
Inherit from
<none>
Figure 6-109 Set the properties for the UserInfoBO Business Object
412
9. Using the Business Object editor, create attributes to the UserInfoBO

according to Table 6-5.
Table 6-5 Attributes of the UserInfoBO Business Object
Name
Type
Required
username
string
yes
firstName
string
no
lastName
string
no
fullName
string
no
After adding the four attributes, the UserInfoBO looks as illustrated in the
Figure 6-110.
Figure 6-110 The UserInfoBO Business Object after adding the attributes
10.Save the Business Object by pressing Ctrl+S and then close the Business
Object editor.
413
11.Create a third business object and set the properties as listed in Table 6-6.
Table 6-6 Properties for the UserListResponseBO Business Object
Module
ITSOSAPXI2ESB_WS
Namespace
Folder
Leave as empty
Name
UserListResponseBO
Inherit from
<none>
Figure 6-111 Create the UserListResposeBO Business Object
414
12.Add an attribute to the UserListResponseBO and in the Properties View set

the properties as follows (Figure 6-112):
a. Enter userList in the Name field.
b. Set the Type field to UserInfoBO.
c. Leave the Required field clear.
d. Select Array.
Figure 6-112 Create the userList attribute to the response Business Object
13.Save the changes to the Business Object and then close the editor.
415
14.In the Business Integration View, right-click the Interfaces node and select
New Interface as shown in Figure 6-113.
416
15.In the window that opens, set the Interface properties as follows
(Figure 6-114):
a. Make sure that the Module field is set to ITSOSAPXI2ESB_WS.
b. Clear the default option in the Namespace field and set it to
http://itso.ibm.com/sg247220.
c. Leave the Folder field as empty.
d. Type UserListIF in the Name field.
Figure 6-114 Set the properties of the UserListIF interface
417
16.In the Interface Editor that opens, right-click the empty area and select Add
Request-Response Operation as shown in Figure 6-115.
Figure 6-115 Add an operation to the UserListIF interface
17.Enter getUserList as the name of the operation.

18.Right-click the getUserList operation and select Add Input as shown in
Figure 6-116.
Figure 6-116 Add an input to the operation
418
19.In the Properties View, enter request in the name field and set the type field
to UserListRequestBO.
20.In the Interface Editor, right-click the getUserList operation again and select
Add Output.
21.In the Properties View, enter response in the name field and set the type field
to UserListResponseBO (Figure 6-117).
Figure 6-117 The getUserList operation after adding input and output parameters
22.Save the interface by clicking Ctrl+S and then close the Interface Editor.
419
Assembling the mediation module

To assemble the mediation module, follow these steps:
1. Double-click the ITSOSAPXI2ESB_WS assemble diagram in the Business
Integration View to open it in the Assembly Editor.
2. Select the Mediation1 component in the Assembly editor by clicking it and
rename it to UserList_MediationFlow in the Properties View as shown in
Figure 6-118.
Figure 6-118 Rename the Mediation Flow component
420
3. Right-click the UserList_MediationFlow component in the Assembly Editor

and select Add Interface as shown in Figure 6-119.
Figure 6-119 Add an interface to the Mediation Flow component
421
4. From the list of interfaces, select UserListIF and click OK as shown in

Figure 6-120.
Figure 6-120 Select the interface to add to the Mediation Flow component
422
Creating the Java component

This phase of the implementation includes the creation of the Java component,
which provides a actual business service for the Mediation Module. To create the
Java component, follow these steps:
1. In the Assembly Editor, select the Java component from the palette and place
it on the diagram as shown in Figure 6-121.
Figure 6-121 Select Java component from the palette
423
2. Select the Java component in the Assembly Editor and rename it to

UserListService_Java as shown in Figure 6-122.
Figure 6-122 Rename the Java component
424
3. Right-click the UserListService_Java component and select Add

Interface. From the list of interfaces, select UserListIF and click OK as
Figure 6-123 Select interface for the UserListService_Java component
425
4. Right-click the UserListService_Java component and select Generate

Implementation as shown in Figure 6-124.
Figure 6-124 Generate implementation for the Java component
a. In the window that opens, select New Package to create a new Java
package for the class file as shown in Figure 6-125.
Figure 6-125 Create a new package for the class file
426
b. Enter com.ibm.itso.sg247220 as the package name and click OK as

Figure 6-126 Select name for the new package
c. Select com.ibm.itso.sg247220 from the package list and click OK as

Figure 6-127 Select package for the class file
427
5. After generating the implementation, the WebSphere Integration Developer

opens the skeleton implementation, named as UserListService_JavaImpl, in
the Java Editor. Replace the implementation of the getUserList method with
the code that is listed in Example 6-3.
Example 6-3 Implement the getUserList method
public DataObject getUserList(DataObject request) {

// Get request parameters
int amount = request.getInt("amount");
boolean includeNames = request.getBoolean("includeNames");
ServiceManager serviceManager = ServiceManager.INSTANCE;
serviceManager.locateService(
"com/ibm/websphere/bo/BOFactory");
List userList = new ArrayList();
for (int i = 0; i < amount; i++) {
DataObject userInfo =
"UserInfoBO");
userInfo.setString("username", "username" + i);
if (includeNames) {
userInfo.setString("firstName", "John" + i);
userInfo.setString("lastName", "Doe" + i);
userInfo.setString("fullName", "John" + i + " Doe" + i);
}
userList.add(userInfo);
}
DataObject response =
"UserListResponseBO");
response.setList("userList", userList);
return response;
}
You can find the complete source code of the Java class in Appendix A,
Additional material on page 1441.
6. Save the changes in the Java class by pressing Ctrl+S and then close the
editor.
428
Wiring the components

To wire the components, follow these steps:
1. In the Assembly Editor, select the Wire tool from the palette and create a wire
from the UserList_MediationFlow component to the UserListService_Java
component. If prompted, select OK to create a matching reference on the
source component as shown in Figure 6-128.
Figure 6-128 Create a wire from Mediation Flow to Java component
Implementing the mediation flow

To implement the mediation flow, follow these steps:
1. In the Assembly Editor, double-click the UserList_MediationFlow component
and select Yes to generate the implementation.
2. In the window that opens, select ITSOSAPXI2ESB_WS as the target folder
for the implementation and click OK as shown in Figure 6-129. This action
opens the Mediation Flow Editor.
Figure 6-129 Select folder the Mediation Flow implementation
429
3. In the Operations connection section (upper section) of the editor, create a

connection from the UserListIF / getUserList operation to the
UserListIFPartner / getUserList operation (Figure 6-130).
Figure 6-130 Connect the operations
4. In the Flow section of the editor, create a connection from the out terminal of
the Request node to the in terminal of the Invoke node (Figure 6-131).
Figure 6-131 Implement the request flow
5. In the editor, switch to the Response flow (Figure 6-132).
Figure 6-132 Switch to the response flow
430
6. In the Response flow, create a connection from the out terminal of the Callout
Response node to the in terminal of the Input Response node (Figure 6-133).
Figure 6-133 Implement the response flow
7. Save the Mediation Flow component by clicking Ctrl+S and then close the
Mediation Flow Editor.
Creating the Web Service export

To create the Web Service export, follow these steps:
1. In the Assembly Editor, right-click the UserList_MediationFlow component
and select Generate Export Web Service Binding as shown in
Figure 6-134.
Figure 6-134 Generate a Web Service export
431
2. When prompted, select Yes to generate a WSDL file that includes the port
and binding information as shown in Figure 6-135.
Figure 6-135 Generate the WSDL file of the export
3. Select soap/http as a transport protocol for the Web Service binding as

Figure 6-136 Select transport protocol
4. Save the Assembly Diagram by pressing Ctrl+S and then close the Assembly
Editor.
Building the mediation module

To build the mediation module, from the drop-down menu, select Project
Clean. In the pop-up window, select Clean all projects and make sure that Start
a build immediately is selected, and then click OK.
432
6.6.3 Testing
WebSphere Enterprise Service Bus environment.
Setting up the WebSphere Enterprise Service Bus

To set up the WebSphere Enterprise Service Bus, follow these steps:
1. From the Servers view, select the WebSphere ESB Server v6.0 runtime and
click the Start icon as shown in Figure 6-137.
Figure 6-137 Start the WebSphere ESB
2. When the server has started, make sure that the Console view includes the
following log entry.
3. Right-click the WebSphere ESB Server v6.0 runtime and select Add and
remove Projects as shown in Figure 6-138.
Figure 6-138 Add the project to the server
433
4. From the project selection window, move the ITSOSAPXI2ESB_WSApp

application to the right side by selecting and clicking Add. Then, click Finish
to deploy the application as shown in Figure 6-139.
Figure 6-139 Select projects to add
5. Verify the successful deployment of the application by switching to the

Console view and verifying that it includes following log entry.
WSVR0221I: Application started: ITSOSAPXI2ESB_WSApp
Invoking the service from SAPGUI

To invoke the service from SAPGUI, follow these steps:
1. Open the SAPGUI client and logon to the SAP ERP system.
2. Open the Function Builder from the SAP menu.
434
3. In the Function Builder: Initial Screen view, enter BAPI_USER_GETLIST in the

Function Module field and click Test/Execute as shown in Figure 6-140.
Figure 6-140 Select the function module
435
4. In the Test Function Module: Initial Screen view, set the fields as follows
(Figure 6-141):
a. Enter ITSO_XI_TO_ESB in the RFC target sys field.
b. Enter 3 in the MAX_ROWS field.
c. Enter X in the WITH_USERNAME field.
Figure 6-141 Set properties for the function call
5. Click Execute to execute the function call and to open the result view.
436
6. In the Test Function Module: Result Screen view, click the button located in
left side of the 3 Entries column of the USERLIST Result row. This action
opens the USERLIST result set as shown in Figure 6-142.
Figure 6-142 The results of the function call
437
7. Double-click the USERLIST result entries to open the details of this structure.
Figure 6-143 The contents of the USERLIST result set
6.7 Conclusion
This scenario demonstrates how you can use SAP Exchange Infrastructure to
consume a Web Service from the WebSphere Enterprise Service Bus. In the
WebSphere side, the implementation of the scenario follows the standard path of
developing a mediation module and creating a Web Service export for the client
(here SAP Exchange InfrastructureI). In this example, the actual service provider
(Java component) used the same interface as the export, so no data mapping in
the WebSphere side were required. In the SAP Exchange Infrastructure side, the
implementation of the example requires the creation of inbound scenario, which
maps the interface that is used by the BAPI component to the interface that is
provided by WebSphere Enterprise Service Bus.
6.8 Extension A: WebSphere Process Server

Infrastructure
In this section, we extend the solution from scenario A by using the WebSphere
Process Server. The SAP Exchange Infrastructure configuration is unchanged
as in the original implementation. The functionality of BAPI_USER_EXISTENCE
is used to check the existence of some specified user. In the WebSphere side,
we reuse the mediation module that is built in to the original implementation by
building a simple business process on top of it.
438

Figure 6-144 depicts the operational model of the extension.

6.0.1.0
Test Client
SAP Exchange
Module
SAP ERP 5.0
ITSOWPS2SAPXI_WS
Module
SOAP/
ITSOESB2SAPXI_WS
HTTP
RFC
Figure 6-144 The operational model of the extension
6.8.2 Development
This section describes the required development steps for implementing the
ITSOWPS2SAPXI_WS module.
Common preparation procedures

The common preparation procedure includes starting the WebSphere Integration
Developer and opening the workspace that is used for scenario A. The
workspace for scenario A includes the ITSOESB2SAPXI_WS mediation module
and ITSOSAPXI_WS_Lib library.
439
Reorganizing resources
Because some of the interfaces and Business Objects that are required by the
extension are currently located in the mediation module, you have to move them
to the library to expose them. To reorganize resources, follow these steps:
1. In the Business Integration View, while pressing Ctrl, select
UserExistenceRequestBO, UserExistenceResponseBO from Business
Objects and UserExistenceIF from interfaces. Then, right-click and select
Refactor Move as shown in Figure 6-145.
Figure 6-145 Move the files
440
2. Select ITSOSAPXI_WS_Lib as a target folder and click Preview to preview

the changes as shown in Figure 6-146.
Figure 6-146 Select the target folder
3. In the preview window, click OK to move the files as shown in Figure 6-147.
Figure 6-147 Preview the changes caused by moving the files
441
Creating an SCA export

To invoke the mediation module from another SCA module, you need to create
an SCA export. Follow these steps:
1. In the Business Integration View, double-click the Assembly Diagram of the
ITSOESB2SAPXI_WS Mediation Module to open it in the editor as shown in
Figure 6-148.
Figure 6-148 Open the Assembly Diagram
2. In the Assembly Editor, right-click the UserExistence_MediationFlow

component and select Generate Export SCA binding as shown in
Figure 6-149.
Figure 6-149 Generate SCA export
442
3. After generating the export, the WebSphere Integration Developer adds it to

the Assembly Diagram as shown in Figure 6-150.
Figure 6-150 Assembly Diagram with the SCA export
4. Save the Assembly Diagram by pressing Ctrl+S and then close the editor.
Creating a new module

To create a new module, follow these steps:
1. In the Business Integration View, right-click in the empty area and select
New Module as shown in Figure 6-151.
Figure 6-151 Create a new module
443
2. In the module properties window, enter ITSOWPS2SAPXI_WS in the Name field

and leave the Default field selected for the module location. Then, click
Finish to create the module as shown in Figure 6-152.
Figure 6-152 Set properties for the module
3. After creating the module, right-click the module that you just created in the
Business Integration View and select Open Dependency Editor as shown in
Figure 6-153.
Figure 6-153 Open the Dependency Editor
444
4. In the Libraries section of the Dependency Editor, click Add as shown in

Figure 6-154.
Figure 6-154 Add a library reference
5. In the selection window, select ITSOSAPXI_WS_Lib and click OK as shown

in Figure 6-155.
Figure 6-155 Select the library to add
445
6. Save the changes made to the Dependency Editor by pressing Ctrl+S and
then close the editor.
Creating the Business Process

To create the Business Process, follow these steps:
ITSOWPS2SAPXI_WS module to open it.
2. In the Assembly Editor, select the Process component from the palette and
place it on the diagram as shown in Figure 6-156.
Figure 6-156 Select the process component from the palette
3. Rename the process component to UserExistence_Process as shown in

Figure 6-157.
Figure 6-157 The renamed process component
4. Select the process component and click Add interface as shown in

Figure 6-158.
Figure 6-158 Add an interface to the component
446
5. From the list of interfaces, select UserExistenceIF and click OK as shown in

Figure 6-159.
Figure 6-159 Select the interface to add
6. In the Assembly Editor, select the process component and click Add
Reference as shown in Figure 6-160.
Figure 6-160 Add a reference to a component
7. From the list of interfaces, select UserExistenceIF again and click OK.
447
8. Right-click the UserExistence_Process component and select Generate

Figure 6-161 Generate the implementation for the process component
9. Select the ITSOWPS2SAPXI_WS folder and click OK to generate the

implementation as shown in Figure 6-162.
Figure 6-162 Select folder for the implementation
448
10.In the Business Process Editor, select the Invoke node from the palette and
place it between the Receive and Reply nodes as shown in Figure 6-163.
Figure 6-163 Select the Invoke node from the palette
11.Rename the Invoke node to Invoke SAP_XI as shown in Figure 6-164.
Figure 6-164 The Business Process after renaming
449
12.Select the Invoke SAP_XI node, and switch to the Details tab of the
Properties View. Click the Browse button as shown in Figure 6-165.
Figure 6-165 Browse for partners for the invoke node
13.Select UserExistenceIFPartner from the list and click OK as shown in

Figure 6-166.
Figure 6-166 Select the partner for the invoke node
450
14.In the Details tab, click the button located in right side of the request input
parameter as shown in Figure 6-167.
Figure 6-167 Define the input parameter for the invoke node
451
15.Select the Request variable from the list and click OK as shown in
Figure 6-168.
Figure 6-168 Select variable for the input parameter
16.In the Details tab, click the button located on the right side of the response
output parameter.
17.Select the Response variable from the list and click OK.
452
18.After defining the input and output parameters for the invoke node, the Details
tab looks as illustrated in Figure 6-169.
Figure 6-169 The details of the invoke node after setting the parameters
19.Save the changes to the process by pressing Ctrl+S and then close the
Business Process Editor.
Assembling the module

To assemble the module, follow these steps:
1. In the Assembly Editor, select the Import tool from the palette and place it on
the diagram as shown in Figure 6-170.
Figure 6-170 Select the import tool from the palette
2. Rename Import1 to UserExistenceMediation_Import as shown in

Figure 6-171.
Figure 6-171 The Assembly Diagram after renaming the import
453
3. Click the Add Interface icon above the import and select the UserExistenceIF
interface from the list. Then, click OK.
4. Right-click UserExistenceMediation_Import and select Generate
Binding SCA Binding as shown in Figure 6-172.
Figure 6-172 Generate the binding for the import
5. Select UserExistenceMediation_Import and switch to the Binding tab of the

Properties View. Click Browse as shown in Figure 6-173.
Figure 6-173 Browse for exports for the import
454
6. From the list of available SCA exports, select

UserExistence_MediationFlowExport and click OK as shown in
Figure 6-174.
Figure 6-174 Select the SCA export
7. Using the wiring tool from the palette, create a wire from
UserExistence_Process to UserExistenceMediation_Import as shown in
Figure 6-175.
Figure 6-175 Create a wire from the process component to the import node
8. Save the Assembly Diagram by pressing Ctrl+S and then close the editor.
455
Building the module

To build the module, select Build All from the Project menu to build the
workspace as shown in Figure 6-176.
Figure 6-176 Build the module
Verifying Web Service client authentication configuration

As mentioned previously, the cleaning and rebuilding of the workspace overrides
the previously configured authentication settings for the Web Service client. You
can use the instructions from Configuring SAP Exchange Infrastructure
authentication on page 369 to verify that the HTTP basic authentication for
BapiUserExistenceCheck is in place.
6.8.3 Testing
WebSphere Process Server environment.
1. In the Servers view, select the WebSphere Process Server v6.0 runtime and
click the Start icon as shown in Figure 6-177.
Figure 6-177 Start the WebSphere Process Server Test Environment
2. Verify the successful startup of the server by switching to the Console View
and making sure that in includes following log entry.
456
3. Right-click the WebSphere Process Server v6.0 runtime and select Add and
Remove projects as shown in Figure 6-178.
Figure 6-178 Add and removing projects to the server
457
4. In the project selection window, click Add All to move both applications to the
right side. Then, click Finish to deploy the applications as shown in
Figure 6-179.
Figure 6-179 Select projects to deploy
458
5. In the Business Integration View, right-click the ITSOWPS2SAPXI_WS

module and select Test Test Module as shown in Figure 6-180.
Figure 6-180 Start the Test Client
459
6. In the Test Client, set the properties and parameters as follows

(Figure 6-181):
a. Select ITSOWPS2SAPXI_WS in the Module field.
b. Select UserExistence_Process in the Component field.
c. Make sure that UserExistenceIF is selected in the Interface field.
d. Make sure that checkUserExistence is selected in the Operation field.
e. Enter itsouser in the Value column of the username Input Parameter.
Figure 6-181 Configure the Test Client
7. Click Continue to run the test. If prompted, select WebSphere Process

Server v6.0 runtime as a target server for the Test Client.
460
8. After invoking the component, the Test Client displays the message return
parameter with value User ITSOUSER exists as shown in Figure 6-182.
Figure 6-182 The return parameters of the test
6.8.4 Conclusion
This extension demonstrates how you can use the WebSphere Process Server
to consume a Web Service from the SAP Exchange Infrastructure.
From the SAP Exchange Infrastructure perspective, the configuration does not
care whether the consuming client is WebSphere Enterprise Service Bus or
WebSphere Process Server. Also, in the WebSphere side, creating the Web
Service import from a WSDL file is similar both in standard modules as well as in
Mediation Modules. For demonstration purposes, this extension scenario
combines both types of modules. It is a combination of SCA imports and exports.
However, the Web Service call can be also made directly from the business
process (or from any other WebSphere Process Server specific component)
without the usage of a Mediation Module.
6.9 Extension B: SAP Exchange Infrastructure

consuming Web Service from WebSphere Process
Server
In this extension, the solution from scenario C uses the WebSphere Process
Server. The SAP Exchange Infrastructure configuration is unchanged as in the
original implementation. The SAP ERP back-end system makes a RFC call to
SAP Exchange Infrastructure, which mediates the request to the WebSphere
Process Server. In the WebSphere side, we reuse the Mediation Module that is
built in to the original implementation by building a simple business process on
top of it.
461

Figure 6-183 depicts the operational model of the extension.

6.0.1.0
Java Component
UserListService_JavaImpl
SAP ERP 5.0
SAP Exchange
Module
ITSOSAPXI2WPS_WS
BAPI_USER_GETLIST
RFC
SOAP/
Mediation Module
HTTP
ITSOSAPXI2ESB_WS
Figure 6-183 The operational model of the extension
6.9.2 Development
This section describes how to modify the ITSOSAPXI2ESB_WS Mediation
Module and how to implement the ITSOSAPXI2WPS_WS module.
Common preparations procedures

Start the WebSphere Integration Developer and switch to the workspace that you
used to implement scenario C. The workspace must include the
ITSOSAPXI2ESB_WS Mediation Module.
462
Reorganizing the resources

Because some of the resources (interfaces and Business Objects) that we use in
this extension are referenced by two different modules, you must reorganize
them into a library. To reorganize the resources, follow these steps:
1. In the Business Integration View, right-click the empty area and select New
Library as shown in Figure 6-184.
Figure 6-184 Create a new library
463
2. In the window that opens, enter ITSOSAPXI_WS_Lib in the Library name field
and use the default location for library as shown in Figure 6-185.
Figure 6-185 Set library properties
3. In the Business Integration View, right-click the ITSOSAPXI2ESB_WS

Mediation Module and select Open Dependency Editor as shown in
Figure 6-186.
Figure 6-186 Open the Dependency Editor
464
4. In the Dependency Editor, using the Add button add the ITSOSAPXI_WS_Lib
library to the list of required libraries and verify that the Deploy with Module
option is selected as shown in Figure 6-187.
Figure 6-187 Add the required library
5. Save the changes by pressing Ctrl+S and then close the Dependency Editor.
465
6. In the Business Integration View, select the following from the

ITSOSAPXI2ESB_WS Mediation Module.
UserInfoBO Business Object

UserListRequestBO Business Object
UserListResponseBO Business Object
UserListIF interface
Then, right-click and select Refactor Move (Figure 6-188).
Figure 6-188 Move the resources
466
7. Select ITSOSAPXI_WS_Lib library as the target folder and click Preview to

preview the changes as shown in Figure 6-189.
Figure 6-189 Select the target folder for the resources
8. In the preview window, click OK to move the resources as shown in

Figure 6-190.
Figure 6-190 Preview the changes
467
Refactoring the Mediation Module

To refactor the Mediation Module, follow these steps:
ITSOSAPXI2ESB_WS Mediation Module to open it in the Assembly Editor.
2. In the Assembly Editor, right-click the UserListServer_Java component and
select Delete as shown in Figure 6-191.
Figure 6-191 Delete the Java component
3. Select the Import node from palette and place it on the diagram. Rename it to
UserListProcess_Import as shown in Figure 6-192.
Figure 6-192 Create and rename the import
468
4. Using the Wiring tool from the palette, create a wire from the
UserList_MediationFlow component to the UserListProcess_Import. If
prompted, click OK to create a matching interface on the target node as
Figure 6-193 Create a wire from the mediation flow to the import
5. Save the changes by pressing Ctrl+S and then close the Assembly Editor.
Creating a new module

To create a new module, follow these steps:
1. In the Business Integration View, right-click the empty area and select New
Module as shown in Figure 6-194.
469
2. In the Module properties window, enter ITSOSAPXI2WPS_WS in the Module

name field and leave Use default selected for the module location as shown
in Figure 6-195.
3. Click Finish to create the module.
Figure 6-195 Set module properties
4. In the Business Integration View, right-click the ITSOSAPXI2WPS_WS

module and select Open Dependency Editor.
470
5. In the Depedency Editor, use the Add button to add the ITSOSAPXI_WS_Lib
library to the list of required libraries. Make sure that the Deploy with Module
option is selected as shown in Figure 6-196.
Figure 6-196 Add depedency to the library
6. Save the changes by pressing Ctrl+S and then close the Dependency Editor.
Creating the business process

To create the business process, follow these steps:
ITSOSAPXI2WPS_WS to open it.
2. Select the Process node from the palette and place it on the diagram.
Rename it to UserList_Process as shown in Figure 6-197.
Figure 6-197 The process component after renaming
3. Select the process component and click Add Interface as shown in

Figure 6-198.
Figure 6-198 Add an interface to the process component
471
4. Select the UserListIF interface from the list and click OK as shown in
Figure 6-199.
Figure 6-199 Select the interface for the process component
5. Select the process component and click Add Reference.

6. Select the UserListIF interface from the list and click OK.
472
7. Double-click the process component and click Yes to generate the

implementation. In the window that opens, select ITSOSAPXI2WPS_WS as a
target folder for the implementation and click OK as shown in Figure 6-200.
8. In the Business Process Editor, select the Invoke node from the palette and
place it between the Receive and Reply nodes as shown in Figure 6-201.
Figure 6-201 Select the invoke node from the palette
473
9. Rename the Invoke node to Invoke Java as shown in Figure 6-202.
Figure 6-202 Rename the invoke node
10.Select the Invoke Java node and switch to the Details tab of the Properties
View. Click Browse as shown in Figure 6-203.
Figure 6-203 Set properties for the invoke node
474
11.Select the UserListIFPartner from the list and click OK as shown in

Figure 6-204.
Figure 6-204 Select the partner for the invoke node
475
12.In the Details tab of the Properties View, click the button which is located in
the right side of the request input parameter as shown in Figure 6-205.
Figure 6-205 Define the variable for the request input parameter
476
13.Select the Request variable from the list and click OK as shown in
Figure 6-206.
Figure 6-206 Select the variable for the input parameter
14.n the Details tab of the Properties View, click the button which is located in
the right side of the response input parameter.
15.Select Response for the response output parameter.
16.Save the business process by pressing Ctrl+S and then close the Business
Process Editor.
17.Save the Assembly Diagram by pressing Ctrl+S.
477
Creating the Java component

In this phase of the development a new Java component is created to the
ITSOSAPXI2WPS_WS module. This component reuses the implementing class
from the scenario C, which is simply moved from the ITSOSAPXI2ESB_WS
module in order to make it accessible. To create the Java component, follow
these steps:
1. Switch to the Java perspective as shown in Figure 6-207.
Figure 6-207 Switch to the Java perspective
2. In the Project Explorer View, right-click the ITSOSAPXI2WPS_WS module

and select New Package as shown in Figure 6-208.
Figure 6-208 Create a new package
478
3. In the window that opens, enter com.ibm.itso.sg247220 in the Name field and
click Finish to create the Java package as shown in Figure 6-209.
Figure 6-209 Define a name for the new package
4. From the Package Explorer View, right-click the UserListService_JavaImpl

class and select Refactor Move as shown in Figure 6-210.
Figure 6-210 Move the Java class
479
5. In the window that opens select

ITSOSAPXI2WPS_WS/com.ibm.itso.sg247220 as a target folder for the
Java class as shown in Figure 6-211.
Figure 6-211 Select target folder for the Java class
6. Switch to the Business Integration Perspective.
480
7. Select the Java component from the palette and place it on the diagram as
Figure 6-212 Select the Java component from the palette
8. Rename the Java component to UserListService_Java as shown in

Figure 6-213.
Figure 6-213 Rename the Java component
481
9. Select the UserListService_Java component and click Add Interface. Select

the UserListIF interface from the list and click OK.
10.Right-click the UserListService_Java component and click Select
Figure 6-214 Select implementation for the Java component
482
11.In the window that opens, enter UserListService_JavaImpl in the Name field
and click OK as shown in Figure 6-215.
Figure 6-215 Select the implementing Java class
Assembling the module

To assemble the module, follow these steps:
1. In the Business Integration View, select the wiring tool and create a wire from
the UserListProcess component to the UserListService_Java component as
Figure 6-216 Create a wire from the process component to the Java component
483
2. Right-click the UserList_Process component and select Generate Export

SCA Binding as shown in Figure 6-217.
Figure 6-217 Generate an SCA export from the process component
Figure 6-218 shows the assembly diagram after you generate the export.
Figure 6-218 The assembly diagram after generating the export
3. Save the Assembly Diagram diagram by pressing Ctrl+S.
484
Generating the binding for the SCA import

To generate the binding for the SCA import, follow these steps:
ITSOSAPXI2ESB_WS module in order to open it as shown in Figure 6-219.
Figure 6-219 Open the Assembly Diagram of the Mediation Module
2. In the Assembly Editor, right-click the UserListProcess_Import and select

Generate Binding SCA Binding as shown in Figure 6-220.
Figure 6-220 Generate the binding for the import
485
3. Select the UserListProcess_Import node and switch to the Binding tab of the
Properties View. Click Browse as shown in Figure 6-221.
Figure 6-221 Browse the exports
4. From the SCA Export Selection list select the UserList_ProcessExport and
click OK as shown in Figure 6-222.
Figure 6-222 Select the SCA export
5. Save the changes by pressing Ctrl+S and then close the Assembly Editor.
486
Building the modules

To build the modules, follow these steps:
1. From the drop-down menus, select Project Clean.
2. From the cleaning options, select Clean all projects and make sure that
Start a build immediately is checked. Finally click OK to start the cleaning
and building process.
6.9.3 Testing
This section demonstrates how to test the extension.
Preparing WebSphere Process Server

Before you can invoke the function from the SAP back-end system, you must
start the WebSphere Process Server and deploy the new modules. Follow these
steps:
1. In WebSphere Integration Developer, switch to the Servers view.
2. Select the WebSphere Process Server v6.0 runtime and click Start.
3. Verify the successful startup of the server by switching to the Console View
and making sure that in includes following log entry.
4. Right-click the WebSphere Process Server v6.0 runtime and select Add and
Remove projects as shown in Figure 6-223.
Figure 6-223 Add and remove projects to the server
487
5. In the project selection window, click Add All to move both applications to the
right side. Then, click Finish to deploy the applications as shown in
Figure 6-224.
Figure 6-224 Select projects for deployment
488
6. Verify the successful deployment of the modules by switching to the Console

view and checking that it includes the following log entry.
WSVR0221I: Application started: ITSOSAPXI2WPS_WSApp
Note: If when you verify the deployment, you receive the validation error
shown in Example 6-4, read the instructions that follow the example to correct
the error.
Example 6-4 Process validation error
[9/21/06 17:50:04:094 CEST] 000000a1 BpelEngine

E
CWWBV0003E: Validated process
model 'UserList_Process' with findings: 4 errors, 0 warnings, 0 information:
CWWBV3187E: The XSD type definition 'UserListRequestBO' was not found (activity
'InvokeJava', parameter 1, matching part or element 'request').
CWWBV3187E: The XSD type definition 'UserListResponseBO' was not found (activity
'InvokeJava', parameter 1, matching part or element 'response').
'Receive', parameter 1, matching part or element 'request').
'Reply', parameter 1, matching part or element 'response').
com.ibm.bpe.plugins.BPELValidationException:
CWWBV0003E: Validated process model 'UserList_Process' with findings: 4 errors, 0
warnings, 0 information:
'InvokeJava', parameter 1, matching part or element 'request').
'InvokeJava', parameter 1, matching part or element 'response').
'Receive', parameter 1, matching part or element 'request').
'Reply', parameter 1, matching part or element 'response').
at
com.ibm.bpe.validation.BPELValidation.writeProblemsToSystemOutWithException(BPELValid
ation.java:802)
at
com.ibm.bpe.validation.BPELValidation.validateExecutableBPELExtensionsProcess(BPELVal
idation.java:317)
at com.ibm.bpe.deployment.BPELDeployer.installBPEL(BPELDeployer.java:220)
at com.ibm.bpe.admin.AdminService.installProcessComponent(AdminService.java:221)
at
com.ibm.bpe.processarchive.SCDLProcessComponentInstallTask.performTask(SCDLProcessCom
ponentInstallTask.java:134)
at com.ibm.ws.management.application.SchedulerImpl.run(SchedulerImpl.java:253)
at java.lang.Thread.run(Thread.java:568)
489
The validation error shown in Example 6-4 is caused by a relative path reference
in the UserListIF.wsdl file. This relative path is generated by WebSphere
Integration Developer when the interfaces and Business Objects are been
moved from the Mediation Module to the library module. To correct this error,
follow these steps:
1. In the Java perspective, right-click the UserListIF.wsdl file and select Open
With WSDL Editor as shown in Figure 6-225.
Figure 6-225 Open the interface with WSDL editor
2. Switch to the Source view of the editor as shown in Figure 6-226.
Figure 6-226 Switch to the source view
490
3. If the WSDL file includes directives with relative paths to the XSD files as
shown in Example 6-5, remove the path from the schemaLocation attribute as
shown in Example 6-6.
Example 6-5 Include directives with relative paths
<xsd:include
schemaLocation="../ITSOSAPXI_WS_Lib/UserListResponseBO.xsd"/>
<xsd:include
schemaLocation="../ITSOSAPXI_WS_Lib/UserListRequestBO.xsd"/>
Example 6-6 Include directives without a path
<xsd:include schemaLocation="UserListResponseBO.xsd"/>
<xsd:include schemaLocation="UserListRequestBO.xsd"/>
4. Save the changes to the WSDL file and deploy the application again.
Invoking the service from SAPGUI

To invoke the service from SAPGUI, follow these steps:
1. Open the SAPGUI client and log on to the SAP ERP system.
2. Open the Function Builder from the SAP menu.
3. In the Function Builder: Initial Screen view, enter BAPI_USER_GETLIST in the
Function Module field and click Test/Execute as shown in Figure 6-227.
Figure 6-227 Select the function module
491
4. In the Test Function Module: Initial Screen view, set the fields as follows
(Figure 6-228):
a. Enter ITSO_XI_TO_ESB in the RFC target sys field.
b. Enter 3 in the MAX_ROWS field.
c. Enter X in the WITH_USERNAME field.
Figure 6-228 Set properties for the function call
5. Click Execute to execute the function call and to open the result view.
492
6. In the Test Function Module: Result Screen view, click the button located in
left side of the 3 Entries column of the USERLIST Result row. This opens the
USERLIST result set as shown in Figure 6-229.
Figure 6-229 The results of the function call
7. Double-click the USERLIST result entries to open the details of this structure.
Figure 6-230 The contents of the USERLIST result set
493
6.9.4 Conclusion
This extension demonstrates how you can use the SAP Exchange Infrastructure
to consume a Web Service from the WebSphere Process Server. From the SAP
Exchange Infrastructure perspective, the changing of runtime from WebSphere
Enterprise Service Bus to WebSphere Process Server is transparent because
the original Mediation Module is included in the extension as a mediating
component.
494
Chapter 7.
JMS-based integration
scenarios between
WebSphere Enterprise
Service Bus and SAP
Exchange Infrastructure
This chapter describes how to integrate WebSphere Enterprise Service Bus and
WebSphere Process Server with SAP Exchange Infrastructure using Java
Message Service technology. It covers different integration scenarios using SAP
Exchange Infrastructure both as a JMS provider and JMS consumer in
combination with WebSphere Enterprise Service Bus and WebSphere Process
Server. We discuss each scenario in detail by describing its architecture, the
required configuration, development steps, and testing.
Preparation on page 498.
495
Scenario A: WebSphere Enterprise Service Bus as a JMS consumer on

page 518
Scenario B: WebSphere Enterprise Service Bus as a JMS provider on
page 558
Extension A: WebSphere Process Server as a JMS consumer on page 625
Extension B: WebSphere Process Server as a JMS provider on page 649

Figure 7.1 is an overview of all installed systems and software.
ITSO_IBM_1
ITSO_SAP_2

V 6.0.1.2

3.0 SP 18

V 6.0.1.2

SE 1.4.2_11

V 6.0.1.2

V 9.2.0.1
WebSphere MQ 6,0
ITSO_SAP_3
5.0
V 8.2
Figure 7-1 System landscape
496
The environment includes one node for the WebSphere software (ITSO_IBM_1)
and two nodes for the SAP software (ITSO_SAP_2 and ITSO_SAP_3):
ITSO_IBM_1 node includes the WebSphere Enterprise Service Bus, the
WebSphere Process Server, and the WebSphere Integration Developer
toolkit.
ITSO_SAP_2 node includes the SAP Exchange Infrastructure and the related
tools and databases.
ITSO_SAP_3 node includes the SAP ERP back-end system and databases
of business applications.
Attention: This configuration is the setup that we use for this book. The
operating system and version number of products might be different in your
environment. Always apply the latest fix pack.

This chapter discusses several different scenarios between IBM WebSphere and
SAP Exchange Infrastructure using Java Message Service based integration.
In the different scenarios the actual WebSphere side product is varied between
WebSphere Enterprise Service Bus and WebSphere Process Server, and the
roles of the service producer and the service consumer are changed between
SAP Exchange Infrastructure and WebSphere.

as a JMS consumer
In this scenario, the WebSphere Enterprise Service Bus is configured as a JMS
client and the SAP Exchange Infrastructure as a JMS provider. The aim of this
scenario is to request from WebSphere Enterprise Service Bus information about
SAP user account using the SAP Exchange Infrastructure.
7.2.2 Scenario B: WebSphere Enterprise Service Bus as a

JMS provider
In this scenario theWebSphere Enterprise Service Bus is configured as a JMS
provider. The WebSphere Enterprise Service Bus provides the functionality of a
simple Java component which is triggered when a message is received in a JMS
queue.
Chapter 7. JMS-based integration scenarios between WebSphere Enterprise Service Bus and SAP Exchange Infrastructure
497
7.2.3 Extension A: WebSphere Process Server as a JMS consumer

In this scenario the solution from scenario A is extended by using the
Mediation Module built into the original implementation is reused by building a
7.2.4 Extension B: WebSphere Process Server as a JMS provider

In this scenario, the solution from scenario C is extended by using the
Java component, JMS export and custom selector built into the original
implementation are reused and linked to a simple business process on top of it.
7.3 Preparation
The scenarios access SAP Exchange Infrastructure using Java Message
Service. There are common preparation steps for all scenarios. You need to
install WebSphere MQ 6.0 software and configure a foreign bus in both
WebSphere Enterprise Service Bus and WebSphere Process Server. We do not
discuss how to install WebSphere Enterprise Service Bus, WebSphere Process
Server, WebSphere Integration Developer, and WebSphere MQ 6.0 in this book.
Check the product documentation if you do not have these products installed.
7.3.1 Configuring SAP Exchange Infrastructure

We describe the configuration of SAP Exchange Infrastructure for the scenarios
in this chapter in 5.7, Configuring the JMS outbound scenarios in SAP
Exchange Infrastructure on page 210 and in 5.8, Configuring the JMS inbound
scenarios in SAP XI on page 264.
498
7.3.2 Configuring WebSphere Enterprise Service Bus V6

You need to configure WebSphere Enterprise Service Bus and WebSphere
Process Server so that they can communicate with WebSphere MQ using a
foreign bus. You need to:
Create a foreign bus.
Configure a MQ link from WebSphere Enterprise Service Bus to WebSphere
MQ.
Configure WebSphere MQ, which allows the communication from
WebSphere MQ to WebSphere Enterprise Service Bus.
Creating the foreign bus

To create the foreign bus, follow these steps:
1. Start the WebSphere ESB Server.
a. From WebSphere Integration Developer select the Servers tab.
b. Select WebSphere ESB Server v6.0 server and right-click and select
Start.
2. Open the WebSphere ESB Server Administration Console. From the Servers
tab, right-click WebSphere ESB Server v6.0 and select Run Administration
Console.
3. In the Left navigation pane, select Service integration Buses
(Figure 7-2).
499
Figure 7-2 Administration console
4. Select the SCA.APPLICATION.esbCell.Bus instance (Figure 7-3).
Figure 7-3 List of service integration buses
500
5. Click Foreign buses under Topology as shown in Figure 7-4.
Figure 7-4 SCA.APPLICATION.esbCell.Bus configuration panel
6. Create a new Foreign Bus by clicking New (Figure 7-5).
Figure 7-5 Foreign bus creation
501
7. Enter Itso_ForeignBus as name of the new foreign bus and click Next as
Figure 7-6 Definition of the foreign bus name
8. Select Direct, WebSphere MQ link as a routing type as shown in

Figure 7-7and click Next.
Figure 7-7 Selection of the routing definition type
502
9. No user IDs are required (Figure 7-8). Click Next.
Figure 7-8 Routing definition properties
10.Click Finish as shown in Figure 7-9.
Figure 7-9 Summary
503
11.Click the Save link to apply the changes to the master configuration
(Figure 7-10).
Figure 7-10 Save the configuration of the foreign bus
12.Click Save to update the master repository with the changes as shown in
Figure 7-11.
Figure 7-11 Confirmation of changes
504
Creating and configuring the WebSphere MQ link

After you create the foreign bus, you need to create and configure the
WebSphere MQ link by following these steps:
1. Select the messaging engine from the WebSphere Enterprise Service Bus
administration console welcome page. Follow these steps:
a. Select Service integration bus Buses from the left pane.
b. Select SCA.APPLICATION.esbCell.Bus as shown in Figure 7-12.
Figure 7-12 List of service integration buses
505
c. Select the Messaging Engines link under Topology as shown in

Figure 7-13.
Figure 7-13 SCA.APPLICATION.esbCell.Bus general properties
506
d. In the next panel, select the default messaging engine,

esbNode.server1-SCA.APPLICATION.esbCell.Bus, as shown in
Figure 7-14.
Figure 7-14 List of messaging engines link to SCA.APPLICATION.esbCell.Bus
507
2. Create the WebSphere MQ links:

a. From the Messaging engine panel select WebSphere MQ links as shown
in Figure 7-15.
Figure 7-15 Messaging engine general properties
508
b. Click New to create a new WebSphere MQ link as shown in Figure 7-16.
Figure 7-16 List of WebSphere MQ links
c. Enter the data for the foreign bus name and the queue manager name
(Figure 7-17) as shown in Table 7-1. Then, click Next.
Table 7-1 WebSphere MQ link properties
Name
Itso_MQLink
Foreign bus name
Itso_ForeignBus
Queue manager name
Itso_ESBAppBus
The Queue manager name is the name of the virtual queue manager that
is associated with the messaging engine and by which the messaging
engine is known to a remote WebSphere MQ network.
509
Figure 7-17 WebSphere MQ link general properties
d. Enter or select the values shown in Table 7-2 to create the sender MQ
channel (Figure 7-18). Then, click Next.
Table 7-2 Sender channel properties
510
Sender MQ channel name
Itso_BusToMQ
Host name
localhost
Port
3414
Transport chain
OutboundBasicMQLink
Figure 7-18 Sender channel WebSphere MQ link properties
511
e. Enter the Receiver MQ channel name as shown in Figure 7-19. Then, click
Next.
Figure 7-19 Receiver channel WebSphere MQ link properties
f. Click Finish to complete the creation of the WebSphere MQ link as shown

in Figure 7-20.
Figure 7-20 Summary of WebSphere MQ link properties
512
g. Click the Save link to apply the changes to the master configuration
(Figure 7-21).
Figure 7-21 WebSphere MQ link
h. Click Save to update the master repository with the changes as shown in
Figure 7-22.
Figure 7-22 WebSphere MQ link confirmation
513
Configuring WebSphere MQ
To configure WebSphere MQ, follow these steps:
1. Define the queue manager:
a. In the WebSphere MQ Explorer, right-click the Queue Managers folder
and select New Queue Manager.
b. Enter ItsoQmgr2 in the Queue manager name entry, then click Next.
c. Accept the default settings and click Next.
d. Enter the value 3414 in the Listen on port number field and then click
Finish (Figure 7-23).
Note: Check whether the port 3414 is available by issuing the netstat -a
command. If the port is already in use, then select a different port and use
that port.
Figure 7-23 Queue manager listener port
514
2. Define a transmission queue (Figure 7-24):

a. In the WebSphere MQ Explorer, right-click the Queues folder and select
New Local Queue.
b. Enter Itso_XQESBAppBus as the name and click Next.
c. From the Usage pull-down list, select Transmission.
d. Click Finish.
Figure 7-24 Transmission queue completed attributes
515
3. Define a receiver channel.

a. In the WebSphere MQ Explorer, right-click the Channels folder and select
New Receiver Channel.
b. Enter Itso_BusToMQ as a Channel Name, the dialog box opens as shown
in Figure 7-25.
c. Click Finish.
Figure 7-25 Receiver channel name
4. Define a sender channel:

a. In the WebSphere MQ Explorer, right-click the Channels folder and select
New Sender Channel.
b. Enter Itso_MQToBus as Name and click Next.
c. Enter or select the values that are listed in Table 7-3 to create the sender
channel.
Table 7-3 Transmission queue properties
516
Transmission Protocol
TCP/IP
Connection Name
localhost(5559)
Transmission Queue
Itso_XQESBAppBus
The Connection Name attribute equals to

WebSphereESBServerHost(SIB_MQ_ENDPOINT_ADDRESS) where:
WebSphereESBServerHost is the host of the WebSphere Enterprise Service
Bus Server or WebSphere Process Server.
SIB_MQ_ENDPOINT_ADDRESS is the Service Integration Bus MQ Endpoint
port. The SIB_MQ_ENDPOINT_ADDRESS can be found in the list of ports that
are used by WebSphere Enterprise Service Bus and WebSphere Process
Server by selecting from the Administration Console. Follow these steps:
i. Open the WebSphere Administration Console.
ii. Select Servers Application servers server1 from the navigation
pane.
iii. Click the Ports link underneath Communication.The window now looks
similar to that shown in Figure 7-26, where
SIB_MQ_ENDPOINT_ADDRESS displays.
Figure 7-26 List of ports
Attention: The SIB_MQ_ENDPOINT_ADDRESS includes a different value in

both WebSphere Enterprise Service Bus and WebSphere Process Server.
Make sure to change the connection name, localhost(5558), with the correct
port when using WebSphere Process Server in scenario B and D.
517
d. The dialog box displays as shown in Figure 7-27. Click Finish.
Figure 7-27 Receiver channel properties

as a JMS consumer
This scenario describes how to integrate WebSphere Enterprise Service Bus and
SAP Exchange Infrastructure using JMS. In this scenario WebSphere Enterprise
Service Bus acts as a JMS client by writing a message into JMS queue named
ESB2XI_Request, asking for information about the existence of an SAP user,
this message is then processed by SAP Exchange Infrastructure, which then
gives response by generating a message in a JMS queue named
XI2ESB_Response.
The SCA application is listening to messages on the Receive Destination using a
specific correlation scheme. The receive message needs to have the message
header property JMSCorrelationID equals to the sent message header property
JMSMessageID. The JMS provider in this case SAP Exchange Infrastructure
518
must ensure that response messages it sends back to WebSphere Enterprise

Service Bus with message header property JMSCorrelationID populated
correctly.

In this scenario, WebSphere Enterprise Service Bus uses Java Message Service
to connect through Remote Function Call to the SAP system. A request for user
information is generated by WebSphere Enterprise Service Bus in a form of a
message put in a WebSphere MQ queue(ESB2XI_Request). The message is
processed by SAP Exchange Infrastructure, which is called
BAPI_USER_EXISTENCE_CHECK, to check whether a user is found in the SAP
system. The response of user existence is then put in a WebSphere MQ queue,
XI2ESB_Response (Figure 7-28).
ESB 6.0.1.2 (WAS 6.0.2.9) / MQ6
ESB 6.0.1.2
SAP XI
SAP
MQ6
ESB2XI_Request
ITSOESB2SAPXI_JMS
XI2ESB_Response
ITSO_IBM_1
ITSO_SAP_2
ITSO_SAP_3
Figure 7-28 Operational model
Attention: This is the setup that we use for this book. The operating system
and version number of products might be different in your environment.
Always apply the latest fix pack.
519
7.4.2 Configuration
This section describes how to:
Create the WebSphere MQ queues (request and response queues) that is
needed to communicate with SAP Exchange Infrastructure.
Create the destinations and JMS resources in WebSphere Enterprise Service
Bus.
Creating the queues in WebSphere MQ

To create the queues in WebSphere MQ, follow these steps:
1. Start WebSphere MQ Explorer by selecting Start Programs IBM
WebSphere MQ WebSphere MQ Explorer.
2. Create the remote queue definition XI2ESB_Response:
a. From WebSphere MQ Explorer, expand the folder ItsoQmgr2.
b. Right-click the folder Queues and select New Remote Queue
Definition.
c. In the remote queue definition dialog box, enter XI2ESB_Response as the
Name and click Next.
d. In the next dialog box, enter the entries as shown in Table 7-4.
Table 7-4 XI2ESB_Response properties
520
Remote queue
XI2ESB_Response
Remote queue manager
Itso_ESBAppBus
Transmission queue
Itso_XQESBAppBus
e. The dialog box now looks similar to that shown in Figure 7-29. Click Finish
to complete the creation of the remote queue definition.
Figure 7-29 XI2ESB_Response attributes
521
3. Create the locale queue ESB2XI_Request:

a. Return to WebSphere MQ Explorer and expand the folder ItsoQmgr2.
b. Right-click the folder Queues and select New Local Queue.
c. In the local queue creation dialog box, enter ESB2XI_Request as Name and
click Finish as shown in Figure 7-30 to complete the creation of the
queue.
Figure 7-30 ESB2XI_Request attribute
Creating the destinations

The next step after creating the request and response queues in WebSphere
MQ, is to define the destinations and JMS resources in WebSphere Enterprise
Service Bus. To create the destinations, follow these steps:
1. Start the WebSphere ESB Server from WebSphere Integration Developer by
selecting the Servers tab, selecting the WebSphere ESB Server v6.0 server,
and then right-clicking and selecting Start.
2. Open the WebSphere ESB Server Administration Console.
3. From the administration console expand Service Integration Bus and select
Buses.
4. From the list of Buses, click SCA.APPLICATION.esbCell.Bus.
5. Navigate to the Destination page and select the Destinations link.
522
6. Create a new local destination named XI2ESB_Response:

a. Click New to create a new destination.
b. Select Queue as a destination type as shown in Figure 7-31 and click
Next.
Figure 7-31 Select destination type
c. Enter XI2ESB_Response as a destination name, and click Next as shown in

Figure 7-32.
Figure 7-32 Set queue attributes
523
d. Select esbNode:server1 and click Next as shown in Figure 7-33.
Figure 7-33 Assign the queues to a bus member
e. Click Finish to complete the creation of the destination as shown in

Figure 7-34.
Figure 7-34 Confirm queue creation
f. Save the changes by clicking the Save link as shown in Figure 7-35.
Figure 7-35 Save the changes
524
g. Confirm the changes by clicking Save as shown in Figure 7-36.
Figure 7-36 Confirm the changes
7. Create a new alias destination named ESB2XI_Request.

After creating the destination for the inbound corresponding to
XI2ESB_Response, you need to create the outbound destination for
ESB2XI_Request. Follow these steps:
a. From the SCA.APPLICATION.esbCell.Bus, click the Destination link.
b. Click New to create a destination.
c. Select Alias as the destination type and click Next (Figure 7-37).
d. Enter ESB2XI_Request as the Identifier of the new destination.

e. Select SCA.APPLICATION.esbCell.Bus as Bus.
f. Use the drop-down menu to select Itso_ForeignBus as Target bus.
525
g. Select other, please specify in the Target identifier field. Enter

ESB2XI_Request@ItsoQmgr2 as shown in Figure 7-38. Then, click Next.
Figure 7-38 Set alias destination attributes
h. Click Finish to complete the creation of the alias destination as shown in

Figure 7-39.
Figure 7-39 Confirm alias destination creation
526
i. Save the changes by clicking the Save link as shown in Figure 7-40.
Figure 7-40 Save the changes
j. Confirm the changes by clicking Save as shown in Figure 7-41.
Figure 7-41 Confirm the changes
527
8. Enable MQRFH2 headers to be generated for the alias destination

ESB2XI_Request. After creating the alias destination EBS2XI_Request, the
next task is to enable the creation of MQRFH2 headers:
a. Return to EBS2XI_Request general properties.
b. Click the Context properties link as shown in Figure 7-42.
Figure 7-42 ESBXI_Request general properties
c. Click New to create a new context.

d. Enter _MQRFH2Allowed as a Name.
528
e. Enter true as a Context value as shown in Figure 7-43. Then, click OK.
Figure 7-43 Add _MQRFH2Allowed context to ESB2XI_Request
f. Save the changes by clicking the Save link. Then, confirm the changes by
clicking Save.
529
Creating the JMS resources

After creating the destination, navigate back to the welcome page of WebSphere
Administration Console. Then, create the JMS resources by following these
steps:
1. From the navigation pane, select Resources JMS Providers Default
messaging.
2. Make sure that the scope is set to Node:esbNode as shown in Figure 7-44.
Figure 7-44 Select the Node scope
3. Create the JMS Connection factory:

a. Select the JMS connection factory link.
b. Click New.
c. In the create dialog box, enter and select the values as shown in Table 7-5.
Then, click OK.
d. Save the changes.
Table 7-5 Connection factory properties
530
Name
ESB2SAPXI_CF
JNDI name
jms/ESB2SAPXI_CF
Bus name
SCA.APPLICATION.esbCell.Bus
4. Create the ESB2XI_Request JMS queue:

a. Return to the Default Messaging Provider window in WebSphere
Administration Console.
b. Select the JMS queue link.
c. Click New.
d. In the create dialog box, enter or select the values as shown in Table 7-6.
Then, click OK.
e. Save the changes.
Table 7-6 ESB2XI_Request properties
Name
ESB2XI_Request
JNDI name
jms/ESB2XI_Request
Queue name
ESB2XI_Request
Bus name
5. Create the XI2ESB_Response JMS queue:

c. Click New.
d. Enter the values as shown in Table 7-7. Then, click OK.
Table 7-7 XI2ESB_Response properties
Name
XI2ESB_Response
JNDI name
jms/XI2ESB_Response
Queue name
XI2ESB_Response
Bus name
6. Log out of the WebSphere Administration Console.

7. Restart the server.
531
7.4.3 Development
This section describes how to create a Mediation Module that communicates with
SAP Exchange Infrastructure using a JMS binding. It explains how to complete
the following tasks:
Creating a new library project that includes the schema that are imported for
SAP Exchange Infrastructure.
Creating a Mediation Module.
Creating a library project

This section explains how to create a library project that is used in the Mediation
Module and in the Module that includes the process component. To create a
library project, follow these steps:
1. Start WebSphere Integration Developer.
2. In the Business Integration View, right-click and select New Library as
Figure 7-45 Select the Library project
532
3. Enter ITSO2SAPXI_JMSLib as the Library Name as shown in Figure 7-46.
Figure 7-46 Library project properties
4. Click Finish to create the library project.
533
Importing the schemas from SAP Exchange Infrastructure

The schemas of the Message Types that are created by SAP Exchange
Infrastructure provide the Data Types objects that you need to build the
Assembly Diagram. To import the schemas from SAP Exchange Infrastructure,
follow these steps:
1. Right-click ITSO2SAPXI_JMSLib and select Import as shown in Figure 7-47.
Figure 7-47 Select import
2. Select File system as shown in Figure 7-48.
Figure 7-48 Select File system import
534
3. Click Next.
4. Click Browse on the same line as the From directory.
5. Browse to the directory where the schemas are located. In this scenario, the
directory is C:\ITSO.
6. Click OK.
7. Select BapiUserExistenceCheckQuery_MT.xsd and
BapiUserExistenceCheckResponse_MT.xsd, as shown in Figure 7-49.
8. Click Finish.
Figure 7-49 Select SAP Exchange Infrastructure schemas
535
Creating a new interface definition

The next task is to create a new interface definition,
UserQueryResponseInterface. The UserQueryResponseInterface interface is a
two-way request and response operation that passes a single part of type
BapiUserExistenceCheckQuery_MT and receives a part of type
BapiUserExistenceCheckResponse_MT. To create a new interface definition,
follow these steps:
1. Under the ITSO2SAPXI_JMSLib project, select the Interfaces folder.
2. Right-click and select New Interface as shown in Figure 7-50.
3. Deselect Default.
4. Enter http://ibm.com/itso/sg247220/esb as Namespace.
5. Name the new interface UserQueryResponseInterface as shown in
Figure 7-51.
Figure 7-51 New interface properties.
536
6. Add a request and response operation to the interface:

a. Click the Add Request Response Operation icon as shown in Figure 7-52.
Figure 7-52 Select add request response operation
b. Rename the operation from the default operation name (operation1) to

userQueryResponse as shown in Figure 7-53.
Figure 7-53 Create a new operation
c. In the Interface editor pane, select userQueryResponse and click the

Add Input icon as shown in Figure 7-54.
Figure 7-54 Add an input to userQueryResponse operation
d. Set the Input(s) Name to UserInput and the Type to

BapiUserExistenceCheckQuery_MT as shown in Figure 7-55.
Figure 7-55 Set the input name and type name
537
e. In the Interface editor pane, select the userQueryResponse and click the
Add Output icon as shown in Figure 7-56.
Figure 7-56 Add an output to userQueryResponse operation
f. Set the Output(s) Name to UserResponse and the Type to

BapiUserExistenceCheckResponse_MT as shown in Figure 7-57.
Figure 7-57 userQueryResponse operation overview
g. From the WebSphere Integration Developer menu, select File Save to

save the new interface.
h. From the WebSphere Integration Developer,select File Close to close
the Interface Editor.
Creating a mediation module

The next task involves setting up a mediation module that creates and reads
messages from JMS queues. To create a mediation module, follow these steps:
1. Create a mediation module named ITSOESB2SAPXI_JMS.
a. From the Business Integration View, right-click and select New
Mediation Module as shown in Figure 7-58.
Figure 7-58 Select Mediation Module project
538
b. Enter ITSOESB2SAPXI_JMS as the Module Name.

c. Select WebSphere ESB Server v6.0 as the Target Runtime as shown in
Figure 7-59. Then, click Next.
Figure 7-59 Mediation Module properties
539
d. Select the ITSO2SAPXI_JMSLib library module to be used by the

mediation module as shown in Figure 7-60.
e. Click Finish to complete the creation of the project.
Figure 7-60 Select required libraries
2. Open the Assembly Diagram.

3. Rename the default Mediation1 component to UserExist_JMSMediationFlow.
4. Add a reference to UserExist_JMSMediation component:
a. Right-click UserExist_JMSMediation and select Add Reference as
Figure 7-61 Add reference to UserExist_JMSMediationFlow
540
b. From the Add Reference dialog box, select

UserQueryResponseInterface as shown in Figure 7-62.
c. Click OK to add the reference.
Figure 7-62 Select matching interface
541
5. Add an interface to UserExist_JMSMediation component:

a. Right-click UserExist_JMSMediation and select Add Interface as
Figure 7-63 Add interface to UserExist_JMSMediationFlow
b. From the Add Interface dialog box, select UserQueryResponseInterface

c. Click OK to add the interface.
542
6. Add an Import component:

a. From the left of the Assembly Diagram, locate and select the Import icon
from the palette as shown in Figure 7-65.
Figure 7-65 Select import component from the palette
b. Place the icon on the Assembly Diagram.

c. Name the export component, UserExist_JMSImport. The Assembly
Diagram now appears as shown in Figure 7-66.
Figure 7-66 Rename the import component
7. Add an interface to the UserExist_JMSImport component:

a. Right-click UserExist_JMSImport and select Add Interface as shown in
Figure 7-67.
Figure 7-67 Add an interface to UserExist_JMSImport
543
b. From the Add Interface dialog box, select UserQueryResponseInterface

c. Click OK to add the interface.
Figure 7-68 Select a matching interface
544
8. Build the mediation flow:

a. Right-click UserExist_JMSMediationFlow and select Generate
Figure 7-69 Generate the implementation for UserExist_JMSMediationFlow
b. Accept the suggested ITSOESB2SAPXI_JMS folder as shown in

Figure 7-70. Then, click OK.
Figure 7-70 Folder selection
545
c. In the Operation connections panel, wire the userQueryResponse operation

on the UserQueryResponseInterface interface to the userQueryResponse
operation on the UserQueryResponseInterfacePartner reference as
Figure 7-71 Wire operation connections
546
d. After wiring the operations, the request flow open. Wire the
UserQueryResponseInterface_userQueryResponse_Input to the in terminal
of UserQueryResponseInterfacePartner_userQueryResponse_Callout as
Figure 7-72 Request flow
9. After wiring the request flow, do the same with the response flow:
a. In the mediation flow editor, click the Response tab as shown in
Figure 7-73.
Figure 7-73 Select the response flow
547
b. Wire
UserQueryResponseInterfacePartner_userQueryResponse_CalloutResponse
to UserQueryResponseInterface_userQueryResponse_InputResponse as
Figure 7-74 Response flow
10.After implementing the mediation flow, open the Assembly Diagram and wire
UserExist_JMSMediationFlow to UserExist_JMSImport as shown in
Figure 7-75.
Figure 7-75 Wire UserExist_JMSMeditionFlow to UserExist_JMSImport
The Assembly Diagram displays as shown in Figure 7-76.
Figure 7-76 Assembly Diagram overview
548
Creating JMS binding

The next task is to set up the Import node to use JMS. We defined the necessary
JMS and JNDI resources in Creating the JMS resources on page 530. Follow
these steps:
1. Right-click UserExist_JMSImport and select Generate Binding JMS
Binding as shown in Figure 7-77.
Figure 7-77 Generate JMS binding
2. At the Configure JMS Import Service dialog box, follow these steps:
a. Select Configure new messaging provider resources.
b. Select Business Object XML using JMS TextMessage as a
Serialization type.
549
c. Make sure that Generate TargetFunctionName message header

property for default JMS Function Selector is selected as shown in
Figure 7-78.
d. Click OK.
Figure 7-78 Configure JMS import binding
3. After generating the JMS binding, click UserExist_JMSImport and display

the component by right-clicking and selecting Show in Properties.
4. Specify the connection factory properties:
a. Click Binding Endpoint configuration.
b. Select Specify JNDI name for pre-configured messaging provider
resource.
550
c. Enter jms/ESB2SAPXI_CF in the JNDI Lookup Name field as shown in

Figure 7-79.
Figure 7-79 Connection factory properties
5. Specify the Send Destination Properties:

a. Select the JMS Destinations tab.
resource.
c. Enter jms/ESB2XI_Request in the JNDI Lookup Name field as shown in
Figure 7-80.
Figure 7-80 Send destination properties
551
6. Specify the Receive Destination Properties:

a. In the same JMS Destinations tab, expand the Receive Destinations
Properties.
resource.
c. Enter jms/XI2ESB_Response in the JNDI Lookup Name field as shown in
Figure 7-81.
Figure 7-81 Receive destination properties
7. From the WebSphere Integration Developer menu, select File Save to

save the JMS binding.
552
7.4.4 Deployment to WebSphere Enterprise Service Bus

This section explains how to deploy the mediation module that you created in a
WebSphere Enterprise Service Bus environment. To deploy the mediation
module to WebSphere Enterprise Service Bus, follow these steps:
selecting the Servers tab. Then, select WebSphere ESB Server v6.0 server
and right-click and select Start.
2. If the server is started, right-click WebSphere ESB Server v6.0 and select
Add and remove projects as shown in Figure 7-82.
Figure 7-82 Add and remove projects
3. Select the ITSOESB2SAPXI_JMS project on the left and click Add to move it
to right.
553
7.4.5 Execution and test

This section explains how to execute and test the created project using the
WebSphere Integration Developer test client.
Testing with WebSphere Integration Developer test client

In the test, you create a message to JMS queues for SAP Exchange
Infrastructure to check whether a user is known in the SAP system. To perform
this test, follow these steps:
1. In the Assembly Editor right-click UserExist_JMSMediationFlow and select
Test Component to start the test client that is integrated in the WebSphere
Integration Developer environment as shown in Figure 7-83.
Figure 7-83 Test Simulator
554
2. Remove the UserExist_JMSImport simulator:

a. Select the Configurations tab.
b. Select the Emulators and click Remove as shown in Figure 7-84.
Figure 7-84 Remove the UserExist_JMSImport
555
3. Go to the Events tab.

4. Enter ITSOUSER in the USERNAME field and click Continue to start the test as
Figure 7-85 Test invocation
556
5. A window prompt displays to select the server where the application is

deployed. Select WebSphere ESB Server v6.0 as shown in Figure 7-86.
Click Finish.
Figure 7-86 Select deployment location
557
The result displays as shown in Figure 7-87.
Figure 7-87 Test results
7.4.6 Conclusion
This scenario demonstrates how you can use WebSphere Enterprise Service
Bus as a JMS consumer in a context where SAP Exchange Infrastructure acts as
a JMS provider. From the WebSphere Enterprise Service Bus perspective, SAP
Exchange Infrastructure as the JMS provider provides schemas of the Message
Types that are imported into WebSphere Enterprise Service Bus as Data Types.
7.5 Scenario B: WebSphere Enterprise Service Bus as a

JMS provider
In this scenario, we configure WebSphere Enterprise Service Bus as a JMS
provider. WebSphere Enterprise Service Bus provides the functionality of a
simple Java component, which is triggered when a message is received in a JMS
queue.
The SCA architecture in both WebSphere Enterprise Service Bus and
WebSphere Process Server uses a specific correlation scheme to correlate
response messages. By default, the SCA application populates the response
message header property JMSCorrelationID with the value found in the inbound
message header property JMSMessageID, which allows SAP Exchange
Infrastructure to correlate both the request and response messages.
558

In this scenario SAP Exchange Infrastructure uses JMS to connect to
WebSphere Enterprise Service Bus. The BAPI_USER_GETLIST is called from
the SAP system, which is connected to SAP Exchange Infrastructure, and then
SAP Exchange Infrastructure request user information by generating a message
to WebSphere MQ. The response is then generated by WebSphere Enterprise
Service Bus and put in a WebSphere MQ queue. Refer to Figure 7-88
SAP
SAP XI
ESB 6.0.1.2 (WAS 6.0.2.9) / MQ6
MQ6
ESB 6.0.1.2
X12ESB_Request
BAPI_USER_GETLIST
ITSOSAPX12ESB_JMS
ESB2XI_Response
ITSO_SAP_3
ITSO_SAP_2
ITSO_IBM_1
559
7.5.2 Configuration
Create the WebSphere MQ queues (request and response queues) that are
needed to communicate with SAP Exchange Infrastructure.
Create the destinations and JMS resources in WebSphere Enterprise Service
Bus.
Creating the queues in WebSphere MQ

To create the queues in WebSphere MQ, follow these steps:
1. Create the remote queue definition XI2ESB_Request:
a. From WebSphere MQ Explorer, expand the folder ItsoQmgr2,
b. Right-click the folder Queues and select New Remote Queue
Definition.
c. In the remote queue definition dialog box, enter XI2ESB_Request as the
Name and click Next.
d. In the next dialog box, enter the entries as shown in Table 7-8.
Table 7-8 XI2ESB_Request properties
560
Remote queue
XI2ESB_Request
Remote queue manager
Itso_ESBAppBus
Transmission queue
Itso_XQESBAppBus
e. The dialog box opens as shown in Figure 7-89. Click Finish to complete
the creation of the remote queue definition.
Figure 7-89 XI2ESB_Request properties
561
2. Create the locale queue ESB2XI_Response:

a. Return to WebSphere MQ Explorer and expand the folder ItsoQmgr2.
b. Right-click the folder Queues and select New Local Queue.
c. In the local queue creation dialog box, enter ESB2XI_Response as the
Name and click Finish (Figure 7-90).
Figure 7-90 ESB2XI_Response properties
Creating the destinations

Next, you need to define the destinations and JMS resources in WebSphere
Enterprise Service Bus. To create the destinations:
1. Start the WebSphere ESB Server by selecting the Servers tab from
WebSphere Integration Developer. Then, select WebSphere ESB Server
v6.0 server and right-click and select Start.
2. Open the WebSphere ESB Server Administration Console.
3. From the administration console, expand Service Integration Bus and select
Buses.
4. From the list of Buses, click the SCA.APPLICATION.esbCell.Bus name.
5. Navigate to the Destination page and click the Destinations link.
562
6. Create a new local destination named XI2ESB_Request:

a. Click New to create a new destination.
b. Select Queue as a destination type and click Next as shown in
Figure 7-91.
c. Enter XI2ESB_Request as the destination name and click Next as shown in

Figure 7-92.
Figure 7-92 Set queue attributes
563
d. Select esbNode:server1 and click Next as shown in Figure 7-93.
Figure 7-93 Assign the queue to a bus member
e. Click Finish as shown in Figure 7-94.
Figure 7-94 Confirm queue creation
f. Save the changes by clicking the Save link. Confirm the changes by
clicking Save.
564
After you create the destination for the inbound corresponding to

XI2ESB_Request, you need to create the outbound destination for
ESB2XI_Response. Follow these steps:
1. Create a new Alias destination named XI2ESB_Request:
a. From the SCA.APPLICATION.esbCell.Bus, click the Destination link.
b. Click New to create a destination.
c. In the next dialog box, select Alias as a destination type and click Next as
2. Enter ESB2XI_Response as the Identifier.

3. Select SCA.APPLICATION.esbCell.Bus as Bus.
4. Use the drop-down menu to select Itso_ForeignBus as Target bus.
565
5. Select other and specify in the Target identifier field. Enter

ESB2XI_Response@ItsoQmgr2 as shown in Figure 7-96. Then, click Next.
Figure 7-96 Set Alias destination attributes
566
6. Click Finish as shown in Figure 7-97.
Figure 7-97 Confirm alias destination creation
7. Save the changes by clicking the Save link. Confirm the changes by clicking
Save.
After creating the alias destination EBS2XI_Response, the next task is to create
MQRFH2 headers. Follow these steps:
1. Return to EBS2XI_Response general properties.
2. Click the Context properties link as shown in Figure 7-98.
Figure 7-98 ESBXI_Response general properties
567
3. Click New to create a new context.

4. Enter _MQRFH2Allowed as the Name.
5. Enter true as a Context value as shown in Figure 7-99. Then, click OK.
Figure 7-99 Add _MQRFH2Allowed context to ESB2XI_Response
6. Save the changes by clicking the Save link. Confirm the changes by clicking
Save.
568
Creating the JMS resources

After creating the destinations, navigate to the welcome page of WebSphere
Administration Console. Then, to create the JMS resources, follow these steps:
1. From the navigation pane, select Resources JMS Providers Default
messaging.
2. Make sure that the scope is set to Node:esbNode as shown in Figure 7-100.
Figure 7-100 Select node scope
3. Create the JMS Connection factor:

a. Select JMS connection factory link.
b. Click New.
c. In the create dialog box, enter and select the values as shown in Table 7-9.
d. Click OK.
Table 7-9 Connection factory properties
Name
SAPXI2ESB_CF
JNDI Name
jms/SAPXI2ESB_CF
Bus Name
4. Create the XI2ESB_Request JMS queue:

569
c. Click New.
e. Click OK.
Table 7-10 XI2ESB_Request JMS properties
Name
XI2ESB_Request
JNDI name
jms/XI2ESB_Request
Bus name
Queue name
XI2ESB_Request
5. Create the ESB2XI_Response JMS queue:

b. Select JMS queue link.
c. Click New.
d. Enter the values as shown in Table 7-11.
e. Click OK.
f. Save the changes.
Table 7-11 ESB2XI_Response JMS properties
Name
ESB2XI_Response
JNDI name
jms/ESB2XI_Response
Bus name
Queue name
ESB2XI_Response
6. Create the JMS activation specification:

b. Select the JMS activation specification link.
c. Click New.
e. Click OK.
f. Save the changes.
570
Table 7-12 JMS activation properties

Name
SAPXI2ESB_AS
JNDI name
eis/SAPXI2ESB_AS
Destination type
Queue
Destination JNDI name
jms/XI2ESB_Request
7. Log out of the WebSphere Administration Console.

7.5.3 Development
This section describes how to create a Mediation Module that communicates
with SAP Exchange Infrastructure when WebSphere Enterprise Service Bus is
acting as a JMS provider.
Creating a new Mediation Module

This section explains how to create a Mediation Module and how to implement
the Mediation Flow link to it. To create a new Mediation Module:
1. Start WebSphere Integration Developer.
2. In the business integration view, right-click and select New Mediation
Module as shown in Figure 7-101.
Figure 7-101 Mediation module creation
571
3. Set the Module Name to ITSOSAPXI2ESB_JMS as shown in Figure 7-102.

4. Make sure that the Target Runtime is set to WebSphere ESB Server v6.0.
5. Click Finish to create the project.
Figure 7-102 Mediation module general properties
6. Open the module in the Assembly Editor. Select the default mediation module
Module1 and change the name of it to UserList_JMSMediationFlow.
572
Creating business objects

To create a new UserInfo business object, follow these steps:
1. In the Business Integration view, expand ITSOSAPXI2ESB_JMS, right-click
Data Types and select New Business Object as shown in Figure 7-103.
Figure 7-103 Business object creation
2. In the Business Object window, set the values as shown in Table 7-13.
Table 7-13 UserInfo business object properties
Default
Unchecked
Namespace
http://itso.ibm.com/sg247220/UserInfo
Folder
Leave blank
Name
UserInfo
Inherit from
<none>
573
3. The dialog box opens as shown in Figure 7-104. Click Finish.
Figure 7-104 UserInfoBO business object
574
4. The UserInfoBO opens in the Business Object Editor. In the business object
editor, right-click UserInfoBO and select Add Attribute as shown in
Figure 7-105.
Figure 7-105 Add attribute to UserInfoBo
5. An attribute is created with a default name of attribute1 and a default type of

string. Rename it to username and leave its type as string.
575
6. Set the attribute username as a required attribute. Right-click the username

attribute and select Show in Properties as shown in Figure 7-106.
Figure 7-106 Show attribute properties
7. From the Properties view, specify that the attribute is mandatory by selecting
Required as shown in Figure 7-107.
Figure 7-107 The username properties
576
8. Use the steps 4 to 7 to create the firstName, lastName, and fullName

attributes as shown in Table 7-14.
Table 7-14 UserInfoBO attributes
Name
Type
Required
firstName
string
no
lastName
string
no
fullName
string
no
The UserInfoBO business object now appears as shown in Figure 7-108.
Figure 7-108 UserInfoBO business object
9. Create a UserListRequestBO business object by entering or selecting the

values shown in Table 7-15.
Table 7-15 UserListRequestBO business object properties
NameSpace
http://itso.ibm.com/sg247220/UserListRe
questBO
Folder
Leave blank
Name
UserListRequestBO
Inherit from
<none>
577
10.Click Finish (Figure 7-109).
Figure 7-109 UserListRequestBO business object
11.Add the attributes shown in Table 7-16 to UserListRequestBO.

Table 7-16 UserListRequest BO attributes.
578
Name
Type
Required
amount
int
yes
includeName
boolean
yes
The UserListRequestBO business object now displays as shown in

Figure 7-110.
Figure 7-110 UserListRequestBO business object
12.The last business object to create is UserListResponseBO using the values

given in Table 7-17.
Table 7-17 UserListResponse properties
Namespace
Folder
Leave blank
Name
UserListResponseBO
Inherit from
<none>
579
13.The dialog box opens as shown in Figure 7-111. Click Finish.
Figure 7-111 UserListResponse business object
14.Add an attribute to the business object UserListResponseBO using the values

given in Table 7-18.
Table 7-18 The userList attribute
580
Name
Type
Array
userList
UserInfoBO
yes
15.The dialog box opens as shown in Figure 7-112. Click Finish.
Figure 7-112 UserList business object overview
Creating a new interface definition

The next task is to create a new interface definition, UserListInterface.The
UserListInterface interface is a two-way request and response operation that
passes a single part of type UserListRequestBO and receives a part of type
UserListResponseBO. To create a new interface definition, follow these steps:
1. In the Business Integration View, expand ITSOSAPXI2ESB_JMS.
581
2. Right-click Interfaces and select New Interface as shown in Figure 7-113.
3. Clear the Default check box.

4. Set the Namespace to http://itso.ibm.com/sg247220.
582
5. Set the Name of the interface to UserListInterface as shown in

Figure 7-114.
6. Click Finish.
Figure 7-114 UserListInterface properties
7. Add a request and response operation to the interface by clicking Add

Request Response Operation icon. Rename the operation name to
getUserList as shown in Figure 7-115.
Figure 7-115 Add a request response operation
8. In the Interface Editor, select the getUserList operation and click the Add
Input icon.
583
9. Set the Name to userinput and the Type to UserListRequestBO as shown in

Figure 7-116.
Figure 7-116 Set the Name and the Type of the input parameter
10.In the Interface Editor, select the getUserList operation and click the Add
Output icon.
11.Set the Name to useroutput and the Type to UserListResponseBO as shown
in Figure 7-117.
Figure 7-117 Set the Name and the Type of the output parameter
12.Save and close the interface.
Assembling the Mediation Module

To assemble the Mediation Module, follow these steps:
1. Add an interface to UserList_JMSMediationFlow:
a. In the Assembly Diagram right-click UserList_JMSMediationFlow and
select Add Interface as shown in Figure 7-118.
Figure 7-118 Add an interface to UserList_JMSMediationFlow
584
b. Select the UserListInterface interface and click OK as shown in

Figure 7-119.
2. Add also reference to mediation flow:

a. Right-click UserList_JMSMediationFlow and select Add Reference
Figure 7-120 Add a reference to UserList_JMSMediationFlow
585
b. From the Reference window, select the UserListInterface reference and

select OK as shown in Figure 7-121.
586
3. Add an export component:

a. From the left of the Assembly Diagram, locate and select the export
component as shown in Figure 7-122.
Figure 7-122 Select the export icon from the palette
b. Place the component on the Assembly Diagram.

c. Rename the export to UserListJMS_Export as shown in Figure 7-123.
Figure 7-123 Rename the export to UserListJMS_Export
587
4. Add an interface to UserListJMS_Export:

a. Right-click the UserListJMS_Export component and select Add Interface
Figure 7-124 Add an interface to UserListJMS_Export
b. From the list of Interfaces select UserListInterface and click OK as

588
5. Build the mediation flow:

a. Right-click UserList_JMSMediationFlow and select Generate
Figure 7-126 Generate UserList_JMSMediationFlow implementation
b. Select ITSOSAPXI2ESB_JMS as the folder where the Mediation Flow is

generated and click OK as shown in Figure 7-127. The Mediation Flow
Editor opens.
Figure 7-127 Folder Selection
589
c. In the Operation connections panel, wire the getUserList operation on the

UserListInterface interface to the getUserList operation on the
UserListInterface reference as shown in Figure 7-128.
Figure 7-128 Wire operation connections
590
6. After wiring the Operations, the request flow appears (Figure 7-129).
Implement the request flow by following these steps:
a. For logging purpose select the Message Logger from the left palette and
drag-and-drop on the panel then a MessageLogger1 component is
created.
b. Right-click MessageLogger1 and select Show in Properties.
c. In the Properties View, select the Details tab and enter a slash (/) as Root.
d. Wire the UserListInterface_getUserList_Input to the in terminal of
MessageLogger1.
e. Wire the MessageLogger1 out terminal to the in terminal of
UserListInterfacePartner_getUserList_Callout.
Figure 7-129 Request flow
7. After wiring the request flow, do the same with the response flow. In the
mediation flow editor, go to the Response tab as shown in Figure 7-130.
Figure 7-130 Select the response flow
591
8. Then, implement the Response flow by following these steps (Figure 7-131):
a. To be able to log the response message that is generated by the Java
component, select the Message Logger from the left palette and
drag-and-drop on the panel then a MessageLogger1 component is
created.
b. Right-click MessageLogger1 and select Show in Properties.
c. In the Properties View, select the Details tab and enter a slash (/) as Root.
d. Wire UserListInterfacePartner_getUserList_CalloutResponse to the in
terminal of MessageLogger1.
e. Then wire MessageLogger1 out terminal to the in terminal of
UserListInterface_getUserList_InputResponse.
Figure 7-131 Response flow
592
9. After implementing the Mediation Flow, open the Assembly Diagram and wire
the UserListJMS_Export to the UserList_JMSMediationFlow as shown in
Figure 7-132.
Figure 7-132 Wire UserListJMS_Export to UserList_JMSMediationFlow
10.Create the Java Component:

a. Select a Java component from the palette and drag-and-drop it on the
Assembly Diagram as shown in Figure 7-133. The Component1 is now in
the Assembly Diagram.
Figure 7-133 Select the Java icon from the palette
b. Click the Component1 and rename it to UserList_POJO as shown in

Figure 7-134.
Figure 7-134 Rename the Java component to UserList_POJO
593
c. Add an interface to the UserList_POJO by right-clicking UserList_POJO

and selecting Add Interface as shown in Figure 7-135.
Figure 7-135 Add an interface to UserList_POJO
d. From the list of interfaces, select the UserListInterface and click OK as

594
11.Implement the Java component:

a. Right-click the UserList_POJO and select Generate Implementation as
Figure 7-137 Generate the UserList_POJO implementation
b. In the next window, select the package where the Java implementation is
generated. To define a new package, click New Package as shown in
Figure 7-138.
Figure 7-138 Select a Java package
595
c. Enter sapxi2esb in the Package name field and select OK as shown in

Figure 7-139.
Figure 7-139 Define a new Java package name
d. Select sapxi2esb from the package list and click OK as shown in

Figure 7-140.
Figure 7-140 Select the new Java package created
596
e. A class named UserList_POJOImpl is created automatically. Replace the

implementation of the getUserList method with the code as shown in
Example 7-1.
Example 7-1 getUserList method
public DataObject getUserList(DataObject userinput) {

// Get request parameters
int amount = userinput.getInt("amount");
boolean includeNames = userinput.getBoolean("includeNames");
ServiceManager serviceManager = ServiceManager.INSTANCE;
serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
List userList = new ArrayList();
for (int i = 0; i < amount; i++) {
DataObject userInfo =
factory.create("http://itso.ibm.com/sg247220/UserInfoBO",
"UserInfoBO");
userInfo.setString("username", "username" + i);
if (includeNames) {
userInfo.setString("firstName", "John" + i);
userInfo.setString("lastName", "Doe" + i);
userInfo.setString("fullName", "John" + i + " Doe" + i);
}
userList.add(userInfo);
}
DataObject response =
factory.create("http://itso.ibm.com/sg247220/UserListResponseBO",
"UserListResponseBO");
response.setList("userList", userList);
return response;
}
597
f. At this stage, the class still includes some errors due to types that cannot
be resolved. To solve this issue, right-click anywhere in the class and
select Source Organize imports as shown in Figure 7-141.
Figure 7-141 Organize imports
598
g. Select the java.util.List import as shown in Figure 7-142. Click Finish.
Figure 7-142 Choose type to import
h. The generated implementation is now without any errors. Save the

implementation.
12.Wire the UserList_JMSMediationFlow to UserList_POJO as shown in
Figure 7-143.
Figure 7-143 Wire the UserList_JMSMediationFlow to UserList_POJO
599
Creating the custom selector

When a JMS messages arrives on a destination, the function selector role is to
determine the operation that corresponds to the incoming JMS message. By
default the JMS export binding provide a function selector class, named
JMSFunctionSelectorImpl, that returns the value of the JMS String Property
TargetFunctionName from the JMS header.
In this scenario, SAP Exchange Infrastructure is not populating the JMS custom
headers with the TargetFunctionName property, which means that a custom
JMS function selector is required.
For more information about the JMS function selector refer to:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?topi
c=/com.ibm.wbit.help.messaging.doc/topics/rjmsfunctsel.html
To create a custom JMS function selector, follow these steps:
1. From Business Integration View, select Window Open Perspective
Other as shown in Figure 7-144.
Figure 7-144 Open a new perspective
600
2. From the list of available perspectives select the Java perspective as shown
in Figure 7-145.
Figure 7-145 Select the Java perspective
3. Create a new project by selecting File New Project as shown in

Figure 7-146.
Figure 7-146 Create a new project
601
4. Then select Java Java Project and click Next as shown in Figure 7-147.
Figure 7-147 Select Java Project
602
5. Enter ITSOCustomSelector as the Project name and click Next as shown in

Figure 7-148.
Figure 7-148 Java project properties
603
6. Select the commonj.connector.jar library:

a. Go to the Libraries tab.
b. Click Add External JARs.
c. In the JAR Selection dialog box, browse to the directory <WebSphere
Integration Installation Directory>\runtimes\bi_v6\lib and select the jar file
commonj.connector.jar as shown in Figure 7-149.
d. Click Open to include the library in the project.
e. Click Finish.
Figure 7-149 Add an external library
604
7. After completing the creation of the project, select ITSOCustomSelector,

right-click and select New Class as shown in Figure 7-150.
Figure 7-150 Create Java class
8. Enter itso.ibm.com.sg247220.selectors as a Package.

9. Enter ITSOCustomerSelector as a Name.
10.Click Add to select the interface that needs to be implemented by the class.
11.From the interface dialog box, enter FunctionSelector as interface.
605
12.Click Add to add the interface FunctionSelector and click OK.

13.The dialog box looks as shown in the Figure 7-151. Click Finish.
Figure 7-151 ITSOCustomSelector properties
14.Replace the implementation of the method generateEISFunctionName with the

code shown in Example 7-2.
Example 7-2 Method generateEISFunctionName
public String generateEISFunctionName(Object[] arg0)

throws SelectorException {
// TODO Auto-generated method stub
return "getUserList";
}
606
15.Select File Save to save the custom selector.

16.Select Project Build Project to build the custom selector.
Associating the custom selector project to the Mediation

Module
To associate the custom selector project to the Mediation Module, follow these
steps:
1. From the Java Perspective view, switch to the Business Integration View by
selecting the Business Integration Perspective View from Window Open
Perspective.
2. Right-click ITSOSAPXI2ESB_JMS and select Open Dependency Editor as
Figure 7-152 Open dependency editor
3. From the Open Dependency Editor, click Add under Java as shown in
Figure 7-153.
Figure 7-153 Add a dependent Java project
607
4. From the Java Project Selection select ITSOCustomSelector and click OK

Figure 7-154 Select ITSOCustomSelector as a dependent Java project
5. Make sure that Deploy with Module is set as shown in Figure 7-155.
Figure 7-155 Open dependency editor overview
6. Save the Dependency Editor.
608
Creating JMS binding

To create JMS binding, follow these steps:
1. From the Navigation pane, double-click ITSOSAPXI2ESB_JMS to open the
Assembly Diagram.
2. Right-click UserListJMS_Export and select Generate Binding JMS
Figure 7-156 Generate UserListJMS_Export JMS binding
609
3. At the Configure JMS Export Service dialog box:

a. Select Business Object XML using JMS TextMessage as a
Serialization type.
b. Clear the Use the default JMS Function Selector class option.
c. Click Browse to select the custom selector class created previously as
Figure 7-157 JMS export binding properties
610
d. From the list of Matching Types, select ITSOCustomSelector as shown in

Figure 7-158. Then, click OK.
Figure 7-158 Select ITSOCustomSelector
611
e. The dialog box displays as shown in Figure 7-159. Click OK.
Figure 7-159 JMS export binding summary
612
4. After generating the JMS binding, click UserListJMS_Export and display the
component by right-clicking and selecting Show in Properties.
5. Specify the activation specification properties:
a. Click Binding Endpoint configuration.
resource.
c. Enter eis/SAPXI2ESB_AS in the JNDI Lookup Name field as shown in
Figure 7-160.
Figure 7-160 Activation specification properties
6. Specify the receive destination properties:

a. Select the JMS Destinations tab.
b. Expand Receive Destination Properties.
c. Select Specify JNDI name for pre-configured messaging provider
resource.
d. Enter jms/XI2ESB_Request as JNDI Lookup Name as shown in
Figure 7-161.
Figure 7-161 Receive destination properties
613
7. Specify the send destination properties:

a. In the same JMS Destinations tab, expand Send Destination Properties.
resource.
c. Enter jms/ESB2XI_Response as the JNDI Lookup Name as shown in
Figure 7-162.
Figure 7-162 Send destination properties
8. Specify the connection factory:

a. To define the JMS connection factory select the Response Connection
tab.
resource.
c. Enter jms/SAPXI2ESB_CF as the JNDI Lookup Name as shown in
Figure 7-163.
Figure 7-163 Connection factory properties
614
9. Check the method binding and verify that the native method binding name
correspond to the name that is return by the custom selector that you defined
previously. Follow these steps:
a. Select Binding Method bindings.
b. Expand Bound Methods in the navigation tree.
c. Select getUserList. The dialog box now looks like Figure 7-164, where
the Native Method equals getUserList, which also corresponds to the
string that is return by the custom selector ITSOCustomSelector.
Figure 7-164 Method bindings properties
10.Save the changes by selecting File Save All.

11.Compile by selecting Project Build All.
615
7.5.4 Deployment to WebSphere Enterprise Service Bus

This section illustrates how to deploy the Mediation Module that you created in a
WebSphere Enterprise Service Bus environment. To deploy to WebSphere
Enterprise Service Bus, follow these steps:
selecting the Servers tab, selecting WebSphere ESB Server v6.0 server, and
then right-clicking and selecting Start.
2. If the server is started, right-click WebSphere ESB Server v6.0 and select
Add and remove projects as shown in Figure 7-165.
616
3. Select the ITSOSAPXI2ESB_JMS project on the left and click Add to move it
to right as shown in Figure 7-166.
4. Click Finish to deploy the project ITSOSAPXI2ESB_JMS.
Figure 7-166 Add project

This section describes how to test WebSphere Enterprise Service Bus with SAP
This section is divided into two parts:
Testing using RFHUTIL
Describes how to unit test WebSphere Process Server on its own. In this
case, RFHUTIL is used to put a message in the XI2ESB_Request queue.
Testing from SAP
Describes how to test the complete solution by calling the
BAPI_USER_GETLIST from the SAP back-end system, which then
communicates with the SAP Exchange Infrastructure using the RFC
617
destination ITSO_XI_TO_PROCESS_ESB.SAP that acts as a JMS

consumer that writes a message in the XI2ESB_Request queue.
Cloudview checks the messages going through WebSphere Enterprise Service
Bus.

To test the scenario, RFHUTIL is used to put a message in the XI2ESB_Request
queue. You can find more information about RFHUTIL at the following Web site:
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24000637&loc=en_
US&cs=utf-8&lang=en
To test using RFHUTIL, follow these steps:
1. Load the request message in the XI2ESB_Request queue:
a.
b.
c.
d.
e.
Run rfhutil.exe.
Select the Main tab.
Enter ItsoQmgr2 as the Queue Manager Name.
Enter XI2ESB_Request as the Queue Name.
Click Read File and load the file ItsoSAPXI2ESB.xml.
2. After loading the file, select the Data tab.

3. Select XML as Data Format as shown in Figure 7-167.
Figure 7-167 Request message
618
4. Configure the RFH2 header information.

You need to configure the RFH2 header for the request message following
the selection of the Business Object XML using JMS TextMessage field
during the generation of the JMS export binding.
To configure the RFH2 header information, follow these steps:
a. Select the jms tab and select text as the JMS Message Type as shown in
Figure 7-168.
Figure 7-168 Select text as JMS Message Type
b. Select the RFH tab and select Version 2 as the RFH Type as shown in
Figure 7-169.
Figure 7-169 Select version 2 as the RFH Type
5. Then select the Main tab and click Write Q to put the message in the
XI2ESB_Request queue.
6. The message is then processed by WebSphere Enterprise Service Bus,
which then generates the response message in the ESB2XI_Response
queue.
7. Read the response message:
a. Using rfhutil.exe, enter ItsoQmgr2 as Queue Manager and
ESB2XI_Response as Queue Name.
b. Select Start Browse.
c. Select the Data tab and XML as Data format.
619
The window now looks as shown in Figure 7-170.
Figure 7-170 Response message
620
Testing from SAP

You use the function module BAPI_USER_GETLIST to test the scenario from
SAP. Follow these steps:
1. Execute the transaction /nse37.
2. In the Function Builder: Initial Screen dialog box, enter BAPI_USER_GETLIST as
a Function module. Then, click the Test/Execute icon.
3. In the Test Function Module:Initial Screen dialog box, follow these steps:
a.
b.
c.
d.
Enter ITSO_XI_TO_PROCESS_ESB as a RFC target sys.

Enter 1 in the MAX_ROWS field.
Enter in the WITH_USERNAME field as shown in Figure 7-171.
Click the Execute icon.
Figure 7-171 Test Function Module: Initial dialog box
621
4. The result displays and the dialog box opens as shown in Figure 7-172.
Figure 7-172 Test Function Module results
5. Click the USERLIST Result to display the list of users as shown in

Figure 7-173.
Figure 7-173 Display USERLIST results
622
7.5.6 Verifying messages using Cloudview

The Mediation Module includes a Logging Primitive that allows WebSphere
Enterprise Service Bus to log messages. You can use Cloudview to browse the
cloudscape database where the logs are stored. Follow these steps:
1. Stop the WebSphere Enterprise Service Bus server.
2. Run <WebSphere Integration Developer
folder>\runtimes\bi_v6\cloudscape\bin\embedded\cview.bat to start
Cloudview (Figure 7-174).
Figure 7-174 Cloudview
3. Select File Open and select <WebSphere Integration Developer

folder>\pf\esb\databases\EsbLogMedDB.
4. Select the table MSGLOG, then click the Data tab.
623
5. In the row corresponding to the request message, select the column

MESSAGE and click the icon Text Editor as shown in Figure 7-175.
Figure 7-175 MSGLOG data
6. The windows displays the request message as shown in Figure 7-176.
7. Follow the same steps to view the response message.
624
7.5.7 Conclusion
This scenario demonstrates how you can use WebSphere Enterprise Service
Bus as a JMS provider so that it communicates with SAP Exchange
Infrastructure acting as a JMS client. In this scenario, you need a custom function
selector because there are missing JMS custom headers with the
TargetFunctionName property.
7.6 Extension A: WebSphere Process Server as a JMS

consumer
In this scenario, the SAP Exchange Infrastructure integration does not differ from
scenario A where WebSphere Enterprise Service Bus acts as a JMS client. This
scenario reuses the Mediation Module created in scenario A and links to the new
module project for WebSphere Process Server. The new module created in this
section includes a simple business process which is used through the Business
Process Container (BPC) Explorer as a Web interface.
This is only a short introduction to one of the powerful options WebSphere
Process Server offers. For additional information refer to Technical Overview of
WebSphere Process Server and WebSphere Integration Developer,
REDP-4041, which is available at:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4041.pdf
625

In this scenario, WebSphere Process Server uses JMS to connect through
Remote Function Call to the SAP system. WebSphere Process Server generates
a request for user information in the form of a message that is put in a
WebSphere MQ queue (ESB2XI_Request). SAP Exchange Infrastructure
processes the message, which calls the BAPI_USER_EXISTENCE_CHECK to
check whether a user is found in the SAP system. If the user exists, the message
is then put in a WebSphere MQ queue (XI2ESB_Response). Refer to
Figure 7-177.
WPS 6.0.1.2 (WAS 6.0.2.9) /MQ6
WPS 6.0.1.2
SAP XI
SAP
MQ6
ITSOWPS2SAPXI_JMS
ESB2XI_Request
ITSOESB2SAPXI_JMS
XI2ESB_Response
ITSO_IBM_1
ITSO_SAP_2
ITSO_SAP_3
7.6.2 Configuration
For this scenario, use the same WebSphere MQ queues and create the same
destinations and JMS resources on the WebSphere Process Server V6.0 server
that we describe in 7.4.2, Configuration on page 520.
626
7.6.3 Development
This section describes how to create a process component that communicates
with the Mediation Module that you created in Scenario A.
The section includes the following steps:
Creating an SCA export of the Mediation Module that was used in scenario A.
Creating a Mediation Module for the process component.
Implementing the Business Process.
Exporting the UserExist_JMSMediationFlow as SCA

component
This section describes how to generate an export a component from a Mediation
Flow component so that it can be used later to expose the functionality of the
Mediation Flow in another Module project. Follow these steps:
1. Open the Assembly Diagram for ITSOESB2SAPXI_JMS.
2. In the Assembly Diagram, right-click UserExist_JMSMediationFlow and
select Generate Export SCA Binding as shown in Figure 7-178.
Figure 7-178 Generate UserExist_JMSMediationFlow SCA export
627
3. Verify that the Assembly Diagram looks as shown in Figure 7-179.
Figure 7-179 Assembly Diagram overview after SCA export
Creating a Module project

To create a Module project that include the process component, follow these
steps:
1. From the Business Integration View right-click the empty area and select
Figure 7-180 Module creation
628
2. Enter ITSOWPS2SAPXI_JMS as the Module Name as shown in Figure 7-181.

3. Click Finish to create the project.
Figure 7-181 Module properties
629
Assigning Library to Module project

The next task is to link the Library ITSO2SAPXI_JMSLib to the Module
ITSOWPS2SAPXI_JMS. Follow these steps:
1. RIght-click the ITSOWPS2SAPXI_JMS project and select Open
Dependency Editor.
Figure 7-182 Open dependency editor
2. Click Add.
3. From the Library Selection dialog box, select ITSO2SAPXI_JMSLib.
4. Click OK. The dependency editor looks as shown in Figure 7-183.
Figure 7-183 Configured the required libraries
630
Creating a business process

The next task is to create a new BPEL process, UserExistenceCheck.The
UserExistenceCheck uses the UserQueryResponseInterface interface. To create
a business process, follow these steps:
1. From the Business Integration View expand ITSOSAPXI2WPS_JMS.
2. Right-click Processes and select New Business Process as shown in
Figure 7-184.
Figure 7-184 Business process creation
3. In the New Business Process dialog box, clear Default.

4. Enter http://ibm.com/itso/sg247220 as the Namespace.
5. Enter UserExistenceCheck as the Name as shown in Figure 7-185.
6. Click Next.
Figure 7-185 Business process properties
631
7. At the Select an interface dialog box, click Select an existing Interface as

8. For the Interface field, click Browse.
Figure 7-186 Select an existing interface
632
9. At the Interface Selection prompt, select UserQueryResponseInterface as

shown in Figure 7-187. Then, click OK.
633
10.The Select an Interface dialog box now looks as shown in Figure 7-188. Click
Finish to complete the creation of the business process.
Figure 7-188 Business process overview
Implementing the UserExistenceCheck BPEL process

To implement the UserExistenceCheck BPEL process, follow these steps:
1. In the Business Process Editor, expand the Palette and select the invoke
activity icon as shown in Figure 7-189.
Figure 7-189 Select the invoke icon from the palette
2. Click under Receive activity to add invoke to the business process.
634
3. Set a Partner to the invoke activity by selecting the Invoke activity. Then, click
Set Partner to create a partner that is associated to the invoke activity as
Figure 7-190 Set a partner to the invoke activity
635
4. At the Select a Partner dialog box:

a. Click New. At the New Partner prompt, enter UserExistPartner and click
OK.
b. The dialog box now looks as shown in Figure 7-191. Click OK.
Figure 7-191 Select UserExistPartner
c. On the right side of your Business Process Editor, select

UserExistPartner as shown in Figure 7-192.
Figure 7-192 Select UserExistPartner
d. In the Properties View (lower pane), select the Details properties tab and
click Browse reference interface.
636
e. In the Interface Selection dialog box, select

UserQueryResponseInterface as shown in Figure 7-193. Then, click
OK.
f. Examine properties of the UserExistPartner using Figure 7-194.
Figure 7-194 UserExistPartner details
5. In the Business Process Editor, select the invoke activity and in the Properties
View select the Details tab.
6. In the Operation field, use the drop-down menu to select the operation
userQueryResponse.
637
7. For the Input(s) variable, click the ellipses (...) button. At the Select variable
for UserInput prompt, select UserInput as shown in Figure 7-195. Then, click
OK.
Figure 7-195 Select variable for UserInput
638
8. For the Output(s) variable, click the ellipses (...) button. At the Select variable
for UserResponse prompt, select UserResponse as shown in Figure 7-196.
Then, click OK.
Figure 7-196 Select variable for UserResponse
9. Examine the properties of the invoke activity for the business process using
the Figure 7-197.
Figure 7-197 Invoke activity properties
639
Assembling the Module project

To assemble the Module project, follow these steps:
1. From the Business Integration View, double-click ITSOWPS2SAPXI_JMS to
open its Assembly Diagram.
2. Select UserExistenceCheck BPEL in the Business Integration View, and
drag-and-drop it onto the Assembly Editor as shown in Figure 7-198.
Figure 7-198 Drag-and-drop business process onto the Assembly Diagram
640
The Assembly Diagram now looks like Figure 7-199.
Figure 7-199 Assembly Diagram
641
3. Expand the ITSOESB2SAPXI_JMS project, select

UserExist_JMSMediationFlowExport, and drag-and-drop it onto the
Assembly Diagram of ITSOWPS2SAPXI_JMS as shown in Figure 7-200.
Figure 7-200 Drag-and-drop UserExist_JMSMediationFlowExport onto Assembly Diagram
642
4. A window prompt opens. From this window prompt, select import with SCA
Binding as shown in Figure 7-201. Then, click OK.
Figure 7-201 Select Import with SCA Binding
643
5. Wire UserExistenceCheck to Import1 as shown in Figure 7-202.
Figure 7-202 Wire UserExistenceCheck to import1
7.6.4 Deployment
The deployment to the WebSphere Process Server does not differ from the
deployment on a WebSphere Enterprise Service Bus. To deploy to WebSphere
Process Server, follow these steps:
1. Start the WebSphere Process Server from WebSphere Integration Developer
by selecting the Servers tab. Then, select WebSphere Process Server v6.0
server and right-click and select Start.
644
2. If the server is started, right-click WebSphere Process Server v6.0 and

3. Select the project ITSOWPS2SAPXI_JMS on the left and click Add to move it
to right. Refer to Figure 7-204.
Figure 7-204 Add projects
645

This section illustrates the execution and test of the created SCA module in a
WebSphere Process Server environment. You can use BPC Explorer to test the
modules. In this test, you do a simple call to SAP Exchange Infrastructure to
check whether a user is known in the SAP system. Follow these steps:
1. Right-click the WebSphere Process Server v6.0 entry and select Launch
BPC Explorer.
Figure 7-205 Launch BPC Explorer
This action starts the BPC Explorer, which is integrated in the WebSphere
Integration Developer environment (Figure 7-206).
Figure 7-206 BPC Explorer welcome page
646
2. Select My Process Templates.

3. Select the UserExistenceCheck process Template and click Start Instance
Figure 7-207 Start UserExistenceCheck instance
4. Enter ITSOUSER as USERNAME and click Submit as shown in Figure 7-208.
Figure 7-208 Submit
647
The result is shown in Figure 7-209.
Figure 7-209 Test results
7.6.6 Conclusion
This extension demonstrates how you can use WebSphere Process Server as a
JMS consumer in a context where SAP Exchange Infrastructure acts as a JMS
provider. From the SAP Exchange Infrastructure, the configuration does not
distinguish whether the JMS consumer is WebSphere Enterprise Service Bus or
WebSphere Process Server. For demonstration purposes, this extension
scenario reuses the Mediation Module that was created in scenario A. However,
the JMS import that was created in the Mediation Module can also be directly
created in the module.
648
7.7 Extension B: WebSphere Process Server as a JMS

provider
In this example, you reuse the business objects, interface, JMS export, and Java
component that was created in scenario C when WebSphere Enterprise Service
Bus was the JMS provider. The new module that you create in this section also
includes a simple business process that is used to invoke the Java component.
WebSphere Process Server and WebSphere Integration Developer, REDP-4041,
which is available at:

In this scenario, SAP Exchange Infrastructure uses Java Message Service to
connect to WebSphere Enterprise Service Bus. The SAP system calls the
BAPI_USER_GETLIST, which is connected to SAP Exchange Infrastructure.
Then, SAP Exchange Infrastructure requests user information by generating a
message to WebSphere MQ. WebSphere Process Server then generates the
response and puts it in a WebSphere MQ queue. Refer to Figure 7-210.
SAP
SAP XI
WPS 6.0.1.2 (WAS 6.0.2.9)
SCA
X12ESB_Request
BAPI_USER_GETLIST
ITSOSAPXI2WPS_JMS
ESB2XI_Response
ITSO_SAP_3
ITSO_SAP_2
ITSO_IBM_1
649
Attention: This is the setup that we used for this book. The operating system
7.7.2 Configuration
You can use the same WebSphere MQ queues and create the same
destinations and JMS resources on the WebSphere Process Server v6.0 server
that we describe in 7.5.2, Configuration on page 560.
7.7.3 Development
with SAP Exchange Infrastructure. It includes:
Creating a Mediation Module for the process component that reuses the
same objects as described in scenario C.
Implementing the Business Process.
Creating a module project

This section explains how to create a module project that reuses the same
artifacts created in scenario C. Follow these steps:
1. From the Business Integration View right-click the empty area and select
Figure 7-211 Create a Module project
650
2. Enter ITSOSAPXI2WPS_JMS as the Module Name as shown in Figure 7-212.

Then, click Finish.
Figure 7-212 Project properties
651
3. The creation of business objects, interface, UserListJMS_Export, and

UserList_POJO is exactly as described in 7.5.3, Development on page 571
when WebSphere Enterprise Service Bus is a JMS provider. After following
the steps to create business objects, the workspace now looks like
Figure 7-213.
Figure 7-213 Assembly Diagram overview
652
Creating a business process

The next task is to create a new BPEL process, UserList. The UserList utilizes
the UserListInterface interface. To create a business process, follow these steps:
1. From the Business Integration View expand ITSOSAPXI2WPS_JMS.
2. Right-click Processes and select New Business Process as shown in
Figure 7-214.
Figure 7-214 Create a business process
3. In the New Business Process dialog box, clear Default.

4. Enter http://itso.ibm.com/sg247220 as the Namespace.
5. Enter UserList as the Name as shown in Figure 7-215. Then, click Next.
Figure 7-215 Business process properties
653
6. At the Select an Interface dialog box, click Select an existing Interface.

7. For the Interface field, click Browse as shown in Figure 7-216.
Figure 7-216 Select an existing interface
654
8. At the Interface Selection prompt, select UserListInterface inside the

matching interfaces as shown in Figure 7-217. Then, click OK.
9. The Select an interface dialog box now looks like Figure 7-218. Click Finish
to complete the creation of the business process.
Figure 7-218 Business process overview
655
Implementing UserExistenceCheck BPEL Process

To implement the UserList BPEL process, follow these steps:
1. In the Business Process Editor, expand the Palette and select the invoke
activity icon as shown in Figure 7-219.
Figure 7-219 Select the invoke icon from the palette
2. Click under the Receive activity to add invoke to the business process.
3. Set a Partner to the invoke activity by selecting the invoke activity. Then, click
the Set Partner to create a partner that is associated to the invoke activity as
Figure 7-220 Set a partner to the invoke activity
656
4. At the Select a Partner dialog box:

a. Click New.
b. At the New Partner prompt, enter UserListPartner. Then, click OK.
c. The dialog box now looks like Figure 7-221. Click OK.
Figure 7-221 Select a matching partner
d. On the right side of your Business Process Editor, select UserListPartner

Figure 7-222 Select UserListPartner
e. In the Properties View (lower pane), select the Details properties tab, and
click Browse for reference interface.
657
f. In the Interface Selection dialog box, select the UserListInterface

g. Click OK. Examine the properties of the UserListPartner using the

Figure 7-224.
Figure 7-224 UserListPartner details
5. In the Business Process Editor, select the invoke activity, in the Properties
View select the Details tab.
6. In the Operation field, use the drop-down menu to select the operation
getUserList.
658
7. For the input variable, click the ellipses (...) button. At the Select variable for
userinput prompt, select Userinput as shown in Figure 7-225. Then, click
OK.
Figure 7-225 Select variable for userinput
659
8. For the output variable, click the ellipses (...) button. At the Select Variable for
useroutput prompt, select Useroutput as shown in Figure 7-226. Then, click
OK.
Figure 7-226 Select variable for useroutput
9. Examine properties of the invoke activity for the business process using
Figure 7-227.
Figure 7-227 Invoke activity properties
10.Click File Save.
660
Assembling the module project

To assembling the module project, follow these steps:
1. From Business Integration View,double-click ITSOSAPXI2WPS_JMS to
open its Assembly Diagram.
2. Select UserList BPEL in the Business Integration View and drag-and-drop it
onto the Assembly Editor as shown in Figure 7-228.
Figure 7-228 Drag-and-drop the business process onto the Assembly Diagram
3. Wire the UserListJMS_Export export component to UserList as shown in

Figure 7-229.
Figure 7-229 Wire the UserListJMS_Export export component to the UserList
4. Then wire the UserList BPEL process to UserList_POJO as shown in

Figure 7-230.
Figure 7-230 Wire the UserList BPEL process to the UserList_POJO
661
5. Click File Save to save the changes.

6. Now click Project Build All to build the project.
7.7.4 Deployment
This section illustrates how to deploy the created Mediation Module in a
WebSphere Process Server environment. Follow these steps:
selecting the Servers tab. Then, select WebSphere Process Server v6.0
server and right-click and select Start.
2. If the server is started, right-click WebSphere Process Server v6.0 and
662
3. Select the project ITSOSAPXI2WPS_JMS on the left and click Add to move it
to right as shown in Figure 7-232.
4. Click Finish to deploy the project ITSOSAPXI2WPS_JMS.

This section describes how to test WebSphere Process Server with SAP
Exchange Infrastructure. It is divided into two parts:
Describes how to unit test WebSphere Process Server on its own. In this
case, RFHUTIL is used to put a message in the XI2ESB_Request queue.
Testing from SAP
Describes how to test the complete solution starting by calling the
BAPI_USER_GETLIST from the SAP back-end system, which then
communicates with SAP Exchange Infrastructure using the RFC destination
663
ITSO_XI_TO_PROCESS_ESB.SAP that acts as a JMS consumer that writes

a message in the XI2ESB_Request queue.

To test the scenario, RFHUTIL is used to put a message in the XI2ESB_Request
queue. You can find more information about RFHUTIL at the following Web site:
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24000637&loc=en_
US&cs=utf-8&lang=en
To test using RFHUTIL, follow these steps:
1. Load the request message in the XI2ESB_Request queue:
a.
b.
c.
d.
e.
Run rfhutil.exe.
Select the Main tab.
Enter ItsoQmgr2 as Queue Manager Name.
Enter XI2ESB_Request as Queue Name.
Click Read File and load the file ItsoSAPXI2WPS.xml.
2. After loading the file, select the Data tab.

3. Then select XML as Data Format as shown in Figure 7-233.
4. Configure the RFH2 header information.

You need to configure the RFH2 header for the request message following
the selection of the Business Object XML using JMS TextMessage field
during the generation of the JMS export binding.
664
To configure the RFH2 header information, follow these steps:

a. Select the jms tab and select text as the JMS Message Type as shown in
Figure 7-234.
Figure 7-234 Select text as JMS Message Type
b. Select the RFH tab and select Version 2 as the RFH Type as shown in
Figure 7-235.
Figure 7-235 Select Version 2 as the RFH Type
5. Then select the Main tab and click Write Q to put the message in the
XI2ESB_Request queue.
6. WebSphere Process Server then processes the message and generates the
response message in the ESB2XI_Response queue.
665
7. Read the response message:

a. Using rfhutil.exe, enter ItsoQmgr2 as Queue Manager and
ESB2XI_Response as Queue Name.
b. Select Start Browse.
c. Select the Data tab and XML as Data format. The window now looks like
Figure 7-236.
Figure 7-236 Response message
666
Testing from SAP

To test the scenario from SAP, the function module BAPI_USER_GETLIST is
used. Follow these steps:
1. Execute the transaction /nse37.
2. In the Function Builder: Initial Screen dialog box, enter BAPI_USER_GETLIST as
a Function module. Then, click the Test/Execute icon.
3. In the Test Function Module:Initial Screen dialog box, follow these steps:
a.
b.
c.
d.
Enter ITSO_XI_TO_PROCESS_ESB as a RFC target sys.

Enter 4 in the MAX_ROWS field.
Enter X in the WITH_USERNAME field as shown in Figure 7-237.
Click the Execute icon.
Figure 7-237 Test Function Module: Initial Screen
667
4. The result displays and the dialog box now looks like Figure 7-238.
Figure 7-238 Test Function Module results
5. Click the USERLIST Result to display the list of users as shown in

Figure 7-239.
Figure 7-239 Display USERLIST results
668
7.7.6 Conclusion
This extension demonstrates how you can use WebSphere Process Server as a
JMS provider in a context where SAP Exchange Infrastructure acts as a JMS
client. From the SAP Exchange Infrastructure the configuration does not
differentiate whether the JMS provider is WebSphere Enterprise Service Bus or
669
670
Chapter 8.
JMS-based integration
scenarios between
and SAP Exchange
Infrastructure
This chapter documents in detail how to connect WebSphere Message Broker to
SAP Exchange Infrastructure using reliable communication that is based on JMS
with WebSphere MQ as a messaging provider. This topic is illustrated by means
of two scenarios in which WebSphere Message Broker acts as a Service
Provider as well as a Service Consumer.
We begin this chapter with an overview of the scenarios. After that, we provide a
short introduction of how to configure scenarios within Message Broker and then
give a detailed description of how to prepare the Message Broker environment.
Finally, we document the detailed configuration of the two scenarios, which you
can set up independently and run concurrently.
671
This chapter includes the following topics:

An overview of how to configure scenarios in WebSphere Message Broker
on page 675
Preparing the Message Broker Environment on page 677
Scenario A: Configure the JMS outbound scenario in WebSphere Message
Broker on page 685
Scenario B: Configure the JMS inbound scenario in WebSphere Message
Broker on page 739
Configuring the scenario on page 741

In 4.3, Implemented integration scenarios in this book on page 124, we identify
two integration scenarios between WebSphere Message Broker and SAP
Exchange Infrastructure that are based on a request and reply pattern using
two-way JMS based communication. While we introduced the SAP Exchange
Infrastructure part of the two scenarios in 5.7, Configuring the JMS outbound
scenarios in SAP Exchange Infrastructure on page 210 and 5.8, Configuring
the JMS inbound scenarios in SAP XI on page 264, this chapter documents how
to configure the complement in WebSphere Message Broker.
In detail this chapter discusses:
8.4, Scenario A: Configure the JMS outbound scenario in WebSphere
Message Broker on page 685
Introduces the ItsoConsumeJmsServiceFromXi scenario in which
WebSphere Message Broker consumes a service that is provided by SAP
Exchange Infrastructure. The request message of this service is defined by
the XML schema file BapiUserExistenceCheckQuery_MT.xsd, while the
response message is defined by the XML schema file
BapiUserExistenceCheckResponse_MT.xsd. For providing an adequate test
environment, the example is extended by Web Service Interface that triggers
the generation of the JMS request messages and visualizes its respective
response. Refer to Figure 8-1.
672
BapiUserExistenceCheckQuery_MT.xsd
WebSphere
Application
Server
SOAP
WebSphere
Message
Broker
SAP Exchange
Infrastructure
JMS
RFC
SAP ERP 5.0
BapiUserExistenceCheckResponse_MT.xsd
Figure 8-1 JMS outbound scenario ItsoConsumeJmsServiceFromXi
8.5, Scenario B: Configure the JMS inbound scenario in WebSphere

Message Broker on page 739
Introduces the JmsProvideJmsServiceToXi scenario in which WebSphere
Message Broker acts as a JMS Service Provider to SAP Exchange
Infrastructure. Thereby the request message is defined by the XML schema
file UserListRequestBO.xsd while the response message is determined by
UserListResponseBO.xsd. For testing purposes, the scenario retrieves test
data from a DB2 based database. Refer to Figure 8-2.
UserListRequestBO.xsd
SAP ERP 5.0
RFC
SAP Exchange
Infrastructure
JMS
WebSphere
Message
Broker
JDBC
DB2
UserListResponseBO.xsd
Figure 8-2 JMS inbound scenario ItsoProvideJmsServiceToXi
Note that from the perspective of WebSphere Message Broker, SAP Exchange
Infrastructure is just another JMS Service Consumer or Provider and vice versa,
connected by a contract that is defined in terms of XML schema files. The
description of both scenarios is self-contained, so that the reader can configure
them independently.
For a general overview of how to configure scenarios in WebSphere Message
Broker, see 8.2, An overview of how to configure scenarios in WebSphere
Message Broker on page 675.
Chapter 8. JMS-based integration scenarios between WebSphere Message Broker and SAP Exchange Infrastructure
673
This environment rests upon the system landscape depicted in Figure 8-3.
WebSphere Message Broker and its components are installed on node
ITSO_IBM_2. For testing the JMS inbound scenario, DB2 Enterprise Server
Edition is installed on this node additionally. The test of the JMS outbound
scenario is triggered by a Web Service client that is deployed on a WebSphere
Application Server on node ITSO_IBM_3. Both JMS scenarios rely on SAP
Exchange Infrastructure running and configured on node ITSO_SAP_2 as well
as an SAP ECC instance on node ITSO_SAP_3.
ITSO_IBM_2
ITSO_SAP_2
WebSphere Message Broker Toolkit

V 6.0.0.1

3.0 SP 18

V 6.0.0.2
WebSphere MQ Client
V 6.0
WebSphere MQ
V 6.0

SE 1.4.2_11

V 8.1.7

V 9.2.0.1
Microsoft Windows Server 2003 SP1
ITSO_SAP_3
ITSO_IBM_3

5.0

V 6 Test Environment Update 6.0.2.5

V 8.2

V 6.0.1.1
Figure 8-3 System Landscape of the test environment
674
8.2 An overview of how to configure scenarios

in WebSphere Message Broker
The goal of configuring a scenario in WebSphere Message Broker is to connect
different systems, maybe business systems or self-developed applications, to
exchange business data or provide cross-system business processes between
systems that might distinguish themselves using different protocols and data
formats or even semantically data models. This section provides a short
introduction into the essential elements of building integration scenarios in
WebSphere Message Broker. Refer to Figure 8-4.
Message set
Message flow
Configuration
Manager
Broker
Queue
Manager
Figure 8-4 Elements of configuring and executing a scenario using message broker
The logic of an integration scenario is defined by a message flow. A message flow

is a sequence of processing steps that executes in a broker when an input
message is received. The processing steps are made up of nodes, either built-in
or user defined, representing major building blocks such as:
Input nodes that represent the receiving of a message from an external or
internal instance using different protocols, as for instance receiving a
message from an input queue, called a MQInput node, or from a HTTP
request.
Output nodes representing for example the sending to an external instance
using HTTP or a queue or storing data internally in a queue. An output node
representing the access to a queue is called a MQOutput node.
Transformation nodes for providing common processing logic, such as
transforming and enriching data, routing data between different nodes or
calling external devices.
Other nodes for decision making or error processing.
A message flow starts by an incoming message that is received by an input
node. The incoming message is transformed into an internal logical tree-based
675
format, before it travels through the message flow along the connections
between the nodes which define the data and control flow. Along its way, a
message is manipulated before it is finally submitted using an output node.
Different mechanisms exist for implementing data and control manipulations
such as:
ESQL, which is an extension of the Structured Query Language (SQL).
Java with respective set of libraries for navigating and manipulating the
internal message tree.
Mapping nodes that support mappings of the fields of an input message to
those of an output message using graphical elements.
The structure of messages processed within a flow can be specified by a
message set. A message set comprises both a physical and a logical format
definition. The physical format defines the exchange format of a message, for
example Tagged Delimited Strings or XML. The logical format defines the actual
message structure in a message definition file. Associating a message set with
nodes of a message flows supports validation of the messages to be processed
by that flow.
The design elements introduced above are specified using the Message Brokers
Toolkit, which is an eclipse-based development environment providing special
editors and tools for defining message flows, message sets, and subsuming
them into projects.
In addition, the toolkit provides an administration perspective for deploying the
design artifacts on the broker, where they are actually executed. The Toolkit is
not directly connected to the broker but uses the configuration manager as a link
in between. The configuration manager stores configuration details in an internal
configuration repository providing a central store for the resources deployed on
the broker. The configuration manager then is responsible for deploying of
message flows to the broker.
Note that multiple brokers on different machines can be subsumed under one
broker domain in which case one and only one configuration manager is
responsible for storing all the configuration data and deploying to all the brokers
in the domain.
Finally, the communication between the toolkit, configuration manager and
broker is based on messaging using queues that are managed by a WebSphere
MQ queue manager. Also the predominant computational paradigm is based on
WebSphere MQ.
676
8.3 Preparing the Message Broker Environment

Chapter 7, JMS-based integration scenarios between WebSphere Enterprise
Service Bus and SAP Exchange Infrastructure on page 495 introduced the
essential elements of a scenario that is configured within WebSphere Message
Broker. In that chapter, we also discuss the architectural elements.
This chapter documents the messaging runtime environment on node
ITSO_IBM_2 to which the scenarios are to be deployed. As introduced in the
previous section, this runtime consists of the configuration manager, the broker
and the queue manager. In addition, a database is required for storing all the
configuration data as well as the test data that are required by the JMS inbound
scenario. For deploying integration applications to the runtime environment, a
domain connection ItsoConnection has to be configured within the Message
Brokers Toolkit as the development environment. Refer to Figure 8-5.
ITSO_IBM_2
Configuration Manager
ItsoConnection
ItsoConfigMgr
Queue Manager
ItsoQmgr1
Database
brkdb2
Broker
ItsoBrk
Figure 8-5 Entities in Message Broker on node ITSO_IBM_2
The following description assumes that WebSphere Message Broker,

WebSphere MQ and DB2 is installed on ITSO_IBM_2.
A very good overview of how to install a WebSphere Message Broker
environment is available in the WebSphere Message Broker Basics, SG24-7137,
which you can download from the following Web site:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247137.pdf
677
8.3.1 Setting up the queue manager

As a first step, you need to create the Queue Manager, common queue, and a
server-connection channel using the WebSphere MQ Explorer. After that, the
configuration of the broker, its database, and the configuration manager are
documented. To set up the queue manager, follow these steps:
1. Select Start Programs IBM WebSphere MQ WebSphere MQ
Explorer to open the WebSphere MQ Explorer.
2. Open the folder IBM WebSphere MQ in the left pane of the WebSphere MQ
Explorer, select Queue Managers and select New Queue Manager from
its context menu. Refer to Figure 8-6.
Figure 8-6 New queue manager
3. In the Create Queue Manager dialog box, enter ItsoQmgr1 as the name of the
new queue manager, specify DEAD_LETTER_QUEUE as the dead letter queue of
the queue manager. Refer to Figure 8-7.
Figure 8-7 Enter name of new queue manager
678
4. Click Next until step 4 is displayed. Select Create listener configured for
TCP/IP and enter 3414 as the listener port. Click Finish to create and start the
new queue manager. Refer to Figure 8-8.
Figure 8-8 Specify listener port
5. Again in the WebSphere MQ Explorer, select the Queues folder of the new
queue manager ItsoQmgr1 and select New Local Queue from its context
menu as shown in Figure 8-9.
Figure 8-9 Create local queue
6. Enter the name DEAD_LETTER_QUEUE and click Finish as shown in Figure 8-10.
Figure 8-10 Enter name of new queue
679
7. Repeat the previous two steps to create the queues as listed in Table 8-1.
Table 8-1 Local Queues required for the scenarios
Queue name
Scenario
WMB2XI_Request
ItsoConsumeJmsServiceFromXi
XI2WMB_Response
ItsoConsumeJmsServiceFromXI
STORE_CALL_STATE
ItsoConsumeJmsServiceFromXI
XI2WMB_Request
ItsoProvideJmsServiceToXi
WMB2XI_Response
8. Open the folder Advanced in the left pane of the WebSphere MQ Explorer,
click Channels and select New Server-connection Channel from its
Figure 8-11 Create a server connection channel
9. Enter all.clients as the name of the new channel (Figure 8-12) and click
Next.
Figure 8-12 Enter name of server-connection channel
680
10.Select MCA in the all.clients - Properties dialog box and enter a name of a
local operating system user, here mymquser, under which the message
channel agent of this channel runs (Figure 8-13). Ensure that the user is a
member of the local groups mqm and mqbrks. Click Finish.
Figure 8-13 Enter MCA user ID
8.3.2 Configuring the broker and configuration manager

The message broker runtime components configuration manager, broker, and
database are created from a command console. To configure the broker and
configuration manager, follow these steps:
1. Open the command console by selecting Start Programs IBM
WebSphere Message Brokers 6.0 Command Console.
2. Create a broker database brkdb2 on DB2 Universal Database by executing
the following command in the command console:
mqsicreatedb brkdb2 -i myMbUserId -a myMbPwd -e db2
This command requires the following input parameters:
-i
-a
-e
an administrative user, enter myMbUserId

the password, enter myMbPwd
the database, enter db2
3. Create a configuration manager ItsoConfigMgr by executing the following

command in the command console:
mqsicreateconfigmgr ItsoConfigMgr -i myMbUserId -q myMbPwd -q
ItsoQmgr1
-i
-a
-q

the database, enter ItsoQmgr1
681
4. Create a broker ItsoBrk by executing the following command in the

command console:
mqsicreatebroker ItsoBrk -i myMbUserId -q myMbPwd -q ItsoQmgr1 -n
brkdb2
-i
-a
-q
-n
-e

the queue manager, ItsoQmgr1
the broker database, brkdb2
the database, enter db2
5. Start the configuration manager and broker, using the following commands:
mqsistart ItsoConfigMgr
mqsistart ItsoBrk
Alternatively, you can use the services entry from the operating systems
administrative console. Refer to Figure 8-14.
Figure 8-14 Services for broker and configuration manager
8.3.3 Configuring the domain connection

If the services are up and running, configure the domain connection, which is a
reference to a configuration manager and the broker in Message Brokers Toolkit.
To configure the domain connection, follow these steps:
1. Launch the Message Brokers Toolkit by selecting Start Programs IBM
WebSphere Message Brokers 6.0 WebSphere Message Brokers
Toolkit.
2. Open the Broker Administration Perspective in the toolkit by issuing
Window Open Perspective Broker Administration as shown in
Figure 8-15.
Figure 8-15 Open the broker administration perspective
682
3. Select Domain Connections in the Broker Administration Navigator and select

New Domain from its context menu as shown in Figure 8-16.
Figure 8-16 Create a new domain
4. In the Domain dialog box, enter ItsoQmgr1 as the name of the queue
manager for the domain, together with its port 3414 as shown in Figure 8-17.
Click Next.
Figure 8-17 Specify queue manager for domain
5. Enter ItsoConnection as the connection name and leave Servers as the

default for the server project as shown in Figure 8-18. Click Finish.
Figure 8-18 Enter project and connection name
683
6. As a result, a domain connection file ItsConnection.configmgr is created in

the Servers project. Refer to Figure 8-19.
Figure 8-19 Result of creating a domain
7. Again, click Domain Connections and select New Broker from its context
menu. Refer to Figure 8-20.
Figure 8-20 Add a broker to the domain
8. In the Broker dialog box, enter ItsoBrk as the Broker name and ItsoQmgr1 as
the Queue Manager Name (Figure 8-21). Click Next.
Figure 8-21 Specify the broker
684
9. In the Topology Configuration Deploy message window that displays, click

Delta, which specifies to deploy only those parts of a configuration that have
changed. Refer to Figure 8-22.
Figure 8-22 Specify the deployment
A response message indicates whether the broker has been added to the
domain connection successfully. In addition, an entry to ItsoBrk is added to
the displayed domain connection in the Domains view. Refer to Figure 8-23.
Figure 8-23 Result of adding a broker to the domain
The broker domain is now ready for configuring the scenarios.
8.4 Scenario A: Configure the JMS outbound scenario

in WebSphere Message Broker
In 5.7, Configuring the JMS outbound scenarios in SAP Exchange
Infrastructure on page 210, we presented an integration scenario that was
configured in SAP Exchange Infrastructure. That scenario provides a JMS
Service whose interfaces are defined by the XML schema files
BapiUserExistenceCheckQuery_MT.xsd and
BapiUserExistenceCheckResponse_MT.xsd.
This section describes how to consume the provided JMS within a scenario that
is configured in WebSphere Message Broker. We first provide an overview of the
685
configured scenario. Then, we give a detailed description of the various

configuration steps. Finally, we describe how to test the scenario end-to-end with
involvement of the scenario in SAP Exchange Infrastructure.
8.4.1 Overview of the configured scenario

The ItsoConsumeJmsServiceFromXi scenario consumes a JMS Service that is
provided by SAP Exchange Infrastructure. The scenario includes a message
flow, SynchSoapToAsynchJmsFlow, that extends the JMS communication to
SAP Exchange Infrastructure by a Web Services based front end that triggers
the execution of the message flow. Refer to Figure 8-24.
WMB2XI_Request
ItsoConsumeJmsServiceFromXi_Message_SetService
XI2WMB_Response
CheckNames
BapiUserExistenceCheckResponse_MT
Figure 8-24 Overview of message flow SynchSoapToAsynchJmsFlow
The flow, which is derived from the Web Service Host scenario that is provided
by the Message Brokers Toolkit samples gallery, consists of two paths. The first
path is initiated by a Web Services request that is received by a HTTP Input
node. The payload of the corresponding SOAP request is defined by the
message definition file set CheckNames, which is taken as the base for
generating the WSDL ItsConsumeJmsServiceFromXi_Message_SetService.
The node Create_XI_Msg creates a message of type
BapiUserExistenceCheckQuery_MT from the payload of the SOAP request.
Using the MQOutput node WMB2XI_Request, the created message is put into
the queue with the same name as the output node. From there the message gets
consumed by the counterpart of the JMS outbound scenario in SAP Exchange
Infrastructure.
The header of the SOAP request is further processed by the node
Create_Response_Header that extracts a request/response context and stores it
in a queue STORE_CALL_HEADER as a temporary container. We explain this
mechanism in more detail later.
686
The second path of the message flow is triggered by an incoming message in the
queue represented by the MQInput node XI2WMB_Response. This message is
a response to executing the counterpart of the JMS outbound scenario in SAP
Exchange Infrastructure. Node RETRIEVE_CALL_STATE takes this response,
retrieves the corresponding request/reply context from the temporary container
and forwards both, the payload of the response message and the
request/response context to node Create_Response_Msg. There the actual
SOAP response message is created before it is finally returned using the HTTP
Reply node.
The construction of the message flow supports concurrent execution of Web
Services calls. Basic to this construction is the mechanism for calling and
retrieving the request/response header from the queue STORE_CALL_STATE
as illustrated in Figure 8-25.
Node Create_XI_Msg transforms an incoming request message A into a
message A of structure BapiUserExistenceCheckQuery_MT before it forwards it
to the queue WMB2XI_Request. When the message flow forwards message A
to node Create_Response_Msg, a new message C is derived there, which is
stored in queue STORE_CALL_HEADER. Message C includes
A field CorrelationID which is assigned the value of field MessageID of
message A
A request/response context from the header of the original message A
When a response B to request message A is received in queue
XI2WMB_Response, node RETRIEVE_CALL_STATE retrieves the message C
from STORE_CALL_STATE by means of the value of field CorrelationID.
Message C together with message B is forwarded to node
Create_Response_Msg where an appropriate response message B is
constructed.
687
Request Message
Request A
WMB2XI_Request
Request A
...
...
MessageID
MessageID
Req/Resp-Context
...
...
STORE_CALL_STATE
Message C
Response Message
Response B
...
XI2WMB_Response
CorrelationID
Response B
Req/Resp-Context
...
CorrelationID
Req/Resp-Context
...
Get by CorrelationID
...
Figure 8-25 Correlating response with request message
The next section provides a detailed description of how to configure the scenario.
8.4.2 Configuring the scenario

This section defines the message set, which consists of message definition files
that are derived from the external XML schema files and those for the Web
Services call. It also introduces the message flow and explains how the
configured entities are deployed on the Message Broker.
Building message set and message definition files

To build message set and message definition files, follow these steps:
1. Open the Message Brokers Toolkit by selecting Start Programs IBM
Toolkit. Ensure that you are in the Broker Application Development
perspective.
688
2. Within the Message Broker Toolkit select New Message Set Project from
the file menu (Figure 8-26).
Figure 8-26 New message set project
3. The New Message Set Project dialog box opens. Enter

ItsoConsumeJmsServiceFromXi Message Set Project as the name for the new
project (Figure 8-27) and click Next.
Figure 8-27 Choose name for message set project
689
4. Enter ItsoConsumeJmsServiceFromXi_Message_Set as the name for the new

message set, select Use namespaces (Figure 8-28) and click Next.
Figure 8-28 Enter name for new message set
5. Define XML as the physical message format by selecting XML Wire Format
Name (Figure 8-29). The value XML1 is inserted as a default name for the
physical format. Click Finish.
Figure 8-29 Select XML wire format
690
6. The file messageSet.mset, which includes the specification of the physical

format of the messages within this message set, is opened in the Message
set editor as shown in Figure 8-30. In the Properties Hierarchy, click Message
Set and select XML1 as a Default Wire Format. Save the file.
Figure 8-30 Created message set project
The previous steps determined the physical format of the message set. Next
define its logical structure by importing the two XML schema files provided by
SAP Exchange Infrastructure.
7. Select the ItsoConsumeJmsServiceFromXI Message Set Project and select
File Import. Refer to Figure 8-31.
Figure 8-31 Start importing the XML schema files from SAP Exchange Infrastructure
691
8. In the Import dialog box, select File system as the import source and click
Next.
9. Navigate to the file system where you have stored the XML schema files
BapiUserExistenceCheckQuery_MT.xsd and
BapiUserExistenceCheckResponse_MT.xsd (see5.7.3, Exporting the XML
schema files on page 233) and select the files (Figure 8-32). Click Finish. As
a result, the two files are imported into the project folder.
Figure 8-32 Import resources from the local file system
692
10.Next, create a new message definition file from the imported XML schema
files. Select the message set project and select New Message Definition
File from its context menu as shown in Figure 8-33.
Figure 8-33 Create new message definition file
11.In the New Message Definition File dialog box, select XML schema file
(Figure 8-34) and click Next.
Figure 8-34 Select the message definition source
693
12.Select BapiUserExistenceCheckQuery_MT.xsd as the schema file

Figure 8-35 Select schema file
13.Select ItsoConsumeJmsServiceFromXi_Message_Set as the target

message set (Figure 8-36) and click Next.
Figure 8-36 Select target message set for new message definition file
694
14.Select BapiUserExistenceCheckQuery_MT as the global element within the

imported XML schema from which to create a message (Figure 8-37) and
click Finish.
Figure 8-37 Select global elements from which to create messages
15.As a result the file BapiUserExistenceCheckQuery_MT.mxsd is created within

the message set project. Open it to see how the external structure is reflected
within the message definition file as shown in Figure 8-38.
Figure 8-38 Imported message definition file
695
16.Apply step 10 to step 14 to the imported XML schema

BapiUserExistenceCheckResponse_MT to create a message definition file
BapiUserExistenceCheckResponse_MT.mxsd as shown in Figure 8-39.
Figure 8-39 Message definition file BapiUserExistenceCheckResponse_MT.mxsd
17.Next create the message definition file CheckNames. Select File New
Message Definition File either from the context menu of the project or from
the file menu as shown in Figure 8-33 on page 693. This time, select Create a
new message definition file (Figure 8-40) and click Next.
Figure 8-40 Create a new message definition file
696
18.Select ItsoConsumeJmsServiceFromXi_Message_Set as the message set

and enter CheckNames as the name of the new message definition file
(Figure 8-41). Click Next.
Figure 8-41 Choose message set and file name for new message definition file
697
19.Leave xsd as the default Prefix, select Use target namespace and enter a
namespace, for example http://sg247220.itso.ibm.com (Figure 8-42). Click
Finish.
Figure 8-42 Enter namespace http://sg247220.itso.ibm.com
20.When CheckNames.mxsd is opened in the Message Definition Editor, select

Messages and select Add Message from its context menu as shown in
Figure 8-43.
Figure 8-43 Add a message to CheckNames
698
21.As a result, a new entry is inserted under Messages. Rename it to

CheckNameIn as shown in Figure 8-44.
Figure 8-44 Enter name for message
22.Expand Types. Rename the entry complexType1, which was added

automatically, to CheckNameIn as shown in Figure 8-45.
Figure 8-45 Rename type to CheckNameIn
23.Still in the Message Definition Editor, select Elements and Attributes and
select Add Global Elements from its context menu as shown in Figure 8-46.
Figure 8-46 Add global element
699
24.A global element with a default name is added and highlighted. Rename it to
userName as shown in Figure 8-47.
Figure 8-47 Add global element UserName
25.Select the CheckNameIn in the Messages folder and select Add Element
Reference from its context menu as shown in Figure 8-48.
Figure 8-48 Add reference to global element
26.Select the new entry, which is created, and select tns:userName as shown in
Figure 8-49.
Figure 8-49 Select userName as element reference
700
27.Repeat steps 20 to 26 and apply them to the entries shown in Table 8-2.
Table 8-2 Add message CheckNameOut
Messages
Types
Elements and
Attributes
Element
Reference
CheckNameOut
CheckNameOut
userExistsMsg
CheckNameOut
tns:userExistsMsg
28.Ensure that the result looks like Figure 8-50. Save the definition.
Figure 8-50 Message definition file CheckNames.mxsd
701
The following steps document how to derive the WSDL for the Web Services
based frontend (refer to Figure 8-1 on page 673) from the message definition file
CheckNames.mxsd:
1. Start to create a new message definition file by selecting File New
Message Definition File either from the context menu of the project or from
the file menu (Refer to Figure 8-33). This time, select IBM supplied message
Figure 8-51 Create a new message definition file with IBM supplied source
2. Within the folder Message Brokers IBM supplied Message Definitions

select the one with ending soapenv11.xsd (Figure 8-52) and click Next.
Figure 8-52 Select the IBM supplied message
702
3. Select the message set ItsoConsumeJmsServiceFromXI_Message_Set,

accept soapenv11.mxsd as the message definition file name (Figure 8-53)
and click Finish.
Figure 8-53 Select target message set and enter message definition file name
703
4. As a prerequisite of generating a WSDL create a message category. Select

New Message Category File either from the context menu of the project
or from the file menu. Refer to Figure 8-54.
Figure 8-54 New message category file
704
5. Keep all the defaults on the first window of the dialog box Message Category
File and click Next. On the next panel select the target message set, accept
cat1 category file and click Next. Figure 8-55 opens.
Figure 8-55 Specify category name
705
6. Select CheckNameIn and CheckNameOut as the messages to be added to

the category. Ensure that CheckNameOut has the output kind. Refer to
Figure 8-56. Click Finish.
Figure 8-56 Select messages to add to the new category
7. As a result the file cat1.category is created and opened in the category editor.
Because you do not have to apply any changes, just close this file.
706
8. Create a new folder wsdl in ItsoConsumeJmsServiceFromXi Message Set

Project. Then select New WSDL Definition from the File menu as shown
in Figure 8-57.
Figure 8-57 Create WSDL Definition
9. In the New WSDL Definition dialog box, select the message set
ItsoConsumeJmsServiceFromXi_Message_Set and click Next as shown in
Figure 8-58.
Figure 8-58 Select message set folder for new WSDL Definition
707
10.Select wsdl as destination folder (Figure 8-59) and click Next.
Figure 8-59 Select destination for the WSDL to be generated
11.Enter http://ibm.com/itso/sg247220 as the namespace (Figure 8-60). Keep

all other defaults and click Next.
Figure 8-60 Specify WSDL details
12.Select cat1.category (Figure 8-61) and click Next.
Figure 8-61 Select category for which operations are created
708
13.Select the SOAP/HTTP as the bindings (Figure 8-62) and click Next.
Figure 8-62 Select bindings
14.Finally, the service properties of the WSDL display as shown in Figure 8-63.
Ensure that the Port Address includes the correct host name. Click Finish.
Figure 8-63 Specify service properties for SOAP/HTTP
15.As a result, the folder wsdl includes the generated WSDL file together with
the XML schema CheckName.xsd. Export the folder wsdl for building the
Web Services test client as described in 8.4.3, Testing the scenario on
page 733.
Figure 8-64 Generated WSDL
709
Building the message flow

This section illustrates how to create the message flow
SynchSoapToAsychJmsFlow, an overview of which was given in Figure 8-24 on
page 686. To build the message flow, follow these steps:
1. Start creating a new message flow project by issuing New Message Flow
Project from the file menu as shown in Figure 8-65.
Figure 8-65 New message flow project
2. Enter ItsoConsumeJmsServiceFromXi Message Flow Project as the project

name and click Next. Refer to Figure 8-66.
Figure 8-66 Enter ItsoConsumeJmsServiceFromXi Message Flow Project
3. Select ItsoConsumeJmsServiceFromXi Message Set Project as a

dependable project (Figure 8-67) and click Finish.
Figure 8-67 Specify dependency on respective message set project
710
4. Start creating a new message flow by selecting New Message Flow from
the file menu as shown in Figure 8-68.
Figure 8-68 New message flow
5. Select ItsoConsumeJmsServiceFromXi Message Flow Project as the

project for the new message flow, enter SynchSoapToAsynchJmsFlow as the
name (Figure 8-69) and click Finish.
Figure 8-69 Select project and name for new message flow
711
6. Open the new message flow in the Message Flow Editor, if it is not already
displayed there. Using the Palette in the left pane, add the following built-in
nodes to the canvas as shown in Figure 8-70.
1 HTTP Input node

3 Compute nodes
2 MQOutput nodes
1 MQInput node
1 MQget node
1 HTTPReply node
Figure 8-70 Create a message flow template
712
7. During the next steps, the message flow template is adjusted to the business
needs. Start by selecting the Compute node and select Rename from its
context menu as shown in Figure 8-71. Enter Create_XI_Msg as the new node
name and click OK.
Figure 8-71 Rename the Compute node
8. Rename all the other nodes as shown in Table 8-3.

Table 8-3 Rename nodes in message flow
Template node name
New node name
Compute
Create_XI_Msg
MQOutput
WMB2XI_Request
Compute1
Create_Response_Header
MQOutput1
STORE_CALL_HEADER
MQInput
XI2WMB_Response
MQGet
RETRIEVE_CALL_STATE
Compute2
Create_Response_Msg
713
9. Next create the connections between the various nodes. First, select the
HTTP Input node and select Create Connection from its context menu as
Figure 8-72 Start creating a connection
10.Select the Out terminal for the connection as shown in Figure 8-73 and click
OK. As shown in the figure, a node can have a different number of terminals
which can represent different results of processing in the node.
Figure 8-73 Select terminal for connection
11.Connect the Out terminal of HTTP Input to the In terminal of Create_XI_Msg

using the mouse pointer as shown in Figure 8-74.
Figure 8-74 Target of the connection
714
12.Create the additional connections as shown in Table 8-4.

Table 8-4 Create connections
Node name
Terminal
Connect to this node
Create_XI_Msg
Out
WMB2XI_Request
WMB2XI_Request
Out
Create_Response_Msg
Create_Response_Msg
Out
STORE_CALL_STATE
XI2WMB_Response
Out
RETRIEVE_CALL_STATE
RETRIEVE_CALL_STATE
Out
Create_Response_Msg
Create_Response_Msg
Out
HTTPReply
Note: The built-in nodes offer additional terminals for error, exception and
so on, to make the flow more resilient. However, these additional terminals
are not used here, because the main focus of the documented
configurations is on providing basic integration fucntionality.
The following steps define the properties of the input and output nodes and
customize the compute nodes.
13.Select the HTTP Input node and select Properties from its context menu as
Figure 8-75 Setting the properties of the HTTP Input node
715
14.In the HTTP Input Node Properties dialog box, select Basic in the left pane
and assign /wassoap/servlet/router to the URL Selector field as shown in
Figure 8-76.
Figure 8-76 Set the basic properties of HTTP Input
15.Click Default in the left pane and choose the values of the fields Message
Domain, Message Set, Message Type and Message Format from the
drop-down lists of the fields as shown in Figure 8-77. Click OK to save the
configurations.
Figure 8-77 Set the message properties of HTTP Input
716
16.Next customize the first compute node Create_XI_Msg. Click that node and
open Properties from its context menu. In the Compute Node Properties
dialog box, select Basic in the left pane and enter
SynchSoapToAsynchJmsFlow_Create_XI_Msg into the ESQL Module field as
shown in Figure 8-78. Click OK to save the configuration.
Figure 8-78 Enter the name of ESQL Module
17.Again click Create_XI_Msg and select Open ESQL from the context menu
Figure 8-79 Open ESQL
717
18.As a result, a template is created and opened in the ESQL editor. Change the
template to the code displayed in Figure 8-80. You can copy the ESQL
module from the Web material available to download (see Appendix A,
Additional material on page 1441).
Figure 8-80 ESQL module SynchSoapToAsynchJmsFlow_Create_XI_Msg
As explained in 8.4.1, Overview of the configured scenario on page 686,

node Create_XI_Msg is responsible for creating a WebSphere MQ message
of type BapiUserExistenceCheckQuery_MT from the SOAP request. This is
achieved by manipulating the internal logical tree structure into which a SOAP
request is transformed as soon as it is received within the message flow. The
details of the internal logical tree structure and its manipulation using ESQL
are beyond the scope of this book.
718
For more information about ESQL and the logical tree structure refer to
Message Flows handbook which you can download from:
http://www-306.ibm.com/software/integration/wbimessagebroker/library/
19.Click node WMB2XI_Request and open Properties from its context menu. In
the MQOutput Node Properties dialog box select Basic in the left pane and
enter ItsoQmgr1 as queue manager and WMB2XI_Request as the queue name
Figure 8-81 Set queue manager and queue name in properties of WMB2XI_Request
20.Select Advanced in the left pane. Set Transaction Mode to Yes and Message
Context to Default as shown in Figure 8-82. Click OK to save the
configuration.
Note: In contrast to the Web Services Host pattern, the request and
reply-to-queue properties are not configured in this scenario, because all
the queues to be used by SAP Exchange Infrastructure have to be
configured statically.
Figure 8-82 Set advanced properties of WMB2XI_Request
719
21.Open Properties from the context menu of the node

Create_Response_Header, in the Compute Node Properties dialog box,
change the name of the ESQL Module to
SynchSoapToAsynchJmsFlow_Create_Response_Header as shown in
Figure 8-83 and click OK.
Figure 8-83 Customer Create_Response_Header node
22.Click Create_Response_Header and select Open ESQL from the context

menu and adjust the code of the ESQL module
SynchSoapToAsynchJmsFlow_Create_Response_Header as depicted in
Figure 8-84 . The ESQL module is available for download from the reference
listed in Appendix A, Additional material on page 1441.
The module creates a message C as depicted in Figure 8-25 on page 688.
Again the details of the ESQL code depend on the structure of the internal
logical tree format and are beyond of the scope of this book.
720
Figure 8-84 ESQL Module SynchSoapToAsynchJmsFlow_Create_Response_Header
23.Click the STORE_CALL_STATE node and select Properties from its context
menu. Set ItsoQmgr1 as Queue Manager Name and STORE_CALL_STATE as the
Queue Name in the MQOutput Node properties dialog box as shown in
Figure 8-85.
Figure 8-85 Set queue manager and queue name for STORE_CALL_STATE
721
24.Select Advanced in the left pane and set Transaction Mode to Yes and
Message Context to Default as shown in Figure 8-86. Click OK to save the
configuration.
Figure 8-86 Set advanced properties of STORE_CALL_STATE
25.Click XI2WMB_Response node and select Properties from its context

menu. Select Basic and set the Queue Name to XI2WMB_Response as shown
in Figure 8-87.
Figure 8-87 Configure queue name for XI2WMB_Response
722
26.Select Default in the left pane and specify the Message Domain, Message
Set, Message Type and Message Format of the messages to be processed
by this node as depicted in Figure 8-88. Click OK to save the configuration.
Figure 8-88 Set message type to be processed by XI2WMB_Response
27.Open the Properties dialog box of node RETRIEVE_CALL_STATE and

specify the Queue Name STORE_CALL_STATE as a basic attribute as shown in
Figure 8-89.
Figure 8-89 Set queue name for RETRIEVE_CALL_STATE node
28.Select Default and specify the structure of the messages to be processed by

RETRIEVE_CALL_STATE as shown in Figure 8-90.
Figure 8-90 Structure of messages to be processed by RETRIEVE_CALL_STATE
723
29.Select Advanced and specify the attributes as shown in Figure 8-91. In

particular, ensure that Message and LocalEnvironment is assigned to
Generate Mode and Copy Entire Message to Copy Message.
Figure 8-91 Set advanced properties of RETRIEVE_CALL_STATE
30.Select Request and click Get by Correlation ID check box as shown in

Figure 8-92. This specification states that the CorrelationID of the incoming
message is used as a selector for retrieving an entry from the queue. Thus, a
request/response entry is retrieved that corresponds to the incoming
response message.
Figure 8-92 Configure Get by Correlation ID
724
31.Finally, select Result and assign OutputLocalEnvironment to the Output

Data Location attribute as shown in Figure 8-93. Click OK to save the
configured properties.
Figure 8-93 Set output data location
32.Open the Properties dialog box of the Create_Response_Msg node. In the

Basic sub-dialog box select LocalEnvironment and Message as a value for
Compute Node. Set SynchSoapToAsynchJmsFlow_Create_Response_Msg as
the name of the ESQL Module as shown in Figure 8-94. Click OK to save the
properties.
Figure 8-94 Set basic properties of Create_Response_Msg node
33.Open the ESQL Editor from the context menu of the Create_Response_Msg
node and specify the module
SynchSoapToAsynchJmsFlow_Create_Response_Msg as shown in
Figure 8-95. You can copy the ESQL module from the Web material available
to download (see Appendix A, Additional material on page 1441).
The module constructs a SOAP response message from the payload of the
message received by the node XI2WMB_Response and the
request/response context as processed by RETRIEVE_CALL_STATE.
725
Figure 8-95 ESQL Module SynchSoapToAsynchJmsFlow_Create_Response_Msg
Deploying message set and message flow

The following steps describe how to build a broker archive including the
configured message set and flow and deploy it on the broker. To deploy
message set and message flow, follow these steps:
1. Switch to the administration perspective in the Message Brokers Toolkit by
selecting Window Open Perspective Broker Administration as
Figure 8-96 Switch to the Broker Administration perspective
726
2. Expand Broker Archives, select the folder Servers and select New
Message Broker Archive from its context menu as shown in Figure 8-97.
Figure 8-97 Create Message Broker Archive
727
3. Ensure that Servers is selected in the Message Broker Archive dialog box,
enter ItsConsumeJmsServiceFromXi as the name of the broker archive and
click Finish. Refer to Figure 8-98.
Figure 8-98 Enter name of broker archive
728
4. The file ItsoConsumeJmsServiceFromXi.bar is created and opened in the

archive editor. Start adding deployable files by pressing the Add as shown in
Figure 8-99.
Figure 8-99 Add deployable files to the archive
5. In the Add to Broker Archive dialog box, choose

ItsoConsumeJmsServiceFromXi Message Flow Project and
ItsoConsumeJmsServiceFromXi_Message_Set as shown in Figure 8-100
and click OK.
Figure 8-100 Add to Broker Archive
729
6. The compiled message flow and message set as a dictionary file are added to
the broker archive. Refer to Figure 8-101. Save and close the broker archive.
Figure 8-101 Contents of broker archive ItsoConsumeJmsServiceFromXi.bar
7. Next start creating an execution group as a unit of deployment. In the

Domains view expand the configured broker domain ItsoConfigMgr and
ensure that it is connected to the respective configuration. If not, select
Connect from its context menu. Then select ItsoBrk and select New
Execution Group from its context menu as shown in Figure 8-102.
Figure 8-102 Start creating an execution group
730
8. Ensure that ItsoBrk is selected as the broker, enter

ItsoConsumeJmsServiceFromXi-ExecutionGroup as the Execution Group
Name as shown in Figure 8-103 and click Finish.
Figure 8-103 Enter execution group name
9. Click the broker archive ItsoConsumeJmsServiceFromXi.bar in the Broker

Administration Navigator view and select Deploy File from its context
Figure 8-104 Deploy broker archive
731
10.In the Deploy a BAR File dialog box, select the

ItsoConsumeJmsServiceFromXi-ExecutionGroup as shown in Figure 8-105
and click OK.
Figure 8-105 Select execution group where to deploy the bar file
11.As a result, the files that are included within the message broker archive
appears in the respective execution group folder. Refer to Figure 8-106.
Figure 8-106 Result of deployment
The last step finished the definition of the message flow. Proceed with testing it
as described in the next section.
732
8.4.3 Testing the scenario

Having configured ItsoConsumeJmsServiceFromXi in WebSphere Message
Broker, you can now test the overall JMS outbound scenario as depicted in
Figure 8-107. From the depicted components, only the Web Services client that
triggers the message flow in ItsoConsumeJmsServiceFromXi is left to be
configured.

WSClient4ItsoJmsConsume

ItsoConsumeJmsServiceFromXi
ItsoConsumeJmsServiceFromXi_Message_SetService.wsdl

SAP ECC 5.0
ItsoWmbJmsOutboundScenario
WMB2XI_Request
XI2WMB_Response
Figure 8-107 Testing the JMS outbound scenario
In the scenario documented here, the Web Services client is generated using
Rational Application Developer. As a graphical user interface for calling the Web
Services client, Java Server Pages are created as well and deployed on the
Before actually performing the test, ensure that:
The message set and flow of scenario ItsoConsumeJmsServiceFromXi is
deployed on WebSphere Message Broker.
ItsoWmbJmsOutboundScenario is active on SAP Exchange Infrastructure.
The queues WMB2XI_Request and XI2WMB_Response exist on queue
manager ItsoQmgr1.
The SAP ECC instance is up and running.
To test the scenario:
1. Start the Rational Application Developer on node ITSO_IBM_3 by issuing
Start Programs IBM Rational IBM Rational Application
Developer V6.0 Rational Application Developer.
733
2. Open the Preferences dialog box by selecting Window Preferences in the

Rational Application Developer. Expand Workbench, click Capabilities and
ensure that the check box Web Service Developer is selected as shown in
Figure 8-108.
Figure 8-108 Enable the Web Services Capabilities in the preferences dialog box
3. Switch to the Web perspective by selecting Window Open Perspective

Web as shown in Figure 8-109.
Figure 8-109 Switch to the Web perspective
4. Select New Dynamic Web Project to create the project for the Web
Service client as shown in Figure 8-110.
Figure 8-110 New dynamic Web project
734
5. In the New Dynamic Web Project dialog box, enter WSClient4ItsoJmsConsume

as the project name (Figure 8-111) and click Finish.
Figure 8-111 Enter name of dynamic Web project
6. Select the new dynamic Web project WSClient4ItsoJmsConsume and select

Import Import from its context menu as shown in Figure 8-112.
Figure 8-112 Import the WSDL
735
7. In the Import dialog box, select File system as the import source and click
Next. Browse to the shared drive that includes the wsdl folder as exported
from the Message Brokers Toolkit (Refer to Figure 8-64 on page 709) and
select the folder (Figure 8-113). Click Finish.
Figure 8-113 Select the import source
8. Open the imported WSDL file in the WSDL-Editor and ensure that the entry
soap:address refers to node ITSO_IBM_2 and port 7080. Refer to
Figure 8-114.
Figure 8-114 SOAP address of provided Web Service
736
9. Navigate to the imported WSDL file and select Web Services Generate
Client from its context menu as shown in Figure 8-115.
Figure 8-115 Generate Web Services client
737
10.In the Web Services Client dialog box, select Test the Web Service
Figure 8-116 Specify Web Service
11.Click Next again until the Client Environment Configuration panel is

displayed. Ensure that the settings are compliant with the ones shown in
Figure 8-117 and click Finish.
Figure 8-117 Environment settings for the Web Services client
The previous step generates the proxy to the given WSDL file. In addition it
creates Java Server Pages for testing the client and deploys them on the
integrated WebSphere Application Server. After a successful deployment, the
JSP TestClient.jsp is displayed in the integrated Web browser.
738
12.For testing the JMS outbound scenario, click cat1 in the Methods pane, enter
a name of a user that is registered on the SAP ECC instance and click Invoke
Figure 8-118 Test the Web Service
8.5 Scenario B: Configure the JMS inbound scenario in

In the JMS inbound scenario, WebSphere Message Broker provides a service
that is to be consumed by an integration scenario that is specified in SAP
Exchange Infrastructure. Whereas we discussed the SAP Exchange
Infrastructure part of the scenario in 5.8, Configuring the JMS inbound scenarios
in SAP XI on page 264, this section introduces in detail how to configure
WebSphere Message Broker to provide a JMS.
Note that in the JMS inbound scenario the interfaces between the different parts
are defined by WebSphere Message Broker. Therefore the configurations in this
section are a prerequisite for defining the respective scenario in SAP Exchange
Infrastructure.
This section starts with giving an overview of the configured scenario. Then a
detailed description of the various configuration steps is given. Finally the
scenario is tested end-to-end with involvement of the scenario in SAP Exchange
Infrastructure.
739
8.5.1 Overview of configured scenario

The scenario ItsoProvideJmsServiceToXi which defines a service in WebSphere
Message Broker that returns a specified number of user data. Request and
response messages are transmitted to and from the service using JMS with
WebSphere MQ as a transport. Figure 8-119 shows the message flow
ProvideJmsServiceFlow of the scenario. It consists of:
A MQInput node XI2WMB_Request representing the receiving of a JMS
request of type UserListRequestBO in queue XI2WMB_Request.
A MQOutput node WMB2XI_Response that returns a response message of
type UserListResponseBO in queue WMB2XI_Response.
A Compute node in between, which includes the central logic of the scenario,
consisting of taking the request as input to aggregate user data from a
database ITSOUSDB and returning the data as a response.
In this scenario, the database ITSOUSDB represents a downstream back-end
system. Thereby, access to the database from within the Compute node is
covered for demonstration purposes only because common patterns suggest
that message flows delegate back-end processing to external systems or
applications.
Besides aggregating user data, the Compute node also copies the value of the
header field JMSCorrelationId from the request message to the respective field
of the response message way. In this way, SAP Exchange Infrastructure is able
to correlate the response message as depicted in Figure 5-221 on page 267.
UserListRequestBO
UserListResponseBO
XI2WMB_Request
WMB2XI_Response
ITSOUSDB
Figure 8-119 Overview of message flow ProvideJmsServiceFlow
The types UserListRequestBO and UserListResponseBO of the request and

response messages are defined as message definition files within the Message
Brokers Toolkit. Their logical structure, illustrated in Figure 8-120, is identical to
the that defined in 7.5.3, Development on page 571. Using this approach, the
structure of a JMS Service consumer defined in SAP Exchange Infrastructure
can be sustained identical regardless of whether the JMS Service is provided by
WebSphere ESB or WebSphere Message Broker.
740
UserListRequestBO
amount
includeNames
UserListResponseBO
userList
username
UserInfoBO
firstName
lastName
fullName
Figure 8-120 Logical Structure of UserListRequestBO and UserListResponseBO
8.6 Configuring the scenario

This section defines the message set and message definition files for the request
and response messages. It also introduces the message flow and explains how
to deploy the configured entities on the Message Broker.
8.6.1 Building message set and message definition files

To build message set and message definition files, follow these steps:
1. Open the Message Brokers Toolkit by issuing Start Programs IBM
Toolkit. Ensure that you are in the Broker Application Development
perspective.
2. When the Message Broker Toolkit is opened, select New Message Set
Project from the file menu as shown in Figure 8-121.
Figure 8-121 New message set project
741
3. In the New Message Set Project dialog box, choose

ItsoProvideJmsServiceToXi Message Set Project as the Project Name as
shown in Figure 8-122 and click Next.
Figure 8-122 Choose name for message set project
4. Enter ItsoProvideJmsServiceToXi_Message_Set as the name for the new

message set, check Use namespaces as shown in Figure 8-123 and click
Next.
Figure 8-123 Enter name for new message set
5. Define XML as the physical message format by selecting XML Wire Format
Name as shown in Figure 8-124. The value XML1 is inserted as a default name
for the physical format. Click Finish.
Figure 8-124 Select XML wire format
742
6. The file messageSet.mset, which includes the specification of the physical

format of the messages within this message set, is opened in the Message
set editor. In the Properties Hierarchy click Message Set and select XML1 as
a Default Wire Format as shown in Figure 8-125. Save the file.
Figure 8-125 Created message set project
Next create the message definition file UserListRequestBO, whose logical

structure is displayed in Figure 8-120 on page 741.
7. Select File New Message Definition File either from the context menu
of the project or from the file menu (refer to Figure 8-33 on page 693). This
time, select Create a new message definition file as shown in Figure 8-126
and click Next.
Figure 8-126 Create a new message definition file
743
8. Select ItsoProvideJmsServiceToXi_Message_Set as the message set and

enter UserListRequestBO as the name of the new message definition file as
shown in Figure 8-127. Click Next.
Figure 8-127 Choose message set and file name for new message definition file
744
9. Leave xsd as the default Prefix, select Use target namespace and enter
http://itso.ibm.com/sg247220/UserListRequestBO as the Namespace as
shown in Figure 8-128. Click Finish.
Figure 8-128 Specify namespace for new message definition
10.When UserListRequestBO.mxsd is opened in the Message Definition Editor,

select Messages Add Message from its context menu as shown in
Figure 8-129.
Figure 8-129 Add a message to UserListRequestBO
745
11.As a result, a new entry is inserted under Messages. Rename it to

UserListRequestBO as shown in Figure 8-130.
Figure 8-130 Enter name for message
12.Expand Types. Rename the entry complexType1, which was added

automatically, to UserListRequestBO as shown in Figure 8-131.
Figure 8-131 Rename type to UserListRequestBO
13.Still in the Message Definition Editor, select UserListRequestBO and select

Add Local Elements from its context menu as shown in Figure 8-132.
Figure 8-132 Add local element
746
14.A local element with a default name is added and highlighted. Rename it to
amount and select int as its type from the drop-down list of the respective
field as shown in Figure 8-133.
Figure 8-133 Add local element amount
15.Repeat the previous two steps to create an additional field includeNames of

type boolean. Save the message definition file and close the editor.
16.Select File New Message Definition File in order to create the
message definition file UserInfoBO. Refer to Figure 8-33 on page 693.
a. Select Create a new message definition file and click Next. Refer to
747
b. Select ItsoProvideJmsServiceToXi_Message_Set as the message set,

enter UserInfoBO as the name of the new message definition file as
shown in Figure 8-134 and click Next.
Figure 8-134 New message definition file UserInfoBO
748
17.Select Use target namespace, enter

http://itso.ibm.com/sg247220/UserInfoBO as the Namespace as shown in
Figure 8-135, and click Finish.
Note: As mentioned in 8.5.1, Overview of configured scenario on
page 740, it is transparent to SAP Exchange Infrastructure whether
WebSphere Message Broker or WebSphere ESB as a JMS Service
provider. Hence the namespaces in the message types defined within
WebSphere Message Broker as well as WebSphere ESB must be
identical.
Figure 8-135 Enter namespace for UserInfoBO
18.When the message definition file UserInfoBO.mxsd is opened in the editor,

select Types Add Complex Type from the context menu as shown in
Figure 8-136.
Figure 8-136 Add complex type to UserInfoBO
749
19.Rename the created entry below Types to UserInfoBO. Select

UserInfoBO Add Local Element from its context menu as shown in
Figure 8-137.
Figure 8-137 Add local element to UserInfoBO type
20.Rename the created element to username and leave the default string type.
Create additional three local elements firstName, lastName, and fullName as
shown in Figure 8-138. Ensure that the Min Occurs entry for those elements
includes a 0. Save and close the definition.
Figure 8-138 Defined message definition UserInfoBO.mxsd
21.Select File New Message Definition File in order to create the

message definition file UserListResponseBO (refer to Figure 8-33 on
page 693).
a. Select Create a new message definition file and click Next. Refer to
b. Select ItsoProvideJmsServiceToXi_Message_Set as the message set,
enter UserListResponseBO the name of the new message definition file
and click Next.
750
c. Select Use target namespace, enter Q1 as Prefix and

http://itso.ibm.com/sg247220/UserListResponseBO as Namespace as
shown in Figure 8-139 and click Finish.
Figure 8-139 Enter namespace of UserListResponseBO
22.When the message definition file UserListResponseBO.mxsd is opened in the

editor view, select Messages Add Message from its context menu as
Figure 8-140 Add message to UserListResponseBO
751
23.Rename the generated message to UserListResponseBO. Do the same for

the generated entry in the Types folder as shown in Figure 8-141.
Figure 8-141 Rename message and type
24.Select the message UserListResponseBO

a. Select Add Local Element from its context menu.
b. Rename the element to userList.
c. Click in the corresponding Type field and select {More...} from the
drop-down list as shown in Figure 8-142.
Figure 8-142 Select the type of the userList element
752
d. In the Type Selection dialog box, choose UserInfoBO as shown in

Figure 8-143 Select UserInfoBO type
e. Set Min Occurs to 0 and Max Occurs to -1 for the element userList as
shown in Figure 8-144. Save the definition and close the editor.
Figure 8-144 Set Min and Max Occurs
The last steps finished the definition of the message set. Next export the
created message definition files as XML schema files to make them available
to SAP Exchange Infrastructure (see 5.8.2, Preparing the Integration
Repository for JMS inbound scenario on page 271).
25.Generate a folder xml-schema-files in the message set project as a
destination of generating the XML schema files.
753
26.Select UserInfoBO.mxsd and select New XML Schema from its context
Figure 8-145 Generate a XML Schema from UserInfoBO.mxsd
27.On the next page, UserInfoBO.mxsd is selected as the source message

definition. So just choose XML1 as the XML Wire Format and click Next.
Choose the folder xml-schema-files in message set project as the destination
folder as shown in Figure 8-146 and click Finish.
Figure 8-146 Select destination folder where to generate the XML schema file
28.Apply the previous two steps to generate XML schema files for
UserListResponseBO.mxsd and UserListRequestBO.mxsd.
754
The XML schema files are ready for export to a shared file system, from where
they can be imported into the Integration Repository of the SAP Exchange
Infrastructure.
8.6.2 Building the message flow

To create the message flow ProvideJmsServiceFlow as depicted in Figure 8-119
on page 740, follow these steps:
1. Start creating a new message flow project by selecting New Message
Flow Project from the file menu as shown in Figure 8-147.
Figure 8-147 New message flow project
2. Enter ItsoProvideJmsServiceToXi Message Flow Project as the Project

name as shown in Figure 8-148 and click Next.
Figure 8-148 Enter ItsoProvideJmsServiceToXi Message Flow Project
755
3. Select ItsoProvideJmsServiceToXi Message Set Project as a dependable

project as shown in Figure 8-149 and click Finish.
Figure 8-149 Specify dependency on respective message set project
4. Start creating a new message flow by selecting New Message Flow from
the file menu as shown in Figure 8-150.
Figure 8-150 New message flow
5. Select ItsoProvideJmsServiceToXi Message Flow Project as the project

for the new message flow, enter ProvideJmsServiceFlow as the Name as
Figure 8-151 Select project and name for new message flow
756
6. Open the new message flow in the Message Flow Editor, if it is not already
displayed there. Using the Palette in the left pane, add a MQInput, MQOutput
and Compute built-in node to the canvas as shown in Figure 8-152.
Figure 8-152 Create a message flow template
7. During the next steps, the message flow template is adjusted to the business
needs. Start by selecting the MQInput node and select Rename from its
context menu as shown in Figure 8-153. Enter XI2WMB_Request as the new
node name and click OK.
Figure 8-153 Rename the MQInput node
8. In the same way, click the MQOutput node, select Rename from the context
menu and enter WMB2XI_Response as the new node name.
757
9. Next create the connections between the various nodes. First, select the
XI2WMB_Request and select Create Connection from its context menu as
Figure 8-154 Start creating a connection
10.Select the Out terminal for the connection as shown in Figure 8-155 and click
OK.
Figure 8-155 Select terminal for connection
11.Connect the Out terminal of XI2WMB_Request to the In terminal of Compute

using the mouse pointer as shown in Figure 8-156.
Figure 8-156 Target of the connection
12.In addition, create a connection from the Out terminal of the node Compute to
WMB2XI_Response.
758
The following steps define the properties of the input and output nodes and
customize the Compute node.
13.Select the XI2WMB_Request node and select Properties from its context
menu. In the MQInput Node Properties dialog box, select Basic in the left
pane and enter XI2WMB_Request as the Queue Name as shown in
Figure 8-157.
Figure 8-157 Set queue name for XI2WMB_Request
14.Click Default in the left pane and associate the Message Type
UserListRequestBO with its respective domain, Message Set and Message
Format as shown in Figure 8-158. Click OK to save the configuration.
Figure 8-158 Specify message properties for XI2WMB_Request
759
15.Select the WMB2XI_Response node and select Properties from its context
menu. In the MQOutput Node Properties dialog box, select Basic in the left
pane and enter ItsoQmgr1 as the Queue Manager Name and
WMB2XI_Response as the Queue Name as shown in Figure 8-159. Click OK to
save the configuration.
Figure 8-159 Set queue name for WMB2XI_Response
16.Open the Properties dialog box of the Compute node and enter ITSOUSDB
into the field Data Source. This entry establishes the link to the database
ITSOUSDB including the test data. Leave all other defaults and click OK.
Figure 8-160 Properties of Compute node
760
17.Select the Compute node again and select Open ESQL from its context
Figure 8-161 Open ESQL for the Compute node
761
18.As a result, a ESQL module ProvideJmsServiceFlow_Compute with default

code snippets is generated and displayed in the ESQL editor. Change the
code as displayed in Figure 8-162. You can copy the ESQL from the Web
material available to download (see Appendix A, Additional material on
page 1441).
Figure 8-162 ESQL Module ProvideJmsServiceFlow_Compute
The details of this code are beyond the scope of this book. Therefore only the
major logical steps are explained.
The operation CopyMessageHeaders copies all the header fields, in
particular the field JMSCorrelationID, of the request message to the response
message.
762
The Main function first constructs a string that includes the SELECT statement
for retrieving user data from the table USERLISTTB. The amount of user data
to be retrieved is determined by attributes of the request message.
Note that the request message is converted into an internal logical tree
structure whose root is denoted by InputRoot. In the same way, OutputRoot
refers to the root of the logical tree that represents the response message.
The PASSTHRU statement delivers the constructed SELECT string to the
database system for execution. The logical tree of the response message is
then populated by the result of this execution.
8.6.3 Deploying message set and message flow

To build a broker archive including the configured message set and flow and
deploy it on the broker, follow these steps:
1. Switch to the administration perspective in the Message Brokers Toolkit by
selecting Window Open Perspective Broker Administration as
Figure 8-163 Switch to the Broker Administration perspective
2. Expand Broker Archives, select the folder Servers and select New
Message Broker Archive from its context menu as shown in Figure 8-164.
Figure 8-164 Create Message Broker Archive
763
3. Ensure that Servers is selected in the Message Broker Archive dialog box,
enter ItsProvideJmsServiceToXi as the name of the broker archive as shown
in Figure 8-165 and click Finish.
Figure 8-165 Enter name of broker archive
764
4. The file ItsoProvideJmsServiceToXi.bar is created and opened in the archive

editor. Start adding deployable files by selecting Add. Refer to Figure 8-166.
Figure 8-166 Add deployable files to the archive
5. In the Add to Broker Archive dialog box, choose

ItsoProvideJmsServiceToXi Message Flow Project and
ItsoProvideJmsServiceToXi_Message_Set as shown in Figure 8-167 and
click OK.
Figure 8-167 Add to Broker Archive
6. The compiled message flow and message set as a dictionary file are added to
the broker archive. Refer to Figure 8-168. Save and close the broker archive.
Figure 8-168 Contents of broker archive ItsoProvideJmsServiceToXi.bar
765
7. Next start creating an execution group as a unit of deployment. In the

Domains view expand the configured broker domain ItsoConfigMgr and
ensure that it is connected to the respective configuration. If not, select
Connect from its context menu. Then select ItsoBrk and select New
Execution Group from its context menu as shown in Figure 8-169.
Figure 8-169 Start creating an execution group
8. Ensure that ItsoBrk is selected as the broker, enter

ItsoProvideJmsServiceToXi-ExecutionGroup as the name as shown in
Figure 8-170 Enter execution group name
766
9. Click the broker archive ItsoProvideJmsServiceToXi.bar in the Broker

Administration Navigator view and select Deploy File from its context
Figure 8-171 Deploy broker archive
10.In the Deploy a BAR File dialog box, select

ItsoProvideJmsServiceToXi-ExecutionGroup as shown in Figure 8-172
and click OK.
Figure 8-172 Select execution group where to deploy the bar file
11.The message flow is ready for testing as soon as the files that are included
within the message broker archive appear in the respective execution group
folder. Refer to Figure 8-173.
Figure 8-173 Result of deployment
767
The last step finished the definition of the message flow. Proceed with testing it
as described in the next section.
8.6.4 Testing the JMS inbound scenario

Having configured the scenario ItsoProvideJmsServiceToXi as described in this
chapter and the integration scenario ItsoWmbInboundScenario in SAP Exchange
Infrastructure (5.8.3, Configuring ItsoEsbJmsInboundScenario in the Integration
Directory on page 288), you can now test the overall JMS inbound scenario as
shown Figure 8-174. This test is started by calling BAPI_USER_GETLIST in an
SAP Easy Access application with directing the call to the SAP Exchange
Infrastructure instance by means of the RFC destination
ITSO_XI_TO_PROCESS_WMB.
SAP ECC 5.0
ItsoWmbJmsInboundScenario
BAPI_USER_GETLIST
ITSO_XI_TO_PROCESS_WMB
XI2WMB_Request
ITSOUSDB
WMB2XI_Response
Figure 8-174 Testing the JMS inbound scenario
The only prerequisite still to be configured is preparing the database

environment. Therefore, first create the database ITSOUSDB on node
ITSO_IBM_2, an ODBC connection to the database and the table USERLISTDB
which contains the user data to be used by the scenario of this chapter.
768
To test the JMS inbound scenario, follow these steps:

1. Create a file itsousdb.sql that includes the commands in Example 8-1.
Example 8-1 The itsousdb.sql file
CREATE DB ITSOUSDB
CONNECT TO ITSOUSDB
CATALOG SYSTEM ODBC DATA SOURCE ITSOUSDB
CONNECT RESET
CONNECT TO ITSOUSDB
DROP TABLE USERLISTTB
CREATE TABLE USERLISTTB (USERNAME CHAR(15) NOT NULL, FIRSTNAME CHAR(25)
NOT NULL, LASTNAME CHAR(25) NOT NULL, FULLNAME CHAR(50) NOT NULL)
CONNECT RESET
TERMINATE
2. Execute db2start in a command window to ensure that DB2 is started.
3. Open a DB2 command window by executing Start Programs IBM
DB2 Command Line Tools Command Window
4. In the command window issue db2 -vf itsousdb.sql which executes the
commands within the file.
5. Create an additional file insertTestdata.sql that includes SQL statements for
inserting the test data into the table USERLISTDB, similar to the ones shown
in Example 8-2.
Example 8-2 insertTestdata.sql
CONNECT TO ITSOUSDB
insert into USERLISTTB VALUES ('saida', 'Saida', 'Davies', 'Saida
Davies')
insert into USERLISTTB VALUES ('sascha', 'Sascha', 'Schefenacker',
'Sascha Schefenacker')
insert into USERLISTTB VALUES ('clara', 'Clara Akiko', 'Matsuki',
'Clara Akiko Matsuki')
CONNECT RESET
TERMINATE;
6. Again in the DB2 command window issue db2 -vf insertTestData.sql to
execute the insert-statements within the file.
Having prepared the test database, open an SAP Logon to the SAP ECC
instance on ITSO_SAP_3 to actually execute the test.
769
7. In the application SAP Easy Access choose transaction code se37 to open
the transaction Function Builder and click Enter (Figure 8-175).
Figure 8-175 Open transaction se37
8. In the initial panel of the transaction Function Builder, enter

BAPI_USER_GETLIST in the Function Module field and click Test/Execute (F8),
Figure 8-176 Execute testing BAPI_USER_GETLIST
770
9. The initial panel of the transaction Test Function Module opens

(Figure 8-177). Follow these steps:
a. Enter ITSO_XI_TO_PROCESS_WMB as value of the RFC target sys field.
b. Specify input parameters to the BAPI_USER_GETLIST, such as 3 for
MAX_ROWS and x for WITH_USERNAME, which specifies to get 3 rows
with complete user data.
c. Click Execute (F8).
Figure 8-177 Test Function Module
771
10.The Test Function Module: Result Screen opens. The return data of the call
BAPI_USER_GETLIST are included in the table USERLIST as shown in
Figure 8-178.
Figure 8-178 Test Function Module: Result Screen
772
11.To display the data that is returned, click the icon beside the value 3 Entries
(Figure 8-178). This opens the Structure Editor: Display USERLIST from
Entry panel and shows the actual data that is retrieved from the database
ITSOUSDB by means of the scenario ItsoProvideJmsServiceToXi
(Figure 8-179).
Figure 8-179 Display USERLIST
8.7 Conclusion
This chapter illustrated how to configure WebSphere Message Broker as a JMS
Service Provider and JMS Service Consumer to SAP Exchange Infrastructure.
This collaboration between the two middleware systems rests upon XML schema
files as interface contracts only. Thus, for message broker it is transparent that
the communication partner is SAP Exchange Infrastructure and vice versa.
The scenarios that we introduced are self-contained. You can use them as
showcases for collaboration based on open standards. In addition, you might use
them as patterns for more complex business scenarios. Even though not
demonstrated here, the one-way JMS communication can be treated as a
special case of the more general two-way request and reply pattern that was
investigated thoroughly during this chapter.
773
774
Chapter 9.
Web Services based

integration to SAP
WebApplication Server
scenario
This chapter describes how to expose a standard SAP Remote Function Module
as a Web Service using SAP WebApplication Server (WebAS) 6.40. The
beginning shows the configurations steps for generating a Web Service from a
given BAPI BAPI_USER_EXISTENCE_CHECK using the Web Service Creation
Wizard. After that, the Web Service is called by WebSphere Enterprise Service
Bus V6.
In general, any BAPI or Remote Function Call can be Web Service enabled.
Finally this chapter describes how to send an IDoc from WebSphere Application
Server V6 into SAP Web AS using Web Service technology. Exposing the
Remote Function Call IDOC_INBOUND_ASYNCHRONOUS any IDoc can be
sent through SOAP into SAP.
775
This chapter consists of the following topics:

System landscape on page 776.
Scenarios overview on page 777.
Scenario A: Web Service based access to SAP WebApplication Server on
page 778.
Scenario B: Send an IDoc using a Web Service into SAP on page 824.
Extension A: WebSphere Process Server deployment and test process on
page 851.

Figure 9-1 is an overview of all installed systems and software.
ITSO.IBM.COM
ITSO.SAP.COM

6.0.1.2
SAP ERP 2004

6.0.1.0
IBM DB2 8.1
Server ND 6.0.2.9
Microsoft Windows 2003
WebSphere Enterprise
Service Bus 6.0.1.2
6.0.1.2
Microsoft Windows XP SP2
776

The scenarios are independent and focus on different options to integrate SAP
Web AS with WebSphere products using Web Service service technology.
9.2.1 Scenario A: Web Service based access to SAP

WebApplication Server
This scenario describes how to call the Web Service enabled BAPI module
BAPI_USER_EXISTENCE_CHECK in SAP through SOAP/HTTP using
WebSphere Enterprise Service Bus V6. To test the Web Service, the
WebSphere Integration Developer Test Client is used.
9.2.2 Scenario B: Send an IDoc using a Web Service into SAP

This scenario shows how to send an IDoc unparsed through the SOAP/HTTP
protocol into SAP. Therefore, the RFC IDOC_INBOUND_ASYNCHRONOUS is
exposed as Web Service. Using this Web Service you can send any IDOC into
SAP. This Web Service is called from WebSphere Application Server V6 to send
the IDOC into SAP.

and test process
The SAP integration does not differ if the Mediation component is running on
WebSphere Enterprise Service Bus or WebSphere Process Server. But the
WebSphere Process Server offers powerful additional features.
In this example you completely reuse the module you created in Scenario A.
Scenario A describes how to call the Web Service enabled BAPI module
BAPI_USER_EXISTENCE_CHECK in SAP through SOAP/HTTP using a
WebSphere Enterprise Service Bus V6 Mediation Module.
In this Extension A scenario a new service component architecture (SCA)
module is created, that includes a simple business process. This new SCA
module containing the business process calls the module created in scenario A
through SCA binding. The Business Process Container (BPC) Explorer is used
as Web interface to administer the business process.
Chapter 9. Web Services based integration to SAP WebApplication Server scenario
777
9.3 Scenario A: Web Service based access to

SAP WebApplication Server
This scenario shows how to call the Web Service enabled BAPI module
BAPI_USER_EXISTENCE_CHECK in SAP through SOAP/HTTP using
WebSphere Enterprise Service Bus V6. To test the Web Service, the
WebSphere Integration Developer Test Client is used.

Figure 9-2 gives an overview of all installed systems and software.
SAP WebAS 6.40

SOAP/HTTP request
WID
TestClient
Mediation module
SOAP/HTTP response
WebService
enabled BAPI
ITSO.IBM.COM
ITSO.SAP.COM
9.3.2 Preparation
This section shows how to expose the BAPI BAPI_USER_EXISTENCE_CHECK
as a Web Service and test this Web Service in SAP.
Generating the Web Service in SAP WebApplication Server

In this section a BAPI is exposed as Web Service. To general the web Service in
SAP WebApplication Server:
1. Create a Package for the Virtual Interfaces. A Virtual Interface maps the Web
Service interface to the BAPI interface:
a. Log in to the SAP WebAS using the SAP GUI with a user ID that has the
appropriate authorizations (at least role AP_BC_WEBSERVICE_ADMIN).
b. Open transaction SE80.
778
c. Select Package as shown in Figure 9-3.
Figure 9-3 Select Package from the list
779
d. Enter a name for the new package, for example Z_ITSOPACKAGE, as

shown in Figure 9-4 .
Note: Names of custom objects in SAP have to start with a Z.
Figure 9-4 Enter a name for the new package
780
e. Click Display and select Yes in the Create Object dialog box as shown in
Figure 9-5.
Figure 9-5 Click Yes to crate the new object
f. Enter a Short Text for the package. Keep the default values as shown in
Figure 9-6. Click New.
Figure 9-6 Add a short text for the package
g. Enter a Workbench Request. You require it to create new objects in SAP.

If you do not have one, create a Workbench request by clicking New as
Figure 9-7 Create a Workbench Request
h. Click Continue.
781
i. In the Create Task dialog box click Continue.
Figure 9-8 Click OK in the Create Task dialog box
2. Create the Web Service using the Web Service wizard:

a. In transaction SE80 right-click the package, for example
Z_ITSOPACKAGE, and select Create Enterprise Service / Web
Service Web Service, as shown in Figure 9-9.
782
Figure 9-9 Right-click the package and select Web Service
783
b. Click Continue on the Wizard: Create Web Service panel as shown in

Figure 9-10.
Figure 9-10 The overview panel of the wizard
784
c. Create a Virtual Interface Z_BAPI_USER_EXISTENCE_CHECK_VI as

shown in Figure 9-11 and click Continue.
Note: Names of custom objects in SAP have to start with the letter Z.
Figure 9-11 Create a Virtual interface
785
d. Choose BAPI_USER_EXISTENCE_CHECK as the Endpoint for the Web

Service as shown in Figure 9-12 and click Continue.
Note: You can select any BAPI or Remote Function Module as the Web
Service Endpoint.
Figure 9-12 Select the endpoint for the Web Service
786
e. Select a name such as Z_BAPI_USER_EXISTENCE_CHECK_WS for the

Web Service Definition as shown in Figure 9-13 and click Continue.
Figure 9-13 Create the Web Service Definition
787
f. Review the settings as shown in Figure 9-14 and click Complete.
Figure 9-14 Review the settings
788
g. Save the Web Service definition and virtual interface within your selected
package as shown in Figure 9-15 by clicking Save.
Figure 9-15 Save the objects
h. Assign the created artefacts to a transport request.

i. Review the created Virtual Interface in the Object Navigator as shown in
Figure 9-16.
Figure 9-16 Review the Virtual Interface
789
j. To ensure that the Web Service is released, open transaction

WSCONFIG, select the created Web Service definition
Z_BAPI_USER_EXISTENCE_CHECK_WS as shown in Figure 9-17 and
click Refresh.
Figure 9-17 Transaction WSCONFIG
k. Generate a WSDL for the created Web Service by opening transaction

WSADMIN, select the generated Web Service definition
Z_BAPI_USER_EXISTENCE_CHECK_WS and click WSDL as shown in
Figure 9-18.
Figure 9-18 Generate the WSDL file
790
l. Select Document Style in the WSDL generation panel as shown in

Figure 9-19. If subsequently prompted, authenticate yourself to the SAP
system, and save the displayed WSDL file for further processing in
WebSphere into your file system, for example C:\ITSO, of the machine
where WebSphere Integration Developer resides.
Figure 9-19 Select Document Style
The BAPI is now Web Service enabled and the WSDL file is available for the
Testing the Web Service in the SAP WebApplication Server

This section explains how to text the Web Service in SAP.
Restriction: The SAP J2EE Server must be installed to perform the test in
SAP.
To test the Web Service in the SAP WebApplication Server, follow these steps:
1. Test the Web Service by opening transaction WSADMIN, select the
generated Web Service definition
Z_BAPI_USER_EXISTENCE_CHECK_WS, and click Web Service
Homepage to test the Web Service.
791
2. Select Document Style in the WSDL generation panel as shown in

3. A Web browser opens. On the Web Service Navigator page, authenticate

yourself to the SAP system, click Test, and click the operation
(test.types.BAPI_USER_EXISTENCE_CHECK parameters) as shown in
Figure 9-21.
Figure 9-21 Click the operation
792
4. Enter a user name as input parameter, for example KTW, and click Send as
Figure 9-22 Enter the input parameter and click Send
793
5. The response message displays. Review the return parameters as shown in

Figure 9-23. Especially notice the value of the MESSAGE field, which
indicates whether the User ID exists.
Figure 9-23 Review the return parameters
6. The test was successfully performed. Close the Web browser.
794
9.3.3 Configuration
To create a Web Service client for the SAP Web Service using WebSphere
Integration Developer and WebSphere Enterprise Service Bus V6, follow these
steps:
2. Close the Welcome page as shown in Figure 9-24.
Figure 9-24 Close the Welcome page
795
3. Create a new Project in WebSphere Integration Developer:

a. Select File New Project.
b. Select in the New Project dialog box, Mediation Module as shown in
Figure 9-25 and click Next.
Mediation Modules include data objects, interfaces, and mediation logic.
The data objects and interface are imported using the SAP wsdl file. You
can deploy Mediation Modules on WebSphere Enterprise Service Bus V6
and WebSphere Process Server v6.0.
Figure 9-25 Select Mediation Module
796
c. Enter a name, for example ITSOWebSphere2SAP, as shown in Figure 9-26

and click Finish.
Figure 9-26 Enter a name for the module
797
4. Import the WSDL file into the Mediation Module:

a. Select File Import from the menu.
b. In the Import dialog box, select File system as shown in Figure 9-27.
Figure 9-27 Import the WSDL from the file system
798
c. Browse for the WSDL file as shown in Figure 9-28, for example
C:\ITSO\Z_BAPI_USER_EXISTENCE_CHECK_WS.wsdl and click
Finish.
Figure 9-28 Browse and select the WSDL file
799
5. Review the imported WSDL in the Business Integration View by expanding

the Mediation Module ITSOWebSphere2SAP and double-clicking
Z_BAPI_USER_EXISTENCE_CKECK_WS under Interfaces.
The interface has one operation with one input and one output parameter.
The input parameter is of type char12 and the return parameter is of type
BAPIRET2 as shown in Figure 9-29.
Figure 9-29 Z_BAPI_USER_EXISTENCE_CKECK_WS interface
800
6. In the Business Integration View expand the Mediation Module

ITSOWebSphere2SAP and double-click BAPIRET2 under Data Types as
Figure 9-30 The Data Type BAPIRET2
801
7. Open the Assembly Diagram Editor in WebSphere Integration Developer as

Figure 9-31 The Assembly Diagram Editor
8. Drag-and-drop the Interface to the Assembly Diagram Editor.

9. In the Component Creation dialog box, select Import with Web Service
Binding as shown in Figure 9-32. Using this import the Mediation Module is
able to connect to the interface using a Web Service binding.
Figure 9-32 Create an import with Web Service Binding
The Import1 component is now in the Assembly Diagram Editor.
802
10.Click the Import1 component, then click the Properties tab and the Bindings
tab as shown in Figure 9-33. Review the Endpoint address of the Web
Service.
Figure 9-33 Import with Web Service Binding Properties
803
11.Rename the Import1 component to CallWebService by clicking the Import1

component and the Properties tab and the Description tab as shown in
Figure 9-34. Enter in the Display field CallWebService.
Figure 9-34 Rename the Import component
804
12.Add an interface to the Mediation1 component. By adding interfaces to a

Mediation module the input and output data structures for the mediation are
defined.
a. Right-click the Mediation1 component.
b. Select Add Reference.
c. Select the Z_BAPI_USER_CHECK_EXISTENCE_CHECK_WS interface
Figure 9-35 Add a Reference
Now the Mediation Module component includes the reference symbol and
looks as shown in Figure 9-36.
Figure 9-36 Mediation component with reference
805
13.Move the mouse over the Reference symbol and wire it to the
CallWebService component. The Assembly Diagram Editor now displays as
Figure 9-37 The wired components
14.The Z_BAPI_USER_CHECK_EXISTENCE_CHECK_WS interface is a

complex and application specific interface. Therefore a new a interface
UserExistCheck is created now. The UserExistCheck interface is called later
from a Web Service client. The advantage of mapping the application specific
interface Z_BAPI_USER_CHECK_EXISTENCE_CHECK_WS to the generic
interface UserExistCheck is to decouple the interface and its business objects
from the Web Service client application logic.
a. Right-click Interfaces folder and select New Interface.
b. Name the interface UserExistCheck and click Finish.
c. Add the Request Response Operation userExistenceCheck to the
interface.
d. Add as input a String and name it UserId.
e. Add as output a String and name it UserExistMsg.
806
The interface looks as shown in Figure 9-38.
Figure 9-38 The UserExistCheck interface
15.Add the UserExistCheck interface to the Mediation1 component. By adding

interfaces to a Mediation module the input and output data structures for the
mediation are defined.
16.Right-click the Mediation1 component.
a. Select Add Interface.
b. Select the UserExistCheck interface and click OK as shown in
Figure 9-39.
Figure 9-39 Add an interface
807
17.Add an Export component to the Assembly Diagram Editor. In this scenario

we add an Export component with an SCA binding to the Assembly Diagram
Editor. In general, also a stand-alone reference or a Web service binding can
be used.
a. Click in the palette of the Assembly Diagram Editor on the Export
component as shown in Figure 9-40 and click the editor pane.
Figure 9-40 Add an Export component
808
b. Select the Export Component and wire it to the Mediation1 component as

c. Right-click the Export component and select Generate Binding SCA
Figure 9-41 Generate an SCA binding
d. Rename the Export to Mediation1Export as shown in Figure 9-42.
Figure 9-42 Enter a name for the Export component
809
e. The Assembly Diagram Editor now looks as shown in Figure 9-43.
Figure 9-43 The renamed Export component wired to the Mediation1 component
18.Generate the implementation for the Mediation1 module by right-clicking

Mediation1. Select Generate Implementation. The implementation maps
the UserExistCheck interface to the
Z_BAPI_USER_EXISTENCE_CHECK_WS interface as shown in Figure 9-44
using XSL transformation (XSLT) technology. The XSLT code is created by
using the visual mapping editor in WebSphere Integration Developer.
Figure 9-44 Generated implementation
810
There two mappings are created. First the request flow mapping is done, then
the response flow mapping is implemented:
a. Drag-and-drop the userExistenceCheck operation to the
Z_BAPI_USER_EXISTENCE_CHECK operation.
b. Click the wire between userExistenceCheck and
Z_BAPI_USER_EXISTENCE_CHECK to open the flow editor.
c. Drop a XSL Transformation node to the editor and wire it as shown in
Figure 9-45.
i. Wire the out terminal of the Request node to the in terminal of the
XSLTransformation1 node.
ii. Wire the out terminal of the XSLTransformation1 node to the in
terminal of the Invoke node.
iii. The fail terminal is not wired in this implementation. If exceptions in the
XSLTransformation1 node are caught, then the fail terminal must be
wired. Because the fail terminal is not wired, exceptions are printed in
the SystemOut.log of the server. Also the Immediate Response node is
not wired. The Immediate Response node can be used if SAP is not
invoked but you want to send a response back to the caller; you can
think of implementing a more complex transformation where you check
the integrity of your input message first before sending it to SAP.
Figure 9-45 The wired Mediation flow
811
d. Click the XSLTransformation1 node and select the Properties tab and
the Details tab as shown in Figure 9-46.
e. Click New to create a XSLT implementation.
Figure 9-46 Create an implementation for the XSL transformation
f. In the New XSLT Mapping dialog box, keep the values as shown in
Figure 9-47 Keep the default values
812
g. Map the UserId field to the USERNAME field:

i. Click the UserId field.
ii. Right-click the USERNAME field.
iii. Select Create Mapping as shown in Figure 9-48.
Figure 9-48 Create the mapping
19.Save and Close the XSL Transformation.

20.In the Mediation Flow Editor select the Response: userExistenceCheck tab.
21.To create a Response flow, create a XSL Transformation Node and wire it to
the Request and Invoke nodes:
a. Click the XSL Transformation1 node and select the Properties tab and the
Details tab.
b. Click New as shown in Figure 9-49.
Figure 9-49 Create an implementation for the response flow
813
c. In the New XSLT Mapping dialog box, keep the values as shown in
Figure 9-50 Keep the default values
814
d. Map the MESSAGE field to the UserExistMsg field.

i. Click the Message field.
ii. Right-click the UserExistMsg field as shown in Figure 9-51.
iii. Select Create Mapping.
Figure 9-51 Create the mapping
e. Save and Close the XSL Transformation.

f. Save the Mediation Flow Editor. Now the request and response mapping
flows are created.
815
22.To call the Web Service in SAP the HTTP authentication settings for the Web
Service in the Deployment Descriptor of the application must be configured.
Therefore, SAP user ID and password are required. Follow these steps:
a. In WebSphere Integration Developer switch to the Resource perspective.
b. Click Window Open Perspective Other on the menu as shown in
Figure 9-52.
Figure 9-52 Open the Resource perspective
816
c. In the Select Perspective dialog box, select Resource and click OK as

Figure 9-53 Select Resource
817
d. Open in the Navigator view the EJB Deployment Descriptor file ejb-jar.xml
in the ITSOWebSphere2SAPEJB folder by double-clicking as shown in
Figure 9-54.
Figure 9-54 Open the EJB Deployment Descriptor
e. In the EJB Deployment Descriptor file switch to the WSBinding tab.

f. Navigate to the Port Qualified Name Binding Details section.
g. Under HTTP basic authentication, enter the SAP user ID into the field
User ID.
818
h. Under HTTP basic authentication, enter the SAP password into the field
Password as shown in Figure 9-55.
Figure 9-55 Enter the user ID and the password
i. Save and close the EJB Deployment Descriptor file.

Note: When performing a project clean, the EJB Deployment Descriptor file is
built new and your user ID and password entries are overwritten.
819

Test the scenario with the WebSphere Integration Developer Test Client by
following these steps:
2. Open the Assembly Diagram Editor.
3. Right-click the Mediation1 component in the Assembly Diagram Editor.
4. Select Test Component to start the test client view as shown in Figure 9-56.
Figure 9-56 Start the test client
5. In the test client view, switch to the Configurations tab.
820
6. Mark the CallWebService Emulator and click Remove. If the emulator is not
removed, the Web Service interface to SAP is not called. It would make
sense to keep the emulator, if only the mediation is tested without accessing
SAP. The test client view now looks as shown in Figure 9-57.
Figure 9-57 Remove the CallWebService emulator
7. Go back to the Events tab.
821
8. Enter a string value for the UserId field, for example ktw, as shown in
Figure 9-58.
Figure 9-58 Enter the input value
9. Click Continue.
822
10.Select the Deployment Location, for example WebSphere ESB Server V6.0,
as shown in Figure 9-59 and click Finish.
Figure 9-59 Select the deployment target
11.After the test has finished, the test client displays the result as shown in
Figure 9-60.
Figure 9-60 Review the response
9.3.5 Conclusion
In this section, we created an SAP Web Service based on the BAPI
BAPI_USER_EXISTENCE_CHECK. The SAP WSDL was imported into
WebSphere Integration Developer. Based on the SAP WSDL interface in
823
WebSphere Integration Developer a Mediation Module was implemented, which

maps the SAP WSDL interface to a more generic one. The Mediation Module
was deployed as a J2EE Enterprise Application to WebSphere Enterprise
Service Bus V6. The WebSphere Enterprise Service Bus V6 now provides a
simple interface to SAP based on the SOAP/HTTP protocol.
9.4 Scenario B: Send an IDoc using a Web Service into

SAP
This scenario shows how to send an IDoc unparsed through the SOAP/HTTP
protocol into SAP. Therefore, the RFC IDOC_INBOUND_ASYNCHRONOUS is
exposed as Web Service. Using this Web Service you can send any IDoc into
SAP. This Web Service is called from WebSphere Application Server V6 to send
the IDoc into SAP.

Figure 9-61 shows an overview of all installed systems and software.

6.0.1.9
SAP WebAS 6.40
WebService
Test Client
SOAP/HTTP request
SOAP/HTTP response
WebService
enabled RFC
ALE
ITSO.IBM.COM
ITSO.SAP.COM
Figure 9-61 Operation model
824
9.4.2 Preparation
Generate the Web Service in SAP
Configure ALE in SAP
Terminology
ALE is the acronym for Application Link Enabling and describes the loose
coupling of distributed SAP business applications. The key concept is an
asynchronous message based exchange of business data between distributed
applications.
ALE is a core SAP communication technology and included within any SAP
Basis system respectively SAP WebApplication Server.
Generating the Web Service in SAP WebApplication Server

In this section the RFC IDOC_INBOUND_ASYNCHRONOUS is exposed as Web
Service. Using this Web Service you can send any IDoc into SAP. To generate
the Web Service in SAP WebApplication Server, follow these steps:
1. Use an existing Package for the Virtual Interfaces, or create a new one as
described in 9.3.2, Preparation on page 778.
825
2. Create the Web Service using the Web Service wizard. In transaction SE80,
right-click the package, for example Z_ITSOPACKAGE, and select Create
Enterprise Service / Web Service Web Service as shown in Figure 9-62.
826
3. Create the Virtual Interface Z_IDOC_INBOUND_ASYNCHRONOUS_VI and

click Continue as shown in Figure 9-63.
Figure 9-63 Create a Virtual Interface
827
4. Choose IDOC_INBOUND_ASYNCHRONOUS as the endpoint for the Web

Service as shown in Figure 9-64 and click Continue.
828
5. Select a name such as Z_IDOC_INBOUND_ASYNCHRONOUS_WS for the

Web Service Definition as shown in Figure 9-65, and click Continue.
829
6. Review the settings and click Complete as shown in Figure 9-66.
830
7. Save the Web Service definition and virtual interface within your selected
8. Assign the created artifacts to a transport request.

9. To ensure that the Web Service is released, open transaction WSCONFIG,
select the created Web Service definition
Z_IDOC_INBOUND_ASYNCHRONOUS_WS as shown in Figure 9-68 and
click Refresh.
831
10.Generate a WSDL for the created Web Service by opening transaction

WSADMIN, select the generated Web Service definition
Z_BAPI_USER_EXISTENCE_CHECK_WS, and click WSDL as shown in
Figure 9-69.
11.Select Document Style in the WSDL Generation panel as shown in

WebSphere into your file system, for example C:\ITSO, of the machine where
WebSphere Integration Developer resides.
The BAPI is now Web Service enabled and the WSDL file is available for the
832
Configuring ALE
The SAP application must be configured to process inbound Idocs. This chapter
describes the step-by-step configuration of ALE. This section includes the
following configuration steps:
Create a Partner type Logical System (LS)

Create an SAP Logical System
Create a Distribution Model
Generate Partner Profiles and transactional RFC Ports
Creating a partner type logical system

The logical system is used as the partner ID for communication. To create a
partner type logical system, follow these steps:
1. In the SAP application open transaction BD54.
2. The table is cross-client dialog box opens. Click OK to continue.
3. Add a entry for the WebSphere Business Integration Adapter for
mySAP.com. Name it, for example WAS, and supply a description as shown
in Figure 9-71.
4. Click Save.
Figure 9-71 Transaction bd54: Logical Systems
A Prompt for Workbench request pop-up window is seen. SAP records

information whenever a user changes critical SAP system properties.
833
Creating a Local SAP Logical System

Open transaction SCC4 to check if a Logical System is assigned to your client.
The logical system is used as the ID for communication. Each system in the
distributed environment must have a unique logical system name (even non-SAP
systems like the WebSphere Business Integration Adapter for mySAP.com). If it
is assigned, notice the name of the Logical System, usually it is
<SID>CLNT<CLIENT>, for example BSCCLNT800.
If the SAP client has no Logical System assigned, follow these steps:
2. Add a entry for the SAP client the Adapter is accessing. Name it like
<systemname>CLNT<client>, for example BSCCLNT800 and supply a
description.
3. Link the local SAP logical system to the client.
a. Open transaction scc4.
b. Click the Table view menu.
c. Select Display Change to change the current Display view to Change
view.
d. The table is cross-client dialog box opens. Click OK to continue.
e. Double-click the entry for the client number. In this use case it is client
800.
f. Type BSCCLNT800 as the logical system name of the SAP system.
4. Click Save.
Creating a distribution model in the inbound SAP application

If a message is to be sent from one logical system to another, in the distribution
model is specified which message type, from which logical system, is to be sent
to which other logical system. To create a distribution model in the inbound SAP
application, follow these steps:
2. Switch to the edit mode (F9).
834
3. Click Create Model View. Enter a Short text, for example WASCON, and a
Technical Name, for example WASCON, for the Model View as shown in
Figure 9-72.
Figure 9-72 Transaction bd64: Create a model view
4. Select the Model View that was created and click Add Message Type.
a. Enter the name of the Logical System, for example WAS, into the Sender
field.
b. Enter the name of the SAP Logical System, for example BSCCLIENT800,
into the Receiver field.
c. Enter MATMAS into the Message type field as shown in Figure 9-73.
Figure 9-73 Transaction bd64: Add a message type to the model view
5. Click Save.
835
6. Generate a Partner Profile by clicking Environment Generate Partner

Profile in the menu as shown in Figure 9-74.
Figure 9-74 Transaction BD64: Generate Partner Profile
836
7. In the next panel keep the default values as shown in Figure 9-75 and click
OK.
Figure 9-75 Generate Partner Profile
837
8. The summary displays (Figure 9-76).

Note: Note that no RFC ports are created because we use only inbound
processing.
838
9. Open transaction WE20 to check the Partner Profiles. Refer to Figure 9-77.
Figure 9-77 Transaction we20: Partner Profiles
Now the SAP system is able to receive and process incoming IDocs of type
MATMAS from WebSphere through a Web Service call.
9.4.3 Configuration
This section presents the configuration steps for building and testing Web
Services clients for sending IDocs into SAP with IBM Rational Application
Developer and WebSphere Application Server V6. The clients are derived from a
WSDL, which is generated by SAP tools as described within the previous
839
sections. Given that Rational Application Developer together with the integrated
WebSphere Application Server V6 is up and running, perform the following
steps:
1. Create a Dynamic Web Project in Rational Application Developer by selecting
File New Dynamic Web Project as shown in Figure 9-78.
Figure 9-78 Create a Dynamic Web Project
840
2. Name the project DeliverIDOC2SAP and click Finish as shown in Figure 9-79.
Figure 9-79 Enter a name for the project
3. Import the WSDL, which was created as described in 9.3.2, Preparation on

page 778, by selecting the new project within the Project Explorer and select
Import Import from its context menu as shown in Figure 9-80.
Figure 9-80 Import the WSDL file
841
4. On the next panel, select File system and click Next as shown in
Figure 9-81.
Figure 9-81 Select file system
5. Browse to the file location of the WSDL to be imported and open it. Select
Z_IDOC_INBOUND_ASYNCHRONOUS_WS.wsdl and click Finish.
842
6. After successful import, select

Z_IDOC_INBOUND_ASYNCHRONOUS_WS.wsdl within Project Explorer
and select Web Services Test with Web Services Explorer from the
Figure 9-82 Generate the test client
843
7. A Web browser window in the Rational Application Developer opens. Review

the Endpoint and click the operation IDOC_INBOUND_ASYNCHRONOUS as
Figure 9-83 Click the operation
8. Click Add to add one instance of the IDOC_CONTROL_REC_40 and two

instances of IDOC_DATA_REC_40. Refer to Figure 9-84.
Figure 9-84 Add instances
844
9. Enter the parameters listed in Table 9-1 for first segment of the IDoc data
record IDOC_CONTROL_REC_40. Leave the other parameters blank.
Table 9-1 Parameters for the IDoc control record
Type
Value
Comment
TABNAM
EDI_DC40
MANDT
800
DOCREL
640
DIRECT
IDOCTYP
MATMAS05
MESTYP
MATMAS
STDMES
MATMAS
SNDPOR
XMLPORT
SNDPRT
LS
SNDPRN
WEBSPHERE
Logical System name of

the client.
RCVPOR
SAPBSC
Enter the receiver port in

the form SAP<SID>
RCVPRT
LS
RCVPRN
BSCCLNT800
CREDAT
2006-10-03
CRETIM
09:09:09
your SAP system client
1 = SAP outbound
2 = SAP inbound
Logical System of the SAP

client. Refer to transaction
SCC4 to check your
Logical System name
845
10.Enter the parameters listed in Table 9-2 for the first IDOC_DATA_REC_40.
Table 9-2 Parameters for the first segment of the IDoc data record
Type
Value
SEGNAM
E1MARAM
MANDT
800
DOCNUM
Comment
leave blank
SEGNUM
000001
PSGNUM
000000
Parent Segment number
HLEVEL
02
Hierarchy level
SDATA
005200-265###########
19941111WILMS#######
19961125TORSTEN####
#KCEDPLQBG######XR
OH#C004#############
###########KGM
The hash sign (#) must be

a blank. The data is a fixed
length delimited value.
11.Table 9-3 describes the SDATA field in detail.

Table 9-3 SDATA field in detail
846
Name
Value
Length
MSGFN
005
MATNR
200-265
ERSDA
19941111
ERNAM
WILMS
12
LAEDA
19961125
AENAM
WILMS
12
PSTAT
KCEDPLQBG
15
LVORM
MTART
ROH
MBRSH
MATKL
004
27
MEINS
KGM
12.Enter the parameters given in Table 9-4 for the second segment of the IDoc
data record IDOC_DATA_REC_40.
Table 9-4 Parameters for the second segment of the IDoc data record
Type
Value
SEGNAM
E2MAKTM
MANDT
800
DOCNUM
Comment
leave blank
SEGNUM
000002
PSGNUM
000001
Parent Segment number
HLEVEL
03
Hierarchy level
SDATA
005EADDITIOVE#VXXL#
5924#NEW############
########EN
The hash sign (#) must be

a blank. The data is a fixed
length delimited value.
Using this string the
description is set to
ADDITIOVE VXXL 5924
NEW
13.Click Go. It is expected that the material description of material 200-265 is

changed to ADDITIOVE VXXL 5924 NEW.
847
14.Review the Web Service response message for any errors. If the Web
Service call was successful, the request message is replied as response
message. Refer to Figure 9-85.
Figure 9-85 The Web Service response message
848
15.Log in to SAP and open transaction WE02 to check the IDoc status. If that
transaction has a status of 53, then it was posted successfully to the SAP
application. Refer to Figure 9-86.
Figure 9-86 Transaction WE02
16.Open transaction MM03 to check whether the description of material 200-265

was changed to ADDITIOVE VXXL 5924 NEW.
849
17.Enter 200-265 into the Material field as shown in Figure 9-87 and click Enter.
Figure 9-87 Transaction MM03
18.Select Basic Data 1 as shown in Figure 9-88 and click Continue.
Figure 9-88 Select Basic Data 1
850
19.Review the product description. It is now ADDITIOVE VXXL 5924 NEW. Refer to
Figure 9-89.
Figure 9-89 Review the material description
9.4.4 Conclusion
This scenario explained how to send an IDoc through the SOAP/HTTP protocol
into SAP. First, the RFC IDOC_INBOUND_ASYNCHRONOUS was exposed as
Web Service in SAP. Using this RFC any IDocs can be processed in SAP. Then
SAP ALE was configured to process inbound material Master IDocs. The SAP
Web Service definition file was imported from SAP into Rational Application
Developer and in a bottom up approach a J2EE Web Service client was created.
In this scenario we used the Web Services Explorer in Rational Application
Developer as client to send IDoc data through SOAP/HTTP into SAP.

deployment and test process
The SAP integration does not differ if the Mediation component is running on
WebSphere Enterprise Service Bus or WebSphere Process Server. However,
the WebSphere Process Server offers powerful additional features. In this
example, you completely reuse the module you created in Scenario A. Scenario
A describes how to call the Web Service enabled BAPI module
BAPI_USER_EXISTENCE_CHECK in SAP through SOAP/HTTP using a
WebSphere Enterprise Service Bus V6 Mediation Module.
In this Extension A scenario, a new SCA module is created that includes a simple
business process. This new SCA module containing the business process calls
851
the module created in scenario A through SCA binding. The BPC Explorer is
used as Web interface to administer the business process.
This is only a short introduction to one of the powerful features WebSphere
Process Server offers. For additional information refer to:
Technical Overview of WebSphere Process Server and WebSphere
Integration Developer, REDP-4041, which is available at:
Patterns: Serial and Parallel Processes for Process Choreography and
Workflow, SG24-6306, which is available at:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246306.pdf


6.0.1.2
Module with
Business Process
WID
TestClient
Mediation module
SAP WebAS 6.40

SOAP/HTTP request
SOAP/HTTP response
WebService
enabled BAPI
ITSO.SAP.COM
ITSO.IBM.COM
Figure 9-90 Operational Model
9.5.2 Development
with the Mediation Module created in Scenario A. The section includes the
following steps:
Create a library project for the interfaces
Create a Mediation module for the Process component
Implement the Business Process
852
Creating a library project for the interfaces

In this section a library project for the interface is created that is used in the
Mediation Module and in the Module that contain the process component. To
create a library project for the interfaces, follow these steps:
1. Open the workspace with the module of Scenario A.
2. Right-click in the Navigator pane and select New Library to create a new
library project as shown in Figure 9-91. This library is used as common
repository for the interface that is used in the mediation module and in the
module for the business process. Instead of using a library, the interface
could be copied to the module for the business process.
Figure 9-91 Create the library
853
3. Enter ITSOCommonLib as the Library Name and click Finish as shown in

Figure 9-92.
Figure 9-92 Name the library
854
4. Configure the ITSOWebSphere2SAP module to use the library:

a. Right-click the project and select Open Dependencies Editor as shown
in Figure 9-93.
Figure 9-93 Open the Dependencies Editor
b. Click Add in the Libraries section.
855
c. Select in the Library Selection dialog box, the ITSOCommonLib and click
OK as shown in Figure 9-94.
Figure 9-94 Select the library
d. Save the changes.
856
e. The dependency is created now and the dependency editor looks as

Figure 9-95 Dependencies are added
5. Move the interface from the ITSOWebSphere2SAP project into the library.
857
6. Click UserExistCheck and select Move as shown in Figure 9-96.
Figure 9-96 Select the interface to move
858
7. Select the ITSOCommonLib library and click OK as shown in Figure 9-97.
Figure 9-97 Select the library
8. Check that the interface was moved. Expand the Interface folder in the
ITSOCommonLib project and make sure the interface UserExistCheck is
available as shown in Figure 9-98.
Figure 9-98 The UserExistCheck is in the library
859
Creating the process component

To create a Mediation Module for the Process component and to implement the
Process follow these steps:
1. Create a new module for the business process as shown in Figure 9-99. This
module is deployed on WebSphere Process Server v6.0. The module
contains only a simple business process. Focus here is to demonstrate the
integration between the mediation and the SCA modules.
860
2. Enter ITSOWPSExtension as the Module Name and click Finish as shown in

Figure 9-100.
Figure 9-100 Name the new module
861
3. Add ITSOCommonLib to the dependencies. Refer to Figure 9-101.
Figure 9-101 Configure dependencies
4. Open the Assembly Diagram Editor of the ITSOWPSExtension module.

5. Drag-and-drop the UserExist interface from the library to the Assembly
Diagram Editor of the ITSOWPSExtension module.
6. In the Component Creation dialog box, select Import with no Binding as
Figure 9-102 Add new Import
862
7. Right-click the new created Import1. Select Generate Binding SCA

Figure 9-103 Generate import SCA binding
863
8. Right-click the created Import1 and Select Service to Import as shown in

Figure 9-104.
Figure 9-104 Configure import SCA binding
864
9. Select the Mediation1Export provided by the ITSOWebSphere2SAP module

Figure 9-105 Select the SCA Export
865
10.Add a Process to the Assembly Diagram Editor. Refer to Figure 9-106.
Figure 9-106 Add a Process component
11.Now the Assembly Diagram Editor looks as shown in Figure 9-107.
Figure 9-107 The added Process component
866
12.Wire the new process component Component1 to the Import1 import

component. If prompted to add a reference to the component, click OK as
Figure 9-108 Create a reference
13.Add the UserExistCheck interface to the Process component:

a. Right-click Component1 and select Add Interface.
b. Select the UserExistCheck interface and click OK.
14.Right-click the Component1 and select Generate Implementation. Use the
default folder and click OK.
15.In the Process Editor select Invoke in the palette and insert it with a left click
to the process between the Receive and Reply activity. Refer to Figure 9-109.
Figure 9-109 Add invoke to process
867
16.Right-click Invoke and select Set Partner as shown in Figure 9-110.
Figure 9-110 Set partner
868
17.Use the UserExistCheckPartner and click OK as shown in Figure 9-111.
Figure 9-111 Select partner
869
18.Navigate to the Details of Invoke as shown in Figure 9-112:

a. Click Invoke.
b. Click the Properties tab.
c. Click the Details tab.
Figure 9-112 Define variables
870
19.Set the Username variable as Input and the ExistResponse variable as the
Output as shown in Figure 9-113.
Figure 9-113 Variables defined
20.Save and close the Business Process.

21.Save the Assembly Diagram Editor.
22.The modules are prepared for deployment.
871
9.5.3 Deploying to WebSphere Process Server

The deployment to the WebSphere Process Server does not differ from the
deployment on a WebSphere Enterprise Service Bus. To deploy to WebSphere
Process Server, follow these steps:
1. Start WebSphere Process Server.
2. Right-click the entry in the Server tab and select Add and remove projects.
3. Select the module on the left and click Add to move it to the right as shown in
Figure 9-114.
872

WebSphere Process Server environment. We use the BPC Explorer to test the
modules.
Testing with BPC Explorer

The BPC Explorer provides a Web client interface for human interaction and
administrating business processes and human tasks. In the test you do a simple
call to SAP to check if a user is known in the SAP system. Follow these steps:
1. Right-click the WebSphere Process Server entry and select Launch BPC
Explorer as shown in Figure 9-115.
Figure 9-115 Start test component
873
This starts the BPC Explorer which is integrated in the WebSphere

Integration Developer environment. Refer to Figure 9-116.
2. Click My Process Templates as shown in Figure 9-117.
874
3. Select Component1 as Process Template Name and click Start Instance.

Enter ktw as the UserId in the Process Input Message field and click Submit
Figure 9-118 Select target Server
You see the result in the BPC Explorer as shown in Figure 9-119.
Figure 9-119 The result is displayed in the field Process Output Message
875
9.5.5 Conclusion
In this scenario, the Mediation Module created in Scenario A, which maps a
simple interface to an SAP Web Service enabled BAPI, was deployed on
WebSphere Process Server. The mediation service was exposed as SCA
binding and called from a second module which contains a business process
implemented in WS-BPEL.
This scenario shows how to decouple the data transformation from the business
logic. The data transformation and back-end access can be changed without
affecting the business logic and vice versa. The Mediation Module containing the
data transformation can be reused from an amount of SCA and non-SCA
applications.
876
10
Chapter 10.
XML-based exchange of
IDocs between WebSphere
Application Server and
SAP WebAS
This chapter describes how to send an IDoc through the HTTP protocol in the
XML format from SAP to WebSphere Application Server. On WebSphere
Application Server, a simple servlet deploys that catches the IDoc from HTTP
and sends a status message back to SAP. This chapter also describes how to
build a SOAP bridge from WebSphere MQ to SAP using the SOAP/WebSphere
MQ implementation and an Axis Web service.
The chapter discusses the following topics:
Scenario A: Sending an IDoc from SAP to WebSphere Application Server
using XML/HTTP on page 879
Scenario B: Build a WebSphere MQ to SAP bridge on page 903
877

ITSO.IBM.1
ITSO.SAP.1

6.0.1.2
SAP ERP 2004
Server ND 6.0.2.9
IBM DB2 8.1
WebSphere MQ 6.0
Microsoft .NET Framework

SDK

The scenarios are independent and focus on different options to integrate SAP
Web AS with WebSphere products using Web service technology.
10.2.1 Scenario A: Sending an IDoc from SAP to WebSphere

Application Server using XML/HTTP
This scenario describes how to send an IDoc through the HTTP protocol in the
XML format to WebSphere Application Server. On WebSphere Application
Server a simple servlet is deployed which catches the IDoc from HTTP and
sends a status message back to SAP.
878
10.2.2 Scenario B: Build a WebSphere MQ to SAP bridge

This scenario shows how to send an IDoc unparsed through WebSphere MQ into
SAP. Therefore, the RFC IDOC_INBOUND_ASYNCHRONOUS is exposed as
Web service in SAP. Using this Web service you can send any IDoc into SAP.
10.3 Scenario A: Sending an IDoc from SAP to

WebSphere Application Server using XML/HTTP
This scenario describes how to send an IDoc through the HTTP protocol in the
XML format from SAP to WebSphere Application Server. On WebSphere
Application Server a simple servlet deploys that catches the IDoc from HTTP and
sends a status message back to SAP.

Figure 10-2 shows the system setup for the scenario.

6.0.1.9
SAP WebAS 6.40
Servlet
XML/HTTP request
XML/HTTP response
ITSO.IBM.COM
XML HTTP
Port
ALE
ITSO.SAP.COM
Chapter 10. XML-based exchange of IDocs between WebSphere Application Server and SAP WebAS
879
10.3.2 Preparation
This section describes the configuration steps in SAP:
Set up the RFC connection to WebSphere
Create a XML HTTP port
Creating a HTTP Connection to WebSphere

This section describes how to set up the RFC Connection in SAP. The RFC
connection specifies the connection properties to WebSphere. Because the
connection type is a HTTP connection, the hostname and port of the target Web
server, for example WebSphere Application Server, must be specified.
1. Open transaction SM59.
2. Click Create (F8).
3. Enter as RFC Destination, for example HTTP_WEBSPHERE.
4. Select G (HTTP Connection to Ext. Server) as the Connection Type.
5. Enter the Target Host host name or IP Address and the Service Port. The
Target Host is the WebSphere Application Server host and the Port is the
HTTP port of the WebSphere Application Server.
880
6. Enter the Path Prefix as shown in Figure 10-3, for example

/ITSOSAP2WebSphere/servlet/ReceiveIDocServlet. In a later step, you
develop and deploy a servlet in Rational Application Developer to WebSphere
Application Server V6 that listens on this Path Prefix.
7. Save the RFC Destination.
Figure 10-3 Set the host and path prefix
881
Configuring ALE
You must configure the SAP application to process outbound Idocs. This chapter
describes step-by-step the configuration of ALE and includes information about
the following configuration steps:
Creating a port for IDoc processing

Creating a Partner of type Logical System (LS)
Creating an SAP Logical System
Creating a Distribution Model
Generating Partner Profiles and transactional RFC Ports
Creating an XML HTTP port in transaction WE21

This section explains how to create the XML HTTP. Ports are required for IDoc
processing and define the type of communication between the SAP system and
the external system. For example, the type of communication could be HTTP,
File, or RFC.
To create a port, follow these steps:
1. Open transaction WE21.
2. Click the XML HTTP port type (Figure 10-4) and click Create.
Figure 10-4 Create an XML HTTP port
3. Enter as Port name, for example HTTPPort.

4. Enter Description, for example XML HTTP Port.
5. Select the RFC destination created in step 1, for example
HTTP_WEBSPHERE.
882
6. Select as Content Type Text/XML as shown in Figure 10-5 and click Save.
Figure 10-5 Select the Content Type
Creating a Partner Logical System

The Logical System is used as the partner ID for communication. To create a
Partner Logical System, follow these steps:
1. In the SAP application, open transaction BD54.
3. Add a entry for the WebSphere Business Integration Adapter for mySAP.com.
Name it WEBSPHERE and supply a description as shown in Figure 10-6.
4. Click Save.
Figure 10-6 Transaction Bd54: Logical Systems
A prompt for Workbench request pop-up window opens. SAP records information
whenever a user changes critical SAP system properties.
883

Open transaction SCC4 to check whether a Logical System is assigned to your
client. The Logical System is used as the ID for communication. Each system in
the distributed environment must have a unique logical system name (even
non-SAP systems like the WebSphere Business Integration Adapter for
mySAP.com). If it is assigned, notice the name of the Logical System. Usually, it
is <SID>CLNT<CLIENT> (for example BSCCLNT800).
2. Add a entry for the SAP client the Adapter is accessing. Name it
<systemname>CLNT<client> (for example BSCCLNT800) and supply a
description.
b. Click Table view.
view.
d. In the dialog box that open, click OK to continue.
e. Double-click the entry for the client number. In this case it is client 800.
f. Type BSCCLNT800 as the logical system name of the SAP system.
4. Click Save.
884
Creating a distribution model in the outbound SAP application

If a message is sent from one logical system to another, you need to configure
the distribution model and specify the message type. Also, you need to configure
the sender and target logical system for the message in the distribution model.To
create a distribution model, follow these steps:
3. Click Create Model View. Enter a Short text, for example WEBSPHERE
REDBOOK TEST, and a Technical Name, for example WEBSERVICE, for
the Model View as shown in Figure 10-7.
Figure 10-7 Transaction BD64: Create a model view
4. Select the Model View that you created and click Add Message Type.
a. Enter BSCCLNT800 as the name of the SAP Logical System in the Sender
field.
b. Enter WEBSPHERE as the name of the Logical System in the Receiver field.
c. Enter MATMAS in the Message Type field as shown in Figure 10-8.
Figure 10-8 Transaction BD64: Add a message type to the model view
5. Click Save.
885
6. Generate a partner profile by clicking Environment Generate partner

profiles from the menu as shown in Figure 10-9.
886
7. In the next panel, keep the default values and click OK (Figure 10-10).
The summary displays. Note that no RFC ports are created and the default
XML port is used instead.
887
8. Open transaction WE20 to check the Partner Profiles as shown in

Figure 10-11.
9. Double-click MATMAS.
888
10.Set the Receiver port to XMLHTTP as shown in Figure 10-12 and save the
changes.
Figure 10-12 Set the Receiver port
The SAP System is now configured to send MATMAS IDocs through the HTTP
port to external systems.
10.3.3 Configuration
To create a servlet in Rational Application Developer which receives the IDoc
from SAP and sends a status message back to SAP follow these steps:
1. Start the Rational Application Developer with a new workspace.
2. Close the Welcome page.
3. Create a new Project by clicking File New Project.
889
4. Select Web Dynamic Web Project and click Next as shown in

Figure 10-13.
Figure 10-13 Create a new Dynamic Web project
890
5. Enter ITSOSAP2WebSphere as the Name for the project and click Finish as
Figure 10-14 Enter a name for the project
891
6. To create a Servlet that receives the IDoc, right-click ITSOSAP2WebSphere

under Dynamic Web Projects in the Project Explorer view and select New
Other as shown in Figure 10-15.
Figure 10-15 Create a servlet
892
7. Select Servlet in the Web folder and click Next as shown in Figure 10-16.
Figure 10-16 Select Servlet
893
8. In the new Servlet dialog box, enter ReceiveIDocServlet as a servlet name

and click Next as shown in Figure 10-17.
Figure 10-17 Enter a name for the servlet
894
9. In the next panel of the Create Servlet dialog box, keep the default values as
Figure 10-18 Specify the class file destination
895
10.Expand the Java Resource folder and double-click the

ReceiveIDocServlet.java file to open it as shown in Figure 10-19.
Figure 10-19 The skeleton of the servlet
11.Make the following modifications to the ReceiveIDocServlet.java file:

a. Delete the following import statements and add as imports.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
b. Then, modify the doPost method as shown in Example 10-1. The doPost
method receives the IDoc over XML/HTTP from SAP and sends a status
to SAP.
Example 10-1 The doPost method
//the doPost method receives the IDOC over XML/HTTP from SAP and sends a status back
//to SAP
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
//
read payload of the IDoc

BufferedReader b = request.getReader();
String IDoc = b.readLine();
//response message to SAP to update the IDoc status
response.setContentType("text/xml");
ServletOutputStream out = response.getOutputStream();
896
//return success status to SAP: STATUS = 200

out.print("<?xml version=\"1.0\"?><sap:Envelope
xmlns:sap=\"http://schemas.xmlsoap.org/soap/envelope/\"
version=\"1.1\"><sap:Body><STATUS>200</STATUS></sap:Body></sap:Envelope>");
out.close();
//print out the IDoc to SystemOut.log

System.out.println("******Start unparsed IDOC*****************************");
System.out.println(IDoc);
System.out.println("******End unparsed IDOC*******************************");
}
c. Modify the doGet method as shown in the Example 10-2. The doGet
method is called by SAP during the connection test in transaction SM59.
Example 10-2 The doGet method
// doGet method is called by SAP during the connection test in transaction SM59
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
//response message to SAP
response.setContentType("text/xml");
ServletOutputStream out = response.getOutputStream();
out.print("Connection to WebSphere Application Server established");
out.close();
System.out.println("******************************************");
System.out.println("*****Connection test request from SAP*****");
System.out.println("******************************************");
}
897
Figure 10-20 shows the implemented servlet in Rational Application Developer.
Figure 10-20 The implemented servlet
The servlet returns a status 200 to SAP, which means that SAP updates the
Status record to IDoc delivered to Port.
You can also consider to extend the servlet to send the ALEAUD IDoc to SAP to
update the Idoc Status, for example to IDoc processed. Therefore, you have to
set the ALEUAD IDoc to the IDoc number that you want to update and the status.
For information about how to send an Idoc into SAP, refer to Scenario A:
Sending an IDoc from SAP to WebSphere Application Server using XML/HTTP
on page 879.
898
10.3.4 Deployment
Deploying to the WebSphere Process Server does not differ from the deployment
on a WebSphere Process Server v6.0 or a WebSphere Enterprise Service Bus.
To deploy to WebSphere Application Server V6 start WebSphere Application
Server V6:
1. If the server is started, right-click the entry in the Server tab and select Add
and remove projects.
2. Add the project to WebSphere Application Server V6.
3. Select the module on the left and click Add to move it to the right.
10.3.5 Test
To test WebSphere Application Server V6:
1. Open the RFC Destination in transaction SM59.
2. Click Test connection as shown in Figure 10-21.
Figure 10-21 Test the connection
899
A panel displays as shown in Figure 10-22.
Figure 10-22 The results of the connection test in SAP
3. In the Console view of Rational Application Developer, an output displays as

Figure 10-23 The result of the connection test in WebSphere Application Server
900
4. After the connection test, send an IDoc from SAP to WebSphere Application
Server V6 as follows:
a.
b.
c.
d.
e.
f.
Open in SAP transaction BD10.

Select 200-265 as Material.
Select MATMAS as Message Type (R/3 Standard).
Select WEBSPHERE as Logical System as shown in Figure 10-24.
Click Execute (F8).
If any information dialog boxes open, click OK.
Figure 10-24 Send an IDoc from SAP
5. In the Console view of Rational Application Developer, an output opens as

shown in Figure 10-25, including the payload of the IDoc message.
Figure 10-25 The IDoc in WebSphere Application Server
901
6. Check the IDoc status in SAP transaction WE02:

a. Open transaction WE02 and click Execute (F8). Refer to Figure 10-26.
Figure 10-26 Transaction WE02
902
b. Expand Control Rec. and notice that the IDoc has the status Data passed
to port OK. Refer to Figure 10-27.
Figure 10-27 The status of the IDoc in SAP
The IDoc was sent out of SAP and into WebSphere Application Server V6
successfully.
10.3.6 Conclusion
An IDoc was sent through the HTTP protocol in the XML format from SAP to
WebSphere Application Server. On WebSphere Application Server a simple
servlet receives the IDoc from SAP and sent a status message back to SAP.
10.4 Scenario B: Build a WebSphere MQ to SAP bridge

Web service in SAP. Using this Web service you can send any IDoc type into
SAP.
A stand-alone Java client puts a message on a queue using SOAP over
WebSphere MQ. A Java Axis Web service deployed on WebSphere MQ serves
this request and calls the Web service exposed RFC
IDOC_INBOUND_ASYNCHRONOUS in SAP to sent the IDoc into SAP using
SOAP over HTTP.
903
This scenario includes the following steps:

Exposing the RFC IDOC_INBOUND_ASYNCHRONOUS as Web service in
SAP.
Configuring ALE in SAP.
Developing the MQ/SAP bridge Java snippet and deploy it into WebSphere
MQ.
Developing a stand-alone Java client to test the MQ/SAP bridge.
Testing the scenario.

Figure 10-28 shows the operational model of the WebSphere MQ to SAP
scenario.
Stand-alone
Java client
SOAP/MQ
sender
SAP WebAS 6.40
WebSphere MQ 6.0
SOAP/HTTP request
requestqueue
SOAP/MQ
listener
MQ/SAP
Bidge.java
SOAP/HTTP response
WebService
enabled RFC
ALE
responsequeue
ITSO.IBM.COM
ITSO.SAP.COM
Figure 10-28 Operation model
10.4.2 Preparation
Generate Web service in SAP
904
Generating a Web service in SAP WebApplication Server

In this section the RFC IDOC_INBOUND_ASYNCHRONOUS is exposed as
Web service. Using this Web service you can send any IDOC into SAP. To
generate a Web service, follow these steps:
1. Use an existing Package for the Virtual Interfaces or create a new one as
described in 10.3.2, Preparation on page 880.
2. Create the Web service using the Web service wizard:
a. In transaction SE80 right-click the package, for example
T_ITSOPACKAGE, and select Create Enterprise Service / Web
Service Web Service as shown in Figure 10-29.
905
3. Click Continue on the Wizard Create Web Service panel.

4. Create the Virtual Interface Z_IDOC_INBOUND_ASYNCHRONOUS_VI and
click Continue. Refer to Figure 10-30.
Figure 10-30 Create virtual interface
906
5. Choose IDOC_INBOUND_ASYNCHRONOUS as the endpoint for the Web

service as shown in Figure 10-31 and click Continue.
907
6. Enter Z_IDOC_INBOUND_ASYNCHRONOUS_WS as the name for the Web Service

Definition as shown in Figure 10-32 and click Continue.
908
7. Review the settings and click Complete.
909
8. Save the Web Service Definition and Virtual Interface within your selected
9. Assign the created artefacts to a transport request.

10.To ensure that the Web service is released, open transaction WSCONFIG,
select the created Web Service Definition
Z_IDOC_INBOUND_ASYNCHRONOUS_WS as shown in Figure 10-35 and
click Refresh.
910
11.Generate a WSDL for the created Web service by opening transaction

WSADMIN, select the generated Web Service Definition
Z_BAPI_USER_EXISTENCE_CHECK_WS and click WSDL. Refer to
Figure 10-36.
12.Select Document Style in the WSDL generation panel as shown in

WebSphere into your file system, for example C:\ITSO, of the machine where
WebSphere Integration Developer resides.
The BAPI is now Web service enabled and the WSDL file is available for the
Web service consumer.
911
Configuring ALE
The SAP application must be configured to process inbound Idocs. This chapter
describes the step-by-step configuration of ALE.
This chapter includes the following configuration steps:
Creating a Partner type Logical System (LS)

Creating an SAP Logical System
Creating a Distribution Model
Generating Partner Profiles and transactional RFC Ports
Creating a Partner of type Logical System

The Logical System is used as the partner ID for communication. To create a
Partner of type Logical System:
3. Add a entry for the WebSphere Business Integration Adapter for mySAP.com.
name it WAS and supply a description. Refer to Figure 10-38.
4. Click Save.
Figure 10-38 Transaction BD54: Logical Systems
A prompt for Workbench request window opens. SAP records information

whenever a user changes critical SAP system properties.

Open transaction SCC4 to check whether a Logical System is assigned to your
client. The Logical System is used as the ID for communication. Each system in
the distributed environment must have a unique logical system name (even
912
non-SAP systems like the WebSphere Business Integration Adapter for

mySAP.com). If it is assigned, notice the name of the Logical System, usually it is
<SID>CLNT<CLIENT>, for example BSCCLNT800.
2. Add a entry for the SAP client the Adapter is accessing. Name it
<systemname>CLNT<client>, for example BSCCLNT800, and supply a
description.
b. Click the Table view menu.
view.
d. In the dialog box that opens, click OK to continue.
e. Double-click the entry for the client number. In this case it is client 800.
f. Enter BSCCLNT800 as the logical system name of the SAP system.
4. Click Save.
Creating a distribution model in the inbound SAP application

If a message is sent from one logical system to another, you need to configure
the distribution model and specify the message type. Also, you need to configure
the sender and target logical system for the message in the distribution model.To
create a distribution model, follow these steps:
3. Click Create a Model View. Enter a Short text, for example WASCON, and a
Technical name, for example WASCON, for the Model View as shown in
Figure 10-39.
Figure 10-39 Transaction BD64: Create a model view
913
4. Select the Model View that was created and click Add Message Type.
a. Enter WAS as the name of the Logical System in the Sender field.
b. Enter BSCCLIENT800 as the name of the SAP Logical System in the
Receiver field.
c. Enter MATMAS into the Message Type field as shown in Figure 10-40.
Figure 10-40 Transaction BD64: Add a message type to the model view
5. Click Save.
914
6. Generate a Partner Profile by clicking Environment Generate Partner

Profile in the menu as shown in Figure 10-41.
915
7. In the next panel, keep the default values and click OK (Figure 10-42).
916
8. The summary is displayed. Note that no RFC ports are created because we
use only inbound processing. Refer to Figure 10-43.
917
9. Open transaction WE20 to check the Partner Profiles. Refer to Figure 10-44.
Now the SAP system is able to receive and process incoming IDocs of type
MATMAS from WebSphere through a Web service call.
918
10.4.3 Development
After the SAP system is configured, you can configure WebSphere MQ to use
SOAP, and you can develop the MQ/SAP bridge in the form of a Java Snippet. In
addition, you can implement a test client to test the Web service call through
WebSphere MQ.
This section describes the following steps:
Prerequisites
Configuring WebSphere MQ to use SOAP
Developing the MQ/SAP bridge Java Snippet and deploy it into WebSphere
MQ
Developing a stand-alone Java client to test the MQ/SAP bridge
919
Figure 10-45 shows the overall development and test process.
Enable Web service in SAP
Export
Z_IDOC_INBOUND_ASYNCHRONOUS_WS.wsdl
from SAP
Configuration
Configure WebSphere MQ to use SOAP
Import
into Rational Application Developer
Create the MQ/SAP Java Snippet in

Rational Application Developer based on the
Development
Deploy the MQ/SAP Java Snippet into WebSphere MQ.

During deployment a new wsdl file called
com.ibm.sap.MQSAPBridge_Wmq.wsdl is created.
Import
com.ibm.sap.MQSAPBridge_Wmq.wsdl
into Rational Application Developer
In Rational Application Developer

create a Web service client
based on com.ibm.sap.MQSAPBridge_Wmq.wsdl
Test the Web service call to SAP over MQ

using the generated test client
Figure 10-45 The development and test process
920
Test
Prerequisites
The following software must be installed on the system:
WebSphere MQ V6
Microsoft .NET Framework 1.1 SDK
JAVA SDK 1.4.2
Rational Application Developer (optional)
Configuring WebSphere MQ to use SOAP

As a minimum, you need to create the SOAP system response queue. You might
also need to create a default queue manager. To help, a script is supplied as part
of the SOAP WebSphere MQ installation. This script is called setupWMQSOAP,
and you can find the script in the following location:
<WebSphere MQ installation directory>\Tools\soap\samples
Executing setupWMQSOAP with no parameters creates a queue manager called
WMQSOAP.DEMO.QM. A default response queue is created at this queue

manager. Alternatively, you can specify a queue manager name as a parameter.
This scenario uses a queue manager called ITSO.QM:
setupWMQSOAP ITSO.QM
If a queue manager is specified that does not exist, the queue manager is
created. When the queue manager has been created or if it already exists, a
default response queue is created.
921
Developing the MQ/SAP bridge Java snippet

This section explains how to develop a Java snippet that calls the Web service
Z_IDOC_INBOUND_ASYNCHRONOUS_WS in SAP using SOAP/HTTP. The
Java snippet fills the IDoc segments of the control and the data record. The
snippet is deployed in a later step into WebSphere MQ. To develop the Java
snippet, follow these steps:
1. Open Rational Application Developer.
2. Generate a proxy for the SAP Web service by creating new Java project:
a. Click File New Other in the menu.
b. In the New Project dialog box, select Java Java Project and click Next
Figure 10-46 Create a new Java Project
922
c. Enter ITSO_MQSAPBridge as the Project name and click Finish as shown in

Figure 10-47.
Figure 10-47 Enter the project name
923
d. Import the wsdl file Z_IDOC_INBOUND_ASYNCHRONOUS_WS.wsdl

into Rational Application Developer:
i. Right-click the ITSO_MQSAPBridge project and select Import.
ii. In the Import dialog box, select File system and click Next as shown in
Figure 10-48.
Figure 10-48 Import the WSDL file from the file system
iii. Select the WSDL file from the folder where it is saved, for example
C:\ITSO, and click Finish.
924
e. Make sure the Web service capabilities in your Rational Application

Developer workbench are enabled. Click Windows Preferences in the
i. In the Preferences dialog box, click Workbench Capabilities.
ii. Select the capabilities Web Developer (advanced), Web Developer
(typical), and Web Service Developer as shown in Figure 10-49.
iii. Click OK.
Figure 10-49 Enable the Web Service capabilities
925
f. In the Package Explorer view, right-click

Z_IDOC_INBOUND_ASYNCHRONOUS_WS.wsdl and select Web
Services Generate Client as shown in Figure 10-50. This client is
deployed to WebSphere MQ in a later step.
g. In the Web Service client dialog box, keep the default settings and click
Finish.
926
h. Notice that in the ITSO_MQSAPBridge folder two packages, including

Java classes, are created. Refer to Figure 10-51.
Figure 10-51 The generated artifacts
927
3. Create the Java snippet that implements the Web service call to SAP:
a. Right-click the ITSO_MQSAPBridge folder and select New Class.
b. In the New Java Class dialog box, enter MQSAPBridge as the Name and
define a Package, for example com.ibm.sap.
c. Click Finish.
Figure 10-52 Enter the name of the Java class
928
d. Insert the code in the MQSAPBridge.java file (shown in Example 10-3).

For information about how to download this file, see Appendix A,
Additional material on page 1441.
Example 10-3 The MQSAP_Bridge Java class
package com.ibm.sap;
import sap_com.document.sap.rfc.functions.*;
import sap_com.document.sap.rfc.functions.holders.*;
public class MQSAPBridge {
public static final String SCCSID = "@(#) @(#) com/ibm/sap/MQSAPBridge.java, soap,
p000, p000-L050512 1.8 06/09/19 18:12:58";
public String sendIdoc (String sdata_e1maram, String sdata_e2maktm) throws
Exception
{
String ret;
try {
//CREATE A WEB SERVICE PROXY
System.out.println("creating the proxy...");
Z_IDOC_INBOUND_ASYNCHRONOUS_WSProxy myProxy = new
Z_IDOC_INBOUND_ASYNCHRONOUS_WSProxy();
//SET THE WEB SERVICE ENDPOINT

System.out.println("calling an operation on the proxy...");
myProxy.setEndpoint("http://ITSO.SAP.1:8000/sap/bc/srt/rfc/sap/Z_IDOC_INBOUND_ASYNCHR
ONOUS_WS?sap-client=800");
System.out.println("the endpoint of the proxy is " +
myProxy.getEndpoint());
//SET PARAMETERS OF IDOC CONROL RECORD

System.out.println("Setting the IDoc Control Record parameters...");
EDI_DC40 eDI_DC40 = new EDI_DC40();
eDI_DC40.setMANDT(new Clnt3("800"));//CLIENT
eDI_DC40.setDOCREL(new Char4("640"));//SAP RELEASE
eDI_DC40.setDIRECT(new Char1("2"));//IDOC DIRECTION 2=INBOUND
eDI_DC40.setIDOCTYP(new Char30("MATMAS05"));//IDOCTYPE
eDI_DC40.setMESTYP(new Char30("MATMAS"));//MESSAGETYPE
eDI_DC40.setSTDMES(new Char6("MATMAS"));//EDI MESSAGETYPE
929
eDI_DC40.setSNDPOR(new Char10("XMLPORT"));//SENDERPORT
eDI_DC40.setSNDPRT(new Char2("LS"));//SENDERPARTNERTYPE
eDI_DC40.setSNDPRN(new Char10("WEBSPHERE"));//SENDERPARTNER
eDI_DC40.setRCVPOR(new Char10("SAPBSC"));//RECEIVERPORT
eDI_DC40.setRCVPRT(new Char2("LS"));//RECEIVERTYPE
eDI_DC40.setRCVPRN(new Char10("BSCCLNT800"));//RECEIVERPARTNER
eDI_DC40.setCREDAT(new Date("2006-10-03"));//CREATIONDATE
eDI_DC40.setCRETIM(new Time("09:09:09"));//CREATIONTIME
//END SET PARAMETERS OF IDOC CONROL RECORD
//ADD THE CONTROL RECORD TO A HOLDER TABLE
TableOfEDI_DC40 tableOfEDI_DC40 = new TableOfEDI_DC40 ();
tableOfEDI_DC40.setItem(0,eDI_DC40);
TableOfEDI_DC40Holder tableOfEDI_DC40Holder = new
TableOfEDI_DC40Holder(tableOfEDI_DC40);
//SET PARAMETERS OF IDOC DATA RECORD

System.out.println("Setting the IDoc Data Record parameters...");
//SET SEGMENT E1MARAM
EDI_DD40 eDI_DD40_e1maram = new EDI_DD40();
eDI_DD40_e1maram.setSEGNAM(new Char30("E1MARAM"));//SEGMENTNAME
eDI_DD40_e1maram.setMANDT(new Clnt3("800"));//CLIENT
eDI_DD40_e1maram.setDOCNUM(new Char16(""));//DOCNUMBER
eDI_DD40_e1maram.setSEGNUM(new Char6("000001"));//SEGMENTNUMBER
eDI_DD40_e1maram.setPSGNUM(new Numeric6("000000"));//NUMBER OF THE ELEMENT
ABOVE IN HIERARCHIE
eDI_DD40_e1maram.setHLEVEL(new Char2("02"));//HIERARCHIELEVEL
eDI_DD40_e1maram.setSDATA(new Longchar1000(sdata_e1maram));//DATA STRING
//SET SEGMENT E2MAKTM
EDI_DD40 eDI_DD40_e2maktm = new EDI_DD40();
eDI_DD40_e2maktm.setSEGNAM(new Char30("E2MAKTM"));//SEGMENTNAME
eDI_DD40_e2maktm.setMANDT(new Clnt3("800"));//CLIENT
eDI_DD40_e2maktm.setDOCNUM(new Char16(""));//DOCNUMBER
eDI_DD40_e2maktm.setSEGNUM(new Char6("000002"));//SEGMENTNUMBER
eDI_DD40_e2maktm.setPSGNUM(new Numeric6("000001"));//NUMBER OF THE ELEMENT
ABOVE IN HIERARCHIE
eDI_DD40_e2maktm.setHLEVEL(new Char2("03"));//HIERARCHIELEVEL
eDI_DD40_e2maktm.setSDATA(new Longchar1000(sdata_e2maktm));//DATA STRING
//END SET PARAMETERS OF IDOC DATA RECORD
//ADD THE DATA RECORDS TO A HOLDER TABLE
TableOfEDI_DD40 tableOfEDI_DD40 = new TableOfEDI_DD40 ();
tableOfEDI_DD40.setItem(0,eDI_DD40_e1maram);
930
tableOfEDI_DD40.setItem(1,eDI_DD40_e2maktm);
TableOfEDI_DD40Holder tableOfEDI_DD40Holder = new
TableOfEDI_DD40Holder(tableOfEDI_DD40);
//CALL SAP USING THE PROXY

System.out.println ("Calling SAP...");
myProxy.IDOC_INBOUND_ASYNCHRONOUS(tableOfEDI_DC40Holder,
tableOfEDI_DD40Holder);
System.out.println ("IDoc sent to SAP");
ret = "IDoc sent to SAP";
} catch (Exception e)
{
System.out.println(e.toString());
ret = e.toString();
}
return(ret);
}
}
e. Add SAP user credentials to the Web service binding, which is required to
log into SAP. First, open the file
Z_IDOC_INBOUND_ASYNCHRONOUS_WSSoapBindingStub.java in the
package sap_com.document.sap.rfc.functions.
Then, add the following two lines of code into the
com.ibm.ws.webservices.engine.client.Stub.Invoke
_getIDOC_INBOUND_ASYNCHRONOUSInvoke0 method as shown in
Figure 10-53 on page 932:
mc.setUsername("twilms");
mc.setPassword("myPassword");
The code sets the SAP user ID and password in the HTTP header.
f. Save and close the file.
931
Figure 10-53 Add the SAP user credentials
g. Perform the clean up steps for the generated Java classes:

i. The item variable in the class TableOfEDI_DC40.java is not initialized.
Therefore, you need to open the file TableOfEDI_DC40.java in the
package sap_com.document.sap.rfc.functions.
932
ii. Then, replace this line of code:

private sap_com.document.sap.rfc.functions.EDI_DC40[] item;
with this line of code:
private sap_com.document.sap.rfc.functions.EDI_DC40[] item =
new EDI_DC40[1];
Figure 10-54 Initialize the item variable
iii. Repeat steps i and ii to add the initialization of the item variable also in
the TableOfEDI_DD40.java file.
iv. Then, replace the following line of code:
private sap_com.document.sap.rfc.functions.EDI_DD40[] item;
with this line of code:
private sap_com.document.sap.rfc.functions.EDI_DD40[] item =
new EDI_DD40[1];
Figure 10-55 Initialize the item variable
v. Save and close the files.

Now the client code is implemented, and you can deploy it into WebSphere MQ.
933
Deploying the MQSAPBridge.java into WebSphere MQ

This section describes how to deploy the Java snippet MQSAPBridge Web
service client into WebSphere MQ. This snippet also acts as Web service
provider which can be called using SOAP over WebSphere MQ. To deploy the
Java snippet, follow these steps:
1. Create a folder in your file system of the server where WebSphere MQ is
installed, for example C:\ITSO\com\ibm\sap.
2. Export the packages as jar file from Rational Application Developer into the
folder C:\ITSO\com\ibm\sap:
a. In Rational Application Developer select both packages
sap_com.document.sap.rfc.functions and
sap_com.document.sap.rfc.functions.holders, right-click them and click
Export as shown in Figure 10-56.
Figure 10-56 Export the packages
934
b. In the Export dialog box, select JAR file and click Next as shown in
Figure 10-57.
Figure 10-57 Export the packages as JAR file
935
c. In the JAR Export dialog box, enter C:\ITSO\com\ibm\sap\sap_com.jar as

the path and name for the JAR file, and then click Finish as shown in
Figure 10-58.
Figure 10-58 Enter a name for the JAR file
936
3. Export the MQSAPBridge.java into the folder C:\ITSO\com\ibm\sap:

a. Right-click MQSAPBridge.java and select Export.
b. In the Export dialog box, select File system and click Next.
c. Select as export target directory, C:\ITSO\com\ibm\sap, and click Finish.
Figure 10-59 Export the MQSAP_Bridge.java file
Now all required artifacts for the deployment into WebSphere MQ are
exported from Rational Application Developer into the file system.
4. Open a Command Prompt and switch to the folder C:\ITSO\com\ibm\sap.
937
5. Execute the dir command to check that the exported files are available.
Figure 10-60 shows the output for the dir command.
Figure 10-60 The exported files
6. Add the exported sap_com.jar to the CLASSPATH variable by entering the

following command:
set CLASSPATH=%CLASSPATH%;C:\ITSO\com\ibm\sap\sap_com.jar
938
7. Add other classes to the CLASSPATH variables that are required for
performing the WebSphere MQ deployment steps. Run
C:\WebSphereMQ\bin\amqwsetcp.cmd to set the CLASSPATH variable. Refer
to Figure 10-61.
Figure 10-61 Run amqwsetcp.cmd
8. Perform the deployment by running the following command:

C:\WebSphereMQ\bin\amqwdeployWMQService.cmd -f
com/ibm/sap/MQSAPBridge.java.
In a simple deployment where no queue manager or response queue has
been specified, amqwdeployWMQService uses the default queue manager and
port. For more information about amqwdeployWMQService, visit the WebSphere
MQ Information Center:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp
Note: The PATH variable must be set to the java\bin directory of the Java
SDK for the javac command that amqwdeployWMQService uses to work
correctly.
It is also important that you perform the command in the C:\ITSO directory.
You need to place the code in this directory structure for the javac
command that amqwdeployWMQService uses to work. For further
information, refer to:
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html
939
To use WebSphere MQ as a transport mechanism, the service needs access

to a queue manager. There is a request queue set up during the deployment
process: SOAPJ.com.ibm.sap.MQSAPBridge. This is the request queue that
the service uses. Client request messages are placed on this queue. The
name of the queue is a generated name based on the service package and
source file names. A custom name for the request queue name can be
specified in the deployment script as parameter. You created the response
queue in Configuring WebSphere MQ to use SOAP on page 921.
A listener configuration is created during the deployment process for a
particular request queue. This listener only listens on the specified request
queue. As the only action performed on the response queue by a listener is a
write, multiple listeners can share a response queue.
Within the directory that amqwdeployWMQService was executed, for
example C:\ITSO, a new file and a folder was created:
The new file is server-config.wsdd, a generated service deployment
descriptor for Axis.
The new folder is called generated and contains the rest of the output from
amqwdeployWMQService.
WDSL file. This is named after the service, including package name, with
the suffix _Wmq, in this case, com.ibm.sap.MQSAPBridge_Wmq.wsdl.
Folder named Client, which includes generated proxy code for the
following service:
Visual Basic and C# proxy code with a suffix of Service. In this case
MQSAPBridgeService.cs and MQSAPBridgeService.vb.
Folder called Remote containing the Java client code in the appropriate
folder structure.
Folder named Server, which includes:
Script files to start and stop the listener. For a Windows system, they
are called startWMQJListener.cmd and endWMQJListener.cmd.
A folder structure based on the package name. In this case, a folder

called com/ibm/sap. At the bottom of this structure is the class file for
the service and Axis deploy/undeploy files for the services.
Now the Web service is deployed to WebSphere MQ.

9. Start the WebSphere MQ listener by using the following script:
C:\ITSO\generated\server\startWMQJListener.cmd
940
Developing a stand-alone Java client to test the MQ/SAP

bridge
The Java client class acts as client and calls the MQSAPBridge Web service,
that is deployed in WebSphere MQ, through SOAP/MQ. To develop a
stand-alone Java client to test the MQSAPBridge Web Service, follow these
steps:
1. In Rational Application Developer create a new Java project for the client
application.
a. Select File New Project.
b. Select Java Java Project in the New Project dialog box and click Next
Figure 10-62 Create a new Java project
c. Name the project ITSO_ClientApp and click OK.

2. Import from the File system the WSDL file
C:\ITSO\generated\com.ibm.sap.MQSAPBridge_Wmq.wsdl into the project
ITSO_ClientApp.
941
3. Right-click the imported WSDL as shown in Figure 10-63 and select Web
Services Generate Client.
942
4. In the Web Service Client dialog box, set the Client proxy type to Java proxy
Figure 10-64 Select Java proxy
5. Review the generated Java proxy classes in the ITSO_ClientApp project.
Figure 10-65 The generated Java proxy
6. Create a Java class in the project. This class includes a main method, and it
acts as client that uses the generated Java proxy. Follow these steps:
a. Right-click the new created project ITSO_ClientApp and select New
Class.
b. In the New Java Class dialog box, enter ClientApp as a name for the
class.
943
c. Enter MQSAPVBridge_Wmq.sap.ibm.com as the Package name.

d. Select to create a main method as shown in Figure 10-66 and click Finish.
Figure 10-66 Create a new Java class
944
7. In the Java editor pane insert the code as shown in Figure 10-67.
Figure 10-67 Used Java code
8. Note that the packages com.ibm.sap.* are imported. Therefore, you must add
the project ITSO_MQSAPBridge to the Java Build Path of the
ITSO_ClientApp project. To add this project, follow these steps:
a. Right-click the ITSO_ClientApp and select Properties.
945
b. In the Properties for ITSO_ClientApp dialog box, click Java Build Path
and click the Projects tab as shown in Figure 10-68. Select
ITSO_MQSAPBridge.
Figure 10-68 Add the ITSO_MQSAPBridge project to the Java Build Path
9. Switch to the Libraries tab to add the required WebSphere MQ libraries for
the project.
10.Add the jar files listed in Table 10-1 to the Java Build Path of the project by
using the Add External JARs option.
Table 10-1 Add the jar files to the Java Build Path
946
Library
Location
axis.jar
<WebSphere MQ installation directory>\Java\lib\soap
commons-discovery.jar
commons-logging.jar
jaxrpc.jar
saaj.jar
servlet.jar
wsdl4j.jar
com.ibm.mq.jar
<WebSphere MQ installation directory>\Java\lib
com.ibm.mq.soap.jar
commonservices.jar
11.Click OK to close the Java Build Path dialog box.
10.4.4 Testing
This section explains how to start ITSO_ClientApp to test the scenario.
ITSO_ClientApp calls the MQSAP_Bridge Web service through SOAP/MQ. The
MQSAP_Bridge sends an IDoc through SOAP/HTTP into SAP. The IDoc is
processed in SAP. To start ITSO_ClientApp:
1. In Rational Application Developer open the MQSAP_Bridge project.
2. Select Run Run As 3 Java Application as shown in Figure 10-69. The
IDoc data is sent through the Web service into SAP.
Figure 10-69 Run as Java Application
947
3. Check in the SAP transaction WE02 that the IDoc was processed
successfully (Figure 10-70).
Figure 10-70 The inbound IDoc
Completing these steps means that the test was successfully performed. The
IDoc data was sent from the WebSphere stand-alone Java snippet over
SOAP/MQ to the MQSAP_Bridge service in WebSphere MQ. The
MQSAP_Bridge service transferred the IDoc data through SOAP/HTTP to SAP.
10.4.5 Conclusion
Web service in SAP. A stand-alone Java client puts a message on a queue using
SOAP/MQ. A Java Axis Web service deployed on WebSphere MQ served this
request and called the Web service exposed RFC
948
IDOC_INBOUND_ASYNCHRONOUS in SAP to send the IDoc into SAP using

SOAP over HTTP.
949
950
11
Chapter 11.
Adapter-based integration to
SAP: JCA Adapter
BAPI scenarios
This chapter provides an overview of the implemented scenarios and describes
the common preparations for all scenarios. It also includes the installation of the
WebSphere Adapter for SAP Software and the configuration of the WebSphere
Enterprise Service Bus and WebSphere Process Server. It describes the
development of the different scenarios that use the WebSphere Adapter to
connect to an SAP system through remote function calls. The scenarios include
single BAPI calls, multiple BAPI calls, transactional BAPI calls, and the use of a
remote function call to access SAP data directly.
You can enhance these scenarios with additional extensions. Extension A
explains the dynamic authentication feature of the WebSphere Adapter for SAP
Software (JCA Adapter). Extension B runs the Service Component Architecture
modules on WebSphere Enterprise Service Bus and WebSphere Process Server
using additional possibilities of the WebSphere Process Server.
951

Scenario A: WebSphere Enterprise Service Bus executes a single BAPI call
on page 970
Scenario B: WebSphere Enterprise Service Bus executes a multiple BAPI
call on page 1005
Scenario C: WebSphere Enterprise Service Bus executes a transactional
BAPI call on page 1047
Scenario D: WebSphere Enterprise Service Bus uses Read Table RFC on
page 1082
Extension A: Dynamic authentication on page 1117
Execution and test on page 1132
Extension B: WebSphere Process Server deployment and test process on
page 1139

ITSO.IBM.1
ITSO.SAP.1

6.0.1.2
SAP ERP 2004

6.0.1.2
IBM DB2 8.1
WebSphere Process Server 6.0.1.2
WebSphere Adapter for SAP

Software 6.0.1
952
Note: The scenarios that we demonstrate in this chapter require

authentication. We use the itsouser user ID and itso1 password as examples.
However, you can replace these as appropriate to suit your environment.

The scenarios are independent and focus on different options of the WebSphere
Adapter for SAP Software. There examples are included to introduce the
different communication possibilities and configuration options of the WebSphere
Adapter. The scenarios include:
Scenario A: WebSphere Enterprise Service Bus executes a single BAPI call
A single BAPI call is a synchronous call. The adapter supports single BAPI
calls by representing each with a single business object schema.
Scenario B: WebSphere Enterprise Service Bus executes a multiple BAPI call
A multiple BAPI call is the same as a single call. The adapter supports to
group different single BAPI calls with different operations (Create,
UpdateWithDelete, Retrieve, and Delete) for a special use case. Each call
needs to be performed singularly.
Scenario C: WebSphere Enterprise Service Bus executes a transactional
BAPI call
A BAPI transaction, also referred to as BAPI Logical Unit of Work, consists
of a set of BAPIs that are executed in sequence so as to complete the entire
transaction.
Scenario D: WebSphere Enterprise Service Bus uses Read Table RFC
The WebSphere Business Integration Adapter had a module called
Hierarchical Dynamic Retrieve (HDR) to access SAP tables. This function is
also possible with the WebSphere Adapter by using a single RFC call.
Technically this is the same solution, just that there is not a special HDR
configuration needed.
Chapter 11. Adapter-based integration to SAP: JCA Adapter BAPI scenarios
953
Extension A: Dynamic authentication

The WebSphere Adapter for SAP Software supports the possibility to build up
the adapter connection with a named user. This dynamic authentication could
be used if the login to SAP requires a special username in runtime and not a
technical user for all SAP connections.
Extension B: WebSphere Process Server deployment and test process
The SAP integration is the same whether the components and adapters are
running on WebSphere Enterprise Service Bus or WebSphere Process
Server. However, the WebSphere Process Server offers some powerful
additional features.
11.3 Preparation
The scenarios access SAP through the WebSphere Adapter for SAP Software
which is using SAP JCo. There are common preparation steps for all scenarios.
You need to install the WebSphere Adapter for SAP Software, and you need to
create a Java 2 Connector (J2C) Authentication Data Entry in the runtime
environment.
The procedure to install WebSphere Enterprise Service Bus, WebSphere
Process Server, WebSphere Integration Developer, and SAP JCo is not part of
this book. Check the product documentation if you do not have these products
installed.
11.3.1 Installing SAP JCo

In the Windows environment, do the following:
1. Copy sapjco.jar into the WebSphere Integration developer directory
\runtimes\bi_v6\lib\ext.
2. Copy librfc32.dll and sapjcorfc.dll into the WebSphere Integration developer
directories \runtimes\bi_v6\java\bin and \eclipse\jre\bin#.
3. Install the Microsoft files msvcp71.dll and msvcr71.dll files in the Windows
system path. See SAP Note 684106 on the SAP Service Marketplace Web
site (www.service.sap.com) for additional details. The DLL files are included
in the attachments section of the SAP Note along with instructions about how
to install them. You must have a valid user name and password for the SAP
Service Marketplace to view the SAP Note.
For platforms other than Windows, refer to SAP JCo installation documentation.
954
11.3.2 Installing WebSphere Adapter for SAP Software

This section describes how to install the WebSphere Adapter for SAP software
into the System.
Note: Make sure that you have the WebSphere Adapter for SAP 6 Package
for Windows as well as the latest fix pack available.
Follow these steps:
1. Use the launchpad_win.exe in the extracted 6.0.0 directory.
2. Select English as the language and click OK as shown in Figure 11-2.
Figure 11-2 Choose Launchpad language
955
3. Click Install Product. Refer to Figure 11-3.
Figure 11-3 Start installation process
956
4. You see the Welcome panel as shown in Figure 11-4. Click Next.
Figure 11-4 Installation welcome
5. Read the software license agreement. If you accept the terms of the
agreement, select that option as shown in Figure 11-5 and click Next.
Figure 11-5 Installation license
957
6. Click Browse and select C:\websphere\SAPAdapter as the installation path.

Then, click Next as shown in Figure 11-6.
Figure 11-6 Installation path
7. You see the summary as shown in Figure 11-7. Click Next.
Figure 11-7 Installation summary
958
8. After the installation, you get a successfully installed notice, as shown in

Figure 11-8 Installation success
Important: Always apply the latest fix pack as explained in the product
documentation.
After you set up the WebSphere Adapter for SAP Software, you find two different
adapter resource files in the target directory.
/adapter/SAP/deploy/CWYAP_SAPAdapter.rar
Use this file if you want the adapter to perform ALE and BAPI processing
without local transaction support. In this case, the application provides the
local transaction support.
/adapter/SAP/deploy/CWYAP_SAPAdapter_Tx.rar
Use this file if you want the container (WebSphere Process Server) to control
local transaction support for BAPI processing. In this case, the adapter
participates in the local transaction started by the container.
959
11.3.3 Deploying WebSphere Adapter for SAP Software

This section describes the installation of the WebSphere Adapter for SAP
software into the WebSphere Integration Developer environment. Follow these
steps:
1. Open WebSphere Integration Developer.
2. Change to J2EE perspective. Select Window Open Perspective Other
and choose J2EE in the dialog box. Refer to Figure 11-9.
Figure 11-9 Select J2EE Perspective
960
3. Inside the Project Explorer, right-click Connector Projects and select

Import RAR file as shown in Figure 11-10.
Figure 11-10 Import connector RAR file
961
4. Click Browse next to Connector file and open CWYAP.SAPAdapter.rar

(located in \adapter\SAP\deploy directory within the directory where the
adapter is installed). Refer to Figure 11-11.
5. Select WebSphere ESB Server v6.0 as the Target server.
6. Clear the Add module to an EAR project option.
7. Click Finish.
Figure 11-11 Connector RAR file import properties
962
8. Inside the Project Explorer, right-click the new project CWYAP_SAPAdapter

and select Properties from the context menu.
9. Select the Java Build Path property. Refer to Figure 11-12.
10.Select the Libraries tab and click Add External JARs.
11.In the file dialog box, open the sapjco.jar (in \WID\runtimes\bi_v6\lib\ext
directory). Then, click OK.
Figure 11-12 Change SAP adapter properties
The SAP Adapter is installed in the WebSphere Integration Developer

environment.
11.3.4 Configuring J2C authentication data

It is recommended that you store the SAP credentials in the Java 2 Connector
Authentication (J2C) alias. Otherwise, the password is visible in the configuration
files. To configure J2C authentication data, follow these steps:
1. Start WebSphere ESB Server v6.0 in the Server view. If the Server view is not
visible, select Window Show View Servers. Select the ESB Server
963
v6.0 and click Start. Wait until the server status changes to Started. Refer to
Figure 11-13.
Figure 11-13 Start server
2. After it is started, right-click again on the name and select Run

administrative console as shown in Figure 11-14.
Figure 11-14 WebSphere Enterprise Service Bus run administrative console
964
3. You do not need a user name to log in. Just click Log in as shown in
Figure 11-15.
Figure 11-15 Log in
965
Creating J2C authentication data

To create J2C authentication data, follow these steps:
1. Navigate to the J2C Authentication data panel (Figure 11-16):
a. On the left pane, click Security Global Security.
b. On the right pane, click JAAS configuration J2C Authentication
data.
Figure 11-16 Navigate to J2C configuration
966
2. Create a new entry with valid SAP credentials in it:

a. Click New to create a new entry. Refer to Figure 11-17.
Figure 11-17 Add new J2C entry
967
b. Enter the data provided in the Table 11-1. Refer to Figure 11-18.
Table 11-1 User Credentials for the SAP System
Alias
SAPLogin
User ID
itsouser
Password
itso1
Figure 11-18 Add new J2C entry fill data
c. Click OK.
968
d. A new Entry, esbNode/SAPLogin, is in the list. Click the Save link to save
the master configuration and check whether the new entry is in the list.
Figure 11-19 Add new J2C entry save
e. To make sure it is saved, click Save, which results in a new Entry with
esbNode/SAPLogin as J2C Authentication data name. Refer to
Figure 11-20.
Figure 11-20 Add new J2C entry save complete
3. Repeat steps 1 and 2 to configure the WebSphere Process Server v6.0 in the
same way.
969

executes a single BAPI call
A single BAPI call is a synchronous call. The adapter supports single BAPI calls
by representing each with a single business object schema. BAPIs that represent
Create, UpdateWithDelete, Retrieve, and Delete operations are grouped with a
wrapper business object during business object generation using the enterprise
service discovery wizard. The BAPIs are children of the business object wrapper.
Only one BAPI, the one that is associated with the operation to be performed, is
called at a time.
The adapter relies on the metadata at the business object and property level to
convert the business object into the appropriate SAP API function call. After the
SAP system processes the function call and returns it to the adapter, the adapter
converts the response into a business object that is stored in the adapters output
record.

Scenario A uses the WebSphere Adapter for SAP Software to connect through
SAP Remote Function Call to the SAP Enterprise Resource Planning System.
The BAPI_USER_EXISTENCE_CHECK is used to check if a user is found in the
SAP system. Figure 11-21 gives an overview of the operational model.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
ITSOWebSphereSAPSimpleBAPI
Adapter 6.0.1
RAR
TCP/SAPRFC
User Management
One call
ITSO.IBM.1
970
ITSO.SAP.1
11.4.2 Development
Creating a module with SAP call
Creating an Export
Creating a Mediation

To create a module with SAP call, follow these steps:
1. Click New Other as shown in Figure 11-22.
Figure 11-22 Create new project
971
2. Select Enterprise Service Discovery and click Next as shown in

Figure 11-23.
Figure 11-23 Select Enterprise Service Discovery project
972
3. When prompted to select an adapter to use for discovering the service, select
IBM WebSphere Adapter for SAP Software, which you created in 11.3.3,
Deploying WebSphere Adapter for SAP Software on page 960 and click
If you have previously run the Enterprise Service Discovery wizard, your
connection properties have been saved and appear when you expand the
adapter name node (click the plus symbol, +, next to the adapter name). You
can select the saved connection properties if you plan to connect to the same
SAP application as when you last ran the Enterprise Service Discovery
wizard.
Figure 11-24 Select the adapter
4. In the Configure Settings for Discovery Agent window, Specify the adapter
configuration properties for connecting to SAP as provided in the Table 11-2.
Properties marked with an asterisk (*) are mandatory. Be sure to set the
Select Module property (under Metadata Properties) to the value BAPI.
Table 11-2 Credentials for the SAP System
Alias
SAPLogin
UserName
itsouser
Password
itso1
Client
800
System Number
00
ApplicationServerHost
ITSO.SAP.1
Select the Module
BAPI
973
5. You see the completed panel as shown in Figure 11-25. Click Next.
Figure 11-25 ESD connection data
974
6. In the next window configure the used BAPI. Click Run Query as shown in
Figure 11-26.
If you receive an error the connection to the SAP system cannot be
established. Check whether there is a firewall between you and the server or
whether the logon credentials are correct.
Figure 11-26 Run Query
975
7. Click the plus sign (+) before RFC and expand the tree structure. Then, select
Discover By Name as shown in Figure 11-27 but do not drill down further,
because a filter must be applied first.
Figure 11-27 Query result
8. Click Filter because in an SAP system there are usually a lot of BAPIs and
RFCs.
976
9. In the Filter Properties for Discover By Name window, enter the name of the
Remote Function Call (RFC) that you want to discover. You can include an
asterisk (*) as a wild card character at the beginning or end of the name to
indicate that you want to discover all SAP application components that
contain the specified name. Enter Discovery Criteria BAPI_USER* as shown in
Figure 11-28. Then, click OK to start the search.
Figure 11-28 Enter search criteria
977
10.Use the plus sign (+) before Discover By Name to expand the tree structure.
The structure only includes the filtered SAP Calls as shown in Figure 11-29.
Figure 11-29 Search result
978
11.Select BAPI_USER_EXISTENCE_CHECK and click Add. On the next

window, select Use Field Name to generate the attribute(s) as shown in
Figure 11-30.
Figure 11-30 Use field names to generate attributes
979
12.This adds the selected BAPI in the Objects to be imported field as shown in
Figure 11-31. If there is the requirement to include multiple IDocs, repeat the
previous steps. Otherwise, click Next.
Figure 11-31 Call is added
980
13.In the next window configure the used operation:

a. Enter SAPBO as the Object Location (Enter relative Path) to use a local
folder.
b. Enter exist_ as an object prefix as the name of the Business Object.
c. Click Add, select Retrieve operation for the call, and click Next as shown
in Figure 11-32.
Figure 11-32 Configure operation
981
14.The next panel offers selection of the module where the new objects and
interfaces get saved (Figure 11-33). Click New to create a new module.
Figure 11-33 Create new module
982
15.In the wizard, select Create a mediation module project to generate a

module that can be deployed to the WebSphere Enterprise Service Bus and
click Next as shown in Figure 11-34.
Figure 11-34 Create a mediation module
16.Enter ITSOWebSphereSAPSingleBAPI as the Module Name and make sure

WebSphere Enterprise Service Bus v6.0 is selected as Target Runtime as
Figure 11-35 Create a mediation module with Name
983
17.Enter the Java 2 Connector (J2C) Authentication Data Entry, configured in a

prerequisite task, and click Use discovered connection properties. With
this option the user name and password comes out of the server and the
Adapter with the needed parameter get stored in the module.
18.Specify the SAP connection properties as shown in Figure 11-36.
Restriction: The Node level deployment of the WebSphere Adapter for
SAP Software is currently not supported. Always deploy with the options
Adapter with module and Use discovered connection properties
selected.
Attention: Do not fill the UserName and Password fields in this panel.
These fields were used for the development process before the J2C
Authentication Data Entry was supported. Now, the values stored in these
fields are not used, but they are readable in the module development in
clear text.
984
Figure 11-36 Use Server configuration
985
19.Click Finish to generate all artifacts. Refer to Figure 11-37.
Figure 11-37 New generated module
At this point, the SAPOutboundInterface is ready. In the next steps build a

sample mediation module to receive the data out of the inbound interface,
transform it to another interface and provide it to other SCA components.
Creating an Export
To create an export, follow these steps:
1. Add an Export to the Assembly Diagram by using the palette to make the
SCA component callable from outside, as shown in Figure 11-38.
Figure 11-38 Add Export
986
2. Right-click the Interfaces name and select New Interface because we

map the complex SAP interface to a much simpler for easy use. Refer to
Figure 11-39.
Figure 11-39 Create interface
3. Set UserExist as the Name (Figure 11-40).
Figure 11-40 Name interface
987
4. Use Add Request Response Operation and name it checkUser

(Figure 11-41).
Figure 11-41 Add operation
5. Use Add Input and name the Input username (Figure 11-42).
Figure 11-42 Add Input
6. Use Add Output and name the output existResponse (Figure 11-43).
Figure 11-43 Add Output
7. The interface is finished. Just save it. Refer to Figure 11-44.
Figure 11-44 Interface complete
988
8. In the Assembly Diagram use the Wire tool and wire the bound interface to
the Mediation (Figure 11-45).
Figure 11-45 Wire added SCA Components
9. If a window opens, click OK to create needed references (Figure 11-46).
Figure 11-46 Approve wire
10.Use the Add Interface option for the Export. Refer to Figure 11-47.
Figure 11-47 Add interface to export
989
11.In the window, select the new created Interface UserExist and click OK as
Figure 11-48 Select interface
12.Wire the Export to the Mediation component.
990
To create a Mediation, follow these steps:
1. Right-click Mediation1 and select Generate Implementation as shown in
Figure 11-49.
Figure 11-49 Generate implementation
2. Select the default folder to store the implementation (Figure 11-50).
Figure 11-50 Select folder
991
3. The Mediation Flow Editor opens. Just connect the checkUser operation from
the newly created interface with the retrieveSapexist_Wrapper operation from
the SAP interface through drag-and-drop. Refer to Figure 11-51.
Figure 11-51 Connect operations
992
4. Add a Extensible Stylesheet Language (XSL)Transformation to the flow as

Figure 11-52 Add XSL transformation
5. Connect the flow as shown in Figure 11-53.
Figure 11-53 Connect flow
993
6. In the detail properties of the XSL Transformation click New as shown in

Figure 11-54.
Figure 11-54 New mapping
7. Accept the defaults and click Finish as shown in Figure 11-55.
Figure 11-55 Accept default mapping
994
8. This opens the mediation editor. Open the tree structures and assign the
username on the left through drag-and-drop to the Username on the right.
Figure 11-56 Define mapping
9. This drag-and-drop adds the mapping to the overview section (Figure 11-57).
Figure 11-57 Mapping defined
995
10.Save and Close the XSL Transformation. In the Mediation Flow Editor, switch
to the Response configuration, as shown in Figure 11-58.
Figure 11-58 Switch to response tab
11.Create a similar XSL Transformation for the response. Just map the Message
[0..1] to the existResponse, as shown in Figure 11-59.
Figure 11-59 Response mapping complete
12.In the detail properties of both XSL Transformation, click Regenerate XSL as
Figure 11-60 Generate XSL
996
13.Both times a Message window displays as shown in Figure 11-61. Click OK.
Figure 11-61 XSL generated
14.Finally, click Generate Binding SCA Binding as shown in Figure 11-62.
Figure 11-62 Generate SCA binding
997
15.Click Project in the menu and check whether your WebSphere Integration
Developer is configured to Build Automatically as shown in Figure 11-63. If
not, start the Build Project.
Figure 11-63 Build automatically
998
11.4.3 Deployment
This section illustrates how to deploy the created SCA module in a WebSphere
Enterprise Service Bus environment. The same deployment for the WebSphere
Process Server is illustrated in 11.9.3, Deployment on page 1153.
To deploy to WebSphere Enterprise Service Bus:
1. Start WebSphere Enterprise Service Bus as described in 11.3.4, Configuring
J2C authentication data on page 963. If the server is started, right-click the
entry in the Server tab and select Add and remove projects as shown in
Figure 11-64.
Figure 11-64 Add project to WebSphere Enterprise Service Bus
999
2. Select the module on the left and click Add to move it to the right
(Figure 11-65).
3. Click Finish.
1000

WebSphere Enterprise Service Bus environment. The same execution and test
for the WebSphere Process Server is illustrated in 11.9.4, Execution and test on
page 1155. In the test you do a single call to SAP to check if a user is known in
the SAP system. To test with WebSphere Integration Developer Test Client:
1. Right-click in the assembly editor on the Export and select Test Component
2. This starts the test client which is integrated in the WebSphere Integration
Developer environment. Switch to the Configurations tab (Figure 11-67).
Figure 11-67 Switch to Configurations tab
1001
3. Select Emulators and click Remove as shown in Figure 11-68.
Figure 11-68 Remove Emulators
4. When all Emulators are removed, go back to the Events tab (Figure 11-69).
Figure 11-69 All Emulators removed
1002
5. Enter itsouser in the table field on the right side which represents the data
input for the call and click Continue to start the test (Figure 11-70).
Figure 11-70 Fill input
6. A window opens to select the server where the application is deployed.

Choose WebSphere ESB Server v6.0 as shown in Figure 11-71.
1003
You see the result with values in the Test Client table. Refer to Figure 11-72.
Figure 11-72 Test Client result
11.4.5 Conclusion
This scenario demonstrates how you can configure the WebSphere Adapter to
provide an interface to call an SAP BAPI from an SAP ERP System to interact
with the system. This kind of interaction with SAP is used if special calls with data
retrieval or data manipulation is needed and there is a BAPI or RFC available to
solve this task. It is more easier and faster than using complex IDocs.
1004

executes a multiple BAPI call
A multiple BAPI call is the same as the single call. The adapter supports to group
different single BAPI calls with different operations (Create, UpdateWithDelete,
Retrieve, Delete) for a special use case. Each call needs to be performed
singularly. Refer to Figure 11-73.
BAPI_USER_CHANGE
Business Object
create
BAPI_USER_CREATE1
Update with delete

delete
BAPI_USER_DELETE
retrieve
BAPI_USER_GET_DETAIL
Figure 11-73 Operations in the business object
This is a good possibility to group SAP calls that operate with the same object to
a single adapter configuration.
1005

Scenario B uses the WebSphere Adapter for SAP Software to connect through
SAP Remote Function Calls to the SAP Enterprise Resource Planning System.
The BAPI_USER_GET_DETAIL is used to retrieve the user first name out of the
SAP system. The BAPI_USER_CHANGE is used to change this first name.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
ITSOWebSphereSAPMultipleBAPI
Adapter 6.0.1
RAR
TCP/SAPRFC
One call per

operation
ITSO.IBM.1
User Management
BAPI_USER_CHANGE
BAPI_USER_CHANGE
BAPI_USER_CREATE1
BAPI_USER_CREATE1
BAPI_USER_DELETE
BAPI_USER_DELETE
ITSO.SAP.1
11.5.2 Development
The section includes following steps:
Creating an Export
1006

1. Click New Other to create a new Project as shown in Figure 11-75.
Figure 11-75 Create new Project
1007

Figure 11-76.
1008
IBM WebSphere Adapter for SAP Software that you created in 11.3.3,
SAP application as when you last ran the Enterprise Service Discovery
wizard.
Figure 11-77 Select the adapter
4. In the Configure Settings for Discovery Agent window, complete the

connection credentials as provided in Table 11-3.
Alias
SAPLogin
UserName
itsouser
Password
itso1
Client
800
System Number
00
ITSO.SAP.1
Select the Module
BAPI
1009
1010
6. In the next window configure the used BAPI. Click Run Query (Figure 11-79).
established. Check whether there is a firewall between you and the server or
whether the logon credentials are correct.
1011
Discover By Name as shown in Figure 11-80.
1012
RFCs.
contain the specified name.
Enter Discovery Criteria BAPI_USER* as shown in Figure 11-81. Then, click
OK to start the search.
1013
10.Use the plus sign (+) before Discover By Name to expand the tree structure.
The structure only includes the filtered SAP Calls as shown in Figure 11-82.
1014
11.Select BAPI_USER_CHANGE. Click Add and on the next window, select

Use Field Name to generate the attribute(s) as shown in Figure 11-83.
1015
12.This adds the selected BAPI in the Objects to be imported field

(Figure 11-84). If there is the requirement to include multiple IDocs, repeat the
previous steps. Otherwise, click Next.
Figure 11-84 Calls are added
1016

a. Enter SAPBO as the Object Location (enter relative Path) to use a local
folder.
b. Enter user_ as an object prefix as the name of the Business Object.
in Figure 11-85.
Figure 11-85 Configure select box
1017
14.Assign the BAPIs as shown in Figure 11-86 and click Next.
Figure 11-86 Configure complete
1018
15.The next panel offers selection of the module where the new objects and
interfaces get saved. Click New to create a new module (Figure 11-87).
Figure 11-87 Create new Module
1019
16.In the wizard, select Create a mediation module project to generate a

module that can be deployed to the WebSphere Enterprise Service Bus and
click Next as shown in Figure 11-88.
17.Enter ITSOWebSphereSAPMultipleBAPI as the Module Name and make sure

WebSphere Enterprise Service Bus v6.0 is selected as Target Runtime.
Click Finish. Refer to Figure 11-89.
Figure 11-89 Create a mediation module name
1020
18.Enter the Java 2 Connector (J2C) Authentication Data Entry and click Use
discovered connection properties as shown in Figure 11-90. With this
option the user name and password comes out of the server and the adapter
with the needed parameter get stored in the module.
SAP Software is currently not supported. Always deploy with the options
selected.
Attention: Do not complete the UserName and Password fields in this

panel. These fields were used for the development process before the J2C
Authentication Data Entry was supported. Now, the values stored in these
fields are not used, but they are readable in the module development in
clear text.
19.Click Finish to generate all artifacts.
1021
Figure 11-90 Set J2C and JNDI names
1022
At this point, the SAP Outbound interface is ready (Figure 11-91). In the next
steps, you build a sample mediation module to receive the data out of the
inbound interface, transform it to another interface, and provide it to other SCA
components.
Creating an Export
To create an export, follow these steps:
1. Right-click the Interface name and select New Interface (Figure 11-92).
We map the complex SAP interface to make it easier to use.
1023
2. Set RetrieveFirstname as the Name as shown in Figure 11-93.
3. Use Add Request Response Operation and name it getFirstname

(Figure 11-94).
4. Use Add Input and name the Input username (Figure 11-95).
1024
5. Use Add Output and name the output firstname (Figure 11-96).
6. The interface is finished. Save it. Refer to Figure 11-97.
7. Create a second interface with the name SetFirstname and the details as
1025
8. Drag-and-drop the new interfaces to the Assembly Diagram. This creates a

new Export to make the SCA module callable from outside. In the window that
opens, select Export with no Binding and click OK as shown in
Figure 11-99.
Figure 11-99 Create Export
9. Create a wire between the Exports and the Mediation. Then create a wire
between the Mediation and the Outbound interface as shown in
Figure 11-100.
1026
10.If a window opens, click OK to create needed references. Refer to

Figure 11-101.
The Assembly Diagram now looks as shown in Figure 11-102.
Figure 11-102 Wired components
11.Rename the Exports as shown in Figure 11-103.
1027
Figure 11-104.
2. Select the Default folder and click OK as shown in Figure 11-105.
1028
The Mediation Flow Editor opens. Refer to Figure 11-106.
Figure 11-106 Mediation Flow editor
3. Use drag-and-drop to connect the operations as shown in Figure 11-107.
1029
4. Select the connection to get the first name and add an Extensible Stylesheet
Language (XSL) Transformation to the flow as shown in Figure 11-108.
6. Do the implementation of the GetFirstname:

a. In the detail properties of the XSL Transformation, click New as shown in
Figure 11-110.
1030
b. Accept the defaults and click Finish as shown in Figure 11-111.
c. This opens the mediation editor. Open the tree structures and assign the
username on the left through drag-and-drop to Username on the right.
1031
d. This drag-and-drop adds the mapping to the overview section. Refer to

Figure 11-113.
e. Save and Close the XSL Transformation.

f. In the detail properties of the XSL Transformation, click Regenerate XSL
1032
A Message window opens as shown in Figure 11-115.
g. In the Mediation Flow Editor, switch to the Response configuration as

h. Create a similar XSL Transformation for the response with the result as
Figure 11-117 Response xsl transformation
1033
7. Do the same for the SetFirstname mapping:

a. To include a static string to the mapping, right-click the Firstname[0..1] in
the tree structure and select Define XSLT Function as shown in
Figure 11-118.
Figure 11-118 Define XSLT Function
b. Select String and click Next as shown in Figure 11-119.
Figure 11-119 Select XSLT Function
1034
c. Select String as Function name and click Add as shown in

Figure 11-120.
Figure 11-120 Select XSLT Function
1035
d. As the value of the function enter X to use this static string and click OK as
Figure 11-121 Enter string for XSLT Function
e. Click Finish as shown in Figure 11-122.
Figure 11-122 Finish XSLT Function
1036
The Request mapping looks as shown in Figure 11-123.
Figure 11-123 SetFirstname request xsl transformation
1037
The Response mapping looks as shown in Figure 11-124.
Figure 11-124 SetFirstname response xsl transformation
8. Generate SCA bindings for both Exports as shown in Figure 11-125.
1038
9. Click Project in the menu and check whether your WebSphere Integration
Developer is configured to Build Automatically. If not, start the Build Project.
1039
11.5.3 Deployment
This section illustrates how to deploy the created SCA module in a WebSphere
Enterprise Service Bus environment. The same deployment for the WebSphere
Process Server is illustrated in 11.9.3, Deployment on page 1153.
Figure 11-127.
1040
Figure 11-128.
3. Click Finish.

This section illustrates the execution and test of the SCA module you created in a
WebSphere Enterprise Service Bus environment. The same execution and test
for the WebSphere Process Server is illustrated in 11.9.4, Execution and test on
page 1155. In the test you do a call to SAP to retrieve the user details out of the
SAP system, then you change the first name and recheck in the SAP system if
the changes are stored.
1041
To test with WebSphere Integration Developer Test Client:

1. Right-click in the assembly editor on the import and select Test Component
on the GetFirstname Export as shown in Figure 11-129. This starts the test
client which is integrated in the WebSphere Integration Developer
environment.
2. Switch to the Configurations tab as shown in Figure 11-130.
Figure 11-130 Switch to configuration
1042
3. Select the Emulators and click Remove as shown in Figure 11-131.
4. After all emulators are removed (Figure 11-132), go to the Events tab.
Figure 11-132 Emulators removed
1043
5. Enter itsouser as the username as shown in Figure 11-133 and click

Continue to start the test.
Figure 11-133 Check user set inputs
6. A window opens to select the server where the application is deployed. Select
WebSphere ESB Server v6.0 as shown in Figure 11-134.
Figure 11-134 Select target server
1044
You see the result with values in the Test Client table with Sascha as the
firstname as shown in Figure 11-135.
Figure 11-135 Test Client retrieve result
7. Right-click again in the assembly editor on the import and select Test
Component on the SetFirstname Export as shown in Figure 11-136. This
starts another test client which is integrated in the WebSphere Integration
Developer environment.
1045
8. Remove the Emulators.

9. Enter Alexander as a new firstname and itsouser as username as shown in
Figure 11-137. Click Continue.
Figure 11-137 Input change values
You see the result with values in the Test Client table with the message User
ITSOUSER has changed as shown in Figure 11-138.
Figure 11-138 Test Client change result
1046
10.Repeat steps 1 and 2 to test whether the data in the SAP system is changed.
This time the result for the firstname is Alexander as shown in Figure 11-139.
Figure 11-139 Test Client second retrieve result
11.5.5 Conclusion
This scenario demonstrates how you can configure the WebSphere Adapter to
provide different operations to call different SAP BAPI from an SAP ERP System
to interact with the system. This kind of interaction with SAP is to group a set of
special calls with data retrieval or data manipulation together to one adapter
configuration. It is more easy and faster than using complex IDocs.

executes a transactional BAPI call
A BAPI transaction, also referred to as BAPI Logical Unit of Work, consists of a
set of BAPIs that are executed in sequence so as to complete the entire
transaction. For example, to update an employee record in the SAP system, the
record needs to be locked before being updated. This is accomplished by calling
three BAPIs, in sequence, in the same transaction. The following three BAPIs
illustrate the kind of sequence that forms such a transaction:
BAPI_ADDRESSEMP_REQUEST
BAPI_ADDRESSEMP_CHANGE
BAPI_ADDRESSEMP_APPROVE
The first BAPI in the transaction locks the employee record, the second updates
the record, and the third approves the update. The advantage of using a
transaction is that the client can invoke the employee record change with a single
call, rather than with three separate calls. In addition, if SAP requires that the
1047
BAPIs execute in a specific sequence for the business flow to complete correctly,
the transaction supports this sequence.
The adapter supports a BAPI transaction, or sequence of BAPIs, using a
top-level wrapper business object that consists of multiple child BAPIs, each one
representing a single BAPI in the sequence. The BAPI transaction wrapper
object represents the complete transaction. Each second-level child business
object represents a structure parameter or table parameter of the method.
Simple attributes correspond to simple parameters of the method. The adapter
uses the application specific information set on the operation to determine the
sequence of BAPI calls. BAPI_TRANSACTION_COMMIT can be issued after
each BAPI call by specifying the keyword COMMIT in the ASI sequence. The
adapter calls BAPI_TRANSACTION_COMMIT at the end of a sequence of BAPI
calls even if the application specific information sequence does not specify any
COMMITs.
The adapter supports commit and rollback features which are provided by SAP.
It is recommended to evaluate each BAPI if it requires a dedicated commit
(BAPI_TRANSACTION_COMMIT) and if it is possible to rollback
(BAPI_TRANSACTION_ROLLBACK) the transaction.

Scenario C uses the WebSphere Adapter for SAP Software to connect through
The component does multiple calls in one operation. BAPI_USER_GET_DETAIL
is used to retrieve the user information and lock the user through the
BAPI_USER_LOCK afterwards. This is just an example to show that two
completely different BAPI operations can be performed in one Adapter operation.
1048
Figure 11-140 illustrates the operational model.

WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
ITSOWebSphereSAPTransactionalBAPI
Adapter 6.0.1
RAR
TCP/SAPRFC
Multiple calls
per operation
Sequential
Invocation
ITSO.IBM.1
User Management
BAPI_USER_CHANGE
BAPI_USER_CREATE1
BAPI_USER_LOCK
ITSO.SAP.1
11.6.2 Development
Creating a module with SAP call.
Creating an Export
1049

1. Select New Other to create a new Project as shown in Figure 11-141.
1050

Figure 11-142.
1051
IBM WebSphere Adapter for SAP Software that you created in 11.3.3,
If you have previously run the enterprise service discovery wizard, your
SAP application as when you last ran the enterprise service discovery wizard.
Figure 11-143 Select the Adapter

connection credentials that are provided Table 11-4.
1052
Alias
SAPLogin
UserName
itsouser
Password
itso1
Client
800
System Number
00
ITSO.SAP.1
Select the Module
BAPI
1053
6. In the next window, configure the used BAPI. Click Run Query as shown in
Figure 11-145.
established check if there is a firewall between you and the server or if the
logon credentials are correct.
1054
RFCs.
1055
contain the specified name. Enter Discovery Criteria BAPI_USER* as shown in
Figure 11-147. Then, click OK to start the search.
1056
10.Now use the plus sign (+) before Discover by Name to expand the tree
structure. The structure only includes the filtered SAP Calls. Refer to
Figure 11-148.
1057
11.Select BAPI_USER_GET_DETAIL. Click Add and on the next window, select

1058
12.This adds the selected BAPI in the Objects to be imported field as shown in
Figure 11-150. If there is the requirement to include multiple IDocs, repeat the
previous steps. Otherwise, click Next. Do the same for BAPI_USER_LOCK.
1059

a. Enter SAPBO as the Object Location (enter relative Path) to use a local
folder.
b. Enter user_ as an object prefix as the name of the Business Object.
in Figure 11-151.
Figure 11-151 Configure transactional object
1060
14.In the next panel, you select the module where the new objects and interfaces
get saved:
a. Click New to create a new module (Figure 11-152).
1061
b. In the wizard select Create a mediation module project to generate a

module that can be deployed to the WebSphere Enterprise Service Bus
c. Enter ITSOWebSphereSAPTransactionalBAPI as Module Name and make

sure WebSphere Enterprise Service Bus v6.0 is selected as Target
Runtime as shown in Figure 11-154.
1062
d. Enter the Java 2 Connector (J2C) Authentication Data Entry and select
Use discovered connection properties as shown in Figure 11-155. With
this option the user name and password come from the server and the
adapter with the needed parameter is stored in the module.
SAP Software is not supported currently. Always deploy with the
options selected.
Authentication Data Entry was supported. Now, the values stored in
these fields are not used, but they are readable in the module
development in clear text.
e. Click Finish to generate all artifacts.
1063
1064
The new module is now generated as shown in Figure 11-156.
At this point, the SAPOutboundInterface is ready. In the next steps, you build a
transform it to another interface, and provide it to other SCA components.
Creating the Export

To create the Export, follow these steps:
1. Right-click the Interface name and select New Interface to make it easier
to use. Refer to Figure 11-157.
1065
2. Set CheckAndLock as Name as shown in Figure 11-158.
3. Use Add Request Response Operation (Figure 11-159) and name it

DoCheckAndLock.
4. Use Add Input (Figure 11-160) and name the Input username.
1066
5. Use Add Output (Figure 11-161) and name the outputs firstname and
islocked.
7. Drag-and-drop the new interface to the Assembly Diagram to generate a new

Export to make the SCA module callable from outside. In the window that
opens, select Export with no Binding and click OK.
1067
8. Create a wire between the Export and the Mediation. Then create a wire
between the Mediation and the Outbound interface. Refer to Figure 11-164.
9. If a window opens, click OK to create needed references (Figure 11-165).
To create a mediation, follow these steps:
Figure 11-166.
1068
3. The Mediation Flow Editor opens. Just connect the DoCheckAndLock

operation with the retrieveSapuser_Txn through drag-and-drop as shown in
Figure 11-168.
4. Add an XSL Transformation to the flow as shown in Figure 11-169.
1069
6. In the detail properties of the XSL Transformation, click New as shown in

Figure 11-171.
1070
8. This opens the mediation editor. Open the tree structures and assign the user
name on the left through drag-and-drop to the Username on the right. Refer
to Figure 11-173.
1071
9. This drag-and-drop adds the mapping to the overview section. Do the same
for the second user name as shown in Figure 11-174.

11.In the detail properties of the XSL Transformation click Regenerate XSL as
1072
12.A Message window opens as shown in Figure 11-176. Click OK.
13.In the Mediation Flow Editor, go to the Response configuration as shown in

Figure 11-177.
Figure 11-177 Go to Response tab
14.Create a similar XSL Transformation for the response with the result as
Figure 11-178 Response XML transformation
1073
15.In the detail properties of the XSL Transformation, click Regenerate XSL.
16.Finally, select Generate Binding SCA Binding (Figure 11-179).
Developer is configured to Build Automatically. If not, start the Build Project
1074
11.6.3 Deployment
This section explains how to deploy the SCA module that you created in a
WebSphere Enterprise Service Bus environment. We describe the same
deployment for the WebSphere Process Server in 11.9.3, Deployment on
page 1153.
Figure 11-181.
1075
2. Select the module on the left and click Add to move it to the right. Refer to
Figure 11-182.
3. Click Finish.

This section explains how to execute and test the SCA module that you created
in a WebSphere Enterprise Service Bus environment. We describe the same
execution and test for the WebSphere Process Server in 11.9.4, Execution and
test on page 1155.
In the test, you use SAPGUI to test whether the user is locked. Then, you do a
call to SAP to retrieve the user details from the SAP system in the same
transaction that you lock the user. In the end, you recheck the SAP system to
see if the user is locked.
1076

1. Go through SAPGUI to your SAP system and navigate to the SU01. Then,
enter ITSOUSER. Refer to Figure 11-183.
Figure 11-183 SAP pre test
2. Click the Lock/Unlock button. You see that the user is not locked as shown in
Figure 11-184.
Figure 11-184 SAP pre test user not locked
1077
3. Right-click in the assembly editor on the import and select Test Component
This action starts the test client that is integrated in the WebSphere
Integration Developer environment.
a. Switch to the Configurations tab as shown in Figure 11-186.
1078
b. Select the Emulators and click Remove as shown in Figure 11-187.
c. After all emulators are removed (Figure 11-188), go to the Events tab.
Figure 11-188 Emulators removed
1079
d. Enter itsouser as the username and click Continue to start the test
(Figure 11-189).
Attention: Do not lock a user in SAP if you cannot unlock it again. At
least two users are needed.
Figure 11-189 Check user set inputs
1080
4. A window opens to select the server where the application is deployed. Select
WebSphere ESB Server v6.0 as shown in Figure 11-190.
5. You see the result with values in the Test Client table with Alexander as the
firstname and USER ITSOUSER locked for the islocked message as shown in
Figure 11-191.
1081
6. Go again to the SAPGUI panel of the SU01. Enter ITSOUSER as shown in

Figure 11-192.
Figure 11-192 SAP end test
7. Click the Lock/Unlock button. You see that the user is now locked as shown in
Figure 11-193. Click the Unlock button to unlock the user again.
Figure 11-193 SAP end test user locked
11.6.5 Conclusion
This scenario demonstrated how you can configure the WebSphere Adapter to
call different operations for different SAP BAPI from an SAP ERP System in a
row to interact with the system. This type of interaction with SAP creates a
transaction that needs to be executed in a special order. It can provide data
retrieval or data manipulation and is easier and faster than using complex IDocs.
11.7 Scenario D: WebSphere Enterprise Service Bus

uses Read Table RFC
The WebSphere Business Integration Adapter had a module called Hierarchical
Dynamic Retrieve (HDR) to access SAP tables. This function is also possible
with the WebSphere Adapter by using a single RFC on the RFC_READ_TABLE.
1082
Technically this is the same solution, just that there is not a special HDR
configuration.
You can access all SAP tables through this method, but it is not recommended to
access tables directly. If possible use RFC, BAPI, or IDocs to retrieve and update
data in SAP.

Scenario D uses the WebSphere Adapter for SAP Software to connect through
The RFC_READ_TABLE is used to access the table USR02 in the SAP system.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
USR02
ITSOWebSphereSAPReadTableBAPI
Adapter 6.0.1
RAR
ITSO.IBM.1
TCP/SAPRFC
One call
User Management
BAPI_USER_CHANGE
BAPI_USER_CREATE1
RFC_READ_TABLE
ITSO.SAP.1
1083
11.7.2 Development
Creating an Export

1. Click New Other to create a new Project as shown in Figure 11-195.
1084
2. Select the Enterprise Service Discovery and click Next as shown in

Figure 11-196.
IBM WebSphere Adapter for SAP Software, which you created in 11.3.3,
Deploying WebSphere Adapter for SAP Software on page 960. Then, click
SAP application as when you last ran the enterprise service discovery wizard.
1085
Figure 11-197 Select the Adapter

connection credentials as listed in Table 11-5.
1086
Alias
SAPLogin
UserName
itsouser
Password
itso1
Client
800
System Number
00
ITSO.SAP.1
Select the Module
BAPI
You see the completed panel as shown in Figure 11-198.
5. When the settings are configured, click Next.
1087
6. In the next window configure the used BAPI:

a. Click Run Query as shown in Figure 11-199.
If you receive an error, the connection to the SAP system cannot be
established check if there is a firewall between you and the server or if the
logon credentials are correct.
1088
b. Click the plus sign (+) before RFC and expand the tree structure. Select
c. Click Filter because in an SAP system there are usually a lot of BAPIs and
RFCs.
d. In the Enter Discovery Criteria field, enter RFC_READ* (Figure 11-201).
1089
e. Click OK and the search starts.

f. Now use the plus sign (+) before Discover by Name to expand the tree
structure. The structure only includes the filtered SAP Calls. Refer to
Figure 11-202.
1090
g. Select RFC_READ_TABLE. Click Add and on the next window, select

1091
h. This adds the selected BAPI in the Objects to be imported field as shown
in Figure 11-204. Click Next.
1092
7. In the next window, configure the used operation (Figure 11-205):

a. In the new panel, enter SAPBO as the Object Location to use a local folder.
b. Enter table_ as a object prefix as the name of the Business Object.
c. Click Add, select the Retrieve operation for the call, and click Next.
Figure 11-205 Configure read Table operation
1093
8. The next panel offers selection of the module where the new objects and
interfaces get saved:
a. Click New to create a new module. Refer to Figure 11-206.
1094
b. In the wizard select Create a mediation module project to generate a

module that can be deployed to the WebSphere Enterprise Service Bus
c. Enter ITSOWebSphereSAPReadTable as Module Name and make sure

WebSphere Enterprise Service Bus v6.0 is selected as shown in
Figure 11-208.
1095
d. Enter the J2C Authentication Data Entry and select Use discovered
connection properties as shown in Figure 11-209. With this option the
user name and password comes from the server and the adapter with the
needed parameter is stored in the module.
SAP Software is not supported currently. Always deploy with the
options Adapter with module and Use discovered connection
properties selected.
Authentication Data Entry was supported. Now, the values stored in
these fields are not used, but they are readable in the module
development in clear text.
e. Click Finish to generate all artifacts.
1096
1097
The new module is now generated. Refer to Figure 11-210.
At this point, the SAP Outbound interface is ready. In the next steps, you build a
transform it to another interface, and provide it to other SCA components.
Creating an Export
To create an Export, follow these steps:
1. Right-click the Interface name and select New Interface as shown in
Figure 11-211 because we map the complex SAP interface to a much simpler
for easy use.
1098
2. Set ReadSAPTable as the Name. Refer to Figure 11-212.
3. Use Add Request Response Operation and name it DoCheckAndLock. Refer

to Figure 11-213.
4. Use Add Input and name the Input Table, SAPOption, and Column. Refer to
Figure 11-214.
1099
5. Use Add Output and name the output DataRow. Refer to Figure 11-215.
7. Drag-and-drop the new interface to the Assembly Diagram. This creates a

new Export to make the SCA module callable from outside. In the window that
opens, select Export with no Binding and click OK as shown in
Figure 11-217.
1100
8. Create a wire between the Export and the Mediation. Then create a wire
between the Mediation and the Outbound interface. Refer to Figure 11-218.
9. If a window opens, click OK to create needed references as shown in

Figure 11-219.
1101
Figure 11-220.
1102
3. The Mediation Flow Editor opens. Just connect the readTable operation with
the retrieveSaptable_Txn through drag-and-drop as shown in Figure 11-222.
4. Add an XSL Transformation to the flow as shown in Figure 11-223.
1103
6. In the detail properties of the XSL Transformation, click New as shown in

Figure 11-225.
1104
8. This opens the mediation editor. Open the tree structures and right-click the
Delimiter in the right tree structure. Select Define XSLT Function as shown
in Figure 11-227.
Figure 11-227 Define XSLT Function
9. In the new window select String function and click Next as shown in
Figure 11-228.
Figure 11-228 Select function
1105
10.Select string as the Function name and click Add as shown in Figure 11-229.
Figure 11-229 Select Function name
11.Enter , as the value and click OK as shown in Figure 11-230.
Figure 11-230 Enter parameter
1106
12.You see the new Input parameter and click Finish as shown in Figure 11-231.
Figure 11-231 Accept configuration
1107
13.Use drag-and-drop to map the other inputs to the targets as shown in

Figure 11-232.

15.In the detail properties of the XSL Transformation click Regenerate XSL as
1108
16.A Message window opens as shown in Figure 11-234.
17.In the Mediation Flow Editor switch to the Response configuration. Refer to
Figure 11-235.
18.Create a similar XSL Transformation for the response with the result as
Figure 11-236 Response XML transformation
1109
19.In the detail properties of the XSL Transformation, click Regenerate XSL.
20.Generate the SCA Binding as shown in Figure 11-237.
Developer is configured to Build Automatically. If not, start the Build Project.
1110
11.7.3 Deployment
page 1153.
Figure 11-239.
1111
Figure 11-240.
3. Click Finish.

test on page 1155. In the test, you do a single call to SAP to check whether a
user is known in the SAP system.
1112

1. Right-click in the assembly editor on the Export and select Test Component.
This starts the test client which is integrated in the WebSphere Integration
Developer environment.
a. Switch to the Configurations tab as shown in Figure 11-242.
1113
b. Select Emulators and click Remove as shown in Figure 11-243.
c. After all emulators are removed, go to the Events tab (Figure 11-244).
Figure 11-244 Read table set inputs
d. Enter the data provided in Table 11-6 into the test client.
Table 11-6 Test values for Read Table
1114
QueryTable
USR02
SAPOptions
MANDT EQ '800' AND BNAME EQ 'ITSOUSER'
Column
ANAME
e. Click Continue to start the test.

2. A window opens where you can select the server on which the application is
deployed. Select WebSphere ESB Server v6.0 as shown in Figure 11-245.
You see the result with values in the Test Client table with the name of the
SAP user who created the user you are looking for. Refer to Figure 11-246.
1115
3. Now go to the SAPGUI panel of the SE16 and enter USR02 as the Table name
Figure 11-247 SAP end test SE16
4. Click Table Contents or F7.

5. In the next panel enter itsouser as BNAME as shown in Figure 11-248.
Figure 11-248 SAP end test check for user
6. Click execute or F8.

You see the row in the table. It matches with the SAPData replay in the Test
Client. Refer to Figure 11-249.
Figure 11-249 SAP end test result for user
1116
11.7.5 Conclusion
access SAP data tables from an SAP ERP System. You can use this type of
interaction with SAP if special data from an SAP needs to be accessed without
using a RFC or BAPI. It is very direct and offers possibilities for direct table
manipulation.
11.8 Extension A: Dynamic authentication

The WebSphere Adapter for SAP Software supports the possibility to build up
the adapter connection with a named user. This dynamic authentication could be
used if the login to SAP require a special username in runtime and not a
technical user for all SAP connections.
Every scenario below can be extended by this feature.
To show how to use this feature, we suggest that you have a running BAPI Call
project that you can extend.

The BAPI_USER_EXISTENCE_CHECK is used to check whether a user is
1117
found in the SAP system. The advantage of this extension is that the SAP login is
performed with a user provided by the application and not with one specified
technical user stored for the WebSphere Adapter. Refer to Figure 11-250.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
Set SAP User
and Password
Adapter 6.0.1
RAR
TCP/SAPRFC
User Management
One call
ITSO.IBM.1
ITSO.SAP.1
11.8.2 Development
Creating an Interface
Creating a Java implementation
1118

1. Make sure you have an SAP OutboundInterface similar to the one created in
11.4, Scenario A: WebSphere Enterprise Service Bus executes a single
BAPI call on page 970. Refer to Figure 11-251.
Figure 11-251 Prepared Project
2. Add a new Java component to the project (Figure 11-252).
Figure 11-252 Add Java component
1119
3. Add a new Export to the project. Refer to Figure 11-253.
Figure 11-253 Add Export
Now you have three single components in your Assembly Diagram as shown
in Figure 11-254.
Figure 11-254 Created components
1120
4. Select the SAPOutboundInterface Properties Endpoint

configuration Connection Connection Spec Properties. Select
com.ibm.j2ca.sap.SAPConnectionSpec as the Connection Spec as shown
in Figure 11-255.
Figure 11-255 Config Connection Spec
1121
5. Select the SAPOutboundInterface Properties Security attributes

Authentication Properties Advanced. Select Application as the Res
Auth as shown in Figure 11-256.
Figure 11-256 Config Res Auth
1122
Creating an Interface
To create an Interface, follow these steps:
1. In the left navigator, right-click Interfaces and select New Interface to
create a new Interface as shown in Figure 11-257.
Figure 11-257 Create Interface
2. Enter WebSphereSAPDynamicAuthenticationInterface as the Name of the

Figure 11-258 Name Interface
1123
3. Use the Action bar options to add a 2-way operation with the input and output
Figure 11-259 Config Interface
4. In the next steps, connect the components in the Assembly Diagram. Every
time the question windows open in this project, you do the same actions.
Follow these steps:
a. Click OK to create a matching reference as shown in Figure 11-260.
Figure 11-260 Keep reference
b. Select No to keep the WSDL without changes. Refer to Figure 11-261.
Figure 11-261 Keep WSDL
1124
5. Wire the SAPOutboundInterface to the Java Component as shown in

Figure 11-262.
Figure 11-262 Wire SAPOutboundInterface
1125
6. Click the left button in the bubble to add a interface to the component. This
action opens a new window. Enter websphereSAP in the Filter field, select
WebSphereSAPDynamicAuthenticationInterface, and click OK as shown
in Figure 11-263.
Figure 11-263 Add interface to component
1126
7. Wire the Java Component to the Export. Now the Assembly Diagram looks as
Figure 11-264 Wired Assembly Diagram
Generating the Java implementation

To generate the Java implementation, follow these steps:
1. Right-click the Java component and select Generate Implementation as
Figure 11-265 Generate Implementation
1127
2. Select (default package) and click OK as shown in Figure 11-266.
Figure 11-266 Select Package
3. Search for the WebSphereSAPDynamicAuthenticationWrapper public Java

method in the generated code (Figure 11-267).
Figure 11-267 Generated method
1128
4. Replace the generated method with the code as shown in Example 11-1.
Important: The strings CSusername and CSpassword are predefined in the
Connection Specification.
Example 11-1 Code to fill dynamic authentication
public DataObject WebSphereSAPDynamicAuthenticationWrapper(

DataObject webSphereSAPDynamicAuthenticationInput, String username,
String password) {
//TODO Needs to be implemented.
DataObject property = webSphereSAPDynamicAuthenticationInput
.getDataObject("properties");
// is there already the child object
if (null == property) {
property = webSphereSAPDynamicAuthenticationInput
.createDataObject("properties");
}
// Setting the conn spec property 'username' which is prefixed by CS
property.setString("CSusername", username);
// Setting the conn spec property 'password' which is prefixed by CS
property.setString("CSpassword", password);
// invoke the adapter
Service serv = locateService_SAPOutboundInterfacePartner();
Object boReturn = serv.invoke("retrieveSapuser_Wrapper",
webSphereSAPDynamicAuthenticationInput);
// return the SAP result object
return (DataObject) boReturn;
}
1129
5. Click Project in the menu and check whether your WebSphere Integration
Developer is configured to Build Automatically (Figure 11-268). If not, start the
Build Project.
Figure 11-268 Build Project
1130
11.8.3 Deployment
page 1153.
Figure 11-269.
Figure 11-269 Add Project to WebSphere Enterprise Service Bus
1131
Figure 11-270.
3. Click Finish.

test on page 1155. In the test, you call SAP to check whether the user exists.
You do the call with an invalid logon user for the adapter. Then, you use a correct
user name and password.
1132
To test in a WebSphere Enterprise Service Bus environment:

1. Right-click in the assembly editor on the export and select Test Component
Figure 11-271 Test Component
1133
This action opens the Test Client as shown in Figure 11-272.
Figure 11-272 Test Client
2. Select the Configurations tab. Refer to Figure 11-273.
Figure 11-273 Test Client emulators
1134
3. Select the Emulators and then click Remove as shown in Figure 11-274.
Figure 11-274 Test Client emulators removed
4. Go to the Events tab and enter the data that is listed in Table 11-7 as the
Initial request parameters.
Table 11-7 Testcase 1
Username
itsouser
username
something
password
wrong
5. The panel looks as shown in Figure 11-275. Click Continue.
Figure 11-275 Test Client test 1
1135
6. Now, you select the server on which the application is deployed. Select
WebSphere Enterprise Service Bus Server v6.0 as shown in
Figure 11-276.
1136
The test fails because the user provided in the business graph were not
available in the SAP system. The error message that you receive states that
the login user name or password were incorrect (Figure 11-277).
Figure 11-277 Test Client test 1 result
7. Run the test again but use this data that is listed in Table 11-8 to complete the
Initial request parameters.
Table 11-8 Testcase 2
Username
itsouser
username
itsouser
password
itso1
1137
The panel looks as shown in Figure 11-278.
Figure 11-278 Test Client test 2
This time the test is successful because you used the correct user name and
password as shown in Figure 11-279.
Figure 11-279 Test Client test 2 result
1138
11.8.5 Conclusion
This scenario illustrated that the application is using the credentials that are
provided in the business graph.
access SAP with a user that is defined during runtime. If you use this type of
interaction with SAP, it needs to be performed by a special user, typically in a
Human Resource environment where the user has special permissions and work
items.

deployment and test process
The SAP integration does not change whether the components and adapters are
running on WebSphere Enterprise Service Bus or WebSphere Process Server.
However, the WebSphere Process Server offers some powerful additional
features. In this example, you completely reuse the module that you created and
call it from another module through SCA binding. The new module that you
create includes a simple business process that is used through the BPC Explorer
as a Web interface.
WebSphere Process Server and WebSphere Integration Developer,
REDP-4041.
1139

The BAPI_USER_EXISTENCE_CHECK is used to check whether a user is
found in the SAP system. Refer to Figure 11-280.
WPS 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
SCA
ITSOWPSExtension
BPC Explorer
Lib
SCA
Lib
Adapter 6.0.1
RAR
TCP/SAPRFC
User Management
One call
ITSO.IBM.1
ITSO.SAP.1
11.9.2 Development
Creating a common library
Creating a new Module as caller
Implementing the Process
1140
Creating a common library

A best practice is to put common interfaces into a shared library. In this scenario,
you move the interface UserExist from the ITSOWebSphereSAPSingleBAPI
project to the ITSOCommonLib common library. Follow these steps:
1. Open the Workspace with the module as described in 11.4, Scenario A:
WebSphere Enterprise Service Bus executes a single BAPI call on
page 970. Refer to Figure 11-281.
Figure 11-281 Start with Scenario A
1141
2. Because you deploy this module on WebSphere Process Server, you need to
create the J2C Authentication Data Entry on the WebSphere Process Server
also. Navigate to Binding Security attributes and change the J2C
Authentication Data Entry to widNode/SAPLogin as shown in Figure 11-282.
Figure 11-282 Create library
3. Create a new library to share the interface:

a. Right-click in the Navigator pane and select New Library as shown in
Figure 11-283.
Figure 11-283 Create library
1142
b. Enter ITSOCommonLib as the Library Name and click Finish as shown in

Figure 11-284.
Figure 11-284 Name library
1143
c. Use drag-and-drop to move the Interface UserExist from the

ITSOWebSphereSAPSingleBAPI to the ITSOCommonLib. Refer to
Figure 11-285.
4. Configure the Module to use the Library by double-clicking the project to open
the Dependencies editor (Figure 11-286).
Figure 11-286 ITSOWebSphereSAPSingleBAPI dependencies
1144
5. Click Add in the Libraries section as shown in Figure 11-287.
Figure 11-287 Select Library
1145
6. Select ITSOCommonLib and click OK.

7. Save the changes and the dependency is created as shown in Figure 11-288.
Figure 11-288 Dependencies
Creating a new Module as caller

To create a new Module as caller, follow these steps:
1. Create a new module for the SCA import as shown in Figure 11-289.
1146
2. Enter ITSOWPSExtension as the Module Name and click Finish as shown in

Figure 11-290.
Figure 11-290 Create new module with Name
3. Add the ITSOCommonLib to the Dependencies. Refer to Figure 11-291.
Figure 11-291 Configure dependencies
1147
4. Drag-and-drop the UserExist interface to the Assembly Diagram and select

Import with no Binding as shown in Figure 11-292.
Figure 11-292 Add new Import
5. Right-click the newly created Import1. Select Generate Binding SCA

Figure 11-293 Generate import SCA binding
1148
6. Right-click Import1 and Select Service to Import as shown in Figure 11-294.
Figure 11-294 Configure import SCA binding
7. Select Export1 provided by the ITSOWebSphereSAPSingleBAPI. Refer to

Figure 11-295.
Figure 11-295 Select service
1149
8. Add a Process to the Assembly Diagram as shown in Figure 11-296.
Figure 11-296 Add process
9. Wire the new process to the Import1 and add the UserExist interface to the
process.
Implementing the process

To implement the process, follow these steps:
1. Right-click the process Component1 and click Generate Implementation.
Select OK on the location dialog box. Refer to Figure 11-297.
Figure 11-297 Generate process implementation
1150
2. Use the default folder and click OK as shown in Figure 11-298.
3. In the process view select Invoke in the palette left and insert it with a left click
to the process between the Receive and Reply. Refer to Figure 11-299.
Figure 11-299 Add invoke to process
4. Select the Invoke and use the Set Partner option in the bubble as shown in
Figure 11-300.
Figure 11-300 Set partner
1151
5. Select UserExistPartner and click OK as shown in Figure 11-301.
Figure 11-301 Select partner
6. Navigate to Details of the Invoke as shown in Figure 11-302.
Figure 11-302 Define variables
1152
7. Set the Operation to checkExist, Username variable as Input and the

ExistResponse variable as the Output. Refer to Figure 11-303.
Figure 11-303 Variables defined
Now the modules are prepared for deployment.
11.9.3 Deployment
The steps to deploy to WebSphere Process Server are the same as those to
deploy on a WebSphere Enterprise Service Bus. To deploy to WebSphere
Process Server:
1. Start WebSphere Process Server as described in 11.3.4, Configuring J2C
authentication data on page 963. If the server is started, right-click the entry
in the Server tab and select Add and remove projects as shown in
Figure 11-304.
1153
Figure 11-305.
1154

in a WebSphere Process Server environment. Because the module has a
Human Task, the BPC Explorer is a valid option to test the modules. In the test,
you do a single call to SAP to check whether a user is known in the SAP system.
To test with BPC Explorer, follow these steps:
1. Right-click the WebSphere Process Server entry and select Launch BPC
Explorer as shown in Figure 11-306.
2. This action starts the BPC Explorer which is integrated in the WebSphere
Integration Developer environment. Refer to Figure 11-307.
1155
3. Click My Process Templates as shown in Figure 11-308.
4. Select Component1 as Process Template Name and click Start Instance as

Figure 11-309 Run test client
1156
5. Click Submit as shown in Figure 11-309.

6. Enter itsouser as the username in the Process Input Message field as shown
in Figure 11-310 and click Submit.
You see the result in the BPC Explorer.

The call was successful. So the Human Task interacts with the process. The
process connects to the SCA Import with the binding to the SCA Export of the
SAP BAPI module. The SAP BAPI module uses the JCA Adapter to call SAP and
delivers the response back to the BPC Explorer.
11.9.5 Conclusion
This scenario demonstrated how you can easily reuse a module that is designed
for WebSphere Enterprise Service Bus in a WebSphere Process Server
environment. Also, you can use the powerful additional options of a WebSphere
Process Server. You can extend every WebSphere Adapter for SAP Software
project easily. This reusable modules also allows a reuse of investment if a
company starts with a WebSphere Enterprise Service Bus environment and then
upgrades to a WebSphere Process Server license.
1157
1158
12
Chapter 12.
SAP: WebSphere Adapter
for SAP Software ALE
scenarios
This chapter begins with an overview of the implemented scenarios and
describes the common preparations for the scenarios. It also includes the
installation of the WebSphere Adapter for SAP Software and the configuration of
the SAP System, WebSphere Enterprise Service Bus, and WebSphere Process
Server. The chapter shows the possibilities of Inbound ALE, from SAP to
WebSphere. In addition, the scenarios cover single transfers as well as
acknowledgement and batch transfers.
The chapter also shows the possibilities of Outbound ALE, from WebSphere to
SAP. The scenarios cover single transfers and batch transfers.
Finally, Extension A shows the possibility to run the Service Component
Architecture modules on WebSphere Enterprise Service Bus and WebSphere
Process Server to use additional possibilities of the WebSphere Process Server.
1159
The chapter discusses the following topics:

Scenario A: WebSphere Enterprise Service Bus receives SAP IDOCs on
page 1190
Scenario B: WebSphere Enterprise Service Bus sends a single SAP IDOC
on page 1236
Scenario C: WebSphere Enterprise Service Bus sends batch SAP IDocs on
page 1258
Extension A: WebSphere Process Server deployment inbound ALE on
page 1283
Extension B: WebSphere Process Server deployment outbound ALE on
page 1302

The chapter uses different installations in the scenarios. Figure 12-1 is an
overview of all installed systems and software.
ITSO.IBM.1
ITSO.SAP.1

6.0.1.2
SAP ERP 2004

6.0.1.2
IBM DB2 8.1
WebSphere Adapter for SAP

Software 6.0.1
1160
Note: For the scenarios that we demonstrate in this chapter, authentication is

required. We use the itsouser user ID and itso1 password as examples.
However, you can replace these appropriately to suit your environment.

The SAP Application Link Enabling (ALE) interface enables business process
integration and asynchronous data communication between two or more SAP
systems or between SAP and external systems. Application systems are loosely
coupled in an ALE integrated system and the data is exchanged asynchronously.

receives SAP IDOCs
The WebSphere Enterprise Service Bus starts an RFC Server component to
receive SAP IDocs. The adapter can handle single IDoc transfers as well as
multiple IDocs on package.
12.2.2 Scenario B: WebSphere Enterprise Service Bus sends a single

SAP IDOC
The adapter supports ALE outbound event processing by working with business
objects that represent outbound IDocs. So IDocs can be transferred or generated
by a WebSphere Enterprise Service Bus process and then transferred to the
target SAP System.
12.2.3 Scenario C: WebSphere Enterprise Service Bus sends batch

SAP IDocs
objects that represent outbound IDocs. In the same way the single IDocs get
transferred the adapter can be configured to send several single IDocs in one.
Chapter 12. Adapter-based integration to SAP: WebSphere Adapter for SAP Software ALE scenarios
1161

inbound ALE
The modules of the scenarios can also be deployed into WebSphere Process
Server instead of WebSphere Enterprise Service Bus. This example extends the
mediation module of scenario ALE Inbound with an interface. An additional
module representing a business process is created. When a message including
a material IDoc from SAP arrives, the material number is passed to a business
process.
12.2.5 Extension B: WebSphere Process Server deployment

outbound ALE
This section extends the mediation module of scenario ALE Outbound with an
interface. An additional module representing a business process is created. The
business process delivers an SAP material item to be changed and calls the
mediation module, that is sending an IDoc to SAP.
12.3 Preparation
In the scenarios, SAP is accessed through the WebSphere Adapter for SAP
Software. There are common preparation steps for all scenarios. The following
steps needs to be configured in the SAP system (refer to your SAP
administrator):
1.
2.
3.
4.
5.
RFC destination
Receiver port
Logical system
Distribution model
Partner profile
WebSphere Adapter for SAP Software needs to be installed into the

development environment.
A J2C Authentication Data Entry needs to be created in the runtime environment.
This book does not explain how to install WebSphere Enterprise Service Bus,
WebSphere Process Server, and WebSphere Integration Developer. Check the
product documentation for installation instructions.
1162
12.3.1 SAP RFC destination

A logical Program ID is defined. WebSphere Adapter for SAP Software registers
to SAP as a server using this Program ID.
To create a new RFC destination, follow these steps:
1. In the SAP GUI open the transaction SM59 (Display and Maintain RFC
Destinations) and click Create as shown in Figure 12-2.
Figure 12-2 SM59 Display and Maintain RFC Destinations
1163
2. In the RFC Destination dialog box, specify a new name (ITSO_DEST) and the
Connection Type T for TCP/IP Connection. Select Destination Save (or
Ctrl+S) to save. Now, you can specify the following additional settings:
a. Enter an optional description.
b. Select Registered Server Program as Activation Type.
c. Enter a Program ID (ITSO_SERVER). This Program ID has to be
configured later in the activation spec of the WebSphere Adapter for SAP.
Select Destination Save (or Ctrl+S) to save. Refer to Figure 12-3.
Figure 12-3 Create RFC destination
1164
12.3.2 SAP tRFC port in IDoc processing

To create a new tRFC port, follow these steps:
1. In the SAP GUI open the transaction WE21 (Ports in IDoc processing).
2. In the ports list , select Transactional RFC and click Port Create. Refer to
Figure 12-4.
Figure 12-4 WE21 Ports in IDoc processing
3. Enter a port name and select the button with the check mark on it. Refer to
Figure 12-5.
Figure 12-5 Enter port name
1165
4. Enter an optional description and the RFC Destination, created in the

previous step (ITSO_DEST). Select the Save icon (or Ctrl+S) to save. Refer
to Figure 12-6.
Figure 12-6 Create tRFC port
1166
12.3.3 SAP Logical System

Each system in the distributed environment, SAP or non SAP, must have a
unique logical system name for communication.
To create a new Logical System, follow these steps:
1. In the SAP GUI open the transaction BD54 (Change View Logical Systems:
Overview) and click New Entries as shown in Figure 12-7.
Figure 12-7 BD54 Logical Systems
1167
2. Enter a new Logical System (ITSO_LSYS) and a description and click the Save
icon (or Ctrl+S). Refer to Figure 12-8.
Figure 12-8 New Logical System
3. In most SAP systems a Prompt for Workbench request is configured. Create

a new request by clicking the New request icon (or F8). Refer to Figure 12-9.
Figure 12-9 Prompt for Workbench request
1168
4. Enter a short description and click the Save icon (or Enter). Refer to
Figure 12-10.
Figure 12-10 Create Workbench request
5. The Workbench request is created and the number is set inside the dialog
box. Click the icon with the check mark on it (or Enter). Refer to Figure 12-11.
Figure 12-11 Prompt for Workbench request
12.3.4 SAP Distribution Model

In a Distribution Model, you define two message types with a sender and
receiver. For the ALE inbound scenario, the sender is the logical system name of
the SAP client and the receiver is the logical system name of the WebSphere
System (ITSO_LSYS). For the ALE outbound scenario exchange the logical
systems of sender and receiver.
1169
To create a new Distribution Model, follow these steps:

1. In the SAP GUI open the transaction BD64 (Maintenance of Distribution
Model).
2. Click Distribution Model Switch processing model (F9) to switch into
the edit mode. Refer to Figure 12-12.
Figure 12-12 BD64 Maintenance of Distribution Model
3. Click Create model view. In the dialog box, enter Short text and a name of
the model view (ITSO_MODEL). Click the Continue icon. Refer to Figure 12-13.
Figure 12-13 Create Distribution Model
1170
4. Select the new distribution model and click Add message type. Refer to
Figure 12-14.
Figure 12-14 Distribution Model list
5. Enter the logical system name of the WebSphere system (ITSO_LSYS) as

Sender and the logical system name of the SAP client (in our case
BSCCLNT800) as Receiver. Enter Message Type as MATMAS. Click the Continue
icon. Refer to Figure 12-15.
Figure 12-15 Message Type WebSphere to SAP
6. Select the new distribution model and click Add message type again.
7. Enter the logical system name of the SAP client (in our case BSCCLNT800) as
Sender and the logical system name of the WebSphere system (ITSO_LSYS)
as Receiver. Enter Message Type as MATMAS. Click the Continue icon. Refer
to Figure 12-16.
Figure 12-16 Message type SAP to WebSphere
1171
8. Click the Save icon (or CTRL+S). Refer to Figure 12-17.
Figure 12-17 Distribution Model with additional entry
12.3.5 SAP Partner profile

To create a new partner profile, follow these steps:
1. In the SAP GUI open the transaction WE20 (Partner profiles).
2. Select the Create icon (or F5).
3. Enter the logical system (ITSO_LSYS) and the Partner Type LS.
1172
4. In the Post processing: permitted agent, enter US for User, and specify your
SAP user ID. Refer to Figure 12-18.
5. Click the Save icon (or Ctrl+S).
Figure 12-18 WE20 Partner profiles
6. In Outbound parmtrs, click Create outbound parameter icon. The Outbound

parameters dialog box opens.
1173
7. Enter Message Type as MATMAS, Receiver port as ITSO_PORT, and Basic type
as MATMAS05. Select Transfer IDoc immed as shown in Figure 12-19.
8. Click the Save icon (or Ctrl+S).
Figure 12-19 Partner profile outbound parameters
9. Click F3 to return to the partner profiles view.

10.In the Inbound parameters section, click the Create inbound parameter
icon. The Inbound parameters dialog box opens.
11.Enter MessageType as MATMAS. Enter Process Code as MATM.
1174
12.Click the Save icon (or Ctrl+S). Refer to Figure 12-20.
Figure 12-20 Partner profile inbound parameters MATMAS
13.Click F3 to return to the partner profiles view.

14.In the Inbound Parameters section, click Create inbound parameter icon
again. The Inbound parameters dialog box opens.
1175
15.Enter MessageType as ALEAUD. Enter Process code as AUD1. Refer to

Figure 12-21.
16.Click the Save icon (or Ctrl+S).
Figure 12-21 Partner profile inbound parameters ALEAUD
1176
17.Click F3 to return to the partner profiles view. Refer to Figure 12-22.
Figure 12-22 Partner profile completed
18.Click the Save icon (or Ctrl+S).
1177
12.3.6 Installing SAP JCo

In the Windows environment, follow these steps:
1. Copy sapjco.jar into the WebSphere Integration developer directory
\runtimes\bi_v6\lib\ext.
2. Copy librfc32.dll and sapjcorfc.dll into the WebSphere Integration developer
directories \runtimes\bi_v6\java\bin and \eclipse\jre\bin#.
3. Install the Microsoft files msvcp71.dll and msvcr71.dll files in the Windows
system path. See SAP Note 684106 on the SAP Service Marketplace Web
site (www.service.sap.com) for additional details. The DLL files are contained
in the attachments section of the SAP Note along with instructions on how to
install them. You must have a valid user name and password for the SAP
Service Marketplace to view the SAP Note.
For platforms other than Windows, refer to SAP JCo installation documentation.
12.3.7 Installing WebSphere Adapter for SAP Software

This section describes how to install WebSphere Adapter for SAP Software into
the System.
Installing into a development environment

Note: Make sure that you have the WebSphere Adapter for SAP 6 Package
for Windows as well as the latest Fixpack available.
Follow these steps:
1. Use the launchpad_win.exe in the extracted 6.0.0 directory.
Figure 12-23 JCA Adapter installation; Choose Launchpad language
1178
3. Click Install Product. Refer to Figure 12-24.
Figure 12-24 JCA Adapter installation; Start installation process
1179
4. You see the Welcome panel as shown in Figure 12-25.
Figure 12-25 JCA Adapter installation; installation welcome
5. Read and accept the software license agreement and click Next as shown in
Figure 12-26.
Figure 12-26 JCA Adapter installation; installation license
1180
6. Click Browse to select C:\websphere\SAPAdapter as the installation path

Figure 12-27 JCA Adapter installation; installation path
7. You see the summary. Click Next as shown in Figure 12-28.
Figure 12-28 JCA Adapter installation; installation summary
8. You get a successfully installed notice. Click Finish as shown in Figure 12-29.
1181
Figure 12-29 JCA Adapter installation; installation success
Important: Apply the latest fix pack as explained in the product

documentation.
After setting up the WebSphere Adapter for SAP Software, you find two different
adapter resource files in the target directory.
/adapter/SAP/deploy/CWYAP_SAPAdapter.rar
Use this file if you want the adapter to perform ALE and BAPI processing
without local transaction support. In this case, the application provides the
local transaction support.
/adapter/SAP/deploy/CWYAP_SAPAdapter_Tx.rar
Use this file if you want the container (WebSphere Process Server) to control
local transaction support for BAPI processing. In this case, the adapter
participates in the local transaction started by the container.
12.3.8 Deploying WebSphere Adapter for SAP Software

To deploy WebSphere Adapter for SAP Software, follow these steps:
1. Open WebSphere Integration Developer.
2. Change to J2EE perspective. Select Window Open Perspective Other
and choose J2EE in the dialog box. Refer to Figure 12-30.
1182
Figure 12-30 Select J2EE Perspective
3. Inside Project Explorer, right-click Connector Projects and select

Import RAR file. Refer to Figure 12-31.
Figure 12-31 Import connector RAR file
1183
4. Click Browse next to the Connector file and open CWYAP.SAPAdapter.rar

(located in \adapter\SAP\deploy directory within the directory where the
adapter is installed).
5. Select WebSphere ESB Server v6.0 as Target Server, and clear the Add
module to an EAR project field.
6. Click Finish. Refer to Figure 12-32.
Figure 12-32 Connector RAR file import properties
7. Inside the Project Explorer, right-click the new project CWYAP_SAPAdapter

and select Properties from the context menu.
1184
8. Select Java Build Path property. Refer to Figure 12-33.

a. Select the Libraries tab.
b. Click Add External JARs.
c. In the file dialog box, open the sapjco.jar file (in
\WID\runtimes\bi_v6\lib\ext directory).
d. Click OK.
Figure 12-33 Change SAP adapter properties
12.3.9 Configuring J2C authentication data

It is recommended that you store the SAP credentials in the J2C Authentication
alias. Otherwise, the password is visible in the configuration files. Follow these
steps:
1. Start WebSphere ESB Server v6.0 in the Server view. If the Server view is not
visible, select Window Show View Servers.
1185
2. Select the ESB Server v6.0 and click the Start icon or select Start in the
pop-up menu. Wait until the server status changes to Started. Refer to
Figure 12-34.
Figure 12-34 Start server
3. Right-click the started server and select Run administrative console as

Figure 12-35 Run administrative console
1186
4. On the administrative console login panel, insert any user ID.

5. On the left side, click Security Global Security. Refer to Figure 12-36.
6. On the right side, click JAAS configuration J2C Authentication data.
Figure 12-36 Administrative console
1187
7. In the J2C authentication data view, click New as shown in Figure 12-37.
Figure 12-37 J2C authentication data
1188
8. In the General Properties dialog box, enter an Alias name (SAPLogin). Refer
to Figure 12-38.
9. Enter the SAP user ID and password. Click Ok.
10.A new Entry esbNode/SAPLogin is in the list.
Figure 12-38 J2C authentication data - general properties
11.Click OK in the Global Security view. In the Save dialog box, click Save.
Figure 12-39 Save dialog box
1189
12.Click Save to confirm saving the changes to the master configuration as

Figure 12-40 Master configuration save dialog box
13.Repeat these steps to configure the WebSphere Process Server V6.0.

The names to reference in the applications are:
esbNode/SAPLogin in ESB Server
widNode/SAPLogin in WebSphere Process Server

receives SAP IDOCs
For ALE inbound event processing, the adapter acts as a Remote Function Call
(RFC) Server by listening for ALE events from an SAP system. The adapter
spawns listener threads to the SAP system. Whenever an event occurs in SAP,
the event is pushed to the adapter through the event listeners.
An inbound event can include multiple IDocs, with each IDoc corresponding to a
single business object. The multiple IDocs are pushed out by the SAP system to
the adapter in the form of an IDoc packet.
You can configure the adapter to update the IDoc status for the purpose of
monitoring your IDoc processing. If the adapter configuration property
ALEUpdateStatus is set to true (indicating that an audit trail is required for all
message types), then the adapter updates the IDoc status of ALE business
objects that are retrieved from the SAP system. The update is accomplished by
updating a status IDoc called ALEAUD that the adapter sends to the SAP system
1190
as an inbound IDoc event. After the event is sent to the message endpoint, the
adapter updates the status of the IDoc in SAP to indicate a failure or success in
processing.

Scenario A uses the WebSphere Business Integration Adapter for mySAP.com
to retrieve IDoc sent by an SAP system. Refer to Figure 12-41 for the operational
model.
SAP ERP 2004
WESB 6.0.1.2 (WAS 6.0.2.9)

Cloudscape
Eventtable
bd10
WID 6.0.1.2
Testclient
SCA
ITSOSAPWebSphereALEInbound
ALE
Adapter 6.0.1
RAR
TCP/SAPRFC
MATMAS05
ITSO.SAP.1
ITSO.IBM.1
Figure 12-41 Operational model inbound ALE
1191
12.4.2 Development
This section describes how to create a WebSphere Enterprise Service Bus
mediation module that includes the transformation logic to map the SAP interface
into a simplified interface of a Java component. It uses the WebSphere Adapter
for SAP software to receive an SAP IDOC from the backend and send this
document through a Mediation node to a Java component.
Creating a Mediation module

To create a Mediation module, follow these steps:
1. In WebSphere Integration Developer, switch to the Business Integration
perspective.
2. Create a new mediation project. In the Business Integration view, right-click
and select New Mediation Module from the pop-up menu. Refer to
Figure 12-42.
Figure 12-42 Create Mediation Module
1192
3. In the New Mediation Module dialog box, specify Module Name, select
WebSphere ESB Server as Target Runtime and select Create mediation
flow component. Then, select Finish as shown in Figure 12-43.
Figure 12-43 Mediation Module dialog box
1193
Creating an EIS export

To create an EIS export, follow these steps:
1. Right-click the new mediation project in the Business Integration view and
select New Enterprise Service Discovery from the pop-up menu. If
Enterprise Service Discovery is not visible, select Other from the bottom of
the pop-up menu. Refer to Figure 12-44.
Figure 12-44 Enterprise Service Discovery
1194
2. In the Select a wizard dialog box, expand the Business Integration folder,
select Enterprise Service Discovery and click Next as shown in
Figure 12-45.
Figure 12-45 Select a wizard
1195
IBM WebSphere Adapter for SAP Software and click Next as shown in
Figure 12-46. If you have run the enterprise service discovery wizard
previously, your connection properties have been saved and appear when you
expand the adapter name node (click the plus symbol, +, next to the adapter
name). You can select the saved connection properties if you plan to connect
to the same SAP application as when you last ran the enterprise service
discovery wizard.
Figure 12-46 Select Adapter dialog box
1196
4. When prompted to specify properties in the Configure Settings for Discovery

Agent window, specify the adapter configuration properties for connecting to
SAP. Properties marked with an asterisk (*) are mandatory. Be sure to set the
Select the Module property (under Metadata Properties) to the value ALE as
Figure 12-47 Discovery Agent settings
5. Click Next.
6. In the Find and Discover Enterprise Services window, click Run Query.
1197
7. Under Objects Discovered by query, drill down to the Discover By Name node
and select it as shown in Figure 12-48, but do not drill down further, because
you need to apply a filter.
Figure 12-48 Discovery Agent query
8. Click Filter. In the Filter Properties for Discover by Name window, enter the
name of the IDoc that you want to discover. You can include an asterisk (*) as
a wild card character at the beginning or end of the name to indicate that you
want to discover all SAP application components that include the specified
name. In this example scenario, enter MATMAS*. Refer to Figure 12-49.
9. Click OK.
Figure 12-49 Discovery Agent filter
1198
10.Expand Discover By Name. The filtered list of IDocs are retrieved from the
SAP system as shown in Figure 12-50.
11.Select MATMAS05 and click Add.
Figure 12-50 Discovery Agent - retrieved IDocs
1199
12.In the Configuration Parameters window, select Use SAP Field Name to
generate attribute(s). Click OK as shown in Figure 12-51.
Figure 12-51 MATMAS05 configuration parameters
If there is the requirement to include multiple IDocs, repeat the previous two
steps.
13.When added the IDocs into the Objects to be imported list, select Finish.
14.The Configure Objects dialog box opens, enter a object location, click Add,
select the operation Create, and click OK. Click Next as shown in
Figure 12-52.
Figure 12-52 Discovery Agent - configure objects
15.The Generate Artifacts dialog box opens. Optionally, you can specify a folder
where the SAPInboundInterface artifacts are created.
1200
16.Be sure that the Deploy connector with module and Use discovered
connection properties option is selected.
Note: Deployment of the WebSphere Adapter for SAP Software direct as a
resource adapter on the server and use of the connection properties
specified on the server are not supported in the current release of the
adapter.
Specify the J2C Authentication Entry, configured in the prerequisite task.
Attention: Do not fill the username and password fields directly in this
panel. Otherwise, the password is stored in clear in a configuration file.
For security reasons, always use the J2C Authentication Data Entry
instead field instead.
1201
Figure 12-53 Discovery Agent - generate artifacts
1202
18.It is possible to update the status of the SAP system, when the IDoc arrives.
The Adapter sends out an IDoc of type ALEAUD to the SAP system. To
enable this, select AleUpdateStatus and specify the values for
AleSuccesscode, AleFailureCode, AleSuccessText, and AleFailureText.
Figure 12-54 Discovery Agent - generate artifacts continued
1203
20.Set the SAP IDoc message type in the generated business object
SapMatmas05:
a. In the Business Integration view, open the Data Types directory, right-click
the business object SapMatmas05, and select open. Refer to
Figure 12-55.
b. The Business object view opens. Select the SapMatmas05 object and
select Application Info in the Properties pane.
Figure 12-55 MATMAS05 - Set IDoc message type
21.Navigate to sapasi:MsgType and enter the value MATMAS. Save and close the
business object.
Important: Take care to distinguish between the Message Type
(MATMAS) and the Basic Type (MATMAS05).
1204
Creating a simplified interface

At this point, the SAPInboundInterface is ready. In the next steps, you build a
transform it to another interface and pass one data element to a Java module.
Follow these steps:
1. Open the Assembly Editor. The SAPInboundInterface that you generated in
the previous steps and an empty mediation module are shown in
Figure 12-56.
Figure 12-56 Open Assembly Editor
1205
2. Create a new Interface with one operation having a string as input parameter.
Right-click interfaces and select New Interface as shown in Figure 12-57.
3. In the Create a new interface dialog box, specify a directory name, where the
artifacts are created (sapif) and the interface name (ITSOMaterial). Click
Finish as shown in Figure 12-58.
Figure 12-58 New interface parameter
1206
4. The interface view opens. You can specify the operations and parameters.
Click Add One Way Operation as shown in Figure 12-59.
Figure 12-59 Specify interface operations
5. Select the new operation and click Add Input as shown in Figure 12-60.
Name the input parameter material. Save and close the interface view.
Figure 12-60 Specify interface input parameter
1207
Creating a Java component and wire nodes

To create a Java component and wire nodes, follow these steps:
1. In the Assembly diagram, click the Java icon and then click into the assembly
diagram to create a new Java component as shown in Figure 12-61.
Figure 12-61 Add Java component
2. Select the new Java component and click Add Interface as shown in
Figure 12-62.
Figure 12-62 Add interface
1208
3. In the Add Interface dialog box, select ITSOMaterial and click OK as shown
in Figure 12-63.
Figure 12-63 Add interface dialog box
1209
4. Wire the right side of the Mediation1 component to the left side of the Java
component as shown in Figure 12-64.
Figure 12-64 Wire components
5. There is currently no reference interface defined in the mediation module.

During wiring, it is automatically created using the ITSOMaterial interface of
the Java component. When the confirmation dialog box displays, click OK
(Figure 12-65).
Figure 12-65 Add wire confirmation
1210
6. At this stage, the interfaces are defined and wired together. In the next steps,
you implement the Java component and generate the mediation component.
In the Assembly Diagram, select the Java component and then right-click and
select Generate Implementation as shown in Figure 12-66.
7. In the Generate implementation dialog box, accept the defaults and click OK.
1211
8. The generated Java file with the implementation of the Java component
opens. You have to change the operation method for the needs of the sample
scenario. This operation prints the material number to the output console. To
change the operation method, scroll down to the method public void
operation1 (String material).
9. Insert System.out.println(material); and save the file. Refer to
Figure 12-67.
Figure 12-67 Java component implementation
Generating a mediation implementation

To generate a mediation implementation, follow these steps:
1. In the Assembly Diagram, select the Mediation component and then
right-click and select Generate Implementation.
2. In the Generate implementation dialog box, accept the defaults and click OK.
1212
3. The mediation flow editor opens to configure a mediation. In this scenario,

you create an XSL mediation to extract the SAP material number out of the
incoming material data. In the Operation connections panel, wire
emitCreateAfterImageSapMatmas05 to operation1 as shown in Figure 12-68.
Figure 12-68 Mediation flow editor
1213
4. In the lower part of the mediation editor, select the mediation primitive: XSL
Transformation. Click into the white space of the lower pane to create the
mediation primitive. Wire the Request - emitCreateAfterImageSapMatmas05
to the XSL Transformation and the XSL Transformation to Invoke - operation1
Figure 12-69 Mediation flow - insert XSL transformation
1214
5. Select the XSL Transformation. In the Properties view, select Details as

Figure 12-70 XSL transformation properties
6. You need a new mapping file to mediate the input interface to the output
interface. Click New.
1215
7. In the dialog box that opens, accept the defaults as shown in Figure 12-71
and click Finish.
Figure 12-71 XSLT mapping -- Message type dialog box
1216
8. In the XSLT mapping view, open the source message and navigate to the
material number as shown in Figure 12-72. Drag the element MatNr on the
element material inside the target message. The result is visible in the
overview pane. Save and close the XSLT mapping file.
Figure 12-72 XSLT mapping editor
1217
9. Click Regenerate XSL as shown in Figure 12-73 to synchronize the

associated XSL with the mapping file.
Figure 12-73 Regenerate XSL
10.Save and close the mediation flow editor.

11.Save the Assembly Diagram.
1218
12.4.3 Deployment
You can deploy the module on the WebSphere ESB Server or the WebSphere
Process Server. This scenario uses WebSphere ESB Server. To deploy the
module, follow these steps:
1. Start the WebSphere ESB Server. Refer to Figure 12-74.
Figure 12-74 Start Enterprise Services Bus
2. Rebuild your project to make sure, all artifacts are generated. Select
Project Clean in the menu bar as shown in Figure 12-75. In the
confirmation select your project or rebuild all projects.
Figure 12-75 Clean project
1219
3. Add the project to the server. In the server view, right-click WebSphere ESB
Server and select Add and remove projects as shown in Figure 12-76.
4. In the Add and Remove Projects dialog box, select the

ITSOSAPWebSphereALEInboundApp project and click Add as shown in
Figure 12-77 Add and remove projects dialog box
The application starts and the SAP adapter listeners which listen for SAP
inbound events start also.
1220
12.4.4 Execution and Test: ALE Inbound - Single IDoc

in a WebSphere Enterprise Service Bus environment. We discuss the same
test on page 1155. In the test, you send an IDoc using SAP GUI to the
WebSphere Adapter. This test initiates the deployed project that you created in
this scenario. Follow these steps:
1. In the Business Integration view, right-click the project and select Test
Attach as shown in Figure 12-78.
Figure 12-78 Start attached test
1221
2. In the Events view of the Attached test, click Continue as shown in

Figure 12-79.
Figure 12-79 Attached test - event view
3. Select WebSphere ESB Server v6.0 in the Deployment location dialog box
as shown in Figure 12-80 and click Finish.
Figure 12-80 Deployment location
1222
4. The test client is listening for events.

5. In the SAP GUI, open the transaction BD10 (Send Material).
6. Insert a material number (1500-710) and a logical system (ITSO_LSYS) and
click the Execute icon. Click OK on the information dialog boxes. Refer to
Figure 12-81.
Figure 12-81 BD10 Send material
Inside the attached test event view, new events are generated.
1223
7. Click the request messages to examine the business objects passed between
the components of the module. The SAPInboundInterface delivers the SAP
material data structure, while the Mediation1 component delivers the SAP
material number to be passed to the Java component. The SAP material
number is printed to SystemOut. Refer to Figure 12-82.
Figure 12-82 Test client incoming events
1224
12.4.5 Execution and test: ALE inbound with acknowledgement

To process SAP IDocs with an acknowledgement, you must set the
AleUpdateStatus flag when you configure the adapter (see Figure 12-54 on
page 1203). Then, the WebSphere Adapter for SAP Software returns an SAP
IDoc message of type ALEAUD that includes the status of the message
processing. Follow these steps:
1. In the Business Integration view right-click the project and select Test
1225

Figure 12-84.
3. Select WebSphere ESB Server in the Deployment location dialog box and
click Finish as shown in Figure 12-85.
4. The test client is listening for events. In the SAP GUI open the transaction
BD10 (Send Material). Insert a material number (1500-710) and a logical
1226
system (ITSO_LSYS) and click the Execute icon. Refer to Figure 12-86. Click
OK on the information dialog boxes that display.
Inside the Attached test Events view, new events are generated.
5. Click the request messages to examine the business objects passed between
number is printed to SystemOut. Refer to Figure 12-87.
1227
6. In the SAP GUI, open the transaction WE02 (IDoc list).

7. In the IDocs List view, you can apply a filter for the IDocs. Click the Execute
icon. The list of sent and received IDocs are displayed.
After the message MATMAS05 is sent to WebSphere, a ALEAUD
acknowledgement message for status update is received by SAP. Refer to
Figure 12-88.
Figure 12-88 WE02 IDoc list
1228
12.4.6 Execution and test: ALE inbound - batch IDocs

You can configure SAP to collect IDocs and send IDocs out as batch in one
message with all the IDocs included. WebSphere Adapter for SAP Software
processes each IDoc in sequence, triggering the connected endpoint, which in
our scenario is the mediation component.
To test Batch ALE Inbound, follow these steps:
1. In the Business Integration view right-click the project and select Test
1229

Figure 12-90.
3. Select WebSphere ESB Server v6.0 in the Deployment location dialog box
and click Finish as shown in Figure 12-91.
1230
4. The test client is listening for events. In the SAP GUI, open the transaction
WE20 (PartnerProfiles). Select ITSO_LSYS under Partner Profiles
Partner Type LS (Logical System). Refer to Figure 12-92.
Figure 12-92 WE20 Partner profiles
1231
5. In the Outbound parameter section, open the parameter MATMAS.

6. Select Collect IDocs as Output Mode as shown in Figure 12-93 and save the
Outbound parameter.
Figure 12-93 Output mode Collect IDocs
1232
7. Open the transaction BD10 (Send Material). Insert a material number

(1500-710) and a logical system (ITSO_LSYS) and click the Execute icon.
Refer to Figure 12-94 and click OK on the information dialog boxes.
8. Repeat the previous step with two additional material numbers (1500-720 and
1500-700).
1233
9. Open the transaction WE14 (Process all selected IDocs). Enter MATMAS05 as
Basic type to limit the IDocs to be processed. Refer to Figure 12-95. Click the
Execute icon. All collected IDocs of type MATMAS05 are sent out in one
message.
Figure 12-95 Process all selected IDocs
1234
10.Inside the Attached test Events view, new events are generated. Refer to
Figure 12-96.
11.Click the request messages to examine the business objects passed between
numbers are printed to SystemOut. The various IDocs are processed in
sequence.
12.4.7 Conclusion
start listeners to listen on IDoc messages that are sent by the SAP system. This
type of interaction with SAP is very powerful and can receive single IDocs and
packages with a set of IDocs (batch). It is often used for system replications or
system-to-system transfers. The adapter offers additional support to send an
acknowledgement IDoc to SAP.
1235

sends a single SAP IDOC
objects that represent outbound IDocs.
The following steps describe how the adapter supports outbound processing for
the ALE interface.
The adapter uses an IDoc business object to populate the appropriate
RFC-enabled function call used by the ALE interface.
The adapter establishes a RFC connection to the ALE interface and pass the
IDoc data to the SAP system.
After passing the data to SAP, the adapter releases the connection to SAP.
Because the ALE interface is asynchronous, SAP returns a return code only
and a null object to the caller. When no exceptions are raised, the outbound
transaction is considered successful. The success of the data being
incorporated into the SAP application can be verified by inspecting the IDocs
that have been generated in SAP.
Note: The adapter does not provide J2C local transaction support because
this feature is not provided in a generic manner by the SAP back-end
system.
1236

Scenario B uses the WebSphere Business Integration Adapter for mySAP.com to
send IDoc to the target SAP system. Refer to Figure 12-97 for the operational
model.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
ITSOWebSphereSAPALEOutbound
Adapter 6.0.1
RAR
TCP/SAPRFC
ITSO.IBM.1
ALE
MATMAS05
( ALEAUD )
ITSO.SAP.1
Figure 12-97 Operational model outbound ALE
1237
12.5.2 Development
This section explains how to develop the SCA component. Follow these steps:
perspective.
and select New Mediation Module as shown in Figure 12-98.
1238
3. In the New Mediation Module dialog box, specify the Module Name, select
WebSphere ESB Server v6.0 as Target Runtime, and select Create
mediation flow component as shown in Figure 12-99. Click Finish.
select New Enterprise Service Discovery. If Enterprise Service
Discovery is not visible, select Other as shown in Figure 12-100.
1239
5. In the Select a wizard dialog box, expand the Business Integration folder and
Figure 12-101.
1240
expand the adapter name node (click the plus sign, +, next to the adapter
discovery wizard.
1241

Select Module property (under Metadata Properties) to the value ALE as
8. Click Next.
1242
10.Under Objects discovered by query, drill down to the Discover By Name

node and select it, but do not drill down further, because a filter must be
applied before. Refer to Figure 12-104.
11.Click Filter. In the Filter Properties for Discover By Name window, enter the
want to discover all SAP application components that contain the specified
12.Click OK.
1243
13.Expand Discover By Name (filtered). The filtered list of IDocs are retrieved
from the SAP system. Refer to Figure 12-106.
1244
15.In the Configuration Parameters window, select Use SAP Field Name to
generate attribute(s) as shown in Figure 12-107. Click OK.
steps.
17.The Configure Objects dialog box opens, enter a Object Location (Enter
relative Path), click Add, select Operations Execute and click OK. Then,
click Next. Refer to Figure 12-108.
where the SAPOutboundInterface artifacts are created.
1245
connection properties options are selected. Refer to Figure 12-109.
specified on the server, are not supported in the current release of the
adapter.
1246
1247
20.Specify the J2C Authentication Entry that you configured in a prerequisite

task.
.
panel. Otherwise the password is stored in clear in a configuration file. For
security reasons, always use the J2C Authentication Data Entry field
instead.
23.Open the Assembly Editor. The SAPInboundInterface that you generated in
the previous steps and an empty mediation module display.
At this point, the SAP Outbound interface is ready to be used in the further
development of the mediation module. In the next stage, you test the SAP
Outbound interface with the integrated test client.
12.5.3 Deployment
Process Server. In this scenario, you use WebSphere ESB Server. To deploy the
module, follow these steps:
1248
2. Rebuild your project to make sure that all artifacts are generated. Select
Project Clean in the menu bar as shown in Figure 12-111. In the
confirmation, select your project or rebuild all projects.
1249
4. In the Add and remove projects dialog box, select the

ITSOSAPWebSphereALEInboundApp project and click Add. Click Finish as
1250

In the test scenario, you update a material item in SAP. First, you prepare an
IDoc message with the mandatory sections and properties. Then, you specify a
changed property, in this case the old material number property (Bismt). Follow
these steps:
1. In the assembly editor right-click SAPOutboundInterface and select Test
Component as shown in Figure 12-114.
The integrated test client starts.
1251
2. In the Initial Parameters section, navigate to the SapIDocControlRecord and

complete the initial request parameter (Figure 12-115). Table 12-1 shows the
required parameters of the SapIDocControlRecord.
Table 12-1 SapIDocControlRecord
Parameter
Value
Comment
ReceiverPort
SAPxxx
port name of the SAP system
PartnerTypeOfSender
LS
NameOfBasicType
MATMAS05
PartnerNumberOfSender
ITSO_LSYS
NameOfTableStructure
EDI_DC40
Client
800
Logical MessageType
MATMAS
PartnerNumberOfRecipient
xxxCLNTxxx
PartnerTypeOfRicipient
LS
The logical name defined for the

WebSphere Adapter
Logical name of the SAP system
Figure 12-115 Initial request parameters SapIDocControlRecord
1252
3. Navigate to SapMatmas05E2maram005. This is a mandatory section.

Right-click and select Add Element as shown in Figure 12-116.
Figure 12-116 Initial request parameters add SapMatmas05E2maram005
1253
4. Table 12-2 shows the required parameters of the

SapMatmas05E2maram005. Refer to Figure 12-117.
Table 12-2 SapMatmas05E2maram005
Parameter
Value
Comment
Msgfn
004
Change
MatNr
1500-700
Material to change
Matkl
01002
Material class
Bismt
P-xyz-700
The property holding the old material

number (coming from an existing
system). This is the value actually
changed.
Meins
CSE
Unit of measurement
Figure 12-117 Initial request parameters SapMatmas05E2maram005
1254
5. Navigate to SapMatmas05E2maktm005. This is also a mandatory section.

Figure 12-118 Initial request parameters SapMatmas05E2maktm005
1255
6. Click Continue to send the IDoc to SAP. Refer to Figure 12-119.
Figure 12-119 IDoc sent
1256
7. In the SAP GUI open the transaction WE02 (IDoc List). You can select the
received IDoc. Refer to Figure 12-120.
Figure 12-120 WE02, SAP IDoc list
12.5.5 Conclusion
transfer IDoc messages to the SAP system. This kind of interaction with SAP is
very powerful and can send single IDocs. It is often used for system replications
or system-to-system transfers.
1257

sends batch SAP IDocs
objects that represent outbound IDocs. The following steps describe how the
adapter supports outbound processing for the ALE interface.
The adapter uses an IDoc business object to populate the appropriate
RFC-enabled function call used by the ALE interface.
The adapter establishes a RFC connection to the ALE interface and pass the
IDoc data to the SAP system.
After passing the data to SAP, the adapter releases the connection to SAP.
generated in SAP.

Refer to Figure 12-121 for the operational model for this scenario.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
Adapter 6.0.1
RAR
TCP/SAPRFC
ITSO.IBM.1
Figure 12-121 Operational model outbound ALE batch
1258
ALE
MATMAS05
( ALEAUD )
ITSO.SAP.1
12.6.2 Development
perspective.
and select New Mediation Module as shown in Figure 12-122.
1259
3. In the New Mediation Module dialog box, specify Module Name, select
WebSphere ESB Server v6.0 as Target Runtime and select Create
mediation flow component as shown in Figure 12-123. Click Finish.
select New Enterprise Service Discovery. If Enterprise Service
Discovery is not visible, select Other as shown in Figure 12-124.
1260
5. In the Select a wizard dialog box, expand the Business Integration folder and
Figure 12-125.
1261
expand the adapter name node (click the plus sign, +, next to the adapter
discovery wizard.
1262

Select the Module property (under Metadata Properties) to the value ALE as
8. Click Next.
1263
10.Under Objects discovered by query, drill down to the Discover By Name

node and select it, but do not drill down further, because you need to apply a
filter. Refer to Figure 12-128.
11.Click Filter. In the Filter Properties for Discover by Name window, enter the
want to discover all SAP application components that include the specified
12.Click OK.
1264
13.Expand Discover By Name (filtered). The filtered list of IDocs are retrieved
from the SAP system. Refer to Figure 12-130.
1265
15.In the Configuration Parameters window, select Create ALE Wrapper and
Use SAP Field Name to generate attribute(s). Click OK. Refer to
Figure 12-131.
steps.
17.The Configure Objects dialog box opens, enter an Object Location, click Add,
select Operations Execute, and click OK. Click Next. Refer to
Figure 12-132.
1266
where the SAPOutboundInterface artifacts are created.
connection properties fields are selected.
specified on the server, are not supported in the current release of the
adapter.
20.Specify the J2C Authentication Entry that you configured in a prerequisite
task.
.
panel. Otherwise the password is stored in clear in a configuration file. For
security reasons, always use the J2C Authentication Data Entry field
instead.
21.Specify the SAP connection properties Refer to Figure 12-133.
1267
23.Open the Assembly Editor. The SAPInboundInterface that you generated in

the previous steps and an empty mediation module display.
1268
At this point, the SAP Outbound interface is ready to be used in the further
development of the mediation module. In the next stage, you test the SAP
Outbound interface with the integrated test client.
12.6.3 Deployment
Process Server. In this scenario, you use WebSphere ESB Server. Follow these
steps:
1269
Project Clean as shown in Figure 12-135. In the confirmation select your
project or rebuild all projects.
1270
4. In the Add and remove projects dialog box, select the

ITSOSAPWebSphereALEInboundApp project and click Add as shown in
Figure 12-137. Then, click Finish.
1271

In the test scenario, you update multiple material items in SAP. First, you prepare
an array of IDocs with the mandatory sections and properties. Then, you specify
changed properties, in this case the old material number properties (Bismt).
Follow these steps:
1. In the assembly editor, right-click SAPOutboundInterface and select Test
Component as shown in Figure 12-138.
1272
2. In the Initial Request Parameter section, navigate to the SapMatmas05.

Right-click and select Add Element to create an SAPMatmas05 record. Refer
to Figure 12-139.
Figure 12-139 Initial request parameter add element
1273
3. Inside the SapMatmas05 record, navigate to SapIDocControlRecord and

complete the initial request parameter (Figure 12-140). Table 12-3 shows the
required parameters of the SapIDocControlRecord.
Parameter
Value
Comment
ReceiverPort
SAPxxx
Port name of the SAP system
PartnerTypeOfSender
LS
NameOfBasicType
MATMAS05
ITSO_LSYS
EDI_DC40
Client
800
LogicalMessageType
MATMAS
xxxCLNTxxx
LS
The logical name defined for the

WebSphere Adapter
Logical name of the SAP system
1274
4. Navigate to SapMatmas05E2maram005. This is a mandatory section.

Figure 12-141 Initial request parameters add SapMatmas05E2maram005
1275
5. Figure 12-4 shows the required parameters of the

SapMatmas05E2maram005. Refer to Figure 12-142.
Parameter
Value
Comment
Msgfn
004
Change
MatNr
1500-700
Material to change
Matkl
01002
Material class
Bismt
P-xyz-700

changed.
Meins
CSE
Unit of measurement
1276
6. Navigate to SapMatmas05E2maktm005. This is also a mandatory section.

1277
7. You can store the inserted SapMatmas05 record in a data pool for later
reuse. Right-click the SapMatmas05[0] record and select Add Value to Pool
Figure 12-144 Add Value to Pool
8. In the Value Name dialog box, click OK. Refer to Figure 12-145.
Figure 12-145 Data Pool dialog box
1278
9. To insert additional SapMatmas05 IDoc records, navigate to the

SapMatmas05. Right-click and select Add Element to create another
SapMatmas05 record. Repeat this step for a third SapMatmas05 record.
10.To populate with the same values like in the first record, right-click at each of
the two new records and select Use Value from Pool as shown in
Figure 12-146.
Figure 12-146 Use value from pool
1279
11.Select the SapMatmas05 record that you want to copy and click OK as shown
in Figure 12-147.
Figure 12-147 DataPool dialog box
1280
12.To make the three records targeting different materials, change the data in
SapMatmas05E2maram005 for each record as shown in Table 12-5.
Table 12-5 Change SapMatmas05E2maram005 data
MatNr
1500-700
1500-710
1500-720
Material to change
Bismt
P-xyz-700
P-xyz-710
P-xyz-720

changed.
13.When finished preparing the data, click Continue to send the IDoc to SAP.
1281
14.In the SAP GUI open the transaction WE02 (IDoc List). You can check the
received IDocs. Refer to Figure 12-149.
Figure 12-149 WE02, SAP IDoc list
12.6.5 Conclusion
transfer a collection of IDoc messages to the SAP system. This kind of
interaction with SAP is very powerful and can send batch IDocs. It is often used
for system replications or system-to-system transfers. WebSphere Adapter for
SAP Software sends these objects in one message containing a set of IDocs
representing the single business objects to SAP.
1282

deployment inbound ALE
You can deploy the modules of the scenarios into WebSphere Process Server
instead of WebSphere Enterprise Service Bus. This section extends the
mediation module of scenario ALE Inbound with an interface. An additional
module representing a business process is created. When a message including
a material IDoc from SAP arrives, the material number is passed to a business
process.

Figure 12-150 shows the operational model for this extension.
SAP ERP 2004
WPS 6.0.1.2 (WAS 6.0.2.9)

Cloudscape
Eventtable
bd10
WID 6.0.1.2
Testclient
SCA
ITSOSAPWebSphereALEInbound
ALE
TCP/SAPRFC
MATMAS05
ITSO.SAP.1
Adapter 6.0.1
RAR
ITSO.IBM.1
1283
12.7.2 Development
Creating a Shared Library
Creating a business process module
Extending the mediation module

the interface ITSOMaterial is moved from the project
ITSOSAPWebSphereALEInbound to a common library.
To create a Shared Library, follow these steps:
1. In the Business Integration view, right-click and select New Library as
Figure 12-151 Create Library
1284
2. Enter a name for the Library as shown in Figure 12-152.
Figure 12-152 Library properties
1285
3. Inside the ITSOSAPWebSphereALEInbound project, navigate to Interfaces,

and select Copy in the pop-up menu of the interface ITSOMaterial
(Figure 12-153). Select Interfaces inside the ITSOCommonLib and paste the
Interface ITSOMaterial. Inside the project ITSOSAPWebSphereALEInbound,
you can delete this interface. You can also perform the same task by
dragging the interface with the mouse from
ITSOSAPWebSphereALEInbound Interfaces into the
ITSOCommonLib Interfaces.
Figure 12-153 Copy Interface
4. Save and close the common library.
1286

To create a business process module, follow these steps:
1. In the Business Integration View right-click and select New Module as
1287
2. Enter the name ITSOWPSALEInbound for the new module as shown in

Figure 12-155.
Figure 12-155 New module dialog box
3. Right-click the new module and select Open Dependency Editor as shown
in Figure 12-156.
Figure 12-156 Open Dependency Editor
1288
4. Add ITSOCommonLib as the required library, then save and close the editor.
Figure 12-157 Add dependency
1289
5. Open the assembly editor, in the palette, select Export icon and place the
Export into the pane. On the Export component, select Add Interface as
shown in Figure 12-158. Select the interface ITSOMaterial and click OK.
Figure 12-158 Assembly editor
6. In the palette, click the Process icon and create a process component. Refer
to Figure 12-59.
Figure 12-159 Create process component
1290
7. Connect the Export and the Process component together. In the confirmation
dialog box, click OK.
8. Right-click the process component and click Generate Implementation as
shown in Figure 12-60. Select OK on the location dialog box.
The Business Process Editor opens. Refer to Figure 12-161.
Figure 12-161 Business Process Editor
1291
9. Add a Java snippet below the Receive action. Refer to Figure 12-162.
Figure 12-162 Add Java snippet
10.Select the Java snippet and select Properties and Details.

11.Choose Java for implementation and confirm the following dialog box.
12.Enter the following Java code to print the received material number on the
console:
System.out.println(Business Process is called passing the following
material number: + Material);
1292
Figure 12-163 Implement Java snippet
13.Save the Process component.

14.In the Assembly Editor, right-click the Export component and select Generate
Binding SCA Binding as shown in Figure 12-164.
Figure 12-164 Generate SCA Binding
15.Save the module.
1293

You reuse and modify the mediation module ITSOSAPWebsphereALEInbound
that you developed in 12.4.2, Development on page 1192 for this extended
scenario. Follow these steps:
1. In the module ITSOSAPWebsphereALEInbound, add a dependency to the
ITSOCommonLib where the ITSOMaterial interface is located. Right-click the
project and click Open Dependency Editor as shown in Figure 12-165. Add
ITSOCommonLib as the required library, then save and close the editor.
Figure 12-165 Add dependency
1294
2. Open the Assembly Editor and add an Import component from the palette.
Figure 12-166 Add import component
3. Remove the Java component and connect the Mediation component with the
Import.
Figure 12-167 Assembly Editor
1295
4. Right-click the Import component and select Generate Binding SCA

5. Right-click the import again and select Select Service to Import as shown in
Figure 12-169.
Figure 12-169 Select Service to Import
1296
6. In the SCA Export Selection dialog box, select Export1 of the business
process module that you developed in the previous task. Click OK. Refer to
Figure 12-170.
Figure 12-170 SCA Export Selection
1297
7. Change the J2C Authentication Data Entry name to widNode/SAPLogin, the

one that you configured in the WebSphere Process Server. To change the
name, select SAPInboundInterface and navigate to Properties
Binding Security attributes. Enter widNode/SAPLogin and save the
component. Refer to Figure 12-171.
Figure 12-171 Security attributes
1298
12.7.3 Deployment
This section explains how to deploy the project that you created in a WebSphere
Process Server environment. Follow these steps:
1. In the Server view, right-click WebSphere Process Server and select Start
Figure 12-172 Start WebSphere Process Server
Project Clean in the menu. In the confirmation, rebuild all projects.
3. After the server is started, in the Server view, right-click WebSphere Process
Server and select Add and remove Projects as shown in Figure 12-173.
1299
4. Add ITSOSAPWebsphereALEInboundApp and ITSOWPSALEInboundApp to

the Configured projects as shown in Figure 12-174.

The deployed application is listening for SAP IDoc events. To test, follow these
steps:
1. In the SAP GUI open the transaction BD10 (Send Material).
1300
2. Insert a material number (1500-710) and a logical system (ITSO_LSYS) and

click the Execute icon as shown in Figure 12-175. Click OK on the
information dialog boxes.
3. The material IDoc is sent from SAP to WebSphere. The SAPInboundInterface

receives the IDoc and creates a business object representing the material
item. In a mediation the material number is extracted and passed to a
business process. The business process prints out the material number to the
console. Refer to Figure 12-176.
Figure 12-176 Final console output
1301
12.7.5 Conclusion
This scenario demonstrated how you can easily reuse a module, implementing
an SAP ALE Inbound scenario, designed for WebSphere Enterprise Service Bus
in a WebSphere Process Server environment. Also the powerful additional
options of a WebSphere Process Server could be used.
Every WebSphere Adapter for SAP Software project can be extended very
easily. This also allows a reuse of investment if a company starts with a
WebSphere Enterprise Service Bus environment and then upgrades to a

deployment outbound ALE
You can deploy the modules of the scenarios into WebSphere Process Server
instead of WebSphere Enterprise Service Bus. This section extends the
mediation module of scenario ALE Outbound with an interface. You can create
an additional module representing a business process. The business process
delivers an SAP material item to be changed and calls the mediation module that
is sending an IDoc to SAP.

Figure 12-177 shows the operational model for this extension.
WPS 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004
WID 6.0.1.2
Testclient
SCA
Adapter 6.0.1
RAR
TCP/SAPRFC
IDoc
ITSO.IBM.1
1302
ALE
MATMAS05
( ALEAUD )
ITSO.SAP.1
12.8.2 Development

you move the interface SAPOutboundInterface and all the generated data
objects from the project ITSOWebSphereSAPALEOutbound to the common
library. Follow these steps:
1. Inside the ITSOWebSphereSAPALEOutbound project, navigate to Interfaces,
and move the interface SAPOutboundInterface with the mouse from
ITSOWebSphereSAPALEOutbound Interfaces into the
ITSOCommonLib Interfaces.
2. Inside the ITSOWebSphereSAPALEOutbound project, navigate to Data
Types, and move all data types with the mouse from
ITSOWebSphereSAPALEOutbound Data Types into the
ITSOCommonLib Data Types.
3. Save and close the common library.
Extending a mediation module

You reuse and modify the ITSOWebsphereSAPALEOutbound mediation module
that you developed in 12.5.2, Development on page 1238 for this extended
scenario. Follow these steps:
1. In the module ITSOWebsphereSAPALEOutbound, add a dependency to the
ITSOCommonLib, where the SAPOutboundInterface is located. Right-click
the project and click Open Dependency Editor. Add ITSOCommonLib as the
required library, then save and close the editor.
2. In the project ITSOWebsphereSAPALEOutbound, open the Assembly Editor.
3. Connect the mediation module to the SAPOutboundInterface.
1303
4. Create an Export component and connect it to the mediation module using

the SAPOutboundInterface. Refer to Figure 12-178.
Figure 12-178 ITSOWebsphereSAPALEOutbound Assembly Editor
5. Right-click the Mediation component and select Generate Implementation.

6. Inside the Mediation Editor connect SAPOutboundInterface to
SAPOutboundInterfacePartner.
1304
7. This is the place to put in a mediation, where you can change or map the
messages. In this scenario, the message is passed unchanged. In the lower
pane, connect Request - executeSAPMatmas05:SAPOutboundInterface to
Invoke - executeSAPMatmas05:SAPOutboundInterfacePartner as shown in
Figure 12-179.
Figure 12-179 Request mediation flow
8. Select the Response - executeSAPMatmas05 tab.
1305
9. In the lower pane connect Response executeSAPMatmas05:SAPOutboundInterfacePartner to Response executeSAPMatmas05.:SAPOutboundInterface as shown in Figure 12-180.
Figure 12-180 Response mediation flow
10.Save and close the mediation component and the assembly editor.

To create a business process module, follow these steps:
1. In the Business Integration View, right-click and select New Module.
2. Enter the name ITSOWPSALEOutbound for the new module.
3. Right-click the new module and select Dependency Editor.
4. Add ITSOCommonLib as required library, then save and close the editor.
1306
5. Open the assembly editor, in the palette, select the Import icon, and place
the Import into the pane. On the Import component, select Add Interface.
Select the SAPOutboundInterface interface and click OK as shown in
Figure 12-81.
Figure 12-181 Add Interface dialog box
1307
6. Right-click the Import component and select Generate Binding SCA

Figure 12-182 Generate Binding
7. Right-click the Import component and click Select Service to Import.
1308
8. Choose ITSOWPSALEOutbound /Export1.export as shown in

Figure 12-83.
Figure 12-183 Select service to import
9. In the palette, click the Process icon and create a process component.
1309
10.Connect the Process component and the Import component together. In a

confirmation dialog box, click OK. Refer to Figure 12-184.
Figure 12-184 Assembly Editor
11.Right-click the process component and click Generate Implementation.

Select OK on the location dialog box.
1310
12.The Business Process Editor opens. Place a new Invoke action between the
Receive and Reply action as shown in Figure 12-185.
Figure 12-185 Business Process Editor
13.Right-click the Invoke Action and select Add Partner.
1311
14.In the Select a Partner dialog box, select SAPOut boundInterfacePartner

Figure 12-186 Select a Partner
15.Save and close the Process component.

16.Save the module.
12.8.3 Deployment
This section explains how to deploy the project that you created in a WebSphere
Process Server environment. Follow these steps:
1. In the Server view, right-click WebSphere Process Server and select Start.
Project Clean in the menu. In the confirmation rebuild all projects.
3. After the server is started, in the Server view, right-click WebSphere Process
Server and select Add and remove Projects.
4. Add the ITSOWebsphereALEOutboundApp and ITSOWPSALEOutboundApp
to the configured projects.
1312

In the test scenario, you update a material item in SAP. First you prepare an IDoc
message with the mandatory sections and properties. Then, you specify a
changed property, in this case the old material number property (Bismt). Follow
these steps:
1. Inside the project ITSOWPSALEOutbound, open the assembly editor,
right-click the Process Component1 and select Test Component as shown in
Figure 12-187.

2. Inside the test client select the Configurations tab.
1313
3. Per default, the current component is tested and the import is emulated. In
this case, the imported service is executed. In Configurations, select
Emulators Import1 and click Remove as shown in Figure 12-188.
Figure 12-188 Remove emulators
4. Select the Events tab and go to the Events view.
1314
5. If the SapMatmas05 data that you used in the SAP ALE Outbound scenario is
stored in the Data Pool, you can reuse it. In the Initial Parameter section,
right-click SapMatmas05 and select Use Value from Pool as shown in
Figure 12-189.
Figure 12-189 Use value from pool
In the Data Pool dialog box, filter for type SapMatmas05, select
SapMatmas05, and click OK. Refer to Figure 12-190. The data are copied to
the Initial Parameter section.
If there is already data in the pool, you can reuse that data and you can skip
to step 10 on page 1320. Otherwise, you need to enter the data manually and
need to continue with the next step.
1315
Figure 12-190 Data Pool dialog box
6. If the data is not present in the data pool, in the Initial Parameters section,
navigate to the SapIDocControlRecord and fill in the initial request parameter.
Table 12-6 shows the required parameters of the SapIDocControlRecord.
1316
Parameter
Value
Comment
ReceiverPort
SAPxxx
port name of the SAP system
PartnerTypeOfSender
LS
NameOfBasicType
MATMAS05
ITSO_LSYS
EDI_DC40
Client
800
LogicalMessageType
MATMAS
xxxCLNTxxx
LS
the logical name defined for the

WebSphere Adapter
logical name of the SAP system
7. Navigate to SapMatmas05E2maram005. Refer to Figure 12-192. This is a

mandatory section. Right-click and select Add Element.
8. Table 12-7 shows the required parameters of the
SapMatmas05E2maram005.
Parameter
Value
Comment
Msgfn
004
Change
MatNr
1500-700
Material to change
Matkl
01002
Material class
Bismt
P-xyz-700
The property holding the old

material number (coming from an
existing system). This is the value
actually changed.
Meins
CSE
unit of measurement
1317
1318
9. Navigate to SapMatmas05E2maktm005. Refer to Figure 12-193. This is also

a mandatory section. Right-click and select Add Element.
1319
10.Click Continue to send the IDoc to SAP. In the Deployment Location dialog
box, select WebSphere Process Server as deployment location and click
Finish. Refer to Figure 12-194.
1320
11.In the SAP GUI open the transaction WE02 (IDoc List). The received IDoc
can be checked. Refer to Figure 12-195.
Figure 12-195 WE02, SAP IDoc
12.8.5 Conclusion
This scenario demonstrated how you can reuse a module, implementing an SAP
ALE Outbound scenario, designed for WebSphere Enterprise Service Bus in a
WebSphere Process Server environment. Also, you can use the powerful
additional options of a WebSphere Process Server.
Every WebSphere Adapter for SAP Software project can be extended very
easily. This also allows a reuse of investment if a company starts with an
WebSphere Enterprise Service Bus environment and then upgrades to a
1321
1322
13
Chapter 13.
SAP: WebSphere Business
Integration Adapter
scenarios
This chapter begins with an overview of the implemented scenarios. It then
describes the preparations that are common to all the scenarios. The preparatory
steps include installing the WebSphere Business Integration Adapter or
mySAP.com and pre-requisite software, preparing the SAP environment for
event notification, and the development steps that are common to all the
scenarios.
This chapter then describes each scenario separately. While the scenarios are
meant to apply to either WebSphere Enterprise Service Bus or WebSphere
Process Server, the development is slightly different for these two target
environments. This chapter documents the WebSphere Enterprise Service Bus
environment. Scenario A is extended to run on WebSphere Process Server.
1323
This chapter includes the following sections:

Installing the WebSphere Business Integration Adapter or mySAP.com on
page 1327
Preparing the SAP environment on page 1353
Development steps common to both scenarios on page 1363
Scenario A: WebSphere Business Integration Adapter Advanced Event
notification - SIBus on page 1371
Configuration on page 1372
Scenario B: WebSphere Business Integration Adapter Advanced Event
notification - WebSphereMQ on page 1401
Configuration on page 1401
1324

Figure 13-1 is an overview of the installed systems and software.
ITSO.IBM.1
ITSO.SAP.2

6.0.1.2
SAP ERP 2004
IBM DB2 8.1

6.0.1.2
WebSphere MQ 5.3
WBI Adapter Framework 2.6.5
WBI Adapter 6.0.5
Attention: This is the setup that we used for this book. It reflects the current
support statements for Windows environment. The operating system and
version number of products might be different in your environment. Always
apply the latest fix packs.
Note: For the scenarios that we demonstrate in this chapter, authentication is

required. We use the itsouser user ID and itso1 password as examples.
However, you can replace these appropriately to suit your environment.
Chapter 13. Adapter-based integration to SAP: WebSphere Business Integration Adapter scenarios
1325

You can use the WebSphere Business Integration Adapter or mySAP.com for the
advanced tasks that are not supported by the JCA adapter, such as the
Advanced Event notification, which we demonstrate in this chapter.
Note: Advanced Event notification refers to the collection of processes that
notify the adapter of SAP application object events. Notification includes the
type of the event (object and verb) and the data key that is required for the
external system to retrieve the associated data. It is enabled by the ABAP
Extension Module.
Event notification for the adapter consists of event polling and event triggering.
Event polling function is distributed between the adapter and ABAP
components. However, the adapter component always initiates event polling.
To get events out of the SAP application, it is necessary to implement in SAP
an event triggering mechanism for each business object that IBM WebSphere
supports.
The two scenarios that we present here are identical. The WebSphere Business
Integration Adapter or mySAP.com polls SAP for the subscribed events and
propagates them to the integration broker through JMS. The integration broker in
this case is either WebSphere Process Server V6 or WebSphere Enterprise
Service Bus V6.
The difference between the two scenarios is whether the WebSphere Business
Integration Adapter uses WebSphere MQ messaging and, therefore, additional
configuration for the WebSphere MQ as a foreign bus.
13.2.1 Scenario A: Advanced Event notification with SI Bus

WebSphere Business Integration Adapter or mySAP.com is configured to use
the SI Bus as a message broker. WebSphere Enterprise Service Bus V6 is
configured with WebSphere MQ Client Link.
13.2.2 Scenario B: Advanced Event notification with WebSphere MQ

WebSphere Business Integration Adapter or mySAP.com is configured to use
WebSphere MQ as a message broker. WebSphere Enterprise Service Bus V6 is
configured with MQ Link.
1326
13.3 Preparation
As pointed out in the scenario overview, the scenarios differ in the configuration
of messaging. Another difference is introduced to support the configuration of
more than one scenario in the same environment. The connector is named
differently for each scenario. This naming difference then carries over to the
development process.
There are common preparation steps for both scenarios. These common steps
include software installation and configuration in both the WebSphere and SAP
environments.
13.3.1 Installing the WebSphere Business Integration Adapter

or mySAP.com
The WebSphere business integration system includes WebSphere Business
Integration adapters and other components. WebSphere Business Integration
adapters and some associated components are delivered on CD or through IBM
Electronic Software Delivery (ESD). You must obtain and install the other
components that the WebSphere Business Integration system uses separately.
The installation consists of installing the prerequisite software (WebSphere MQ
and WebSphere Business Integration Adapter Framework), WebSphere
Business Integration Adapter or mySAP.com, and finally the SAP Java API (JCo
adapter).
1327
13.3.2 Installing WebSphere MQ V5.3

This section explains how to install WebSphere MQ and highlights the need to
install the JMS libraries. Follow these steps:
1. You install from WebSphere MQ V5.3 from CD. First, run setup.exe to start
the WebSphere MQ Installation Launchpad as shown in Figure 13-2.
Figure 13-2 WebSphere MQ Installation Launchpad
1328
2. Select 1 Software Prerequisites as shown in Figure 13-3.
Figure 13-3 Step 1 - WebSphere MQ software prerequisites
3. Install the supported Java Runtime Environment (JRE) if necessary. For

example, click Install Now From: WebSphere MQ CD (Figure 13-3). Then,
follow these steps:
a. Select English as the setup language and click OK to start the
InstallShield wizard. Refer to Figure 13-4.
Figure 13-4 JRE setup language dialog box
1329
b. In the Welcome dialog box, click Next as shown in Figure 13-5.
Figure 13-5 JRE installation wizard dialog box
c. Read the License Agreement and then select Yes to accept it

(Figure 13-6).
Figure 13-6 JRE license agreement dialog box
1330
d. You can accept the default installation path or choose another one. Then,
click Next. Refer to Figure 13-7.
Figure 13-7 JRE destination folder dialog box
e. Choose Setup Type and click Next as shown in Figure 13-8.
Figure 13-8 JRE setup type dialog box
1331
f. Click Yes to Install JRE as the System JVM as shown in Figure 13-9.
Figure 13-9 Install JRE as the system JVM dialog box
g. Review the current settings summary and click Next to start copying files.
Figure 13-10 JRE install current settings summary dialog box
1332
h. In the Install Complete dialog box, click Finish to close the wizard as
Figure 13-11 JRE installation complete dialog box
1333
4. Click 2 Network Prerequisites (Figure 13-12). Answer the question as

appropriate.
Figure 13-12 Step 2 - WebSphere MQ network prerequisites
1334
5. Click 3 WebSphere MQ installation. Refer to Figure 13-13.
Figure 13-13 Step 3 - WebSphere MQ pre-installation status
Ignore the missing software prerequisite warning if present, and click Launch
WebSphere MQ Installer.
1335
6. Click Next in the Welcome dialog box as shown in Figure 13-14.
Figure 13-14 WebSphere MQ installation welcome dialog box
7. Read the license agreement and then select I accept the terms in the
license agreement in the License Agreement dialog box. Click Next as
Figure 13-15 WebSphere MQ installation license dialog box
1336
8. Select Custom in the Setup Type dialog box. (A Typical installation does not
select the Java Messaging feature. See step 10). Click Next as shown in
Figure 13-16.
Figure 13-16 WebSphere MQ installation setup type dialog box
9. Select the folder for all three destination dialog boxes (only the first one is
shown in the figure) and click Next to continue. Refer to Figure 13-17.
Figure 13-17 WebSphere MQ installation destination folder dialog box
1337
10.Select the Server and Java Messaging features and click Next. Refer to
Figure 13-18.
Note: The adapter in the configuration needs the JMS libraries and does
not start if it cannot find them.
Figure 13-18 WebSphere MQ installation setup type dialog box
11.Confirm the current settings and click Install as shown in Figure 13-19.
Figure 13-19 WebSphere MQ installation summary dialog box
1338
12.Answer Yes to the sufficient license question as shown in Figure 13-20.
Figure 13-20 WebSphere MQ install sufficient licenses question
13.Wait until the installation completes. Refer to Figure 13-21.
Figure 13-21 WebSphere MQ installation wait dialog box
1339
14.Click Finish in the confirmation dialog box as shown in Figure 13-22. The
installation is complete.
Figure 13-22 WebSphere MQ installation complete confirmation dialog box
15.In the Welcome to the Prepare WebSphere MQ Wizard dialog box, click
Cancel (Figure 13-23). You perform the step to prepare WebSphere MQ later
using a script.
Figure 13-23 Prepare WebSphere MQ Wizard welcome dialog box
1340

Framework
This section explains how to install the WebSphere Business Integration Adapter
framework. Follow these steps:
1. Run setupwin32.exe.
2. Select English as the language and click OK (Figure 13-24).
Figure 13-24 Select the language dialog box
3. Wait for the Welcome dialog box. Click Next to continue (Figure 13-25).
Figure 13-25 Installation welcome dialog box
1341
4. Read the license agreement and select I accept the terms in the license
agreement in the Software License Agreement. Then, click Next
(Figure 13-26).
Figure 13-26 Installation license dialog box
5. Do not select the IBM WebSphere InterChange Server option and click Next
Figure 13-27 Installation InterChange Server dialog box
1342
6. Click Browse or enter the installation directory and click Next to continue as
Figure 13-28 Installation directory dialog box
7. Select the IBM WebSphere Business Integration Adapter Runtime and

IBM WebSphere Business Integration Toolset features under Product
Installation as shown in Figure 13-29 and click Next.
Figure 13-29 Installation features dialog box
1343
8. Ensure that the correct Java library is completed (Figure 13-30) and click
Next to continue.
Figure 13-30 Installation Java library dialog box
9. Accept the value in the Program Group dialog box and click Next as shown in
Figure 13-31.
Figure 13-31 Installation program group dialog box
1344
10.Confirm the information in the location and features dialog box and click Next
Figure 13-32 Installation summary dialog box
11.Wait for the installation to complete. Refer to Figure 13-33.
Figure 13-33 Installation wait dialog box
1345
12.Click Finish to exit the wizard. Refer to Figure 13-34.
Figure 13-34 Installation finish dialog box
1346

or mySAP.com
This section explains how to install the WebSphere Business Integration Adapter
or mySAP.com. Follow these steps:
Important: For WinXP users, WinXP is not a supported environment for the
WebSphere Business Integration Adapter for mySAP.comHowever, it is
possible to install WebSphere Business Integration Adapter or mySAP.com on
WinXP by checking the Win2K compatibility property on the setupwin32.exe,
Figure 13-35 WebSphere Business Integration Adapter installation XP set compatibility
1347
Follow these steps to install WebSphere Business Integration Adapter or

mySAP.com:
1. Run setupwin32.exe.
Figure 13-36 WebSphere Business Integration Adapter installation language dialog box
3. In the Welcome panel, click Next as shown in Figure 13-37.
Figure 13-37 WebSphere Business Integration Adapter installation welcome dialog box
4. Read the license agreement and select I accept the terms in the license
agreement in the Software License Agreement. Then, click Next
(Figure 13-38).
1348
Figure 13-38 WebSphere Business Integration Adapter installation license dialog box
5. Click Browse or enter the installation directory and then click Next as shown
in Figure 13-39.
Figure 13-39 WebSphere Business Integration Adapter installation directory dialog box
1349
6. Review the summary and click Next to continue as shown in Figure 13-40.
Figure 13-40 WebSphere Business Integration Adapter installation summary dialog box
7. Leave all the fields blank (you do not use IBM WebSphere InterChange
Server in this scenario) as shown in Figure 13-41 and click Next.
Figure 13-41 Installation InterChange Server dialog box
1350
8. Accept the default Program Group and click Next as shown in Figure 13-42.
Figure 13-42 Installation program group dialog box
9. In the completion confirmation dialog box, click Finish to close the wizard as
Figure 13-43 Installation completion confirmation dialog box
1351
13.3.5 Verifying the WebSphere Business Integration Adapter

installation
The installer copies the standard files that are associated with the adapter into
your system. It installs the adapter into the following directory:
C:\WebSphere\WBIAdapters\connectors\SAP
You can use Table 13-1 to confirm the installed file structure in the Windows
environment.
Table 13-1 Confirming the installed file structure in the Windows environment
Directory and file name
Description
connectors\SAP\bapi\client
Directory that includes the BAPI Module business

object handler files
connectors\SAP\bapi\server
Directory that includes the RFC Server Module

business object handler files
connectors\SAP\dependencies
Directory that includes all version-specific transport

files
connectors\messages
Directory that includes the Connector.txt file
connectors\SAP\samples
Directory that includes sample ABAP objects
connectors\SAP\CWSAP.jar
Connector class file
connectors\SAP\start_SAP.bat
Batch file used to start the connector
repository\SAP
Directory that includes the CN_SAP.txt file
lib
Includes the WBIA.jar file
bin
Includes the CWConnEvn.bat file
Important: Always apply the latest fix packs as explained in the product
documentation.
13.3.6 Installing the SAP Java API (SAP JCo)

After you install and verify the WebSphere Business Integration Adapter or
mySAP.com, you need to download and install the SAP Java API (SAP JCo).
The WebSphere Business Integration Adapter or mySAP.com currently supports
SAP JCo V.2.1.6.
1352
You can download the SAP JCo for the appropriate operating system from the
SAP Web site at:
http://service.sap.com/connectors
An SAPNet account is required to access the site and to download the SAP JCo.
After you extract the SAP JCo files, copy these files:
librfc32.dll
sapjco.jar
sapjcorfc.dll
To the following directories:
connectors\SAP
ODA\SAP
Note: Install the Microsoft files msvcp71.dll and msvcr71.dll files in the
Windows system path. See SAP Note 684106 on the SAP Service
Marketplace Web site (http://service.sap.com) for additional details. The
DLL files are included in the attachments section of the SAP Note along with
instructions on how to install them. You must have a valid user name and
password for the SAP Service Marketplace to view the SAP Note.
13.3.7 Installing other required software

Information about how to install WebSphere Enterprise Service Bus, WebSphere
Process Server, and WebSphere Integration Developer is not within the scope of
this book. Check the product documentation for installation instructions for these
products.
13.3.8 Preparing the SAP environment

To prepare the SAP environment, you need to install the most recent SAP
Support Package for your version of SAP. You also need to set up a CPIC user
account in the SAP application. This account needs the necessary privileges to
manipulate the data that is required by the business objects that are supported
by the connector.
1353
Configuring SAP for an event notification

To configure SAP for an event notification, follow these steps:
1. Log on to SAP.
2. Use the Business Object Browser (transaction SWO2) to identify the
Business Object to be used, in this case, the MaintenanceOrder
(Figure 13-44).
Figure 13-44 Business Object browser, code SWO2
1354
3. Double-click MaintenanceOrder to bring up detail panel, expand Key fields,

and double-click the key (Figure 13-45).
Note the Object type and Reference table name values, in this case BUS2007
and AUFK respectively.
Figure 13-45 Business Object key fields detail
1355
4. Expand Events, and note the details on Event created (Figure 13-46).
Figure 13-46 Business Object events detail
1356
5. Use SAP Business Workflow to hook up on the workflow event. Use the
transaction code SWETYPV and scroll down to the area of the Object Type.
Figure 13-47 Event type linkages panel, code SWETYPV
1357
6. Click New Entries to create a new entry for the event (Figure 13-48).
Example 13-1 gives the details of the values to create a new entry for a
workflow event.
Example 13-1 Values to create a new entry for a workflow event
Object Category: BOR Object Type

Object Type: BUS2007
Receiver Call: Function Module
Receiver Function Module: /CWLD/ADD_TO_QUEUE_DUMMY_47
Receiver Type Function Module: /CWLD/ADD_TO_QUEUE_WF_47
Linkage Activated (select)
Figure 13-48 Event type linkages panel, creating new entry
1358
7. Configure the WebSphere Business Integration ABAP Extension Module to

receive event from SAP:
a. Use the WebSphere Business Integration Station v6.0 Maintain objects
function on the Tools tab or transaction code /CWLD/OB to create the
object SAP47_aufk (Figure 13-49).
Figure 13-49 WebSphere Business Integration Maintain objects
1359
b. Use the Config Objects function or transaction code /CWLD/CO to create

a configuration object (Figure 13-50). Example 13-2 gives the details of
the values to create a configuration object.
Example 13-2 Values to create a configuration object
Configuration name: MaintenanceOrder.CREATED

Text: Workflow trigger
Figure 13-50 WebSphere Business Integration Configuration objects
1360
c. Use the WebSphere Business Integration Station v6.0 Configuration

Values function on the Config tab or transaction code /CWLD/RJ to create
a mapping between SAP Workflow event and WebSphere Business
Integration event BO (Figure 13-51). Example 13-3 gives the values to
create new BI Object parameter configuration.
Example 13-3 Create new BI Object parameter configuration
Configuration name: MaintenanceOrder.CREATED

Counter :0
Configuration value: SAP47_aufk.Retrieve
Figure 13-51 WebSphere Business Integration Object parameter configuration
1361
d. Use the Event Distribution function or transaction code /CWLD/RH to

create an event distribution to connector (Figure 13-52). Example 13-4
gives the details of the values to create new BI Object parameter
configuration.
Example 13-4 Create new BI Object parameter configuration
Object name: SAP47_aufk

Counter :0
Connector name: ITSOConnector
Figure 13-52 WebSphere Business Integration event distribution between connectors
1362
13.4 Development steps common to both scenarios

This section describes the configurations that are necessary to both scenarios
on the IBM side.
13.4.1 Creating an integration component library

To create an integration component library, follow these steps:
1. Open the System Manager.
2. Create new integration component library.
3. Right-click in the Integration Component Libraries tree and click New
Integration Component Library as shown in Figure 13-53.
Figure 13-53 Create integration component library
1363
4. Name it ITSO_SAP_ICL as shown in Figure 13-54 and click Finish.
Figure 13-54 New Integration Component Library dialog box
13.4.2 Developing an event business object

To develop an event business object, follow these steps:
1. Start mySAP.com Object Discovery Agent.
2. In the System Manager window expand the Integration component library
created in the previous step, right-click the tree Business Objects, and click
Create New business object as shown in Figure 13-55. This opens the
Business Object Designer.
Figure 13-55 Create new business object
1364
3. Click Cancel to close the initial business object naming panel.

4. Click File New using ODA to start the Business Object wizard as shown in
Figure 13-56.
Figure 13-56 Start Business Object wizard through New Using ODA
5. Click Find Agents to get a list of the running ODAs and select the Located
agent and click Next. Refer to Figure 13-57.
Figure 13-57 Business Object wizard Step 1 of 6
6. Specify the SAP back-end system with values shown in Table 13-2. Then,
click Next.
1365
Table 13-2 ODA configuration data

Field
Value
User Name
itsouser
Password
itso1
Client
800
System Number
00
AS Hostname
ITSO.SAP.2
File Destination
C:\repository\export\ITSO_SAP
Note: You can use saved system profiles to avoid typing errors by opening the
Current profile select box. Refer to Figure 13-58.
1366
7. In Step 3 of the Business Object Wizard, follow these steps:

a. Expand Dynamic Definitions.
b. Expand HDR.
c. Right-click Search By Name and click Search items.
d. Enter the name AUFK noted in Figure 13-45 on page 1355. (It is possible to
use a wildcard). Refer to Figure 13-59. Click OK.
Figure 13-59 Business Object wizard search dialog box
1367
e. Select the table and click Next. Refer to Figure 13-60.
1368
8. ODA now generates the object definition. Make sure that the Prefix Value is
correct or change it in the additional values dialog box. Refer to Figure 13-61.
9. Click Yes in the dialog box that warns you about the 512 bytes limitation and
select the attributes to be included (Figure 13-62). Then, in the next dialog
box, click OK.
Figure 13-62 Agent notification 512 bytes exceeded
1369
10.Save Business object definitions as shown in Figure 13-63 and click Finish.
Important: The business object name has to match the value that you
entered earlier in the configuration value field (for example, SAP47_aufk).
Check that the Retrieve verb of the business object is set to the value
sap.bapimodule.vDynRetBOH.
11.Close the Business Object Designer.
13.4.3 Starting the target server

For the purposes of the following instructions, the WebSphere Integration
Developer is expected to be open, and the server running. To start the target
server, follow these steps:
1. Open WebSphere Integration Developer and switch to the Business
Integration Perspective.
2. In the Servers view, select WebSphere ESB Server v6.0, then right-click and
select Start from the context menu.
1370
3. Wait for the message Server server1 open for e-business to display in the
Console view as shown in Figure 13-64.
Figure 13-64 Server server1 open for e-business
13.5 Scenario A: WebSphere Business Integration

Adapter Advanced Event notification - SIBus
This inbound scenario demonstrates how the WebSphere Enterprise Service
Bus can receive events from SAP application using the capability provided by the
ABAP Extension Module of the WebSphere Business Integration Adapter or
mySAP.com.
1371

Figure 13-65 shows the system setup and the step-by-step flow.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004

1
WID 6.0.1.2
Testclient
WBI Adapter for

mySAP.com 6.0.5
Event
Notification
2
SCA
JMS
ITSOSAPWebSphereAEN
4
SI Bus
ITSO_SAP_1/DELIVERYQUEUE
ITSO.IBM.1
ITSO.SAP.2
Figure 13-65 Scenario A operational model
This section includes following steps:
Configuring the SAP connector
Deploying WebSphere Business Integration artifacts
Creating a batch file on the desktop which starts the connector
Configuring the SAP connector

To configure the SAP connector, follow these steps:
1372
2. Expand the Integration component library created in the Scenario A: Sending

an IDoc from SAP to WebSphere Application Server using XML/HTTP on
page 879, right-click the tree Connectors, and click Create new connector
Figure 13-66 Create new connector
1373
3. In the New Connector dialog box (Figure 13-67), follow these steps:
a. Enter ITSO_SAP_1 as the Name.
b. Select WAS in the System Connectivity droplist.
c. Select SAPConnectorTemplate from the Template Name list.
d. Click OK.
Figure 13-67 New Connector dialog box
4. In the Connector Configurator/Standard Properties tab, enter the values listed

in Table 13-3. Refer to Figure 13-68.
Table 13-3 Connector Configurator/ Standard Properties values
1374
Property
Value
ApplicationName
ITSO
jms MessageBrokerName
WBIA_QM:WBIA.JMS.SVRCONN:localhost:5558
jms Username
itsouser /required but not used
jms Password
password /required but not used
MessageFileName
SAPConnector.txt
RepositoryDirectory
C:\repository\ITSO_SAP
Figure 13-68 Connector Configurator Standard Properties tab
1375
5. To determine the port for the JMS MessageBrokerName, look it up using the
administrative console under Servers Application servers server1
Communications Ports. Look for SIB_MQ_ENDPOINT_ADDRESS. Refer
to Figure 13-69.
Figure 13-69 Administrative console ports table
6. In the Connector-Specific Properties tab, enter the values listed in Table 13-4.
Table 13-4 Connector-Specific Properties values
1376
Property
Value
ApplicationUserName
itsouser
ApplicationPassword
itso1
Modules
Extension
Client
800
Hostname
ITSO.SAP.2
Sysnr
00
Figure 13-70 Connector Configurator Connector-Specific Properties tab
7. In the Supported Business Objects tab, select SAP47_aufk as shown in

Figure 13-71.
Figure 13-71 Connector Configurator Supported Business Objects tab
1377
8. Select File Save as shown in Figure 13-72. Save the connector

configuration to file c:\repository\export\ITSO_SAP\ITSO_SAP_1.cfg.
Figure 13-72 Save the connector configuration
9. Close the Connector Configurator.

To deploy WebSphere Business Integration artifacts, follow these steps:
2. Right-click User Projects WAS project and select New WebSphere
Application Server project as shown in Figure 13-73.
Figure 13-73 Create new user project
1378
3. Name the project ITSO_SAP and select Available Integration Component

Libraries as ITSO_SAP_ICL. Refer to Figure 13-74. Click Finish.
Figure 13-74 New user project dialog box
1379
4. Right-click the created project and select Deploy WebSphere Application

Server project. Refer to Figure 13-75.
Figure 13-75 Deploy WebSphere Application Server project
5. Clear all except the AgentDelivery operation as shown in Figure 13-76. This
is the only operation that is used. Click Next.
Figure 13-76 Deploy wizard component selection page
1380
6. Choose to export the artifacts to a dedicated directory, in this case

C:\repository\export\ITSO_SAP, as shown in Figure 13-77. Click Finish.
Figure 13-77 Deploy wizard destination selection page
The directory after the export procedure includes the following files:
ITSO_SAP_1.cfg
ITSO_SAP_1.wsdl
ITSO_SAP_1JMSBindings.wsdl
ITSO_SAP_1JMSService.wsdl
Creating a batch file on the desktop, which starts the

connector
Enter the line shown in Example 13-5 in the batch file.
Example 13-5 startAdapter.bat
C:\websphere\WBIAdapters\connectors\SAP\start_SAP.bat WED WAS

-cC:\repository\export\ITSO_SAP\ITSO_SAP_1.cfg
To start the connector, execute the batch file. To stop the connector, enter q in
the open connector DOS box.
1381
13.5.3 Development
1. Switch to WebSphere Integration Developer.
2. In the Business Integration view, right-click to bring up the context menu.
Select New Mediation Module as shown in Figure 13-78.
Figure 13-78 Create new mediation module
1382
3. In the New Mediation Module dialog box, enter ITSOSAPWebSphereAEN in the

Module Name field, accept WebSphere ESB Server v6.0 as Target Runtime,
leave Create mediation flow component select , and click Finish. Refer to
Figure 13-79.
Figure 13-79 New mediation module dialog box
1383
4. Right-click the ITSPSAPWebSphereAEN module in the Business Integration

view and select New Enterprise Service Discovery. Refer to
Figure 13-80. If that choice is not visible, click New Other to open a wizard
selection dialog box. Select Enterprise Service Discovery, and click Next.
Figure 13-80 New enterprise service discovery
5. Select WBI Adapter Artifact Importer and click Next as shown in

Figure 13-81.
Figure 13-81 ESD wizard resource adapter dialog box
1384
6. In the Configure Settings for Discovery Agent dialog box, browse for the
Connector configuration file, and Business object schema directory as
created in the configuration section. Click Next. Refer to Figure 13-82.
Figure 13-82 ESD wizard settings for discovery agent dialog box
7. In the Find and Discover Enterprise Services dialog box, click Run Query.
Figure 13-83 ESD wizard find and discover service dialog box - Run Query
1385
8. Select the discovered object SAP47_aufk and click Add (Figure 13-84).
Figure 13-84 ESD wizard find and discover service dialog box - Add
9. In the Configuration Parameters dialog box, clear all but

receivedSAP47_aufkDelivery and click OK as shown in Figure 13-85.
Figure 13-85 Configuration parameters for discovered object
1386
10.This completes the Find and Discover Enterprise Services dialog box.
Click Next as shown in Figure 13-86.
Figure 13-86 Completed ESD wizard find and discover service dialog box
11.Specify the folder in which the artifacts will be generated and click Finish
(Figure 13-87).
Figure 13-87 ESD wizard generate articles dialog box
1387
12.Open the Assembly Diagram editor. Refer to Figure 13-88.
Figure 13-88 Assembly diagram editor
1388
13.Wire the WEDDeliveryHub export to the mediation flow component

Mediation1 as shown in Figure 13-89.
Figure 13-89 Wiring the export and mediation flow components
14.Create new Java component, and wire the mediation flow component to the
Java component. Refer to Figure 13-90.
Figure 13-90 Wiring the mediation flow and Java components
1389
15.Click OK in the Add Wire and in the following Add Reference dialog boxes as
Figure 13-91 Add Reference dialog box
16.Right-click the Java component and select Generate Implementation as

Figure 13-92 Generate implementation for Java component
1390
17.In the Generate Implementation dialog box, select or create a new package
and click OK. Refer to Figure 13-93.
Figure 13-93 Generate Implementation dialog box
18.Insert the code shown in Figure 13-94 into the method

receivedSAP47_aufkDelivery().
Figure 13-94 Implement the method receivedSAP47_aufkDelivery()
1391
19.In the Assembly diagram, click the mediation component and select
Generate implementation (Figure 13-95). Click Yes in the Open dialog box.
Figure 13-95 Generate Implementation for the mediation flow component
20.Select the folder for the implementation, and click OK. Refer to Figure 13-96.
Figure 13-96 Select the folder for the implementation
1392
21.Connect the source and target operations, and wire the request to the invoke
node. Refer to Figure 13-97.
Figure 13-97 Mediation flow editor panel

23.Save and close the Java editor.
24.Save the Assembly Diagram. This rebuilds the project and removes any
errors. If there are any errors remaining, clean and rebuild the project
manually.
1393
13.5.4 Deployment
Deployment of the just developed module into the WebSphere Enterprise
Service Bus is fully supported by the IBM WebSphere Integration Developer
tooling. It creates all the artifacts and queue definitions.To deploy to WebSphere
Enterprise Service Bus, follow these steps:
1. In the WebSphere Integration Developer servers view right-click WebSphere
ESB Server v6.0 and select Add and remove projects. Refer to
Figure 13-98.
1394
2. Select ITSOSAPWebSphereAENApp in the Available projects pane, click

Add, and then Finish (Figure 13-99).
Figure 13-99 Add and remove projects finished dialog box
1395
4. Verify that the destinations were created as shown in Figure 13-100.
Figure 13-100 Administrative console bus destinations
1396

This section illustrates the execution and test of the created module in a
WebSphere Enterprise Service Bus test environment.
To test with WebSphere Integration Developer Test Client, follow these steps:
1. Right-click the ITSOSAPWebSphereAEN module, select Test Attach as
Figure 13-101 Test Attach ITSOSAPWebSphereAEN module
1397
2. In the test client window, click Continue. Refer to Figure 13-102.
Figure 13-102 ITSOSAPWebSphereAEN_test window
3. Make sure that WebSphere ESB Server v6.0 is selected, and click Finish.
Figure 13-103 Select deployment location dialog box
1398
4. Start the connector using the batch file startAdapter.bat that was created
earlier.
5. Log into SAP.
6. Navigate to the Create Maintenance Order transaction IW31.
7. Use the transaction to trigger a new MaintOrder.CREATE event
(Figure 13-104).
Figure 13-104 Create Maintenance Order to trigger event
Note: The order needs to be created correctly to produce the notification. One
way to do it is to find an existing valid maintenance order using transaction
code IW33 - order type PM01. Display detail, note functional location. In the
Central Header panel, complete the missing detailorder description and
cost.
You can confirm the event notification using the IBM WebSphere Business
Integration Station, Management tab, log, or current events functions.
Transactions /CWLD/DISPLAY_LOG or /CWLD/ED.
You can use WebSphere Business Integration: Archived Events (/CWLD/EM)
to resubmit previous event.
1399
8. The test client window is now showing the caught event (Figure 13-105).
Figure 13-105 Test client view after the event
13.5.6 Conclusion
Bus to process event notifications from SAP system using WebSphere Business
Integration Adapter or mySAP.com configured as SI Bus client. An application
was assembled to listen for an SAP event .Test client was used to display the
event data.
1400
13.6 Scenario B: WebSphere Business Integration

Adapter Advanced Event notification WebSphereMQ
This inbound scenario demonstrates how the WebSphere Enterprise Service
Bus can receive events from SAP application using the capability provided by the
ABAP Extension Module of the WebSphere Business Integration Adapter or
mySAP.com.

Figure 13-106 shows the system setup and the step-by-step flow.
WESB 6.0.1.2 (WAS 6.0.2.9)
SAP ERP 2004

1
WID 6.0.1.2
Testclient
WBI Adapter for

mySAP.com 6.0.5
Event
Notification
2
SCA
JMS
ITSOSAPWebSphereAEN
4
SI Bus
WMQ 5.3
ITSO_SAP_1/DELIVERYQUEUE
SCAAPPLICATIONesbCellBus
(XMTQ)
ITSO.IBM.1
ITSO.SAP.2
Figure 13-106 Scenario B operational model
The component that allows messages to be exchanged between a WebSphere
Application Server and a WebSphere MQ is WebSphere MQ link. To the
WebSphere MQ link engine, the WebSphere MQ queue manager appears to be
1401
a foreign bus. To the queue manager, the WebSphere MQ link engine appears to
be another WebSphere MQ queue manager. Figure 13-107 depicts the nature of
the configuration that needs to be performed. Refer to Table 13-5.
FOREIGN BUS: FB.QM01

WEBSPHERE MQ
BUS:BUS1
ALIASDEST (AQ1)
BUS1.TO.QM01
MQLINK (TO.QM01)
SEND
TARGID: LQ1@QM01
TARG.BUS: FB.QM01
S BUS1.TO.QM01
LOCAL DEST (Q1)
R QM01.TO.BUS1
R
LQ1
QM01.TO.BUS1
BUS1
(XMITQ)
R
= receiver channel
= sender channel
Figure 13-107 WebSphere MQ Link configuration

Table 13-5 WebSphere MQ Link configuration data
BUS1
FB.QM01
ItsoQmgr1
TO.QM01
TO.OtsoQmgr1
BUS1.TO.QM01
Bus1.2.ItsoQmgr1
QM01.TO.BUS1
ItsoQmgr1.2.Bus1
Q1, LQ1, AQ1
ITSO_SAP/REQUESTQUEUE
RQ1
ITSO_SAP/DELIVERYQUEUE
ITSO_SAP/RESPONSEQUEUE
1402
RQ1
RNAME (Q1)
RQMNAME (BUS1)
XMITQ (BUS1)
PUT
APPLICATION
APPLICATION
(QMGR:BUS1)
(QMGR:BUS1)
Configuring WebSphere MQ
To configure WebSphere MQ, follow these steps:
1. Define queue manager [ItsoQmgr1].
2. Define sender channel [ItsoQmgr1.2.Bus1].
3. Define receiver channel [Bus1.2.ItsoQmgr1].
4. Define transmission queue [SCA.APPLICATION.esbCell.Bus].
Important: The WebSphere MQ link receiver channel must have the same
name as its partner WebSphere MQ Sender channel, and vice versa.
5. Define the queues that are required by the adapter. The connector name is
ITSO_SAP. You can use the WebSphere MQ Explorer or the command line
with the configure_mq.bat script that is included with WebSphere Business
Integration Adapter or mySAP.com. Refer to Example 13-6.
Example 13-6 Configuring WebSphere MQ to be used with the scenario
C:\WebSphere\WBIAdapters\templates\configure_mq.bat ItsoQmgr1 MQ_SAP_Setup.txt
6. Paste the contents of Example 13-7 in the file .\MQ_SAP_Setup.txt.

Example 13-7 MQ_SAP_Setup.txt
****************************************************
* WebSphere MQ Link will require sender, and receiver channels
* First define the transmission queue for the sender channel.
****************************************************
DEFINE QLOCAL('SCA.APPLICATION.esbCell.Bus') USAGE(XMITQ)
*******************************************************
* Define the channel, channel type and transport method
* SI Bus uses port 5558 for embedded messaging by default
*******************************************************
DEFINE CHANNEL('ItsoQmgr1.2.Bus1') CHLTYPE(SDR)
XMITQ('SCA.APPLICATION.esbCell.Bus') CONNAME('localhost(5558)')
TRPTYPE(TCP)
DEFINE CHANNEL('Bus1.2.ItsoQmgr1') CHLTYPE(RCVR) TRPTYPE(TCP)
****************************************************
* Define the SAP ADAPTER QUEUES
****************************************************
DEFINE QLOCAL(ITSO_SAP/ADMININQUEUE)
DEFINE QLOCAL(ITSO_SAP/ADMINOUTQUEUE)
1403
DEFINE QREMOTE(ITSO_SAP/DELIVERYQUEUE) RNAME(ITSO_SAP/DELIVERYQUEUE)

RQMNAME('SCA.APPLICATION.esbCell.Bus')
XMITQ('SCA.APPLICATION.esbCell.Bus')
DEFINE QLOCAL(ITSO_SAP/REQUESTQUEUE)
DEFINE QREMOTE(ITSO_SAP/RESPONSEQUEUE) RNAME(ITSO_SAP/RESPONSEQUEUE)
RQMNAME('SCA.APPLICATION.esbCell.Bus')
XMITQ('SCA.APPLICATION.esbCell.Bus')
DEFINE QLOCAL(ITSO_SAP/CALLBACKQUEUE)
DEFINE QLOCAL(ITSO_SAP/FAULTQUEUE)
DEFINE QLOCAL(ITSO_SAP/SYNCHRONOUSREQUESTQUEUE)
DEFINE QLOCAL(ITSO_SAP/SYNCHRONOUSRESPONSEQUEUE)
Configuring MQ Link in WebSphere Application Server

Use the administrative console to complete the following steps:
1. To start the administrative console, first start WebSphere ESB Server v6.0.
Then, open WebSphere Integration Developer.
2. In the Servers view, select WebSphere ESB Server v6.0, then right-click and
open the administrative console.
1404
Adding a foreign bus

You need to add a foreign bus to define a routing definition type for a WebSphere
MQ queue manager. Follow these steps.
1. In the navigation pane, click Service integration Buses. A list of buses
displays in the content pane.
2. In the content pane, click the SCA.APPLICATION.esbCell.bus. Refer to
Figure 13-108.
Figure 13-108 Select bus
3. In the content pane, under Topology, click Foreign buses. A list of foreign
buses is displayed.
4. Click New to start the foreign bus definition wizard.
1405
5. Specify the following properties for the new foreign bus (Figure 13-109):
a. Name, [FB.ItsoQmgr1]
b. Description (optional)
c. Select Send allowed.
d. Click Next.
Figure 13-109 Foreign bus properties
1406
6. Select the Routing type for the foreign bus as Direct, WebSphere MQ Link.
Click Next. Refer to Figure 13-110.
Figure 13-110 Foreign bus routing definition type
7. Specify the Routing definition properties for the foreign bus (accept defaults).
Click Next. Refer to Figure 13-111.
Figure 13-111 Foreign bus routing definition properties
1407
8. Review the Summary. Refer to Figure 13-112. Click Finish to create the
foreign bus.
Figure 13-112 Foreign bus summary
9. Save your changes to the master configuration.
Creating a WebSphere MQ Link

To create a WebSphere MQ Link, follow these steps:
1. In the navigation pane, click Service integration Buses [Content
Pane] bus_name [Topology] Messaging engines engine_name
[Additional Properties] WebSphere MQ links.
2. In the content pane, click New to start a wizard and define the WebSphere
MQ Link:
a. Enter the Name of the new WebSphere MQ link.
b. Enter a Description for the WebSphere MQ link.
c. Select the name of the Foreign Bus that represents the WebSphere MQ.
d. Enter the [messaging-engine] Queue manager name, WebSphere MQ
uses it to address this service integration bus. The WebSphere MQ
transmission queue name must match it. Maximum 48 characters.
1408
e. Review the default values in the remaining fields on the panel, modify any
values as necessary. Refer to Figure 13-113. Click Next.
Figure 13-113 WebSphere MQ link properties
3. Define the WebSphere MQ link sender channel:

a. Enter the name of the Sender channel associated with this WebSphere
MQ link. Maximum 20 characters. This name must be the same as the
name of the partner receiver channel in the WebSphere MQ.
b. Enter the host name or address of the target queue manager in the
WebSphere MQ.
c. Enter the port number on which the queue manager is listening for the
inbound communication requests [defaults to 1414].
d. Select the transport chain [OutboundBasicMQLink].
1409
4. Review the default values in the remaining fields on the panel, and modify
any values as necessary. Refer to Figure 13-114. Click Next.
Figure 13-114 WebSphere MQ link sender channel
5. Define the WebSphere MQ link receiver channel.

a. Enter the name of the Receiver channel associated with this WebSphere
MQ link. Maximum 20 characters. This name must be the same as the
name of the partner sender channel in the WebSphere MQ network.
1410
b. Review the default values in the remaining fields on the panel, using the
field help in the Help pane to obtain more information about each field.
Modify any values as necessary. Refer to Figure 13-115. Click Next. Refer
to Figure 13-115. Click Next.
Figure 13-115 WebSphere MQ link receiver channel
1411
6. Check the Summary of WebSphere MQ link properties. Refer to

Figure 13-116 WebSphere MQ link summary
7. Save your changes to the master configuration.

8. Restart the application server.
1412
The WebSphere MQ link is now ready to send, receive, or exchange messages

with the WebSphere MQ network. Checking on the status of send and receive
channels must show their status as running. Refer to Figure 13-117 and
Figure 13-118.
Figure 13-117 Checking the status of MQ Link sender channel
Figure 13-118 Checking the status of MQ Link receiver channel
1413
Configuring the SAP adapter

To configure the SAP adapter, follow these steps:
2. Expand the Integration component library created in the preparation section,
right-click the tree Connectors, and click Create new connector as shown
in Figure 13-119.
Figure 13-119 Create new connector
1414
3. In the New Connector dialog box (Figure 13-120), follow these steps:
a. Enter ITSO_SAP_2 as the Name.
b. Select WAS in the System Connectivity droplist.
c. Select SAPConnectorTemplate from the Template Name list. Click OK.
Figure 13-120 New Connector dialog box
4. In the Connector Configurator/Standard Properties tab enter values from

Table 13-6. Refer to Figure 13-121.
Table 13-6 Adapter configuration data - standard
Property
Value
ApplicationName
WED
jms MessageBrokerName
ItsoQmgr1
jms Username
itsouser /required but not used
jms Password
password /required but not used
MessageFileName
SAPConnector.txt
RepositoryDirectory
C:\repository\ITSO_SAP
1415
Figure 13-121 Connector Configurator Standard Properties tab
1416
5. In the Connector-Specific Properties tab, enter values as listed in Table 13-7.

Table 13-7 Adapter configuration data - connector specific
Property
Value
ApplicationUserName
itsouser
ApplicationPassword
itso1
Modules
Extension
Client
800
Hostname
ITSO.SAP.2
Sysnr
00
Figure 13-122 Connector Configurator Connector-Specific Properties tab
1417
6. In the Supported Business Objects tab, select SAP47_aufk as shown in

Figure 13-123.
Figure 13-123 Connector Configurator Supported Business Objects tab
7. From File menu, save the connector configuration into the project. Refer to
Figure 13-124.
8. Save the connector configuration to file
c:\repository\export\ITSO_SAP\TSO_SAP_2.cfg.
Figure 13-124 Save connector
1418

To deploy WebSphere Business Integration artifacts, follow these steps:
2. Right-click User Projects WAS project and select New WebSphere
Application Server project as shown in Figure 13-125.
Figure 13-125 Create new user project
3. Name the project ITSO_SAP and select Available Integration Component

Libraries ITSO_SAP_ICL as shown in Figure 13-126. Click Finish.
Figure 13-126 New user project dialog box
1419
4. Right-click the created project and select Deploy WebSphere Application

Server project as shown in Figure 13-127.
Figure 13-127 Deploy WebSphere Application Server project
5. Choose only to generate the representation for the AgentDelivery operation

because only this operation is used. Refer to Figure 13-128. Click Next.
Figure 13-128 Deploy wizard- component selection page
1420
6. Choose to export the artifacts to a dedicated directory, for example,

C:\repository\export\ITSO_SAP, as shown in Figure 13-129. Click Finish.
Figure 13-129 Deploy wizard destination selection page
The directory includes the following files after the export procedure:
ITSO_SAP_2.cfg
ITSO_SAP_2.wsdl
ITSO_SAP_2JMSBindings.wsdl
ITSO_SAP_2JMSService.wsdl
Creating a batch file on the desktop, which starts the

connector
Enter the line shown in Example 13-8 in the batch file.
Example 13-8 startAdapter2.bat
C:\websphere\WBIAdapters\connectors\SAP\start_SAP.bat WED WAS

-cC:\repository\export\ITSO_SAP\ITSO_SAP_2.cfg
To start the connector, execute the batch file. To stop the connector, enter q in
the open connector DOS box.
1421
13.6.3 Development
1. Switch to WebSphere Integration Developer.
2. In the Business Integration view, right-click to bring up the context menu.
Select New Mediation Module as shown in Figure 13-130.
Figure 13-130 Create new mediation module
1422
3. Enter ITSOEAPWebSphereAEN in the Module Name, accept WebSphere ESB

Server v6.0 as Target Runtime, select Create mediation flow component
as shown in Figure 13-131. Click Finish.
Figure 13-131 New mediation module dialog box
1423
4. Right-click the ITSPSAPWebSphereAEN module, and click New Other

Enterprise Service Discovery, and click Next as shown in Figure 13-132.
Figure 13-132 New enterprise service discovery
5. Select WBI Adapter Artifact Importer, and click Next as shown in

Figure 13-133.
Figure 13-133 ESD wizard resource adapter dialog box
1424
6. In the Configure Settings for Discovery Agent dialog box, browse for the
Connector configuration file, and Business object schema directory as
created in the previous steps. Click Next. Refer to Figure 13-134.
Figure 13-134 ESD wizard settings for discovery agent dialog box
7. In the Find and Discover Enterprise Services dialog box, click Run Query.
Figure 13-135 ESD wizard find and discover service dialog box - Run Query
1425
8. Select the discovered object SAP47_aufk and click Add. Refer to

Figure 13-136.
Figure 13-136 ESD wizard find and discover service dialog box - Add
9. In the Configuration Parameters dialog box, clear all but the

receivedSAP47_aufDelivery check box and click OK as shown in
Figure 13-137.
Figure 13-137 Configuration parameters for discovered object
1426
10.This completes the Find and Discover Enterprise Services dialog box, click
Next. Refer to Figure 13-138.
Figure 13-138 Completed ESD wizard find and discover service dialog box
11.Specify the folder for the artifacts that will be generated and click Finish.
Figure 13-139 ESD wizard generate articles dialog box
1427
12.Open the Assembly Diagram editor. Refer to Figure 13-140.
Figure 13-140 Assembly diagram editor
1428
13.Wire the WEDDeliveryHub export to the mediation flow component

Mediation1 as shown in Figure 13-141.
Figure 13-141 Wiring the export and mediation flow components
14.Create new Java component, and wire the mediation flow component to the
Java component. Refer to Figure 13-142.
Figure 13-142 Wiring the mediation flow and Java components
1429
15.Click OK in the Add Wire and in the Add Reference dialog boxes. Refer to
Figure 13-143.
Figure 13-143 Add Reference dialog box
16.Right-click the Java component and select Generate Implementation. In the

Generate Implementation dialog box, select or create a new package and
click OK. Refer to Figure 13-144.
Figure 13-144 Generate Implementation dialog box
1430
17.Insert the code shown in Figure 13-145 into the method

receivedSAP47_aufkDelivery().
Figure 13-145 Implement the method receivedSAP47_aufkDelivery()
1431
18.In the assembly diagram, click the mediation component, and select
Generate implementation. Refer to Figure 13-146.
.
Figure 13-146 Generate Implementation for the mediation flow component
19.Select folder for the implementation, and click OK. Refer to Figure 13-147.
1432
20.Connect the source and target operations, and wire the request to the invoke
node. Refer to Figure 13-148.
Figure 13-148 Mediation flow editor panel

22.Save and close the Java editor.
23.Save the Assembly Diagram. This rebuilds the project and removes any
errors. If there are any errors remaining, clean and rebuild the project
manually.
1433
13.6.4 Deployment
Deployment of the just developed module into the WebSphere Enterprise
Service Bus UTE is fully supported by tooling. It creates all the artifacts and
queue definitions. (AEN does not use any request queue, so there is no need to
define any alias for it).
To deploy to WebSphere Enterprise Service Bus, follow these steps:
1. In the WebSphere Integration Developer servers view right-click the
WebSphere ESB Server v6.0 and select Add and remove projects as
1434
2. Select ITSOSAPWebSphereAENApp in the Available projects pane, click

Add, and then Finish as shown in Figure 13-150.
Figure 13-150 Add and remove projects finished dialog box
1435
4. Verify that the destinations were created as shown in Figure 13-151.
Figure 13-151 Administrative console bus destinations
1436

This section illustrates the execution and test of the created module in a
WebSphere Enterprise Service Bus test environment.
To test with WebSphere Integration Developer Test Client, follow these steps:
1. Right-click the ITSOSAPWebSphereAEN module, select Test Attach as
Figure 13-152 Test Attach ITSOSAPWebSphereAEN module
1437
2. In the test client window click Continue as shown in Figure 13-153.
Figure 13-153 ITSOSAPWebSphereAEN_test window
3. Make sure that WebSphere ESB server v6.0 is selected, and click Finish as
Figure 13-154 Select deployment location dialog box
1438
4. Start the connector using the batch file startAdapter.bat created earlier.
5. Log into SAP.
6. Navigate to the Create Maintenance Order transaction IW31.
7. Use the transaction to trigger a new MaintOrder.CREATE (Figure 13-155).
Figure 13-155 Create Maintenance Order to trigger event
Note: The order needs to be created correctly to produce the notification. One
way to do it is to find an existing valid maintenance order using transaction
code IW33 - order type PM01. Display detail, note functional location. In the
Central Header panel, complete the missing detailorder description and
cost.
You can confirm the event notification using the IBM WebSphere Business
Integration Station, Management tab, log, or current events functions.
Transactions /CWLD/DISPLAY_LOG or /CWLD/ED.
You can use WebSphere Business Integration: Archived Events (/CWLD/EM)
to resubmit previous event.
1439
The test client window now shows the caught event. Refer to Figure 13-156.
Figure 13-156 Test client view after the event
13.6.6 Conclusion
Bus to process event notifications from SAP system using WebSphere Business
Integration Adapter or mySAP.com configured as MQ Client. WebSphere MQ
was configured as a foreign bus. The scenario assembled an application to listen
for an SAP event and used the test client to display the event data.
1440
Appendix A.
Additional material
This book refers to additional material that you can download from the Internet as
described in this appendix.
1441
Locating the Web material

The Web material that is associated with this book is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG247220
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the book form number, SG247220.
Using the Web material

The additional Web material that accompanies this book includes the following
files:
File name
All.zip
Ch6, Scenario A.zip
Ch6, Scenario B.zip
Ch6, Scenario C.zip
Ch7.zip
Ch11.zip
Description
All compressed files
Scenario A - ESB-to-SAPXI
Scenario B - WAS-to-SAPXI
Scenario C - SAPXI-to-ESB
Scenarios for chapter 7
Scenarios for chapter 11
How to use the Web material

Create a subdirectory (folder) on your workstation, and extract the contents of
the Web material compressed file into this folder.
1442
Glossary
Administration Console_The IBM Administrative
Console is the Web interface to the Application
Server, Process Server, or Enterprise Service Bus.
It offers powerful options for configuration and
deployment.
Bar file_Abbreviation for message broker archive
file, used to store compiled message flows,
message sets and other code to be deployed to an
execution group.
binding_Defines the kind of interaction as well as
the caller and sender. It could be used to connect
different SCA Modules together.
BIP message_An event message produced by
WebSphere Message Broker, identifiable by its BIP
number, for example BIP1003.
BO_A Business Objects are representations of data
structure used in business processes.
BPEL_The Business Process Execution Language
is a open standard to store process definitions in a
file.
Breakpoint_Used as a point to stop the flow of a
message in a message flow when the flow debugger
is attached.
Broker_A broker is a set of execution processes
that host and run message flows.
Broker Administration perspective_This is the
perspective in the Message Brokers Toolkit which is
used for administering and monitoring objects in the
broker domain. This perspective is also used for
changing the configuration and message flow
deploy operations.
Broker Application Development

perspective_This is the perspective in the Message
Brokers Toolkit in which message flows and
message sets can be developed.
Broker database_A database that stores
configuration for a broker. Multiple brokers can
share the same database.
Broker Domain_A group of brokers that share a
common configuration and managed by a single
Configuration Manager.
bus_A bus provides the possibility to transfer data
between different nodes connected to this bus.
Business Process_A business Process defines a
flow of actions to solve a special task. It could be
stored in a BPEL file.
Compute node_A node in a message flow for
processing messages using ESQL. Usually used for
message transformation.
Configuration Manager_The Configuration
Manager stores the configuration data for the broker
domain that it manages, and performs the
deployment operations between the Message
Broker Toolkit and the brokers in the domain.
DB2 Enterprise Server_A database which is
supported for use as a broker database and is
supplied with WebSphere Message Broker.
Domain connection_A reference to a broker
domain in the Message Brokers Toolkit.
ESQL_ESQL is Extended Structured Query
Language and is used in the transformation of
messages in message flows. It is also used to
perform database operations such as querying or
updating a database.
1443
Execution groups_An execution group represents

a collection of message flows within a broker.
Foreign bus_Connect different buses together by
configuration. Extending a bus network in this way
enables all the buses in the network to exchange
messages.
Message Domain_The Message Domain is a

property that can be set on an input node to indicate
the type of message that the flow expects to
process, and selects the appropriate parser for the
flow to use. Examples are XML and MRM.
HTTPInput node_A node in a message flow that

used to receive a Web Services request. Must be
used in conjunction with a HTTPReply node.
Message Engine_A messaging engine is a

component, running inside a server, that manages
messaging resources for a bus member.
Applications are connected to a messaging engine
when accessing a service integration bus.
HTTPReply node_A node in a message flow that

returns a response from a message flow to a Web
Service client.
Message Flow editor_An editor within the Message

Brokers Toolkit for creating message flows by
adding and connecting nodes on a canvas.
Inbound_WebSphere versus SAP Exchange

InfrastructureI terminology
Message flows_Message flows provide the logic

used by the broker to process messages. Message
flows are built from nodes programmed with basic
logic.
Java Snippet_A small part of a program code

written in JAVA.
JCA_The Java Connector Architecture a Java
based technology solution for connecting application
servers and enterprise information systems.
Message sets_Message sets contain definitions of

messages to be processed by the broker. These
message definitions contain information about the
logical and physical structure of the messages.
Mapping_A method of message transformation

using drag-and-drop from references to message
definitions and database definitions.
MQGet node_A node in a message flow that can be

used anywhere in a flow to retrieve a message from
a WebSphere MQ queue.
Mediation_Mediation defines a mapping with

advanced actions. A mediation can reorder and
reformat every input so that the target systems get
the needed items with the right name and value.
MQInput node_A node in a message flow used to

receive messages from clients that connect to the
broker using the WebSphere MQ Enterprise
Transport, and that use the MQI and AMI Application
Programming Interfaces. The MQInput node
receives message input to a message flow from a
WebSphere MQ message queue.
Mediation Flow_Defines the mediation step by

step. It could include XSL transformations as well as
custom transformation via Java snippets.
Message Brokers Toolkit_A graphical user
interface for performing the development and
debugging of message flow applications. It is also
used for administering WebSphere Message Broker
components and deploying message flow
applications.
1444
MQOutput node_A node in a message flow used to

send messages to clients that connect to the broker
using the WebSphere MQ Enterprise Transport and
that use the MQI and AMI Application Programming
Interfaces. The MQOutput node delivers an output
message from a message flow to a WebSphere MQ
queue.
node_A node is a logical unit in a server

environment. a cluster consists out of connected
nodes working together as one logical unit.
Outbound_WebSphere versus SAP Exchange
Infrastructure terminology.
Output node_A node in a message flow that
provides an out terminal for a subflow.
Queue manager_A queue manager is a system
program that provides queuing services to
applications. It is used to enable communication
between the WebSphere Message Broker
components, each component requires access to a
Queue Manager.
Rational Agent Controller_The Rational Agent
Controller is used for message flow debugging in the
Message Brokers Toolkit. It must be installed on the
same machine as the broker being debugged.
SAP WebAS_An application server from SAP which
is also included in different products as a common
basement.
SCA_The service component architecture is the
base for a service-oriented architecture because the
different services could be easily connected to
solutions.
SCA component_A part of an SCA module which
has a specific functionality. They could be
assembled to a meaningful service.
SCA Export_An possibility to provide a interface
which could be called by other SCA modules via an
import.
SCA Import_An possibility to call a interface of an
other SCA module which is provided via an export.
SCA Module_A logical unit of different SCA
compounds building a service.
SDO_The Service Data Object is a data
representation mostly used to connect to a
enterprise information system. It caches the data so
that the consumer do not have to care about
interacting with the EIS directly.
SI Bus_is a logical entity based on the physical

implementation of a Message Driven Bean, there is
no inherent high availability or workload
management functionality.
SMO_A service message object provides an
abstraction layer for processing and manipulating
messages exchanged between services.
Terminal_Each node in a message flow has a
number of terminals. Messages are output to
different terminals on a node depending upon the
results of processing in the node.
WebSphere Application Server_A very powerful
application server offered from IBM. It is also
included as a powerful foundation in other products
like WebSphere Portal, WebSphere Process Server.
WebSphere Event Broker_Used for the distribution
and routing of messages from disparate
applications. Is often used for publish/subscribe
messaging.
WebSphere Message Broker_Provides storage,
transformation and enrichment of data in addition to
the functionality provided by WebSphere Event
Broker.
WebSphere MQ_A messaging application which
enables the Message Brokers Toolkit, Configuration
Manager, and brokers to communicate. WebSphere
MQ provides many of the available transport
protocols between business applications and
message flows.
WebSphere MQ Explorer_A graphical user
interface for WebSphere MQ for administering
WebSphere MQ components such as queue
managers, channels and queues.
Windows Event Viewer_A Windows tool for
viewing the contents of the Application and System
logs.
Wire_A connection between SCA components in an
SCA module. The wire always connect Reference to
interface.
Glossary
1445
WebSphere Process Server_A state of the art

Business Process execution environment.
1446
Abbreviations and acronyms

ABAP
Application Server invoking

SAP WebAS
HDR
Hierarchical Dynamic
Retrieve
ALE
Application Link Enabling
HTTP
Hypertext Transfer Protocol
APIs
Application Programming
Interfaces
IBM
International Business
Machines Corporation
BAPI
Business Application
Programming Interface
ICM
Internet Communication
Manager
BI
Business Intelligence
IDE
BO
Business Objects
integrated development
environment
BOR
Business Object Repository
IDOC
Intermediate Document
BPC
Business Process Container
IBM SICC
BPEL
Business Process Execution

Language
IBM SAP International

Competence Center
ITSO
BPM
Business Process
Management
International Technical
Support Organization
J2C
Java 2 Connector
BSP
Business Server Pages
J2EE
Java 2 Enterprise Edition
CAF
Composite Application
Framework
JCA
J2EE Connector Architecture
JCo
Java Connector
CBE
Common Base Event
JDO
Java Data Objects
CCMS
Computing Center
Management System
JMS
Java Message Service
JSP
JavaServer Page
CEI
Common Event Infrastructure
JSPs
JavaServer Pages
CMP
Container-managed
persistence
KM
Knowledge Management
CTSC
Collaboration Technology
Support Center
KPIs
key performance indicators
LS
Logical System
Enterprise application
integration
LUW
Logical Unit of Work
MATMAS
Message Type
EAR
Enterprise application archive
MDM
Master Data Management
EIS
Enterprise information
systems
ODA
Object Discovery Agent
PMI
Process Monitoring
Infrastructure
EAI
EJB
Enterprise JavaBeans
ERP
Enterprise Resource Planning
QoS
Quality of Service
ESB
RAD
GUI
graphical user interface
Rational Application
Developer
1447
RFC
Remote Function Call
RFM
Remote callable function

modules
SCA
Service component
architecture
SDO
Service Data Objects
SIB
Service Integration Bus
SIP
supports Session Initiation

Protocol
SLD
System Landscape Directory
SMO
Service Message Object
SMTP
Simple Mail Transport

Protocol
SOA
Service-oriented architecture
SQL
Structured Query Language
SSL
Secure Socket Layer
TCP
TRPTYPE
UDDI
Universal Description,
Discovery, and Integration
WebAS
Web Application Server
WSDL
Web Services Description

Language
WSIL
Web Services Inspection

Language
XML
Extensible Markup Language
XSD
XML Schema Definition
XSLT
XSL transformation
1448
Related publications
We consider the publications that we list in this section particularly suitable for a
more detailed discussion of the topics that we cover in this book.
IBM Redbooks publications

For information about ordering these publications, see How to get IBM
Redbooks publications on page 1451. Note that some of the documents that we
reference here might be available in softcopy only.
WebSphere Application Server V6.1: Technical Overview, REDP-4191
http://www.redbooks.ibm.com/redpieces/abstracts/redp4191.html?Open
Getting Started with WebSphere Enterprise Service Bus V6, SG24-7212
Integration Developer, REDP-4041
http://www.redbooks.ibm.com/abstracts/redp4041.html?Open
Patterns: Building Serial and Parallel Processes for IBM WebSphere Process
Server V6, SG24-7205
WebSphere Business Integration for SAP, SG24-6354
WebSphere Message Broker Basics, SG24-7137
Integration Developer, REDP-4041
Patterns: Serial and Parallel Processes for Process Choreography and
Workflow, SG24-6306
1449
Online resources
These following are also relevant as further information sources:
Detailed information about IBM WebSphere products is available at:
http://www.ibm.com/software/websphere
You can find a huge collection of material at IBM Developer Works:
http://www.ibm.com/developerworks/websphere
WebSphere Message Broker V6.0 online documentation is available at:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?to
pic=/com.ibm.etools.mft.doc/ah24100_.htm
High availability document for WebSphere Message Broker is available at:
http://www-128.ibm.com/developerworks/websphere/library/techarticles
/0403_humphreys/0403_humphreys.html
WebSphere Message Broker requirements
http://www-306.ibm.com/software/integration/wbimessagebroker/require
ments/
Configuring dynamic authentication in WebSphere Adapter for SAP
http://www-128.ibm.com/developerworks/websphere/library/techarticles
/0608_martinez/0608_martinez.html
SupportPacs
http://www.ibm.com/software/integration/support/supportpacs
1450
How to get IBM Redbooks publications

You can search for, view, or download IBM Redbooks, Redpapers, Hints and
Tips, draft publications and Additional materials, as well as order hardcopy IBM
Redbooks or CD-ROMs, at this Web site:
ibm.com/redbooks
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
Related publications
1451
1452
Index
A
ABAP extension module 117
ABAP transports 117
ABAP workbench function builder 63
abstract message interface 215
adapter based communications 5
adapter engine 66
adapter type 183
ALE (Application Link Enabling) 7, 5153, 77, 109,
111, 113114, 116, 119, 139, 825, 833, 880, 882,
904, 912, 959, 1159, 11611162, 1182, 1236, 1258,
1283, 1302
ALE distribution model 113114, 116, 119
ALEAUD 139
APIs (Application Programming Interfaces) 53
application link enabling 825
Application Link Enabling (ALE) 7, 5153, 77, 109,
111, 113114, 116, 119, 139, 825, 833, 880, 882,
904, 912, 959, 1159, 11611162, 1182, 1236, 1258,
1283, 1302
Application Programming Interfaces (APIs) 53
assemble 19
assembly diagram 534
assembly editor 355
asynchronous 231
B
BAPI 7, 5152, 6364, 75, 332, 383, 438, 778, 851,
951, 970, 1005, 1047, 1083, 1117, 1182
BAPI logical unit of work 953
BapiUserExistenceCheckQuery_MT.xsd 535
BapiUserExistenceCheckResponse_MT.xsd 535
BD10 901
BD64 834
BO (Business Objects) 344
BPC Explorer 625, 646, 777, 852, 873874, 1139,
1155
BPEL (Business Process Execution Language) 54
BPM (Business Process Management) 19
broker 46, 676
broker administration navigator 683
broker archive 726
broker domain 676
BSCCLIENT800 835
Business Application Programming Interface (BAPI)
7, 5152, 6364, 75, 332, 383, 438, 778, 851, 951,
970, 1005, 1047, 1083, 1117, 1182
business event producer 121
business integration perspective 332
business integration view 337
business landscape 156
Business Object editor 413
Business Object maps 45
Business Objects (BO) 344
Business Process Choreographer Explorer (BPC
Explorer) 625, 646, 777, 852, 873874, 1139, 1155
business process editor 453
business process engine 67
business process execution 5
Business Process Execution Language (BPEL) 54
Business Process Management (BPM) 19
business systems 68
C
callout response node 431
CBE 42
CCMS 69
CEI 42
central integration broker 15
channels folder 516
child nodes 360
cloudscape database 623
cloudview 623
CMP (Container Managed Persistence) 62
collaboration knowledge 65
Common Base Event (CBE) 42
Common Event Infrastructure (CEI) 42
commonj.sdo.DataObject 25
communication patterns 5
compiler 26
computational paradigm 676
Computing Center Management System (CCMS)
69
condition editor 205
configuration 66
configuration manager 48, 676
1453
configured inbound interfaces 185

connection management 50
connection name 517
Container Managed Persistence (CMP) 62
context root 377
contract 673
control record 63
conversationID 267
correlation bridge 102
CorrHeader 287
create mediation flow component 407
create queues in WebSphere MQ 520
creating SCA export 442
custom selector 498
D
data graph 26
data object 25
data record 63
data types 344
dead letter queue 678
default messaging provider window 531
delta 685
deploy 20
deployment descriptor 399
design 66
integration builder 163
development tools 29
direct connectivity 14
distribution engine 65
document style 791
doGet method 897
doPost method 896
dynamic retrieve 117
dynamic transactions 117
E
EAI 64
EAR 50, 56, 377, 1184
EAR project 377
eclipse 47
edit interface mapping 177
EIS 12, 1416, 4951, 112114, 1194
EJB binding 43
emulators 555
enhanced event notification 120
Enterprise Application Archive (EAR) 50, 56, 377,
1184
1454
enterprise application integration (EAI) 64

enterprise information systems (EIS) 12, 1416,
4951, 112114, 1194
Enterprise Resource Planning (ERP) 6
enterprise resource planning (ERP) 35, 61,
108121, 123, 133135, 140141, 329, 404, 461,
497, 1004
Enterprise Service Bus (ESB) 5
ERP 35, 61, 108121, 123, 133135, 140141,
329, 404, 461, 497, 1004
ERP (Enterprise Resource Planning) 6
ESB (Enterprise Service Bus) 5
ESB2XI_Request 525
ESB2XI_Request JMS queue 531
esbNode
server1 524
esbNode.server1-SCA.APPLICATION.esbCell.Bus 507
event notification 50
export component 543
export node 89
exports 43
F
file system 534
foreign bus 498
function builder 434
G
generic Web service client 392
getUserList 583
governance and processes 36
H
HDR (Hierarchical Dynamic Retrieve) 138, 953
Hierarchical Dynamic Retrieve (HDR) 138, 953
HTTP request node 92
I
IBM rational application developer 35
IBM SOA Reference Architecture 33
IBM SOA reference architecture 3637
IBM support assistant 41
IBM WebSphere adapter 49
IBM WebSphere application server 35
IBM WebSphere business monitor 36
IBM WebSphere enterprise service bus 35
IBM WebSphere integration developer 35

IBM WebSphere message broker 35
IBM WebSphere MQ 35
IBM WebSphere portal 36
IBM WebSphere portlet factory 35
IBM WebSphere process server 36
IDE (Integrated Development Environment ) 55
IDocs (Intermediate Documents) 63
immediate response node 811
import component 543
import node 86
imports 43
inbound interface 261
inbound processing 52
inbound scenarios 145
infrastructure intelligence 13
input nodes 675
Input Response node 431
InputRoot 763
Integrated Development Environment (IDE) 55
integration brokers 5
integration builder 65
configuration 68
design 68
integration developer 114
integration directory 65
integration engine 66
integration logic 12
integration repository 65
integration scenario 190
interface editor 351
interface editor pane 537
interface mapping 261
interface mappings 147
interface maps 45
Intermediate Documents (IDocs) 63
invoke node 359
ITSO_ESB 150, 159, 165, 167, 180, 184185, 187,
191, 201, 204205, 207, 209, 212, 217218, 235,
241242, 244, 246248, 265, 270, 289, 292, 294,
297299, 301304
Itso_ForeignBus 525
ITSO_SAP_ECC 150, 162, 165, 167, 182,
184185, 187, 191, 201202, 205, 207209,
212213, 217, 232, 239, 243, 245, 247248, 254,
258, 260, 262, 265266, 270, 289290, 297, 300,
303, 307, 314, 317, 320
ItsoConnection 677
ITSOSAPXI_WS_Lib 336, 339, 439, 464465, 467,
471
ItsoSoapSenderChannel 181
J
J2EE 28, 39, 49, 56, 6061
Java 22, 2427, 29, 5152, 5556, 6162, 66, 68
Java 2 Enterprise Edition (J2EE) 28, 39, 49, 56,
6061
Java 2 Enterprise Edition Connector architecture
(JCA) 49
Java class libraries 26
Java client 903, 941
Java Data Objects (JDO) 62
Java Database Connectivity (JDBC) 62
Java Message Service (JMS) 41, 48, 50, 75, 77,
98103, 105, 107, 117, 119, 131132, 145, 685,
739
Java platform 28
Java Platform Micro Edition (Java ME) 28
Java Platform Standard Edition (Java SE) 28
Java Runtime Environment (JRE) 29
Java SDK 29
Java snippet 922
Java Software Development Kit (Java SDK) 29
Java Virtual Machine (JVM) 29
JavaServer Page (JSP) 25, 61
JCA 49
JCA adapters 49
JDO 62
JMS 41, 48, 50, 75, 77, 98103, 105, 107, 117,
119, 131132, 145, 685, 739
JMS Adapter 130
JMS adapter 98104, 106, 131
JMS API 98103, 105, 107, 130131
JMS binding 43, 103, 115118, 120, 130
JMS connection factory 530
JMS consumer 146, 213, 495
JMS export 498
JMS invocation 80
JMS libraries 130131
JMS outbound scenarios 210
JMS protocol 130131
JMS provider 54, 99100, 102107, 130132, 141,
495
JMS request messages 132
JMS transport layer 50
JMSCorrelationID 267
JNDI Lookup Name 551
Index
1455
JRE 29
JSP 61
JSP (JavaServer Page) 25
JVM 29
K
key performance indicators (KPIs) 36
methods 27
model 19
MQ client link 77
MQInput 675
MQInput node 675
MQOutput node 675
MQOutputNode 102
multiple BAPI call 953
MyAsynchJmsToSynchRfcBridge 213
L
library 335
library name 533
listen on port number 514
load balancing 48
logging primitive 623
logical messages 63
logical routing rules 147
Logical Unit of Work 1047
Logical Unit of Work (LUW) 137
M
manage 20
mapping editor 364
markup language 397
master configuration 504
master repository 504
mediation base 42
mediation flow components 43
mediation flow editor 357
mediation flows 45
mediation functions 42
mediation layer 42
mediation logic 796
mediation module 129
mediation primitives 43
mediations 42
message brokers toolkit 676
message consumer 98
message definition file 676
message emitter 107
message flow 93, 675
message logger 591
message producer 98
message queuing infrastructure 29
message set 676
messaging backbone 107
messaging engine 505
messaging patterns 5
1456
N
new interface definition 536
Node
esbNode 530
O
object definition 51
Object Discovery Agent (ODA) 53
Object Discovery Agent Development Kit (ODK) 54
object key 69
object-oriented language 27
ODA (Object Discovery Agent) 53
open dependency editor 444
outbound 145
outbound processing 52
outbound scenarios 145
output nodes 675
OutputRoot 763
P
PASSTHRU 763
path reference 490
port 3414 514
Process Monitoring Infrastructure (PMI) 69
programming language 27
properties hierarchy 691
Q
quality of service 13
queue manager clusters 30
queue manager name 509
R
Rational Application Developer (RAD) 128
rational software development platform 47
receiver agreement 187
receiver channel 516
Receiver MQ channel name 512

Redbooks Web site 1451
Contact us xxix
reference symbol 806
relationships 45
remote function modules 88
ReplyTo Queue 102
ReplyTo queue 103
request flow 547
RequestTF primitive 359
resource adapters 49
response flow 547
RFC (Remote Function Call) 51
RFC client parameter 183
runtime 66
runtime workbench 69
S
SAP API function call 970
SAP exchange infrastructure 83
SAP Exchange Infrastructure (XI) 128
SAP Java Connector (SAP JCo) 51
SAP JCo installation
librfc32.dll 954
msvcp71.dll 954
msvcr71.dll 954
sapjco.jar 954
sapjcorfc.dll 954
SAP NetWeaver 58
SAP NetWeaver Architecture 33
SAP Web Application Server 82
SAP XI configuration 331
SCA (Service component architecture) 23
SCA binding 43
SCA.APPLICATION.esbCell.Bus 500, 522
SDO (Service Data Objects) 23
SE80 778
selectors 45
sender agreement 186
sender channel 516
serialization 549
Service component architecture (SCA) 23
service component architecture module 8687
Service Data Objects (SDO) 23
Service Integration Bus (SIB) 8
Service Message Object (SMO) 42
service references 25
service-oriented architecture (SOA) 4, 14, 20, 23,
3334, 38, 41, 4445, 5456

Session Initiation Protocol (SIP) 40
SIB (Service Integration Bus) 8
single BAPI call 953
SIP (Session Initiation Protocol) 40
SLD (System Landscape Directory) 67
SM59 209
SMO (Service Message Object) 42
SOA 4, 14, 20, 23, 3334, 38, 41, 4445, 5456
SOA core 45
SOA Foundation 4, 34, 37
SOA integration platform 43
SOA life cycle 4, 19, 3435
SOA reference architecture 3637
SOAP 22, 48, 62, 64, 130131, 133, 135, 145, 191,
323, 327, 775, 777, 824, 851, 903, 919, 922, 934
SOAP adapter 81, 86, 89, 92, 95, 127129
SOAP bridge 877
SOAP response message 687, 725
SOAP server 22
SOAP system response queue 921
software catalog 151
source tree 360
SQL (Structured Query Language) 676
stand-alone references 25
standard based communications 5
status records 63
Structured Query Language (SQL) 676
SupportPacs 30
SynchRfcToAsynchJmsBridge. 268
synchronous call 970
system landscape directory 148
System Landscape Directory (SLD) 67
T
tagged delimited strings 676
target bus 525
target identifier 526
target runtime 539
target tree 360
technical landscape 155
technical system browser 155
technical systems 68
test client 332
testing 402
text editor 624
third-party systems 68
topology configuration deploy 685
Index
1457
transformation nodes 675

transmission queue 515
transport protocol 237
U
Universal Description, Discovery, and Integration
(UDDI) 22
User ITSOUSER 375
User UNKNOWN 376
UserExist_JMSImport 543
UserExistenceIF 354
UserList_JMSMediationFlow 585
UserListInterface 594
UserListResponseBO 580
useroutput 584
userQueryResponse 537
V
validation error 490
virtual interface 778
virtual queue manager 509
visual mapping editor 810
W
Web Service calls 134
Web Service client 82
Web Service consumer. 86
Web Service creation wizard 64
Web Service provider 82
Web Services 21
Web Services binding 43
Web Services Description Language (WSDL) 22
Web Services invocation 80
WebApplication Server (WebAS) 6
WebSphere adapter binding 43
WebSphere administration console 531
WebSphere application server network deployment
42
WebSphere Business Integration Adapter adapter
77
WebSphere Business Integration Adapter Advanced Event notification
SIBus 1371
WebSphereMQ 1371
WebSphere Business Integration Adapter for
mySAP.com) 834, 884, 913
WebSphere business modeler 55
1458

execution of a multiple BAPI call 970
execution of a single BAPI call 970
execution of a transactional BAPI call 970
WebSphere enterprise service bus 330
WebSphere ESB
batch SAP IDOC
conclusion 1258
deployment 1258
development 1258
execution and test 1258
operational model 1258
Read Table RFC
conclusion 1082
deployment 1082
development 1082
single SAP IDOC
conclusion 1236
deployment 1236
development 1236
WebSphere integration developer toolkit 329
WebSphere interchange server 38
WebSphere message broker 96
WebSphere message broker project 94
WebSphere message broker toolkit 47
WebSphere MQ 934, 941
WebSphere MQ link 502
WebSphere MQ workflow 38
WebSphere process server 331
WebSphere Process Server deployment
inbound ALE 1283
outbound ALE 1283
wiring the components 429
wiring tool 355
workbench request 781
WSADMIN 791
WSDL (Web Services Description Language) 22
WSDL Port type 24
WSIL (Web Services Inspection Language) 22
X
XML (Extensible Markup Language) 21
XML Namespace 276
XML Schema Definition (XSD) 55
XSD (XML Schema Definition) 55

XSL transformation primitive 358
Index
1459
1460
Connect WebSphere
Service-Oriented
Middleware to SAP
(2.5 spine)
2.5<->nnn.n
1315<-> nnnn pages
Back cover
Connect WebSphere
Service-Oriented
Middleware to SAP
Business
connectivity using
WebSphere
Enterprise Service
Bus, Process Server,
and Message Broker
Integration
scenarios using open
standards and
WebSphere Adapters
Common
broker-to-broker
and direct
communication
patterns
Over years, the typical IT infrastructure grows and is very likely a

collection of separated, heterogeneous environments that can
collide with todays requirement for companies to react quickly
to changing business needs. This changing environment
demands a middleware that is both robust and extensible as
well as flexible when reacting to change.
With WebSphere Middleware products from IBM you can
operate flexible service-oriented architectures that overcome
these integration challenges. The IBM WebSphere
Service-Oriented Middleware product suite includes different
integration brokers and a multitude of application and
technology adapters. In addition to the adapter-based
integration approach, this product suite supports a wide range
of open standards to connect any back-end component in a
service-like manner to the middleware infrastructure.
This book highlights broker-to-broker connectivity to the SAP
Exchange Infrastructure as well as direct communication
patterns to the SAP WebApplication Server. This book also
illustrates how to integrate data and processes that are located
in SAP back-end systems that use IBM Service-Oriented
Middleware technology. The adapter-based scenarios use the
WebSphere adapters for SAP, and the standards-based
integration scenarios use the Web Services and Java Message
Service capabilities that are built in to the products of both IBM
and SAP.
SG24-7220-00
ISBN 0738486205
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks

SG 247220

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SG 247220

Enviado por

Direitos autorais:

Formatos disponíveis

Front cover

International Technical Support Organization

WebSphere Application Server

IBM WebSphere Enterprise

IBM WebSphere Enterprise

IBM WebSphere Process Server

IBM WebSphere Process Server

IBM WebSphere Message Broker

IBM WebSphere Business

IBM WebSphere Adapter for SAP

SAP ERP 2004

First Edition (May 2007)

Copyright International Business Machines Corporation 2007. All rights reserved.

Copyright IBM Corp. 2007. All rights reserved.

Connect WebSphere Service-Oriented Middleware to SAP

3.9.3 SAP Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Web Services (xvii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Connect WebSphere Service-Oriented Middleware to SAP

for SAP and ALE (xl). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.3.19 WebSphere Enterprise Service Bus sending multiple IDOCs to SAP

Connect WebSphere Service-Oriented Middleware to SAP

Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Connect WebSphere Service-Oriented Middleware to SAP

7.6.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

Connect WebSphere Service-Oriented Middleware to SAP

Chapter 11. Adapter-based integration to SAP: JCA Adapter

11.9 Extension B: WebSphere Process Server

Connect WebSphere Service-Oriented Middleware to SAP

12.5.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238

13.4.1 Creating an integration component library . . . . . . . . . . . . . . . . . 1363

Connect WebSphere Service-Oriented Middleware to SAP

Copyright IBM Corp. 2007. All rights reserved.

13-8 startAdapter2.bat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421

Connect WebSphere Service-Oriented Middleware to SAP

Copyright IBM Corp. 2007. All rights reserved.

Connect WebSphere Service-Oriented Middleware to SAP

Connect WebSphere Service-Oriented Middleware to SAP

Copyright IBM Corp. 2007. All rights reserved.

IBM WebSphere MQ 5.3.0.12

The team that wrote this book

Connect WebSphere Service-Oriented Middleware to SAP

Certified Solution Designer for service-oriented architectures, specialized to

Connect WebSphere Service-Oriented Middleware to SAP

Robert Sulzmann is a Senior IT Consultant for IBM Software Group Germany.

The photo was taken by Ms. Mareike Lattermann.

Connect WebSphere Service-Oriented Middleware to SAP

Become a published author

Connect WebSphere Service-Oriented Middleware to SAP

Information about this book

Copyright IBM Corp. 2007. All rights reserved.

Connect WebSphere Service-Oriented Middleware to SAP

The objective of the book

Chapter 2, Key technologies and concepts on page 11

Copyright IBM Corp. 2007. All rights reserved.

Connect WebSphere Service-Oriented Middleware to SAP

Introduction and objective of

Executive summary on page 4

Copyright IBM Corp. 2007. All rights reserved.

1.1 Executive summary

Connect WebSphere Service-Oriented Middleware to SAP

1.2 The scope of this book

It also provides an overview of WebSphere middleware products and SAP

Chapter 1. Introduction and objective of the book