In February 2001, IBM released a brand new iSeries and AS/400 product called Connect for iSeries (iSeries Connect), which is a software integration framework for B2B. iSeries Connect is IBM’s OS/400-based low-cost B2B solution for providing secure integration of your core business applications with your trading partner’s business applications. As such, it is built on industry standard software (e.g., Java and XML), as well as IBM-based e- business solutions (e.g., WebSphere and MQSeries). IBM also provides a set of tools that enable trained third-party service providers or IBM business partners to easily connect your business to a trading service (e.g., Ariba, Inc. and Metiom, Inc., formerly Intelisys Electronic Commerce) in a matter of days. Trading services can offer substantial cost savings compared to electronic data interchange (EDI) or other custom-built B2B solutions.

In this article, we’ll introduce the iSeries Connect solution for B2B trading solutions using OS/400 V4R5 or above. We’ll explain the concepts behind iSeries Connect, the architecture and what buyer/supplier models it runs under, and how to get started using iSeries Connect in an OS/400-based B2B environment. This article will give you the core information you need to evaluate iSeries Connect and decide if it’s right for your shop.

Solving the Seller’s Dilemma

iSeries Connect focuses on the sell-side (supplier side) of B2B. This involves suppliers offering their goods and services to other trading partners through direct and indirect buying or e-marketplaces. iSeries Connect is targeted to sellers of goods and services who suddenly realize that buyers are now in control of the trading protocols to be used for the exchange of goods and services. Buyers, in an attempt to streamline their purchasing process and reduce expenses, are purchasing new procurement software from companies like Ariba. This software has the capability of communicating to multiple seller organizations using XML-based protocols that flow easily over the Internet. Buyers, therefore, are motivated to do business with sellers that support these Internet protocols as it helps them to reduce their expenses. Sellers not supporting these new protocols will be at a competitive disadvantage, and iSeries Connect is your OS/400-based answer to getting into this marketplace.

The iSeries Connect Solution

Your OS/400-based machine already has the necessary infrastructure needed to support these Internet-based protocols. However, if you decide to program this solution yourself, be aware that there would be a fair amount of programming required to support each trading partner’s unique requirements. iSeries Connect is designed to support multiple

trading partner protocols and to interface to multiple back-end applications. One of the goals of iSeries Connect is to provide a highly configurable plug-in architecture that is easy to use and extendable. Figure 1 outlines the iSeries Connect framework and how it is supported by the following segments that allow the product to be installed, configured, customized, and managed:

• Delivery gateway—This segment handles the e-business interface from various trading partners using multiple protocols. The Delivery gateway consists of a collection of plug-ins that support several popular buyer and e-market protocols used to submit requests (e.g., order placement, order status checks, and catalog maintenance). These plug-ins are provided with the product.

• Flow manager—This segment deals primarily with the processing of the B2B requests by tying them into existing ERP, order processing, and other core business applications. The Flow manager contains a collection of connector types that support three popular OS/400 interfacing mechanisms: program calls, queues, and Java methods. These connector types are provided with the product. For each connector instance, an Application Connector Document (ACD) must be provided to describe the interface and the data to be passed to the application.

• Tools—This segment provides the appropriate configuration tools that are used to install, develop, deploy, and manage your iSeries Connects plug-ins and connectors.

iSeries Connect is built using the industry standard Java and XML languages. It is written in 100% Pure Java for ease of development and portability. A messaging interface is used to transfer XML documents between different components of iSeries Connect.

Runtime Architecture

Figure 2 shows the relatively simple concept behind iSeries Connect. iSeries Connect receives messages from buyers’ procurement software, and it maps those messages into already existing back-end applications. The rules for mapping these messages are provided as a series of XML documents that can be created by the iSeries Connect Tools. No special programming is required. iSeries Connect is implemented as a pluggable framework that will make it easy to add additional trading partner protocols in the future. iSeries Connect v1.0 is written to handle two trading partner protocols initially: Commerce XML (cXML)

from Ariba and mXML from Metiom. Figure 3 depicts the architecture of iSeries Connect v1.0.

The primary runtime components of iSeries Connect are the Delivery gateway and the Flow manager. These two components accept incoming requests from trading partners, map those requests into back-end applications, and return an appropriate response to the trading partner. MQSeries is used to communicate between the Delivery gateway and Flow manager.

The Delivery gateway is implemented as a Java servlet. As such, it requires the services of an application servlet engine in order to operate. With iSeries Connect, two choices for servlet engines are available:

• WebSphere Application Server—Either the Standard or the Advanced edition can be used in combination with the IBM HTTP server for AS/400 to provide hosting for Java servlets and HTTP protocol handling, respectively.

• Lotus Domino—Domino has a built-in servlet engine and its own HTTP server that can also be used to host Java servlets.

