IBM SG24-6526-00 User Manual
Front cover
Geac System21
commerce.connect
Implementation on the IBM iSeries Server
Gain useful insights through the
product overview
Follow the step-by-step guide to
install commerce.connect
Learn helpful usage and
performance tips and techniques
Yessong Johng
Colin Brown
Jim Hirsch
John Lawler
ibm.com/redbooks
International Technical Support Organization
Geac System21 commerce.connect:
Implementation on the IBM
~ iSeries Server
December 2002
SG24-6526-00
Note: Before using this information and the product it supports, read the information in “Notices” on
page vii.
First Edition (December 2002)
This edition applies to Geac call.connect Version 1.1, vendor.connect 1.1, and System21 3.5.2b SP4 or SP5.
© Copyright International Business Machines Corporation 2002. 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
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Chapter 1. The .connect applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 call.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 vendor.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 2. Architecture of the commerce.connect products . . . . . . . . . . . . . . . . . . . . . 7
2.1 The need for an architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Key Enterprise JavaBeans and WebSphere Application Server benefits. . . . . . . . 8
2.1.2 The architecture moving forward. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 The development process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5 The design methodology: Using Unified Modelling Language . . . . . . . . . . . . . . . 10
2.2 Messaging: Java Message Service and IBM WebSphere MQ . . . . . . . . . . . . . . . . . . . 12
2.2.1 call.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 vendor.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Overview of process.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Architectural representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Architectural goals and constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Non-functional architectural considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Functional architectural considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Reusing and extending System21 business logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Accessing System21 RPG business logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 3. Installing and setting up call.connect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Skills and prerequisites for installing, running WebSphere Application Server . . . . . . . 20
3.1.1 Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 System21 authorization code for Order Management (OM) . . . . . . . . . . . . . . . . . 22
3.2 Standard installation procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Installing Order Management and call.connect. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 WebSphere installation and configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4 Stored procedures and SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.5 Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.6 User profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.7 System21 data set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.8 Java Web Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.9 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 call.connect housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.1 Daily backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2 Stopping WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.3 Starting call.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
© Copyright IBM Corp. 2002. All rights reserved. iii
3.3.4 Restoring IFS objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.1 WebSphere node name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.2 Errors on starting the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.3 Errors when running the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.4 Cached data and .bl and .cd files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.5 Log files and debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5 Manual configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.1 Non-standard Order Management and call.connect installation . . . . . . . . . . . . . . 56
3.5.2 WebSphere manual configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5.3 Manual client installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6 Alternative configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6.1 Setting up a test instance of WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6.2 Setting up an iSeries server for a test system. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.6.3 Server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.6.4 WebSphere administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.6.5 Manual client installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 4. Installing and setting up vendor.connect. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1 Preparing for the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.1 Skills required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2 Installing vendor.connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.1 System21 base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2.2 Java components and configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2.3 Restoring libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.4 Installing and configuring WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.5 IBM HTTP Server for iSeries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2.6 MQSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2.7 Work Management Trigger Handler for the iSeries. . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.8 Active Architecture framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.9 JConnects server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.2.10 Setting up new vendor.connect user IDs and supplier IDs . . . . . . . . . . . . . . . . . 92
4.2.11 Database synchronization from System21 to the vendor.connect database . . 103
4.2.12 Testing the vendor.connect Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2.13 Backing up the configuration components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.3 Changing the iSeries on which the application is running. . . . . . . . . . . . . . . . . . . . . . 105
4.4 Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4.1 Daily . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4.2 Stopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4.3 Starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.4.4 Restoring the vendor.connect IFS objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Chapter 5. Performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.1 Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.2 Operating System/400 (OS/400) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2.1 SQL server job configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2.2 Toolbox JDBC driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.2.3 Subsystems and memory pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.2.4 Automatic performance adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.2.5 Manual performance adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.3 Stateless and stateful connections, datasources, connection pools, etc. . . . . . . . . . . 122
5.3.1 Stateful connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.3.2 Stateless connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
iv Geac System21 commerce.connect: Implementation on the iSeries Server
5.3.3 Total connections and SQL server jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.4 Performance topics for Java virtual machine (JVM) settings . . . . . . . . . . . . . . . . . . . 124
5.4.1 Initial Java heap size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.4.2 Maximum Java heap size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.4.3 Verbose garbage collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.4.4 Static compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Chapter 6. Tips and techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.1 The iSeries integrated file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.1.1 Using File Transfer Protocol (FTP) with the iSeries IFS . . . . . . . . . . . . . . . . . . . 139
6.1.2 Mapping a PC drive to the iSeries IFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.1.3 Editing an iSeries stream file using a PC editor . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.1.4 Stream files and CCSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.1.5 The cd command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.1.6 Managing stream files with the OS/400 WRKLNK command . . . . . . . . . . . . . . . 143
6.1.7 Other stream file commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.1.8 Stream file authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.1.9 Editing an iSeries stream file using the OS/400 EDTF command. . . . . . . . . . . . 146
6.2 The Qshell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.2.1 Managing stream files with Qshell commands . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.2.2 The touch and setccsid commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.2.3 Viewing an iSeries stream file using the Qshell tail command . . . . . . . . . . . . . . 149
6.2.4 Qshell scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.3 Checking the QEJBSBS subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
6.3.1 Instance monitor jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.3.2 Instance administration jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.3.3 Specifying ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.3.4 Application server jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4 WebSphere versions on the iSeries, your console system, and clients . . . . . . . . . . . 156
6.4.1 Checking the WebSphere PTF level on the iSeries . . . . . . . . . . . . . . . . . . . . . . 156
6.4.2 Checking the WebSphere PTF level on a PC. . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.5 Common problems with commerce.connect on iSeries . . . . . . . . . . . . . . . . . . . . . . . 158
6.5.1 Problems connecting the console to WebSphere on the iSeries . . . . . . . . . . . . 158
6.5.2 Checking the iSeries name as required by WebSphere . . . . . . . . . . . . . . . . . . . 159
6.5.3 Checking the iSeries database name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Contents v
vi Geac System21 commerce.connect: Implementation on the iSeries Server
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.
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 illustrates 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. 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 IBM's application programming interfaces.
© Copyright IBM Corp. 2002. All rights reserved. vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks(logo)™
AS/400®
DB2®
DB2 Universal Database™
IBM®
IBM eServer™
iSeries™
MQSeries®
OS/390®
OS/400®
Perform™
Redbooks™
S/390®
SecureWay®
SP™
TCS®
VisualAge®
WebSphere®
The following terms are trademarks of International Business Machines Corporation and Lotus Development
Corporation in the United States, other countries, or both:
Lotus® Notes® Word Pro®
The following terms are trademarks of other companies:
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United
States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems,
Inc. in the United States, other countries, or both.
C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic
Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
viii Geac System21 commerce.connect: Implementation on the iSeries Server
Preface
This IBM Redbook introduces the new Geac commerce platform .connect applications – the
call.connect and vendor.connect applications. These applications extend and enhance the
capabilities of Geac System21 into the intranet and Internet.
This redbook targets consultants or customers who work with these .connect applications. It
explains how to install, maintain, integrate, and manage these applications on the IBM
~ iSeries server. It also helps you to understand the architecture and middleware used
by the applications.
Prior to reading this book, you must be familiar with the basic, traditional use of the iSeries or
AS/400 and System21. For example, you should know how to enter simple commands and
understand such concepts as the library list. Similarly for System21, you should be familiar
with the menus and such tasks as defining a System21 user.
As necessary throughout the book, detail is provided about the newer, less traditional features
of the iSeries such as the integrated files system (IFS), Qshell, Java, and WebSphere.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world working at the
International Technical Support Organization, Rochester Center.
Yessong Johng is an IBM Certified IT Specialist at the IBM International Technical Support
Organization, Rochester Center. He specializes in WebSphere and Domino implementation
on iSeries, with a focus on their integration. Recently Yessong expanded his expertise to
include Linux and its solutions on the iSeries server.
Colin Brown is a Senior Software Architect at Geac United Kingdom (UK). He has 15 years
of experience in software design and implementation. He holds a degree in computer
science. His area of expertise includes Enterprise JavaBean (EJB) component development.
Jim Hirsch is a Test Manager at Geac UK. He has 20 years of experience in various IT
disciplines. He holds a degree in math from London University. His areas of expertise include
AS/400, iSeries, and Geac System21.
John Lawler is a Technical Consultant at Geac UK. He has 18 years of experience in IT. He
holds a degree in mathematics from Oxford University. His areas of expertise include AS/400,
iSeries, UNIX, Windows NT, RPG, C, Java, and WebSphere.
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with
specific products or solutions, while getting hands-on experience with leading-edge
technologies. You'll team with IBM technical professionals, Business Partners and/or
customers.
Your efforts will help increase product acceptance and customer satisfaction. As a bonus,
you'll develop a network of contacts in IBM development labs, and increase your productivity
and marketability.
© Copyright IBM Corp. 2002. All rights reserved. ix
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 Redbooks to be as helpful as possible. Send us your comments about this or
other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JLU Building 107-2
3605 Highway 52N
Rochester, Minnesota 55901-7829
x Geac System21 commerce.connect: Implementation on the iSeries Server
Chapter 1. The .connect applications
This redbook covers the two Geac .connect applications:
call.connect
vendor.connect
This chapter introduces you to these two applications.
Geac also offers the following applications, which provide security, process control and
messaging, and integration with System21:
1
secure.connect
process.connect
inter.connect
These are part of the commerce platform.
commerce.connect that supports the integration of applications and processes with
System21. commerce.platform includes:
The process.connect business modeling tool and workflow engine to define and automate
business processes
Secure.connect to manage and control user access to information and processes
A series of components that contain the business rules and connections needed to
integrate System21 with external applications
To learn how vendor.connect uses process.connect and inter.connect, see Chapter 2,
“Architecture of the commerce.connect products” on page 7.
commerce.platform is the element of
© Copyright IBM Corp. 2002. All rights reserved. 1
1.1 call.connect
Geac call.connect fills two roles. First, it is a telesales-oriented product. It is intended to help
call center personnel actively sell to the customer and create and foster personal
relationships.
To support this type of active sales, call center personnel need instant access to all relevant
information for the calling customer. Typical information includes order history, account
information, and product information. The ability to quickly enter an order (complete with stock
allocation, customer pricing, and credit checking) while the customer is still on the telephone
is paramount. This should be backed up by the ability to script the conversation to highlight
selling and promotion opportunities.
Companies need to classify their markets and customers and determine their policy in
satisfying conflicting priorities and supplies. Geac call.connect is a customer service and
order taking application that is designed to be deployed in this fast moving and complex
environment to meet these requirements.
call.connect is a component-based order capture application. This component-based
approach allows the Geac Professional Services Organization to build solutions that optimize
the order capture process for individual customers. Indeed, this component-based approach
allows Geac consultants to build new order capture solutions for sales force automation or
mobile computing, for example.
Figure 1-1 shows a typical call.connect window. The top two-thirds of the window show the
Reactive Sales page. This contains products that are relevant to the particular customer to
which the operator is selling. These products may be ones that the customer buys on a
regular basis, ones that are on special promotion, or ones that are on the special price list for
the customer. The bottom third of this window shows a configurable set of tabs. These pages
contain information about the current customer, which may help the operator in the telesales
environment.
2 Geac System21 commerce.connect: Implementation on the iSeries Server
Figure 1-1 The call.connect buying list
call.connect is a flexible order capture process that includes the following facilities:
Dynamic buying lists: The lists of products that the customer is likely to purchase is
created by combining a fixed list of products with a dynamic list, based on rules applied to
previous purchase history.
Call management: Supervisors have access to a call-management application that allows
them to track the progress of calls and re-assign them to operators to ensure adequate
throughput. Operators can be assigned a skill level to aid the allocation of customer calls
to operators.
Stock allocation: Rule-based stock allocation and sourcing engine.
Promotions: A rule-based promotions engine supports a variety of promotions (for
example, buy one get one free), special prices, discounts, and loyalty points.
Active selling: Includes support for up-sell and cross-sell.
Up-sell prompts the operator to
suggest a higher value product to appropriate customers. For example, when the operator
selects a 21-inch television, call.connect prompts an up-sell opportunity to sell a 25-inch
television.
Cross-sell prompts the operator to offer associated products. For example,
when the operator selects a video recorder, call.connect suggests some blank tapes to go
with it.
Order management: Includes standing orders, order copy, and the ability to “park” an
order for later completion. call.connect is a “front-office” order capture and customer
service application that integrates with System21 for order fulfilment processing (picking,
despatch, etc.). The component-based approach allows the application to be extended to
support, for example, integration with call-center telephone exchanges to provide efficient
call routing and improved customer responsiveness.
Chapter 1. The .connect applications 3
1.2 vendor.connect
Geac vendor.connect is a supplier self-service application. It is designed to support a
cooperative relationship between customers using System21 and their suppliers. It makes
information available, exchanges business documents, and allows controlled direct update
facilities.
vendor.connect improves supplier communication, aids planning, and reduces inventory
investment in the supply chain. Figure 1-2 shows an example of the vendor.connect
Replenishment page.
Figure 1-2 The vendor.connect Replenishment page
vendor.connect supports a number of supplier relationships. This includes vendor-managed
inventory, direct delivery to the end customer, and normal purchase orders. vendor.connect
provides:
Web-based interfaces to System21 to support:
– Enquiries on orders, returns, and receipts
– Displays of relevant System21 information to the supplier
– New orders and changes to orders since the supplier last visited the site are
highlighted for convenience
– A search facility and rule-based exception notification
Order transmission: In addition to the ability to print or fax orders, you can send orders to
the suppler as e-mail attachments. A Web page allows the supplier to acknowledge receipt
of the order and update the System21 purchase order appropriately.
4 Geac System21 commerce.connect: Implementation on the iSeries Server
Supplier planning: An enquiry allows the supplier to view the stock status and demand for
products for which they are the preferred supplier. The demand enquiry includes relevant
information from System21 – unallocated sales orders, expected demand from Material
Requirements Planning (MRP), expected demand from Distributed Requirements
Planning (DRP), and a historical demand element based on sales and customer-specific
filters (for example, sales current year to date or previous year to date).
Maintain blanket order delivery schedule: Allows the supplier to amend a blanket
purchase order to specify planned delivery dates and quantities.
Promise date update: Allows the supplier to specify the date they plan to make the delivery.
For direct delivery orders, the supplier updates the promise date for the associated sales
order and e-mails the customer with the delivery notification.
Create Advanced Shipping Notification (ASN): Allows the supplier to construct a shipment
from current order lines and amend quantities on the delivery as required.
Support for entering packaging details to allow shipping documentation to be created.
Allows the customer to receive against the ASN. This reduces the time it takes to get
products into the warehouse.
Delivery of direct customer orders: Allows the supplier to build the details of a direct
shipment to an end customer. They can use this as the start of an @ctive process to
initiate customer billing.
Documentation print: Allows the supplier to print standard shipping documentation
(barcode labels, quality reports, etc.) to be sent with the shipment.
Chapter 1. The .connect applications 5
6 Geac System21 commerce.connect: Implementation on the iSeries Server
Chapter 2. Architecture of the
commerce.connect products
The products that make up the commerce.connect platform originate from a diverse
background. The challenge and vision is to bring these applications together into a single
coherent, product strategy. This requires an architecture that can encompass the entire
technology spectrum from the legacy applications to the leading-edge Enterprise Java
applications.
2
This chapter explains the key parts of the architecture, specifically the architecture of
call.connect and vendor.connect, which are the two applications that were designed and
developed from the ground up around an Enterprise JavaBean (EJB)/Java 2 Platform,
Enterprise Edition (J2EE) architecture. Both of these applications integrate with System21.
This chapter also highlights the key integration points.
© Copyright IBM Corp. 2002. All rights reserved. 7
2.1 The need for an architecture
Why is an architecture necessary? Can’t we simply write programs that deliver the function
that is required? The reasons for having an architecture are:
Ever increasing demands are placed on systems in terms of security and availability.
The need to extend the system to both customers and suppliers across the Internet is
growing rapidly. Applications need to have this capability “architected in”.
The need to reduce the product development life-cycle, while delivering more complex
systems at the same time, means that Geac simply cannot develop its systems from
scratch or the infrastructure required.
There is a need to connect different systems (both Geac and external systems) to provide
a viable, reliable, and robust solution.
To meet these requirements, Geac has to rely more and more on infrastructure or middleware
to provide these services. In turn, this means that Geac should clearly architect, develop, and
deploy its software to maximize the benefits that the chosen middleware offers.
Over two years ago, as part of the strategic alliance with IBM, Geac chose to base its new
e-business enterprise applications around WebSphere.
The WebSphere suite of products enables Geac to develop, deploy, and integrate
next-generation e-business applications. This includes such applications for
business-to-business e-commerce. Geac also supports business applications from simple
Web publishing through enterprise-scale transaction processing, extending applications to
incorporate mobile devices, etc.
The entire WebSphere philosophy allows Geac, as an Enterprise Application Developer, to
build, integrate, and deliver solutions more timely to market using WebSphere. WebSphere is
the cornerstone of IBM’s enterprise development strategy. There is little functional or time
availability differences between the release of WebSphere on the iSeries server and
WebSphere on Windows 2000. This allows Geac to deploy its J2EE applications on the
platform that is best suited to the particular customer.
Many of the middleware services provided by WebSphere form part of IBM’s implementation
of the J2EE specification. J2EE defines the standard for developing multi-tier enterprise
applications. J2EE simplifies enterprise applications by basing them on standardized,
modular components, providing a complete set of services to those components, and
handling many details of application behavior automatically, without complex programming.
However, it is true (from practical experience) that both the EJB specification and WebSphere
do not completely remove or absolve the implementor of the responsibility of using the above
services appropriately. Performance needs to be “designed” into the application. Key
architectural decisions still need to be made within the constraints and goals of the project
and these decisions need to be well documented and understood by everyone involved in the
project. This ensures a consistent and high quality approach when designing and
implementing a large-scale project.
2.1.1 Key Enterprise JavaBeans and WebSphere Application Server benefits
The Architectural Specification Geac follows is Enterprise JavaBeans 1.0 (EJB 1.0). As
discussed, the Application Server that Geac uses to implement this specification is IBM’s
WebSphere Application Server Advanced Edition. If the applications that Geac were
implementing were entirely PC-based, WebSphere Advanced Edition would not be
necessary, but this is not the case.
8 Geac System21 commerce.connect: Implementation on the iSeries Server
The EJB standard is a server-side Java-based component architecture for building multi-tier,
distributed, enterprise applications. WebSphere Application Server provides such services
as:
Authentication and security services: Are provided either via the host operating system
or through Lightweight Directory Access Protocol (LDAP).
Transaction management: Ensures integrity of data, not just within a single database,
but across the enterprise.
Resource pooling: Allows more efficient use of valuable system resources. This is
especially important in a large Internet deployment scenario, where there may be
thousands rather than tens of users apparently concurrently using the system.
Clustering and high availability: Enable scalability and ease the implementation of a
fault tolerant high availability system.
Developing EJBs and deploying within WebSphere offers other key benefits that are often
overlooked in the context of a single project, but that
strategy of the company.
For the first time in Geac’s System21 development history, they can deploy the
WebSphere-based Business Application (in the form of EJB components) that they develop
on almost any Enterprise Server where there is a business benefit. Currently Geac’s
requirements are restricted to iSeries and Windows NT or Windows 2000. But in the wider
Geac worldwide context, they could deploy onto OS/390 and most UNIX variants, including
Linux.
must be considered within the technical
As the e-marketplace develops, a significant number of third-party EJB components will
become available. A simple example of this is be Secure Credit Card Authorization. Using a
common architecture across multiple components reduces the number of possible failure
points, simplifies deployment, and in this example, can actually guarantee true transaction
integrity.
2.1.2 The architecture moving forward
Java standards relating to the enterprise have evolved over the past couple of years. The
biggest push on standards by IBM, Sun, and others has been around J2EE. J2EE
encompasses all of the Java standards relating to middleware and enterprise application
development. The EJB specification is now part of the J2EE standard.
Geac’s architectural strategy is to follow, comply with, and implement J2EE solutions. For
example, in the short to medium term, Geac will:
Use JMS as its messaging subsystem with MQSeries as the message transport layer
wherever possible. This allows for maximum flexibility and reliability between Java- and
non-Java-based systems.
Ensure that the Geac’s infrastructure software, such as process.connect and
inter.connect, not only coexist on the same server as one of its WebSphere EJB-based
applications, but will take full advantage of the facilities offered by WebSphere.
Implement and support the next generation of Web Technologies such as Universal
Description, Discovery, and Integration (UDDI). For more information, see:
http://www.uddi.org
Chapter 2. Architecture of the commerce.connect products 9
2.1.3 The development process
Geac uses a development process based around the Rational Unified Process, but heavily
modifies it. Development process refers to a process that starts at project inception and goes
all the way through deployment onto the customer’s site. Rational Software is the prime
contributor to the Rational Unified Process.
A key process difference to the normal Geac approach is that the process is iteration-based,
rather than traditional waterfall based. The process splits the project into several smaller
deliverables rather than one large deliverable at the end of the project. Therefore, a project
can consist of several smaller iterations each with identifiable, measurable objectives.
Another key difference is that the process focuses on risk elimination. The idea is that
identified high risks (for example, potential technical problems) are addressed early on in the
process to avoid large surprises later on. This reduces the risk of costly failures late in the
project. For more information, see:
http://www.rational.com
The architecture has a key role to play in the development process. Early in the process, any
requirements that may impact the architecture, such as the “user interface is going to be
Web-based and PC client-based“, are taken into account and the risk is assessed. When
there are high technical risks to a project, these risks are mitigated in an “elaboration phase”,
which attempts to develop a “proof of concept” deliverable that focuses on the specific risks.
A risk that Geac identified was the need to re-use the existing System21 RPG code base for a
specific business function. Geac saw this as a high risk area, because of the different
technologies involved and potential performance considerations. If a viable solution could not
be found, this would greatly increase the cost of the project because of the need to rewrite
large parts of existing business logic in Java.
2.1.4 Implementation
All software development is carried out under VisualAge for Java 3.5.4. Developers test and
deploy locally in the WebSphere Test Environment before testing on the iSeries server. The
database is always DB2 Universal Database (UDB) for iSeries. Geac uses a shared
VisualAge Repository for Source Code control.
2.1.5 The design methodology: Using Unified Modelling Language
Geac uses the Unified Modelling Language (UML) for both high-level and detailed design. It
uses Rational Rose as the design tool that supports UML.
Geac’s design methodology is more a component than strict object-oriented (OO)-based
design. It designs and implements course grained components based around business
subsystems. Each of these subsystems has one or more defined interfaces.
10 Geac System21 commerce.connect: Implementation on the iSeries Server
Figure 2-1 shows an example of the primary relationship between the main SalesOrder
subsystem and its dependencies for call.connect.
Item
Supply
SalesOrder
Pricing
Delivery
Planning
Figure 2-1 SalesOrder subsystem dependencies
Customer
Chapter 2. Architecture of the commerce.connect products 11
For vendor.connect, Figure 2-2 shows the relationship between the controlling servlet and the
vendor.connect subsystems.
supplier
contract
Generic
Servlet
Figure 2-2 vendor.connect dependencies
call.connect components are designed to be extensible, reusable, and replaceable. This
means that the business functionality can be extended without needing to cut and paste
entire programs. This helps to reduce maintenance overhead and allows existing code to be
reused.
shipment
purchaseorder
fulfillment
2.2 Messaging: Java Message Service and IBM WebSphere MQ
The term messaging refers to the sending of structured information between two or more
subsystems. Typically the message is sent asynchronously. That is that the sender can
continue to run without waiting for a reply from the receiver. Also, the sender and receiver
typically run as separate processes and possibly on physically separate machines.
2.2.1 call.connect
Both call.connect and vendor.connect use asynchronous messaging to meet specific
requirements:
call.connect uses messaging to meet two requirements:
To send information back to the client user interface (UI) such as “the order has been put
on hold due to credit problems”, or “a given item is out of stock”
To allow for time-consuming steps to be completed asynchronously, for example, order
completion when the order is actually committed into System21
12 Geac System21 commerce.connect: Implementation on the iSeries Server
call.connect messaging is implemented using IBM’s implementation of the Java Message
Service (JMS), which itself uses MQSeries as the underlying messaging facility. You can
learn more about JMS at:
http://java.sun.com/products/jms/index.html
Figure 2-3 shows how call.connect uses messaging.
PC Client
Client request
Order information
WebSphere Application
Server
Call Business
Logic
SalesOrder
Subscriber
Figure 2-3 call.connect messaging usage
Event
Queue
SalesOrder
SalesOrder
EJB
EJB
Publish SalesOrder
Business Event
Adding a Sales Order Line scenario
This example explains what happens when an order line is added to a Sales Order by an
operator:
1. The SalesOrder EJB processes the addline in the normal way.
2. The Business Event Addline is published.
3. Control returns back to the client ready for further input.
4. The SalesOrder subscriber is a separate process that listens for SalesOrder events and
receives the Addline message.
5. The subscriber calls back into the SalesOrder EJB to perform a “check for unusual
quantity” request to see if the customer normally orders this amount of stock for the item
concerned.
6. If the quantity ordered is unusual, the SalesOrder subscriber notifies the PC client by
making a call back into the client. The client displays the notification text in the UI status
bar.
Chapter 2. Architecture of the commerce.connect products 13
2.2.2 vendor.connect
vendor.connect uses messaging in conjunction with process.connect. The main requirement
is to synchronize and respond to changes in System21 data such as purchase order updates.
Figure 2-4 shows how this is achieved.
Flow of Information to vendor.connect after System21 Update
Program
Flow starts here
System21
Application
Application
Update
Export
Queue
inter.connect
Channel
Manager
BOD/Java
Mappings
Trigger
Triggers
System21
database
Method
process.connect
fired
Trigger
Queue
Upload
Triggers
Handler
@ctive Modular
Events
Message
Reader
Trigger
Rules
Update
inter.connect
Event
Queue
WebSphere Application
Server
Purchase Order
EJB
System21 Export
Connector
Mapping
XSLT
Map Event Image
to XML BOD
Properties
DB update
via SQL
Export
Queue
vendor.connect
database
Key
Key
System21
commerce.connect
vendor.connect
Figure 2-4 vendor.connect messaging usage
MQSeries is used as the underlying message transport facility by process.connect.
Figure 2-5 shows the relationship between the .connect applications, the commerce.connect
platform, System21, and the IBM middleware-WebSphere and MQSeries application server.
14 Geac System21 commerce.connect: Implementation on the iSeries Server
PC Client Rich
Java Swing UI
Web Browser
UI
.connect application
Middleware
Call
Business
Function
call.connect
EJBs
SQL via JDBC
HTML Web Pages
vendor.
connect
Servlets/JSPs
Call Business Function
vendor.connect
EJBs
Send XML Document
inter.
connect
Via Jacada Server
System21 Business
Function
Web server
EJB Container
Authenticate/
Authorize
User
commerce.connect
System21
secure.
connect
Send XML Document
WebSphere MQ
process.
connect
System21
Database
Product Interaction Overview
Figure 2-5 Relationship between the .connect applications
2.3 Overview of process.connect
process.connect provides a business modelling tool and workflow engine to define and
automate business processes. It delivers optimal business processes that electronically
improve the performance of mid-market companies. It integrates the commerce.platform and
the commerce.connect applications, @ctive Processes and @ctive Modeler, to deliver rapid
modelling, implementation, and execution of critical-business activities.
process.connect can also integrate the processes of the System21 organization with those of
its suppliers or customers. A process can interact with customers (or suppliers) by sending an
Database Triggers
Chapter 2. Architecture of the commerce.connect products 15
e-mail requesting information. The e-mail reply is then used to control the next step in the
process. For example, in an order fulfilment process, if an order cannot be fully allocated, the
process can e-mail the customer and ask if a part shipment is acceptable. Links in the e-mail
send a yes or no response back to the process, which continues appropriately.
2.4 Architectural representation
The deployment requirements (for example, must be able to run on a single iSeries machine)
considerably affect the overall architecture in terms of physical location of database, code,
etc. However, Geac ensures that the architecture is not constrained by these physical
limitations.
There is a logical view of the architecture that identifies each significant layer of the system
and shows how that layer maps onto a design and implementation tiered architecture. For
example, Geac can deploy the Business Logic for vendor.connect onto either the iSeries
server or Windows 2000.
2.4.1 Architectural goals and constraints
In an ideal world, the architecture allows and assists the product team to build the ultimate
system with infinite flexibility, scalability, ease of use, and installation. In the real world, each
interested stakeholder has their priorities for the system.
For a sales person, the system should be seen as infinitely flexible and expandable. In reality,
meeting these aspirations may lead to an architecture that is overly complex and
cumbersome for the main day-to-day running of the system. Therefore the architecture is a
trade-off between many requirements.
2.4.2 Non-functional architectural considerations
This section details the key requirements of the system that may significantly impact the
architecture:
Compatibility with System21: The architecture needs to consider that all .connect
applications have a constraint that they must be compatible with System21.
Performance and scalability: The system must meet specific volume and response time
requirements for the project where the product will be deployed.
Re-usability: Both call.connect and vendor.connect were originally developed as part of
individual specific customer projects. The justification for the development of is that Geac
expects to have a significant amount of design and implementation re-use for future
projects. Therefore, the ability to re-use and extend the core business logic is vital to the
success of the product.
The follow on to re-usability is supportability: Geac must be able to enhance and add
functionality to the product while supporting existing installations from the common design
and code base.
e-commerce support: The call.connect EJB Business Logic components form the
back-end order entry system for the Geac e-commerce solution, web.connect. Therefore,
the architecture must support or be extendible to support the Web deployment model of
servlets, JavaServer Pages (JSPs), etc.
Deployability: In the short term, where possible, both call.connect and vendor.connect
should be deployable on a single iSeries running alongside System21 on the same
physical hardware. Due to hardware and system software constraints, it may be necessary
16 Geac System21 commerce.connect: Implementation on the iSeries Server
to upgrade the hardware, software, or both. The minimum hardware requirements
obviously depend on the usage profile of the customer as well as the base WebSphere
Application Server requirements.
2.4.3 Functional architectural considerations
This section details current known functional requirements that may likely have a major
impact on the architecture of the system.
The deployment influence
Certain aspects of the architecture are strongly influenced by the targeted deployment
implementation platform of Java, WebSphere, and EJB.
What? No entity beans?
From previous architectural prototypes, and call.connect Release 1, and the current level of
EJB support within WebSphere, Geac chose not to use EJB entity beans for database
access. This was primarily on the grounds of performance, which was found to be significantly
slower than the equivalent hand-crafted Java Database Connectivity (JDBC) database
access.
There were also concerns over issues to do with legacy integration, specifically RPG
programs potentially accessing the same tables as those mapped by an entity bean. This was
an indication that there could be further performance problems.
Geac intends to re-evaluate the use of entity beans for the next release of call.connect. The
main benefits are of improved productivity and maintainability.
Session beans
The EJBs that contain the call.connect and vendor.connect Business Logic are designed and
deployed as
specific data (for example, Order Number) across method calls.
In theory (and proven in practice by using the WebSphere Performance Monitor), this allows
the EJB container (WebSphere) to pool session beans, thereby reducing the resource usage
on the system. Even if there are 75 telesales operators all entering orders into the system,
there may be only 10 instances of the Sales Order Session Bean actively running (and
consuming system resources) on the system.
stateless session beans. This means that they do not (directly) maintain any state
2.5 Reusing and extending System21 business logic
This section details the options that are available when considering how to maximize the
reuse of existing legacy application logic.
2.5.1 Accessing System21 RPG business logic
The need to reuse existing System21 logic was identified early on in the original call.connect
project. The following technical options were available.
IBM Toolbox for Java (previously AS/400 Toolbox for Java)
This is an obvious candidate. This has many classes for accessing iSeries objects including
calling programs.
Chapter 2. Architecture of the commerce.connect products 17
There are two disadvantages:
The first is primarily stylistic. Using Toolbox for Java would make Java look more iSeries
specific.
The second is that Toolbox for Java would form its own connection independently of any
JDBC connection. This would mean that updates made by iSeries programs called in this
way could not easily be part of the same commit transaction as updates made through
JDBC.
The first objection is more apparent than real. Toolbox for Java is 100% Pure Java. Therefore,
its use does not restrict the portability of the Java code. The second objection is more
significant.
Java Native Interface (JNI)
Sun defines a technique for calling between Java and native code called the Java Native
Interface
the Sun documentation discusses C and C++, but it is also possible with RPG on the iSeries.
At V4R4 and V4R5, it was quite difficult to integrate Java and RPG. At V5R1, it became much
easier. If V4R5 had to be supported, then the coding complexity would be an issue.
At V5R1, there was no longer an issue but another objection remained. JNI is a direct call and
the native code would have to be on the same system. This would force an element of Java
onto the iSeries and restrict the deployment options for the application. The entire application
would not have to be on the iSeries since some form of remote invocation could be used, but
would add a considerable degree of complexity.
. By native, Sun means non-Java code supported by the underlying platform. All of
Stored procedures
There are two forms of stored procedure on the iSeries server. They may be written in
Structured Query Language (SQL) or in most other supported languages for example, RPG
and CL.
Geac does the reverse of typical usage. It does not have a stored procedure and then decide
to write it in RPG. Instead, Geac already has RPG and creates a stored procedure, which
becomes the program. This stored procedure can then easily be called using JDBC from
Java. For a programmer who has learned basic SQL and JDBC, this is easy.
The choice
JNI is probably the best performing option. However, its restrictions on deployment options
eliminated it. Also V5R1 did not exist at the time that Geac made the choice, and the
complexity of JNI prior to V5R1 counted against it.
The performance of the IBM Toolbox for Java and stored procedure options is similar. The
coding complexity is similar but stored procedures have the advantage of similarity with other
SQL. The final decision was made based on the ability of stored procedures to share
connections and partake in transactions.
18 Geac System21 commerce.connect: Implementation on the iSeries Server
Loading...