The Flow manager receives requests from the Delivery gateway and transforms them into something that an existing back-end application can process. This transformation is done based on a set of rules supplied by the customer. The transformation rules are in the form of a Process Flow Model (PFM) that is built by using the iSeries Connect business process editor tool. Currently, iSeries Connect supports the following three connector types as ways to pass requests to back-end applications:

• Direct program calls to ILE applications (e.g., RPG)

• Java method calls

• Queuing mechanisms (e.g., MQSeries queues or OS/400 Data Queues)

Additional connector types will be provided in subsequent versions of iSeries Connect.

Flow manager communicates with applications using one of the connector types, therefore it must be provided with the incoming messages and parameters format that the target OS/400 application expects. These descriptions must be provided by the customer or the OS/400 application provider in the form of an ACD. An ACD is an XML document that adheres to the document type definition (DTD) defined for the appropriate connector type. There are ACD DTDs for each of the three supported connector types. An ACD for the Java connector and the program call connector indicates the name of the class or program to be called and a description of the parameters it expects to be passed. An ACD for the queue connector indicates the name of the queue to use and the format of the message to be placed on that queue.

B2B Buyer/Supplier Models

Early B2B marketplace vendors such as Metiom, Ariba, and Commerce One have independently developed a similar approach for buyers to communicate with suppliers. This is more or less a de-facto standard that we will call the B2B buyer/supplier model and it consists of two models for processing orders: the Local Catalog model and the Remote Catalog model.

The Local Catalog B2B Buyer/Supplier Model

Figure 4 depicts the B2B buyer/supplier model. A buyer organization purchases procurement software from a third-party vendor. This procurement software allows a requisitioner in the buying organization to use a browser to make purchases (step 1). In this scenario, each supplier is responsible for uploading the catalog information to the buyer’s site (step 0), and, since the catalog information is hosted at the buyer’s site, this B2B buyer/supplier scenario is called the Local Catalog model. After the requisitioner selects the items and quantities needed, the order is approved and submitted (step 2). An approved order request results in a purchase order message being sent by the procurement software to the appropriate supplier of the goods (step 3). The supplier accepts the purchase order, processes it, and sends a purchase order response message to indicate that the order was accepted. It is the job of iSeries Connect to accept the purchase order request, process it, and respond with a purchase order response (step 4). iSeries Connect is responsible for accepting the various message requests (e.g., cXML for Ariba, mXML for Metiom) and mapping the data from the incoming message to a format understandable by a back-end application. It then maps the response from the back-end application to a response format acceptable by the procurement software. iSeries Connect can also help build, upload, and manage the catalog information that the buyer sees.

The Remote Catalog B2B Buyer/Supplier Model

Figure 5 shows a variation of the B2B buyer/supplier model. The catalog and shopping experience are hosted at the supplier site (the Remote Catalog model). In this scenario, the requisitioner uses a browser to choose an approved catalog from which to shop (step 1), but the procurement software indicates that the catalog is hosted remotely. The procurement software knows or obtains directly from the supplier site the URL needed for shopping the catalog and returns this information to the browser. The requisitioner then shops the remote catalog (step 2), places items in a shopping cart, confirms the order, and finalizes the order (through the actions in step 3, or steps 3a and 3b as explained later).

When the requisitioner confirms an order, the supplier’s responsibility is to send the shopping cart contents to the buyer’s procurement system. The shopping cart contents contain all the information about the items being purchased and it can be sent to the procurement system in one of two ways: It can be sent directly to the buyer’s system as a separate message (step 3), or it can be sent directly to the requisitioner’s browser (step 3a) where it is redirected to the procurement system (step 3b). The latter approach is usually selected because it is the easiest way to traverse through firewalls. The remaining steps are the same as the local catalog scenario where the order is approved (step 4) and a purchase order is sent to the supplier system (step 5). Finally, the supplier processes the order in its back-end applications (step 6). iSeries Connect handles the duties of setting up and extending the commerce application (e.g., WebSphere Commerce Suite) to handle the remote browsing requests and the generation of the shopping cart contents. It also handles the resulting purchase order and integrates it with the back-end application or routes it to WebSphere Commerce Suite for completion.

Roles and Responsibilities for iSeries Connect Deployment

The customer or a third-party service provider can handle iSeries Connect installation. iSeries Connect is installed directly to an OS/400-based machine from a CD-ROM either on the target AS/400 or iSeries 400 machine or on a client PC. All the components of iSeries Connect will install onto your OS/400-based machine during the installation. MQSeries, which is included on the iSeries Connect CDs, is also installed. The iSeries Connect Tools are installed separately on a client PC.

The iSeries Connect configuration wizard is accessed inside a browser session and it ensures that all the necessary prerequisites are installed on iSeries. These prerequisites include OS/400 V4R5, an HTTP Server, a Web Application Server, and, optionally, WebSphere Commerce Suite (if you are hosting a storefront as we discussed in the Remote Catalog B2B Buyer/Supplier Model section). The proper versions of these applications must be installed before continuing with the iSeries Connect configuration.

When all the prerequisites are in place, the configuration wizard then helps you through the following configuration tasks:

• Create a new iSeries Connect instance

• Specify which trading partner protocols and transactions should be supported (e.g., Ariba, Metiom)

• Specify which deployment platform to use (e.g., WebSphere or Domino)

• Select which WebSphere Commerce Suite instance to use (if you’re using the Remote Catalog model)

• Create a new iSeries Connect subsystem, MQSeries queues, HTTP, and WebSphere Application Server instances

WebSphere Commerce Suite Configuration

If a remote catalog is to be supported on the supplier’s system for direct shopping by the buyers, then the WebSphere Commerce Suite (WCS) must be purchased, installed, and configured. This is an optional step and must be performed by someone knowledgeable in WCS. A new WCS instance for B2B shoppers must first be created on the iSeries server using the instructions included with WCS. Then, WCS Store Creator is run from a PC to create a B2B-enabled store. iSeries Connect includes a suitable store template that is used for this purpose. Once created, this B2B store is deployed to iSeries. This will define the merchant information as well as the products to be sold. At this time, shopper groups can be defined to allow for buyer-specific pricing. Next, the iSeries Connect Buyer/ Supplier configuration tool is used to create buyer and supplier information and associate it with WCS shoppers and merchants respectively. Shoppers can then be placed in the previously created shopper groups using WCS administration tools.

Buyer/Supplier Configuration

The next step is to provide the B2B-specific information that establishes the supplier installation and identifies the trading partners (buyers) required for communication. This is done by using the Buyer/Supplier configuration tool that is run by a service provider with an understanding of B2B concepts. The Buyer/Supplier configuration tool is run from a standard browser session and it will guide the user through these steps per iSeries Connect instance:

1. Register the B2B supplier information. The supplier information can be associated with one or more marketplaces. For each marketplace, the user specifies the acceptable logon information that is to be provided by that marketplace and the specific actions (protocols) that will be accepted from that marketplace.

2. Associate the supplier information. If the WebSphere Commerce Suite is used for remote catalog support, the user can associate the supplier information with a WCS merchant. (This step is optional.)

3. Register the B2B supplier information with the remote trading partners. For Ariba, this is done by using a Web browser to register supplier information with the Ariba Network. The information registered must match the information that was entered in step 1.

4. Register the B2B buyer organization information for all potential buyers. Each buyer organization can be associated with one or more suppliers defined in the previous step. If WCS is used for remote catalog support, each buyer can also be added as a shopper in the WCS shopper table.

Build Local Catalogs

If the buyers are shopping from catalogs hosted locally at the buyer’s site or from the marketplace, the supplier must export product information in catalog format. iSeries Connect provides a Connect catalog services tool to help create a catalog database. The Connect catalog services tool is run from a standard browser and is used to perform the following functions:

• Extract product information from a flat file or a database into a special catalog database. The tool helps associate the columns of the database file with the columns of the catalog file and maintains this mapping for subsequent updates to the catalog file. The type of information required for a properly formatted catalog includes at least a product name, product description, and a manufacturer name.

• Associate the catalog with a B2B supplier created with the Buyer/Supplier configuration tool.

• Edit the catalog contents to include additional field level information that may not have been available from an existing database or flat file. For example, it may be necessary to add fields such as UNSPSC classification code, unit price, currency, and unit of measure. The tool makes this editing easy. Note: For small catalogs, it is possible to completely build the catalog by using this editing tool. It is not necessary to import the data from a database or flat file.

• Extract the catalog information in a format acceptable by the buying organization or marketplace. iSeries Connect supports two catalog export formats:

• cXML 1.1 catalog format for Ariba

• CIF 3.0 (Catalog Interchange Format, comma delimited file)

The catalog information is extracted and sent to the buyer or marketplace using a mutually agreed upon transport mechanism (usually a Web browser or FTP upload).

iSeries Connect Request Processing

The goal of iSeries Connect, which is illustrated in Figure 6, is to accept requests from remote trading partners and map those requests to new or existing back-end applications. Incoming requests (usually in XML format) pass through the iSeries Connect Flow manager into a back-end application where they are processed, and an appropriate response is returned. In order for this processing to take place, runtime metadata information must be supplied to the flow manager.

First, information needs to be made available about the format of data expected by the back-end application. The back-end application’s interface is abstracted in the form of an ACD. Development of an ACD for a particular application is done typically by the application’s provider, business partner, or by IBM, and it can be done by the service provider doing the installation. Before creating an ACD, you must first decide what connector type will be used. Figure 7 outlines the iSeries Connect connector types available.

The Program Call connector is used to call any iSeries program either on the local system or on a remote iSeries system. A PCML document describes the program to be called and the parameters expected by that program.

The Queue connector is used to send and receive messages on an MQSeries queue or an iSeries data queue. These queues can be defined locally or on a remote system. A PCML document or an XML document can be used to define the format of the message to be placed on the queue. The message must be in the format expected by the receiving application.

The Java connector is used to call a user-written Java method that, in turn, can call other Java programs (local or remote) or access local or remote databases. The data available to this Java method is defined by either a PCML or an XML document.

For a particular connector type, an ACD defines a connector instance. A connector instance must be defined for each back-end application. To assist in creating an ACD, iSeries Connect provides an ACD Creation function as part of its business process editor tool. This tool is used to create an ACD for a particular connector type, with properties specific to the application being accessed. For each ACD, you specify the ACD name, the type of ACD (e.g., Program Call, Queue, or Java method), specific properties of the program or queue being accessed (e.g., system name, user ID, and password to use), and

the name of the PCML or XML documents that describe the input and output data for the back-end application.

A completed ACD is then fed into the process flow creation function of the business process editor. This tool is used to create a PFM, which correlates an incoming transaction request (e.g., cXML OrderRequest) with a particular application’s ACD. The PFM also includes mapping information that describes how to map the trading partner’s request and response fields into the application’s input/output parameters. The Process flow creation tool displays the fields in the incoming request and the mappable fields in the ACD and it guides the process of matching the appropriate fields together.

Building the ACD and PFM is the most difficult aspect of setting up iSeries Connect because this requires knowledge of B2B protocols such as cXML and domain knowledge of the back-end applications. To make this process easier, ACDs and PFMs can be pre-built by business partners and application providers and then made available to service providers for easy deployment.

Back-end Application Connector Deployment

The ACD and PFM are not tied to any specific installation of iSeries Connect. To tie them to a particular instance, they must be fed into the Process deployment tool, which uniquely identifies the specific B2B request to be serviced: by protocol, marketplace, buying organization (or *All), request action, and supplier (or *All).

Setting Up a B2B Supplier Site

To summarize, here are the steps involved in setting up an iSeries Connect supplier site:

1. Install iSeries Connect from a CD.

2. Configure one or more iSeries Connect instances. Set up MQSeries queues.

3. Optionally configure WebSphere Commerce Suite for supplier-hosted catalog shopping. Identify approved buyers.

4. Register supplier and buyer information. Associate buyer organizations with the supplier.

5. Optionally build catalogs for export to buying organizations.

6. Define interfaces to back-end applications. Use the Business Process Editor (BPE) to build ACDs.

7. Provide mapping rules between marketplace messages and back-end applications—Use BPE to create PFMs. Map fields from incoming message to fields in the ACD.

8. Associate mappings with a step in the process flow.

At this point, iSeries Connect is ready to accept requests from various trading partners, call the appropriate back-end applications, and return responses.

An iSeries-connected World

As you can see, the concepts behind the iSeries Connect are not difficult to understand, but understanding iSeries Connect is only the beginning. For more information on ordering, buying, installing, and configuring your OS/400 V4R5 as a B2B supplier site, be sure to check out the links on IBM’s iSeries Business-To-Business Web site at www.iseries.ibm.com/btob. Also, be sure to read IBM’s White Paper about iSeries

Connect at the IBM Connect for iSeries Overview Web site at (www.iseries.ibm.com/ btob/iconovr1.htm).

References and Related Materials

Ariba, Inc. Web site: www.ariba.com

Commerce One, Inc. Web site: www.commerceone.com

IBM’s Business-To-Business Web site: ww.iseries.ibm.com/btob

IBM’s Connect for iSeries Web site: www.iseries.ibm.com/btob/ iconnect.htm

IBM Solution Mall: IBM eserver iSeries solution team Web site: www.iseries.ibm.com/btob/partner

Metiom, Inc. Web site: www.metiom.com

White Paper: IBM Connect for iSeries Overview Web site: www.iseries.ibm.com/btob/iconovr1.htm

Figure 1: iSeries Connect is an OS/400-based framework that contains certain key segments for implementation.

Figure 2: The concepts behind iSeries Connect are relatively simple.

Figure 3: Under the covers, this is what iSeries Connect looks like and how its architecture fits together

Figure 4: In the B2B Local Catalog model, the catalog resides on the buyer’s system.

Figure 5: In the B2B Remote Catalog model, the catalog resides on the seller’s system, and this adds another layer of complexity to the process.

Figure 6: iSeries Connect’s goal is to accept requests from remote trading partners and map those requests to new or existing back-end applications.

Figure 7: iSeries connector types define what types of OS/400 objects and applications can be used to process orders.